From amenkov at openjdk.org Fri Nov 1 00:53:34 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 1 Nov 2024 00:53:34 GMT Subject: RFR: 8343378: Exceptions in javax/management DeadLockTest.java do not cause test failure In-Reply-To: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com> References: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com> Message-ID: On Thu, 31 Oct 2024 12:11:41 GMT, Kevin Walls wrote: > Test update: fail when it hits an Exception. > > This test still references jmxmp and iiop, which are of course redundant, there are various tests that still do this. > I am working on http, so we may revisit these tests in future to change their list of protocols. > > For now, I'd like to simply make this test fail if any of the protocols it tests have failures. > Fix a few typos while we are here. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21804#pullrequestreview-2409308811 From dholmes at openjdk.org Fri Nov 1 01:59:50 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 01:59:50 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25] In-Reply-To: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> References: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> Message-ID: On Thu, 31 Oct 2024 21:50:50 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: > > - add comment to ThreadService::find_deadlocks_at_safepoint > - Remove assignments in preempt_kind enum Marked as reviewed by dholmes (Reviewer). src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); > 888: } else { > 889: // frame can't be freezed. Most likely the call_stub or upcall_stub Suggestion: // Frame can't be frozen. Most likely the call_stub or upcall_stub src/hotspot/share/services/threadService.cpp line 467: > 465: if (waitingToLockMonitor->has_owner()) { > 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); > 467: // If currentThread is nullptr we would like to know if the owner Suggestion: // If currentThread is null we would like to know if the owner src/hotspot/share/services/threadService.cpp line 474: > 472: // vthread we never record this as a deadlock. Note: unless there > 473: // is a bug in the VM, or a thread exits without releasing monitors > 474: // acquired through JNI, nullptr should imply unmounted vthread owner. Suggestion: // acquired through JNI, null should imply an unmounted vthread owner. ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2409348761 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344054 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344940 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825345446 From dholmes at openjdk.org Fri Nov 1 02:04:27 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 02:04:27 GMT Subject: RFR: 8341796: Fix ExceptionOccurred in jdk.hotspot.agent [v2] In-Reply-To: References: Message-ID: <-z5Ocq_D4HdfteyIMYCkDPjahbK0a8JYNjjQ5wRyDns=.d0c0db47-685a-4a9f-820c-ab960bbf4fa4@github.com> On Thu, 31 Oct 2024 20:14:43 GMT, Justin Lu wrote: >> Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.hotspot.agent_. >> >> This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > for consistency, include the comments as well Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21813#pullrequestreview-2409354612 From dholmes at openjdk.org Fri Nov 1 02:08:28 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 02:08:28 GMT Subject: RFR: 8341798: Fix ExceptionOccurred in jdk.jdwp.agent In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 20:13:08 GMT, Justin Lu wrote: > Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.jdwp.agent_. > > This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean. Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21814#pullrequestreview-2409356889 From cjplummer at openjdk.org Fri Nov 1 02:33:27 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 1 Nov 2024 02:33:27 GMT Subject: RFR: 8341796: Fix ExceptionOccurred in jdk.hotspot.agent [v2] In-Reply-To: References: Message-ID: <6kXNQsZhQikOZCoidcFhJn0v25wpTZi6P4JfN8AGnwE=.e8f84a1b-a86a-4617-957f-0b5aa8815359@github.com> On Thu, 31 Oct 2024 20:14:43 GMT, Justin Lu wrote: >> Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.hotspot.agent_. >> >> This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > for consistency, include the comments as well Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21813#pullrequestreview-2409374400 From cjplummer at openjdk.org Fri Nov 1 02:36:33 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 1 Nov 2024 02:36:33 GMT Subject: RFR: 8341798: Fix ExceptionOccurred in jdk.jdwp.agent In-Reply-To: References: Message-ID: <5g14kBnz3Y9QmtfcR-Fpqp0S6ZxJyS9HTkGSynHbgdE=.8876d8da-929f-46e4-8bce-ac558e3f8840@github.com> On Thu, 31 Oct 2024 20:13:08 GMT, Justin Lu wrote: > Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.jdwp.agent_. > > This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean. Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21814#pullrequestreview-2409376344 From heidinga at openjdk.org Fri Nov 1 03:57:34 2024 From: heidinga at openjdk.org (Dan Heidinga) Date: Fri, 1 Nov 2024 03:57:34 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 02:23:24 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed whitespace; fixed minimal build src/hotspot/share/cds/aotClassInitializer.cpp line 348: > 346: } > 347: JavaValue result(T_VOID); > 348: JavaCalls::call_static(&result, ik, Based on the discussions in JDK-8342283, do we need a memory fence after the call to runtimeSetup? I think we do to be consistent with the non-AOTCache run as there is a fence after `` (when this code would normally run) due to the initialization lock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1825400292 From dholmes at openjdk.org Fri Nov 1 04:52:29 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 1 Nov 2024 04:52:29 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v2] In-Reply-To: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com> References: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com> Message-ID: On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote: > I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. A `CriticalSection` is a mutex. A RWLock is not a "mutex". ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2451288744 From jwaters at openjdk.org Fri Nov 1 05:28:31 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 1 Nov 2024 05:28:31 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v4] In-Reply-To: References: Message-ID: <-ksBFuJLoUvuk79FQCrZeyidIBwr8uQLJ6cKC883Yxc=.d0b3d22e-2432-4885-ac4b-5889f74f0619@github.com> On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove global memHandle, would've liked to keep it as a comment :( I guess Weijun's comment means security is good to go, even though it's not an approval. jpackage, any comments? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2451316177 From dlong at openjdk.org Fri Nov 1 07:17:48 2024 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Nov 2024 07:17:48 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo wrote: >> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest. Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling. >> >> It's still unclear to me exactly how we resume after preemption. It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted. If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment. In your example, last_Java_pc would be set to 0xffffdfdba5e4. I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments. > >> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? >> > It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825498409 From kevinw at openjdk.org Fri Nov 1 07:55:27 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 1 Nov 2024 07:55:27 GMT Subject: RFR: 8343378: Exceptions in javax/management DeadLockTest.java do not cause test failure In-Reply-To: <07kSV5FDDKBnyWvsM8qELMdZ7llvUV_l_HjS4sWgT6k=.5bd99d2e-73b8-409a-a1d8-b09a69f23493@github.com> References: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com> <07kSV5FDDKBnyWvsM8qELMdZ7llvUV_l_HjS4sWgT6k=.5bd99d2e-73b8-409a-a1d8-b09a69f23493@github.com> Message-ID: On Thu, 31 Oct 2024 21:57:10 GMT, Chris Plummer wrote: >> I actually think it's more readable with the comma. >> If there is (one protocol failure), then that (fails the test). >> Without the comma, "failure fails" runs together, but the failure did not fail, it was a perfectly good failure. Pause for breath. What do we do now? Well, experiencing that kind of problem, fails the test. >> >> Extended discussions on language style, from the test that brought you "listner" and "should no block". 8-) > > The best way to get to the right answer here is simplify to the subject and verb: "failure fails". You don't put a comma between the subject and the verb, unless is something more much complex like "a failure, for which there can be more than one, fails the test". I think the reason you feel it reads better with the comma is because of the repetition of "fail". Would you still want a comma if the sentence was "any one protocol error fails the test"? I assume no, but the sentence is structurally identical. Right, it is the repetition that makes me want the comma. There are other ways of phrasing this which would not need the comma. Even then, I still might introduce one to imply a pause, which I still think helps make it unambiguous on first read, without making it "...causes the test to fail" which is unnecessarily lengthy. It's also a comment buried in a test, not front page news. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21804#discussion_r1825551758 From kevinw at openjdk.org Fri Nov 1 08:38:31 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 1 Nov 2024 08:38:31 GMT Subject: RFR: 8343378: Exceptions in javax/management DeadLockTest.java do not cause test failure In-Reply-To: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com> References: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com> Message-ID: On Thu, 31 Oct 2024 12:11:41 GMT, Kevin Walls wrote: > Test update: fail when it hits an Exception. > > This test still references jmxmp and iiop, which are of course redundant, there are various tests that still do this. > I am working on http, so we may revisit these tests in future to change their list of protocols. > > For now, I'd like to simply make this test fail if any of the protocols it tests have failures. > Fix a few typos while we are here. Thanks Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21804#issuecomment-2451512243 From kevinw at openjdk.org Fri Nov 1 08:38:31 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 1 Nov 2024 08:38:31 GMT Subject: Integrated: 8343378: Exceptions in javax/management DeadLockTest.java do not cause test failure In-Reply-To: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com> References: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com> Message-ID: On Thu, 31 Oct 2024 12:11:41 GMT, Kevin Walls wrote: > Test update: fail when it hits an Exception. > > This test still references jmxmp and iiop, which are of course redundant, there are various tests that still do this. > I am working on http, so we may revisit these tests in future to change their list of protocols. > > For now, I'd like to simply make this test fail if any of the protocols it tests have failures. > Fix a few typos while we are here. This pull request has now been integrated. Changeset: 4a70c83b Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/4a70c83bd0c563185123ce9d8a34e006c62db7cc Stats: 11 lines in 1 file changed: 4 ins; 1 del; 6 mod 8343378: Exceptions in javax/management DeadLockTest.java do not cause test failure Reviewed-by: amenkov ------------- PR: https://git.openjdk.org/jdk/pull/21804 From attila at openjdk.org Fri Nov 1 09:19:12 2024 From: attila at openjdk.org (Attila Szegedi) Date: Fri, 1 Nov 2024 09:19:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Modify three RMI tests to work without the security manager: > - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java > - test/jdk/java/rmi/registry/readTest/CodebaseTest.java > - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java > Also remove them from the problem list. > - Remove two obsolete RMI tests: > - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java > - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java > Adjust two tests to run without the Security Manager: > - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java > Remove all of these tests from the problem list. > - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. > - Added API Notes to ProtectionDomain clarifying that the current policy always > grants no permissions. A few other small changes to Policy and PD. > - Merge branch 'master' into jep486 > - JAXP tests: organize imports of a few tests > - Improve description of Executors.privilegedThreadFactory > - rename TestAppletLoggerContext.java as suggested in util test review > - clientlibs: Javadoc cleanup > - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b `jdk.dynalink` changes look good. ------------- Marked as reviewed by attila (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2409755977 From schernyshev at openjdk.org Fri Nov 1 09:54:36 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 1 Nov 2024 09:54:36 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev wrote: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... I've done the standard tiers (1-3), and additionally "jtreg:jdk/internal/platform/cgroup" and "gtest::cgroupTest". I see now some of the dockers are failing. I am looking into it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2451611651 From kevinw at openjdk.org Fri Nov 1 12:15:33 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 1 Nov 2024 12:15:33 GMT Subject: RFR: 8204681: Option to include timestamp in hprof filename [v2] In-Reply-To: References: Message-ID: On Tue, 10 Sep 2024 15:42:57 GMT, Sonia Zaldana Calles wrote: >> Hi all, >> >> This PR addresses [8204681](https://bugs.openjdk.org/browse/JDK-8204681) enabling support for timestamp expansion in filenames specified in `-XX:HeapDumpPath` using `%t`. >> >> As mentioned in this comments for this issue, this is somewhat related to [8334492](https://bugs.openjdk.org/browse/JDK-8334492) where we enabled support for `%p` for filenames specified in jcmd. >> >> With this patch, I propose: >> - Expanding the utility function `Arguments::copy_expand_pid` to `Arguments::copy_expand_arguments` to deal with `%p` expansions for pid and `%t` expansions for timestamps. >> - Leveraging the above utility function to enable argument expansion for both heap dump filenames and jcmd output commands. >> - Though the linked JBS issue only relates to heap dumps generated in case of OOM, I think we can edit it to more broadly support filename expansion to support `%t` for jcmd as well. >> >> Testing: >> - [x] Added test cases pass with all platforms (verified with a GHA job). >> - [x] Tier 1 passes with GHA. >> >> Looking forward to hearing your thoughts! >> >> Thanks, >> Sonia > > Sonia Zaldana Calles has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8204681 > - 8204681: Option to include timestamp in hprof filename Thanks Sonia -- Regarding timestamp format: UL style got you a timestamp like: 2024-10-31T15:14:39.344-0400 make_log_name() would give: YYYY-MM-DD_HH-MM-SS Precision vs filename length? The .001 of a second accuracy might not be that meaningful on a file name. I was liking the make_log_name() style above, but it's not really critical which. But what does Unified Logging do when you log to a file? file=filename uses %p and %t for pid and STARTUP timestamp. Hmm.... For usage like heapdumps where you may want multiple, current time is much more useful than startup time. But hey, it's another vote for the use of %t for timestamp in a filename, and a UnifiedLogging log to a file does not give you control over exactly how you want the timestamp in the filename. You get what you get. (The events logged in the file are what matter I suppose (and I agree)). So what timestamp do you get? java -Xlog:gc*:file%t.out -version creates file2024-11-01_12-01-10.out ..so that looks like the simpler version, like make_log_name() mentioned earlier. No milliseconds or time offsets. I would do that, and forget multi-character patterns unless somebody really wants/needs it. 8-) ------ On changing Arguments::copy_expand_pid to Arguments::copy_expand_arguments There are a few users, listed below. I can't see any problem by starting to respect a new % token, but there is always a chance as I think Thomas was suggesting. If anybody is concerned, we should keep Arguments::copy_expand_pid, and add a new function to do timestamps additionally. ------ Arguments::copy_expand_pid I find usage by: perfMemory.cpp: perdata file is not normally going to have %t in it but -XX:PerfDataSaveFile= could set it. Users would be really unwise to add specify %t here! Maybe that means there should still be Arguments::copy_expand_pid which ONLY does %p expansion. diagnosticArgument.cpp uses it, good, that's what we want. vmError.cpp: next_OnError_command uses it. Having timestamp support in -XX:OnError command strings in addition to %p could be really useful. Small chance of a clash with existing commands/scripts. vmError.cpp: expand_and_open / prepare_log_file / VMError::report_and_die calls: prepare_log_file(ErrorFile, "hs_err_pid%p.log",... OK, being able to specify a timestamp in hs_err could be very useful. Also the compiler replay data file would be affected (again not bad). Also called by JVMCI::fatal_log() meaning -XX:JVMCINativeLibraryErrorFile= could set a filename using %p and now %t. jfrEmergencyDump.cpp: create_emergency_dump_path() uses it, with these patterns, which are not configurable, so not a problem: 44 static const char vm_error_filename_fmt[] = "hs_err_pid%p.jfr"; 45 static const char vm_oom_filename_fmt[] = "hs_oom_pid%p.jfr"; 46 static const char vm_soe_filename_fmt[] = "hs_soe_pid%p.jfr"; The changes look generally useful. A release note and maybe other doc updates will be needed (which is fine). If the impact looks too much, keeping Arguments::copy_expand_pid and creating Arguments::copy_expand_arguments which optionally does timestamp expansion, will mean the other changes (hs_err, replay, etc..) can be made separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20568#issuecomment-2451776538 From schernyshev at openjdk.org Fri Nov 1 13:15:28 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 1 Nov 2024 13:15:28 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev wrote: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Thanks Severin! It was the problematic change in the logic that skips duplicate cgroup contoller mount points. Failing tests are mounting duplicates of the host's cgroups with `--volume=/sys/fs/cgroup:/cgroup-in:ro`. As they're in fact mounting read-write, the logic picked up `rw` mount option and falsely detected "host mode". Also the `--privileged` creates `rw` mounts, so the entire approach needs correction. I am changing to the draft PR for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2451851221 From aboldtch at openjdk.org Fri Nov 1 15:26:56 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Fri, 1 Nov 2024 15:26:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25] In-Reply-To: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> References: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> Message-ID: On Thu, 31 Oct 2024 21:50:50 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: > > - add comment to ThreadService::find_deadlocks_at_safepoint > - Remove assignments in preempt_kind enum src/hotspot/share/oops/stackChunkOop.cpp line 445: > 443: > 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) { > 445: const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw. src/hotspot/share/oops/stackChunkOop.cpp line 460: > 458: } else { > 459: oop value = *reinterpret_cast(at); > 460: HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). So either use `*reinterpret_cast(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825949756 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825942254 From ihse at openjdk.org Fri Nov 1 15:46:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 15:46:56 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v16] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: No need to check for LP64 inside a #ifdef _WINDOWS anymore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/0fff0971..fe8ba082 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=14-15 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Fri Nov 1 15:46:57 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 15:46:57 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Error in os_windows.cpp for unknown cpu > > `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes @vnkozlov > There is useless code in src/hotspot/cpu//x86/interpreterRT_x86_32.cpp which is guarded by #ifdef AMD64 which is false for 32-bit. Yes; this has been discussed above. Aleksey opened https://bugs.openjdk.org/browse/JDK-8343167 to solve that separately, since it is not Windows 32-bit specific. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452093887 From ihse at openjdk.org Fri Nov 1 15:55:39 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 15:55:39 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15] In-Reply-To: <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com> Message-ID: On Wed, 30 Oct 2024 19:37:47 GMT, Vladimir Kozlov wrote: > Bug in macroAssembler_x86.cpp - should be _WINDOWS So what does that mean? That the code is currently broken and is incorrectly included on Windows? If so, it should be fixed in a separate PR. Or is it just a stylistic issue, that both `_WINDOWS` and `WINDOWS` are defined when building hotspot on Windows, but the rule is to stick to `_WINDOWS`? If so, I can sneak in a fix for it here, even if it is not really part of the x86 removal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452112264 From ihse at openjdk.org Fri Nov 1 16:04:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 16:04:55 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers - Remove windows-32-bit code in CompilerConfig::ergo_initialize ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/fe8ba082..68d6fe5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=15-16 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Fri Nov 1 16:04:55 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 1 Nov 2024 16:04:55 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov wrote: > `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes I'm actually not sure which places you refer to here. Can you be more specific? (Note that, oddly enough, `_WIN32` is still defined on 64-bit Windows, Microsoft considers "win32" to be the general name of the Windows API.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452127151 From cjplummer at openjdk.org Fri Nov 1 17:21:33 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 1 Nov 2024 17:21:33 GMT Subject: RFR: 8343378: Exceptions in javax/management DeadLockTest.java do not cause test failure In-Reply-To: References: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com> <07kSV5FDDKBnyWvsM8qELMdZ7llvUV_l_HjS4sWgT6k=.5bd99d2e-73b8-409a-a1d8-b09a69f23493@github.com> Message-ID: On Fri, 1 Nov 2024 07:53:20 GMT, Kevin Walls wrote: >> The best way to get to the right answer here is simplify to the subject and verb: "failure fails". You don't put a comma between the subject and the verb, unless is something more much complex like "a failure, for which there can be more than one, fails the test". I think the reason you feel it reads better with the comma is because of the repetition of "fail". Would you still want a comma if the sentence was "any one protocol error fails the test"? I assume no, but the sentence is structurally identical. > > Right, it is the repetition that makes me want the comma. There are other ways of phrasing this which would not need the comma. Even then, I still might introduce one to imply a pause, which I still think helps make it unambiguous on first read, without making it "...causes the test to fail" which is unnecessarily lengthy. It's also a comment buried in a test, not front page news. My 8th grade grammar teacher took no pity on students with "comma-itis" as he called it. They got penalized harshly for gratuitous use of commas. He definitely got through to me though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21804#discussion_r1826091908 From kevinw at openjdk.org Fri Nov 1 17:40:31 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 1 Nov 2024 17:40:31 GMT Subject: RFR: 8343378: Exceptions in javax/management DeadLockTest.java do not cause test failure In-Reply-To: References: <-gJdcK0JYzbY92LW6AhSuhNbf5wRF-RdsYYCoHdhIfI=.54d5b240-e7c2-42e7-82d0-93835a141bd4@github.com> <07kSV5FDDKBnyWvsM8qELMdZ7llvUV_l_HjS4sWgT6k=.5bd99d2e-73b8-409a-a1d8-b09a69f23493@github.com> Message-ID: On Fri, 1 Nov 2024 17:18:50 GMT, Chris Plummer wrote: >> Right, it is the repetition that makes me want the comma. There are other ways of phrasing this which would not need the comma. Even then, I still might introduce one to imply a pause, which I still think helps make it unambiguous on first read, without making it "...causes the test to fail" which is unnecessarily lengthy. It's also a comment buried in a test, not front page news. > > My 8th grade grammar teacher took no pity on students with "comma-itis" as he called it. They got penalized harshly for gratuitous use of commas. He definitely got through to me though. I think he should meet my parents, Jay-Z and Beyonce. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21804#discussion_r1826111791 From kvn at openjdk.org Fri Nov 1 17:55:41 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 1 Nov 2024 17:55:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v15] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com> Message-ID: On Fri, 1 Nov 2024 15:52:50 GMT, Magnus Ihse Bursie wrote: > > Bug in macroAssembler_x86.cpp - should be _WINDOWS > > So what does that mean? That the code is currently broken and is incorrectly included on Windows? If so, it should be fixed in a separate PR. Or is it just a stylistic issue, that both `_WINDOWS` and `WINDOWS` are defined when building hotspot on Windows, but the rule is to stick to `_WINDOWS`? If so, I can sneak in a fix for it here, even if it is not really part of the x86 removal. I think `WINDOWS` is not defined in our build macros. I filed https://bugs.openjdk.org/browse/JDK-8343452 to fix it and backport. > > `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes > > I'm actually not sure which places you refer to here. Can you be more specific? > > (Note that, oddly enough, `_WIN32` is still defined on 64-bit Windows, Microsoft considers "win32" to be the general name of the Windows API.) % grep -i win32 -r src/hotspot/share/ src/hotspot/share//c1/c1_Compiler.cpp: // compilation seems to be too expensive (at least on Intel win32). src/hotspot/share//runtime/globals.hpp: "Using high time resolution (for Win32 only)") \ src/hotspot/share//runtime/globals.hpp: "Bypass Win32 file system criteria checks (Windows Only)") \ src/hotspot/share//runtime/globals.hpp: "Unguard page and retry on no-execute fault (Win32 only) " \ src/hotspot/share//runtime/javaCalls.cpp: // This is used for e.g. Win32 structured exception handlers. src/hotspot/share//runtime/safefetch.hpp:#ifdef _WIN32 src/hotspot/share//runtime/os.hpp: class win32; src/hotspot/share//runtime/vmStructs.cpp: /* unsigned short on Win32 */ \ src/hotspot/share//runtime/vmStructs.cpp: // Win32, we can put this back in. src/hotspot/share//runtime/park.cpp:// Native TLS (Win32/Linux/Solaris) can only be initialized or src/hotspot/share//runtime/sharedRuntimeTrans.cpp:// by roughly 15% on both Win32/x86 and Solaris/SPARC. src/hotspot/share//runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 src/hotspot/share//runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 src/hotspot/share//prims/jvmti.xml: example, in the Java 2 SDK a CTRL-Break on Win32 and a CTRL-\ on Linux src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING) src/hotspot/share//classfile/javaClasses.cpp:#if defined(_WIN32) && !defined(_WIN64) src/hotspot/share//classfile/compactHashtable.cpp:#ifndef O_BINARY // if defined (Win32) use binary files. src/hotspot/share//cds/filemap.cpp:#ifndef O_BINARY // if defined (Win32) use binary files. src/hotspot/share//utilities/vmError.cpp:#ifndef _WIN32 src/hotspot/share//adlc/adlc.hpp:#ifdef _WIN32 src/hotspot/share//adlc/adlc.hpp:#endif // _WIN32 src/hotspot/share//adlc/main.cpp:#if !defined(_WIN32) || defined(_WIN64) src/hotspot/share//compiler/disassembler.cpp:#ifdef _WIN32 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452318589 PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452322471 From kvn at openjdk.org Fri Nov 1 18:04:44 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 1 Nov 2024 18:04:44 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize 1. There is use of `WIN32` instead of `_WIN32`. 2. There are comments referencing `Win32` which we need to rename to `Windows` to avoid confusion. 3. There is `class os::win32` in `os_windows.hpp` which is batter to rename to avoid confusion. Could be done in separate RFE. 4. "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it is really true, I would still suggest to use our variable `_WINDOWS` for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452335968 From kvn at openjdk.org Fri Nov 1 18:13:58 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 1 Nov 2024 18:13:58 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Okay, I am confuse about `_WIN32` vs `WIN32`. You are saying that "_WIN32 is still defined on 64-bit Windows" but you are removing code guarded by `#ifdef _WIN32` And our make files defines `WIN32` for all Windows OSs: https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452349567 From pchilanomate at openjdk.org Fri Nov 1 18:19:20 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:19:20 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v26] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits: - Fix comments for David - Add comment in X509TrustManagerImpl.java - Remove oop clearing in transfer_lockstack + pass _barriers as argument - Merge branch 'master' into JDK-8338383 - add comment to ThreadService::find_deadlocks_at_safepoint - Remove assignments in preempt_kind enum - Remove redundant assert in ObjectMonitor::VThreadEpilog - Comment in FreezeBase::recurse_freeze + renames in continuation.hpp - Explicitly pass tmp register to inc/dec_held_monitor_count + use static const in clobber_nonvolatile_registers - Use frame::sender_sp_offset in continuationFreezeThaw_riscv.inline.hpp - ... and 51 more: https://git.openjdk.org/jdk/compare/751a914b...113fb3d3 ------------- Changes: https://git.openjdk.org/jdk/pull/21565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=25 Stats: 9506 lines in 242 files changed: 6936 ins; 1424 del; 1146 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Fri Nov 1 18:19:21 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:19:21 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25] In-Reply-To: References: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> Message-ID: On Fri, 1 Nov 2024 15:21:50 GMT, Axel Boldt-Christmas wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: >> >> - add comment to ThreadService::find_deadlocks_at_safepoint >> - Remove assignments in preempt_kind enum > > src/hotspot/share/oops/stackChunkOop.cpp line 445: > >> 443: >> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) { >> 445: const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); > > Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. > > There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw. Good, passed as argument now. > src/hotspot/share/oops/stackChunkOop.cpp line 460: > >> 458: } else { >> 459: oop value = *reinterpret_cast(at); >> 460: HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); > > Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). > So either use `*reinterpret_cast(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless. Ok, I just omitted clearing the oop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826149674 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826148888 From pchilanomate at openjdk.org Fri Nov 1 18:24:53 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:24:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v22] In-Reply-To: References: <0C6Y-BWqBlPx6UG8W9NS6TsDuAEmZya4dqtY8E8ymX4=.c45ec952-7387-4ce8-aa5a-f294347f0555@github.com> Message-ID: On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57: >> >>> 55: static { >>> 56: try { >>> 57: MethodHandles.lookup().ensureInitialized(AnchorCertificates.class); >> >> Why is this needed? A comment would help. > > That's probably a good idea. It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority. Added comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826153929 From pchilanomate at openjdk.org Fri Nov 1 18:24:52 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:24:52 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v25] In-Reply-To: References: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com> Message-ID: On Fri, 1 Nov 2024 01:53:01 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: >> >> - add comment to ThreadService::find_deadlocks_at_safepoint >> - Remove assignments in preempt_kind enum > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > >> 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); >> 888: } else { >> 889: // frame can't be freezed. Most likely the call_stub or upcall_stub > > Suggestion: > > // Frame can't be frozen. Most likely the call_stub or upcall_stub Fixed. > src/hotspot/share/services/threadService.cpp line 467: > >> 465: if (waitingToLockMonitor->has_owner()) { >> 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); >> 467: // If currentThread is nullptr we would like to know if the owner > > Suggestion: > > // If currentThread is null we would like to know if the owner Fixed. > src/hotspot/share/services/threadService.cpp line 474: > >> 472: // vthread we never record this as a deadlock. Note: unless there >> 473: // is a bug in the VM, or a thread exits without releasing monitors >> 474: // acquired through JNI, nullptr should imply unmounted vthread owner. > > Suggestion: > > // acquired through JNI, null should imply an unmounted vthread owner. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826154797 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155159 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155815 From pchilanomate at openjdk.org Fri Nov 1 18:29:49 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:29:49 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v7] In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman wrote: >> Thanks for the explanation but that needs to be documented somewhere. > > The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in. Brought the comment from the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826160691 From prr at openjdk.org Fri Nov 1 18:46:57 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 1 Nov 2024 18:46:57 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com> On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize make/modules/jdk.accessibility/Lib.gmk line 57: > 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE) > 56: > 57: ############################################################################## Most of the desktop related changes are related to Assistive Technologies I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something. The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT. So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826177047 From pchilanomate at openjdk.org Fri Nov 1 18:47:23 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 18:47:23 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v27] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Revert fixes after 8343132 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/113fb3d3..33eb6388 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=25-26 Stats: 22 lines in 3 files changed: 0 ins; 17 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From aivanov at openjdk.org Fri Nov 1 19:17:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:17:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: <5_m66jOr6E-qHq5r9AHGX-Yb5IKCT_VbHGmq_Yh8v34=.172e81bb-9281-4364-a8cb-3696c5ef4b36@github.com> On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Modify three RMI tests to work without the security manager: > - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java > - test/jdk/java/rmi/registry/readTest/CodebaseTest.java > - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java > Also remove them from the problem list. > - Remove two obsolete RMI tests: > - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java > - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java > Adjust two tests to run without the Security Manager: > - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java > Remove all of these tests from the problem list. > - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. > - Added API Notes to ProtectionDomain clarifying that the current policy always > grants no permissions. A few other small changes to Policy and PD. > - Merge branch 'master' into jep486 > - JAXP tests: organize imports of a few tests > - Improve description of Executors.privilegedThreadFactory > - rename TestAppletLoggerContext.java as suggested in util test review > - clientlibs: Javadoc cleanup > - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b I looked through the updates to `java.desktop` module and to tests under `java/awt`, `javax/sound`, `javax/swing`. Looks good. ------------- Marked as reviewed by aivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2410517684 From aivanov at openjdk.org Fri Nov 1 19:17:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:17:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 20:57:50 GMT, Sean Mullan wrote: >> @honkar-jdk I'm inclined to leave it as because it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file. >> >> If it's worth taking care of, we may submit another bug to address it later. > > This does not need to be handled in this PR. In the majority of changes, we have really tried hard to avoid making unrelated changes, but sometimes a few snuck in, like moving package imports or perhaps fixing a typo here and there that was not specific to JEP 486. My opinion is that unless it is something that _really_ should be done as part of a more general technical debt or code cleanup exercise, then it is ok to let a few of these in and they don't have to be reverted. > > Can we add a blank line here? It's present in the methods above. > > > > Although there are other places below where it's missing; _so not worth worrying_. > > ? it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file. > > If it's worth taking care of, we may submit another bug to address it later. I've submitted [JDK-8343448](https://bugs.openjdk.org/browse/JDK-8343448): _Improve formatting of docs in java.awt.Desktop_. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826079117 From aivanov at openjdk.org Fri Nov 1 19:17:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:17:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com> References: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com> Message-ID: On Mon, 28 Oct 2024 14:08:46 GMT, Sean Mullan wrote: >> src/java.desktop/share/classes/java/awt/Font.java line 1612: >> >>> 1610: * obtained. The {@code String} value of this property is then >>> 1611: * interpreted as a {@code Font} object according to the >>> 1612: * specification of {@code Font.decode(String)} >> >> Suggestion: >> >> * specification of {@code Font.decode(String)}. >> >> Period is missing. > > Not part of this change, can be fixed later as a follow-on cleanup. I've submitted [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446): _Add missing periods in docs for java.awt.Font_. >> src/java.desktop/share/classes/java/awt/Font.java line 1780: >> >>> 1778: *

>>> 1779: * The property value should be one of the forms accepted by >>> 1780: * {@code Font.decode(String)} >> >> Suggestion: >> >> * {@code Font.decode(String)}. >> >> Period is missing. > > Not part of this change, can be fixed later as a follow-on cleanup. Deferred to [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826080609 PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826081342 From aivanov at openjdk.org Fri Nov 1 19:17:12 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:17:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 18:07:26 GMT, Harshitha Onkar wrote: >> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. >> But I don't see a problem with keeping the rest of the test. > > Test updated in sandbox - https://github.com/openjdk/jdk-sandbox/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea > I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test. @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`: https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826141057 From pchilanomate at openjdk.org Fri Nov 1 19:37:14 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 1 Nov 2024 19:37:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Use lazySubmitRunContinuation when blocking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/33eb6388..52c26642 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=26-27 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From aivanov at openjdk.org Fri Nov 1 19:43:18 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:43:18 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Modify three RMI tests to work without the security manager: > - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java > - test/jdk/java/rmi/registry/readTest/CodebaseTest.java > - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java > Also remove them from the problem list. > - Remove two obsolete RMI tests: > - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java > - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java > Adjust two tests to run without the Security Manager: > - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java > Remove all of these tests from the problem list. > - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. > - Added API Notes to ProtectionDomain clarifying that the current policy always > grants no permissions. A few other small changes to Policy and PD. > - Merge branch 'master' into jep486 > - JAXP tests: organize imports of a few tests > - Improve description of Executors.privilegedThreadFactory > - rename TestAppletLoggerContext.java as suggested in util test review > - clientlibs: Javadoc cleanup > - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1: > 1: /* I wonder if we should add an Oracle copyright to the update test file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826228675 From aivanov at openjdk.org Fri Nov 1 19:43:18 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 19:43:18 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 14:35:57 GMT, Sean Mullan wrote: >> That and possibly rename the test because now it does not have anything to do with the SecurityException. Now we only check that providing an empty file causes the InvalidMidiDataException so EmptySoundBankTest or something to that extent would be a better name. > > Fixed in https://github.com/openjdk/jdk/pull/21498/commits/934e1c28f783b32c43e6977f0e1ba6e1c68f810f Thank you for clarification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826225216 From dlong at openjdk.org Fri Nov 1 20:11:50 2024 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Nov 2024 20:11:50 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote: >>> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? >>> >> It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. > > It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. Here's my suggested C2 change: diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad index d9c77a2f529..1e99db191ae 100644 --- a/src/hotspot/cpu/aarch64/aarch64.ad +++ b/src/hotspot/cpu/aarch64/aarch64.ad @@ -3692,14 +3692,13 @@ encode %{ __ post_call_nop(); } else { Label retaddr; + // Make the anchor frame walkable __ adr(rscratch2, retaddr); + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); __ lea(rscratch1, RuntimeAddress(entry)); - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); __ blr(rscratch1); __ bind(retaddr); __ post_call_nop(); - __ add(sp, sp, 2 * wordSize); } if (Compile::current()->max_vector_size() > 0) { __ reinitialize_ptrue(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826252551 From dlong at openjdk.org Fri Nov 1 20:30:51 2024 From: dlong at openjdk.org (Dean Long) Date: Fri, 1 Nov 2024 20:30:51 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking Marked as reviewed by dlong (Reviewer). I finished looking at this, and it looks good. Nice work! ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410825883 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2452534349 From aivanov at openjdk.org Fri Nov 1 20:31:37 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 1 Nov 2024 20:31:37 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 12:56:25 GMT, Sean Mullan wrote: >> test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30: >> >>> 28: * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom >>> 29: * @compile -XDignore.symbol.file Marshal.java >>> 30: * @run main/othervm/java.security.policy==test.policy Marshal >> >> With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main " when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again. >> >> Also, missing a copyright update, will fix. > > Fixed in https://github.com/openjdk/jdk/pull/21498/commits/548eb9e2eb3f586bbb620d5357fe3e5665aeb505 > With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main " when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again. I guess it's the intended behaviour, jtreg implies `@run` if there are no other commands; you have to provide `@run` explicitly if there are `@compile` or `@build` tags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826256418 From fbredberg at openjdk.org Fri Nov 1 20:59:49 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Fri, 1 Nov 2024 20:59:49 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking I'm done reviewing this piece of good-looking code, and I really enjoyed it. Thanks! ------------- Marked as reviewed by fbredberg (Committer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410872086 From mgronlun at openjdk.org Fri Nov 1 21:59:38 2024 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Fri, 1 Nov 2024 21:59:38 GMT Subject: RFR: 8304824: NMT should not use ThreadCritical [v9] In-Reply-To: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com> References: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com> Message-ID: On Mon, 28 Oct 2024 16:12:39 GMT, Robert Toyonaga wrote: >> ### Summary >> This PR just replaces `ThreadCritical` with a lock specific to NMT. `ThreadCritical` is a big lock and is unnecessary for the purposes of NMT. I've implemented the new lock with a semaphore so that it can be used early before VM init. There is also the possibility of adding assertions in places we expect NMT to have synchronization. I haven't added assertions yet in many places because some code paths such as the (NMT tests) don't lock yet. I think it makes sense to close any gaps in locking in another PR in which I can also add more assertions. >> >> Testing: >> - hotspot_nmt >> - gtest:VirtualSpace >> - tier1 > > Robert Toyonaga has updated the pull request incrementally with two additional commits since the last revision: > > - add a comment explaining lock rank > - remove unnecessary dropping of tracking level src/hotspot/share/runtime/mutexLocker.hpp line 31: > 29: #include "runtime/flags/flagSetting.hpp" > 30: #include "runtime/mutex.hpp" > 31: #include "runtime/thread.hpp" This include is not needed because there are no uses that require the definition of Thread. After pull, I am getting circularity errors from runtime/thread.hpp -> jfr/support/jfrThreadLocal.hpp (which now needs runtime/mutexLocker.hpp (-> runtime/thread.hpp) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1826330949 From kbarrett at openjdk.org Fri Nov 1 22:10:40 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 1 Nov 2024 22:10:40 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: <0AP1wOF-MdqLdSNofINZ2JTL4nnIdVFRsZpZ1LT7oHY=.e1bb41e9-b0f4-4157-9d78-d5b819c5c1d9@github.com> On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Looks good, subject to addressing @vnkozlov comments. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2410940653 From fyang at openjdk.org Sat Nov 2 02:44:55 2024 From: fyang at openjdk.org (Fei Yang) Date: Sat, 2 Nov 2024 02:44:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273: >> >>> 271: ? frame_sp + fsize - frame::sender_sp_offset >>> 272: // we need to re-read fp because it may be an oop and we might have fixed the frame. >>> 273: : *(intptr_t**)(hf.sp() - 2); >> >> Suggestion: >> >> : *(intptr_t**)(hf.sp() - frame::sender_sp_offset); > > Changed. Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826453713 From sspitsyn at openjdk.org Sat Nov 2 04:53:56 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Sat, 2 Nov 2024 04:53:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking src/hotspot/share/runtime/objectMonitor.cpp line 537: > 535: } > 536: } > 537: Just a question. It is not clear from scratch why the `Continuation::try_preempt()` is called before the `VThreadMonitorEnter()`. It would be nice to add a comment explaining it. It can be also good to explain how it works together in this order. Even a surface explanation of a general idea would be very helpful. A part of this already explained in the comment at lines 515-517. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826492850 From kizune at openjdk.org Sat Nov 2 07:53:44 2024 From: kizune at openjdk.org (Alexander Zuev) Date: Sat, 2 Nov 2024 07:53:44 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com> Message-ID: On Fri, 1 Nov 2024 18:44:02 GMT, Phil Race wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers >> - Remove windows-32-bit code in CompilerConfig::ergo_initialize > > make/modules/jdk.accessibility/Lib.gmk line 57: > >> 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE) >> 56: >> 57: ############################################################################## > > Most of the desktop related changes are related to Assistive Technologies > I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something. > The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT. > > So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java We built 32-bit dll in order to provide access to the accessibility interfaces for the legacy 32-bit software that can not load the 32-bit code. We abandoned this practice since at least Java 11 and we had no complaints about it ever since. All the relevant accessibility software we are aware of have 64-bit executable and only support 32-bit operating systems with the legacy versions that are not recommended to use with modern OSes. I do not see any problem in abandoning 32-bit code in windowsaccessbridge.dll. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826520980 From acobbs at openjdk.org Sat Nov 2 16:09:56 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 2 Nov 2024 16:09:56 GMT Subject: RFR: 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) Message-ID: @SuppressWarnings annotations that don't actually suppress any warnings create a potential pathway for future bugs to creep in unnoticed. They should be removed if possible. This issue is for those JDK files with the "serviceability" label. ------------- Commit messages: - Remove unnecessary @SuppressWarnings annotations. Changes: https://git.openjdk.org/jdk/pull/21857/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21857&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343483 Stats: 21 lines in 16 files changed: 0 ins; 16 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21857/head:pull/21857 PR: https://git.openjdk.org/jdk/pull/21857 From duke at openjdk.org Sat Nov 2 22:42:07 2024 From: duke at openjdk.org (ExE Boss) Date: Sat, 2 Nov 2024 22:42:07 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Modify three RMI tests to work without the security manager: > - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java > - test/jdk/java/rmi/registry/readTest/CodebaseTest.java > - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java > Also remove them from the problem list. > - Remove two obsolete RMI tests: > - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java > - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java > Adjust two tests to run without the Security Manager: > - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java > Remove all of these tests from the problem list. > - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. > - Added API Notes to ProtectionDomain clarifying that the current policy always > grants no permissions. A few other small changes to Policy and PD. > - Merge branch 'master' into jep486 > - JAXP tests: organize imports of a few tests > - Improve description of Executors.privilegedThreadFactory > - rename TestAppletLoggerContext.java as suggested in util test review > - clientlibs: Javadoc cleanup > - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b src/java.base/share/classes/java/lang/System.java line 1364: > 1362: *
> 1363: * It is the responsibility of the provider of > 1364: * the concrete {@code LoggerFinder} implementation to ensure that This is?still a?part of?the?paragraph related to?the?security?manager. src/java.base/share/classes/java/lang/System.java line 2338: > 2336: * Invoked by VM. Phase 3 is the final system initialization: > 2337: * 1. eagerly initialize bootstrap method factories that might interact > 2338: * negatively with custom security managers and custom class loaders They?might?still interact?negatively with?custom class?loaders?though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826864120 PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826863295 From acobbs at openjdk.org Sun Nov 3 03:11:54 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Sun, 3 Nov 2024 03:11:54 GMT Subject: RFR: 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) [v2] In-Reply-To: References: Message-ID: > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Update copyright years. - Merge branch 'master' into SuppressWarningsCleanup-serviceability - Merge branch 'master' into SuppressWarningsCleanup-serviceability - Remove unnecessary @SuppressWarnings annotations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21857/files - new: https://git.openjdk.org/jdk/pull/21857/files/4de38fe6..a8e438be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21857&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21857&range=00-01 Stats: 3237 lines in 135 files changed: 2078 ins; 749 del; 410 mod Patch: https://git.openjdk.org/jdk/pull/21857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21857/head:pull/21857 PR: https://git.openjdk.org/jdk/pull/21857 From alanb at openjdk.org Sun Nov 3 07:01:07 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 3 Nov 2024 07:01:07 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Sat, 2 Nov 2024 22:18:09 GMT, ExE Boss wrote: >> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Modify three RMI tests to work without the security manager: >> - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java >> - test/jdk/java/rmi/registry/readTest/CodebaseTest.java >> - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java >> Also remove them from the problem list. >> - Remove two obsolete RMI tests: >> - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java >> - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java >> Adjust two tests to run without the Security Manager: >> - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java >> - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java >> Remove all of these tests from the problem list. >> - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. >> - Added API Notes to ProtectionDomain clarifying that the current policy always >> grants no permissions. A few other small changes to Policy and PD. >> - Merge branch 'master' into jep486 >> - JAXP tests: organize imports of a few tests >> - Improve description of Executors.privilegedThreadFactory >> - rename TestAppletLoggerContext.java as suggested in util test review >> - clientlibs: Javadoc cleanup >> - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b > > src/java.base/share/classes/java/lang/System.java line 2338: > >> 2336: * Invoked by VM. Phase 3 is the final system initialization: >> 2337: * 1. eagerly initialize bootstrap method factories that might interact >> 2338: * negatively with custom security managers and custom class loaders > > They?might?still interact?negatively with?custom class?loaders?though. The context here is custom a security manager doing string concatenation, this has required StringConcatFactory be eagerly initialized or security managers set on the command line to have been compiled with -XDstringConcat=inline. I think your question is about overriding the system class loader and whether its initialisation can use string concatenation reliably. That's a good thing to add a test for. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826916876 From dfuchs at openjdk.org Sun Nov 3 11:28:10 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Sun, 3 Nov 2024 11:28:10 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com> On Sat, 2 Nov 2024 22:25:06 GMT, ExE Boss wrote: >> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Modify three RMI tests to work without the security manager: >> - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java >> - test/jdk/java/rmi/registry/readTest/CodebaseTest.java >> - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java >> Also remove them from the problem list. >> - Remove two obsolete RMI tests: >> - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java >> - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java >> Adjust two tests to run without the Security Manager: >> - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java >> - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java >> Remove all of these tests from the problem list. >> - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. >> - Added API Notes to ProtectionDomain clarifying that the current policy always >> grants no permissions. A few other small changes to Policy and PD. >> - Merge branch 'master' into jep486 >> - JAXP tests: organize imports of a few tests >> - Improve description of Executors.privilegedThreadFactory >> - rename TestAppletLoggerContext.java as suggested in util test review >> - clientlibs: Javadoc cleanup >> - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b > > src/java.base/share/classes/java/lang/System.java line 1364: > >> 1362: *
>> 1363: * It is the responsibility of the provider of >> 1364: * the concrete {@code LoggerFinder} implementation to ensure that > > This is?still a?part of?the?paragraph related to?the?security?manager. Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826959976 From alanb at openjdk.org Sun Nov 3 12:36:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 3 Nov 2024 12:36:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com> References: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com> Message-ID: On Sun, 3 Nov 2024 11:25:13 GMT, Daniel Fuchs wrote: >> src/java.base/share/classes/java/lang/System.java line 1364: >> >>> 1362: *
>>> 1363: * It is the responsibility of the provider of >>> 1364: * the concrete {@code LoggerFinder} implementation to ensure that >> >> This is?still a?part of?the?paragraph related to?the?security?manager. > > Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that. Removed in jep486 branch in sandbox so will get picked up when PR is refreshed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826972198 From jiangli at openjdk.org Sun Nov 3 20:24:08 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Sun, 3 Nov 2024 20:24:08 GMT Subject: RFR: 8343497: Missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries Message-ID: Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries. Thanks. ------------- Commit messages: - Add DEF_STATIC_JNI_OnLoad to libjimage and libsaproc native libraries.Q Changes: https://git.openjdk.org/jdk/pull/21861/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21861&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343497 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21861/head:pull/21861 PR: https://git.openjdk.org/jdk/pull/21861 From jiangli at openjdk.org Mon Nov 4 00:28:46 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 4 Nov 2024 00:28:46 GMT Subject: RFR: 8343497: Missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries [v2] In-Reply-To: References: Message-ID: > Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries. Thanks. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Fix macos build issue. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21861/files - new: https://git.openjdk.org/jdk/pull/21861/files/0744bd82..5a948674 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21861&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21861&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21861.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21861/head:pull/21861 PR: https://git.openjdk.org/jdk/pull/21861 From dholmes at openjdk.org Mon Nov 4 02:18:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 02:18:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking src/hotspot/share/classfile/javaClasses.cpp line 2107: > 2105: > 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { > 2107: return vthread->long_field(_timeout_offset); Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827128518 From dholmes at openjdk.org Mon Nov 4 02:37:40 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 02:37:40 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Changes requested by dholmes (Reviewer). src/hotspot/share/adlc/adlc.hpp line 43: > 41: > 42: /* Make sure that we have the intptr_t and uintptr_t definitions */ > 43: #ifdef _WIN32 As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct. ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412031267 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827135809 From iklam at openjdk.org Mon Nov 4 03:10:38 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 4 Nov 2024 03:10:38 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6] In-Reply-To: References: Message-ID: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com> On Fri, 1 Nov 2024 03:54:24 GMT, Dan Heidinga wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed whitespace; fixed minimal build > > src/hotspot/share/cds/aotClassInitializer.cpp line 348: > >> 346: } >> 347: JavaValue result(T_VOID); >> 348: JavaCalls::call_static(&result, ik, > > Based on the discussions in JDK-8342283, do we need a memory fence after the call to runtimeSetup? > > I think we do to be consistent with the non-AOTCache run as there is a fence after `` (when this code would normally run) due to the initialization lock. I think this is already done: `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1827146321 From iklam at openjdk.org Mon Nov 4 03:15:25 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 4 Nov 2024 03:15:25 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v7] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits: - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - reverted changes in modules.cpp to make it easy to merge with mainline - Fixed whitespace; fixed minimal build - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity" - fixed comments - @ashu-mehra comment - renamed function to SystemDictionaryShared::should_be_excluded(); added comments and asserts; make sure the class is indeed checked - Backed out 58233cc20fa22abfd711bb59aafb78e20fabc195 - @ashu-mehra comment - rename/comment AOTClassLinker::add_new_candidate() and added asserts for thread safety - ... and 162 more: https://git.openjdk.org/jdk/compare/29882bfe...935dcc68 ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=06 Stats: 7256 lines in 105 files changed: 6408 ins; 519 del; 329 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From alanb at openjdk.org Mon Nov 4 05:54:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Nov 2024 05:54:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com> On Mon, 4 Nov 2024 02:12:40 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Use lazySubmitRunContinuation when blocking > > src/hotspot/share/classfile/javaClasses.cpp line 2107: > >> 2105: >> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { >> 2107: return vthread->long_field(_timeout_offset); > > Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827219720 From jwaters at openjdk.org Mon Nov 4 06:03:32 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 4 Nov 2024 06:03:32 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v4] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove global memHandle, would've liked to keep it as a comment :( @alexeysemenyukoracle Sorry for the page, needed a reviewer for jpackage. Is jpackage good to go? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2453881416 From dholmes at openjdk.org Mon Nov 4 07:05:44 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 07:05:44 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf Message-ID: This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. Testing: - tier 1-3 (sanity) Thanks ------------- Commit messages: - 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf Changes: https://git.openjdk.org/jdk/pull/21867/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8339134 Stats: 50 lines in 9 files changed: 44 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21867/head:pull/21867 PR: https://git.openjdk.org/jdk/pull/21867 From aboldtch at openjdk.org Mon Nov 4 07:23:51 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Mon, 4 Nov 2024 07:23:51 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use lazySubmitRunContinuation when blocking src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: > 60: NATIVE(2, "Native frame or on stack"), > 61: MONITOR(3, "Monitor held"), > 62: CRITICAL_SECTION(4, "In critical section"); Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827276764 From jsjolen at openjdk.org Mon Nov 4 07:56:38 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 4 Nov 2024 07:56:38 GMT Subject: RFR: 8304824: NMT should not use ThreadCritical [v9] In-Reply-To: References: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com> Message-ID: On Fri, 1 Nov 2024 21:56:36 GMT, Markus Gr?nlund wrote: >This include is not needed because there are no uses that require the definition of Thread. Right, seems like the forward declaration used to be provided by `memory/allocation.hpp`. Let's get rid of the include and use a forward declaration of our own instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1827311285 From alanb at openjdk.org Mon Nov 4 08:02:57 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Nov 2024 08:02:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 07:21:19 GMT, Axel Boldt-Christmas wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Use lazySubmitRunContinuation when blocking > > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: > >> 60: NATIVE(2, "Native frame or on stack"), >> 61: MONITOR(3, "Monitor held"), >> 62: CRITICAL_SECTION(4, "In critical section"); > > Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? > > I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue. Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827316145 From dholmes at openjdk.org Mon Nov 4 09:02:10 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 09:02:10 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: > This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. > > There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. > > Testing: > - tier 1-3 (sanity) > > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Restore previous behaviour for zero length strings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21867/files - new: https://git.openjdk.org/jdk/pull/21867/files/4ffe35d5..f0e285da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21867/head:pull/21867 PR: https://git.openjdk.org/jdk/pull/21867 From kbarrett at openjdk.org Mon Nov 4 09:03:42 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 4 Nov 2024 09:03:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 02:34:13 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers >> - Remove windows-32-bit code in CompilerConfig::ergo_initialize > > src/hotspot/share/adlc/adlc.hpp line 43: > >> 41: >> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */ >> 43: #ifdef _WIN32 > > As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct. The deletion is apparently working, else we'd be getting build failures. So while there are some potential issues and opportunities for further cleanup in this file, I think they ought to be addressed separately from this PR. See new https://bugs.openjdk.org/browse/JDK-8343530. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827395928 From dholmes at openjdk.org Mon Nov 4 09:13:43 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 4 Nov 2024 09:13:43 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 09:00:59 GMT, Kim Barrett wrote: >> src/hotspot/share/adlc/adlc.hpp line 43: >> >>> 41: >>> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */ >>> 43: #ifdef _WIN32 >> >> As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct. > > The deletion is apparently working, else we'd be getting build failures. So > while there are some potential issues and opportunities for further cleanup in > this file, I think they ought to be addressed separately from this PR. See > new https://bugs.openjdk.org/browse/JDK-8343530. There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827408129 From stuefe at openjdk.org Mon Nov 4 09:24:58 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Nov 2024 09:24:58 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize Can we get rid of `JNICALL` too, please? Or would that change be too big? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454188077 From stefank at openjdk.org Mon Nov 4 09:26:55 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 4 Nov 2024 09:26:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v16] In-Reply-To: References: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com> Message-ID: On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo wrote: >> This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object. > > If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. This code in `StackChunkAllocator::initialize` mimics the clearing code in: void MemAllocator::mem_clear(HeapWord* mem) const { assert(mem != nullptr, "cannot initialize null object"); const size_t hs = oopDesc::header_size(); assert(_word_size >= hs, "unexpected object size"); oopDesc::set_klass_gap(mem, 0); Copy::fill_to_aligned_words(mem + hs, _word_size - hs); } but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be: if (oopDesc::has_klass_gap()) { oopDesc::set_klass_gap(mem, 0); } So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827424227 From alanb at openjdk.org Mon Nov 4 09:31:41 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 4 Nov 2024 09:31:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 09:21:52 GMT, Thomas Stuefe wrote: > Can we get rid of `JNICALL` too, please? > > Or would that change be too big? There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454201348 From stuefe at openjdk.org Mon Nov 4 09:44:42 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Nov 2024 09:44:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers > - Remove windows-32-bit code in CompilerConfig::ergo_initialize This is a very nice reduction in complexity. As I wrote before, removing windows 32-bit removes the need for calling convention definition, so I think we could get rid of JNICALL in addition to anything stdcall/fastcall related. I had a close look at hotspot os and os_cpu changes, cursory glances at other places, all looked fine. ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412592195 From stuefe at openjdk.org Mon Nov 4 09:47:41 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Nov 2024 09:47:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> On Mon, 4 Nov 2024 09:28:50 GMT, Alan Bateman wrote: > > Can we get rid of `JNICALL` too, please? > > Or would that change be too big? > > There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing. Yeah. I count >8000 places in total... Maybe just define JNICALL to be empty in jni_md.h for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454234501 From kbarrett at openjdk.org Mon Nov 4 10:01:45 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 4 Nov 2024 10:01:45 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 09:11:16 GMT, David Holmes wrote: >> The deletion is apparently working, else we'd be getting build failures. So >> while there are some potential issues and opportunities for further cleanup in >> this file, I think they ought to be addressed separately from this PR. See >> new https://bugs.openjdk.org/browse/JDK-8343530. > > There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR. "using namespace std;" in a header is generally a bad idea. It brings all kinds of stuff into scope, potentially leading to name conflicts down the road. And seems like a strange thing to do only for windows. Removal of the strdup macro is covered by the NONSTDC macros added at build time. It's not a 32bit cleanup either, and you suggested it. Removal of [u]intptr_t definitions will cause a build failure if it results in them being undefined. And getting an incorrect definition from elsewhere seems implausible. I claim this all just isn't needed anymore and can be removed in this PR, just as you suggested for the strdup macro. The 64bit definitions could be added back in this PR (to be removed later by JDK-8343530), but that just seems like useless churn. So I'm happy with the current removal of the entire chunk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827469354 From stefank at openjdk.org Mon Nov 4 13:44:46 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Mon, 4 Nov 2024 13:44:46 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v5] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 21 Oct 2024 21:16:50 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 492 commits: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - Merge > - 8342560: GenShen: Fix confusing method name > > Reviewed-by: ysr > - 8342564: GenShen: Only reference young/old generation names in generational mode > > Reviewed-by: xpeng, ysr > - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction > > Reviewed-by: kdnilsen, ysr > - 8342239: GenShen: Revert changes in adaptive heuristic to avoid overflow on 32 bit > > Reviewed-by: ysr > - 8342278: GenShen: Move non-generational mode test out of generational test configuration > > Reviewed-by: ysr > - 8342255: GenShen: Remove unnecessary enum initial values > > Reviewed-by: ysr > - ... and 482 more: https://git.openjdk.org/jdk/compare/71583222...2a2aa408 The changes to the shared code is minimal and looks good. ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2413104483 From ihse at openjdk.org Mon Nov 4 13:56:27 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 13:56:27 GMT Subject: RFR: 8343497: Missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries [v2] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 00:28:46 GMT, Jiangli Zhou wrote: >> Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries. Thanks. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Fix macos build issue. Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21861#pullrequestreview-2413132294 From fbredberg at openjdk.org Mon Nov 4 14:00:55 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 4 Nov 2024 14:00:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote: >> Changed. > > Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? > > (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827720269 From stuefe at openjdk.org Mon Nov 4 14:07:35 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Mon, 4 Nov 2024 14:07:35 GMT Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2] In-Reply-To: References: Message-ID: <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com> On Tue, 29 Oct 2024 14:09:21 GMT, Simon Tooke wrote: >> Looking good, small nits remain. Could you share an example output (maybe one run with G1, one with ZGC?) > >> Looking good, small nits remain. Could you share an example output (maybe one run with G1, one with ZGC?) > > @tstuefe, Sample output for G1 and ZGC has been attached to the description (and I fixed the ZGC test) Hi @stooke, nice. There are some aspects about the output that is surprising, though. I expect reserved-only memory to be mapped with MAP_NORESERVE and no access rights. I expect committed memory to be mapped without MAP_NORESERVE and write- or executable access. - (G1) I only see one segment for JAVAHEAP. I would expect at least two, one reserved-only, one reserved and committed. Or did you precommit the heap (start JVM with -Xmx==-Xms)? Can you please test that with ParallelGC and without specifying Xms, we should see four java heap mappings side by side, for young and old gen, each with a committed part (rw) and a reserved part (not accessible). Like we do now for the CODE section. Please also countercheck that the address ranges are correct against the heap range (easiest, run jcmd .. VM.info and look for the Heap section, it tells you the address ranges). - The 64K META and CLASS blocks confuse me. For one, they are too small. A Metaspace node is 64M sized. It can contain multiple committed and reserved sections, so typically spreads over multiple lines, but usually not many. Here (G1 file), I see many that are 64K in size, spanning in total just about 5MB. You can counter-check the META blocks with `jcmd .. VM.metaspace vslist` - it prints the virtual space node list at the start. - Another thing that is strange is that the MEAT lines are not coalesced, though the properties displayed seem to be the same. But that can be the result of hidden properties being different. Also, could you rename the OS-specific names to `[lowercase-something]`? The `[UPPERCASE]` names are easily confused with the uppercase NMT tags. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2454804578 From heidinga at openjdk.org Mon Nov 4 14:23:33 2024 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 4 Nov 2024 14:23:33 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6] In-Reply-To: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com> References: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com> Message-ID: On Mon, 4 Nov 2024 03:08:02 GMT, Ioi Lam wrote: >> src/hotspot/share/cds/aotClassInitializer.cpp line 348: >> >>> 346: } >>> 347: JavaValue result(T_VOID); >>> 348: JavaCalls::call_static(&result, ik, >> >> Based on the discussions in JDK-8342283, do we need a memory fence after the call to runtimeSetup? >> >> I think we do to be consistent with the non-AOTCache run as there is a fence after `` (when this code would normally run) due to the initialization lock. > > I think this is already done: > > `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. > > https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300 I think you're right about the memory fencing being covered there but reading that code shows another potential issue - what if the `runtimeSetup()` call throws an exception? If I read `InstanceKlass::call_class_initializer()` correctly, an exception from `runtimeSetup()` will lead to marking the class as failing initialization (`initialization_error`) which will be an unexpected outcome as there may be instances of the class in the AOTCache that aren't produced by paths through the `` method. Classes are able to create an instance in `` and escape it to other code and then fail initialization. The instances are left in an odd state where after the `` the instance methods can be called but static fields and static methods can't be accessed. `runtimeSetup()` expands on this corner case which I think is OK for current "crawl" stage of our "crawl-walk-run" approach as its analogous to the existing `` behaviour. It may need refining in the future to abort the VM or do something else (?) in the case of failed `runtimeSetup` calls ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1827813351 From ihse at openjdk.org Mon Nov 4 16:42:26 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:42:26 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v20] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove __stdcall notation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/d89bc561..fbd91ad0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=18-19 Stats: 119 lines in 13 files changed: 0 ins; 1 del; 118 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From duke at openjdk.org Mon Nov 4 14:54:37 2024 From: duke at openjdk.org (Robert Toyonaga) Date: Mon, 4 Nov 2024 14:54:37 GMT Subject: RFR: 8304824: NMT should not use ThreadCritical [v9] In-Reply-To: References: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com> Message-ID: On Mon, 4 Nov 2024 07:53:48 GMT, Johan Sj?len wrote: >> src/hotspot/share/runtime/mutexLocker.hpp line 31: >> >>> 29: #include "runtime/flags/flagSetting.hpp" >>> 30: #include "runtime/mutex.hpp" >>> 31: #include "runtime/thread.hpp" >> >> This include is not needed because there are no uses that require the definition of Thread. >> >> After pull, I am getting circularity errors from runtime/thread.hpp -> jfr/support/jfrThreadLocal.hpp (which now needs runtime/mutexLocker.hpp (-> runtime/thread.hpp) >> >> The include of "runtime/thread.hpp" can instead be placed in "nmt/nmtCommon.hpp" which has a use in the NmtVirtualMemoryLocker constructor. > >>This include is not needed because there are no uses that require the definition of Thread. > > Right, seems like the forward declaration used to be provided by `memory/allocation.hpp`. Let's get rid of the include and use a forward declaration of our own instead. Should I open another PR to remove it? I can also remove the locking related to NMT in arena.cpp in the same PR as well (as per [this comment](https://github.com/openjdk/jdk/pull/20852#issuecomment-2450515494)). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1827863263 From coleenp at openjdk.org Mon Nov 4 15:32:32 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 4 Nov 2024 15:32:32 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 09:02:10 GMT, David Holmes wrote: >> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. >> >> There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. >> >> Testing: >> - tier 1-3 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restore previous behaviour for zero length strings src/hotspot/share/utilities/exceptions.cpp line 264: > 262: // will be within reasonable limits - specifically we will never hit the INT_MAX limit > 263: // of os::vsnprintf when it tries to report how big a buffer is needed. Even so we > 264: // further limit the formatted output to 1024 characters. If we're chopping off the message at 1024 characters, why do we have to audit the callers? Is it because vsnprintf will overflow before truncating the message? Seems like it could be easy to add a caller that breaks this. There's no way to check here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21867#discussion_r1827926037 From ihse at openjdk.org Mon Nov 4 16:11:44 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:11:44 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com> Message-ID: On Sat, 2 Nov 2024 07:51:20 GMT, Alexander Zuev wrote: >> make/modules/jdk.accessibility/Lib.gmk line 57: >> >>> 55: TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE) >>> 56: >>> 57: ############################################################################## >> >> Most of the desktop related changes are related to Assistive Technologies >> I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something. >> The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT. >> >> So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java > > We built 32-bit dll in order to provide access to the accessibility interfaces for the legacy 32-bit software that can not load the 32-bit code. We abandoned this practice since at least Java 11 and we had no complaints about it ever since. All the relevant accessibility software we are aware of have 64-bit executable and only support 32-bit operating systems with the legacy versions that are not recommended to use with modern OSes. I do not see any problem in abandoning 32-bit code in windowsaccessbridge.dll. @azuev-java Thanks! I have one more question for you: To avoid risking breaking any compatibility, the file generated from the source code in `windowsaccessbridge` is still compiled into a file called `windowsaccessbridge-64.dll`. This is a bit unusual, and requires a quirk in the build system -- normally we assume there is a 1-to-1 relationship between the directory containing the native library source code, and the generated `.dll` file. Is this file exposed to external parties, that rely on a specific name? Or is it just used internally by the JDK, so we could rename it to `windowsaccessbridge.dll`, and just update our reference to it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827989703 From ihse at openjdk.org Mon Nov 4 16:53:48 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:53:48 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> Message-ID: On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote: >>> Can we get rid of `JNICALL` too, please? >>> >>> Or would that change be too big? >> >> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing. > >> > Can we get rid of `JNICALL` too, please? >> > Or would that change be too big? >> >> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing. > > Yeah. I count >8000 places in total... > > Maybe just define JNICALL to be empty in jni_md.h for now. @tstuefe Your comment reminded me of another important cleanup, to remove `__stdcall` (and `_stdcall`, an accepted but not recommended variant) from the code base. This only has meaning on 32-bit Windows. Furthermore, when searching for this, I found additional code that is looking for symbol names of "__stdcall format", i.e. `@`. This is not needed anymore. I'll delete it where I find it, but there might be other places that I'm missing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455215002 From ihse at openjdk.org Mon Nov 4 16:23:06 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:23:06 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v18] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Restore code in adlc.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/68d6fe5a..c6dce38d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=16-17 Stats: 27 lines in 1 file changed: 27 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 16:23:06 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:23:06 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com> Message-ID: On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe wrote: > Can we get rid of `JNICALL` too, please? That we can never do, since it is part of jni.h which are imported in likely millions of JNI projects. But we can replace it with an empty define. And we can document it as not needed anymore, and start removing it from our own call sites. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455142166 From ihse at openjdk.org Mon Nov 4 16:23:06 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:23:06 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v18] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Mon, 4 Nov 2024 09:58:49 GMT, Kim Barrett wrote: >> There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR. > > "using namespace std;" in a header is generally a bad idea. It brings all > kinds of stuff into scope, potentially leading to name conflicts down the > road. And seems like a strange thing to do only for windows. > > Removal of the strdup macro is covered by the NONSTDC macros added at build > time. It's not a 32bit cleanup either, and you suggested it. > > Removal of [u]intptr_t definitions will cause a build failure if it results in > them being undefined. And getting an incorrect definition from elsewhere seems > implausible. I claim this all just isn't needed anymore and can be removed in > this PR, just as you suggested for the strdup macro. The 64bit definitions > could be added back in this PR (to be removed later by JDK-8343530), but that > just seems like useless churn. > > So I'm happy with the current removal of the entire chunk. It was already quite tangential to the 32-bit windows removal effort. I've restored the original code (with the exception of the 32-bit Windows part) in this PR, so we don't have to argue about that. Let's remove this as a separate effort, presumably as part of JDK-8343530. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1828003651 From ihse at openjdk.org Mon Nov 4 16:28:14 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:28:14 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v19] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Make JNICALL an empty define on all platforms ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/c6dce38d..d89bc561 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=17-18 Stats: 7 lines in 3 files changed: 2 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From kvn at openjdk.org Mon Nov 4 17:04:43 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 4 Nov 2024 17:04:43 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> On Mon, 4 Nov 2024 16:04:12 GMT, Magnus Ihse Bursie wrote: > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? Yes, I completely agree to do such clean up in separate RFE. Please, file one. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455239110 From ihse at openjdk.org Mon Nov 4 17:11:42 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 17:11:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> Message-ID: <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com> On Mon, 4 Nov 2024 17:01:33 GMT, Vladimir Kozlov wrote: > > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? > > Yes, I completely agree to do such clean up in separate RFE. Please, file one. Good. I filed https://bugs.openjdk.org/browse/JDK-8343553. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455256779 From kvn at openjdk.org Mon Nov 4 17:20:04 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 4 Nov 2024 17:20:04 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com> Message-ID: On Mon, 4 Nov 2024 17:08:40 GMT, Magnus Ihse Bursie wrote: >>> With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? >> >> Yes, I completely agree to do such clean up in separate RFE. Please, file one. > >> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? >> >> Yes, I completely agree to do such clean up in separate RFE. Please, file one. > > Good. I filed https://bugs.openjdk.org/browse/JDK-8343553. @magicus Back to my question about https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ? I see only few uses of `#ifdef WIN32` in HotSpot which can be replaced with `#ifdef _WINDOWS`: src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 Note, there are a lot more usages of `WIN32` in JDK libraries native code which we may consider renaming later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455274589 From ihse at openjdk.org Mon Nov 4 16:06:41 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 16:06:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> Message-ID: On Fri, 1 Nov 2024 18:11:13 GMT, Vladimir Kozlov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers >> - Remove windows-32-bit code in CompilerConfig::ergo_initialize > > Okay, I am confuse about `_WIN32` vs `WIN32`. > > You are saying that "_WIN32 is still defined on 64-bit Windows" but you are removing code guarded by `#ifdef _WIN32` > And our make files defines `WIN32` for all Windows OSs: https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 @vnkozlov > * There is use of `WIN32` instead of `_WIN32`. > > * There are comments referencing `Win32` which we need to rename to `Windows` to avoid confusion. > > * There is `class os::win32` in `os_windows.hpp` which is batter to rename to avoid confusion. Could be done in separate RFE. > > * "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it is really true, I would still suggest to use our variable `_WINDOWS` for that. Ok. Let's start with being on the same page about the meaning of "win32". This is what Microsoft has to say about it: "The Win32 API (also called the Windows API) is the native platform for Windows apps. [T]he same functions are generally supported on 32-bit and 64-bit Windows." https://learn.microsoft.com/en-us/windows/win32/apiindex/api-index-portal#win32-windows-api I'd say that they are the authoritative source on the subject. :-) So technically there is nothing **wrong** with stuff targeting Windows being called "win32", even if we only support 64-bit Windows going forward. With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? I will, however, do an additional round of checking all the grep hits on "win32" left to double-and-triple check that they indeed are not 32-bit specific. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455104589 From ihse at openjdk.org Mon Nov 4 17:31:00 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 17:31:00 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v21] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/fbd91ad0..dccf1a1d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=19-20 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 17:31:00 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 17:31:00 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v17] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com> <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com> <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com> Message-ID: <5af9UbiLlBKx6KCuroe94EZxYiD0d9jqmt6TSgYp4XM=.e1b42d0c-4d70-46c6-9e00-bc3e102bf9ec@github.com> On Mon, 4 Nov 2024 17:16:49 GMT, Vladimir Kozlov wrote: >>> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that? >>> >>> Yes, I completely agree to do such clean up in separate RFE. Please, file one. >> >> Good. I filed https://bugs.openjdk.org/browse/JDK-8343553. > > @magicus > Back to my question about https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ? > > I see only few uses of `#ifdef WIN32` in HotSpot which can be replaced with `#ifdef _WINDOWS`: > > src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 > src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32 > > > Note, there are a lot more usages of `WIN32` in JDK libraries native code which we may consider renaming later. @vnkozlov I have now looked at all ~1800 case-independent hits of "win32" in the `src` directory. All of them is referring to the general Windows API, and not any 32-bit specific code, as far as I can tell from the filename and local context. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455296938 From jsjolen at openjdk.org Mon Nov 4 15:06:42 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 4 Nov 2024 15:06:42 GMT Subject: RFR: 8304824: NMT should not use ThreadCritical [v9] In-Reply-To: References: <5IltCSB3t2hWzYpCn243kz4DceyvD6sXtUFSV700LaA=.a024c8b6-4575-4b7a-9e6d-cba108b2aa60@github.com> Message-ID: On Mon, 4 Nov 2024 14:52:06 GMT, Robert Toyonaga wrote: >>>This include is not needed because there are no uses that require the definition of Thread. >> >> Right, seems like the forward declaration used to be provided by `memory/allocation.hpp`. Let's get rid of the include and use a forward declaration of our own instead. > > Should I open another PR to remove it? I can also remove the locking related to NMT in arena.cpp in the same PR as well (as per [this comment](https://github.com/openjdk/jdk/pull/20852#issuecomment-2450515494)). I've fixed that particular bug and integrated it already :-). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20852#discussion_r1827882920 From kvn at openjdk.org Mon Nov 4 17:49:43 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 4 Nov 2024 17:49:43 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v21] In-Reply-To: <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com> Message-ID: On Mon, 4 Nov 2024 17:31:00 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp HotSpot VM changes are good for me. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2413705033 From jiangli at openjdk.org Mon Nov 4 17:49:56 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 4 Nov 2024 17:49:56 GMT Subject: RFR: 8343497: Missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries [v2] In-Reply-To: References: Message-ID: <6q-Ja-BRK_5Oy3TS6lc6ymzH4utYEnLjdsdisTjwK4I=.efba392d-8bba-40c8-808e-69d14608cae2@github.com> On Mon, 4 Nov 2024 00:28:46 GMT, Jiangli Zhou wrote: >> Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries. Thanks. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Fix macos build issue. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21861#issuecomment-2455341721 From jiangli at openjdk.org Mon Nov 4 18:01:44 2024 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 4 Nov 2024 18:01:44 GMT Subject: Integrated: 8343497: Missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries In-Reply-To: References: Message-ID: <83OuKUxRRFjaggpaCTif2Cm9jvyvmWNUqSQ1J8kigP8=.5b3c6ac4-14f0-4776-9907-406d8c442ae7@github.com> On Sun, 3 Nov 2024 20:19:47 GMT, Jiangli Zhou wrote: > Please review this trivial fix that adds missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries. Thanks. This pull request has now been integrated. Changeset: 774de278 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/774de278f77817e4494dc73bfee9257f145600fc Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod 8343497: Missing DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries Reviewed-by: ihse ------------- PR: https://git.openjdk.org/jdk/pull/21861 From pchilanomate at openjdk.org Mon Nov 4 18:18:23 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:18:23 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: - Update comment block in objectMonitor.cpp - Fix issue with unmounted virtual thread when dumping heap - Remove ThawBase::possibly_adjust_frame() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/52c26642..11396312 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=27-28 Stats: 349 lines in 14 files changed: 219 ins; 101 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Mon Nov 4 18:21:56 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:21:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long wrote: >> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. > > Here's my suggested C2 change: > > diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad > index d9c77a2f529..1e99db191ae 100644 > --- a/src/hotspot/cpu/aarch64/aarch64.ad > +++ b/src/hotspot/cpu/aarch64/aarch64.ad > @@ -3692,14 +3692,13 @@ encode %{ > __ post_call_nop(); > } else { > Label retaddr; > + // Make the anchor frame walkable > __ adr(rscratch2, retaddr); > + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); > __ lea(rscratch1, RuntimeAddress(entry)); > - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() > - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); > __ blr(rscratch1); > __ bind(retaddr); > __ post_call_nop(); > - __ add(sp, sp, 2 * wordSize); > } > if (Compile::current()->max_vector_size() > 0) { > __ reinitialize_ptrue(); Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. @RealFYang I made the equivalent change for riscv, could you verify it's okay? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828186069 From pchilanomate at openjdk.org Mon Nov 4 18:21:57 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:21:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v16] In-Reply-To: <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com> References: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com> <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com> Message-ID: On Tue, 29 Oct 2024 22:58:31 GMT, Dean Long wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix comment in VThreadWaitReenter > > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316: > >> 314: pc = ContinuationHelper::return_address_at( >> 315: sp - frame::sender_sp_ret_address_offset()); >> 316: } > > You could do this with an overload instead: > > static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) { > assert(pc != nullptr, ""); > [...] > } > static void set_anchor(JavaThread* thread, intptr_t* sp) { > address pc = ContinuationHelper::return_address_at( > sp - frame::sender_sp_ret_address_offset()); > set_anchor(thread, sp, pc); > } > > but the compiler probably optmizes the above check just fine. Added an overload method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828187178 From kevinw at openjdk.org Mon Nov 4 18:23:20 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 4 Nov 2024 18:23:20 GMT Subject: RFR: 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table Message-ID: This test is sensitive to timing, and should not run with -Xcomp (like NotifReconnectDeadlockTest.java). With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but if we handle that, it can also fail on the first iteration through the loop, at the call: JMXConnector client = JMXConnectorFactory.connect(addr, env); This test sets a short timeout value for connections, and -Xcomp slows things down greatly. RMI is gone before the connection is established. ------------- Commit messages: - 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table Changes: https://git.openjdk.org/jdk/pull/21884/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21884&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343491 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21884.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21884/head:pull/21884 PR: https://git.openjdk.org/jdk/pull/21884 From pchilanomate at openjdk.org Mon Nov 4 18:28:55 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:28:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote: >> Changed. > > Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? > > (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828190876 From pchilanomate at openjdk.org Mon Nov 4 18:28:56 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:28:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo wrote: >> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? >> >> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) > > Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? > I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828191725 From pchilanomate at openjdk.org Mon Nov 4 18:28:57 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:28:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> Message-ID: <3ThzYwhF_zfOZCcLiTcQIYjPtA5mNuUYZLWjiH3zJGE=.a4c97906-8a38-4af9-9cee-2c26b1f35271@github.com> On Fri, 25 Oct 2024 04:40:24 GMT, David Holmes wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision: >> >> - Rename set/has_owner_anonymous to set/has_anonymous_owner >> - Fix comments in javaThread.hpp and Thread.java >> - Rename nonce/nounce to seqNo in VirtualThread class >> - Remove ObjectMonitor::set_owner_from_BasicLock() > > src/hotspot/share/runtime/objectMonitor.cpp line 132: > >> 130: >> 131: // ----------------------------------------------------------------------------- >> 132: // Theory of operations -- Monitors lists, thread residency, etc: > > This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage Updated comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828195851 From pchilanomate at openjdk.org Mon Nov 4 18:36:57 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 4 Nov 2024 18:36:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: > > - Update comment block in objectMonitor.cpp > - Fix issue with unmounted virtual thread when dumping heap > - Remove ThawBase::possibly_adjust_frame() I brought a small fix to the heap dump code from the loom repo for an issue found recently. It includes a reproducer test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2455431391 From ihse at openjdk.org Mon Nov 4 19:27:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 19:27:59 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v22] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Also remove __cdecl - Also remove __stdcall on tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/dccf1a1d..82fbc51e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=20-21 Stats: 31 lines in 13 files changed: 0 ins; 10 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 19:35:42 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 19:35:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v22] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 19:27:59 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Also remove __cdecl > - Also remove __stdcall on tests I created https://bugs.openjdk.org/browse/JDK-8343560 to track the possible removal of `JNICALL` in the JDK source. Ultimately, we need to decide if it is worth the churn, or if we should keep it "just in case" some future platform will require a special keyword in that location (utterly unlikely as it might seem). If we go ahead with it, there are additional "downstream" fixes that needs to go with it, I highlighted some in the JBS issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455537378 From ihse at openjdk.org Mon Nov 4 19:45:57 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 19:45:57 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v23] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/82fbc51e..b5a481db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=21-22 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From wkemper at openjdk.org Mon Nov 4 19:52:30 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 4 Nov 2024 19:52:30 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: - Merge openjdk/jdk tip into great-genshen-pr-redux - Merge remote-tracking branch 'jdk/master' into merge-latest - Merge remote-tracking branch 'jdk/master' into merge-latest - Merge - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates Reviewed-by: kdnilsen - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational Reviewed-by: ysr - 8342919: GenShen: Fix whitespace Reviewed-by: xpeng, kdnilsen - 8342927: GenShen: Guarantee slices of time for coalesce and filling Reviewed-by: kdnilsen - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java Reviewed-by: kdnilsen, ysr - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode Reviewed-by: wkemper - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=05 Stats: 22859 lines in 229 files changed: 21116 ins; 886 del; 857 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From ihse at openjdk.org Mon Nov 4 19:58:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 19:58:59 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v24] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: buildJniFunctionName is now identical on Windows and Unix, so unify it ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/b5a481db..466a1a7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=22-23 Stats: 48 lines in 4 files changed: 8 ins; 40 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:02:32 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:02:32 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v25] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix build_agent_function_name to not handle "@"-stdcall style names ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/466a1a7a..88d89e75 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=23-24 Stats: 21 lines in 1 file changed: 3 ins; 16 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:18:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:18:23 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v26] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <3ZIvKBKdzJvYU91TwQcAGKUlDENAC5D5VNUFjI8zQzA=.a81d7ec5-c2ba-4eb0-ba78-c94ef65c8e28@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/88d89e75..6f690d02 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=24-25 Stats: 21 lines in 3 files changed: 7 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:21:09 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:21:09 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v27] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <_PNwSCgsqsInETeof5O-P5dZUGus72uvmtcYomw1QII=.eb53d7ac-250c-40cc-9fb5-68d5d3b15dd6@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: JVM_EnqueueOperation do not need __stdcall name lookup anymore ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/6f690d02..48d722bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=25-26 Stats: 8 lines in 1 file changed: 0 ins; 5 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:23:56 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:23:56 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v28] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <-YUW42BZ3ZY4k5baNUWfHqBlItoEyoOsXOMPxp_mvyM=.e3f414f4-c1c5-40db-ab72-debeb41968f5@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits: - Merge branch 'master' into impl-JEP-479 - JVM_EnqueueOperation do not need __stdcall name lookup anymore - [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them - Fix build_agent_function_name to not handle "@"-stdcall style names - buildJniFunctionName is now identical on Windows and Unix, so unify it - Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer - Also remove __cdecl - Also remove __stdcall on tests - Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp - Remove __stdcall notation - ... and 23 more: https://git.openjdk.org/jdk/compare/8b474971...699c641a ------------- Changes: https://git.openjdk.org/jdk/pull/21744/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=27 Stats: 1885 lines in 84 files changed: 86 ins; 1572 del; 227 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:29:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:29:23 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v29] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Update copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/699c641a..40291b9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=27-28 Stats: 39 lines in 39 files changed: 0 ins; 0 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Mon Nov 4 20:38:41 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:38:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v29] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 20:29:23 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright years I have now searched for `@[0-9]` to find instances of "stdcall-style" symbol names, and fixed those. I have also done a wide sweep of searching for "@" in general over the code base, which (unsurprisingly) generated a sh*tload of hits. I tried to sift through this, using some mental heuristics to skip those that are likely to be irrelevant, and scrutinized some other more carefully, to identify any other code that might be working with name mangling/parsing. I found no such code, outside of what I had already previously located. At this point, I believe I have resolved all outstanding issues from the reviews, and also finished fixing up the additional removal of the 32-bit Windows calling convention remnants. >From my PoV, what remains now is for me to repeat the in-depth testing of this PR, and to wait for the JEP to become targeted. @shipilev @erikj79 @vnkozlov @kimbarrett I'd appreciate a re-review from you at the current commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455648651 PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455651750 From ihse at openjdk.org Mon Nov 4 20:42:59 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 4 Nov 2024 20:42:59 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: fix: jvm_md.h was included, but not jvm.h... ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/40291b9b..9b10e74c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=28-29 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From jlu at openjdk.org Mon Nov 4 20:57:35 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 4 Nov 2024 20:57:35 GMT Subject: RFR: 8341796: Fix ExceptionOccurred in jdk.hotspot.agent [v2] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 20:14:43 GMT, Justin Lu wrote: >> Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.hotspot.agent_. >> >> This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > for consistency, include the comments as well Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21813#issuecomment-2455682666 From jlu at openjdk.org Mon Nov 4 20:57:37 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 4 Nov 2024 20:57:37 GMT Subject: Integrated: 8341796: Fix ExceptionOccurred in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 19:54:20 GMT, Justin Lu wrote: > Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.hotspot.agent_. > > This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean. This pull request has now been integrated. Changeset: 825ceb16 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/825ceb16b2e2347a4d9c1977d9a3a2da1296d5fe Stats: 29 lines in 5 files changed: 0 ins; 0 del; 29 mod 8341796: Fix ExceptionOccurred in jdk.hotspot.agent Reviewed-by: dholmes, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/21813 From sspitsyn at openjdk.org Mon Nov 4 20:57:53 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 4 Nov 2024 20:57:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: > > - Update comment block in objectMonitor.cpp > - Fix issue with unmounted virtual thread when dumping heap > - Remove ThawBase::possibly_adjust_frame() src/hotspot/share/runtime/continuation.cpp line 134: > 132: return true; > 133: } > 134: #endif // INCLUDE_JVMTI Could you, please, consider the simplification below? #if INCLUDE_JVMTI // return true if started vthread unmount bool jvmti_unmount_begin(JavaThread* target) { assert(!target->is_in_any_VTMS_transition(), "must be"); // Don't preempt if there is a pending popframe or earlyret operation. This can // be installed in start_VTMS_transition() so we need to check it here. if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { JvmtiThreadState* state = target->jvmti_thread_state(); if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { return false; } } // Don't preempt in case there is an async exception installed since // we would incorrectly throw it during the unmount logic in the carrier. if (target->has_async_exception_condition()) { return false; } if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); } else { target->set_is_in_VTMS_transition(true); // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) } return false; } static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { if (target->is_in_VTMS_transition()) { // We caught target at the end of a mount transition. return false; } return true; } #endif // INCLUDE_JVMTI ... static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { assert(java_lang_VirtualThread::is_instance(vthread), ""); if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition return false; } return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); } ... int Continuation::try_preempt(JavaThread* target, oop continuation) { verify_preempt_preconditions(target, continuation); if (LockingMode == LM_LEGACY) { return freeze_unsupported; } if (!is_safe_vthread_to_preempt(target, target->vthread())) { return freeze_pinned_native; } JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); log_trace(continuations, preempt)("try_preempt: %d", res); return res; } The following won't be needed: target->set_pending_jvmti_unmount_event(true); jvmtiThreadState.cpp: + if (thread->pending_jvmti_unmount_event()) { + assert(java_lang_VirtualThread::is_preempted(JNIHandles::resolve(vthread)), "should be marked preempted"); + JvmtiExport::post_vthread_unmount(vthread); + thread->set_pending_jvmti_unmount_event(false); + } As we discussed before there can be the `has_async_exception_condition()` flag set after a VTMS unmount transition has been started. But there is always such a race in VTMS transitions and the flag has to be processed as usual. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828376585 From jlu at openjdk.org Mon Nov 4 21:39:31 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 4 Nov 2024 21:39:31 GMT Subject: RFR: 8341798: Fix ExceptionOccurred in jdk.jdwp.agent In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 20:13:08 GMT, Justin Lu wrote: > Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.jdwp.agent_. > > This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean. Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21814#issuecomment-2455750512 From jlu at openjdk.org Mon Nov 4 21:39:32 2024 From: jlu at openjdk.org (Justin Lu) Date: Mon, 4 Nov 2024 21:39:32 GMT Subject: Integrated: 8341798: Fix ExceptionOccurred in jdk.jdwp.agent In-Reply-To: References: Message-ID: <7kaJS-hZC7Th9s6II27SU-bNVQyHmTLgJIpDNUEh7-U=.ebf36dc4-5f9e-4418-845e-d534415e873d@github.com> On Thu, 31 Oct 2024 20:13:08 GMT, Justin Lu wrote: > Please review this PR which is a JNI cleanup to replace incorrect usages of `jthrowable ExceptionOccurred(JNIEnv *env)` with `jboolean ExceptionCheck(JNIEnv *env)` in _jdk.jdwp.agent_. > > This is part of the bigger umbrella issue: https://bugs.openjdk.org/browse/JDK-8341542. This change only modifies instances where the exception object is not needed, and the method return value is being treated as if it were a boolean. This pull request has now been integrated. Changeset: 714472d8 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/714472d8a5b3d16b870bc272ce8664cd62733857 Stats: 28 lines in 7 files changed: 0 ins; 0 del; 28 mod 8341798: Fix ExceptionOccurred in jdk.jdwp.agent Reviewed-by: dholmes, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/21814 From asmehra at openjdk.org Mon Nov 4 22:35:37 2024 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 4 Nov 2024 22:35:37 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v7] In-Reply-To: References: Message-ID: <1wukRI6kmV2-xWutsU-7yRUnYMLAs9jwXIDDlyLj77M=.da0215eb-76bc-4f4c-b3e3-a7b26f642140@github.com> On Mon, 4 Nov 2024 03:15:25 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits: > > - fixed merge > - Merge branch 'master' into jep-483-candidate > - 8343493: Perform module checks during MetaspaceShared::map_archives() > - reverted changes in modules.cpp to make it easy to merge with mainline > - Fixed whitespace; fixed minimal build > - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity" > - fixed comments > - @ashu-mehra comment - renamed function to SystemDictionaryShared::should_be_excluded(); added comments and asserts; make sure the class is indeed checked > - Backed out 58233cc20fa22abfd711bb59aafb78e20fabc195 > - @ashu-mehra comment - rename/comment AOTClassLinker::add_new_candidate() and added asserts for thread safety > - ... and 162 more: https://git.openjdk.org/jdk/compare/29882bfe...935dcc68 Marked as reviewed by asmehra (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2414263812 From iklam at openjdk.org Mon Nov 4 23:57:48 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 4 Nov 2024 23:57:48 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @DanHeidinga comment -- exit VM when runtimeSetup() fails ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21642/files - new: https://git.openjdk.org/jdk/pull/21642/files/935dcc68..c46ae0b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=06-07 Stats: 34 lines in 5 files changed: 20 ins; 9 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From iklam at openjdk.org Mon Nov 4 23:57:48 2024 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 4 Nov 2024 23:57:48 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v6] In-Reply-To: References: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com> Message-ID: On Mon, 4 Nov 2024 14:21:09 GMT, Dan Heidinga wrote: >> I think this is already done: >> >> `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. >> >> https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300 > > I think you're right about the memory fencing being covered there but reading that code shows another potential issue - what if the `runtimeSetup()` call throws an exception? > > If I read `InstanceKlass::call_class_initializer()` correctly, an exception from `runtimeSetup()` will lead to marking the class as failing initialization (`initialization_error`) which will be an unexpected outcome as there may be instances of the class in the AOTCache that aren't produced by paths through the `` method. > > Classes are able to create an instance in `` and escape it to other code and then fail initialization. The instances are left in an odd state where after the `` the instance methods can be called but static fields and static methods can't be accessed. > > `runtimeSetup()` expands on this corner case which I think is OK for current "crawl" stage of our "crawl-walk-run" approach as its analogous to the existing `` behaviour. It may need refining in the future to abort the VM or do something else (?) in the case of failed `runtimeSetup` calls Thanks for catching this. I added code to exit the JVM when `runtimeSetup()` fails. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1828549749 From fyang at openjdk.org Tue Nov 5 00:20:53 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 00:20:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> Message-ID: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com> On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo wrote: >> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > >> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? >> > I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. > As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. > Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? I agree with @pchilano in that we are fine with these places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828563437 From vlivanov at openjdk.org Tue Nov 5 00:23:34 2024 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 5 Nov 2024 00:23:34 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 23:57:48 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @DanHeidinga comment -- exit VM when runtimeSetup() fails Looks good. Stylistic comment: while browsing the code a mix of "AOT" & "aot" caught my eye. I find the former spelling more descriptive. Any particular reason to use "aot" unless all lowercase spelling is preferred in some particular context? ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2414396530 From fyang at openjdk.org Tue Nov 5 00:26:54 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 00:26:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com> References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com> Message-ID: On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang wrote: >>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? >>> >> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. > >> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. > > Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. > >> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? > > I agree with @pchilano in that we are fine with these places. > Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828566395 From iklam at openjdk.org Tue Nov 5 01:13:39 2024 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 5 Nov 2024 01:13:39 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 00:20:56 GMT, Vladimir Ivanov wrote: > Looks good. > > Stylistic comment: while browsing the code a mix of "AOT" & "aot" caught my eye. I find the former spelling more descriptive. Any particular reason to use "aot" unless all lowercase spelling is preferred in some particular context? I've been using AOT in class names and aot in function/variable names. I think that's consistent with HotSpot convention. In logging, I've been using "aot" as logging seems to favor lowercase. In comments, I've been using a mix of AOT-xxx and aot-xxx, for no particular reason :-( ------------- PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2456016366 From pchilanomate at openjdk.org Tue Nov 5 01:40:15 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:40:15 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: - Add oopDesc::has_klass_gap() check - Rename waitTimeout/set_waitTimeout accessors - Revert suggestion to ThawBase::new_stack_frame - Improve JFR pinned reason in event - Use freeze_result consistently ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/11396312..79189f9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=28-29 Stats: 439 lines in 21 files changed: 123 ins; 261 del; 55 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Tue Nov 5 01:43:57 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:43:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v9] In-Reply-To: References: <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com> <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com> <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com> Message-ID: On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang wrote: >>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. >> >> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. >> >>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? >> >> I agree with @pchilano in that we are fine with these places. > >> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > > Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup. Reverted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615499 From pchilanomate at openjdk.org Tue Nov 5 01:43:58 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:43:58 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v28] In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com> Message-ID: <-NVIl6YW1oji4m0sLlL34aIrsJ0zq1_0PlgT6eva-jY=.9026ecf7-915c-4366-afff-30ec82ec6f98@github.com> On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 2107: >> >>> 2105: >>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { >>> 2107: return vthread->long_field(_timeout_offset); >> >> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? > > It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too. Renamed accessors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615772 From pchilanomate at openjdk.org Tue Nov 5 01:43:59 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:43:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v16] In-Reply-To: References: <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com> Message-ID: On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson wrote: >> If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. > > This code in `StackChunkAllocator::initialize` mimics the clearing code in: > > void MemAllocator::mem_clear(HeapWord* mem) const { > assert(mem != nullptr, "cannot initialize null object"); > const size_t hs = oopDesc::header_size(); > assert(_word_size >= hs, "unexpected object size"); > oopDesc::set_klass_gap(mem, 0); > Copy::fill_to_aligned_words(mem + hs, _word_size - hs); > } > > > but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be: > > if (oopDesc::has_klass_gap()) { > oopDesc::set_klass_gap(mem, 0); > } > > > So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`? Thanks for confirming. I added the check here which I think should cover any merge order. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828614946 From pchilanomate at openjdk.org Tue Nov 5 01:50:58 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 01:50:58 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently I brought some JFR changes from the loop repo that improve the reported reason when pinning. @mgronlun @egahlin Could any of you review these JFR changes? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2456054504 From syan at openjdk.org Tue Nov 5 01:51:37 2024 From: syan at openjdk.org (SendaoYan) Date: Tue, 5 Nov 2024 01:51:37 GMT Subject: RFR: 8343490: Update copyright year for JDK-8341692 Message-ID: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> Hi all, The copyright year of some files which has been changed by [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update correctly. This PR update the copyright year of [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk. ------------- Commit messages: - delete tail whitespace of test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java - 8343490: Update copyright year for JDK-8341692 Changes: https://git.openjdk.org/jdk/pull/21891/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21891&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343490 Stats: 66 lines in 66 files changed: 2 ins; 0 del; 64 mod Patch: https://git.openjdk.org/jdk/pull/21891.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21891/head:pull/21891 PR: https://git.openjdk.org/jdk/pull/21891 From amitkumar at openjdk.org Tue Nov 5 04:15:54 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 5 Nov 2024 04:15:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently Hi @pchilano, I see couple of failures on s390x, can you apply this patch: diff --git a/src/hotspot/cpu/s390/macroAssembler_s390.cpp b/src/hotspot/cpu/s390/macroAssembler_s390.cpp index f342240f3ca..d28b4579824 100644 --- a/src/hotspot/cpu/s390/macroAssembler_s390.cpp +++ b/src/hotspot/cpu/s390/macroAssembler_s390.cpp @@ -3492,7 +3492,7 @@ void MacroAssembler::increment_counter_eq(address counter_address, Register tmp1 void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Register temp1, Register temp2) { assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight"); - assert_different_registers(oop, box, temp1, temp2); + assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch); Register displacedHeader = temp1; Register currentHeader = temp1; @@ -3566,8 +3566,8 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis // If csg succeeds then CR=EQ, otherwise, register zero is filled // with the current owner. z_lghi(zero, 0); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_csg(zero, Z_R1_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_csg(zero, Z_R0_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged); // Store a non-null value into the box. z_stg(box, BasicLock::displaced_header_offset_in_bytes(), box); @@ -3576,7 +3576,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis BLOCK_COMMENT("fast_path_recursive_lock {"); // Check if we are already the owner (recursive lock) - z_cgr(Z_R1_scratch, zero); // owner is stored in zero by "z_csg" above + z_cgr(Z_R0_scratch, zero); // owner is stored in zero by "z_csg" above z_brne(done); // not a recursive lock // Current thread already owns the lock. Just increment recursion count. @@ -3594,7 +3594,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Register temp1, Register temp2) { assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight"); - assert_different_registers(oop, box, temp1, temp2); + assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch); Register displacedHeader = temp1; Register currentHeader = temp2; @@ -3641,8 +3641,8 @@ void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Reg // Handle existing monitor. bind(object_has_monitor); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_cg(Z_R1_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner))); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_cg(Z_R0_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner))); z_brne(done); BLOCK_COMMENT("fast_path_recursive_unlock {"); @@ -6164,7 +6164,7 @@ void MacroAssembler::lightweight_unlock(Register obj, Register temp1, Register t } void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Register box, Register tmp1, Register tmp2) { - assert_different_registers(obj, box, tmp1, tmp2); + assert_different_registers(obj, box, tmp1, tmp2, Z_R0_scratch); // Handle inflated monitor. NearLabel inflated; @@ -6296,12 +6296,12 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Registe // If csg succeeds then CR=EQ, otherwise, register zero is filled // with the current owner. z_lghi(zero, 0); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_csg(zero, Z_R1_scratch, owner_address); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_csg(zero, Z_R0_scratch, owner_address); z_bre(monitor_locked); // Check if recursive. - z_cgr(Z_R1_scratch, zero); // zero contains the owner from z_csg instruction + z_cgr(Z_R0_scratch, zero); // zero contains the owner from z_csg instruction z_brne(slow_path); // Recursive CC: @RealLucy ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2414585800 From fyang at openjdk.org Tue Nov 5 06:35:52 2024 From: fyang at openjdk.org (Fei Yang) Date: Tue, 5 Nov 2024 06:35:52 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo wrote: >> Here's my suggested C2 change: >> >> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad >> index d9c77a2f529..1e99db191ae 100644 >> --- a/src/hotspot/cpu/aarch64/aarch64.ad >> +++ b/src/hotspot/cpu/aarch64/aarch64.ad >> @@ -3692,14 +3692,13 @@ encode %{ >> __ post_call_nop(); >> } else { >> Label retaddr; >> + // Make the anchor frame walkable >> __ adr(rscratch2, retaddr); >> + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); >> __ lea(rscratch1, RuntimeAddress(entry)); >> - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() >> - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); >> __ blr(rscratch1); >> __ bind(retaddr); >> __ post_call_nop(); >> - __ add(sp, sp, 2 * wordSize); >> } >> if (Compile::current()->max_vector_size() > 0) { >> __ reinitialize_ptrue(); > > Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. > @RealFYang I made the equivalent change for riscv, could you verify it's okay? @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup! `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform. BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2 Do you mind adding following small addon change to fix it? Thanks. diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp index 84a292242c3..ac28f4b3514 100644 --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { if (LockingMode != LM_LEGACY) { // Check preemption for Object.wait() Label not_preempted; - __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset())); - __ beqz(t0, not_preempted); + __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset())); + __ beqz(t1, not_preempted); __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset())); - __ jr(t0); + __ jr(t1); __ bind(native_return); __ restore_after_resume(true /* is_native */); // reload result_handler ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828797495 From egahlin at openjdk.org Tue Nov 5 08:02:54 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 5 Nov 2024 08:02:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently src/hotspot/share/jfr/metadata/metadata.xml line 160: > 158: > 159: > 160: Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html (Note: The fact that the event is now written in the JVM doesn't determine the category.) src/hotspot/share/jfr/metadata/metadata.xml line 160: > 158: > 159: > 160: The label should be "Blocking Operation" with a capital "O". Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828875263 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828878025 From alanb at openjdk.org Tue Nov 5 08:22:55 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 5 Nov 2024 08:22:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 07:48:40 GMT, Erik Gahlin wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: >> >> - Add oopDesc::has_klass_gap() check >> - Rename waitTimeout/set_waitTimeout accessors >> - Revert suggestion to ThawBase::new_stack_frame >> - Improve JFR pinned reason in event >> - Use freeze_result consistently > > src/hotspot/share/jfr/metadata/metadata.xml line 160: > >> 158: >> 159: >> 160: > > Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: > > https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html > > (Note: The fact that the event is now written in the JVM doesn't determine the category.) Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value that was in the `@Catalog` wasn't carried over. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828915229 From sspitsyn at openjdk.org Tue Nov 5 08:33:28 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 5 Nov 2024 08:33:28 GMT Subject: RFR: 8342577: Clean up JVMTI breakpoint support In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 01:42:36 GMT, Alex Menkov wrote: > The fix cleans up code to support list of JVMTI breakpoints. > - classes required to supports cache of byte code pointers (GrowableElement, GrowableCache, JvmtiBreakpointCache) are dropped; > - class JvmtiCurrentBreakpoints (JvmtiBreakpoints factory) is left as is, dropped unused code; > - fixed race in JvmtiCurrentBreakpoints::get_jvmti_breakpoints() (fix for JDK-8210637); > - JvmtiBreakpoint:JvmtiBreakpoint() + JvmtiBreakpoint::copy(JvmtiBreakpoint& bp) are replaced with copy ctor; > - JvmtiBreakpoints::clearall_in_class_at_safepoint() is simplified to do a single pass; > > Testing: tier1..tier6 Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21675#pullrequestreview-2414941187 From kevinw at openjdk.org Tue Nov 5 10:32:28 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 5 Nov 2024 10:32:28 GMT Subject: RFR: 8343344: Windows attach logic failed to handle a failed open on a pipe In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 00:42:23 GMT, Alex Menkov wrote: > The fix adds correct handling of "could not open pipe" errors in attach listener instead of assert which causes target VM crash. > > testing: tier1,tier2,hs-tier5-svc Hi, List of tests doesn't mention tier4 where the failures were first noticed? When PipeChannel::open logs error, and returns false, then Win32AttachOperation::open_pipe returns that value, then Win32AttachListener::dequeue() also logs that there was an error? Is that message just a less detailed duplicate? (it states whether it's v1 or v2, but maybe that's not that interesting?) In the v2 case, Win32AttachListener::dequeue() will log if open succeeded, if !op->read_request(). But AttachOperation::read_request mostly logs its own errors as well. I think it's only this one: 639 if (buffer_size < 0) { 640 return false; ...where it does not log when returning false. Maybe it should log then, and Win32AttachListener::dequeue() does not need to log? While are are here, is it possible to address these at the same time? open/src/hotspot/share/services/attachListener.cpp typo "ot" -> "or" 631 case ATTACH_API_V2: // 000000 632 if (AttachListener::get_supported_version() < 2) { 633 log_error(attach)("Failed to read request: v2 is unsupported ot disabled"); exact -> "exactly" 649 // Must contain exact 'buffer_size' bytes. Also, is the line 631 comment, with 3 args, misleading? (moving away from exactly 3 arguments...) Thanks! ------------- PR Review: https://git.openjdk.org/jdk/pull/21888#pullrequestreview-2415229062 From sspitsyn at openjdk.org Tue Nov 5 11:38:53 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 5 Nov 2024 11:38:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently src/hotspot/share/runtime/objectMonitor.cpp line 1643: > 1641: // actual callee (see nmethod::preserve_callee_argument_oops()). > 1642: ThreadOnMonitorWaitedEvent tmwe(current); > 1643: JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out); We post a JVMTI `MonitorWaited` event here for a virtual thread. A couple of questions on this: - Q1: Is this posted after the `VirtualThreadMount` extension event posted? Unfortunately, it is not easy to make this conclusion. - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801. Does it post the `MonitorWaited` event for this virtual thread as well? If not, then it is not clear how posting for virtual thread is avoided. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829199889 From duke at openjdk.org Tue Nov 5 13:19:09 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 13:19:09 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding Message-ID: - Changed several "NULL" in comments to "null" - Changed several `NULL` in code to `nullptr` ------------- Commit messages: - Fix copyright year - 8342860: Fix more NULL usage backsliding Changes: https://git.openjdk.org/jdk/pull/21826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342860 Stats: 22 lines in 11 files changed: 0 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/21826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21826/head:pull/21826 PR: https://git.openjdk.org/jdk/pull/21826 From szaldana at openjdk.org Tue Nov 5 13:19:09 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 5 Nov 2024 13:19:09 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 13:35:56 GMT, theoweidmannoracle wrote: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` I am not a Reviewer but I left a small comment. Cheers! src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 1: > 1: /* Missing copyright update. ------------- Changes requested by szaldana (Committer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2413904415 PR Review Comment: https://git.openjdk.org/jdk/pull/21826#discussion_r1828249544 From duke at openjdk.org Tue Nov 5 13:19:09 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 13:19:09 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 19:10:50 GMT, Sonia Zaldana Calles wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 1: > >> 1: /* > > Missing copyright update. Thanks for spotting this! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21826#discussion_r1829109988 From szaldana at openjdk.org Tue Nov 5 14:24:39 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 5 Nov 2024 14:24:39 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> On Fri, 1 Nov 2024 13:35:56 GMT, theoweidmannoracle wrote: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` Hi @theoweidmannoracle, I think the GHA tests are not running because you haven't enabled GHA on your personal fork. See https://wiki.openjdk.org/display/SKARA/Testing for a bit more info. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457309128 From pchilanomate at openjdk.org Tue Nov 5 14:34:21 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:34:21 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v31] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: - Fixes to JFR metadata.xml - Fix return miss prediction in generate_native_entry for riscv - Fix s390x failures ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/79189f9b..124efa0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=29-30 Stats: 16 lines in 3 files changed: 0 ins; 0 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Tue Nov 5 14:34:22 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:34:22 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v12] In-Reply-To: References: <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com> Message-ID: On Tue, 5 Nov 2024 06:30:55 GMT, Fei Yang wrote: >> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. >> @RealFYang I made the equivalent change for riscv, could you verify it's okay? > > @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup! > `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform. > > BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2 > Do you mind adding following small addon change to fix it? Thanks. > > diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > index 84a292242c3..ac28f4b3514 100644 > --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { > if (LockingMode != LM_LEGACY) { > // Check preemption for Object.wait() > Label not_preempted; > - __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset())); > - __ beqz(t0, not_preempted); > + __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset())); > + __ beqz(t1, not_preempted); > __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset())); > - __ jr(t0); > + __ jr(t1); > __ bind(native_return); > __ restore_after_resume(true /* is_native */); > // reload result_handler Thanks for checking. Added changes to `TemplateInterpreterGenerator::generate_native_entry`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829457335 From pchilanomate at openjdk.org Tue Nov 5 14:37:54 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:37:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: <8bSr_dBqhXkGBdKhm3qO4j1XJHBtu_RkeIH8ldtDAVA=.b9ae55cd-0172-40f4-bb51-cb72eadac61d@github.com> On Tue, 5 Nov 2024 01:47:29 GMT, Patricio Chilano Mateo wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: >> >> - Add oopDesc::has_klass_gap() check >> - Rename waitTimeout/set_waitTimeout accessors >> - Revert suggestion to ThawBase::new_stack_frame >> - Improve JFR pinned reason in event >> - Use freeze_result consistently > > I brought some JFR changes from the loom repo that improve the reported reason when pinning. > @mgronlun @egahlin Could any of you review these JFR changes? Thanks. > Hi @pchilano, > > I see couple of failures on s390x, can you apply this patch: > Thanks @offamitkumar. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2457338726 From pchilanomate at openjdk.org Tue Nov 5 14:37:56 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:37:56 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: >> >> - Add oopDesc::has_klass_gap() check >> - Rename waitTimeout/set_waitTimeout accessors >> - Revert suggestion to ThawBase::new_stack_frame >> - Improve JFR pinned reason in event >> - Use freeze_result consistently > > src/hotspot/share/jfr/metadata/metadata.xml line 160: > >> 158: >> 159: >> 160: > > The label should be "Blocking Operation" with a capital "O". > > Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829463128 From pchilanomate at openjdk.org Tue Nov 5 14:37:55 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 14:37:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 08:19:34 GMT, Alan Bateman wrote: >> src/hotspot/share/jfr/metadata/metadata.xml line 160: >> >>> 158: >>> 159: >>> 160: >> >> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: >> >> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html >> >> (Note: The fact that the event is now written in the JVM doesn't determine the category.) > > Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829462765 From aboldtch at openjdk.org Tue Nov 5 14:37:57 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 5 Nov 2024 14:37:57 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: > > - Add oopDesc::has_klass_gap() check > - Rename waitTimeout/set_waitTimeout accessors > - Revert suggestion to ThawBase::new_stack_frame > - Improve JFR pinned reason in event > - Use freeze_result consistently src/hotspot/share/runtime/objectMonitor.inline.hpp line 50: > 48: inline int64_t ObjectMonitor::owner_from(oop vthread) { > 49: int64_t tid = java_lang_Thread::thread_id(vthread); > 50: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); Suggestion: assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829464866 From ihse at openjdk.org Tue Nov 5 14:51:47 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 5 Nov 2024 14:51:47 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > fix: jvm_md.h was included, but not jvm.h... This has now passed internal CI testing tier1-5 (except for one test that also fails in mainline). ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2457376495 From duke at openjdk.org Tue Nov 5 14:52:28 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 14:52:28 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> References: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> Message-ID: On Tue, 5 Nov 2024 14:22:06 GMT, Sonia Zaldana Calles wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > Hi @theoweidmannoracle, I think the GHA tests are not running because you haven't enabled GHA on your personal fork. See https://wiki.openjdk.org/display/SKARA/Testing for a bit more info. Hi @SoniaZaldana, thanks for pointing that out. I enabled the tests now, but it seems there's no way to run them except for pushing new changes. I did run Oracle's internal testing, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457377145 From jsjolen at openjdk.org Tue Nov 5 14:58:30 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 5 Nov 2024 14:58:30 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 13:35:56 GMT, theoweidmannoracle wrote: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` Thank you, these changes looks good to me. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2415877774 From duke at openjdk.org Tue Nov 5 15:05:51 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 15:05:51 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` theoweidmannoracle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8342860 - Fix copyright year - 8342860: Fix more NULL usage backsliding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21826/files - new: https://git.openjdk.org/jdk/pull/21826/files/afb592f8..9754145b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=00-01 Stats: 123205 lines in 577 files changed: 97665 ins; 8394 del; 17146 mod Patch: https://git.openjdk.org/jdk/pull/21826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21826/head:pull/21826 PR: https://git.openjdk.org/jdk/pull/21826 From szaldana at openjdk.org Tue Nov 5 15:05:51 2024 From: szaldana at openjdk.org (Sonia Zaldana Calles) Date: Tue, 5 Nov 2024 15:05:51 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> References: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> Message-ID: On Tue, 5 Nov 2024 14:22:06 GMT, Sonia Zaldana Calles wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > Hi @theoweidmannoracle, I think the GHA tests are not running because you haven't enabled GHA on your personal fork. See https://wiki.openjdk.org/display/SKARA/Testing for a bit more info. > Hi @SoniaZaldana, thanks for pointing that out. I enabled the tests now, but it seems there's no way to run them except for pushing new changes. I did run Oracle's internal testing, though. You can try syncing your fork and that should trigger GHA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457405542 From duke at openjdk.org Tue Nov 5 15:05:51 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Tue, 5 Nov 2024 15:05:51 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> Message-ID: <8_mKDBs4-BvKnB4UuU1BHeYGga7yHYe3KDP2xht6H0g=.dbbc64da-97fa-48a3-860c-73bfbdc961de@github.com> On Tue, 5 Nov 2024 15:00:37 GMT, Sonia Zaldana Calles wrote: >> Hi @theoweidmannoracle, I think the GHA tests are not running because you haven't enabled GHA on your personal fork. See https://wiki.openjdk.org/display/SKARA/Testing for a bit more info. > >> Hi @SoniaZaldana, thanks for pointing that out. I enabled the tests now, but it seems there's no way to run them except for pushing new changes. I did run Oracle's internal testing, though. > > You can try syncing your fork and that should trigger GHA. @SoniaZaldana Thanks for the tip! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457412470 From kbarrett at openjdk.org Tue Nov 5 15:11:31 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Nov 2024 15:11:31 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:05:51 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8342860 > - Fix copyright year > - 8342860: Fix more NULL usage backsliding Can you use the (updated) regex in the JBS issue description to verify the only remaining "NULL"s in src/hotspot are jvmti.{xml,xsl} and globalDefinitons_{gcc,visCPP}.hpp? There are also some new NULLs in test/hotspot. ./jtreg/serviceability/jvmti/GetMethodDeclaringClass/libTestUnloadedClass.cpp ./jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp There are a couple more (after filtering out java and C source files) that I think shouldn't be changed. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2415914752 From jwaters at openjdk.org Tue Nov 5 15:52:40 2024 From: jwaters at openjdk.org (Julian Waters) Date: Tue, 5 Nov 2024 15:52:40 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:05:51 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8342860 > - Fix copyright year > - 8342860: Fix more NULL usage backsliding Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2416030956 From kbarrett at openjdk.org Tue Nov 5 16:04:34 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Nov 2024 16:04:34 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 15:05:51 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8342860 > - Fix copyright year > - 8342860: Fix more NULL usage backsliding Can you use the (updated) regex in the JBS issue description to verify the only remaining "NULL"s in src/hotspot are the jvmti.{xml,xls} files and the globalDefinitions_{gcc,visCPP}.hpp files? There are also some NULLs recently introduced in test/hotspot: ./jtreg/serviceability/jvmti/GetMethodDeclaringClass/libTestUnloadedClass.cpp ./jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp (Found by applying the same regex to test/hotspot, and then removing .java and .c files.) There are a few other files in test/hotspot containing NULLs: ./jtreg/vmTestbase/nsk/share/jni/README ./jtreg/vmTestbase/nsk/share/jvmti/README These are documentation files with examples written in C, so should not be changed. ./jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp In a comment describing a string to be used for printing. Uses would need to be examined to ensure it's okay to change the string used for a null value. I think I planned to do this as a followup to JDK-8324799, and then forgot. I'd be okay with doing something about this being separate from the current PR. While the necessary textual changes are probably small, there's a lot of uses to examine to be sure a change is okay. ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2416066994 From kbarrett at openjdk.org Tue Nov 5 16:15:30 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Nov 2024 16:15:30 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding In-Reply-To: References: <8-DSId0L1YvlZctIylDj_p0UMXpuO-9cd-_lXSVlD1M=.21b528f7-e7ea-4d52-84e4-0af1424c9fa7@github.com> Message-ID: On Tue, 5 Nov 2024 15:00:37 GMT, Sonia Zaldana Calles wrote: > Hi @SoniaZaldana, thanks for pointing that out. I enabled the tests now, but it seems there's no way to run them except for pushing new changes. I did run Oracle's internal testing, though. To manually trigger GHA tests: 1. Go to your personal fork, and click on the "Actions" menu item. 2. Select the "OpenJDK GHA Sanity Checks" Action. 3. Click on the "Run workflow" pulldown. 4. Select the branch you want to test in the "Use workflow from" pulldown. 5. Click on "Run workflow". ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2457602766 From stuefe at openjdk.org Tue Nov 5 16:40:54 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Tue, 5 Nov 2024 16:40:54 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v53] In-Reply-To: References: Message-ID: <5EgL-mJp75JLOxEccrrGVxbfS6QdUywRSfsOcgx4zl8=.3c283bf3-3e2e-4fe2-bce5-c30d7d4e2da4@github.com> On Thu, 24 Oct 2024 21:04:51 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Enable riscv in CompressedClassPointersEncodingScheme test Went again through all the changes, with focus on runtime code. Still good. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2416155892 From rkennke at openjdk.org Tue Nov 5 16:49:01 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Nov 2024 16:49:01 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v50] In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 16:22:20 GMT, Roman Kennke wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright >> - Avoid assert/endless-loop in JFR code > > @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case. > @rkennke can you include this small update for s390x as well: > > ```diff > diff --git a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp > index 0f7e5c9f457..476e3d5daa4 100644 > --- a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp > +++ b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp > @@ -174,8 +174,11 @@ void C1_MacroAssembler::try_allocate( > void C1_MacroAssembler::initialize_header(Register obj, Register klass, Register len, Register Rzero, Register t1) { > assert_different_registers(obj, klass, len, t1, Rzero); > if (UseCompactObjectHeaders) { > - z_lg(t1, Address(klass, in_bytes(Klass::prototype_header_offset()))); > - z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes())); > + z_mvc( > + Address(obj, oopDesc::mark_offset_in_bytes()), /* move to */ > + Address(klass, in_bytes(Klass::prototype_header_offset())), /* move from */ > + sizeof(markWord) /* how much to move */ > + ); > } else { > load_const_optimized(t1, (intx)markWord::prototype().value()); > z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes())); > diff --git a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp > index 378d5e4cfe1..c5713161bf9 100644 > --- a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp > +++ b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp > @@ -46,7 +46,7 @@ void C2_MacroAssembler::load_narrow_klass_compact_c2(Register dst, Address src) > // The incoming address is pointing into obj-start + klass_offset_in_bytes. We need to extract > // obj-start, so that we can load from the object's mark-word instead. > z_lg(dst, src.plus_disp(-oopDesc::klass_offset_in_bytes())); > - z_srlg(dst, dst, markWord::klass_shift); // TODO: could be z_sra > + z_srlg(dst, dst, markWord::klass_shift); > } > > //------------------------------------------------------ > diff --git a/src/hotspot/cpu/s390/templateTable_s390.cpp b/src/hotspot/cpu/s390/templateTable_s390.cpp > index 3cb1aba810d..5b8f7a20478 100644 > --- a/src/hotspot/cpu/s390/templateTable_s390.cpp > +++ b/src/hotspot/cpu/s390/templateTable_s390.cpp > @@ -3980,8 +3980,11 @@ void TemplateTable::_new() { > // Initialize object header only. > __ bind(initialize_header); > if (UseCompactObjectHeaders) { > - __ z_lg(tmp, Address(iklass, in_bytes(Klass::prototype_header_offset()))); > - __ z_stg(tmp, Address(RallocatedObject, oopDesc::mark_offset_in_bytes())); > + __ z_mvc( > + Address(RallocatedObject, oopDesc::mark_offset_in_bytes()), // move to > + Address(iklass, in_bytes(Klass::prototype_header_offset())), // move from > + sizeof(markWord) // how much to move > + ); > } else { > __ store_const(Address(RallocatedObject, oopDesc::mark_offset_in_bytes()), > (long) markWord::prototype().value()); > ``` Hi Amit, sorry I only now get to reply to this, I have been traveling. What does the change do? Is it critical? Would it be possible to fix it after I intergrated the JEP? Because any change that I do now invalidates existing reviews, and might delay integration, and we're already running pretty close to RDP1. If at all possible, I would prefer to take it after I intergrated the JEP - we can have fixes well after RDP1, but not new features. If you agree, then please file a follow-up issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2457674486 From amitkumar at openjdk.org Tue Nov 5 16:49:01 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Tue, 5 Nov 2024 16:49:01 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v50] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 16:43:35 GMT, Roman Kennke wrote: >Hi Amit, sorry I only now get to reply to this, I have been traveling. What does the change do? Is it critical? Would it be possible to fix it after I intergrated the JEP? Because any change that I do now invalidates existing reviews, and might delay integration, and we're already running pretty close to RDP1. If at all possible, I would prefer to take it after I intergrated the JEP - we can have fixes well after RDP1, but not new features. If you agree, then please file a follow-up issue. That's perfectly fine. I will do it with separate RFE :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2457680086 From kbarrett at openjdk.org Tue Nov 5 17:11:53 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 5 Nov 2024 17:11:53 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > fix: jvm_md.h was included, but not jvm.h... I kind of wish the __cdecl / __stdcall changes had been done separately. Oh well. src/hotspot/os/windows/os_windows.cpp line 5820: > 5818: } > 5819: > 5820: // FIXME ??? src/hotspot/os/windows/os_windows.cpp line 5863: > 5861: return nullptr; > 5862: } > 5863: [pre-existing, and can't comment on line 5858 because it's not sufficiently near a change.] The calculation of `len` is wasting a byte when `lib_name` is null. The `+2` accounts for the terminating `NUL` and the underscore separator between the sym_name part and the lib_name part. That underscore isn't added when there isn't a lib_name part. I think the simplest fix would be to change `name_len` to `(name_len +1)` and `+2` to `+1` in that calculation. And add some commentary. This might be deemed not worth fixing as there is likely often no actual wastage, due to alignment padding, and it slightly further complicates the calculation. But additional commentary would still be desirable, to guide the next careful reader. In which case it might be simpler to describe the fixed version. Since this is pre-existing and relatively harmless in execution, it can be addressed in a followup change. src/hotspot/share/include/jvm.h line 1165: > 1163: #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > 1164: #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > 1165: #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} There is more cleanup that can be done here. These definitions are used as array initializers (hence the surrounding curly braces). They are now always singleton, rather than sometimes having 2 elements. The uses iterate over the now always singleton arrays. Those iterations are no longer needed and could be eliminated. And these macros could be eliminated, using the corresponding string directly in each use. This can all be done as a followup change. src/java.base/share/native/libjava/NativeLibraries.c line 67: > 65: strcat(jniEntryName, "_"); > 66: strcat(jniEntryName, cname); > 67: } I would prefer this be directly inlined at the sole call (in findJniFunction), to make it easier to verify there aren't any buffer overrun problems. (I don't think there are, but looking at this in isolation triggered warnings in my head.) Also, it looks like all callers of findJniFunction ensure the cname argument is non-null. So there should be no need to handle the null case in findJniFunction (other than perhaps an assert or something). That could be addressed in a followup. (I've already implicitly suggested elsewhere in this PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS thing.) ------------- Changes requested by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2415002837 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829659373 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1828969105 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829478432 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829684759 From mullan at openjdk.org Tue Nov 5 18:30:37 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Nov 2024 18:30:37 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v7] In-Reply-To: References: Message-ID: > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 213 commits: - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Remove "access" and "policy" options from debug help. - Merge branch 'master' into jep486 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486 - remove MainClassCantBeLoadedTest from problemlisting - remove LauncherErrors test from problemlisting - Merge branch 'master' into jep486 - Remove left-over paragraph about SM use from LoggerFinder - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - ... and 203 more: https://git.openjdk.org/jdk/compare/f69b6016...51d2a2a3 ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=06 Stats: 68938 lines in 1889 files changed: 2490 ins; 62600 del; 3848 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From mullan at openjdk.org Tue Nov 5 18:58:22 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Nov 2024 18:58:22 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v8] In-Reply-To: References: Message-ID: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com> > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 217 commits: - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Remove "access" and "policy" options from debug help. - Merge branch 'master' into jep486 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486 - remove MainClassCantBeLoadedTest from problemlisting - remove LauncherErrors test from problemlisting - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9 ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=07 Stats: 68934 lines in 1889 files changed: 2490 ins; 62600 del; 3844 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From mullan at openjdk.org Tue Nov 5 19:24:12 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Nov 2024 19:24:12 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com> Message-ID: On Sun, 3 Nov 2024 12:33:05 GMT, Alan Bateman wrote: >> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that. > > Removed in jep486 branch in sandbox so will get picked up when PR is refreshed. Fixed in https://github.com/openjdk/jdk/pull/21498/commits/ab586f6619ca5f7e213876219abf61a36155735c ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1829886748 From rkennke at openjdk.org Tue Nov 5 20:00:31 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 5 Nov 2024 20:00:31 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v54] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 104 commits: - Merge tag 'jdk-24+22' into JDK-8305895-v4 Added tag jdk-24+22 for changeset 388d44fb - Enable riscv in CompressedClassPointersEncodingScheme test - s390 port - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test - Update copyright - Avoid assert/endless-loop in JFR code - Update copyright headers - Merge tag 'jdk-24+20' into JDK-8305895-v4 Added tag jdk-24+20 for changeset 7a64fbbb - Fix needle copying in indexOf intrinsic for smaller headers - Compact header riscv (#3) Implement compact headers on RISCV --------- Co-authored-by: hamlin - ... and 94 more: https://git.openjdk.org/jdk/compare/388d44fb...b945822a ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=53 Stats: 5214 lines in 218 files changed: 3587 ins; 864 del; 763 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From mullan at openjdk.org Tue Nov 5 20:10:20 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 5 Nov 2024 20:10:20 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v8] In-Reply-To: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com> References: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com> Message-ID: On Tue, 5 Nov 2024 18:58:22 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 217 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Remove "access" and "policy" options from debug help. > - Merge branch 'master' into jep486 > - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486 > - remove MainClassCantBeLoadedTest from problemlisting > - remove LauncherErrors test from problemlisting > - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9 The latest update includes: - merging with the mainline sources - a couple of test removals from the ProblemList for tests that no longer apply - removal of the "policy" and "access" options from the `-Djava.security.debug` help option. - a small update to remove some SM specific text from the `System.LoggerFinder` class description. - copyright header updates for several tests that were previously modified - addition of a few client manual tests to the ProblemList that have dependencies on the Security Manager and will be resolved later ------------- PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2458058335 From amenkov at openjdk.org Tue Nov 5 21:00:07 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 5 Nov 2024 21:00:07 GMT Subject: RFR: 8343344: Windows attach logic failed to handle a failed open on a pipe [v2] In-Reply-To: References: Message-ID: > The fix adds correct handling of "could not open pipe" errors in attach listener instead of assert which causes target VM crash. > > testing: tier1,tier2,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21888/files - new: https://git.openjdk.org/jdk/pull/21888/files/e535bfcd..ec14cd51 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21888&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21888&range=00-01 Stats: 16 lines in 2 files changed: 9 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/21888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21888/head:pull/21888 PR: https://git.openjdk.org/jdk/pull/21888 From amenkov at openjdk.org Tue Nov 5 21:06:28 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 5 Nov 2024 21:06:28 GMT Subject: RFR: 8343344: Windows attach logic failed to handle a failed open on a pipe [v2] In-Reply-To: References: Message-ID: <5VHAvYoOOys93KhLn_bi3EYn5AfPUz0koZ22uOyccYw=.655ad7cb-5a82-4e5f-8df9-7a0ec3fe7d04@github.com> On Tue, 5 Nov 2024 10:29:38 GMT, Kevin Walls wrote: > List of tests doesn't mention tier4 where the failures were first noticed? Good point. Run it now, but it takes time to complete. > When PipeChannel::open logs error, and returns false, then Win32AttachOperation::open_pipe returns that value, then Win32AttachListener::dequeue() also logs that there was an error? Is that message just a less detailed duplicate? (it states whether it's v1 or v2, but maybe that's not that interesting?) > In the v2 case, Win32AttachListener::dequeue() will log if open succeeded, if !op->read_request(). But AttachOperation::read_request mostly logs its own errors as well. I think it's only this one: 639 if (buffer_size < 0) { 640 return false; ...where it does not log when returning false. Maybe it should log then, and Win32AttachListener::dequeue() does not need to log? Ok, done. Also added error logging in PipeChannel:: read and write (AttachOperation::read_request_data does not logs IO errors) > While are are here, is it possible to address these at the same time? open/src/hotspot/share/services/attachListener.cpp > typo "ot" -> "or" 631 case ATTACH_API_V2: // 000000 632 if (AttachListener::get_supported_version() < 2) { 633 log_error(attach)("Failed to read request: v2 is unsupported ot disabled"); Fixed. > exact -> "exactly" 649 // Must contain exact 'buffer_size' bytes. Fixed. > Also, is the line 631 comment, with 3 args, misleading? (moving away from exactly 3 arguments...) Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21888#issuecomment-2458147001 From amenkov at openjdk.org Tue Nov 5 22:41:36 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 5 Nov 2024 22:41:36 GMT Subject: Integrated: 8342577: Clean up JVMTI breakpoint support In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 01:42:36 GMT, Alex Menkov wrote: > The fix cleans up code to support list of JVMTI breakpoints. > - classes required to supports cache of byte code pointers (GrowableElement, GrowableCache, JvmtiBreakpointCache) are dropped; > - class JvmtiCurrentBreakpoints (JvmtiBreakpoints factory) is left as is, dropped unused code; > - fixed race in JvmtiCurrentBreakpoints::get_jvmti_breakpoints() (fix for JDK-8210637); > - JvmtiBreakpoint:JvmtiBreakpoint() + JvmtiBreakpoint::copy(JvmtiBreakpoint& bp) are replaced with copy ctor; > - JvmtiBreakpoints::clearall_in_class_at_safepoint() is simplified to do a single pass; > > Testing: tier1..tier6 This pull request has now been integrated. Changeset: 471f112b Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/471f112bca715d04304cbe35c6ed63df8c7b7fee Stats: 352 lines in 2 files changed: 27 ins; 284 del; 41 mod 8342577: Clean up JVMTI breakpoint support 8210637: Race in JvmtiCurrentBreakpoints::get_jvmti_breakpoints Reviewed-by: cjplummer, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/21675 From pchilanomate at openjdk.org Tue Nov 5 23:55:53 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 23:55:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 20:55:07 GMT, Serguei Spitsyn wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision: >> >> - Update comment block in objectMonitor.cpp >> - Fix issue with unmounted virtual thread when dumping heap >> - Remove ThawBase::possibly_adjust_frame() > > src/hotspot/share/runtime/continuation.cpp line 134: > >> 132: return true; >> 133: } >> 134: #endif // INCLUDE_JVMTI > > Could you, please, consider the simplification below? > > > #if INCLUDE_JVMTI > // return true if started vthread unmount > bool jvmti_unmount_begin(JavaThread* target) { > assert(!target->is_in_any_VTMS_transition(), "must be"); > > // Don't preempt if there is a pending popframe or earlyret operation. This can > // be installed in start_VTMS_transition() so we need to check it here. > if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { > JvmtiThreadState* state = target->jvmti_thread_state(); > if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { > return false; > } > } > // Don't preempt in case there is an async exception installed since > // we would incorrectly throw it during the unmount logic in the carrier. > if (target->has_async_exception_condition()) { > return false; > } > if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { > JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); > } else { > target->set_is_in_VTMS_transition(true); > // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) > } > return false; > } > > static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { > if (target->is_in_VTMS_transition()) { > // We caught target at the end of a mount transition. > return false; > } > return true; > } > #endif // INCLUDE_JVMTI > ... > static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { > assert(java_lang_VirtualThread::is_instance(vthread), ""); > if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition > return false; > } > return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); > } > ... > int Continuation::try_preempt(JavaThread* target, oop continuation) { > verify_preempt_preconditions(target, continuation); > > if (LockingMode == LM_LEGACY) { > return freeze_unsupported; > } > if (!is_safe_vthread_to_preempt(target, target->vthread())) { > return freeze_pinned_native; > } > JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) > int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); > log_trace(continuations, preempt)("try_preempt: %d", res); > return res; > } > > > The following won't be needed: > > target->set_pending_jvmti_unmou... Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830220838 From pchilanomate at openjdk.org Tue Nov 5 23:55:53 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 5 Nov 2024 23:55:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:50:29 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuation.cpp line 134: >> >>> 132: return true; >>> 133: } >>> 134: #endif // INCLUDE_JVMTI >> >> Could you, please, consider the simplification below? >> >> >> #if INCLUDE_JVMTI >> // return true if started vthread unmount >> bool jvmti_unmount_begin(JavaThread* target) { >> assert(!target->is_in_any_VTMS_transition(), "must be"); >> >> // Don't preempt if there is a pending popframe or earlyret operation. This can >> // be installed in start_VTMS_transition() so we need to check it here. >> if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { >> JvmtiThreadState* state = target->jvmti_thread_state(); >> if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { >> return false; >> } >> } >> // Don't preempt in case there is an async exception installed since >> // we would incorrectly throw it during the unmount logic in the carrier. >> if (target->has_async_exception_condition()) { >> return false; >> } >> if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { >> JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); >> } else { >> target->set_is_in_VTMS_transition(true); >> // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) >> } >> return false; >> } >> >> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { >> if (target->is_in_VTMS_transition()) { >> // We caught target at the end of a mount transition. >> return false; >> } >> return true; >> } >> #endif // INCLUDE_JVMTI >> ... >> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { >> assert(java_lang_VirtualThread::is_instance(vthread), ""); >> if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition >> return false; >> } >> return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); >> } >> ... >> int Continuation::try_preempt(JavaThread* target, oop continuation) { >> verify_preempt_preconditions(target, continuation); >> >> if (LockingMode == LM_LEGACY) { >> return freeze_unsupported; >> } >> if (!is_safe_vthread_to_preempt(target, target->vthread())) { >> return freeze_pinned_native; >> } >> JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) >> int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); >> log_trace(con... > > Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 > We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. > Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830222411 From pchilanomate at openjdk.org Wed Nov 6 00:08:16 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 00:08:16 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v32] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/124efa0a..c0c7e6cf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=30-31 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Wed Nov 6 00:08:16 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 00:08:16 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 11:35:29 GMT, Serguei Spitsyn wrote: > Is this posted after the VirtualThreadMount extension event posted? > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830225909 From pchilanomate at openjdk.org Wed Nov 6 00:08:16 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 00:08:16 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:58:39 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1643: >> >>> 1641: // actual callee (see nmethod::preserve_callee_argument_oops()). >>> 1642: ThreadOnMonitorWaitedEvent tmwe(current); >>> 1643: JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out); >> >> We post a JVMTI `MonitorWaited` event here for a virtual thread. >> A couple of questions on this: >> - Q1: Is this posted after the `VirtualThreadMount` extension event posted? >> Unfortunately, it is not easy to make this conclusion. >> - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801. >> Does it post the `MonitorWaited` event for this virtual thread as well? >> If not, then it is not clear how posting for virtual thread is avoided. > >> Is this posted after the VirtualThreadMount extension event posted? >> > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 > The JvmtiExport::post_monitor_waited() is called at the line 1801. > Does it post the MonitorWaited event for this virtual thread as well? > That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830227475 From pchilanomate at openjdk.org Wed Nov 6 00:08:17 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 00:08:17 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 14:35:11 GMT, Axel Boldt-Christmas wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision: >> >> - Add oopDesc::has_klass_gap() check >> - Rename waitTimeout/set_waitTimeout accessors >> - Revert suggestion to ThawBase::new_stack_frame >> - Improve JFR pinned reason in event >> - Use freeze_result consistently > > src/hotspot/share/runtime/objectMonitor.inline.hpp line 50: > >> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) { >> 49: int64_t tid = java_lang_Thread::thread_id(vthread); >> 50: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); > > Suggestion: > > assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable"); Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830229529 From dholmes at openjdk.org Wed Nov 6 01:00:45 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 01:00:45 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > fix: jvm_md.h was included, but not jvm.h... I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! src/hotspot/os/windows/os_windows.cpp line 510: > 508: // Thread start routine for all newly created threads. > 509: // Called with the associated Thread* as the argument. > 510: static unsigned thread_native_entry(void* t) { Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`. https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170 ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2417056020 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1830259353 From amenkov at openjdk.org Wed Nov 6 01:47:45 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 6 Nov 2024 01:47:45 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 00:58:10 GMT, David Holmes wrote: > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170 `On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.` ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458534929 From syan at openjdk.org Wed Nov 6 02:49:59 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 6 Nov 2024 02:49:59 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java Message-ID: Hi all, To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java ------------- Commit messages: - 8343244: Problemlist AttachTest.java and TestZPageAllocationEvent.java Changes: https://git.openjdk.org/jdk/pull/21917/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21917&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343505 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21917/head:pull/21917 PR: https://git.openjdk.org/jdk/pull/21917 From jwaters at openjdk.org Wed Nov 6 04:43:42 2024 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 6 Nov 2024 04:43:42 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov wrote: > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! To my knowledge the only thing __cdecl and __stdcall do is affect the argument passing on the stack since 32 bit uses the stack to pass arguments. Since 64 bit passes arguments inside registers and then only later uses the stack if there are too many parameters to fit in the parameter registers (Basically permanent __fastcall), these specifiers are probably ignored in all 64 bit platforms ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458712195 From dholmes at openjdk.org Wed Nov 6 04:55:34 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 04:55:34 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: <1KCOK7hSTz6122-AErD-x4tjyCx7xvdymzVHlLOpO-4=.8e39cde5-969d-4ee0-9af0-262c1844a1e9@github.com> On Tue, 5 Nov 2024 01:10:37 GMT, Ioi Lam wrote: > I've been using AOT in class names and aot in function/variable names. I think that's consistent with HotSpot convention. As an acronym I think AOT in capitals should be preferred even in function/variable names. > In logging, I've been using "aot" as logging seems to favor lowercase. Yes log tags seem to be always lower-case, by convention. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2458722622 From dholmes at openjdk.org Wed Nov 6 05:19:28 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 05:19:28 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 15:29:49 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore previous behaviour for zero length strings > > src/hotspot/share/utilities/exceptions.cpp line 264: > >> 262: // will be within reasonable limits - specifically we will never hit the INT_MAX limit >> 263: // of os::vsnprintf when it tries to report how big a buffer is needed. Even so we >> 264: // further limit the formatted output to 1024 characters. > > If we're chopping off the message at 1024 characters, why do we have to audit the callers? Is it because vsnprintf will overflow before truncating the message? Seems like it could be easy to add a caller that breaks this. There's no way to check here? Thanks for looking at this @coleenp . Yes it is because vsnprintf will try to tell you how big a buffer you would actually need when you pass a smaller size buffer. There is no way to know how big the formatted message would be without actually expanding it - which of course is only done by vsnprintf. So this comes down to doing a basic audit like this and then remembering to pay attention with new code. The alternative would be to define some global max string size, like the 1024 used here, and then have every caller of `fthrow` use `%*s` passing that max. But that is extremely intrusive if you look at how we end up calling `fthrow`. We have code in the classfile parser/error code where one function creates the message with the `%s` and a lower function actually supplies the argument. It is doable, but it is a lot of code churn to put up a safety rail that this code can't run into anyway. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21867#discussion_r1830400893 From dholmes at openjdk.org Wed Nov 6 05:32:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 05:32:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v32] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 00:08:16 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417279456 From dholmes at openjdk.org Wed Nov 6 05:55:47 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 05:55:47 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <91oCFKrjKmyjkaT3dBRRcpao4NNde2DXg39vjvBn7Wk=.893ab420-92f3-4bda-8744-4a801a07f95c@github.com> On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov wrote: > On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; @alexmenkov and @TheShermanTanker , I stand corrected and my apologies to @magicus . ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458778303 From aboldtch at openjdk.org Wed Nov 6 06:39:55 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 6 Nov 2024 06:39:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v32] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 00:08:16 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() Good work! I'll approve the GC related changes. There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR. Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what. You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre. A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. // the sp of the oldest known interpreted/call_stub frame inside the // continuation that we know about ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417363171 From iklam at openjdk.org Wed Nov 6 06:48:33 2024 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 6 Nov 2024 06:48:33 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: <1KCOK7hSTz6122-AErD-x4tjyCx7xvdymzVHlLOpO-4=.8e39cde5-969d-4ee0-9af0-262c1844a1e9@github.com> References: <1KCOK7hSTz6122-AErD-x4tjyCx7xvdymzVHlLOpO-4=.8e39cde5-969d-4ee0-9af0-262c1844a1e9@github.com> Message-ID: On Wed, 6 Nov 2024 04:52:56 GMT, David Holmes wrote: > > I've been using AOT in class names and aot in function/variable names. I think that's consistent with HotSpot convention. > > As an acronym I think AOT in capitals should be preferred even in function/variable names. I searched for "GC" vs "gc" and "JVMTI" vs "jvmti" in function names. Almost all of them are in lower cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2458836253 From dholmes at openjdk.org Wed Nov 6 06:58:28 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 06:58:28 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 02:39:24 GMT, SendaoYan wrote: > Hi all, > To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java Thanks. test/jdk/ProblemList.txt line 779: > 777: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id0 8343244 linux-aarch64,linux-ppc64le > 778: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 8343244 linux-aarch64,linux-ppc64le > 779: jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java 8343244 linux-aarch64,linux-ppc64le @sendaoYan we have also seen these crashes on x64, so I think it just needs to be linux-all test/jdk/ProblemList.txt line 779: > 777: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id0 8343244 linux-aarch64,linux-ppc64le > 778: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 8343244 linux-aarch64,linux-ppc64le > 779: jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java 8343244 linux-aarch64,linux-ppc64le Also IIUC the JFR test only failed with non-generational ZGC which has now been removed. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21917#pullrequestreview-2417385525 PR Review Comment: https://git.openjdk.org/jdk/pull/21917#discussion_r1830476631 PR Review Comment: https://git.openjdk.org/jdk/pull/21917#discussion_r1830478623 From syan at openjdk.org Wed Nov 6 08:11:07 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 6 Nov 2024 08:11:07 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java [v2] In-Reply-To: References: Message-ID: > Hi all, > To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java SendaoYan has updated the pull request incrementally with one additional commit since the last revision: 1. change os-arch to linux-all; 2. delete jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java from Problemlist ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21917/files - new: https://git.openjdk.org/jdk/pull/21917/files/34226ebb..43a067aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21917&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21917&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21917/head:pull/21917 PR: https://git.openjdk.org/jdk/pull/21917 From syan at openjdk.org Wed Nov 6 08:11:08 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 6 Nov 2024 08:11:08 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java [v2] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 06:55:41 GMT, David Holmes wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. change os-arch to linux-all; 2. delete jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java from Problemlist > > test/jdk/ProblemList.txt line 779: > >> 777: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id0 8343244 linux-aarch64,linux-ppc64le >> 778: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 8343244 linux-aarch64,linux-ppc64le >> 779: jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java 8343244 linux-aarch64,linux-ppc64le > > Also IIUC the JFR test only failed with non-generational ZGC which has now been removed. The test of `jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java` was removed ZGC option `-XX:-ZGenerational` and `-XX:+ZGenerational`. I have no idea that the crash of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) was trigger by `-XX:+UseZGC -XX:-ZGenerational` or just by `-XX:+UseZGC`. Anyway, remove `jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java` from this Problemlist maybe a good option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21917#discussion_r1830546518 From syan at openjdk.org Wed Nov 6 08:23:06 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 6 Nov 2024 08:23:06 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java [v3] In-Reply-To: References: Message-ID: <-xKdgBq3DVjEOtxFMtB30AQxQsvFxGzf9_R3IspfFJk=.6ed943b8-f866-4a67-a9fa-9b4d30300ae8@github.com> > Hi all, > To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java SendaoYan has updated the pull request incrementally with one additional commit since the last revision: change os-arch to generic-all ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21917/files - new: https://git.openjdk.org/jdk/pull/21917/files/43a067aa..ef3306bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21917&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21917&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21917/head:pull/21917 PR: https://git.openjdk.org/jdk/pull/21917 From alanb at openjdk.org Wed Nov 6 08:23:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 08:23:06 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java [v2] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 08:11:07 GMT, SendaoYan wrote: >> Hi all, >> To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > 1. change os-arch to linux-all; 2. delete jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java from Problemlist test/jdk/ProblemList.txt line 778: > 776: > 777: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id0 8343244 linux-all > 778: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 8343244 linux-all yes, I think we have to temporarily exclude this test as it is failing frequently. The jdk_lang section of ProblemList is where java/lang/* tests are usually excluded. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21917#discussion_r1830566215 From syan at openjdk.org Wed Nov 6 08:23:06 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 6 Nov 2024 08:23:06 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java [v3] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 06:53:34 GMT, David Holmes wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> change os-arch to generic-all > > test/jdk/ProblemList.txt line 779: > >> 777: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id0 8343244 linux-aarch64,linux-ppc64le >> 778: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 8343244 linux-aarch64,linux-ppc64le >> 779: jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java 8343244 linux-aarch64,linux-ppc64le > > @sendaoYan we have also seen these crashes on x64, so I think it just needs to be linux-all @dholmes-ora The os-arch tag has been change to `generic-all` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21917#discussion_r1830563138 From syan at openjdk.org Wed Nov 6 08:39:08 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 6 Nov 2024 08:39:08 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java [v4] In-Reply-To: References: Message-ID: > Hi all, > To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java SendaoYan has updated the pull request incrementally with one additional commit since the last revision: move to jdk_lang section ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21917/files - new: https://git.openjdk.org/jdk/pull/21917/files/ef3306bc..6ab1fb17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21917&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21917&range=02-03 Stats: 5 lines in 1 file changed: 2 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21917.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21917/head:pull/21917 PR: https://git.openjdk.org/jdk/pull/21917 From syan at openjdk.org Wed Nov 6 08:39:08 2024 From: syan at openjdk.org (SendaoYan) Date: Wed, 6 Nov 2024 08:39:08 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java [v2] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 08:19:42 GMT, Alan Bateman wrote: >> SendaoYan has updated the pull request incrementally with one additional commit since the last revision: >> >> 1. change os-arch to linux-all; 2. delete jdk/jfr/event/gc/detailed/TestZPageAllocationEvent.java from Problemlist > > test/jdk/ProblemList.txt line 778: > >> 776: >> 777: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id0 8343244 linux-all >> 778: java/lang/Thread/jni/AttachCurrentThread/AttachTest.java#id1 8343244 linux-all > > yes, I think we have to temporarily exclude this test as it is failing frequently. The jdk_lang section of ProblemList is where java/lang/* tests are usually excluded. Thanks for the correction. The test list has been move to jdk_lang section. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21917#discussion_r1830587554 From stuefe at openjdk.org Wed Nov 6 09:13:47 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Nov 2024 09:13:47 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v50] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 16:43:35 GMT, Roman Kennke wrote: >> @egahlin / @mgronlun could you please review the JFR parts of this PR? One change is for getting the right prototype header, the other is for avoiding an endless loop/assert in a corner case. > >> @rkennke can you include this small update for s390x as well: >> >> ```diff >> diff --git a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp >> index 0f7e5c9f457..476e3d5daa4 100644 >> --- a/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp >> +++ b/src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp >> @@ -174,8 +174,11 @@ void C1_MacroAssembler::try_allocate( >> void C1_MacroAssembler::initialize_header(Register obj, Register klass, Register len, Register Rzero, Register t1) { >> assert_different_registers(obj, klass, len, t1, Rzero); >> if (UseCompactObjectHeaders) { >> - z_lg(t1, Address(klass, in_bytes(Klass::prototype_header_offset()))); >> - z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes())); >> + z_mvc( >> + Address(obj, oopDesc::mark_offset_in_bytes()), /* move to */ >> + Address(klass, in_bytes(Klass::prototype_header_offset())), /* move from */ >> + sizeof(markWord) /* how much to move */ >> + ); >> } else { >> load_const_optimized(t1, (intx)markWord::prototype().value()); >> z_stg(t1, Address(obj, oopDesc::mark_offset_in_bytes())); >> diff --git a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp >> index 378d5e4cfe1..c5713161bf9 100644 >> --- a/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp >> +++ b/src/hotspot/cpu/s390/c2_MacroAssembler_s390.cpp >> @@ -46,7 +46,7 @@ void C2_MacroAssembler::load_narrow_klass_compact_c2(Register dst, Address src) >> // The incoming address is pointing into obj-start + klass_offset_in_bytes. We need to extract >> // obj-start, so that we can load from the object's mark-word instead. >> z_lg(dst, src.plus_disp(-oopDesc::klass_offset_in_bytes())); >> - z_srlg(dst, dst, markWord::klass_shift); // TODO: could be z_sra >> + z_srlg(dst, dst, markWord::klass_shift); >> } >> >> //------------------------------------------------------ >> diff --git a/src/hotspot/cpu/s390/templateTable_s390.cpp b/src/hotspot/cpu/s390/templateTable_s390.cpp >> index 3cb1aba810d..5b8f7a20478 100644 >> --- a/src/hotspot/cpu/s390/templateTable_s390.cpp >> +++ b/src/hotspot/cpu/s390/templateTable_s390.cpp >> @@ -3980,8 +3980,11 @@ void TemplateTable::_new() { >> // Initialize object header only. >> __ bind(initialize_header); >> if (UseCompactObjectHeaders) { >> - __ z_lg(tmp, Address(iklass, in_bytes(Klass::prototype_header_offset()))); >> - __ z_stg(tmp, Address(RallocatedObject, oo... Merge is good. @rkennke patch for the new test errors due to removal of non-generational ZGC: https://gist.github.com/tstuefe/321b769d3b281198b767b68e18bb7271 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2459069232 From rkennke at openjdk.org Wed Nov 6 09:13:46 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 6 Nov 2024 09:13:46 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v55] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Fix gen-ZGC removal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20677/files - new: https://git.openjdk.org/jdk/pull/20677/files/b945822a..1ea4de16 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=54 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=53-54 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From stuefe at openjdk.org Wed Nov 6 09:15:11 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Nov 2024 09:15:11 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 04:40:24 GMT, Julian Waters wrote: > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! stdcall and cdecl are 32-bit Windows calling conventions. On x64 and arm64, as on all other platforms we support, there is just one calling convention. See https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention. I am sure __stdcall is ignored by the compiler on x64 or arm64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2459078526 From stuefe at openjdk.org Wed Nov 6 09:15:12 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 6 Nov 2024 09:15:12 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 09:12:02 GMT, Thomas Stuefe wrote: > > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit! > > stdcall and cdecl are 32-bit Windows calling conventions. On x64 and arm64, as on all other platforms we support, there is just one calling convention. See https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention. > > I am sure __stdcall is ignored by the compiler on x64 or arm64. Never mind my noise, other people did already answer this :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2459080708 From alanb at openjdk.org Wed Nov 6 09:26:55 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 09:26:55 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo wrote: >>> Is this posted after the VirtualThreadMount extension event posted? >>> >> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 > >> The JvmtiExport::post_monitor_waited() is called at the line 1801. >> Does it post the MonitorWaited event for this virtual thread as well? >> > That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor. Just to add that the 2 extension events (VirtualThreadMount and VirtualThreadUnmount) are not part of any supported/documented interface. They are a left over from the exploration phase of virtual threads when we assumed the debugger agent would need to track the transitions. So at some point I think we need to figure out how to make them go away as they are an attractive nuisance (esp. if the event callback were to upcall and execute Java code). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830657204 From kevinw at openjdk.org Wed Nov 6 11:46:30 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 6 Nov 2024 11:46:30 GMT Subject: RFR: 8343344: Windows attach logic failed to handle a failed open on a pipe [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 21:00:07 GMT, Alex Menkov wrote: >> The fix adds correct handling of "could not open pipe" errors in attach listener instead of assert which causes target VM crash. >> >> testing: tier1,tier2,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback Thanks Alex, looks good. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21888#pullrequestreview-2418049802 From ihse at openjdk.org Wed Nov 6 15:21:10 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 6 Nov 2024 15:21:10 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Remove FIXME ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/9b10e74c..de3c773a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=29-30 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Wed Nov 6 15:21:10 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 6 Nov 2024 15:21:10 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <1C4ITw6Oql1qCggf80rAZ73NIjGNwdYQzWHUfb_8LLE=.0140fca3-d921-4ec3-bd82-1f9cf7bb0a31@github.com> On Tue, 5 Nov 2024 16:28:04 GMT, Kim Barrett wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> fix: jvm_md.h was included, but not jvm.h... > > src/hotspot/os/windows/os_windows.cpp line 5820: > >> 5818: } >> 5819: >> 5820: // FIXME > > ??? I apologize this slipped through. It was a marker for myself which I added when searching for code that did _stdcall name mangling operations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831227000 From ihse at openjdk.org Wed Nov 6 15:29:49 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 6 Nov 2024 15:29:49 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com> On Tue, 5 Nov 2024 08:58:00 GMT, Kim Barrett wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> fix: jvm_md.h was included, but not jvm.h... > > src/hotspot/os/windows/os_windows.cpp line 5863: > >> 5861: return nullptr; >> 5862: } >> 5863: > > [pre-existing, and can't comment on line 5858 because it's not sufficiently near a change.] > The calculation of `len` is wasting a byte when `lib_name` is null. The `+2` accounts for the > terminating `NUL` and the underscore separator between the sym_name part and the lib_name > part. That underscore isn't added when there isn't a lib_name part. I think the simplest fix would > be to change `name_len` to `(name_len +1)` and `+2` to `+1` in that calculation. And add some > commentary. > > This might be deemed not worth fixing as there is likely often no actual wastage, due to alignment > padding, and it slightly further complicates the calculation. But additional commentary would still > be desirable, to guide the next careful reader. In which case it might be simpler to describe the > fixed version. > > Since this is pre-existing and relatively harmless in execution, it can be addressed in a followup > change. I've created https://bugs.openjdk.org/browse/JDK-8343703 for this, amongst other things. > src/hotspot/share/include/jvm.h line 1165: > >> 1163: #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> 1164: #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> 1165: #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > There is more cleanup that can be done here. These definitions are used as > array initializers (hence the surrounding curly braces). They are now always > singleton, rather than sometimes having 2 elements. The uses iterate over the > now always singleton arrays. Those iterations are no longer needed and could > be eliminated. And these macros could be eliminated, using the corresponding > string directly in each use. This can all be done as a followup change. Handled by https://bugs.openjdk.org/browse/JDK-8343703. > src/java.base/share/native/libjava/NativeLibraries.c line 67: > >> 65: strcat(jniEntryName, "_"); >> 66: strcat(jniEntryName, cname); >> 67: } > > I would prefer this be directly inlined at the sole call (in findJniFunction), > to make it easier to verify there aren't any buffer overrun problems. (I don't > think there are, but looking at this in isolation triggered warnings in my > head.) > > Also, it looks like all callers of findJniFunction ensure the cname argument > is non-null. So there should be no need to handle the null case in > findJniFunction (other than perhaps an assert or something). That could be > addressed in a followup. (I've already implicitly suggested elsewhere in this > PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS > thing.) @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831240264 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831240942 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831243370 From sspitsyn at openjdk.org Wed Nov 6 16:00:59 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 16:00:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman wrote: > So at some point I think we need to figure out how to make them go away ... Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes. > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor... The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though. > That's the path a virtual thread will take if pinned. Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831293112 From sspitsyn at openjdk.org Wed Nov 6 16:34:54 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 16:34:54 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v29] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo wrote: >> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 >> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. >> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. > > Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. > For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. > When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. > > [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks. > but does the specs say the event has to be posted in the context of the vthread? As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context. > For pop_frame/early_ret checks ... The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. > Maybe we could go with this simplified code now and work on it later... Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this. It would be nice to fix a couple of nits though: - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark` - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831367766 From cjplummer at openjdk.org Wed Nov 6 17:37:29 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 6 Nov 2024 17:37:29 GMT Subject: RFR: 8343344: Windows attach logic failed to handle a failed open on a pipe [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 21:00:07 GMT, Alex Menkov wrote: >> The fix adds correct handling of "could not open pipe" errors in attach listener instead of assert which causes target VM crash. >> >> testing: tier1,tier2,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21888#pullrequestreview-2419011277 From pchilanomate at openjdk.org Wed Nov 6 17:39:18 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:39:18 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning Message-ID: This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. In order to make the code review easier the changes have been split into the following initial 4 commits: - Changes to allow unmounting a virtual thread that is currently holding monitors. - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. - Changes to tests, JFR pinned event, and other changes in the JDK libraries. The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. ## Summary of changes ### Unmount virtual thread while holding monitors As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. #### General notes about this part: - Since virtual threads don't need to worry about holding monitors anymore, we don't need to count them, except for `LM_LEGACY`. So the majority of the platform dependent changes in this commit have to do with correcting this. - Zero and x86 (32 bits) where counting monitors even though they don't implement continuations, so I fixed that to stop counting. The idea is to remove all the counting code once we remove `LM_LEGACY`. - Macro `LOOM_MONITOR_SUPPORT` was added at the time to exclude ports that implement continuations but don't yet implement monitor support. It is removed later with the ppc commit changes. - Since now a virtual thread can be unmounted while holding monitors, JVMTI methods `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` had to be adapted. #### Notes specific to the tid changes: - The tid is cached in the JavaThread object under `_lock_id`. It is set on JavaThread creation and changed on mount/unmount. - Changes in the ObjectMonitor class in this commit are pretty much exclusively related to changing `_owner` and `_succ` from `void*` and `JavaThread*` respectively to `int64_t`. - Although we are not trying to fix `LM_LEGACY` the tid changes apply to it as well since the inflated path is shared. Thus, in case of inflation by a contending thread, the `BasicLock*` cannot be stored in the `_owner` field as before. The `_owner` is instead set to anonymous as we do in `LM_LIGHTWEIGHT`, and the `BasicLock*` is stored in the new field `_stack_locker`. - We already assume 32 bit platforms can handle 64 bit atomics, including `cmpxchg` ([JDK-8318776](https://bugs.openjdk.org/browse/JDK-8318776)) so the shared code can stay the same. The assembly code for the c2 fast paths has to be adapted though. On arm (32bits) we already jump directly to the slow path on inflated monitor case so there is nothing to do. For x86 (32bits), since the port is moving towards deprecation ([JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285)) there is no point in trying to optimize, so the code was changed to do the same thing we do for arm (32bits). ### Unmounting a virtual thread blocked on synchronized Currently virtual thread unmounting is always started from Java, either because of a voluntarily call to `Thread.yield()` or because of performing some blocking operation such as I/O. Now we allow to unmount from inside the VM too, specifically when facing contention trying to acquire a Java monitor. On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic. Once the owner releases the monitor and selects it as the next successor the virtual thread will be added again to the scheduler queue to run again. The virtual thread will run and attempt to acquire the monitor again. If it succeeds then it will thaw frames as usual to continue execution back were it left off. If it fails it will unmount and wait again to be unblocked. #### General notes about this part: - The easiest way to review these changes is to start from the monitorenter call in the interpreter and follow all the flow of the virtual thread, from unmounting to running again. - Currently we use a dedicated unblocker thread to submit the virtual threads back to the scheduler queue. This avoids calls to Java from monitorexit. We are experimenting on removing this limitation, but that will be left as an enhancement for a future change. - We cannot unmount the virtual thread when the monitor enter call is coming from `jni_enter()` or `ObjectLocker` since we would need to freeze native frames. - If freezing fails, which almost always will be due to having native frames on the stack, the virtual thread will follow the normal platform thread logic but will do a timed-park instead. This is to alleviate some deadlocks cases where the successor picked is an unmounted virtual thread that cannot run, which can happen during class loading or class initiatialization. - After freezing all frames, and while adding itself to the `_cxq` the virtual thread could?have successfully acquired the monitor. In that case we mark the preemption as cancelled. The virtual thread will still need to go back to the preempt stub to cleanup the physical stack but instead of unmounting it will call thaw to continue execution. - The way we jump to the preempt stub is slightly different in the compiler and interpreter. For the compiled case we just patch a return address, so no new code is added. For the interpreter we cannot do this on all platforms so we just check a flag back in the interpreter. For the latter we also need to manually restore some state after we finally acquire the monitor and resume execution. All that logic is contained in new assembler method `call_VM_preemptable()`. #### Notes specific to JVMTI changes: - Since we are not unmounting from Java, there is no call to `VirtualThread.yieldContinuation()`. This means that we have to execute the equivalent of `notifyJvmtiUnmount(/*hide*/true)` for unmount, and of `notifyJvmtiMount(/*hide*/false)` for mount in the VM. The former is implemented with `JvmtiUnmountBeginMark` in `Continuation::try_preempt()`. The latter is implemented in method `jvmti_mount_end()` in `ContinuationFreezeThaw` at the end of thaw. - When unmounting from Java the vthread unmount event is posted before we try to freeze the continuation. If that fails then we post the mount event. This all happens in `VirtualThread.yieldContinuation()`. When unmounting from the VM we only post the event once we know the freeze succeeded. Since at that point we are in the middle of the VTMS transition, posting the event is done in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()` after the transition finishes. Maybe the same thing should be done when unmounting from Java. ### Unmounting a virtual thread blocked on `Object.wait()` This commit just extends the previous mechanism to be able to unmount inside the VM on `ObjectMonitor::wait`. #### General notes about this part: - The mechanism works as before with the difference that now the call will come from the native wrapper. This requires to add support to the continuation code to handle native wrapper frames, which is a main part of the changes in this commit. - Both the compiled and interpreted native wrapper code will check for preemption on return from the wait call, after we have transitioned back to `_thread_in_Java`. #### Note specific to JVMTI changes: - If the monitor waited event is enabled we need to post it after the wait is done but before re-acquiring the monitor. Since the virtual thread is inside the VTMS transition at that point, we cannot do that directly. Currently in the code we end the transition, post the event and start the transition again. This is not ideal, and maybe we should unmount, post the event and then run again to try reacquire the monitor. ### Test changes + JFR Updates + Library code changes #### Tests - The tests in `java/lang/Thread/virtual` are updated to add more tests for monitor enter/exit and Object.wait/notify. New tests are added for JFR events, synchronized native methods, and stress testing for several scenarios. - `test/hotspot/gtest/nmt/test_vmatree.cpp` is changed due to an alias that conflicts. - A small number of tests, e.g.` test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java` and `test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002`, are updated so they are in sync with the JDK code. - A number of JVMTI tests are updated to fix various issues, e.g. some tests saved a JNIEnv in a static. #### Diagnosing remaining pinning issues - The diagnostic option `jdk.tracePinnedThreads` is removed. - The JFR `jdk.VirtualThreadPinned` event is changed so that it's now recorded in the VM, and for the following cases: parking when pinned, blocking in monitor enter when pinned, Object.wait when pinned, and waiting for a class to be initialized by another thread. The changes to object monitors should mean that only a few events are recorded. Future work may change this to a sampling approach. #### Other changes to VirtualThread class The VirtualThread implementation includes a few robustness changes. The `park/parkNanos` methods now park on the carrier if the freeze throws OOME. Moreover, the use of transitions is reduced so that the call out to the scheduler no longer requires a temporary transition. #### Other changes to libraries: - `ReferenceQueue` is reverted to use `synchronized`, the subclass based on `ReentrantLock` is removed. This change is done now because the changes for object monitors impact this area when there is preemption polling a reference queue. - `java.io` is reverted to use `synchronized`. This change has been important for testing virtual threads. There will be follow-up cleanup in main-line after the JEP is integrated to remove `InternalLock` and its uses in `java.io`. - The epoll and kqueue based Selectors are changed to preempt when doing blocking selects. This has been useful for testing virtual threads with some libraries, e.g. JDBC drivers. We could potentially separate this update if needed but it has been included in all testing and EA builds. - `sun.security.ssl.X509TrustManagerImpl` is changed to eagerly initialize AnchorCertificates, a forced change due to deadlocks in this code when testing. ## Testing The changes have been running in the Loom pipeline for several months now. They have also been included in EA builds throughout the year at different stages (EA builds from earlier this year did not had Object.wait() support yet but more recent ones did) so there has been some external exposure too. The current patch has been run through mach5 tiers 1-8. I'll keep running tests periodically until integration time. ------------- Commit messages: - Use is_top_frame boolean in FreezeBase::check_valid_fast_path() - Move load of _lock_id in C2_MacroAssembler::fast_lock - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java - Update comment for _cont_fastpath - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() - Fixes to JFR metadata.xml - Fix return miss prediction in generate_native_entry for riscv - Fix s390x failures - Add oopDesc::has_klass_gap() check - ... and 70 more: https://git.openjdk.org/jdk/compare/751a914b...211c6c81 Changes: https://git.openjdk.org/jdk/pull/21565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338383 Stats: 9914 lines in 246 files changed: 7105 ins; 1629 del; 1180 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From aboldtch at openjdk.org Wed Nov 6 17:39:21 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 6 Nov 2024 17:39:21 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I've done an initial look through of the hotspot changes. In addition to my comments, I have looked at two more things. One is to remove the _waiters reference counter from deflation and only use the _contentions reference counter. As well as tying the _contentions reference counter to the ObjectWaiter, so that it is easier to follow its lifetime, instead of these naked add_to_contentions, now that the ObjectWaiter does not have a straight forward scope, but can be frozen, and thawed on different threads. 46dacdf96999154e808d21e80b4d4e87f73bc802 Then I looked at typing up the thread / lock ids as an enum class 34221f4a50a492cad4785cfcbb4bef8fa51d6f23 Either of these could be future RFEs. Good work! I'll approve the GC related changes. There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR. Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what. You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre. A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. // the sp of the oldest known interpreted/call_stub frame inside the // continuation that we know about src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231: > 229: > 230: StubFrame::~StubFrame() { > 231: __ epilogue(_use_pop_on_epilogue); Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return? e.g. ```C++ enum return_state_t { does_not_return, requires_return, requires_pop_epilogue_return }; StubFrame::~StubFrame() { if (_return_state == does_not_return) { __ should_not_reach_here(); } else { __ epilogue(_return_state == requires_pop_epilogue_return); } } src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115: > 113: // The object's monitor m is unlocked iff m->owner == nullptr, > 114: // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY, > 115: // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT. Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380: > 378: lea(t2_owner_addr, owner_address); > 379: > 380: // CAS owner (null => current thread id). I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion) src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300: > 298: CodeBlob* cb = top.cb(); > 299: > 300: if (cb->frame_size() == 2) { Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size. src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313: > 311: > 312: log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT > 313: " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]); Is there a reason for the mix of `2` and `frame::metadata_words`? Maybe this could be ```C++ intptr_t* const unadjusted_sp = sp; sp -= frame::metadata_words; sp[-2] = unadjusted_sp[-2]; sp[-1] = unadjusted_sp[-1]; log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]); src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275: > 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) { > 1274: ::continuation_enter_cleanup(masm); > 1275: } Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function. src/hotspot/cpu/x86/assembler_x86.cpp line 2866: > 2864: emit_int32(0); > 2865: } > 2866: } Is it possible to make this more general and explicit instead of a sequence of bytes? Something along the lines of: ```C++ const address tar = L.is_bound() ? target(L) : pc(); const Address adr = Address(checked_cast(tar - pc()), tar, relocInfo::none); InstructionMark im(this); emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D); if (!L.is_bound()) { // Patch @0x8D opcode L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect())); } // Register and [rip+disp] operand emit_modrm(0b00, raw_encode(dst), 0b101); // Adjust displacement by sizeof lea instruction int32_t disp = adr.disp() - checked_cast(pc() - inst_mark() + sizeof(int32_t)); assert(is_simm32(disp), "must be 32bit offset [rip+offset]"); emit_int32(disp); and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`. src/hotspot/share/oops/stackChunkOop.cpp line 445: > 443: > 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) { > 445: const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw. src/hotspot/share/oops/stackChunkOop.cpp line 460: > 458: } else { > 459: oop value = *reinterpret_cast(at); > 460: HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). So either use `*reinterpret_cast(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless. src/hotspot/share/oops/stackChunkOop.cpp line 471: > 469: } > 470: } > 471: } Can we turn these three very similar loops into one? In my opinion, it is easier to parse. ```C++ void stackChunkOopDesc::copy_lockstack(oop* dst) { const int cnt = lockstack_size(); const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops; const auto get_obj = [&](intptr_t* at) -> oop { if (requires_gc_barriers) { if (requires_uncompress) { return HeapAccess<>::oop_load(reinterpret_cast(at)); } return HeapAccess<>::oop_load(reinterpret_cast(at)); } return *reinterpret_cast(at); }; intptr_t* lockstack_start = start_address(); for (int i = 0; i < cnt; i++) { oop mon_owner = get_obj(&lockstack_start[i]); assert(oopDesc::is_oop(mon_owner), "not an oop"); dst[i] = mon_owner; } } src/hotspot/share/prims/jvmtiExport.cpp line 1681: > 1679: EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread)); > 1680: > 1681: // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop. Suggestion: // On preemption JVMTI state rebinding has already happened so get it always directly from the oop. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234: > 2232: retry_fast_path = true; > 2233: } else { > 2234: relativize_chunk_concurrently(chunk); Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247: > 2245: _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize); > 2246: > 2247: chunk->set_lockstack_size(0); After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line. Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops. diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp index d3d63533eed..f737bd2db71 100644 --- a/src/hotspot/share/oops/stackChunkOop.cpp +++ b/src/hotspot/share/oops/stackChunkOop.cpp @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) { } } +void stackChunkOopDesc::clear_lockstack() { + const int cnt = lockstack_size(); + const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); + const bool requires_uncompress = has_bitmap() && UseCompressedOops; + const auto clear_obj = [&](intptr_t* at) { + if (requires_uncompress) { + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); + } else { + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); + } + }; + + if (requires_gc_barriers) { + intptr_t* lockstack_start = start_address(); + for (int i = 0; i < cnt; i++) { + clear_obj(&lockstack_start[i]); + } + } + set_lockstack_size(0); + set_has_lockstack(false); +} + void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const { if (*((juint*)this) == badHeapWordVal) { st->print_cr("BAD WORD"); diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp index 28e0576801e..928e94dd695 100644 --- a/src/hotspot/share/oops/stackChunkOop.hpp +++ b/src/hotspot/share/oops/stackChunkOop.hpp @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc { void fix_thawed_frame(const frame& f, const RegisterMapT* map); void copy_lockstack(oop* start); + void clear_lockstack(); template inline void iterate_lockstack(StackChunkLockStackClosureType* closure); diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp index 5b6e48a02f3..e7d505bb9b1 100644 --- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp +++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp @@ -2244,8 +2244,7 @@ NOINLINE intptr_t* Thaw::thaw_slow(stackChunkOop chunk, Continuation::t chunk->copy_lockstack(tmp_lockstack); _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize); - chunk->set_lockstack_size(0); - chunk->set_has_lockstack(false); + chunk->clear_lockstack(); retry_fast_path = true; } ``` src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538: > 2536: Method* m = hf.interpreter_frame_method(); > 2537: // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler). > 2538: const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2; Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places. src/hotspot/share/runtime/frame.cpp line 535: > 533: assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address"); > 534: return thread_addr; > 535: #endif With this ifdef, it seems like this belongs in the platform dependent part of the frame class. src/hotspot/share/runtime/javaThread.cpp line 1545: > 1543: if (is_vthread_mounted()) { > 1544: // _lock_id is the thread ID of the mounted virtual thread > 1545: st->print_cr(" Carrying virtual thread #" INT64_FORMAT, lock_id()); What is the interaction here with `switchToCarrierThread` and the window between? carrier.setCurrentThread(carrier); Thread.setCurrentLockId(this.threadId()); Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called). src/hotspot/share/runtime/objectMonitor.hpp line 184: > 182: // - We test for anonymous owner by testing for the lowest bit, therefore > 183: // DEFLATER_MARKER must *not* have that bit set. > 184: static const int64_t DEFLATER_MARKER = 2; The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch). src/hotspot/share/runtime/objectMonitor.hpp line 186: > 184: static const int64_t DEFLATER_MARKER = 2; > 185: > 186: int64_t volatile _owner; // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER. Suggestion: int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. src/hotspot/share/runtime/objectMonitor.inline.hpp line 50: > 48: inline int64_t ObjectMonitor::owner_from(oop vthread) { > 49: int64_t tid = java_lang_Thread::thread_id(vthread); > 50: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); Suggestion: assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable"); src/hotspot/share/runtime/synchronizer.cpp line 1467: > 1465: markWord dmw = inf->header(); > 1466: assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value()); > 1467: if (inf->is_owner_anonymous() && inflating_thread != nullptr) { Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze? src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: > 60: NATIVE(2, "Native frame or on stack"), > 61: MONITOR(3, "Monitor held"), > 62: CRITICAL_SECTION(4, "In critical section"); Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2381051930 Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417363171 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808181783 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808189977 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808208652 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808282892 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808261926 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808318304 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808358874 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825949756 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825942254 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808706427 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808809374 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810772765 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810764911 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808460330 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809032469 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809065834 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809091338 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809092367 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829464866 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809111830 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827276764 From dholmes at openjdk.org Wed Nov 6 17:39:47 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:39:47 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... First, congratulations on an exceptional piece of work @pchilano . Also thank you for the very clear breakdown and description in the PR as that helps immensely with trying to digest a change of this size. The overall operational behaviour of this change seems very solid. My only concern is whether the unparker thread may become a bottleneck in some scenarios, but that is a bridge we will have to cross if we come to it. My initial comments mainly come from just trying to understand the top-level changes around the use of the thread-id as the monitor owner. I have a number of suggestions on naming (mainly `is_x` versus `has_x`) and on documenting the API methods more clearly. None of which are showstoppers and some of which pre-exist. Unfortunately though you will need to fix the spelling of `succesor`. Thanks Thanks for those updates. Thanks for updates. (I need to add a Review comment so I get a checkpoint to track further updates.) Next batch of comments ... Updates look good - thanks. I think I have nothing further in terms of the review process. Great work! Marked as reviewed by dholmes (Reviewer). Marked as reviewed by dholmes (Reviewer). > The tid is cached in the JavaThread object under _lock_id. It is set on JavaThread creation and changed on mount/unmount. Why do we need to cache it? Is it the implicit barriers related to accessing the `threadObj` oop each time? Keeping this value up-to-date is a part I find quite confusing. src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382: > 2380: __ bind(after_transition); > 2381: > 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) { It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code? src/hotspot/share/classfile/javaClasses.cpp line 2082: > 2080: } > 2081: > 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) { Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? I'm struggling to understand how a thread can already be on this list? src/hotspot/share/classfile/javaClasses.cpp line 2086: > 2084: jboolean vthread_on_list = Atomic::load(addr); > 2085: if (!vthread_on_list) { > 2086: vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE); It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions? src/hotspot/share/classfile/javaClasses.cpp line 2107: > 2105: > 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { > 2107: return vthread->long_field(_timeout_offset); Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? src/hotspot/share/code/nmethod.cpp line 711: > 709: // handle the case of an anchor explicitly set in continuation code that doesn't have a callee > 710: JavaThread* thread = reg_map->thread(); > 711: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { Suggestion: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { src/hotspot/share/prims/jvm.cpp line 4012: > 4010: } > 4011: ThreadBlockInVM tbivm(THREAD); > 4012: parkEvent->park(); What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); > 888: } else { > 889: // frame can't be freezed. Most likely the call_stub or upcall_stub Suggestion: // Frame can't be frozen. Most likely the call_stub or upcall_stub src/hotspot/share/runtime/javaThread.hpp line 165: > 163: // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the > 164: // current _vthread object, except during creation of the primordial and JNI > 165: // attached thread cases where this field can have a temporal value. Suggestion: // attached thread cases where this field can have a temporary value. Presumably this is for when the attaching thread is executing the Thread constructor? src/hotspot/share/runtime/javaThread.hpp line 166: > 164: // current _vthread object, except during creation of the primordial and JNI > 165: // attached thread cases where this field can have a temporary value. Also, > 166: // calls to VirtualThread.switchToCarrierThread will temporary change _vthread s/temporary change/temporarily change/ src/hotspot/share/runtime/objectMonitor.cpp line 132: > 130: > 131: // ----------------------------------------------------------------------------- > 132: // Theory of operations -- Monitors lists, thread residency, etc: This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage src/hotspot/share/runtime/objectMonitor.cpp line 1140: > 1138: } > 1139: > 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) { Explanatory comment would be good - thanks. src/hotspot/share/runtime/objectMonitor.cpp line 1532: > 1530: } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) { > 1531: // Virtual thread case. > 1532: Trigger->unpark(); So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed? src/hotspot/share/runtime/objectMonitor.cpp line 1673: > 1671: > 1672: ContinuationEntry* ce = current->last_continuation(); > 1673: if (interruptible && ce != nullptr && ce->is_virtual_thread()) { So IIUC this use of `interruptible` would be explained as follows: // Some calls to wait() occur in contexts that still have to pin a vthread to its carrier. // All such contexts perform non-interruptible waits, so by checking `interruptible` we know // this is a regular Object.wait call. src/hotspot/share/runtime/objectMonitor.cpp line 1706: > 1704: // on _WaitSetLock so it's not profitable to reduce the length of the > 1705: // critical section. > 1706: Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't. src/hotspot/share/runtime/objectMonitor.cpp line 2028: > 2026: // First time we run after being preempted on Object.wait(). > 2027: // Check if we were interrupted or the wait timed-out, and in > 2028: // that case remove ourselves from the _WaitSet queue. I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to. src/hotspot/share/runtime/objectMonitor.cpp line 2054: > 2052: // Mark that we are at reenter so that we don't call this method again. > 2053: node->_at_reenter = true; > 2054: assert(!has_owner(current), "invariant"); The position of this assert seems odd as it seems to be something that should hold at entry to this method. src/hotspot/share/runtime/objectMonitor.hpp line 47: > 45: // ParkEvent instead. Beware, however, that the JVMTI code > 46: // knows about ObjectWaiters, so we'll have to reconcile that code. > 47: // See next_waiter(), first_waiter(), etc. This to-do is likely no longer relevant with the current changes. src/hotspot/share/runtime/objectMonitor.hpp line 174: > 172: > 173: int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. > 174: volatile uint64_t _previous_owner_tid; // thread id of the previous owner of the monitor Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ?? src/hotspot/share/runtime/objectMonitor.hpp line 207: > 205: > 206: static void Initialize(); > 207: static void Initialize2(); Please add comment why this needs to be deferred - and till after what? src/hotspot/share/runtime/objectMonitor.hpp line 288: > 286: // Returns true if this OM has an owner, false otherwise. > 287: bool has_owner() const; > 288: int64_t owner() const; // Returns null if DEFLATER_MARKER is observed. null is not an int64_t value. src/hotspot/share/runtime/objectMonitor.hpp line 292: > 290: > 291: static int64_t owner_for(JavaThread* thread); > 292: static int64_t owner_for_oop(oop vthread); Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names? src/hotspot/share/runtime/objectMonitor.hpp line 299: > 297: // Simply set _owner field to new_value; current value must match old_value. > 298: void set_owner_from_raw(int64_t old_value, int64_t new_value); > 299: // Same as above but uses tid of current as new value. By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right? src/hotspot/share/runtime/objectMonitor.hpp line 302: > 300: // Simply set _owner field to new_value; current value must match old_value. > 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); > 302: void set_owner_from(int64_t old_value, JavaThread* current); Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment. src/hotspot/share/runtime/objectMonitor.hpp line 302: > 300: void set_owner_from(int64_t old_value, JavaThread* current); > 301: // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER. > 302: void set_owner_from_BasicLock(JavaThread* current); Shouldn't tid there be the basicLock? src/hotspot/share/runtime/objectMonitor.hpp line 303: > 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); > 302: void set_owner_from(int64_t old_value, JavaThread* current); > 303: // Simply set _owner field to current; current value must match basic_lock_p. Comment is no longer accurate src/hotspot/share/runtime/objectMonitor.hpp line 309: > 307: // _owner field. Returns the prior value of the _owner field. > 308: int64_t try_set_owner_from_raw(int64_t old_value, int64_t new_value); > 309: int64_t try_set_owner_from(int64_t old_value, JavaThread* current); Similar to set_owner* need better comments describing API. src/hotspot/share/runtime/objectMonitor.hpp line 311: > 309: int64_t try_set_owner_from(int64_t old_value, JavaThread* current); > 310: > 311: bool is_succesor(JavaThread* thread); I think `has_successor` is more appropriate here as it is not the monitor that is the successor. src/hotspot/share/runtime/objectMonitor.hpp line 312: > 310: void set_successor(JavaThread* thread); > 311: void set_successor(oop vthread); > 312: void clear_successor(); Needs descriptive comments, or at least a preceding comment explaining what a "successor" is. src/hotspot/share/runtime/objectMonitor.hpp line 315: > 313: void set_succesor(oop vthread); > 314: void clear_succesor(); > 315: bool has_succesor(); Sorry but `successor` has two `s` before `or`. src/hotspot/share/runtime/objectMonitor.hpp line 317: > 315: bool has_succesor(); > 316: > 317: bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); } Again `has_owner` seems more appropriate src/hotspot/share/runtime/objectMonitor.hpp line 323: > 321: } > 322: > 323: bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; } Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner. src/hotspot/share/runtime/objectMonitor.hpp line 333: > 331: bool is_stack_locker(JavaThread* current); > 332: BasicLock* stack_locker() const; > 333: void set_stack_locker(BasicLock* locker); Again `is` versus `has`, plus some general comments describing the API. src/hotspot/share/runtime/objectMonitor.hpp line 334: > 332: > 333: // Returns true if BasicLock* stored in _stack_locker > 334: // points to current's stack, false othwerwise. Suggestion: // points to current's stack, false otherwise. src/hotspot/share/runtime/objectMonitor.hpp line 349: > 347: ObjectWaiter* first_waiter() { return _WaitSet; } > 348: ObjectWaiter* next_waiter(ObjectWaiter* o) { return o->_next; } > 349: JavaThread* thread_of_waiter(ObjectWaiter* o) { return o->_thread; } This no longer looks correct if the waiter is a vthread. ?? src/hotspot/share/runtime/objectMonitor.inline.hpp line 110: > 108: } > 109: > 110: // Returns null if DEFLATER_MARKER is observed. Comment needs updating src/hotspot/share/runtime/objectMonitor.inline.hpp line 130: > 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise. > 129: // This accessor is called when we really need to know if the owner > 130: // field == DEFLATER_MARKER and any non-null value won't do the trick. Comment needs updating src/hotspot/share/runtime/synchronizer.cpp line 670: > 668: // Top native frames in the stack will not be seen if we attempt > 669: // preemption, since we start walking from the last Java anchor. > 670: NoPreemptMark npm(current); Don't we still pin for JNI monitor usage? src/hotspot/share/runtime/synchronizer.cpp line 1440: > 1438: } > 1439: > 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) { `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`? src/hotspot/share/runtime/synchronizer.hpp line 172: > 170: > 171: // Iterate ObjectMonitors where the owner is thread; this does NOT include > 172: // ObjectMonitors where owner is set to a stack lock address in thread. Comment needs updating src/hotspot/share/runtime/threadIdentifier.cpp line 30: > 28: > 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp > 30: static const int64_t INITIAL_TID = 3; Can we express this in terms of those reserved values, or are they inaccessible? src/hotspot/share/services/threadService.cpp line 467: > 465: if (waitingToLockMonitor->has_owner()) { > 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); > 467: // If currentThread is nullptr we would like to know if the owner Suggestion: // If currentThread is null we would like to know if the owner src/hotspot/share/services/threadService.cpp line 474: > 472: // vthread we never record this as a deadlock. Note: unless there > 473: // is a bug in the VM, or a thread exits without releasing monitors > 474: // acquired through JNI, nullptr should imply unmounted vthread owner. Suggestion: // acquired through JNI, null should imply an unmounted vthread owner. src/java.base/share/classes/java/lang/Object.java line 383: > 381: try { > 382: wait0(timeoutMillis); > 383: } catch (InterruptedException e) { I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us. src/java.base/share/classes/java/lang/Thread.java line 654: > 652: * {@link Thread#PRIMORDIAL_TID} +1 as this class cannot be used during > 653: * early startup to generate the identifier for the primordial thread. The > 654: * counter is off-heap and shared with the VM to allow it assign thread Suggestion: * counter is off-heap and shared with the VM to allow it to assign thread src/java.base/share/classes/java/lang/Thread.java line 655: > 653: * early startup to generate the identifier for the primordial thread. The > 654: * counter is off-heap and shared with the VM to allow it assign thread > 655: * identifiers to non-Java threads. Why do non-JavaThreads need an identifier of this kind? src/java.base/share/classes/java/lang/Thread.java line 731: > 729: > 730: if (attached && VM.initLevel() < 1) { > 731: this.tid = 3; // primordial thread The comment before the `ThreadIdentifiers` class needs updating to account for this change. src/java.base/share/classes/java/lang/VirtualThread.java line 109: > 107: * > 108: * RUNNING -> BLOCKING // blocking on monitor enter > 109: * BLOCKING -> BLOCKED // blocked on monitor enter Should this say something similar to the parked case, about the "yield" being successful? src/java.base/share/classes/java/lang/VirtualThread.java line 110: > 108: * RUNNING -> BLOCKING // blocking on monitor enter > 109: * BLOCKING -> BLOCKED // blocked on monitor enter > 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry? src/java.base/share/classes/java/lang/VirtualThread.java line 111: > 109: * BLOCKING -> BLOCKED // blocked on monitor enter > 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue > 111: * UNBLOCKED -> RUNNING // continue execution after blocked on monitor enter Presumably this one means it acquired the monitor? src/java.base/share/classes/java/lang/VirtualThread.java line 115: > 113: * RUNNING -> WAITING // transitional state during wait on monitor > 114: * WAITING -> WAITED // waiting on monitor > 115: * WAITED -> BLOCKED // notified, waiting to be unblocked by monitor owner Waiting to re-enter the monitor? src/java.base/share/classes/java/lang/VirtualThread.java line 178: > 176: // timed-wait support > 177: private long waitTimeout; > 178: private byte timedWaitNonce; Strange name - what does this mean? src/java.base/share/classes/java/lang/VirtualThread.java line 530: > 528: && carrier == Thread.currentCarrierThread(); > 529: carrier.setCurrentThread(carrier); > 530: Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ?? src/java.base/share/classes/java/lang/VirtualThread.java line 631: > 629: // Object.wait > 630: if (s == WAITING || s == TIMED_WAITING) { > 631: byte nonce; Suggestion: byte seqNo; src/java.base/share/classes/java/lang/VirtualThread.java line 948: > 946: * This method does nothing if the thread has been woken by notify or interrupt. > 947: */ > 948: private void waitTimeoutExpired(byte nounce) { I assume you meant `nonce` here, but please change to `seqNo`. src/java.base/share/classes/java/lang/VirtualThread.java line 952: > 950: for (;;) { > 951: boolean unblocked = false; > 952: synchronized (timedWaitLock()) { Where is the overall design of the timed-wait protocol and it use of synchronization described? src/java.base/share/classes/java/lang/VirtualThread.java line 1397: > 1395: > 1396: /** > 1397: * Returns a lock object to coordinating timed-wait setup and timeout handling. Suggestion: * Returns a lock object for coordinating timed-wait setup and timeout handling. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2384039238 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2387241944 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393910702 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393922768 Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2406338095 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2409348761 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417279456 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431004707 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818251880 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815838204 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815839094 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827128518 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815840245 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814306675 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344054 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805616004 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814260043 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815985700 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815998417 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816002660 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816009160 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816014286 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816017269 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816018848 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810025380 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815956322 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816040287 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810027786 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810029858 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811912133 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810032387 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811913172 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810033016 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810035434 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810037658 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815959203 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810036007 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810041017 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810046285 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810049295 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811914377 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815960013 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815967260 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815969101 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816043275 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816047142 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816041444 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810068395 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344940 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825345446 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814294622 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814158735 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814159210 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810076019 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810111255 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113028 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113953 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810114488 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810116177 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810131339 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814169150 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814170953 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814171503 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814172621 From coleenp at openjdk.org Wed Nov 6 17:39:52 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:39:52 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I've done a first pass over the first commit and have some comments and questions. Round 2. There are a lot of very helpful comments in the new code to explain what it's doing but I have some requests for some more. And some questions. Some more comments and questions on the latest commit, mostly minor. I've traced through the runtime code (minus calculations for continuations) and found some typos on the way. Excellent piece of work. > Then I looked at typing up the thread / lock ids as an enum class https://github.com/openjdk/jdk/commit/34221f4a50a492cad4785cfcbb4bef8fa51d6f23 Both of these suggested changes should be discussed as different RFEs. I don't really like this ThreadID change because it seems to introduce casting everywhere. Noticed while downloading this that some copyrights need updating. src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135: > 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); > 134: intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset); > 135: *lspp = f.unextended_sp() - f.fp(); Can you write a comment what this is doing briefly and why? src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550: > 1548: #endif /* ASSERT */ > 1549: > 1550: push_cont_fastpath(); One of the callers of this gives a clue what it does. __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about Why do you do this here? Oh please more comments... src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354: > 5352: str(rscratch2, dst); > 5353: Label ok; > 5354: tbz(rscratch2, 63, ok); 63? Does this really need to have underflow checking? That would alleviate the register use concerns if it didn't. And it's only for legacy locking which should be stable until it's removed. src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032: > 2030: // Force freeze slow path in case we try to preempt. We will pin the > 2031: // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()). > 2032: __ push_cont_fastpath(); We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do? src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2629: > 2627: addi(temp, displaced_header, in_bytes(ObjectMonitor::owner_offset()) - markWord::monitor_value); > 2628: Register thread_id = displaced_header; > 2629: ld(thread_id, in_bytes(JavaThread::lock_id_offset()), R16_thread); Maybe to make things really clear, you could call this thread_lock_id ? Seems to be used consistently as thread_id in much of the platform code. src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231: > 229: > 230: void MacroAssembler::inc_held_monitor_count(Register tmp) { > 231: Address dst = Address(xthread, JavaThread::held_monitor_count_offset()); Address dst(xthread, JavaThread::held_monitor_count_offset()); src/hotspot/share/interpreter/oopMapCache.cpp line 268: > 266: } > 267: > 268: int num_oops() { return _num_oops; } I can't find what uses this from OopMapCacheEntry. src/hotspot/share/oops/stackChunkOop.inline.hpp line 189: > 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const { > 188: ObjectWaiter* waiter = object_waiter(); > 189: if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) { Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; } Not sure what this is excluding. src/hotspot/share/runtime/continuation.cpp line 89: > 87: // we would incorrectly throw it during the unmount logic in the carrier. > 88: if (_target->has_async_exception_condition()) { > 89: _failed = false; This says "Don't" but then failed is false which doesn't make sense. Should it be true? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275: > 1273: > 1274: if (caller.is_interpreted_frame()) { > 1275: _total_align_size += frame::align_wiggle; Please put a comment here about frame align-wiggle. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278: > 1276: } > 1277: > 1278: patch(f, hf, caller, false /*is_bottom_frame*/); I also forgot what patch does. Can you add a comment here too? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1550: > 1548: assert(!cont.is_empty(), ""); > 1549: // This is done for the sake of the enterSpecial frame > 1550: StackWatermarkSet::after_unwind(thread); Is there a new place for this StackWatermark code? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1657: > 1655: } > 1656: > 1657: template This function is kind of big, do we really want it duplicated to pass preempt as a template parameter? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235: > 2233: assert(!mon_acquired || mon->has_owner(_thread), "invariant"); > 2234: if (!mon_acquired) { > 2235: // Failed to aquire monitor. Return to enterSpecial to unmount again. typo: acquire src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492: > 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) { > 2491: ContinuationWrapper::SafepointOp so(current, _cont); > 2492: // Since we might safepoint set the anchor so that the stack can we walked. typo: can be walked src/hotspot/share/runtime/javaThread.cpp line 2002: > 2000: #ifdef SUPPORT_MONITOR_COUNT > 2001: > 2002: #ifdef LOOM_MONITOR_SUPPORT If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ? src/hotspot/share/runtime/javaThread.hpp line 334: > 332: bool _pending_jvmti_unmount_event; // When preempting we post unmount event at unmount end rather than start > 333: bool _on_monitor_waited_event; // Avoid callee arg processing for enterSpecial when posting waited event > 334: ObjectMonitor* _contended_entered_monitor; // Monitor por pending monitor_contended_entered callback typo: Monitor **for** pending_contended_entered callback src/hotspot/share/runtime/objectMonitor.cpp line 416: > 414: set_owner_from_BasicLock(cur, current); // Convert from BasicLock* to Thread*. > 415: return true; > 416: } Not needed? Oh I see, BasicLock is now in stack_locker. src/hotspot/share/runtime/objectMonitor.cpp line 876: > 874: // and in doing so avoid some transitions ... > 875: > 876: // For virtual threads that are pinned do a timed-park instead, to I had trouble parsing this first sentence. I think it needs a comma after pinned and remove the comma after instead. src/hotspot/share/runtime/objectMonitor.cpp line 1014: > 1012: assert_mark_word_consistency(); > 1013: UnlinkAfterAcquire(current, currentNode); > 1014: if (is_succesor(current)) clear_succesor(); successor has two 's'. src/hotspot/share/runtime/objectMonitor.cpp line 1158: > 1156: if (LockingMode != LM_LIGHTWEIGHT && current->is_lock_owned((address)cur)) { > 1157: assert(_recursions == 0, "invariant"); > 1158: set_owner_from_BasicLock(cur, current); // Convert from BasicLock* to Thread*. This is nice you don't have to do this anymore. src/hotspot/share/runtime/objectMonitor.cpp line 2305: > 2303: } > 2304: > 2305: void ObjectMonitor::Initialize2() { Can you put a comment why there's a second initialize function? Presumably after some state is set. src/hotspot/share/runtime/objectMonitor.hpp line 43: > 41: // ParkEvent instead. Beware, however, that the JVMTI code > 42: // knows about ObjectWaiters, so we'll have to reconcile that code. > 43: // See next_waiter(), first_waiter(), etc. Also a nice cleanup. Did you reconcile the JVMTI code? src/hotspot/share/runtime/objectMonitor.hpp line 71: > 69: bool is_wait() { return _is_wait; } > 70: bool notified() { return _notified; } > 71: bool at_reenter() { return _at_reenter; } should these be const member functions? ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2386614214 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2390813935 PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2396572570 Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2405734604 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2430528701 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442058307 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813899129 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814081166 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811590155 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814084085 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811591482 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811595282 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817407075 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823088425 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814905064 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815015410 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815016232 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815245735 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815036910 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823233359 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823252062 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811611376 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823091373 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811613400 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815445109 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811614453 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817415918 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815479877 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817419797 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420178 From fbredberg at openjdk.org Wed Nov 6 17:39:53 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 6 Nov 2024 17:39:53 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Been learning a ton by reading the code changes and questions/answers from/to others. But I still have some questions (and some small suggestions). I'm done reviewing this piece of good-looking code, and I really enjoyed it. Thanks! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945: > 943: > 944: void inc_held_monitor_count(); > 945: void dec_held_monitor_count(); I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Suggestion: void inc_held_monitor_count(Register tmp); void dec_held_monitor_count(Register tmp); src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740: > 738: void MacroAssembler::clobber_nonvolatile_registers() { > 739: BLOCK_COMMENT("clobber nonvolatile registers {"); > 740: Register regs[] = { Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory. Suggestion: static const Register regs[] = { src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273: > 271: ? frame_sp + fsize - frame::sender_sp_offset > 272: // we need to re-read fp because it may be an oop and we might have fixed the frame. > 273: : *(intptr_t**)(hf.sp() - 2); Suggestion: : *(intptr_t**)(hf.sp() - frame::sender_sp_offset); src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793: > 791: > 792: void inc_held_monitor_count(Register tmp = t0); > 793: void dec_held_monitor_count(Register tmp = t0); I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC. Suggestion: void inc_held_monitor_count(Register tmp); void dec_held_monitor_count(Register tmp); src/hotspot/share/runtime/continuation.cpp line 125: > 123: }; > 124: > 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) { I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`. Suggestion: static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) { src/hotspot/share/runtime/continuation.cpp line 135: > 133: #endif // INCLUDE_JVMTI > 134: > 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) { I think the code reads better if you change to `is_safe_to_preempt_vthread`. Suggestion: static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) { src/hotspot/share/runtime/continuation.hpp line 66: > 64: > 65: enum preempt_kind { > 66: freeze_on_monitorenter = 1, Is there a reason why the first enumerator doesn't start at zero? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); > 888: } else { > 889: return freeze_pinned_native; Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me. src/hotspot/share/runtime/objectMonitor.cpp line 1193: > 1191: } > 1192: > 1193: assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, ""); In `ObjectMonitor::resume_operation()` the exact same line is a `guarantee`- not an `assert`-line, is there any reason why? ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2404133418 Marked as reviewed by fbredberg (Committer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410872086 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822551094 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822696920 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822200193 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822537887 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824253403 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824255622 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824262945 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824405820 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824676122 From dlong at openjdk.org Wed Nov 6 17:39:59 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:39:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Marked as reviewed by dlong (Reviewer). > On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic. During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub. In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled. Looking at this reminds me of a paper I read a long time ago, "Using continuations to implement thread management and communication in operating systems" (https://dl.acm.org/doi/10.1145/121133.121155). For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java. Is there a way to fix that? I finished looking at this, and it looks good. Nice work! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188: > 186: // Avoid using a leave instruction when this frame may > 187: // have been frozen, since the current value of rfp > 188: // restored from the stub would be invalid. We still It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem? Do we actually need FP set by the enter() prologue for stubs? If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs. We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away. src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191: > 189: // must restore the rfp value saved on enter though. > 190: if (use_pop) { > 191: ldp(rfp, lr, Address(post(sp, 2 * wordSize))); leave() also calls authenticate_return_address(), which I assume we still want to call here. How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`? src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133: > 131: > 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) { > 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); Suggestion: assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame"); src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135: > 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); > 134: intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset); > 135: *lspp = f.unextended_sp() - f.fp(); Suggestion: f.interpreter_frame_set_last_sp(f.unextended_sp()); src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159: > 157: > 158: // The interpreter native wrapper code adds space in the stack equal to size_of_parameters() > 159: // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter). Suggestion: // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter). Isn't that 2 words, not 3? src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310: > 308: sp -= 2; > 309: sp[-2] = sp[0]; > 310: sp[-1] = sp[1]; This also seems fragile. This seems to depend on an intimate knowledge of what the stub will do when returning. We don't need this when doing a regular return from the native call, so why do we need it here? I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects. Why is this needed for C2 and not C1? src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338: > 336: // Make sure that extended_sp is kept relativized. > 337: DEBUG_ONLY(Method* m = hf.interpreter_frame_method();) > 338: DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata() Isn't m->size_of_parameters() always correct? Why is wait0 a special case? src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77: > 75: // Interpreter frames > 76: interpreter_frame_result_handler_offset = 3, // for native calls only > 77: interpreter_frame_oop_temp_offset = 2, // for native calls only This conflicts with sender_sp_offset. Doesn't that cause a problem? src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555: > 1553: // Make VM call. In case of preemption set last_pc to the one we want to resume to. > 1554: adr(rscratch1, resume_pc); > 1555: str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset())); Is it really needed to set an alternative last_Java_pc()? I couldn't find where it's used in a way that would require a different value. src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567: > 1565: > 1566: // In case of preemption, this is where we will resume once we finally acquire the monitor. > 1567: bind(resume_pc); If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above? src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119: > 117: return mask.num_oops() > 118: + 1 // for the mirror oop > 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot Where is this temp oop slot set and used? src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351: > 1349: // set result handler > 1350: __ mov(result_handler, r0); > 1351: __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize)); I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere. I think this deserves a comment. src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509: > 1507: Label no_oop; > 1508: __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT))); > 1509: __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize)); We only need this when preempted, right? So could this be moved into the block above, where we call restore_after_resume()? src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 223: > 221: } > 222: > 223: void StubAssembler::epilogue(bool use_pop) { Is there a better name we could use, like `trust_fp` or `after_resume`? src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643: > 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) { > 642: #ifdef _LP64 > 643: return r15_off / 2; I think using r15_offset_in_bytes() would be less confusing. src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 324: > 322: movq(scrReg, tmpReg); > 323: xorq(tmpReg, tmpReg); > 324: movptr(boxReg, Address(r15_thread, JavaThread::lock_id_offset())); I don't know if it helps to schedule this load earlier (it is used in the next instruction), but it probably won't hurt. src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146: > 144: // Make sure that locals is already relativized. > 145: DEBUG_ONLY(Method* m = f.interpreter_frame_method();) > 146: DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;) What is the + 2 for? Is the check for is_native because of wait0? Please add a comment what this line is doing. src/hotspot/cpu/x86/interp_masm_x86.cpp line 359: > 357: push_cont_fastpath(); > 358: > 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening. The push/pop of rscratch1 doesn't seem to be doing anything. src/hotspot/cpu/x86/interp_masm_x86.cpp line 361: > 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. > 360: lea(rscratch1, resume_pc); > 361: push(rscratch1); Suggestion: push(rscratch1); // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796: > 3794: __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset())); > 3795: __ testbool(rscratch1); > 3796: __ jcc(Assembler::notZero, preemption_cancelled); If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called. Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called? src/hotspot/share/c1/c1_Runtime1.hpp line 138: > 136: static void initialize_pd(); > 137: > 138: static uint runtime_blob_current_thread_offset(frame f); I think this returns an offset in wordSize units, but it's not documented. In some places we always return an offset in bytes and let the caller convert. src/hotspot/share/code/nmethod.cpp line 712: > 710: JavaThread* thread = reg_map->thread(); > 711: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) > 712: JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { I'm guessing this is because JVMTI can cause a safepoint? This might need a comment. src/hotspot/share/code/nmethod.cpp line 1302: > 1300: _compiler_type = type; > 1301: _orig_pc_offset = 0; > 1302: _num_stack_arg_slots = 0; Was the old value wrong, unneeded, or is this set somewhere else? If this field is not used, then we might want to set it to an illegal value in debug builds. src/hotspot/share/oops/method.cpp line 870: > 868: } > 869: > 870: bool Method::is_object_wait0() const { It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here. src/hotspot/share/oops/stackChunkOop.inline.hpp line 255: > 253: RegisterMap::WalkContinuation::include); > 254: full_map.set_include_argument_oops(false); > 255: closure->do_frame(f, map); This could use a comment. I guess we weren't looking at the stub frame before, only the caller. Why is this using `map` instead of `full_map`? src/hotspot/share/prims/jvmtiEnv.cpp line 1363: > 1361: } > 1362: > 1363: if (LockingMode == LM_LEGACY && java_thread == nullptr) { Do we need to check for `java_thread == nullptr` for other locking modes? src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602: > 1600: // If the thread was found on the ObjectWaiter list, then > 1601: // it has not been notified. > 1602: Handle th(current_thread, w->threadObj()); Why use get_vthread_or_thread_oop() above but threadObj()? It probably needs a comment. src/hotspot/share/runtime/continuation.hpp line 50: > 48: class JavaThread; > 49: > 50: // should match Continuation.toPreemptStatus() in Continuation.java I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match. src/hotspot/share/runtime/continuation.hpp line 50: > 48: class JavaThread; > 49: > 50: // should match Continuation.PreemptStatus() in Continuation.java As far as I can tell, these enum values still don't match the Java values. If they need to match, then maybe there should be asserts that check that. src/hotspot/share/runtime/continuationEntry.cpp line 51: > 49: _return_pc = nm->code_begin() + _return_pc_offset; > 50: _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset; > 51: _cleanup_pc = nm->code_begin() + _cleanup_offset; I don't see why we need these relative offsets. Instead of doing _thaw_call_pc_offset = __ pc() - start; why not do _thaw_call_pc = __ pc(); The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316: > 314: pc = ContinuationHelper::return_address_at( > 315: sp - frame::sender_sp_ret_address_offset()); > 316: } You could do this with an overload instead: static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) { assert(pc != nullptr, ""); [...] } static void set_anchor(JavaThread* thread, intptr_t* sp) { address pc = ContinuationHelper::return_address_at( sp - frame::sender_sp_ret_address_offset()); set_anchor(thread, sp, pc); } but the compiler probably optmizes the above check just fine. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696: > 694: // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments. > 695: // They'll then be stored twice: in the chunk and in the parent chunk's top frame > 696: const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack; `cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once. Would it make sense to add a helper function named something like `total_cont_size()`? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063: > 1061: unwind_frames(); > 1062: > 1063: chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words); It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size). I wonder if there is a way to simply these adjustments. Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411: > 1409: // zero out fields (but not the stack) > 1410: const size_t hs = oopDesc::header_size(); > 1411: oopDesc::set_klass_gap(mem, 0); Why, bug fix or cleanup? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1659: > 1657: int i = 0; > 1658: for (frame f = freeze_start_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map), i++) { > 1659: if (!((f.is_compiled_frame() && !f.is_deoptimized_frame()) || (i == 0 && (f.is_runtime_frame() || f.is_native_frame())))) { OK, `i == 0` just means first frame here, so you could use a bool instead of an int, or even check for f == freeze_start_frame(), right? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842: > 1840: size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast > 1841: size += 2*frame::align_wiggle; // in case of alignments at the top and bottom > 1842: size += frame::metadata_words; // for preemption case (see possibly_adjust_frame) So this means it's OK to over-estimate the size here? src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045: > 2043: // If we don't thaw the top compiled frame too, after restoring the saved > 2044: // registers back in Java, we would hit the return barrier to thaw one more > 2045: // frame effectively overwritting the restored registers during that call. Suggestion: // frame effectively overwriting the restored registers during that call. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062: > 2060: } > 2061: > 2062: f.next(SmallRegisterMap::instance, true /* stop */); Suggestion: f.next(SmallRegisterMap::instance(), true /* stop */); This looks like a typo, so I wonder how it compiled. I guess template magic is hiding it. src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650: > 2648: _cont.tail()->do_barriers(_stream, &map); > 2649: } else { > 2650: _stream.next(SmallRegisterMap::instance); Suggestion: _stream.next(SmallRegisterMap::instance()); src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189: > 187: > 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) { > 189: return Atomic::load(chunk->field_addr(_lockStackSize_offset)); If these accesses need to be atomic, could you add a comment explaining why? src/hotspot/share/runtime/deoptimization.cpp line 125: > 123: > 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) { > 125: if (!nm->can_be_deoptimized()) { Is this a performance optimization? src/hotspot/share/runtime/objectMonitor.cpp line 1612: > 1610: > 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) { > 1612: // Since we might safepoint set the anchor so that the stack can we walked. I was assuming the anchor would have been restored to what it was at preemption time. What is the state of the anchor at resume time, and is it documented anywhere? I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here. src/hotspot/share/runtime/objectMonitor.inline.hpp line 44: > 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) { > 43: int64_t tid = thread->lock_id(); > 44: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); Should the "3" be a named constant with a comment? src/hotspot/share/runtime/objectMonitor.inline.hpp line 207: > 205: } > 206: > 207: inline bool ObjectMonitor::has_successor() { Why are _succ accesses atomic here when previously they were not? src/hotspot/share/runtime/vframe.cpp line 289: > 287: current >= f.interpreter_frame_monitor_end(); > 288: current = f.previous_monitor_in_interpreter_frame(current)) { > 289: oop owner = !heap_frame ? current->obj() : StackValue::create_stack_value_from_oop_location(stack_chunk(), (void*)current->obj_adr())->get_obj()(); It looks like we don't really need the StackValue. We might want to make it possible to call oop_from_oop_location() directly. src/hotspot/share/runtime/vframe.inline.hpp line 130: > 128: // Waited event after target vthread was preempted. Since all continuation frames > 129: // are freezed we get the top frame from the stackChunk instead. > 130: _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map); What happens if we don't do this? That might help explain why we are doing this. src/hotspot/share/services/threadService.cpp line 467: > 465: if (waitingToLockMonitor->has_owner()) { > 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); > 467: } Please explain why it is safe to remvoe the above code. src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108: > 106: processDeregisterQueue(); > 107: > 108: if (Thread.currentThread().isVirtual()) { It looks like we have two implementations, depending on if the current thread is virtual or not. The two implementations differ in the way they signal interrupted. Can we unify the two somehow? src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57: > 55: static { > 56: try { > 57: MethodHandles.lookup().ensureInitialized(AnchorCertificates.class); Why is this needed? A comment would help. test/hotspot/gtest/nmt/test_vmatree.cpp line 34: > 32: > 33: using Tree = VMATree; > 34: using TNode = Tree::TreapNode; Why is this needed? test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42: > 40: * -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep > 41: * -XX:CompileCommand=exclude,java.lang.Thread::afterSleep > 42: * -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos I'm guessing these changes have something to do with JDK-8279653? test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73: > 71: /* ========================================================================== */ > 72: > 73: static int prepare(JNIEnv* jni) { Is this a bug fix? test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30: > 28: * by reflection API > 29: * @library /test/lib/ > 30: * @requires vm.compMode != "Xcomp" If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix. ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410825883 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2439180320 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442765996 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2448962446 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2452534349 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817461936 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817426321 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817439076 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817437593 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817441437 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817464371 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817465037 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819964369 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817537666 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817539657 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817549144 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819973901 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820002377 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819979640 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819982432 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821434823 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819763504 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819996648 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821706030 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817552633 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819981522 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821503185 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821506576 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821558267 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821571623 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594124 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821601480 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821617785 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821746421 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821623432 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821628036 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821632152 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821636581 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821644040 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821653194 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821656267 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821755997 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821670778 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821685316 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823640621 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823644339 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580051 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823663674 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823665393 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825045757 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825050976 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825054769 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825111095 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825097245 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825109698 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104359 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107638 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817413638 From amitkumar at openjdk.org Wed Nov 6 17:39:59 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 6 Nov 2024 17:39:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Hi @pchilano, I see couple of failures on s390x, can you apply this patch: diff --git a/src/hotspot/cpu/s390/macroAssembler_s390.cpp b/src/hotspot/cpu/s390/macroAssembler_s390.cpp index f342240f3ca..d28b4579824 100644 --- a/src/hotspot/cpu/s390/macroAssembler_s390.cpp +++ b/src/hotspot/cpu/s390/macroAssembler_s390.cpp @@ -3492,7 +3492,7 @@ void MacroAssembler::increment_counter_eq(address counter_address, Register tmp1 void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Register temp1, Register temp2) { assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight"); - assert_different_registers(oop, box, temp1, temp2); + assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch); Register displacedHeader = temp1; Register currentHeader = temp1; @@ -3566,8 +3566,8 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis // If csg succeeds then CR=EQ, otherwise, register zero is filled // with the current owner. z_lghi(zero, 0); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_csg(zero, Z_R1_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_csg(zero, Z_R0_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged); // Store a non-null value into the box. z_stg(box, BasicLock::displaced_header_offset_in_bytes(), box); @@ -3576,7 +3576,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis BLOCK_COMMENT("fast_path_recursive_lock {"); // Check if we are already the owner (recursive lock) - z_cgr(Z_R1_scratch, zero); // owner is stored in zero by "z_csg" above + z_cgr(Z_R0_scratch, zero); // owner is stored in zero by "z_csg" above z_brne(done); // not a recursive lock // Current thread already owns the lock. Just increment recursion count. @@ -3594,7 +3594,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Register temp1, Register temp2) { assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight"); - assert_different_registers(oop, box, temp1, temp2); + assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch); Register displacedHeader = temp1; Register currentHeader = temp2; @@ -3641,8 +3641,8 @@ void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Reg // Handle existing monitor. bind(object_has_monitor); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_cg(Z_R1_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner))); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_cg(Z_R0_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner))); z_brne(done); BLOCK_COMMENT("fast_path_recursive_unlock {"); @@ -6164,7 +6164,7 @@ void MacroAssembler::lightweight_unlock(Register obj, Register temp1, Register t } void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Register box, Register tmp1, Register tmp2) { - assert_different_registers(obj, box, tmp1, tmp2); + assert_different_registers(obj, box, tmp1, tmp2, Z_R0_scratch); // Handle inflated monitor. NearLabel inflated; @@ -6296,12 +6296,12 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Registe // If csg succeeds then CR=EQ, otherwise, register zero is filled // with the current owner. z_lghi(zero, 0); - z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset())); - z_csg(zero, Z_R1_scratch, owner_address); + z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset())); + z_csg(zero, Z_R0_scratch, owner_address); z_bre(monitor_locked); // Check if recursive. - z_cgr(Z_R1_scratch, zero); // zero contains the owner from z_csg instruction + z_cgr(Z_R0_scratch, zero); // zero contains the owner from z_csg instruction z_brne(slow_path); // Recursive CC: @RealLucy ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2414585800 From aph at openjdk.org Wed Nov 6 17:40:00 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > * We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60: > 58: > 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight"); > 60: assert_different_registers(oop, box, tmp, disp_hdr, rscratch2); Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341: > 5339: > 5340: void MacroAssembler::inc_held_monitor_count() { > 5341: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); Suggestion: // Clobbers: rscratch1 and rscratch2 void MacroAssembler::inc_held_monitor_count() { Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357: > 5355: > 5356: void MacroAssembler::dec_held_monitor_count() { > 5357: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); Suggestion: // Clobbers: rscratch1 and rscratch2 void MacroAssembler::dec_held_monitor_count() { Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2429587519 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810966647 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810987929 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810989022 From alanb at openjdk.org Wed Nov 6 17:40:00 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:23:50 GMT, Andrew Haley wrote: > This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible. There's nothing exposed today to allow custom schedulers. The experiments/explorations going on right now have to be careful to not hold any locks. Throwing if holding a monitor is an option but only it would need to be backed by spec and would also shine light on the issue of j.u.concurrent locks as a carrier might independently hold a lock there too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431600434 From coleenp at openjdk.org Wed Nov 6 17:40:00 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 06:15:27 GMT, David Holmes wrote: > Why do we need to cache it? Is it the implicit barriers related to accessing the threadObj oop each time? We cache threadObj.thread_id in JavaThread::_lock_id so that the fast path c2_MacroAssembler code has one less load and code to find the offset of java.lang.Thread.threadId in the code. Also, yes, we were worried about performance of the barrier in this path. > src/hotspot/share/runtime/objectMonitor.hpp line 174: > >> 172: >> 173: int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. >> 174: volatile uint64_t _previous_owner_tid; // thread id of the previous owner of the monitor > > Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ?? I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id. $ grep -r JFR_THREAD_ID jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread)) jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id()) runtime/objectMonitor.cpp: _previous_owner_tid = JFR_THREAD_ID(current); runtime/objectMonitor.cpp: iterator->_notifier_tid = JFR_THREAD_ID(current); runtime/vmThread.cpp: event->set_caller(JFR_THREAD_ID(op->calling_thread())); > src/hotspot/share/runtime/synchronizer.cpp line 1440: > >> 1438: } >> 1439: >> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) { > > `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`? If it's always the current thread, then it should be called 'current' imo. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2433252605 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816550112 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816551794 From mchung at openjdk.org Wed Nov 6 17:40:00 2024 From: mchung at openjdk.org (Mandy Chung) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I looked at java.lang.ref and java.lang.invoke changes. ReferenceQueue was reverted back to use synchronized and also adding the code disable/enable preemption looks right. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438401789 From bpb at openjdk.org Wed Nov 6 17:40:00 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... The `InternalLock` and `ByteArrayOutputStream` changes look all right. I'll follow up with [JDK-8343039](https://bugs.openjdk.org/browse/JDK-8343039) once this PR for [JEP 491](https://openjdk.org/jeps/491) is integrated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438461962 From pchilanomate at openjdk.org Wed Nov 6 17:40:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 02:15:29 GMT, Dean Long wrote: > > On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic. > > During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub. In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled. > The problem is that freezing the frames can fail. By then we would have already added the ObjectWaiter as representing a virtual thread. Regarding efficiency (and ignoring the previous issue) both approaches would be equal anyways, since regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption. >It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem? > Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough. > src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191: > >> 189: // must restore the rfp value saved on enter though. >> 190: if (use_pop) { >> 191: ldp(rfp, lr, Address(post(sp, 2 * wordSize))); > > leave() also calls authenticate_return_address(), which I assume we still want to call here. > How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`? Right. I added it here for now to follow the same style in all platforms. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133: > >> 131: >> 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) { >> 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); > > Suggestion: > > assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame"); Changed, here and in the other platforms. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135: > >> 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); >> 134: intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset); >> 135: *lspp = f.unextended_sp() - f.fp(); > > Suggestion: > > f.interpreter_frame_set_last_sp(f.unextended_sp()); Changed, here and in the other platforms. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159: > >> 157: >> 158: // The interpreter native wrapper code adds space in the stack equal to size_of_parameters() >> 159: // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter). > > Suggestion: > > // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter). > > Isn't that 2 words, not 3? The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347 I don't know why we do that for 64 bits. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338: > >> 336: // Make sure that extended_sp is kept relativized. >> 337: DEBUG_ONLY(Method* m = hf.interpreter_frame_method();) >> 338: DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata() > > Isn't m->size_of_parameters() always correct? Why is wait0 a special case? There are two cases where the interpreter native wrapper frame is freezed: synchronized native method, and `Object.wait()`. The extra push of the parameters to the stack is done after we synchronize on the method, so it only applies to `Object.wait()`. > src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77: > >> 75: // Interpreter frames >> 76: interpreter_frame_result_handler_offset = 3, // for native calls only >> 77: interpreter_frame_oop_temp_offset = 2, // for native calls only > > This conflicts with sender_sp_offset. Doesn't that cause a problem? No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one. > src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351: > >> 1349: // set result handler >> 1350: __ mov(result_handler, r0); >> 1351: __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize)); > > I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere. I think this deserves a comment. Added comment. > src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509: > >> 1507: Label no_oop; >> 1508: __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT))); >> 1509: __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize)); > > We only need this when preempted, right? So could this be moved into the block above, where we call restore_after_resume()? Moved. > src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643: > >> 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) { >> 642: #ifdef _LP64 >> 643: return r15_off / 2; > > I think using r15_offset_in_bytes() would be less confusing. I copied the same comments the other platforms have to make it more clear. > src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146: > >> 144: // Make sure that locals is already relativized. >> 145: DEBUG_ONLY(Method* m = f.interpreter_frame_method();) >> 146: DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;) > > What is the + 2 for? Is the check for is_native because of wait0? Please add a comment what this line is doing. It's for the 2 extra words for native methods (temp oop/result handler). Added comment. > src/hotspot/cpu/x86/interp_masm_x86.cpp line 359: > >> 357: push_cont_fastpath(); >> 358: >> 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. > > From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening. The push/pop of rscratch1 doesn't seem to be doing anything. Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it: https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658 > src/hotspot/cpu/x86/interp_masm_x86.cpp line 361: > >> 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >> 360: lea(rscratch1, resume_pc); >> 361: push(rscratch1); > > Suggestion: > > push(rscratch1); // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack Added it as a note with the comment above. > src/hotspot/share/c1/c1_Runtime1.hpp line 138: > >> 136: static void initialize_pd(); >> 137: >> 138: static uint runtime_blob_current_thread_offset(frame f); > > I think this returns an offset in wordSize units, but it's not documented. In some places we always return an offset in bytes and let the caller convert. Added comment. > src/hotspot/share/code/nmethod.cpp line 712: > >> 710: JavaThread* thread = reg_map->thread(); >> 711: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) >> 712: JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { > > I'm guessing this is because JVMTI can cause a safepoint? This might need a comment. I added a comment already in `vthread_monitor_waited_event()` in ObjectMonitor.cpp. I think it's better placed there. > src/hotspot/share/code/nmethod.cpp line 1302: > >> 1300: _compiler_type = type; >> 1301: _orig_pc_offset = 0; >> 1302: _num_stack_arg_slots = 0; > > Was the old value wrong, unneeded, or is this set somewhere else? If this field is not used, then we might want to set it to an illegal value in debug builds. We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods. > src/hotspot/share/oops/method.cpp line 870: > >> 868: } >> 869: >> 870: bool Method::is_object_wait0() const { > > It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here. Right, I added a check for the klass too. > src/hotspot/share/oops/stackChunkOop.inline.hpp line 255: > >> 253: RegisterMap::WalkContinuation::include); >> 254: full_map.set_include_argument_oops(false); >> 255: closure->do_frame(f, map); > > This could use a comment. I guess we weren't looking at the stub frame before, only the caller. Why is this using `map` instead of `full_map`? The full map gets only populated once we get the sender. We only need it when processing the caller which needs to know where each register was spilled since it might contain an oop. > src/hotspot/share/prims/jvmtiEnv.cpp line 1363: > >> 1361: } >> 1362: >> 1363: if (LockingMode == LM_LEGACY && java_thread == nullptr) { > > Do we need to check for `java_thread == nullptr` for other locking modes? No, both LM_LIGHTWEIGHT and LM_MONITOR have support for virtual threads. LM_LEGACY doesn't, so if the virtual thread is unmounted we know there is no monitor information to collect. > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602: > >> 1600: // If the thread was found on the ObjectWaiter list, then >> 1601: // it has not been notified. >> 1602: Handle th(current_thread, w->threadObj()); > > Why use get_vthread_or_thread_oop() above but threadObj()? It probably needs a comment. We already filtered virtual threads above so no point in calling get_vthread_or_thread_oop() again. They will actually return the same result though. > src/hotspot/share/runtime/continuation.hpp line 50: > >> 48: class JavaThread; >> 49: >> 50: // should match Continuation.toPreemptStatus() in Continuation.java > > I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match. Should be just PreemptStatus. Fixed. > src/hotspot/share/runtime/continuation.hpp line 50: > >> 48: class JavaThread; >> 49: >> 50: // should match Continuation.PreemptStatus() in Continuation.java > > As far as I can tell, these enum values still don't match the Java values. If they need to match, then maybe there should be asserts that check that. `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead. > src/hotspot/share/runtime/continuationEntry.cpp line 51: > >> 49: _return_pc = nm->code_begin() + _return_pc_offset; >> 50: _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset; >> 51: _cleanup_pc = nm->code_begin() + _cleanup_offset; > > I don't see why we need these relative offsets. Instead of doing > > _thaw_call_pc_offset = __ pc() - start; > > why not do > > _thaw_call_pc = __ pc(); > > The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is. But these are generated in a temporary buffer. Until we call nmethod::new_native_nmethod() we won't know the final addresses. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316: > >> 314: pc = ContinuationHelper::return_address_at( >> 315: sp - frame::sender_sp_ret_address_offset()); >> 316: } > > You could do this with an overload instead: > > static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) { > assert(pc != nullptr, ""); > [...] > } > static void set_anchor(JavaThread* thread, intptr_t* sp) { > address pc = ContinuationHelper::return_address_at( > sp - frame::sender_sp_ret_address_offset()); > set_anchor(thread, sp, pc); > } > > but the compiler probably optmizes the above check just fine. Added an overload method. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696: > >> 694: // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments. >> 695: // They'll then be stored twice: in the chunk and in the parent chunk's top frame >> 696: const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack; > > `cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once. Would it make sense to add a helper function named something like `total_cont_size()`? Maybe, but I only see it twice, not sure we gain much. Also we save having to jump back and forth to see what total_cont_size() would actually account for. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063: > >> 1061: unwind_frames(); >> 1062: >> 1063: chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words); > > It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size). I wonder if there is a way to simply these adjustments. Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone. The reason why this is added and later subtracted is because when allocating the stackChunk we need to account for all space needed, but when specifying how much space the vthread needs in the stack to allocate the frames we don't need to count _monitors_in_lockstack. I'd rather not group it with frame::metadata_words because these are logically different things. In fact, if we never subtract frame::metadata_words when setting max_thawing_size we should not need to account for it in thaw_size() (this is probably something we should clean up in the future). But for _monitors_in_lockstack we always need to subtract it to max_thawing_size. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842: > >> 1840: size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast >> 1841: size += 2*frame::align_wiggle; // in case of alignments at the top and bottom >> 1842: size += frame::metadata_words; // for preemption case (see possibly_adjust_frame) > > So this means it's OK to over-estimate the size here? Yes, this will be the space allocated in the stack by the vthread when thawing. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045: > >> 2043: // If we don't thaw the top compiled frame too, after restoring the saved >> 2044: // registers back in Java, we would hit the return barrier to thaw one more >> 2045: // frame effectively overwritting the restored registers during that call. > > Suggestion: > > // frame effectively overwriting the restored registers during that call. Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062: > >> 2060: } >> 2061: >> 2062: f.next(SmallRegisterMap::instance, true /* stop */); > > Suggestion: > > f.next(SmallRegisterMap::instance(), true /* stop */); > > This looks like a typo, so I wonder how it compiled. I guess template magic is hiding it. Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650: > >> 2648: _cont.tail()->do_barriers(_stream, &map); >> 2649: } else { >> 2650: _stream.next(SmallRegisterMap::instance); > > Suggestion: > > _stream.next(SmallRegisterMap::instance()); Fixed. > src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189: > >> 187: >> 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) { >> 189: return Atomic::load(chunk->field_addr(_lockStackSize_offset)); > > If these accesses need to be atomic, could you add a comment explaining why? It is read concurrently by GC threads. Added comment. > src/hotspot/share/runtime/deoptimization.cpp line 125: > >> 123: >> 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) { >> 125: if (!nm->can_be_deoptimized()) { > > Is this a performance optimization? No, this might be a leftover. When working on the change for Object.wait I was looking at the deopt code and thought this check was missing. It seems most callers already filter this case except WB_DeoptimizeMethod. > src/hotspot/share/runtime/objectMonitor.cpp line 1612: > >> 1610: >> 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) { >> 1612: // Since we might safepoint set the anchor so that the stack can we walked. > > I was assuming the anchor would have been restored to what it was at preemption time. What is the state of the anchor at resume time, and is it documented anywhere? > I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here. The virtual thread is inside the thaw call here which is a leaf VM method, so there is no anchor. It is still in the mount transition before thawing frames. The top frame is Continuation.enterSpecial so that's what we set the anchor to. > src/hotspot/share/runtime/objectMonitor.inline.hpp line 44: > >> 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) { >> 43: int64_t tid = thread->lock_id(); >> 44: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); > > Should the "3" be a named constant with a comment? Yes, changed to use ThreadIdentifier::initial(). > src/hotspot/share/runtime/vframe.inline.hpp line 130: > >> 128: // Waited event after target vthread was preempted. Since all continuation frames >> 129: // are freezed we get the top frame from the stackChunk instead. >> 130: _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map); > > What happens if we don't do this? That might help explain why we are doing this. We would walk the carrier thread frames instead of the vthread ones. > src/hotspot/share/services/threadService.cpp line 467: > >> 465: if (waitingToLockMonitor->has_owner()) { >> 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); >> 467: } > > Please explain why it is safe to remvoe the above code. Yes, I should have added a comment here. The previous code assumed that if the monitor had an owner but it was not findable it meant the previous currentThread will be blocked permanently and so we recorded this as a deadlock. With these changes, the owner could be not findable because it is an unmounted vthread. There is currently no fast way to determine if that's the case so we never record this as a deadlock. Now, unless there is a bug in the VM, or a thread exits without releasing monitors acquired through JNI, unfindable owner should imply an unmounted vthread. I added a comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442387426 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819473410 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819465574 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819592799 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819466532 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819472086 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819481705 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821393856 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591515 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593810 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821592920 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591143 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593351 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823505700 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591930 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594779 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821595264 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695166 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695964 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821697629 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698318 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698705 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823509538 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821699155 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828187178 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823486049 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823487296 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823488795 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823511520 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823502075 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823503636 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824792648 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793200 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824791832 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793737 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825208611 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825210260 From dlong at openjdk.org Wed Nov 6 17:40:00 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com> On Mon, 28 Oct 2024 18:58:29 GMT, Patricio Chilano Mateo wrote: > regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption. Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption? It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards? We aren't doing the monitor check atomically, so the monitor could get released right after we check it. So I'm guessing we choose to check after freeze because freeze has non-trivial overhead. >> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159: >> >>> 157: >>> 158: // The interpreter native wrapper code adds space in the stack equal to size_of_parameters() >>> 159: // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter). >> >> Suggestion: >> >> // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter). >> >> Isn't that 2 words, not 3? > > The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347 > I don't know why we do that for 64 bits. OK, I think there are historical or technical reasons why it's hard to change, because of the way the JVM spec is written. >> src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77: >> >>> 75: // Interpreter frames >>> 76: interpreter_frame_result_handler_offset = 3, // for native calls only >>> 77: interpreter_frame_oop_temp_offset = 2, // for native calls only >> >> This conflicts with sender_sp_offset. Doesn't that cause a problem? > > No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one. `sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed. Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"? >> src/hotspot/cpu/x86/interp_masm_x86.cpp line 359: >> >>> 357: push_cont_fastpath(); >>> 358: >>> 359: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >> >> From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening. The push/pop of rscratch1 doesn't seem to be doing anything. > > Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it: https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658 OK, I was looking for where it stores it in the anchor, but it doesn't, at least not until make_walkable() is called. >> src/hotspot/share/code/nmethod.cpp line 1302: >> >>> 1300: _compiler_type = type; >>> 1301: _orig_pc_offset = 0; >>> 1302: _num_stack_arg_slots = 0; >> >> Was the old value wrong, unneeded, or is this set somewhere else? If this field is not used, then we might want to set it to an illegal value in debug builds. > > We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods. Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change? I think this change should be reverted. If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used. However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right. >> src/hotspot/share/runtime/continuation.hpp line 50: >> >>> 48: class JavaThread; >>> 49: >>> 50: // should match Continuation.PreemptStatus() in Continuation.java >> >> As far as I can tell, these enum values still don't match the Java values. If they need to match, then maybe there should be asserts that check that. > > `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead. Yes, that would be better for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442880740 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819705281 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821524020 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821705135 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823572138 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823584967 From michaelm at openjdk.org Wed Nov 6 17:40:00 2024 From: michaelm at openjdk.org (Michael McMahon) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I have reviewed the changes to the NIO selector/poller implementations and they look fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2444268747 From pchilanomate at openjdk.org Wed Nov 6 17:40:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com> References: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com> Message-ID: On Mon, 28 Oct 2024 23:46:09 GMT, Dean Long wrote: > > regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption. > > Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption? It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards? We aren't doing the monitor check atomically, so the monitor could get released right after we check it. So I'm guessing we choose to check after freeze because freeze has non-trivial overhead. > After adding the ObjectWaiter to the _cxq we always have to retry acquiring the monitor; this is the same for platform threads. So freezing before that, implies we have to retry. As for whether we need to cancel the preemption if we acquire the monitor, not necessarily. We could still unmount with a state of YIELDING, so the virtual thread will be scheduled to run again. So that part is an optimization to avoid the unmount. >> No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one. > > `sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed. Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"? I think aarch64 is the correct one. For interpreter frames we also have a sender_sp() that we get through that offset value: https://github.com/openjdk/jdk/blob/7404ddf24a162cff445cd0a26aec446461988bc8/src/hotspot/cpu/x86/frame_x86.cpp#L458 I think the confusion is because we also have interpreter_frame_sender_sp_offset where we store the unextended sp. >> We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods. > > Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change? I think this change should be reverted. If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used. However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right. Any compiled native frame would still require a value of zero. This field should be read as the size of the argument area in the caller frame that this method(callee) might access during execution. That's why we set it to zero for OSR nmethods too. The thaw code uses this value to see if we need to thaw a compiled frame with stack arguments that reside in the caller frame. The freeze code also uses it to check for overlap and avoid copying these arguments twice. Currently we have a case for "nmethods" when reading this value, which includes both Java and native. I'd rather not add branches to separate these cases, specially given that we already have this field available in the nmethod class. >> `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead. > > Yes, that would be better for now. Changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2445106760 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823495787 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824785565 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824788898 From alanb at openjdk.org Wed Nov 6 17:40:00 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 03:52:31 GMT, Dean Long wrote: > For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java. Is there a way to fix that? I don't know which view this is but just to say that VirtualThreadPinnedEvent.java and libTracePinnedThreads.c are removed. libSynchronizedNative.c is part of a new test (as it happens, it was previously reviewed as pull/18600 but we had to hold it back as it needed a fix from the loom repo that is part of the JEP 491 implementation). You find is easier to just fetch and checkout the branch to look at the changes locally. Personally I have this easier for large change and makes it easier to see renames and/or removals. > src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108: > >> 106: processDeregisterQueue(); >> 107: >> 108: if (Thread.currentThread().isVirtual()) { > > It looks like we have two implementations, depending on if the current thread is virtual or not. The two implementations differ in the way they signal interrupted. Can we unify the two somehow? When executed on a platform thread is will block in epoll_wait or kqueue so it has to handle EINTR. It doesn't block in sys call when executed in a virtual thread. So very different implementations. > src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57: > >> 55: static { >> 56: try { >> 57: MethodHandles.lookup().ensureInitialized(AnchorCertificates.class); > > Why is this needed? A comment would help. That's probably a good idea. It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority. > test/hotspot/gtest/nmt/test_vmatree.cpp line 34: > >> 32: >> 33: using Tree = VMATree; >> 34: using TNode = Tree::TreapNode; > > Why is this needed? We had to rename the alias to avoid a conflict with the Node in compile.hpp. Just lucky not to run into this in main-line. It comes and goes, depends on changes to header files that are transitively included by the test. I think Johan had planned to change this in main line but it may have got forgotten. > test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42: > >> 40: * -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep >> 41: * -XX:CompileCommand=exclude,java.lang.Thread::afterSleep >> 42: * -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos > > I'm guessing these changes have something to do with JDK-8279653? It should have been added when Thread.sleep was changed but we got lucky. > test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73: > >> 71: /* ========================================================================== */ >> 72: >> 73: static int prepare(JNIEnv* jni) { > > Is this a bug fix? Testing ran into a couple of bugs in JVMTI tests. One of was tests that was stashing the JNIEnv into a static. > test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30: > >> 28: * by reflection API >> 29: * @library /test/lib/ >> 30: * @requires vm.compMode != "Xcomp" > > If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix. JBS has several issues related to ReflectionCallerCacheTest.java and -Xcomp, going back several releases. It seems some nmethod is keeping objects alive and is preventing class unloading in this test. The refactoring of j.l.ref in JDK 19 to workaround pinning issues made it go away. There is some minimal revert in this PR to deal with the potential for preemption when polling a reference queue and it seems the changes to this Java code have brought back the issue. So it's excluded from -Xcomp again. Maybe it would be better to add it to ProblemList-Xcomp.txt instead? That would allow it to link to one of the JSB issue on this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2449153774 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825115214 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825127591 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825121520 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825112326 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825110254 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817692430 From pchilanomate at openjdk.org Wed Nov 6 17:40:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... I brought a small fix to the heap dump code from the loom repo for an issue found recently. It includes a reproducer test. I brought some JFR changes from the loom repo that improve the reported reason when pinning. @mgronlun @egahlin Could any of you review these JFR changes? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2455431391 PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2456054504 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <8bSr_dBqhXkGBdKhm3qO4j1XJHBtu_RkeIH8ldtDAVA=.bd6692e9-93aa-46cf-b9de-75b06d83dd73@github.com> On Tue, 5 Nov 2024 01:47:29 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > I brought some JFR changes from the loom repo that improve the reported reason when pinning. > @mgronlun @egahlin Could any of you review these JFR changes? Thanks. > Hi @pchilano, > > I see couple of failures on s390x, can you apply this patch: > Thanks @offamitkumar. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2457338726 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 17:31:45 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188: >> >>> 186: // Avoid using a leave instruction when this frame may >>> 187: // have been frozen, since the current value of rfp >>> 188: // restored from the stub would be invalid. We still >> >> It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem? >> Do we actually need FP set by the enter() prologue for stubs? If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs. We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away. > >>It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem? >> > Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough. > Do we actually need FP set by the enter() prologue for stubs? If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs. We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away. > I think we need it for the pending exception case. I see we use rfp to get the exception pc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819474263 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 21 Oct 2024 06:38:28 GMT, Axel Boldt-Christmas wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231: > >> 229: >> 230: StubFrame::~StubFrame() { >> 231: __ epilogue(_use_pop_on_epilogue); > > Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return? > e.g. > ```C++ > enum return_state_t { > does_not_return, requires_return, requires_pop_epilogue_return > }; > > StubFrame::~StubFrame() { > if (_return_state == does_not_return) { > __ should_not_reach_here(); > } else { > __ epilogue(_return_state == requires_pop_epilogue_return); > } > } Yes, that's much better. I changed it in both aarch64 and riscv. > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115: > >> 113: // The object's monitor m is unlocked iff m->owner == nullptr, >> 114: // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY, >> 115: // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT. > > Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code. I removed this comment about what other values might be stored in _owner since we don't need to handle those cases here. > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380: > >> 378: lea(t2_owner_addr, owner_address); >> 379: >> 380: // CAS owner (null => current thread id). > > I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. > > Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion) Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300: > >> 298: CodeBlob* cb = top.cb(); >> 299: >> 300: if (cb->frame_size() == 2) { > > Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size. We could also check the caller of the runtime frame, something like: #ifdef ASSERT RegisterMap map(JavaThread::current(), RegisterMap::UpdateMap::skip, RegisterMap::ProcessFrames::skip, RegisterMap::WalkContinuation::skip); frame caller = top.sender(&map); assert(caller.is_compiled_frame(), ""); assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), ""); #endif Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame. > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313: > >> 311: >> 312: log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT >> 313: " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]); > > Is there a reason for the mix of `2` and `frame::metadata_words`? > > Maybe this could be > ```C++ > intptr_t* const unadjusted_sp = sp; > sp -= frame::metadata_words; > sp[-2] = unadjusted_sp[-2]; > sp[-1] = unadjusted_sp[-1]; > > log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT > " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]); I removed the use of frame::metadata_words from the log statement instead to make it consistent, since we would still implicitly be assuming metadata_words it's 2 words when we do the copying. We could use a memcpy and refer to metadata_words, but I think it is clear this way since we are explicitly talking about the 2 extra words missing from the runtime frame as the comment explains. > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275: > >> 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) { >> 1274: ::continuation_enter_cleanup(masm); >> 1275: } > > Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function. Since we have 3 free static functions to handle the continuation entry(create, fill, cleanup) I would prefer to keep the cleanup one for consistency. We could also change them all to be members of SharedRuntime. But except for the exception I added for continuation_enter_cleanup(), all these are called by gen_continuation_enter/gen_continuation_yield() which are also static free functions. > src/hotspot/cpu/x86/assembler_x86.cpp line 2866: > >> 2864: emit_int32(0); >> 2865: } >> 2866: } > > Is it possible to make this more general and explicit instead of a sequence of bytes? > > Something along the lines of: > ```C++ > const address tar = L.is_bound() ? target(L) : pc(); > const Address adr = Address(checked_cast(tar - pc()), tar, relocInfo::none); > > InstructionMark im(this); > emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D); > if (!L.is_bound()) { > // Patch @0x8D opcode > L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect())); > } > // Register and [rip+disp] operand > emit_modrm(0b00, raw_encode(dst), 0b101); > // Adjust displacement by sizeof lea instruction > int32_t disp = adr.disp() - checked_cast(pc() - inst_mark() + sizeof(int32_t)); > assert(is_simm32(disp), "must be 32bit offset [rip+offset]"); > emit_int32(disp); > > > and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`. I'll test it out but looks fine. > src/hotspot/share/oops/stackChunkOop.cpp line 445: > >> 443: >> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) { >> 445: const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); > > Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. > > There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw. Good, passed as argument now. > src/hotspot/share/oops/stackChunkOop.cpp line 460: > >> 458: } else { >> 459: oop value = *reinterpret_cast(at); >> 460: HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); > > Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). > So either use `*reinterpret_cast(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless. Ok, I just omitted clearing the oop. > src/hotspot/share/oops/stackChunkOop.cpp line 471: > >> 469: } >> 470: } >> 471: } > > Can we turn these three very similar loops into one? In my opinion, it is easier to parse. > > ```C++ > void stackChunkOopDesc::copy_lockstack(oop* dst) { > const int cnt = lockstack_size(); > const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); > const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops; > const auto get_obj = [&](intptr_t* at) -> oop { > if (requires_gc_barriers) { > if (requires_uncompress) { > return HeapAccess<>::oop_load(reinterpret_cast(at)); > } > return HeapAccess<>::oop_load(reinterpret_cast(at)); > } > return *reinterpret_cast(at); > }; > > intptr_t* lockstack_start = start_address(); > for (int i = 0; i < cnt; i++) { > oop mon_owner = get_obj(&lockstack_start[i]); > assert(oopDesc::is_oop(mon_owner), "not an oop"); > dst[i] = mon_owner; > } > } Done. I combined it with the oop clearing suggestion. > src/hotspot/share/prims/jvmtiExport.cpp line 1681: > >> 1679: EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread)); >> 1680: >> 1681: // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop. > > Suggestion: > > // On preemption JVMTI state rebinding has already happened so get it always directly from the oop. Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234: > >> 2232: retry_fast_path = true; >> 2233: } else { >> 2234: relativize_chunk_concurrently(chunk); > > Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? > > While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack. Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t? > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247: > >> 2245: _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize); >> 2246: >> 2247: chunk->set_lockstack_size(0); > > After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line. > > Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops. > > > diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp > index d3d63533eed..f737bd2db71 100644 > --- a/src/hotspot/share/oops/stackChunkOop.cpp > +++ b/src/hotspot/share/oops/stackChunkOop.cpp > @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) { > } > } > > +void stackChunkOopDesc::clear_lockstack() { > + const int cnt = lockstack_size(); > + const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); > + const bool requires_uncompress = has_bitmap() && UseCompressedOops; > + const auto clear_obj = [&](intptr_t* at) { > + if (requires_uncompress) { > + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); > + } else { > + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); > + } > + }; > + > + if (requires_gc_barriers) { > + intptr_t* lockstack_start = start_address(); > + for (int i = 0; i < cnt; i++) { > + clear_obj(&lockstack_start[i]); > + } > + } > + set_lockstack_size(0); > + set_has_lockstack(false); > +} > + > void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const { > if (*((juint*)this) == badHeapWordVal) { > st->print_cr("BAD WORD"); > diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp > index 28e0576801e..928e94dd695 100644 > --- a/src/hotspot/share/oops/stackChunkOop.hpp > +++ b/src/hotspot/share/oops/stackChunkOop.hpp > @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc { > void fix_thawed_frame(const frame& f, const RegisterMapT* map); > > void copy_lockstack(oop* start); > + void clear_lockstack(); > > template src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538: > >> 2536: Method* m = hf.interpreter_frame_method(); >> 2537: // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler). >> 2538: const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2; > > Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places. I reverted this change and added an assert instead, since for native methods we always thaw the caller too, i.e. it will not be the bottom frame. I added a comment in the other two references for the extra native slots in continuationFreezeThaw_x86.inline.hpp. > src/hotspot/share/runtime/frame.cpp line 535: > >> 533: assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address"); >> 534: return thread_addr; >> 535: #endif > > With this ifdef, it seems like this belongs in the platform dependent part of the frame class. I moved it to the platform dependent files. > src/hotspot/share/runtime/objectMonitor.hpp line 184: > >> 182: // - We test for anonymous owner by testing for the lowest bit, therefore >> 183: // DEFLATER_MARKER must *not* have that bit set. >> 184: static const int64_t DEFLATER_MARKER = 2; > > The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch). Removed the comments. > src/hotspot/share/runtime/objectMonitor.hpp line 186: > >> 184: static const int64_t DEFLATER_MARKER = 2; >> 185: >> 186: int64_t volatile _owner; // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER. > > Suggestion: > > int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. Fixed. > src/hotspot/share/runtime/objectMonitor.inline.hpp line 50: > >> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) { >> 49: int64_t tid = java_lang_Thread::thread_id(vthread); >> 50: assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable"); > > Suggestion: > > assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable"); Fixed. > src/hotspot/share/runtime/synchronizer.cpp line 1467: > >> 1465: markWord dmw = inf->header(); >> 1466: assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value()); >> 1467: if (inf->is_owner_anonymous() && inflating_thread != nullptr) { > > Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze? Yes, it's just a consequence of using tid as the owner, not really related to freezing. So when a thread inflates a monitor that is already owned we cannot store the BasicLock* in the _owner field anymore, since it can clash with some tid, so we mark it as anonymously owned instead. The owner will fix it here when trying to get the monitor, as we do with LM_LIGHTWEIGHT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809745804 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746249 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746397 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809753868 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809747046 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749481 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749657 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826149674 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826148888 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813222417 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749805 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244844 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244206 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823317839 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750408 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750552 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750685 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830229529 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809754940 From aph at openjdk.org Wed Nov 6 17:40:01 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60: > >> 58: >> 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight"); >> 60: assert_different_registers(oop, box, tmp, disp_hdr, rscratch2); > > Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. > Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. Note also that `inc_held_monitor_count` clobbers `rscratch2`. That might be worth a comment at the call site. I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810985771 From aph at openjdk.org Wed Nov 6 17:40:01 2024 From: aph at openjdk.org (Andrew Haley) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:48:43 GMT, Andrew Haley wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60: >> >>> 58: >>> 59: assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight"); >>> 60: assert_different_registers(oop, box, tmp, disp_hdr, rscratch2); >> >> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. >> Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. > > Note also that `inc_held_monitor_count` clobbers `rscratch2`. That might be worth a comment at the call site. > I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing. > Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. Hmm, forget that. It's rather tricky code, that's true, but I think we're OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810998545 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:56:21 GMT, Andrew Haley wrote: >> Note also that `inc_held_monitor_count` clobbers `rscratch2`. That might be worth a comment at the call site. >> I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing. > >> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility. > > Hmm, forget that. It's rather tricky code, that's true, but I think we're OK. I see we are already using rscratch1 in these locking macros so I could change it to use that instead. But looking at all other macros in this file we are already using rscratch1 and rscratch2 too, so I think we would be fine either way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813513144 From coleenp at openjdk.org Wed Nov 6 17:40:01 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 02:09:33 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380: >> >>> 378: lea(t2_owner_addr, owner_address); >>> 379: >>> 380: // CAS owner (null => current thread id). >> >> I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. >> >> Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion) > > Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do. yes, we preferred lock_id here which is the same as the Java version of thread id, but not the same as the os thread-id. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811583503 From pchilanomate at openjdk.org Wed Nov 6 17:40:01 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 22:59:19 GMT, Coleen Phillimore wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135: > >> 133: assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame"); >> 134: intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset); >> 135: *lspp = f.unextended_sp() - f.fp(); > > Can you write a comment what this is doing briefly and why? Added comment. > src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550: > >> 1548: #endif /* ASSERT */ >> 1549: >> 1550: push_cont_fastpath(); > > One of the callers of this gives a clue what it does. > > __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about > > Why do you do this here? Oh please more comments... _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment. > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354: > >> 5352: str(rscratch2, dst); >> 5353: Label ok; >> 5354: tbz(rscratch2, 63, ok); > > 63? Does this really need to have underflow checking? That would alleviate the register use concerns if it didn't. And it's only for legacy locking which should be stable until it's removed. I can remove the check. I don't think it hurts either though. Also we can actually just use rscratch1 in the ASSERT case. > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032: > >> 2030: // Force freeze slow path in case we try to preempt. We will pin the >> 2031: // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()). >> 2032: __ push_cont_fastpath(); > > We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do? Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack. > src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231: > >> 229: >> 230: void MacroAssembler::inc_held_monitor_count(Register tmp) { >> 231: Address dst = Address(xthread, JavaThread::held_monitor_count_offset()); > > Address dst(xthread, JavaThread::held_monitor_count_offset()); Done. > src/hotspot/share/interpreter/oopMapCache.cpp line 268: > >> 266: } >> 267: >> 268: int num_oops() { return _num_oops; } > > I can't find what uses this from OopMapCacheEntry. It's needed for verification in VerifyStackChunkFrameClosure. It's called in OopMapCacheEntry::fill_for_native(), and we get there from here: https://github.com/openjdk/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp#L114 > src/hotspot/share/runtime/continuation.cpp line 89: > >> 87: // we would incorrectly throw it during the unmount logic in the carrier. >> 88: if (_target->has_async_exception_condition()) { >> 89: _failed = false; > > This says "Don't" but then failed is false which doesn't make sense. Should it be true? Yes, good catch. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275: > >> 1273: >> 1274: if (caller.is_interpreted_frame()) { >> 1275: _total_align_size += frame::align_wiggle; > > Please put a comment here about frame align-wiggle. I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278: > >> 1276: } >> 1277: >> 1278: patch(f, hf, caller, false /*is_bottom_frame*/); > > I also forgot what patch does. Can you add a comment here too? I added a comment where it is defined since it is used in several places. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1550: > >> 1548: assert(!cont.is_empty(), ""); >> 1549: // This is done for the sake of the enterSpecial frame >> 1550: StackWatermarkSet::after_unwind(thread); > > Is there a new place for this StackWatermark code? I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235: > >> 2233: assert(!mon_acquired || mon->has_owner(_thread), "invariant"); >> 2234: if (!mon_acquired) { >> 2235: // Failed to aquire monitor. Return to enterSpecial to unmount again. > > typo: acquire Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492: > >> 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) { >> 2491: ContinuationWrapper::SafepointOp so(current, _cont); >> 2492: // Since we might safepoint set the anchor so that the stack can we walked. > > typo: can be walked Fixed. > src/hotspot/share/runtime/javaThread.hpp line 334: > >> 332: bool _pending_jvmti_unmount_event; // When preempting we post unmount event at unmount end rather than start >> 333: bool _on_monitor_waited_event; // Avoid callee arg processing for enterSpecial when posting waited event >> 334: ObjectMonitor* _contended_entered_monitor; // Monitor por pending monitor_contended_entered callback > > typo: Monitor **for** pending_contended_entered callback Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 876: > >> 874: // and in doing so avoid some transitions ... >> 875: >> 876: // For virtual threads that are pinned do a timed-park instead, to > > I had trouble parsing this first sentence. I think it needs a comma after pinned and remove the comma after instead. Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 2305: > >> 2303: } >> 2304: >> 2305: void ObjectMonitor::Initialize2() { > > Can you put a comment why there's a second initialize function? Presumably after some state is set. Added comment. > src/hotspot/share/runtime/objectMonitor.hpp line 43: > >> 41: // ParkEvent instead. Beware, however, that the JVMTI code >> 42: // knows about ObjectWaiters, so we'll have to reconcile that code. >> 43: // See next_waiter(), first_waiter(), etc. > > Also a nice cleanup. Did you reconcile the JVMTI code? We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage. > src/hotspot/share/runtime/objectMonitor.hpp line 71: > >> 69: bool is_wait() { return _is_wait; } >> 70: bool notified() { return _notified; } >> 71: bool at_reenter() { return _at_reenter; } > > should these be const member functions? Yes, changed to const. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816658344 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660065 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813516395 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660542 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813519648 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819462987 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660817 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661388 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661733 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662247 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583906 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583954 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583822 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662554 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816663065 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463651 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463958 From dlong at openjdk.org Wed Nov 6 17:40:01 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:01 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 02:18:19 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300: >> >>> 298: CodeBlob* cb = top.cb(); >>> 299: >>> 300: if (cb->frame_size() == 2) { >> >> Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size. > > We could also check the caller of the runtime frame, something like: > > #ifdef ASSERT > RegisterMap map(JavaThread::current(), > RegisterMap::UpdateMap::skip, > RegisterMap::ProcessFrames::skip, > RegisterMap::WalkContinuation::skip); > frame caller = top.sender(&map); > assert(caller.is_compiled_frame(), ""); > assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), ""); > #endif > > Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame. I agree, checking for frame_size() == 2 seems fragile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817458483 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 00:27:25 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310: > >> 308: sp -= 2; >> 309: sp[-2] = sp[0]; >> 310: sp[-1] = sp[1]; > > This also seems fragile. This seems to depend on an intimate knowledge of what the stub will do when returning. We don't need this when doing a regular return from the native call, so why do we need it here? I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects. Why is this needed for C2 and not C1? Could the problem be solved with a resume adapter instead, like the interpreter uses? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817556946 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 01:58:30 GMT, Dean Long wrote: >> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310: >> >>> 308: sp -= 2; >>> 309: sp[-2] = sp[0]; >>> 310: sp[-1] = sp[1]; >> >> This also seems fragile. This seems to depend on an intimate knowledge of what the stub will do when returning. We don't need this when doing a regular return from the native call, so why do we need it here? I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects. Why is this needed for C2 and not C1? > > Could the problem be solved with a resume adapter instead, like the interpreter uses? The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it). One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819593485 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 18:56:25 GMT, Patricio Chilano Mateo wrote: >> Could the problem be solved with a resume adapter instead, like the interpreter uses? > > The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it). > One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization. > Could the problem be solved with a resume adapter instead, like the interpreter uses? > It will just move the task of adjusting the size of the frame somewhere else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819594475 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 18:56:58 GMT, Patricio Chilano Mateo wrote: >> The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it). >> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization. > >> Could the problem be solved with a resume adapter instead, like the interpreter uses? >> > It will just move the task of adjusting the size of the frame somewhere else. > One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state. So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor? Then freeze could assert that the thread is already walkable. I'm surprised it doesn't already. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819896849 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 23:38:43 GMT, Dean Long wrote: >>> Could the problem be solved with a resume adapter instead, like the interpreter uses? >>> >> It will just move the task of adjusting the size of the frame somewhere else. > >> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. > > If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state. So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor? Then freeze could assert that the thread is already walkable. I'm surprised it doesn't already. The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like: 0xffffdfdba584: sub sp, sp, #0x10 0xffffdfdba588: stp x29, x30, [sp] 0xffffdfdba58c: ldrb w8, [x28, #1192] 0xffffdfdba590: cbz x8, 0xffffdfdba5a8 0xffffdfdba594: mov x8, #0x4ba0 0xffffdfdba598: movk x8, #0xf6a8, lsl #16 0xffffdfdba59c: movk x8, #0xffff, lsl #32 0xffffdfdba5a0: mov x0, x28 0xffffdfdba5a4: blr x8 0xffffdfdba5a8: mov x9, sp 0xffffdfdba5ac: str x9, [x28, #1000] <------- store last_Java_sp 0xffffdfdba5b0: mov x0, x1 0xffffdfdba5b4: mov x1, x2 0xffffdfdba5b8: mov x2, x28 0xffffdfdba5bc: adr x9, 0xffffdfdba5d4 0xffffdfdba5c0: mov x8, #0xe6a4 0xffffdfdba5c4: movk x8, #0xf717, lsl #16 0xffffdfdba5c8: movk x8, #0xffff, lsl #32 0xffffdfdba5cc: stp xzr, x9, [sp, #-16]! <------- Push two extra words 0xffffdfdba5d0: blr x8 0xffffdfdba5d4: nop 0xffffdfdba5d8: movk xzr, #0x0 0xffffdfdba5dc: movk xzr, #0x0 0xffffdfdba5e0: add sp, sp, #0x10 <------- Remove two extra words 0xffffdfdba5e4: str xzr, [x28, #1000] 0xffffdfdba5e8: str xzr, [x28, #1008] 0xffffdfdba5ec: ldr x10, [x28, #8] 0xffffdfdba5f0: cbnz x10, 0xffffdfdba600 0xffffdfdba5f4: ldp x29, x30, [sp] 0xffffdfdba5f8: add sp, sp, #0x10 0xffffdfdba5fc: ret 0xffffdfdba600: ldp x29, x30, [sp] 0xffffdfdba604: add sp, sp, #0x10 0xffffdfdba608: adrp x8, 0xffffdfc30000 0xffffdfdba60c: add x8, x8, #0x80 0xffffdfdba610: br x8 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821389434 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 19:01:03 GMT, Patricio Chilano Mateo wrote: >>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. >> >> If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state. So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor? Then freeze could assert that the thread is already walkable. I'm surprised it doesn't already. > > The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like: > > > 0xffffdfdba584: sub sp, sp, #0x10 > 0xffffdfdba588: stp x29, x30, [sp] > 0xffffdfdba58c: ldrb w8, [x28, #1192] > 0xffffdfdba590: cbz x8, 0xffffdfdba5a8 > 0xffffdfdba594: mov x8, #0x4ba0 > 0xffffdfdba598: movk x8, #0xf6a8, lsl #16 > 0xffffdfdba59c: movk x8, #0xffff, lsl #32 > 0xffffdfdba5a0: mov x0, x28 > 0xffffdfdba5a4: blr x8 > 0xffffdfdba5a8: mov x9, sp > 0xffffdfdba5ac: str x9, [x28, #1000] <------- store last_Java_sp > 0xffffdfdba5b0: mov x0, x1 > 0xffffdfdba5b4: mov x1, x2 > 0xffffdfdba5b8: mov x2, x28 > 0xffffdfdba5bc: adr x9, 0xffffdfdba5d4 > 0xffffdfdba5c0: mov x8, #0xe6a4 > 0xffffdfdba5c4: movk x8, #0xf717, lsl #16 > 0xffffdfdba5c8: movk x8, #0xffff, lsl #32 > 0xffffdfdba5cc: stp xzr, x9, [sp, #-16]! <------- Push two extra words > 0xffffdfdba5d0: blr x8 > 0xffffdfdba5d4: nop > 0xffffdfdba5d8: movk xzr, #0x0 > 0xffffdfdba5dc: movk xzr, #0x0 > 0xffffdfdba5e0: add sp, sp, #0x10 <------- Remove two extra words > 0xffffdfdba5e4: str xzr, [x28, #1000] > 0xffffdfdba5e8: str xzr, [x28, #1008] > 0xffffdfdba5ec: ldr x10, [x28, #8] > 0xffffdfdba5f0: cbnz x10, 0xffffdfdba600 > 0xffffdfdba5f4: ldp x29, x30, [sp] > 0xffffdfdba5f8: add sp, sp, #0x10 > 0xffffdfdba5fc: ret > 0xffffdfdba600: ldp x29, x30, [sp] > 0xffffdfdba604: add sp, sp, #0x10 > 0xffffdfdba608: adrp x8, 0xffffdfc30000 > 0xffffdfdba60c: add x8, x8, #0x80 > 0xffffdfdba610: br x8 OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest. Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling. It's still unclear to me exactly how we resume after preemption. It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted. If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment. In your example, last_Java_pc would be set to 0xffffdfdba5e4. I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823701666 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 02:33:30 GMT, Dean Long wrote: > OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? > It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824782389 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo wrote: >> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest. Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling. >> >> It's still unclear to me exactly how we resume after preemption. It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted. If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment. In your example, last_Java_pc would be set to 0xffffdfdba5e4. I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments. > >> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? >> > It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825498409 From dlong at openjdk.org Wed Nov 6 17:40:02 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long wrote: >>> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed? >>> >> It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method. > > It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. Here's my suggested C2 change: diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad index d9c77a2f529..1e99db191ae 100644 --- a/src/hotspot/cpu/aarch64/aarch64.ad +++ b/src/hotspot/cpu/aarch64/aarch64.ad @@ -3692,14 +3692,13 @@ encode %{ __ post_call_nop(); } else { Label retaddr; + // Make the anchor frame walkable __ adr(rscratch2, retaddr); + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); __ lea(rscratch1, RuntimeAddress(entry)); - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); __ blr(rscratch1); __ bind(retaddr); __ post_call_nop(); - __ add(sp, sp, 2 * wordSize); } if (Compile::current()->max_vector_size() > 0) { __ reinitialize_ptrue(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826252551 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long wrote: >> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes. Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative. > > Here's my suggested C2 change: > > diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad > index d9c77a2f529..1e99db191ae 100644 > --- a/src/hotspot/cpu/aarch64/aarch64.ad > +++ b/src/hotspot/cpu/aarch64/aarch64.ad > @@ -3692,14 +3692,13 @@ encode %{ > __ post_call_nop(); > } else { > Label retaddr; > + // Make the anchor frame walkable > __ adr(rscratch2, retaddr); > + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); > __ lea(rscratch1, RuntimeAddress(entry)); > - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() > - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); > __ blr(rscratch1); > __ bind(retaddr); > __ post_call_nop(); > - __ add(sp, sp, 2 * wordSize); > } > if (Compile::current()->max_vector_size() > 0) { > __ reinitialize_ptrue(); Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. @RealFYang I made the equivalent change for riscv, could you verify it's okay? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828186069 From fyang at openjdk.org Wed Nov 6 17:40:02 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo wrote: >> Here's my suggested C2 change: >> >> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad >> index d9c77a2f529..1e99db191ae 100644 >> --- a/src/hotspot/cpu/aarch64/aarch64.ad >> +++ b/src/hotspot/cpu/aarch64/aarch64.ad >> @@ -3692,14 +3692,13 @@ encode %{ >> __ post_call_nop(); >> } else { >> Label retaddr; >> + // Make the anchor frame walkable >> __ adr(rscratch2, retaddr); >> + __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset())); >> __ lea(rscratch1, RuntimeAddress(entry)); >> - // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc() >> - __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize))); >> __ blr(rscratch1); >> __ bind(retaddr); >> __ post_call_nop(); >> - __ add(sp, sp, 2 * wordSize); >> } >> if (Compile::current()->max_vector_size() > 0) { >> __ reinitialize_ptrue(); > > Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. > @RealFYang I made the equivalent change for riscv, could you verify it's okay? @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup! `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform. BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2 Do you mind adding following small addon change to fix it? Thanks. diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp index 84a292242c3..ac28f4b3514 100644 --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { if (LockingMode != LM_LEGACY) { // Check preemption for Object.wait() Label not_preempted; - __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset())); - __ beqz(t0, not_preempted); + __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset())); + __ beqz(t1, not_preempted); __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset())); - __ jr(t0); + __ jr(t1); __ bind(native_return); __ restore_after_resume(true /* is_native */); // reload result_handler ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828797495 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 06:30:55 GMT, Fei Yang wrote: >> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code. >> @RealFYang I made the equivalent change for riscv, could you verify it's okay? > > @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup! > `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform. > > BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2 > Do you mind adding following small addon change to fix it? Thanks. > > diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > index 84a292242c3..ac28f4b3514 100644 > --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp > @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) { > if (LockingMode != LM_LEGACY) { > // Check preemption for Object.wait() > Label not_preempted; > - __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset())); > - __ beqz(t0, not_preempted); > + __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset())); > + __ beqz(t1, not_preempted); > __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset())); > - __ jr(t0); > + __ jr(t1); > __ bind(native_return); > __ restore_after_resume(true /* is_native */); > // reload result_handler Thanks for checking. Added changes to `TemplateInterpreterGenerator::generate_native_entry`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829457335 From dholmes at openjdk.org Wed Nov 6 17:40:02 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 13:11:18 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550: >> >>> 1548: #endif /* ASSERT */ >>> 1549: >>> 1550: push_cont_fastpath(); >> >> One of the callers of this gives a clue what it does. >> >> __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about >> >> Why do you do this here? Oh please more comments... > > _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment. It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ??? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245043 From pchilanomate at openjdk.org Wed Nov 6 17:40:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:02 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com> On Mon, 28 Oct 2024 00:53:40 GMT, David Holmes wrote: >> _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment. > > It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ??? Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819831895 From coleenp at openjdk.org Wed Nov 6 17:40:03 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com> References: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com> Message-ID: On Mon, 28 Oct 2024 22:04:23 GMT, Patricio Chilano Mateo wrote: >> It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ??? > > Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here. Yes the comment did seem to contradict the name of the function. But it's something we can re-examine at some later time. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819858784 From dlong at openjdk.org Wed Nov 6 17:40:03 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com> On Sat, 26 Oct 2024 06:51:08 GMT, Richard Reingruber wrote: >> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555: >> >>> 1553: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >>> 1554: adr(rscratch1, resume_pc); >>> 1555: str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset())); >> >> Is it really needed to set an alternative last_Java_pc()? I couldn't find where it's used in a way that would require a different value. > > Its indeed difficult to see how the value is propagaged. I think it goes like this: > > - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517 > - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99 > - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177 > - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771 Thanks, that's what I was missing. >> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567: >> >>> 1565: >>> 1566: // In case of preemption, this is where we will resume once we finally acquire the monitor. >>> 1567: bind(resume_pc); >> >> If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above? > > The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack. > > At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack. OK, that makes sense now. >> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796: >> >>> 3794: __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset())); >>> 3795: __ testbool(rscratch1); >>> 3796: __ jcc(Assembler::notZero, preemption_cancelled); >> >> If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called. Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called? > > The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again. If preemption was cancelled, we skip over the cleanup. The native frames haven't been unwound yet. So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)? It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled. Some some finalize actions would be delated, like a two-stage commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819586705 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819605366 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819657858 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <793XB62tkVT9w5ix7Ie1Hhxse4WnmnA7baNi__fs0Dw=.b1b308d9-8e8e-4d1d-8cd3-935c637679ab@github.com> On Wed, 23 Oct 2024 05:56:48 GMT, Axel Boldt-Christmas wrote: >> Also, is it better to have this without assignment. Which is a nit. >> Address dst(rthread, JavaThread::held_monitor_count_offset()); > > The `=` in a variable definition is always construction, never assignment. > > That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information. Added comment and fixed dst definition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813514402 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:50:15 GMT, Andrew Haley wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357: > >> 5355: >> 5356: void MacroAssembler::dec_held_monitor_count() { >> 5357: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); > > Suggestion: > > // Clobbers: rscratch1 and rscratch2 > void MacroAssembler::dec_held_monitor_count() { > Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); Added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813515113 From aboldtch at openjdk.org Wed Nov 6 17:40:03 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 00:08:54 GMT, Coleen Phillimore wrote: >> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341: >> >>> 5339: >>> 5340: void MacroAssembler::inc_held_monitor_count() { >>> 5341: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); >> >> Suggestion: >> >> // Clobbers: rscratch1 and rscratch2 >> void MacroAssembler::inc_held_monitor_count() { >> Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); > > Also, is it better to have this without assignment. Which is a nit. > Address dst(rthread, JavaThread::held_monitor_count_offset()); The `=` in a variable definition is always construction, never assignment. That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811925424 From rrich at openjdk.org Wed Nov 6 17:40:03 2024 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 01:40:41 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555: > >> 1553: // Make VM call. In case of preemption set last_pc to the one we want to resume to. >> 1554: adr(rscratch1, resume_pc); >> 1555: str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset())); > > Is it really needed to set an alternative last_Java_pc()? I couldn't find where it's used in a way that would require a different value. Its indeed difficult to see how the value is propagaged. I think it goes like this: - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517 - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99 - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177 - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771 > src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567: > >> 1565: >> 1566: // In case of preemption, this is where we will resume once we finally acquire the monitor. >> 1567: bind(resume_pc); > > If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above? The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack. At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack. > src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796: > >> 3794: __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset())); >> 3795: __ testbool(rscratch1); >> 3796: __ jcc(Assembler::notZero, preemption_cancelled); > > If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called. Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called? The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702223 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702986 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817703994 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com> References: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com> Message-ID: On Mon, 28 Oct 2024 18:51:31 GMT, Dean Long wrote: >> Its indeed difficult to see how the value is propagaged. I think it goes like this: >> >> - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517 >> - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99 >> - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177 >> - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771 > > Thanks, that's what I was missing. Right, whatever address is in last_Java_pc is the one we are going to freeze for that frame, i.e. that's the address we are going to return to when resuming. For the freeze slow path this was already how it worked before this PR. For the fast path I added a case to correct the last pc that we freeze on preemption, as Richard pointed out in the last link, since otherwise we would freeze a different one. The idea is that if we already freeze the right pc, then on thaw we don't have to do anything. Note that when there are interpreter frames on the stack we always take the slow path. > If preemption was cancelled, we skip over the cleanup. > We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819595482 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819770854 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Wed, 30 Oct 2024 12:48:02 GMT, Fredrik Bredberg wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945: > >> 943: >> 944: void inc_held_monitor_count(); >> 945: void dec_held_monitor_count(); > > I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. > > Suggestion: > > void inc_held_monitor_count(Register tmp); > void dec_held_monitor_count(Register tmp); Changed. > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740: > >> 738: void MacroAssembler::clobber_nonvolatile_registers() { >> 739: BLOCK_COMMENT("clobber nonvolatile registers {"); >> 740: Register regs[] = { > > Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory. > Suggestion: > > static const Register regs[] = { Added. > src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273: > >> 271: ? frame_sp + fsize - frame::sender_sp_offset >> 272: // we need to re-read fp because it may be an oop and we might have fixed the frame. >> 273: : *(intptr_t**)(hf.sp() - 2); > > Suggestion: > > : *(intptr_t**)(hf.sp() - frame::sender_sp_offset); Changed. > src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793: > >> 791: >> 792: void inc_held_monitor_count(Register tmp = t0); >> 793: void dec_held_monitor_count(Register tmp = t0); > > I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC. > Suggestion: > > void inc_held_monitor_count(Register tmp); > void dec_held_monitor_count(Register tmp); Changed. > src/hotspot/share/runtime/continuation.cpp line 125: > >> 123: }; >> 124: >> 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) { > > I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`. > Suggestion: > > static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) { I renamed it to is_vthread_safe_to_preempt_for_jvmti. > src/hotspot/share/runtime/continuation.cpp line 135: > >> 133: #endif // INCLUDE_JVMTI >> 134: >> 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) { > > I think the code reads better if you change to `is_safe_to_preempt_vthread`. > Suggestion: > > static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) { I renamed it to is_vthread_safe_to_preempt, which I think it reads even better. > src/hotspot/share/runtime/continuation.hpp line 66: > >> 64: >> 65: enum preempt_kind { >> 66: freeze_on_monitorenter = 1, > > Is there a reason why the first enumerator doesn't start at zero? There was one value that meant to be for the regular freeze from java. But it was not used so I removed it. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > >> 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); >> 888: } else { >> 889: return freeze_pinned_native; > > Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me. We just found a frame that can't be freezed, most likely the call_stub or upcall_stub which indicate there are further natives frames up the stack. I added a comment. > src/hotspot/share/runtime/objectMonitor.cpp line 1193: > >> 1191: } >> 1192: >> 1193: assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, ""); > > In `ObjectMonitor::resume_operation()` the exact same line is a `guarantee`- not an `assert`-line, is there any reason why? The `guarantee` tries to mimic the one here: https://github.com/openjdk/jdk/blob/ae82cc1ba101f6c566278f79a2e94bd1d1dd9efe/src/hotspot/share/runtime/objectMonitor.cpp#L1613 The assert at the epilogue is probably redundant. Also in `UnlinkAfterAcquire`, the else branch already asserts `ObjectWaiter::TS_CXQ`. I removed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101744 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825108078 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825100526 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101246 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107036 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825102359 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825103008 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104666 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825106368 From coleenp at openjdk.org Wed Nov 6 17:40:03 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 15:49:32 GMT, Andrew Haley wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341: > >> 5339: >> 5340: void MacroAssembler::inc_held_monitor_count() { >> 5341: Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); > > Suggestion: > > // Clobbers: rscratch1 and rscratch2 > void MacroAssembler::inc_held_monitor_count() { > Address dst = Address(rthread, JavaThread::held_monitor_count_offset()); Also, is it better to have this without assignment. Which is a nit. Address dst(rthread, JavaThread::held_monitor_count_offset()); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811584584 From coleenp at openjdk.org Wed Nov 6 17:40:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 01:51:12 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119: > >> 117: return mask.num_oops() >> 118: + 1 // for the mirror oop >> 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot > > Where is this temp oop slot set and used? It's the offset of the mirror passed to static native calls. It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated. I think this could be cleaned up someday, which would remove this special case. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411: > >> 1409: // zero out fields (but not the stack) >> 1410: const size_t hs = oopDesc::header_size(); >> 1411: oopDesc::set_klass_gap(mem, 0); > > Why, bug fix or cleanup? This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819394224 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823227312 From pchilanomate at openjdk.org Wed Nov 6 17:40:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <6y2W6yaKBLRBbNe-yP_lenR4PMPbWb1Pa9wS3VpFGcI=.0465a56a-7cf4-4455-82c6-4097a3f8e456@github.com> On Tue, 29 Oct 2024 10:06:01 GMT, Fredrik Bredberg wrote: >> Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack. > > It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment. I updated the comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821386261 From fbredberg at openjdk.org Wed Nov 6 17:40:03 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 6 Nov 2024 17:40:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 13:11:38 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032: >> >>> 2030: // Force freeze slow path in case we try to preempt. We will pin the >>> 2031: // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()). >>> 2032: __ push_cont_fastpath(); >> >> We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do? > > Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack. It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820487130 From dlong at openjdk.org Wed Nov 6 17:40:04 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 16:39:14 GMT, Coleen Phillimore wrote: >> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119: >> >>> 117: return mask.num_oops() >>> 118: + 1 // for the mirror oop >>> 119: + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot >> >> Where is this temp oop slot set and used? > > It's the offset of the mirror passed to static native calls. It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated. I think this could be cleaned up someday, which would remove this special case. I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code. So if this slot was added here, shouldn't there be a corresponding change for the bitmap? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819687576 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 20:10:16 GMT, Dean Long wrote: >> It's the offset of the mirror passed to static native calls. It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated. I think this could be cleaned up someday, which would remove this special case. > > I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code. So if this slot was added here, shouldn't there be a corresponding change for the bitmap? When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819757374 From coleenp at openjdk.org Wed Nov 6 17:40:04 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 21:01:47 GMT, Patricio Chilano Mateo wrote: >> I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code. So if this slot was added here, shouldn't there be a corresponding change for the bitmap? > > When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods. What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819869538 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 23:21:14 GMT, Dean Long wrote: >> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. > > So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change. > What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. > The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Object reference. But for synchronized native methods there could be more. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819908946 From dlong at openjdk.org Wed Nov 6 17:40:04 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 22:52:40 GMT, Coleen Phillimore wrote: >> When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods. > > What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819887000 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 23:59:55 GMT, Patricio Chilano Mateo wrote: >> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change. > >> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one. >> > The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Object reference. But for synchronized native methods there could be more. > So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change. > Because before this PR we never freezed interpreter frames belonging to native methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819909304 From fbredberg at openjdk.org Wed Nov 6 17:40:04 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote: >> Changed. > > Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? > > (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827720269 From fyang at openjdk.org Wed Nov 6 17:40:04 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273: >> >>> 271: ? frame_sp + fsize - frame::sender_sp_offset >>> 272: // we need to re-read fp because it may be an oop and we might have fixed the frame. >>> 273: : *(intptr_t**)(hf.sp() - 2); >> >> Suggestion: >> >> : *(intptr_t**)(hf.sp() - frame::sender_sp_offset); > > Changed. Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826453713 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang wrote: >> Changed. > > Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? > > (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828190876 From pchilanomate at openjdk.org Wed Nov 6 17:40:04 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo wrote: >> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? >> >> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd) > > Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? > I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828191725 From fyang at openjdk.org Wed Nov 6 17:40:04 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com> On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo wrote: >> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > >> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? >> > I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. > As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. > Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? I agree with @pchilano in that we are fine with these places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828563437 From pchilanomate at openjdk.org Wed Nov 6 17:40:05 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com> Message-ID: On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang wrote: >>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. >> >> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. >> >>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? >> >> I agree with @pchilano in that we are fine with these places. > >> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? > > Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup. Reverted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615499 From fyang at openjdk.org Wed Nov 6 17:40:04 2024 From: fyang at openjdk.org (Fei Yang) Date: Wed, 6 Nov 2024 17:40:04 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com> References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com> Message-ID: On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang wrote: >>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted? >>> >> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame. > >> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case. > > Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. > >> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted? > > I agree with @pchilano in that we are fine with these places. > Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was? Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828566395 From pchilanomate at openjdk.org Wed Nov 6 17:40:05 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/x86/assembler_x86.cpp line 2866: >> >>> 2864: emit_int32(0); >>> 2865: } >>> 2866: } >> >> Is it possible to make this more general and explicit instead of a sequence of bytes? >> >> Something along the lines of: >> ```C++ >> const address tar = L.is_bound() ? target(L) : pc(); >> const Address adr = Address(checked_cast(tar - pc()), tar, relocInfo::none); >> >> InstructionMark im(this); >> emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D); >> if (!L.is_bound()) { >> // Patch @0x8D opcode >> L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect())); >> } >> // Register and [rip+disp] operand >> emit_modrm(0b00, raw_encode(dst), 0b101); >> // Adjust displacement by sizeof lea instruction >> int32_t disp = adr.disp() - checked_cast(pc() - inst_mark() + sizeof(int32_t)); >> assert(is_simm32(disp), "must be 32bit offset [rip+offset]"); >> emit_int32(disp); >> >> >> and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`. > > I'll test it out but looks fine. Done. I simplified the code a bit to make it more readable. It also follows the current style of keeping the cases separate. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811237106 From pchilanomate at openjdk.org Wed Nov 6 17:40:05 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> On Mon, 28 Oct 2024 01:13:05 GMT, David Holmes wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382: > >> 2380: __ bind(after_transition); >> 2381: >> 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) { > > It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code? Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap. > The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? > Yes. > src/hotspot/share/classfile/javaClasses.cpp line 2086: > >> 2084: jboolean vthread_on_list = Atomic::load(addr); >> 2085: if (!vthread_on_list) { >> 2086: vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE); > > It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions? The same example mentioned above, with a different timing, could result in two threads trying to add the same virtual thread to the list at the same time. > src/hotspot/share/code/nmethod.cpp line 711: > >> 709: // handle the case of an anchor explicitly set in continuation code that doesn't have a callee >> 710: JavaThread* thread = reg_map->thread(); >> 711: if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { > > Suggestion: > > if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) > JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) { Fixed. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889: > >> 887: return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller); >> 888: } else { >> 889: // frame can't be freezed. Most likely the call_stub or upcall_stub > > Suggestion: > > // Frame can't be frozen. Most likely the call_stub or upcall_stub Fixed. > src/hotspot/share/runtime/javaThread.hpp line 165: > >> 163: // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the >> 164: // current _vthread object, except during creation of the primordial and JNI >> 165: // attached thread cases where this field can have a temporal value. > > Suggestion: > > // attached thread cases where this field can have a temporary value. > > Presumably this is for when the attaching thread is executing the Thread constructor? Exactly. > src/hotspot/share/runtime/javaThread.hpp line 166: > >> 164: // current _vthread object, except during creation of the primordial and JNI >> 165: // attached thread cases where this field can have a temporary value. Also, >> 166: // calls to VirtualThread.switchToCarrierThread will temporary change _vthread > > s/temporary change/temporarily change/ Fixed. > src/hotspot/share/runtime/objectMonitor.cpp line 132: > >> 130: >> 131: // ----------------------------------------------------------------------------- >> 132: // Theory of operations -- Monitors lists, thread residency, etc: > > This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage Updated comment. > src/hotspot/share/runtime/objectMonitor.cpp line 1140: > >> 1138: } >> 1139: >> 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) { > > Explanatory comment would be good - thanks. Added comment. > src/hotspot/share/runtime/objectMonitor.cpp line 1532: > >> 1530: } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) { >> 1531: // Virtual thread case. >> 1532: Trigger->unpark(); > > So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed? Right. > src/hotspot/share/runtime/objectMonitor.cpp line 1673: > >> 1671: >> 1672: ContinuationEntry* ce = current->last_continuation(); >> 1673: if (interruptible && ce != nullptr && ce->is_virtual_thread()) { > > So IIUC this use of `interruptible` would be explained as follows: > > // Some calls to wait() occur in contexts that still have to pin a vthread to its carrier. > // All such contexts perform non-interruptible waits, so by checking `interruptible` we know > // this is a regular Object.wait call. Yes, although the non-interruptible call is coming from ObjectLocker, which already has the NoPreemptMark, so I removed this check. > src/hotspot/share/runtime/objectMonitor.cpp line 1706: > >> 1704: // on _WaitSetLock so it's not profitable to reduce the length of the >> 1705: // critical section. >> 1706: > > Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't. Restored. > src/hotspot/share/runtime/objectMonitor.cpp line 2028: > >> 2026: // First time we run after being preempted on Object.wait(). >> 2027: // Check if we were interrupted or the wait timed-out, and in >> 2028: // that case remove ourselves from the _WaitSet queue. > > I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to. This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer. > src/hotspot/share/runtime/objectMonitor.cpp line 2054: > >> 2052: // Mark that we are at reenter so that we don't call this method again. >> 2053: node->_at_reenter = true; >> 2054: assert(!has_owner(current), "invariant"); > > The position of this assert seems odd as it seems to be something that should hold at entry to this method. Ok, I moved it to the beginning of resume_operation. > src/hotspot/share/runtime/objectMonitor.hpp line 47: > >> 45: // ParkEvent instead. Beware, however, that the JVMTI code >> 46: // knows about ObjectWaiters, so we'll have to reconcile that code. >> 47: // See next_waiter(), first_waiter(), etc. > > This to-do is likely no longer relevant with the current changes. Removed. > src/hotspot/share/runtime/objectMonitor.hpp line 207: > >> 205: >> 206: static void Initialize(); >> 207: static void Initialize2(); > > Please add comment why this needs to be deferred - and till after what? Added comment. > src/hotspot/share/runtime/objectMonitor.hpp line 288: > >> 286: // Returns true if this OM has an owner, false otherwise. >> 287: bool has_owner() const; >> 288: int64_t owner() const; // Returns null if DEFLATER_MARKER is observed. > > null is not an int64_t value. Changed to NO_OWNER. > src/hotspot/share/runtime/objectMonitor.hpp line 292: > >> 290: >> 291: static int64_t owner_for(JavaThread* thread); >> 292: static int64_t owner_for_oop(oop vthread); > > Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names? I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id. > src/hotspot/share/runtime/objectMonitor.hpp line 299: > >> 297: // Simply set _owner field to new_value; current value must match old_value. >> 298: void set_owner_from_raw(int64_t old_value, int64_t new_value); >> 299: // Same as above but uses tid of current as new value. > > By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right? It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id. > src/hotspot/share/runtime/objectMonitor.hpp line 302: > >> 300: // Simply set _owner field to new_value; current value must match old_value. >> 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); >> 302: void set_owner_from(int64_t old_value, JavaThread* current); > > Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment. I added a comment. How about s/old_value/old_tid and s/new_value/new_tid? > src/hotspot/share/runtime/objectMonitor.hpp line 302: > >> 300: void set_owner_from(int64_t old_value, JavaThread* current); >> 301: // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER. >> 302: void set_owner_from_BasicLock(JavaThread* current); > > Shouldn't tid there be the basicLock? So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead. > src/hotspot/share/runtime/objectMonitor.hpp line 303: > >> 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); >> 302: void set_owner_from(int64_t old_value, JavaThread* current); >> 303: // Simply set _owner field to current; current value must match basic_lock_p. > > Comment is no longer accurate Fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 309: > >> 307: // _owner field. Returns the prior value of the _owner field. >> 308: int64_t try_set_owner_from_raw(int64_t old_value, int64_t new_value); >> 309: int64_t try_set_owner_from(int64_t old_value, JavaThread* current); > > Similar to set_owner* need better comments describing API. Added similar comment. > src/hotspot/share/runtime/objectMonitor.hpp line 311: > >> 309: int64_t try_set_owner_from(int64_t old_value, JavaThread* current); >> 310: >> 311: bool is_succesor(JavaThread* thread); > > I think `has_successor` is more appropriate here as it is not the monitor that is the successor. Right, changed. > src/hotspot/share/runtime/objectMonitor.hpp line 312: > >> 310: void set_successor(JavaThread* thread); >> 311: void set_successor(oop vthread); >> 312: void clear_successor(); > > Needs descriptive comments, or at least a preceding comment explaining what a "successor" is. Added comment. > src/hotspot/share/runtime/objectMonitor.hpp line 315: > >> 313: void set_succesor(oop vthread); >> 314: void clear_succesor(); >> 315: bool has_succesor(); > > Sorry but `successor` has two `s` before `or`. Fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 317: > >> 315: bool has_succesor(); >> 316: >> 317: bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); } > > Again `has_owner` seems more appropriate Yes, changed. > src/hotspot/share/runtime/objectMonitor.hpp line 323: > >> 321: } >> 322: >> 323: bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; } > > Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner. I changed it to `has_owner_anonymous`. > src/hotspot/share/runtime/objectMonitor.hpp line 333: > >> 331: bool is_stack_locker(JavaThread* current); >> 332: BasicLock* stack_locker() const; >> 333: void set_stack_locker(BasicLock* locker); > > Again `is` versus `has`, plus some general comments describing the API. Fixed and added comments. > src/hotspot/share/runtime/objectMonitor.hpp line 334: > >> 332: >> 333: // Returns true if BasicLock* stored in _stack_locker >> 334: // points to current's stack, false othwerwise. > > Suggestion: > > // points to current's stack, false otherwise. Fixed. > src/hotspot/share/runtime/objectMonitor.hpp line 349: > >> 347: ObjectWaiter* first_waiter() { return _WaitSet; } >> 348: ObjectWaiter* next_waiter(ObjectWaiter* o) { return o->_next; } >> 349: JavaThread* thread_of_waiter(ObjectWaiter* o) { return o->_thread; } > > This no longer looks correct if the waiter is a vthread. ?? It is, we still increment _waiters for the vthread case. > src/hotspot/share/runtime/objectMonitor.inline.hpp line 110: > >> 108: } >> 109: >> 110: // Returns null if DEFLATER_MARKER is observed. > > Comment needs updating Updated. > src/hotspot/share/runtime/objectMonitor.inline.hpp line 130: > >> 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise. >> 129: // This accessor is called when we really need to know if the owner >> 130: // field == DEFLATER_MARKER and any non-null value won't do the trick. > > Comment needs updating Updated. Removed the second sentence, seemed redundant. > src/hotspot/share/runtime/synchronizer.cpp line 670: > >> 668: // Top native frames in the stack will not be seen if we attempt >> 669: // preemption, since we start walking from the last Java anchor. >> 670: NoPreemptMark npm(current); > > Don't we still pin for JNI monitor usage? Only when facing contention on this call. But once we have the monitor we don't. > src/hotspot/share/runtime/synchronizer.hpp line 172: > >> 170: >> 171: // Iterate ObjectMonitors where the owner is thread; this does NOT include >> 172: // ObjectMonitors where owner is set to a stack lock address in thread. > > Comment needs updating Updated. > src/hotspot/share/runtime/threadIdentifier.cpp line 30: > >> 28: >> 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp >> 30: static const int64_t INITIAL_TID = 3; > > Can we express this in terms of those reserved values, or are they inaccessible? Yes, we could define a new public constant `static const int64_t FIRST_AVAILABLE_TID = 3` (or some similar name) and use it here: diff --git a/src/hotspot/share/runtime/threadIdentifier.cpp b/src/hotspot/share/runtime/threadIdentifier.cpp index 60d6a990779..710c3141768 100644 --- a/src/hotspot/share/runtime/threadIdentifier.cpp +++ b/src/hotspot/share/runtime/threadIdentifier.cpp @@ -24,15 +24,15 @@ #include "precompiled.hpp" #include "runtime/atomic.hpp" +#include "runtime/objectMonitor.hpp" #include "runtime/threadIdentifier.hpp" -// starting at 3, excluding reserved values defined in ObjectMonitor.hpp -static const int64_t INITIAL_TID = 3; -static volatile int64_t next_thread_id = INITIAL_TID; +// excluding reserved values defined in ObjectMonitor.hpp +static volatile int64_t next_thread_id = ObjectMonitor::FIRST_AVAILABLE_TID; #ifdef ASSERT int64_t ThreadIdentifier::initial() { - return INITIAL_TID; + return ObjectMonitor::FIRST_AVAILABLE_TID; } #endif Or maybe define it as MAX_RESERVED_TID instead, and here we would add one to it. > src/hotspot/share/services/threadService.cpp line 467: > >> 465: if (waitingToLockMonitor->has_owner()) { >> 466: currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor); >> 467: // If currentThread is nullptr we would like to know if the owner > > Suggestion: > > // If currentThread is null we would like to know if the owner Fixed. > src/hotspot/share/services/threadService.cpp line 474: > >> 472: // vthread we never record this as a deadlock. Note: unless there >> 473: // is a bug in the VM, or a thread exits without releasing monitors >> 474: // acquired through JNI, nullptr should imply unmounted vthread owner. > > Suggestion: > > // acquired through JNI, null should imply an unmounted vthread owner. Fixed. > src/java.base/share/classes/java/lang/Object.java line 383: > >> 381: try { >> 382: wait0(timeoutMillis); >> 383: } catch (InterruptedException e) { > > I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us. We jump to `StubRoutines::cont_preempt_stub()`. We need to remove all the frames that were just copied to the heap from the physical stack, and then return to the calling method which will be `Continuation.run`. > src/java.base/share/classes/java/lang/Thread.java line 654: > >> 652: * {@link Thread#PRIMORDIAL_TID} +1 as this class cannot be used during >> 653: * early startup to generate the identifier for the primordial thread. The >> 654: * counter is off-heap and shared with the VM to allow it assign thread > > Suggestion: > > * counter is off-heap and shared with the VM to allow it to assign thread Fixed. > src/java.base/share/classes/java/lang/Thread.java line 731: > >> 729: >> 730: if (attached && VM.initLevel() < 1) { >> 731: this.tid = 3; // primordial thread > > The comment before the `ThreadIdentifiers` class needs updating to account for this change. Fixed. > src/java.base/share/classes/java/lang/VirtualThread.java line 109: > >> 107: * >> 108: * RUNNING -> BLOCKING // blocking on monitor enter >> 109: * BLOCKING -> BLOCKED // blocked on monitor enter > > Should this say something similar to the parked case, about the "yield" being successful? Since the unmount is triggered from the VM we never call yieldContinuation(), unlike with the PARKING case. In other words, there are no two cases to handle. If freezing the continuation fails, the virtual thread will already block in the monitor code pinned to the carrier, so a state of BLOCKING means freezing the continuation succeeded. > src/java.base/share/classes/java/lang/VirtualThread.java line 110: > >> 108: * RUNNING -> BLOCKING // blocking on monitor enter >> 109: * BLOCKING -> BLOCKED // blocked on monitor enter >> 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue > > Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry? It means it is scheduled to run again and re-contest for the monitor. > src/java.base/share/classes/java/lang/VirtualThread.java line 111: > >> 109: * BLOCKING -> BLOCKED // blocked on monitor enter >> 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue >> 111: * UNBLOCKED -> RUNNING // continue execution after blocked on monitor enter > > Presumably this one means it acquired the monitor? Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor. > src/java.base/share/classes/java/lang/VirtualThread.java line 631: > >> 629: // Object.wait >> 630: if (s == WAITING || s == TIMED_WAITING) { >> 631: byte nonce; > > Suggestion: > > byte seqNo; Changed to seqNo. > src/java.base/share/classes/java/lang/VirtualThread.java line 948: > >> 946: * This method does nothing if the thread has been woken by notify or interrupt. >> 947: */ >> 948: private void waitTimeoutExpired(byte nounce) { > > I assume you meant `nonce` here, but please change to `seqNo`. Changed. > src/java.base/share/classes/java/lang/VirtualThread.java line 952: > >> 950: for (;;) { >> 951: boolean unblocked = false; >> 952: synchronized (timedWaitLock()) { > > Where is the overall design of the timed-wait protocol and it use of synchronization described? When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry. > src/java.base/share/classes/java/lang/VirtualThread.java line 1397: > >> 1395: >> 1396: /** >> 1397: * Returns a lock object to coordinating timed-wait setup and timeout handling. > > Suggestion: > > * Returns a lock object for coordinating timed-wait setup and timeout handling. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819744051 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817192967 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195264 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195487 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826154797 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805830255 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700441 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828195851 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196602 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817197017 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817388840 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817199027 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200025 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200202 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596618 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200507 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596855 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600012 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813525449 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600739 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187730 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601098 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601168 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601545 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195731 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601472 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601619 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601871 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811602000 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187856 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195899 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196260 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196374 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200860 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200711 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237094 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155159 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155815 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701043 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815693906 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237507 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239314 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239799 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240352 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815699934 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700133 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817190381 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700312 From dlong at openjdk.org Wed Nov 6 17:40:05 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382: >> >>> 2380: __ bind(after_transition); >>> 2381: >>> 2382: if (LockingMode != LM_LEGACY && method->is_object_wait0()) { >> >> It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code? > > Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap. It's conceivable that in the future we might have more native methods we want to preempt. Instead of enumerating them all, we could set a flag on the method. I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819880228 From dholmes at openjdk.org Wed Nov 6 17:40:05 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 23:09:58 GMT, Dean Long wrote: >> Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap. > > It's conceivable that in the future we might have more native methods we want to preempt. Instead of enumerating them all, we could set a flag on the method. > > I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze. Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820337946 From pchilanomate at openjdk.org Wed Nov 6 17:40:05 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Tue, 29 Oct 2024 08:29:55 GMT, David Holmes wrote: >> It's conceivable that in the future we might have more native methods we want to preempt. Instead of enumerating them all, we could set a flag on the method. >> >> I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze. > > Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block. It's not that straightforward because the freeze can fail. By then we would have already started the wait call as a virtual thread though, not a platform thread. Maybe we could try to freeze before the wait0 call. We always have the option to use a flag in the method as Dean suggests instead of checking for a specific one. Since now there is only `Object.wait()` I think it's better to explicitly check for it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821391532 From dlong at openjdk.org Wed Nov 6 17:40:05 2024 From: dlong at openjdk.org (Dean Long) Date: Wed, 6 Nov 2024 17:40:05 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com> Message-ID: On Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo wrote: >> If preemption was cancelled, we skip over the cleanup. The native frames haven't been unwound yet. So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)? It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled. Some some finalize actions would be delated, like a two-stage commit. > >> If preemption was cancelled, we skip over the cleanup. >> > We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791 OK got it. I guess it's too early to know if it's worth it to further optimize this case, which is hopefully rare. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819865539 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: On Mon, 28 Oct 2024 07:55:02 GMT, Richard Reingruber wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602: > >> 600: >> 601: address generate_cont_preempt_stub(); >> 602: address generate_cont_resume_monitor_operation(); > > The declaration of `generate_cont_resume_monitor_operation` seems to be unused. Removed. > src/hotspot/share/runtime/synchronizer.cpp line 1559: > >> 1557: // and set the stack locker field in the monitor. >> 1558: m->set_stack_locker(mark.locker()); >> 1559: m->set_anonymous_owner(); // second > > Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now. No, I removed that comment. Both will be visible once we publish the monitor with `object->release_set_mark(markWord::encode(m))`. There was a "first" comment in method ObjectMonitor::set_owner_from_BasicLock() which I removed in [1]. Clearing _stack_locker now happens here in the `mark.has_monitor()` case. The order there doesn't matter either. If some other thread sees that the owner is anonymous and tries to check if he is the owner the comparison will always fail, regardless of reading the BasicLock* value or a nullptr value. [1] https://github.com/pchilano/jdk/commit/13353fdd6ad3c509b82b1fb0b9a3d05284b592b7#diff-4707eeadeff2ce30c09c4ce8c5a987abf58ac06f7bf78e7717cffa9c36cc392fL195 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746524 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746309 From rrich at openjdk.org Wed Nov 6 17:40:06 2024 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602: > 600: > 601: address generate_cont_preempt_stub(); > 602: address generate_cont_resume_monitor_operation(); The declaration of `generate_cont_resume_monitor_operation` seems to be unused. src/hotspot/share/runtime/javaThread.hpp line 166: > 164: // current _vthread object, except during creation of the primordial and JNI > 165: // attached thread cases where this field can have a temporary value. > 166: int64_t _lock_id; Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`. src/hotspot/share/runtime/objectMonitor.hpp line 202: > 200: > 201: // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread. > 202: BasicLock* volatile _stack_locker; IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake. Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it? src/hotspot/share/runtime/synchronizer.cpp line 1559: > 1557: // and set the stack locker field in the monitor. > 1558: m->set_stack_locker(mark.locker()); > 1559: m->set_anonymous_owner(); // second Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818523530 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377293 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819029029 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818521820 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Fri, 25 Oct 2024 18:39:23 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 2082: >> >>> 2080: } >>> 2081: >>> 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) { >> >> Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? >> >> I'm struggling to understand how a thread can already be on this list? > >> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? >> > Yes. > Some comments here about the operation would be useful. > Added a comment. >> src/hotspot/share/runtime/javaThread.hpp line 165: >> >>> 163: // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the >>> 164: // current _vthread object, except during creation of the primordial and JNI >>> 165: // attached thread cases where this field can have a temporal value. >> >> Suggestion: >> >> // attached thread cases where this field can have a temporary value. >> >> Presumably this is for when the attaching thread is executing the Thread constructor? > > Exactly. Comment adjusted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817193493 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809072960 From dholmes at openjdk.org Wed Nov 6 17:40:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 00:43:47 GMT, David Holmes wrote: >>> I'm struggling to understand how a thread can already be on this list? >>> >> With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor. > > Hmmmm ... I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay. That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245776 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Fri, 25 Oct 2024 18:39:54 GMT, Patricio Chilano Mateo wrote: >>> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right? >>> >> Yes. > >> Some comments here about the operation would be useful. >> > Added a comment. > I'm struggling to understand how a thread can already be on this list? > With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817194346 From dholmes at openjdk.org Wed Nov 6 17:40:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Fri, 25 Oct 2024 18:40:51 GMT, Patricio Chilano Mateo wrote: >>> Some comments here about the operation would be useful. >>> >> Added a comment. > >> I'm struggling to understand how a thread can already be on this list? >> > With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor. Hmmmm ... I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818242015 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 00:55:34 GMT, David Holmes wrote: >> Hmmmm ... I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay. > > That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail. Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail: | ThreadA | ThreadB | ThreadC | | --------------------------------------| --------------------------------------| ---------------------------------------------| | | |VThreadMonitorEnter:fails to acquire monitorB | | | | VThreadMonitorEnter:adds to B's _cxq | | | ExitEpilog:picks ThreadC as succesor | | | | ExitEpilog:releases monitorB | | | | | VThreadMonitorEnter:acquires monitorB | | | | VThreadMonitorEnter:removes from B's _cxq | | | | continues execution in Java | | | |VThreadMonitorEnter:fails to acquire monitorA | | | | VThreadMonitorEnter:adds to A's _cxq | | ExitEpilog:picks ThreadC as succesor | | | | ExitEpilog:releases monitorA | | | | ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList() | | ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819829472 From pchilanomate at openjdk.org Wed Nov 6 17:40:06 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> Message-ID: <-NVIl6YW1oji4m0sLlL34aIrsJ0zq1_0PlgT6eva-jY=.e2d498b3-8477-48a7-be81-b328c592289e@github.com> On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 2107: >> >>> 2105: >>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { >>> 2107: return vthread->long_field(_timeout_offset); >> >> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? > > It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too. Renamed accessors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615772 From alanb at openjdk.org Wed Nov 6 17:40:06 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> On Mon, 4 Nov 2024 02:12:40 GMT, David Holmes wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/classfile/javaClasses.cpp line 2107: > >> 2105: >> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) { >> 2107: return vthread->long_field(_timeout_offset); > > Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ?? It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too. > src/hotspot/share/prims/jvm.cpp line 4012: > >> 4010: } >> 4011: ThreadBlockInVM tbivm(THREAD); >> 4012: parkEvent->park(); > > What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed. It's very similar to the "Reference Handler" thread. That thread calls into the VM to get the pending-Reference list. Now we have "VirtualThread-unblocker" calling into the VM to get the list of virtual threads to unblock. ObjectMonitor::ExitEpilog will the unpark this thread when the virtual thread successor is on the list to unblock. > src/java.base/share/classes/java/lang/Thread.java line 655: > >> 653: * early startup to generate the identifier for the primordial thread. The >> 654: * counter is off-heap and shared with the VM to allow it assign thread >> 655: * identifiers to non-Java threads. > > Why do non-JavaThreads need an identifier of this kind? JFR. We haven't changed anything there, just the initial tid. > src/java.base/share/classes/java/lang/VirtualThread.java line 115: > >> 113: * RUNNING -> WAITING // transitional state during wait on monitor >> 114: * WAITING -> WAITED // waiting on monitor >> 115: * WAITED -> BLOCKED // notified, waiting to be unblocked by monitor owner > > Waiting to re-enter the monitor? yes > src/java.base/share/classes/java/lang/VirtualThread.java line 178: > >> 176: // timed-wait support >> 177: private long waitTimeout; >> 178: private byte timedWaitNonce; > > Strange name - what does this mean? Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait. > src/java.base/share/classes/java/lang/VirtualThread.java line 530: > >> 528: && carrier == Thread.currentCarrierThread(); >> 529: carrier.setCurrentThread(carrier); >> 530: Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread > > I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ?? A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19). More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827219720 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814450822 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814387940 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810579901 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810583267 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810598265 From dholmes at openjdk.org Wed Nov 6 17:40:06 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:06 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: <-1gsoTUPRiypD1etOiePGvVI0vBmYKUy_ltb6C4ADNU=.7a75db37-1cb9-4256-969d-d532b6cdc8e5@github.com> On Mon, 28 Oct 2024 22:02:02 GMT, Patricio Chilano Mateo wrote: >> That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail. > > Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail: > > | ThreadA | ThreadB | ThreadC | > | --------------------------------------| --------------------------------------| ---------------------------------------------| > | | |VThreadMonitorEnter:fails to acquire monitorB | > | | | VThreadMonitorEnter:adds to B's _cxq | > | | ExitEpilog:picks ThreadC as succesor | | > | | ExitEpilog:releases monitorB | | > | | | VThreadMonitorEnter:acquires monitorB | > | | | VThreadMonitorEnter:removes from B's _cxq | > | | | continues execution in Java | > | | |VThreadMonitorEnter:fails to acquire monitorA | > | | | VThreadMonitorEnter:adds to A's _cxq | > | ExitEpilog:picks ThreadC as succesor | | | > | ExitEpilog:releases monitorA | | | > | ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList() | | Thanks for that detailed explanation. It is a bit disconcerting that Thread C could leave a trace on monitors it acquired and released in the distant past. But that is an effect of waking the successor after releasing the monitor (which is generally a good thing for performance). We could potentially re-check the successor (which Thread C will clear) before doing the actual unpark (and set_onWaitingList) but that would just narrow the race window not close it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823394886 From egahlin at openjdk.org Wed Nov 6 17:40:07 2024 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/share/jfr/metadata/metadata.xml line 160: > 158: > 159: > 160: Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html (Note: The fact that the event is now written in the JVM doesn't determine the category.) src/hotspot/share/jfr/metadata/metadata.xml line 160: > 158: > 159: > 160: The label should be "Blocking Operation" with a capital "O". Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828875263 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828878025 From pchilanomate at openjdk.org Wed Nov 6 17:40:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/jfr/metadata/metadata.xml line 160: > >> 158: >> 159: >> 160: > > The label should be "Blocking Operation" with a capital "O". > > Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829463128 From pchilanomate at openjdk.org Wed Nov 6 17:40:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 08:19:34 GMT, Alan Bateman wrote: >> src/hotspot/share/jfr/metadata/metadata.xml line 160: >> >>> 158: >>> 159: >>> 160: >> >> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: >> >> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html >> >> (Note: The fact that the event is now written in the JVM doesn't determine the category.) > > Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829462765 From alanb at openjdk.org Wed Nov 6 17:40:07 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 07:48:40 GMT, Erik Gahlin wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/jfr/metadata/metadata.xml line 160: > >> 158: >> 159: >> 160: > > Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category: > > https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html > > (Note: The fact that the event is now written in the JVM doesn't determine the category.) Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828915229 From sspitsyn at openjdk.org Wed Nov 6 17:40:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 20:10:03 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuation.cpp line 88: >> >>> 86: if (_target->has_async_exception_condition()) { >>> 87: _failed = true; >>> 88: } >> >> Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this. > > These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer. Just wanted to understand what needs to be checked after the start_VTMS_transition() call. You are right, we need to check the `_thread->has_async_exception_condition()` after the call. The pending `popframe` and `earlyret` can be checked before as I understand. I'm not sure there is a real need in double-checking before and after. So, let's keep it as it is for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824134075 From pchilanomate at openjdk.org Wed Nov 6 17:40:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 28 Oct 2024 10:37:21 GMT, Yudi Zheng wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329: > >> 327: nonstatic_field(ObjArrayKlass, _element_klass, Klass*) \ >> 328: \ >> 329: unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ > > to make the type assert more precise: > > diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp > index 20b9609cdbf..f2b8a69c03f 100644 > --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp > +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp > @@ -326,7 +326,7 @@ > \ > nonstatic_field(ObjArrayKlass, _element_klass, Klass*) \ > \ > - unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ > + volatile_nonstatic_field(ObjectMonitor, _owner, int64_t) \ > volatile_nonstatic_field(ObjectMonitor, _recursions, intptr_t) \ > volatile_nonstatic_field(ObjectMonitor, _cxq, ObjectWaiter*) \ > volatile_nonstatic_field(ObjectMonitor, _EntryList, ObjectWaiter*) \ > diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp > index 86d7277f88b..0492f28e15b 100644 > --- a/src/hotspot/share/runtime/vmStructs.cpp > +++ b/src/hotspot/share/runtime/vmStructs.cpp > @@ -786,8 +786,8 @@ > \ > volatile_nonstatic_field(ObjectMonitor, _metadata, uintptr_t) \ > unchecked_nonstatic_field(ObjectMonitor, _object, sizeof(void *)) /*... Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746890 From yzheng at openjdk.org Wed Nov 6 17:40:07 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Wed, 6 Nov 2024 17:40:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329: > 327: nonstatic_field(ObjArrayKlass, _element_klass, Klass*) \ > 328: \ > 329: unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ to make the type assert more precise: diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp index 20b9609cdbf..f2b8a69c03f 100644 --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp @@ -326,7 +326,7 @@ \ nonstatic_field(ObjArrayKlass, _element_klass, Klass*) \ \ - unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ + volatile_nonstatic_field(ObjectMonitor, _owner, int64_t) \ volatile_nonstatic_field(ObjectMonitor, _recursions, intptr_t) \ volatile_nonstatic_field(ObjectMonitor, _cxq, ObjectWaiter*) \ volatile_nonstatic_field(ObjectMonitor, _EntryList, ObjectWaiter*) \ diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp index 86d7277f88b..0492f28e15b 100644 --- a/src/hotspot/share/runtime/vmStructs.cpp +++ b/src/hotspot/share/runtime/vmStructs.cpp @@ -786,8 +786,8 @@ \ volatile_nonstatic_field(ObjectMonitor, _metadata, uintptr_t) \ unchecked_nonstatic_field(ObjectMonitor, _object, sizeof(void *)) /* NOTE: no type */ \ - unchecked_nonstatic_field(ObjectMonitor, _owner, int64_t) \ - unchecked_nonstatic_field(ObjectMonitor, _stack_locker, BasicLock*) \ + volatile_nonstatic_field(ObjectMonitor, _owner, int64_t) \ + volatile_nonstatic_field(ObjectMonitor, _stack_locker, BasicLock*) \ volatile_nonstatic_field(ObjectMonitor, _next_om, ObjectMonitor*) \ volatile_nonstatic_field(BasicLock, _metadata, uintptr_t) \ nonstatic_field(ObjectMonitor, _contentions, int) \ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818818274 From sspitsyn at openjdk.org Wed Nov 6 17:40:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082: > 1080: } else { > 1081: assert(vthread != nullptr, "no vthread oop"); > 1082: oop oopCont = java_lang_VirtualThread::continuation(vthread); Nit: The name `oopCont` does not match the HotSpot naming convention. What about `cont_oop` or even better just `cont` as at the line 2550? src/hotspot/share/prims/jvmtiExport.cpp line 1682: > 1680: > 1681: // On preemption JVMTI state rebinding has already happened so get it always directly from the oop. > 1682: JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread)); I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present. src/hotspot/share/prims/jvmtiExport.cpp line 2879: > 2877: JvmtiVTMSTransitionDisabler::start_VTMS_transition((jthread)vthread.raw_value(), /* is_mount */ true); > 2878: current->rebind_to_jvmti_thread_state_of(current->threadObj()); > 2879: } This function looks a little bit unusual. I need to think about the consequences but do not see anything bad so far. I'll look at the `ObjectMonitor` and `continuation` side updates to get more details on this. src/hotspot/share/runtime/continuation.cpp line 88: > 86: if (_target->has_async_exception_condition()) { > 87: _failed = true; > 88: } Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this. src/hotspot/share/runtime/continuation.cpp line 115: > 113: if (jvmti_present) { > 114: _target->rebind_to_jvmti_thread_state_of(_target->threadObj()); > 115: if (JvmtiExport::should_post_vthread_mount()) { This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`. Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point. src/hotspot/share/runtime/continuation.cpp line 134: > 132: return true; > 133: } > 134: #endif // INCLUDE_JVMTI Could you, please, consider the simplification below? #if INCLUDE_JVMTI // return true if started vthread unmount bool jvmti_unmount_begin(JavaThread* target) { assert(!target->is_in_any_VTMS_transition(), "must be"); // Don't preempt if there is a pending popframe or earlyret operation. This can // be installed in start_VTMS_transition() so we need to check it here. if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { JvmtiThreadState* state = target->jvmti_thread_state(); if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { return false; } } // Don't preempt in case there is an async exception installed since // we would incorrectly throw it during the unmount logic in the carrier. if (target->has_async_exception_condition()) { return false; } if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); } else { target->set_is_in_VTMS_transition(true); // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) } return false; } static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { if (target->is_in_VTMS_transition()) { // We caught target at the end of a mount transition. return false; } return true; } #endif // INCLUDE_JVMTI ... static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { assert(java_lang_VirtualThread::is_instance(vthread), ""); if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition return false; } return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); } ... int Continuation::try_preempt(JavaThread* target, oop continuation) { verify_preempt_preconditions(target, continuation); if (LockingMode == LM_LEGACY) { return freeze_unsupported; } if (!is_safe_vthread_to_preempt(target, target->vthread())) { return freeze_pinned_native; } JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); log_trace(continuations, preempt)("try_preempt: %d", res); return res; } The following won't be needed: target->set_pending_jvmti_unmount_event(true); jvmtiThreadState.cpp: + if (thread->pending_jvmti_unmount_event()) { + assert(java_lang_VirtualThread::is_preempted(JNIHandles::resolve(vthread)), "should be marked preempted"); + JvmtiExport::post_vthread_unmount(vthread); + thread->set_pending_jvmti_unmount_event(false); + } As we discussed before there can be the `has_async_exception_condition()` flag set after a VTMS unmount transition has been started. But there is always such a race in VTMS transitions and the flag has to be processed as usual. src/hotspot/share/runtime/objectMonitor.cpp line 1643: > 1641: // actual callee (see nmethod::preserve_callee_argument_oops()). > 1642: ThreadOnMonitorWaitedEvent tmwe(current); > 1643: JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out); We post a JVMTI `MonitorWaited` event here for a virtual thread. A couple of questions on this: - Q1: Is this posted after the `VirtualThreadMount` extension event posted? Unfortunately, it is not easy to make this conclusion. - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801. Does it post the `MonitorWaited` event for this virtual thread as well? If not, then it is not clear how posting for virtual thread is avoided. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820012783 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820052049 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820062505 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822235309 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822224512 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828376585 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829199889 From pchilanomate at openjdk.org Wed Nov 6 17:40:08 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 02:56:30 GMT, Serguei Spitsyn wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082: > >> 1080: } else { >> 1081: assert(vthread != nullptr, "no vthread oop"); >> 1082: oop oopCont = java_lang_VirtualThread::continuation(vthread); > > Nit: The name `oopCont` does not match the HotSpot naming convention. > What about `cont_oop` or even better just `cont` as at the line 2550? Renamed to cont. > src/hotspot/share/prims/jvmtiExport.cpp line 1682: > >> 1680: >> 1681: // On preemption JVMTI state rebinding has already happened so get it always directly from the oop. >> 1682: JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread)); > > I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present. Right, good find. I missed `get_jvmti_thread_state ` will also create the state if null. How about this fix: https://github.com/pchilano/jdk/commit/baf30d92f79cc084824b207a199672f5b7f9be88 I now also see that JvmtiVirtualThreadEventMark tries to save some state of the JvmtiThreadState for the current thread before the callback, which is not the JvmtiThreadState of the vthread for this case. Don't know if something needs to change there too. > src/hotspot/share/runtime/continuation.cpp line 88: > >> 86: if (_target->has_async_exception_condition()) { >> 87: _failed = true; >> 88: } > > Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this. These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer. > src/hotspot/share/runtime/continuation.cpp line 115: > >> 113: if (jvmti_present) { >> 114: _target->rebind_to_jvmti_thread_state_of(_target->threadObj()); >> 115: if (JvmtiExport::should_post_vthread_mount()) { > > This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`. > Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point. Fixed and added comment. > src/hotspot/share/runtime/continuation.cpp line 134: > >> 132: return true; >> 133: } >> 134: #endif // INCLUDE_JVMTI > > Could you, please, consider the simplification below? > > > #if INCLUDE_JVMTI > // return true if started vthread unmount > bool jvmti_unmount_begin(JavaThread* target) { > assert(!target->is_in_any_VTMS_transition(), "must be"); > > // Don't preempt if there is a pending popframe or earlyret operation. This can > // be installed in start_VTMS_transition() so we need to check it here. > if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { > JvmtiThreadState* state = target->jvmti_thread_state(); > if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { > return false; > } > } > // Don't preempt in case there is an async exception installed since > // we would incorrectly throw it during the unmount logic in the carrier. > if (target->has_async_exception_condition()) { > return false; > } > if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { > JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); > } else { > target->set_is_in_VTMS_transition(true); > // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) > } > return false; > } > > static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { > if (target->is_in_VTMS_transition()) { > // We caught target at the end of a mount transition. > return false; > } > return true; > } > #endif // INCLUDE_JVMTI > ... > static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { > assert(java_lang_VirtualThread::is_instance(vthread), ""); > if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition > return false; > } > return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); > } > ... > int Continuation::try_preempt(JavaThread* target, oop continuation) { > verify_preempt_preconditions(target, continuation); > > if (LockingMode == LM_LEGACY) { > return freeze_unsupported; > } > if (!is_safe_vthread_to_preempt(target, target->vthread())) { > return freeze_pinned_native; > } > JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) > int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); > log_trace(continuations, preempt)("try_preempt: %d", res); > return res; > } > > > The following won't be needed: > > target->set_pending_jvmti_unmou... Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. > Is this posted after the VirtualThreadMount extension event posted? > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823319745 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823322449 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823324965 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823323891 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830220838 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830225909 From fbredberg at openjdk.org Wed Nov 6 17:40:09 2024 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: On Thu, 31 Oct 2024 20:05:18 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuation.hpp line 66: >> >>> 64: >>> 65: enum preempt_kind { >>> 66: freeze_on_monitorenter = 1, >> >> Is there a reason why the first enumerator doesn't start at zero? > > There was one value that meant to be for the regular freeze from java. But it was not used so I removed it. Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825168519 From pchilanomate at openjdk.org Wed Nov 6 17:40:09 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 19:02:05 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411: >> >>> 1409: // zero out fields (but not the stack) >>> 1410: const size_t hs = oopDesc::header_size(); >>> 1411: oopDesc::set_klass_gap(mem, 0); >> >> Why, bug fix or cleanup? > > This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object. If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580273 From pchilanomate at openjdk.org Wed Nov 6 17:40:08 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:50:29 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuation.cpp line 134: >> >>> 132: return true; >>> 133: } >>> 134: #endif // INCLUDE_JVMTI >> >> Could you, please, consider the simplification below? >> >> >> #if INCLUDE_JVMTI >> // return true if started vthread unmount >> bool jvmti_unmount_begin(JavaThread* target) { >> assert(!target->is_in_any_VTMS_transition(), "must be"); >> >> // Don't preempt if there is a pending popframe or earlyret operation. This can >> // be installed in start_VTMS_transition() so we need to check it here. >> if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) { >> JvmtiThreadState* state = target->jvmti_thread_state(); >> if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) { >> return false; >> } >> } >> // Don't preempt in case there is an async exception installed since >> // we would incorrectly throw it during the unmount logic in the carrier. >> if (target->has_async_exception_condition()) { >> return false; >> } >> if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) { >> JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true); >> } else { >> target->set_is_in_VTMS_transition(true); >> // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true) >> } >> return false; >> } >> >> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) { >> if (target->is_in_VTMS_transition()) { >> // We caught target at the end of a mount transition. >> return false; >> } >> return true; >> } >> #endif // INCLUDE_JVMTI >> ... >> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) { >> assert(java_lang_VirtualThread::is_instance(vthread), ""); >> if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) { // inside transition >> return false; >> } >> return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true); >> } >> ... >> int Continuation::try_preempt(JavaThread* target, oop continuation) { >> verify_preempt_preconditions(target, continuation); >> >> if (LockingMode == LM_LEGACY) { >> return freeze_unsupported; >> } >> if (!is_safe_vthread_to_preempt(target, target->vthread())) { >> return freeze_pinned_native; >> } >> JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;) >> int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp()); >> log_trace(con... > > Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 > We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. > Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 >> src/hotspot/share/runtime/objectMonitor.cpp line 1643: >> >>> 1641: // actual callee (see nmethod::preserve_callee_argument_oops()). >>> 1642: ThreadOnMonitorWaitedEvent tmwe(current); >>> 1643: JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out); >> >> We post a JVMTI `MonitorWaited` event here for a virtual thread. >> A couple of questions on this: >> - Q1: Is this posted after the `VirtualThreadMount` extension event posted? >> Unfortunately, it is not easy to make this conclusion. >> - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801. >> Does it post the `MonitorWaited` event for this virtual thread as well? >> If not, then it is not clear how posting for virtual thread is avoided. > >> Is this posted after the VirtualThreadMount extension event posted? >> > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 > The JvmtiExport::post_monitor_waited() is called at the line 1801. > Does it post the MonitorWaited event for this virtual thread as well? > That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830222411 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830227475 From sspitsyn at openjdk.org Wed Nov 6 17:40:08 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 17:40:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo wrote: >> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514 >> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior. >> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events. > > Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. > For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. > When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. > > [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks. > but does the specs say the event has to be posted in the context of the vthread? As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context. > For pop_frame/early_ret checks ... The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. > Maybe we could go with this simplified code now and work on it later... Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this. It would be nice to fix a couple of nits though: - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark` - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831367766 From stefank at openjdk.org Wed Nov 6 17:40:09 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo wrote: >> This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object. > > If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. This code in `StackChunkAllocator::initialize` mimics the clearing code in: void MemAllocator::mem_clear(HeapWord* mem) const { assert(mem != nullptr, "cannot initialize null object"); const size_t hs = oopDesc::header_size(); assert(_word_size >= hs, "unexpected object size"); oopDesc::set_klass_gap(mem, 0); Copy::fill_to_aligned_words(mem + hs, _word_size - hs); } but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be: if (oopDesc::has_klass_gap()) { oopDesc::set_klass_gap(mem, 0); } So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827424227 From pchilanomate at openjdk.org Wed Nov 6 17:40:09 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com> Message-ID: <5GigB3kzUJRlduxsGT_kXkmG-Jki2N-gyGkNHNNwXi4=.f139275c-bc20-4f0b-9eef-c979c3e83e12@github.com> On Thu, 31 Oct 2024 21:11:39 GMT, Fredrik Bredberg wrote: >> There was one value that meant to be for the regular freeze from java. But it was not used so I removed it. > > Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero. Yes, I missed to include it in the previous changes. I actually removed the assignment altogether since there is no need to rely on particular values (although it will start at zero by default). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825202651 From coleenp at openjdk.org Wed Nov 6 17:40:09 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <1kRcFJhxhwGYGZxCslZJ_TUZ_SLx-io6w_zCFpIlfxw=.60f00ea4-6466-4a9d-b27d-0d657b0a6fb5@github.com> On Fri, 25 Oct 2024 13:12:11 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275: >> >>> 1273: >>> 1274: if (caller.is_interpreted_frame()) { >>> 1275: _total_align_size += frame::align_wiggle; >> >> Please put a comment here about frame align-wiggle. > > I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though. ok that's helpful. >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1550: >> >>> 1548: assert(!cont.is_empty(), ""); >>> 1549: // This is done for the sake of the enterSpecial frame >>> 1550: StackWatermarkSet::after_unwind(thread); >> >> Is there a new place for this StackWatermark code? > > I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`. Okay, good! >> src/hotspot/share/runtime/objectMonitor.hpp line 43: >> >>> 41: // ParkEvent instead. Beware, however, that the JVMTI code >>> 42: // knows about ObjectWaiters, so we'll have to reconcile that code. >>> 43: // See next_waiter(), first_waiter(), etc. >> >> Also a nice cleanup. Did you reconcile the JVMTI code? > > We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage. Ok, good that there isn't a jvmti special case here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860241 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860643 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819864520 From pchilanomate at openjdk.org Wed Nov 6 17:40:09 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson wrote: >> If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore. > > This code in `StackChunkAllocator::initialize` mimics the clearing code in: > > void MemAllocator::mem_clear(HeapWord* mem) const { > assert(mem != nullptr, "cannot initialize null object"); > const size_t hs = oopDesc::header_size(); > assert(_word_size >= hs, "unexpected object size"); > oopDesc::set_klass_gap(mem, 0); > Copy::fill_to_aligned_words(mem + hs, _word_size - hs); > } > > > but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be: > > if (oopDesc::has_klass_gap()) { > oopDesc::set_klass_gap(mem, 0); > } > > > So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`? Thanks for confirming. I added the check here which I think should cover any merge order. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828614946 From pchilanomate at openjdk.org Wed Nov 6 17:40:09 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <21HfKDagatsu-A7zva9eZ_ndGye37_BRkJ3cyAKQoN0=.4428db89-23a9-4968-878d-c2427ee67622@github.com> On Wed, 23 Oct 2024 05:33:55 GMT, Axel Boldt-Christmas wrote: >> Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames? > > The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment. The nicest model would have been to first fix the oops, (mem)copy, then clear them. But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store. > > It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model. I renamed it to transfer_lockstack() and applied the suggested version with the lambda. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813224287 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 21 Oct 2024 15:41:45 GMT, Axel Boldt-Christmas wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/javaThread.cpp line 1545: > >> 1543: if (is_vthread_mounted()) { >> 1544: // _lock_id is the thread ID of the mounted virtual thread >> 1545: st->print_cr(" Carrying virtual thread #" INT64_FORMAT, lock_id()); > > What is the interaction here with `switchToCarrierThread` and the window between? > > carrier.setCurrentThread(carrier); > Thread.setCurrentLockId(this.threadId()); > > Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called). Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability. In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue). > src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: > >> 60: NATIVE(2, "Native frame or on stack"), >> 61: MONITOR(3, "Monitor held"), >> 62: CRITICAL_SECTION(4, "In critical section"); > > Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? > > I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue. Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810578179 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827316145 From aboldtch at openjdk.org Wed Nov 6 17:40:09 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Wed, 6 Nov 2024 17:40:09 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 19:04:16 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234: >> >>> 2232: retry_fast_path = true; >>> 2233: } else { >>> 2234: relativize_chunk_concurrently(chunk); >> >> Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? >> >> While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack. > > Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t? Something along those lines, yes. >> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247: >> >>> 2245: _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize); >>> 2246: >>> 2247: chunk->set_lockstack_size(0); >> >> After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line. >> >> Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops. >> >> >> diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp >> index d3d63533eed..f737bd2db71 100644 >> --- a/src/hotspot/share/oops/stackChunkOop.cpp >> +++ b/src/hotspot/share/oops/stackChunkOop.cpp >> @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) { >> } >> } >> >> +void stackChunkOopDesc::clear_lockstack() { >> + const int cnt = lockstack_size(); >> + const bool requires_gc_barriers = is_gc_mode() || requires_barriers(); >> + const bool requires_uncompress = has_bitmap() && UseCompressedOops; >> + const auto clear_obj = [&](intptr_t* at) { >> + if (requires_uncompress) { >> + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); >> + } else { >> + HeapAccess<>::oop_store(reinterpret_cast(at), nullptr); >> + } >> + }; >> + >> + if (requires_gc_barriers) { >> + intptr_t* lockstack_start = start_address(); >> + for (int i = 0; i < cnt; i++) { >> + clear_obj(&lockstack_start[i]); >> + } >> + } >> + set_lockstack_size(0); >> + set_has_lockstack(false); >> +} >> + >> void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const { >> if (*((juint*)this) == badHeapWordVal) { >> st->print_cr("BAD WORD"); >> diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp >> index 28e0576801e..928e94dd695 100644 >> --- a/src/hotspot/share/oops/stackChunkOop.hpp >> +++ b/src/hotspot/share/oops/stackChunkOop.hpp >> @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc { >> void fix_thawed_frame(const frame& f, const RegisterMapT* map); >> >> void copy_lo... > > Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames? The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment. The nicest model would have been to first fix the oops, (mem)copy, then clear them. But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store. It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811903902 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811900946 From pchilanomate at openjdk.org Wed Nov 6 17:40:10 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 09:53:44 GMT, Alan Bateman wrote: >> The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it. > > It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended. Pushed a fix to avoid printing the virtual thread tid if we hit that case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814186777 From pchilanomate at openjdk.org Wed Nov 6 17:40:10 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 11:51:47 GMT, Alan Bateman wrote: >> src/hotspot/share/runtime/javaThread.cpp line 1545: >> >>> 1543: if (is_vthread_mounted()) { >>> 1544: // _lock_id is the thread ID of the mounted virtual thread >>> 1545: st->print_cr(" Carrying virtual thread #" INT64_FORMAT, lock_id()); >> >> What is the interaction here with `switchToCarrierThread` and the window between? >> >> carrier.setCurrentThread(carrier); >> Thread.setCurrentLockId(this.threadId()); >> >> Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called). > > Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability. > > In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue). The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811240529 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 22 Oct 2024 19:02:50 GMT, Patricio Chilano Mateo wrote: >> Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability. >> >> In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue). > > The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it. It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377091 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: On Wed, 23 Oct 2024 09:53:53 GMT, Richard Reingruber wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/javaThread.hpp line 166: > >> 164: // current _vthread object, except during creation of the primordial and JNI >> 165: // attached thread cases where this field can have a temporary value. >> 166: int64_t _lock_id; > > Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`. Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812385061 From pchilanomate at openjdk.org Wed Nov 6 17:40:10 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Mon, 28 Oct 2024 00:35:11 GMT, David Holmes wrote: >> This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer. > > The first sentence is not a sentence. Is it supposed to be saying: > > // The first time we run after being preempted on Object.wait() > // we check if we were interrupted or the wait timed-out ... > > ? Yes, I fixed the wording. >> So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead. > > Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have: > > Before: owner = BasicLock* belonging to current > After: owner = JavaThread* of current > > with the new version we have: > > Before: owner = ANONYMOUS_OWNER > After: owner = tid of current > > so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ? I see your point. I removed this method and had the only caller just call set_owner_from_anonymous() and set_stack_locker(nullptr). There was one other caller in ObjectMonitor::complete_exit() but it was actually not needed so I removed it. ObjectMonitor::complete_exit() is only called today on JavaThread exit to possibly unlock monitors acquired through JNI that where not unlocked. >> It is, we still increment _waiters for the vthread case. > > Sorry the target of my comment was not clear. `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread? If the ObjectWaiter is associated with a vthread(we unmounted in `Object.wait`) we just return null. We'll skip it from JVMTI code. >> Only when facing contention on this call. But once we have the monitor we don't. > > But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ??? We will have the native wrapper frame at the top, but we still need to add some extra check to differentiate this `jni_enter()` case with respect to the case of facing contention on a synchronize native method, where we do allow to unmount (only when coming from the interpreter since the changes to support it where minimal). I used the NoPreemptMark here, but we could filter this case anywhere along the freeze path. Another option could be to check `thread->current_pending_monitor_is_from_java()` in the ObjectMonitor code before trying to preempt. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907304 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697784 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819834478 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907921 From dholmes at openjdk.org Wed Nov 6 17:40:10 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Fri, 25 Oct 2024 18:46:52 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 2028: >> >>> 2026: // First time we run after being preempted on Object.wait(). >>> 2027: // Check if we were interrupted or the wait timed-out, and in >>> 2028: // that case remove ourselves from the _WaitSet queue. >> >> I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to. > > This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer. The first sentence is not a sentence. Is it supposed to be saying: // The first time we run after being preempted on Object.wait() // we check if we were interrupted or the wait timed-out ... ? >> src/hotspot/share/runtime/objectMonitor.hpp line 292: >> >>> 290: >>> 291: static int64_t owner_for(JavaThread* thread); >>> 292: static int64_t owner_for_oop(oop vthread); >> >> Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names? > > I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id. I like the idea of using `owner_id_from` but it then suggests to me that `JavaThread::_lock_id` should be something like `JavaThread::_monitor_owner_id`. The use of `tid` in comments can be confusing when applied to a `JavaThread` as the "tid" there would normally be a reference of its `osThread()->thread_id()" not it's `threadObj()->thread_id()`. I don't have an obviously better suggestion though. >> src/hotspot/share/runtime/objectMonitor.hpp line 302: >> >>> 300: // Simply set _owner field to new_value; current value must match old_value. >>> 301: void set_owner_from_raw(int64_t old_value, int64_t new_value); >>> 302: void set_owner_from(int64_t old_value, JavaThread* current); >> >> Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment. > > I added a comment. How about s/old_value/old_tid and s/new_value/new_tid? old_tid/new_tid works for me. >> src/hotspot/share/runtime/objectMonitor.hpp line 302: >> >>> 300: void set_owner_from(int64_t old_value, JavaThread* current); >>> 301: // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER. >>> 302: void set_owner_from_BasicLock(JavaThread* current); >> >> Shouldn't tid there be the basicLock? > > So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead. Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have: Before: owner = BasicLock* belonging to current After: owner = JavaThread* of current with the new version we have: Before: owner = ANONYMOUS_OWNER After: owner = tid of current so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ? >> src/hotspot/share/runtime/objectMonitor.hpp line 349: >> >>> 347: ObjectWaiter* first_waiter() { return _WaitSet; } >>> 348: ObjectWaiter* next_waiter(ObjectWaiter* o) { return o->_next; } >>> 349: JavaThread* thread_of_waiter(ObjectWaiter* o) { return o->_thread; } >> >> This no longer looks correct if the waiter is a vthread. ?? > > It is, we still increment _waiters for the vthread case. Sorry the target of my comment was not clear. `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread? >> src/hotspot/share/runtime/synchronizer.cpp line 670: >> >>> 668: // Top native frames in the stack will not be seen if we attempt >>> 669: // preemption, since we start walking from the last Java anchor. >>> 670: NoPreemptMark npm(current); >> >> Don't we still pin for JNI monitor usage? > > Only when facing contention on this call. But once we have the monitor we don't. But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ??? >> src/java.base/share/classes/java/lang/VirtualThread.java line 111: >> >>> 109: * BLOCKING -> BLOCKED // blocked on monitor enter >>> 110: * BLOCKED -> UNBLOCKED // unblocked, may be scheduled to continue >>> 111: * UNBLOCKED -> RUNNING // continue execution after blocked on monitor enter >> >> Presumably this one means it acquired the monitor? > > Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor. So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have: RUNNING -> BLOCKING -> BLOCKED BLOCKED -> UNBLOCKING -> RUNNABLE I'm just trying to get a better sense of what we can infer if we see these "transition" states. >> src/java.base/share/classes/java/lang/VirtualThread.java line 952: >> >>> 950: for (;;) { >>> 951: boolean unblocked = false; >>> 952: synchronized (timedWaitLock()) { >> >> Where is the overall design of the timed-wait protocol and it use of synchronization described? > > When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry. Thanks for the explanation but that needs to be documented somewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818239594 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811933408 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811935087 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814330162 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818236368 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240013 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814163283 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818228510 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo wrote: >>> Is this posted after the VirtualThreadMount extension event posted? >>> >> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620 > >> The JvmtiExport::post_monitor_waited() is called at the line 1801. >> Does it post the MonitorWaited event for this virtual thread as well? >> > That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor. Just to add that the 2 extension events (VirtualThreadMount and VirtualThreadUnmount) are not part of any supported/documented interface. They are a left over from the exploration phase of virtual threads when we assumed the debugger agent would need to track the transitions. So at some point I think we need to figure out how to make them go away as they are an attractive nuisance (esp. if the event callback were to upcall and execute Java code). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830657204 From alanb at openjdk.org Wed Nov 6 17:40:10 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <_NABF4JJUlSQ9_XfNtXtDGFIkqOPpDcUaoL6wAaJFkY=.70199a12-d9cd-4a85-86e1-2dbdaf474300@github.com> On Wed, 23 Oct 2024 00:56:34 GMT, Coleen Phillimore wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/javaThread.cpp line 2002: > >> 2000: #ifdef SUPPORT_MONITOR_COUNT >> 2001: >> 2002: #ifdef LOOM_MONITOR_SUPPORT > > If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ? LOOM_MONITOR_SUPPORT was only needed when there were ports missing. All 4 are included now so this goes away. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812389702 From pchilanomate at openjdk.org Wed Nov 6 17:40:10 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: On Wed, 23 Oct 2024 09:58:44 GMT, Alan Bateman wrote: >> src/hotspot/share/runtime/javaThread.hpp line 166: >> >>> 164: // current _vthread object, except during creation of the primordial and JNI >>> 165: // attached thread cases where this field can have a temporary value. >>> 166: int64_t _lock_id; >> >> Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`. > > Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them. I extended the comment to mention this case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814189388 From sspitsyn at openjdk.org Wed Nov 6 17:40:10 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 6 Nov 2024 17:40:10 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman wrote: > So at some point I think we need to figure out how to make them go away ... Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes. > It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor... The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though. > That's the path a virtual thread will take if pinned. Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831293112 From stefank at openjdk.org Wed Nov 6 17:40:11 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... src/hotspot/share/runtime/objectMonitor.hpp line 325: > 323: } > 324: > 325: bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; } Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814489387 From coleenp at openjdk.org Wed Nov 6 17:40:11 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: On Wed, 23 Oct 2024 20:42:44 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.hpp line 299: >> >>> 297: // Simply set _owner field to new_value; current value must match old_value. >>> 298: void set_owner_from_raw(int64_t old_value, int64_t new_value); >>> 299: // Same as above but uses tid of current as new value. >> >> By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right? > > It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id. but we can't change it there to thread_id because then it would be too confusing. Since it's used for locking, lock_id seems like a good name. >> src/hotspot/share/runtime/objectMonitor.hpp line 315: >> >>> 313: void set_succesor(oop vthread); >>> 314: void clear_succesor(); >>> 315: bool has_succesor(); >> >> Sorry but `successor` has two `s` before `or`. > > Fixed. Yes, need to fix successor spelling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420867 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811616558 From rrich at openjdk.org Wed Nov 6 17:40:11 2024 From: rrich at openjdk.org (Richard Reingruber) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: On Mon, 28 Oct 2024 13:08:37 GMT, Richard Reingruber wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/objectMonitor.hpp line 202: > >> 200: >> 201: // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread. >> 202: BasicLock* volatile _stack_locker; > > IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake. > Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it? `ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819034645 From dholmes at openjdk.org Wed Nov 6 17:40:11 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 11:59:03 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/objectMonitor.hpp line 174: >> >>> 172: >>> 173: int64_t volatile _owner; // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER. >>> 174: volatile uint64_t _previous_owner_tid; // thread id of the previous owner of the monitor >> >> Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ?? > > I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id. > > > $ grep -r JFR_THREAD_ID > jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread)) > jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id()) > runtime/objectMonitor.cpp: _previous_owner_tid = JFR_THREAD_ID(current); > runtime/objectMonitor.cpp: iterator->_notifier_tid = JFR_THREAD_ID(current); > runtime/vmThread.cpp: event->set_caller(JFR_THREAD_ID(op->calling_thread())); Then it looks like the JFR code needs updating as well, otherwise it is going to be reporting inconsistent information when virtual threads are locking monitors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818234543 From pchilanomate at openjdk.org Wed Nov 6 17:40:11 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com> Message-ID: <2y3cYO8ua_6QovrRnR6ndjSA6apEMXRdaNfnn_m2NdE=.0f1297b9-be4e-4fb9-b34d-4db86ad9a7f8@github.com> On Mon, 28 Oct 2024 13:12:22 GMT, Richard Reingruber wrote: >> src/hotspot/share/runtime/objectMonitor.hpp line 202: >> >>> 200: >>> 201: // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread. >>> 202: BasicLock* volatile _stack_locker; >> >> IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake. >> Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it? > > `ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`. I remember I thought about doing this but discarded it. I don't think it will reduce complexity since we still need to handle that as a special case. In fact I removed several checks throughout the ObjectMonitor code where we had to check for this case. Now it works like with LM_LIGHTWEIGHT (also a plus), where once the owner gets into ObjectMonitor the owner will be already fixed. So setting and clearing _stack_locker is contained here in ObjectSynchronizer::inflate_impl(). Granted that we could do the same when restricting the ids, but then complexity would be the same. Also even though there are no guarantees about the ids I think it might look weird for somebody looking at a thread dump to only see odd ids. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819748043 From pchilanomate at openjdk.org Wed Nov 6 17:40:11 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com> References: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com> Message-ID: On Thu, 31 Oct 2024 02:26:42 GMT, David Holmes wrote: >> src/hotspot/share/runtime/objectMonitor.inline.hpp line 207: >> >>> 205: } >>> 206: >>> 207: inline bool ObjectMonitor::has_successor() { >> >> Why are _succ accesses atomic here when previously they were not? > > General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic. > Why are _succ accesses atomic here when previously they were not? > They should had always been atomic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794270 From pchilanomate at openjdk.org Wed Nov 6 17:40:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 12:00:43 GMT, Coleen Phillimore wrote: >> src/hotspot/share/runtime/synchronizer.cpp line 1440: >> >>> 1438: } >>> 1439: >>> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) { >> >> `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`? > > If it's always the current thread, then it should be called 'current' imo. I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389380 From dholmes at openjdk.org Wed Nov 6 17:40:11 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com> On Thu, 31 Oct 2024 01:32:19 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/objectMonitor.inline.hpp line 207: > >> 205: } >> 206: >> 207: inline bool ObjectMonitor::has_successor() { > > Why are _succ accesses atomic here when previously they were not? General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823698001 From pchilanomate at openjdk.org Wed Nov 6 17:40:11 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com> Message-ID: On Thu, 31 Oct 2024 16:34:41 GMT, Patricio Chilano Mateo wrote: >> General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic. > >> Why are _succ accesses atomic here when previously they were not? >> > They should had always been atomic. > But I agree it seems odd when direct accesses to _succ in the main cpp file are not atomic. > There was only one remaining direct access in debugging function `print_debug_style_on` which I fixed now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794795 From pchilanomate at openjdk.org Wed Nov 6 17:40:11 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 08:08:56 GMT, Stefan Karlsson wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/share/runtime/objectMonitor.hpp line 325: > >> 323: } >> 324: >> 325: bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; } > > Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`. I renamed both `set/has_owner_anonymous` to `set/has_anonymous_owner`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701746 From pchilanomate at openjdk.org Wed Nov 6 17:40:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com> Message-ID: <1MAelVhUXDdz7GI63iJPUEg6QeOQ4DO4S0B0_eC3CRQ=.ec5ff767-4b75-40ab-b40c-1579907b978a@github.com> On Mon, 28 Oct 2024 11:59:57 GMT, Coleen Phillimore wrote: >> The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread. > > ok, I now I see what the discussion is. Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this. Changed to locking_thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819461999 From coleenp at openjdk.org Wed Nov 6 17:40:12 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 21:29:05 GMT, Patricio Chilano Mateo wrote: >> I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too. > >> If it's always the current thread, then it should be called 'current' imo. >> > The inflating thread is always the current one but it's not always equal to `inflating_thread`. I thought locking_thread there may not be the current thread for enter_for() in deopt. It's the thread that should hold the lock but not the current thread. But it might be different now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817423564 From coleenp at openjdk.org Wed Nov 6 17:40:12 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com> References: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com> Message-ID: On Mon, 28 Oct 2024 00:38:39 GMT, David Holmes wrote: >> I thought locking_thread there may not be the current thread for enter_for() in deopt. It's the thread that should hold the lock but not the current thread. But it might be different now. > > The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread. ok, I now I see what the discussion is. Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818935916 From pchilanomate at openjdk.org Wed Nov 6 17:40:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Fri, 25 Oct 2024 21:28:22 GMT, Patricio Chilano Mateo wrote: >> If it's always the current thread, then it should be called 'current' imo. > > I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too. > If it's always the current thread, then it should be called 'current' imo. > The inflating thread is always the current one but it's not always equal to `inflating_thread`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389882 From dholmes at openjdk.org Wed Nov 6 17:40:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com> On Fri, 25 Oct 2024 22:29:56 GMT, Coleen Phillimore wrote: >>> If it's always the current thread, then it should be called 'current' imo. >>> >> The inflating thread is always the current one but it's not always equal to `inflating_thread`. > > I thought locking_thread there may not be the current thread for enter_for() in deopt. It's the thread that should hold the lock but not the current thread. But it might be different now. The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240440 From alanb at openjdk.org Wed Nov 6 17:40:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Wed, 23 Oct 2024 06:11:26 GMT, David Holmes wrote: >> Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait. > > Suggestion: `timedWaitCounter` ? We could rename it to timedWaitSeqNo if needed. >> A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19). >> >> More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed. > > Okay but .... > 1. We have the current virtual thread > 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object > 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name? Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier. setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812537648 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810636960 From pchilanomate at openjdk.org Wed Nov 6 17:40:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Wed, 23 Oct 2024 11:32:54 GMT, Alan Bateman wrote: >> Suggestion: `timedWaitCounter` ? > > We could rename it to timedWaitSeqNo if needed. Ok, renamed to timedWaitSeqNo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240667 From alanb at openjdk.org Wed Nov 6 17:40:12 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> Message-ID: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> On Thu, 24 Oct 2024 02:47:14 GMT, David Holmes wrote: >> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor. > > So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have: > > RUNNING -> BLOCKING -> BLOCKED > BLOCKED -> UNBLOCKING -> RUNNABLE > > I'm just trying to get a better sense of what we can infer if we see these "transition" states. We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it. >> When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry. > > Thanks for the explanation but that needs to be documented somewhere. The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814517084 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818670426 From dholmes at openjdk.org Wed Nov 6 17:40:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> Message-ID: On Thu, 24 Oct 2024 08:26:12 GMT, Alan Bateman wrote: >> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have: >> >> RUNNING -> BLOCKING -> BLOCKED >> BLOCKED -> UNBLOCKING -> RUNNABLE >> >> I'm just trying to get a better sense of what we can infer if we see these "transition" states. > > We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it. Okay but I'm finding it hard to see these names and easily interpret what some of them mean. I think there is a difference between UNBLOCKED and UNPARKED, because as an API once you are unparked that is it - operation over. But for UNBLOCKED you are still in a transitional state and it is not yet determined what you will actually end up doing i.e. get the monitor or block again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815761305 From dholmes at openjdk.org Wed Nov 6 17:40:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> Message-ID: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> On Tue, 22 Oct 2024 11:52:46 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/VirtualThread.java line 115: >> >>> 113: * RUNNING -> WAITING // transitional state during wait on monitor >>> 114: * WAITING -> WAITED // waiting on monitor >>> 115: * WAITED -> BLOCKED // notified, waiting to be unblocked by monitor owner >> >> Waiting to re-enter the monitor? > > yes Okay so should it say that? >> src/java.base/share/classes/java/lang/VirtualThread.java line 178: >> >>> 176: // timed-wait support >>> 177: private long waitTimeout; >>> 178: private byte timedWaitNonce; >> >> Strange name - what does this mean? > > Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait. Suggestion: `timedWaitCounter` ? >> src/java.base/share/classes/java/lang/VirtualThread.java line 530: >> >>> 528: && carrier == Thread.currentCarrierThread(); >>> 529: carrier.setCurrentThread(carrier); >>> 530: Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread >> >> I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ?? > > A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19). > > More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed. Okay but .... 1. We have the current virtual thread 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811937674 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811938604 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810615473 From dholmes at openjdk.org Wed Nov 6 17:40:13 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Tue, 22 Oct 2024 12:31:24 GMT, Alan Bateman wrote: >> Okay but .... >> 1. We have the current virtual thread >> 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object >> 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name? > > Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier. setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier. If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing. Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811877637 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> Message-ID: On Thu, 24 Oct 2024 02:55:18 GMT, David Holmes wrote: >>> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct? >>> >> Yes. > > I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread. We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697084 From dholmes at openjdk.org Wed Nov 6 17:40:13 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> On Wed, 23 Oct 2024 20:36:23 GMT, Patricio Chilano Mateo wrote: >> Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back. >> We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos. >> >> [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491 > >> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct? >> > Yes. I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814167842 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Wed, 23 Oct 2024 20:34:48 GMT, Patricio Chilano Mateo wrote: >> If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing. >> >> Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct? > > Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back. > We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos. > > [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491 > Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct? > Yes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813507846 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> Message-ID: On Wed, 23 Oct 2024 05:18:10 GMT, David Holmes wrote: >> Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier. setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier. > > If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing. > > Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct? Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back. We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos. [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813503450 From alanb at openjdk.org Wed Nov 6 17:40:13 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> Message-ID: On Thu, 24 Oct 2024 22:13:27 GMT, David Holmes wrote: >> We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps. > > Sorry to belabour this but why are we temporarily changing the thread identity? What is the bigger operation that in underway here? We've had these temporary transitions from day 1. The changes in this PR remove one usage, they don't add any new usages. The intention is to make this nuisance go away. The last usage requires changes to the timer support, working on it. For now, it's easiest to think of it as a "java on java" issue where critical code is in Java rather than the VM. The timer issue arises when a virtual thread does a timed park needs to schedule and cancel a timer. This currently requires executing Java code that may contend on a timer or trigger a timer thread to start. This has implications for thread state, the park blocker, and the parking permit. Adding support for nested parking gets very messy, adds overhead, and is confusing for serviceability observers. The exiting behavior is to just temporarily switch the thread identity (as in Thread::currentThread) so it executes in the context of the carrier rather than the virtual thread. As I said, we are working to make this go away, it would have been nice to have removed in advance of the changes here. Update: The temporary transitions are now removed in the fibers branch (loom repo). This removes the switchToCarrierThread and switchToVirtualThread methods, and removes the need to introduce setCurrentLockId that is hard to explain in the discussions here. Need to decide if we should include it in this PR or try to do it before or after. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816425590 From dholmes at openjdk.org Wed Nov 6 17:40:13 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com> <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com> <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com> Message-ID: On Thu, 24 Oct 2024 21:08:47 GMT, Patricio Chilano Mateo wrote: >> I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread. > > We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps. Sorry to belabour this but why are we temporarily changing the thread identity? What is the bigger operation that in underway here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815762233 From aturbanov at openjdk.org Wed Nov 6 17:40:13 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323: > 321: var started2 = new AtomicBoolean(); > 322: > 323: Thread vthread1 = Thread.ofVirtual().unstarted(() -> { Suggestion: Thread vthread1 = Thread.ofVirtual().unstarted(() -> { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808287799 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Mon, 21 Oct 2024 08:01:09 GMT, Andrey Turbanov wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323: > >> 321: var started2 = new AtomicBoolean(); >> 322: >> 323: Thread vthread1 = Thread.ofVirtual().unstarted(() -> { > > Suggestion: > > Thread vthread1 = Thread.ofVirtual().unstarted(() -> { Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809073267 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> References: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com> <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com> Message-ID: On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman wrote: >> Thanks for the explanation but that needs to be documented somewhere. > > The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in. Brought the comment from the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826160691 From pchilanomate at openjdk.org Wed Nov 6 17:40:13 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:40:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman wrote: >> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57: >> >>> 55: static { >>> 56: try { >>> 57: MethodHandles.lookup().ensureInitialized(AnchorCertificates.class); >> >> Why is this needed? A comment would help. > > That's probably a good idea. It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority. Added comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826153929 From pchilanomate at openjdk.org Wed Nov 6 17:53:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:53:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <4EGJTS9LsdYLK3ecIsExhUZaQupaES8wASP95dS88Cc=.3646b0fe-6e6c-4884-b37f-08360f8e144b@github.com> On Mon, 4 Nov 2024 07:59:22 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62: >> >>> 60: NATIVE(2, "Native frame or on stack"), >>> 61: MONITOR(3, "Monitor held"), >>> 62: CRITICAL_SECTION(4, "In critical section"); >> >> Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? >> >> I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string. > > That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue. > > Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that. These have been updated with the latest JFR changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831465256 From pchilanomate at openjdk.org Wed Nov 6 17:52:59 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 17:52:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 06:36:58 GMT, Axel Boldt-Christmas wrote: > A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. > > ``` > // the sp of the oldest known interpreted/call_stub frame inside the > // continuation that we know about > ``` > Updated comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2460396452 From kevinw at openjdk.org Wed Nov 6 19:11:38 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 6 Nov 2024 19:11:38 GMT Subject: RFR: 8343730: JMX cleanups Message-ID: A few small cleanup changes in javax/management. No logic changes, comments and text only. ------------- Commit messages: - 8343730: JMX cleanups Changes: https://git.openjdk.org/jdk/pull/21938/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21938&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343730 Stats: 12 lines in 4 files changed: 0 ins; 5 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/21938.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21938/head:pull/21938 PR: https://git.openjdk.org/jdk/pull/21938 From pchilanomate at openjdk.org Wed Nov 6 19:40:47 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 19:40:47 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: <79vVMnHrSZ9MEDcn0UzBYaPJKz63XZ3a7Qn4N0i-pa8=.adbe56c4-4a73-4015-b364-0196f1a4a75a@github.com> On Mon, 28 Oct 2024 00:29:25 GMT, David Holmes wrote: >> I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id. >> >> >> $ grep -r JFR_THREAD_ID >> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread)) >> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id()) >> runtime/objectMonitor.cpp: _previous_owner_tid = JFR_THREAD_ID(current); >> runtime/objectMonitor.cpp: iterator->_notifier_tid = JFR_THREAD_ID(current); >> runtime/vmThread.cpp: event->set_caller(JFR_THREAD_ID(op->calling_thread())); > > Then it looks like the JFR code needs updating as well, otherwise it is going to be reporting inconsistent information when virtual threads are locking monitors. So we use the os thread id when INCLUDE_JFR is not defined, but in that case we never actually post JFR events. So these _previous_owner_tid/_notifier_tid will be unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831592617 From pchilanomate at openjdk.org Wed Nov 6 19:40:46 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 19:40:46 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 02:09:24 GMT, Dean Long wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 223: > >> 221: } >> 222: >> 223: void StubAssembler::epilogue(bool use_pop) { > > Is there a better name we could use, like `trust_fp` or `after_resume`? I think `trust_fp` would be confusing because at this point rfp will have an invalid value and we don't want to use it to restore sp, i.e. we should not trust fp. And `after_resume` wouldn't always apply since we don't always preempt. The `use_pop` name was copied form x64, but I think it's still fine here. We also have the comment right below this line which explains why we don't want to use `leave()` and instead pop the top words from the stack. > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 324: > >> 322: movq(scrReg, tmpReg); >> 323: xorq(tmpReg, tmpReg); >> 324: movptr(boxReg, Address(r15_thread, JavaThread::lock_id_offset())); > > I don't know if it helps to schedule this load earlier (it is used in the next instruction), but it probably won't hurt. I moved it before `movq(scrReg, tmpReg)` since we need `boxReg` above, but I don't think this will change anything. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1659: > >> 1657: int i = 0; >> 1658: for (frame f = freeze_start_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map), i++) { >> 1659: if (!((f.is_compiled_frame() && !f.is_deoptimized_frame()) || (i == 0 && (f.is_runtime_frame() || f.is_native_frame())))) { > > OK, `i == 0` just means first frame here, so you could use a bool instead of an int, or even check for f == freeze_start_frame(), right? Changed to use boolean `is_top_frame`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831594384 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831597325 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831599268 From pchilanomate at openjdk.org Wed Nov 6 19:40:48 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 6 Nov 2024 19:40:48 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Sat, 26 Oct 2024 05:39:32 GMT, Alan Bateman wrote: >> test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30: >> >>> 28: * by reflection API >>> 29: * @library /test/lib/ >>> 30: * @requires vm.compMode != "Xcomp" >> >> If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix. > > JBS has several issues related to ReflectionCallerCacheTest.java and -Xcomp, going back several releases. It seems some nmethod is keeping objects alive and is preventing class unloading in this test. The refactoring of j.l.ref in JDK 19 to workaround pinning issues made it go away. There is some minimal revert in this PR to deal with the potential for preemption when polling a reference queue and it seems the changes to this Java code have brought back the issue. So it's excluded from -Xcomp again. Maybe it would be better to add it to ProblemList-Xcomp.txt instead? That would allow it to link to one of the JSB issue on this issue. I added the test to `test/jdk/ProblemList-Xcomp.txt` instead with a reference to 8332028. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831604339 From kbarrett at openjdk.org Wed Nov 6 21:27:59 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 6 Nov 2024 21:27:59 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2419454529 From kbarrett at openjdk.org Wed Nov 6 21:28:00 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 6 Nov 2024 21:28:00 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com> Message-ID: On Wed, 6 Nov 2024 15:27:16 GMT, Magnus Ihse Bursie wrote: >> src/java.base/share/native/libjava/NativeLibraries.c line 67: >> >>> 65: strcat(jniEntryName, "_"); >>> 66: strcat(jniEntryName, cname); >>> 67: } >> >> I would prefer this be directly inlined at the sole call (in findJniFunction), >> to make it easier to verify there aren't any buffer overrun problems. (I don't >> think there are, but looking at this in isolation triggered warnings in my >> head.) >> >> Also, it looks like all callers of findJniFunction ensure the cname argument >> is non-null. So there should be no need to handle the null case in >> findJniFunction (other than perhaps an assert or something). That could be >> addressed in a followup. (I've already implicitly suggested elsewhere in this >> PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS >> thing.) > > @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already. The first part, eliminating the (IMO not actually helpful) helper function, I wanted done here. The second part, cleaning up or commenting the calculation of the length and dealing with perhaps unneeded conditionals, I'm okay with being in a followup. I guess I can live with the first part being in that followup too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831728737 From pchilanomate at openjdk.org Thu Nov 7 00:38:18 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:38:18 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/211c6c81..37e30171 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=00-01 Stats: 108 lines in 7 files changed: 65 ins; 33 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Thu Nov 7 00:43:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 16:31:24 GMT, Serguei Spitsyn wrote: >> Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue. >> For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic. >> When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread. >> >> [1] https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629 > > Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks. > >> but does the specs say the event has to be posted in the context of the vthread? > > As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context. > >> For pop_frame/early_ret checks ... > > The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. > >> Maybe we could go with this simplified code now and work on it later... > > Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this. > It would be nice to fix a couple of nits though: > - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark` > - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898126 From pchilanomate at openjdk.org Thu Nov 7 00:43:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 00:37:53 GMT, Patricio Chilano Mateo wrote: >> Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished. > >> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. >> > The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java. > the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark > Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898891 From pchilanomate at openjdk.org Thu Nov 7 00:43:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 00:37:17 GMT, Patricio Chilano Mateo wrote: >> Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks. >> >>> but does the specs say the event has to be posted in the context of the vthread? >> >> As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context. >> >>> For pop_frame/early_ret checks ... >> >> The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. >> >>> Maybe we could go with this simplified code now and work on it later... >> >> Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this. >> It would be nice to fix a couple of nits though: >> - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark` >> - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter > > Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished. > So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. > The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898439 From pchilanomate at openjdk.org Thu Nov 7 00:43:08 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 00:38:40 GMT, Patricio Chilano Mateo wrote: >>> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help. >>> >> The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java. > >> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark >> > Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both? > the function is_vthread_safe_to_preempt() does not need the vthread parameter > Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831899049 From pchilanomate at openjdk.org Thu Nov 7 00:43:08 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 00:43:08 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com> On Wed, 6 Nov 2024 15:57:55 GMT, Serguei Spitsyn wrote: > The two extension events were designed to be posted when the current thread identity is virtual, so this behavior > needs to be considered as a bug. My understanding is that it is not easy to fix. > If we want to post the mount/unmount events here is actually simple if we also use `JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount`. I included it in the last commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831899882 From lmesnik at openjdk.org Thu Nov 7 01:26:41 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 7 Nov 2024 01:26:41 GMT Subject: RFR: 8343505: Problemlist AttachTest.java and TestZPageAllocationEvent.java [v4] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 08:39:08 GMT, SendaoYan wrote: >> Hi all, >> To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > move to jdk_lang section Please update bug/PR summary to reflect actual changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21917#issuecomment-2461128420 From syan at openjdk.org Thu Nov 7 01:50:43 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 7 Nov 2024 01:50:43 GMT Subject: RFR: 8343505: Problemlist java/lang/Thread/jni/AttachCurrentThread/AttachTest.java [v4] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 01:23:32 GMT, Leonid Mesnik wrote: > Please update bug/PR summary to reflect actual changes. Thanks for the remind. The bug and PR summary has been updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21917#issuecomment-2461149994 From lmesnik at openjdk.org Thu Nov 7 02:09:42 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 7 Nov 2024 02:09:42 GMT Subject: RFR: 8343505: Problemlist java/lang/Thread/jni/AttachCurrentThread/AttachTest.java [v4] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 08:39:08 GMT, SendaoYan wrote: >> Hi all, >> To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > move to jdk_lang section Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21917#pullrequestreview-2419794368 From dholmes at openjdk.org Thu Nov 7 03:03:41 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 7 Nov 2024 03:03:41 GMT Subject: RFR: 8343505: Problemlist java/lang/Thread/jni/AttachCurrentThread/AttachTest.java [v4] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 08:39:08 GMT, SendaoYan wrote: >> Hi all, >> To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > move to jdk_lang section LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21917#pullrequestreview-2419845552 From syan at openjdk.org Thu Nov 7 03:14:50 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 7 Nov 2024 03:14:50 GMT Subject: RFR: 8343505: Problemlist java/lang/Thread/jni/AttachCurrentThread/AttachTest.java [v4] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 08:39:08 GMT, SendaoYan wrote: >> Hi all, >> To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > move to jdk_lang section Thanks all for the correction and review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21917#issuecomment-2461231303 From syan at openjdk.org Thu Nov 7 03:14:51 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 7 Nov 2024 03:14:51 GMT Subject: Integrated: 8343505: Problemlist java/lang/Thread/jni/AttachCurrentThread/AttachTest.java In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 02:39:24 GMT, SendaoYan wrote: > Hi all, > To make less CI noisy, before the root cause of [JDK-8343244](https://bugs.openjdk.org/browse/JDK-8343244) has fixed, should we problemlist the failure tests, include AttachTest.java and TestZPageAllocationEvent.java This pull request has now been integrated. Changeset: f2316f68 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/f2316f6829c9b671e992401ee39d7a1a1805857e Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8343505: Problemlist java/lang/Thread/jni/AttachCurrentThread/AttachTest.java Reviewed-by: dholmes, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/21917 From sspitsyn at openjdk.org Thu Nov 7 04:51:45 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 04:51:45 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v3] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 17:20:49 GMT, Larry Cable wrote: >> the implementation I originally provided does not in fact solve the issue! >> >> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). >> >> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach >> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. >> >> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). >> >> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. >> >> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". >> >> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". >> >> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). >> >> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. >> >> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. >> >> therefore an "attacher" has two choices when attempting to attach: >> >> - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) >> - this works with both peers and descendants >> >> - use /tmp >> - this only works if the "attacher" and "attachee" share a /tmp in common >> >> the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. >> >> I... > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8342449: fixed missing param in throws msg and renamed local var src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 268: > 266: * however we can also check the target pid's signal masks to see if it catches SIGQUIT and only do so if in > 267: * fact it does ... this reduces the risk of killing an innocent process in the current ns as opposed to > 268: * attaching to the actual target JVM ... c.f: checkCatchesAndSendQuitTo() below. This still looks pretty risky and dangerous. I'm thinking if it'd make sense to check that the target process is a VM process. At least, we know how VM processes can use the signal mask. Another concern is that the target VM process might be not exactly the same VM the client was expecting to attach. I don't know what can be done to ensure this correctness. src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 327: > 325: private static final String SIGNAL_MASK_PATTERN = "(?<" + FIELD + ">Sig\\p{Alpha}{3}):\\s+(?<" + MASK + ">\\p{XDigit}{16}).*"; > 326: > 327: private static final long SIGQUIT = 1L << 2; Q: why not just 3L ? :) src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 340: > 338: var readBlk = false; > 339: var readIgn = false; > 340: var readCgt = false; Nit: - Minor suggestion to order the lines 338-430 same as lines 330-332 and place them after them - Never liked single-letter identifiers because they are not well searchable. I'd suggest to: rename `p` to something like `pattern` or `ptrn` and `m` to something like `matcher` or `match`. src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 364: > 362: case "SigIgn": { quitIgn = sigquit; readCgt = true; break; } > 363: case "SigCgt": { quitCgt = sigquit; readIgn = true; break; } > 364: } Q: The `readIgn` and `readCgt` are swapped at lines 362-363. Is it intentional or just a typo? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1832048612 PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1832037498 PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1832040824 PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1832042138 From sspitsyn at openjdk.org Thu Nov 7 05:06:43 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 05:06:43 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v3] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 17:20:49 GMT, Larry Cable wrote: >> the implementation I originally provided does not in fact solve the issue! >> >> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). >> >> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach >> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. >> >> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). >> >> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. >> >> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". >> >> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". >> >> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). >> >> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. >> >> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. >> >> therefore an "attacher" has two choices when attempting to attach: >> >> - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) >> - this works with both peers and descendants >> >> - use /tmp >> - this only works if the "attacher" and "attachee" share a /tmp in common >> >> the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. >> >> I... > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8342449: fixed missing param in throws msg and renamed local var src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 358: > 356: signals = signals.substring(slen / 2 , slen); // only really interested in the non r/t signals ... > 357: > 358: final var sigquit = (Long.valueOf(signals, 16) & SIGQUIT) != 0L; Nit: Would it better to rename the `sigquit` identifier to something like `mask_bit_value`, `maskBitValue` or just `bitVal`? (Note: It is quite strange this file uses a mixed Java and C/C++ naming convention) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1832057983 From cjplummer at openjdk.org Thu Nov 7 05:33:41 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 7 Nov 2024 05:33:41 GMT Subject: RFR: 8343730: JMX cleanups In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 17:55:47 GMT, Kevin Walls wrote: > A few small cleanup changes in javax/management. > No logic changes, comments and text only. Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21938#pullrequestreview-2419981620 From duke at openjdk.org Thu Nov 7 08:32:16 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Thu, 7 Nov 2024 08:32:16 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: Fix backslides in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21826/files - new: https://git.openjdk.org/jdk/pull/21826/files/9754145b..e79b7bde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21826&range=01-02 Stats: 10 lines in 2 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/21826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21826/head:pull/21826 PR: https://git.openjdk.org/jdk/pull/21826 From duke at openjdk.org Thu Nov 7 08:32:16 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Thu, 7 Nov 2024 08:32:16 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 16:02:07 GMT, Kim Barrett wrote: > Can you use the (updated) regex in the JBS issue description to verify the only remaining "NULL"s in src/hotspot are the jvmti.{xml,xls} files and the globalDefinitions_{gcc,visCPP}.hpp files? > > There are also some NULLs recently introduced in test/hotspot: ./jtreg/serviceability/jvmti/GetMethodDeclaringClass/libTestUnloadedClass.cpp ./jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp > > (Found by applying the same regex to test/hotspot, and then removing .java and .c files.) > > There are a few other files in test/hotspot containing NULLs: ./jtreg/vmTestbase/nsk/share/jni/README ./jtreg/vmTestbase/nsk/share/jvmti/README These are documentation files with examples written in C, so should not be changed. > > ./jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp In a comment describing a string to be used for printing. Uses would need to be examined to ensure it's okay to change the string used for a null value. I think I planned to do this as a followup to JDK-8324799, and then forgot. I'd be okay with doing something about this being separate from the current PR. While the necessary textual changes are probably small, there's a lot of uses to examine to be sure a change is okay. @kimbarrett I fixed the backslides in the *.cpp files you mentioned. The egrep outputs are now: % find test/hotspot -type f ! -name "*.c" ! -name "*.java" -exec egrep -H "[^[:alnum:]_]NULL([^[:alnum:]_]|$)" {} ; test/hotspot/jtreg/vmTestbase/nsk/share/native/nsk_tools.hpp: * Returns str or "" if str is null; useful for printing strings. test/hotspot/jtreg/vmTestbase/nsk/share/jvmti/README: if (!NSK_JVMTI_VERIFY(jvmti->GetVersion(&version) != NULL)) { test/hotspot/jtreg/vmTestbase/nsk/share/jni/README: jni->FindClass(class_name) != NULL)) { test/hotspot/jtreg/vmTestbase/nsk/share/jni/README: jni->FindClass(class_name)) != NULL)) { and egrep -R "[^[:alnum:]_]NULL([^[:alnum:]_]|$)" src/hotspot src/hotspot/share/prims/jvmti.xml: or return value. A "null pointer" is C NULL or C++ nullptr. src/hotspot/share/prims/jvmti.xml: &methodName, NULL, NULL); src/hotspot/share/prims/jvmti.xml: GetThreadCpuTime(env, NULL, nanos_ptr) src/hotspot/share/prims/jvmti.xsl: , NULL) src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// When __cplusplus is defined, NULL is defined as 0 (32-bit constant) in src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// On 64-bit architectures, defining NULL as a 32-bit constant can cause src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// varargs, we pass the argument 0 as an int. So, if NULL was passed to a src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// only 32-bits of the "NULL" pointer may be initialized to zero. The src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// Solution: For 64-bit architectures, redefine NULL as 64-bit constant 0. src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#undef NULL src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#define NULL 0LL src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#ifndef NULL src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#define NULL 0 src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// NULL vs NULL_WORD: src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:// On Linux NULL is defined as a special type '__null'. Assigning __null to src/hotspot/share/utilities/globalDefinitions_visCPP.hpp:#define NULL_WORD NULL src/hotspot/share/utilities/globalDefinitions_gcc.hpp:// NULL vs NULL_WORD: src/hotspot/share/utilities/globalDefinitions_gcc.hpp:// On Linux NULL is defined as a special type '__null'. Assigning __null to src/hotspot/share/utilities/globalDefinitions_gcc.hpp: #define NULL_WORD NULL ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2461610347 From amitkumar at openjdk.org Thu Nov 7 08:47:14 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 7 Nov 2024 08:47:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: <8WsQTNy83zv4Z7kD6SPo60kURL1EFe3ZMbD4QCqo3II=.3895ed74-7940-436a-aff2-f7aeafbef2b3@github.com> On Wed, 6 Nov 2024 17:38:59 GMT, Patricio Chilano Mateo wrote: >> Good work! I'll approve the GC related changes. >> >> There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR. >> >> Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what. You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre. >> >> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. >> >> // the sp of the oldest known interpreted/call_stub frame inside the >> // continuation that we know about > >> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. >> >> ``` >> // the sp of the oldest known interpreted/call_stub frame inside the >> // continuation that we know about >> ``` >> > Updated comment. @pchilano `CancelTimerWithContention.java` test is failing on s390x with Timeout Error. One weird thing is that it only fails when I run whole tier1 test suite. But when ran independently test passes. One thing I would like to mention is that I ran test by **disabling** VMContinuations, as Vthreads are not yet supported by s390x. [CancelTimerWithContention.log](https://github.com/user-attachments/files/17658594/CancelTimerWithContention.log) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461640546 From alanb at openjdk.org Thu Nov 7 09:43:11 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 7 Nov 2024 09:43:11 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com> On Wed, 6 Nov 2024 17:38:59 GMT, Patricio Chilano Mateo wrote: >> Good work! I'll approve the GC related changes. >> >> There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR. >> >> Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what. You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre. >> >> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. >> >> // the sp of the oldest known interpreted/call_stub frame inside the >> // continuation that we know about > >> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this. >> >> ``` >> // the sp of the oldest known interpreted/call_stub frame inside the >> // continuation that we know about >> ``` >> > Updated comment. > @pchilano `CancelTimerWithContention.java` test is failing on s390x with Timeout Error. One weird thing is that it only fails when I run whole tier1 test suite. But when ran independently test passes. > > One thing I would like to mention is that I ran test by **disabling** VMContinuations, as Vthreads are not yet supported by s390x. We added this test to provoke contention on the delay queues, lots of timed-Object.wait with notification before the timeout is reached. This code is not used when running with -XX:+UnlockExperimentalVMOptions -XX:-VMContinuation. In that execution mode, each virtual thread is backed by a platform/native thread and in this test it will ramp up 10_000 virtual threads. The output in your log suggests it gets to ~4700 threads before the jtreg timeout kicks in. It might be that when you run the test on its own that there is enough resources for the test to pass, but not enough resources (just too slow) when competing with other tests. I think we can add `@requires vm.continuations` to this test. It's not useful to run with the alternative virtual thread implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461756432 From amitkumar at openjdk.org Thu Nov 7 09:49:12 2024 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 7 Nov 2024 09:49:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com> References: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com> Message-ID: <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com> On Thu, 7 Nov 2024 09:40:19 GMT, Alan Bateman wrote: >I think we can add @requires vm.continuations to this test. It's not useful to run with the alternative virtual thread implementation. Sure, that sounds ok. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461768715 From shade at openjdk.org Thu Nov 7 12:12:01 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Nov 2024 12:12:01 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 00:56:49 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> fix: jvm_md.h was included, but not jvm.h... > > src/hotspot/os/windows/os_windows.cpp line 510: > >> 508: // Thread start routine for all newly created threads. >> 509: // Called with the associated Thread* as the argument. >> 510: static unsigned thread_native_entry(void* t) { > > Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`. > https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170 Not sure why this comment was marked as "Resolved". I have the same question here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1832573434 From shade at openjdk.org Thu Nov 7 12:18:57 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 7 Nov 2024 12:18:57 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2420814976 From jwaters at openjdk.org Thu Nov 7 12:18:58 2024 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 7 Nov 2024 12:18:58 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Thu, 7 Nov 2024 12:08:50 GMT, Aleksey Shipilev wrote: >> src/hotspot/os/windows/os_windows.cpp line 510: >> >>> 508: // Thread start routine for all newly created threads. >>> 509: // Called with the associated Thread* as the argument. >>> 510: static unsigned thread_native_entry(void* t) { >> >> Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`. >> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170 > > Not sure why this comment was marked as "Resolved". I have the same question here. @shipilev See addressing comments below: > https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170 > On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack. > To my knowledge the only thing __cdecl and __stdcall do is affect the argument passing on the stack since 32 bit uses the stack to pass arguments. Since 64 bit passes arguments inside registers and then only later uses the stack if there are too many parameters to fit in the parameter registers (Basically permanent __fastcall), these specifiers are probably ignored in all 64 bit platforms ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1832581212 From kevinw at openjdk.org Thu Nov 7 12:40:21 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 7 Nov 2024 12:40:21 GMT Subject: RFR: 8272780: ServerNotifForwarder.removeNotificationListener() incorrect exception handling Message-ID: Long-standing nit where an Exception could fail to be reported. One-character fix to a comparison. Does not cause any different results in any javax/management tests. ------------- Commit messages: - 8272780: ServerNotifForwarder.removeNotificationListener() incorrect exception handling Changes: https://git.openjdk.org/jdk/pull/21950/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21950&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8272780 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21950.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21950/head:pull/21950 PR: https://git.openjdk.org/jdk/pull/21950 From ihse at openjdk.org Thu Nov 7 13:00:02 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 7 Nov 2024 13:00:02 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. @shipilev Sure, I can revert the `_stdcall` changes from here and put them in a a separate PR. Kim also expressed a similar wish. Removing dead code like this is both a bit of an iterative process ("oh, now that we removed X, we can also remove Y"), and a bit of a judgement call ("now that `JNICALL` is not needed,we can remove it"). Sometimes it is not clear where to draw the line. Personally, I'm mostly interested in getting rid of all the junk in the build system; all the rest is just stuff I do as a "community service" to avoid having stuff laying around. (And I did it, under the (apparently na?ve) assumption that this would not require that much extra work :-), coupled with the (more cynical) assumption that if I did not do this, nothing would really happen on this front...) I personally do think that removing the obsolete `_stdcall` is "provably, uncontroversially, visibly safe". But then again, it's not me who is going to have to chase the future bugs, so I respect your opinion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462174907 From kevinw at openjdk.org Thu Nov 7 13:04:41 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 7 Nov 2024 13:04:41 GMT Subject: RFR: 8343730: JMX cleanups In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 17:55:47 GMT, Kevin Walls wrote: > A few small cleanup changes in javax/management. > No logic changes, comments and text only. Thanks Chris! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21938#issuecomment-2462183982 From kevinw at openjdk.org Thu Nov 7 13:13:46 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 7 Nov 2024 13:13:46 GMT Subject: Integrated: 8343730: JMX cleanups In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 17:55:47 GMT, Kevin Walls wrote: > A few small cleanup changes in javax/management. > No logic changes, comments and text only. This pull request has now been integrated. Changeset: d2b681d4 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/d2b681d4557109158fbbce9db995f4146c344c97 Stats: 12 lines in 4 files changed: 0 ins; 5 del; 7 mod 8343730: JMX cleanups Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/21938 From coleenp at openjdk.org Thu Nov 7 13:34:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 7 Nov 2024 13:34:50 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 23:57:48 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @DanHeidinga comment -- exit VM when runtimeSetup() fails I had a couple of drive by comments. src/hotspot/share/cds/aotConstantPoolResolver.cpp line 2: > 1: /* > 2: * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved. If this is a new file, it shouldn't have 2022 in the copyright year. src/hotspot/share/cds/aotConstantPoolResolver.cpp line 81: > 79: } > 80: > 81: if (!k->is_instance_klass()) { How can a field, interface or method cp reference point to a non-instance klass? Or is this for a method in java.lang.Object, which can be an array klass ? I doubt you should bother to support this special case. src/hotspot/share/cds/aotConstantPoolResolver.cpp line 138: > 136: } else if (elem->is_typeArray_klass()) { > 137: return true; > 138: } else { I think bottom_klass can only be InstanceKlass or typeArrayKlass, so else should be not possible and an assert. ------------- PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2420951812 PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832663874 PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832668217 PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832674559 From coleenp at openjdk.org Thu Nov 7 13:34:51 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 7 Nov 2024 13:34:51 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v8] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 13:16:19 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @DanHeidinga comment -- exit VM when runtimeSetup() fails > > src/hotspot/share/cds/aotConstantPoolResolver.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved. > > If this is a new file, it shouldn't have 2022 in the copyright year. Oh looks like it's been moved from classPrelinker, except git doesn't show it's moved. If it's added as a moved file, would there be less diffs to look at? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832685160 From stuefe at openjdk.org Thu Nov 7 15:28:05 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 7 Nov 2024 15:28:05 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: <6qzIK_QQ2Rs5deO4jIyicr7ob4CZCg7ajBnbEd9vCFU=.6fc95a24-9f01-4e61-bb21-442720c53437@github.com> On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. @shipilev @magicus Okay but where do we draw the line? Because then we also need to keep the code that takes care of x86 calling convention name mangling. [Microsoft states](https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170) "On ARM and x64 processors, __stdcall is accepted and *ignored by the compiler*; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack." Similar statements can be found in the MSDN documentation for __cdecl and __fastcall. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462517302 From lmesnik at openjdk.org Thu Nov 7 16:06:45 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 7 Nov 2024 16:06:45 GMT Subject: RFR: 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:15:37 GMT, Kevin Walls wrote: > This test is sensitive to timing, and should not run with -Xcomp (like NotifReconnectDeadlockTest.java). > > With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but if we handle that, it can also fail on the first iteration through the loop, at the call: JMXConnector client = JMXConnectorFactory.connect(addr, env); > > This test sets a short timeout value for connections, and -Xcomp slows things down greatly. RMI is gone before the connection is established. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21884#pullrequestreview-2421433057 From cjplummer at openjdk.org Thu Nov 7 16:11:43 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 7 Nov 2024 16:11:43 GMT Subject: RFR: 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:15:37 GMT, Kevin Walls wrote: > This test is sensitive to timing, and should not run with -Xcomp (like NotifReconnectDeadlockTest.java). > > With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but if we handle that, it can also fail on the first iteration through the loop, at the call: JMXConnector client = JMXConnectorFactory.connect(addr, env); > > This test sets a short timeout value for connections, and -Xcomp slows things down greatly. RMI is gone before the connection is established. What changed that caused it to suddenly start failing a lot? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21884#issuecomment-2462631378 From kevinw at openjdk.org Thu Nov 7 16:45:43 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 7 Nov 2024 16:45:43 GMT Subject: RFR: 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 16:09:22 GMT, Chris Plummer wrote: > What changed that caused it to suddenly start failing a lot? This is the test I changed recently in JDK-8343378 -- it used to not fail even if it threw an Exception. So I make that change, test, and see no failures. But of course -Xcomp testing comes around in tier8 and that can fail... Test sets a short connection timeout so is very timing-sensitive... (I've now linked the bugs.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21884#issuecomment-2462722488 From rkennke at openjdk.org Thu Nov 7 16:58:36 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Nov 2024 16:58:36 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v56] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 106 commits: - Merge tag 'jdk-25+23' into JDK-8305895-v4 Added tag jdk-24+23 for changeset c0e6c3b9 - Fix gen-ZGC removal - Merge tag 'jdk-24+22' into JDK-8305895-v4 Added tag jdk-24+22 for changeset 388d44fb - Enable riscv in CompressedClassPointersEncodingScheme test - s390 port - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test - Update copyright - Avoid assert/endless-loop in JFR code - Update copyright headers - Merge tag 'jdk-24+20' into JDK-8305895-v4 Added tag jdk-24+20 for changeset 7a64fbbb - ... and 96 more: https://git.openjdk.org/jdk/compare/c0e6c3b9...4d282247 ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=55 Stats: 5212 lines in 218 files changed: 3585 ins; 864 del; 763 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Thu Nov 7 17:25:40 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Nov 2024 17:25:40 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: - Merge branch 'master' into JDK-8305895-v4 - Merge tag 'jdk-25+23' into JDK-8305895-v4 Added tag jdk-24+23 for changeset c0e6c3b9 - Fix gen-ZGC removal - Merge tag 'jdk-24+22' into JDK-8305895-v4 Added tag jdk-24+22 for changeset 388d44fb - Enable riscv in CompressedClassPointersEncodingScheme test - s390 port - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test - Update copyright - Avoid assert/endless-loop in JFR code - Update copyright headers - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b ------------- Changes: https://git.openjdk.org/jdk/pull/20677/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20677&range=56 Stats: 5212 lines in 218 files changed: 3585 ins; 864 del; 763 mod Patch: https://git.openjdk.org/jdk/pull/20677.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20677/head:pull/20677 PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Thu Nov 7 17:33:11 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Nov 2024 17:33:11 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b I'd like to prepare for integration now. I merged from master and resolved some conflicts. I am now running at least tier1 on aarch64 x x86_64 x -UCOH x +UCOH, possibly tier2 .. 4, too (time permitting). In the meantime, could you please re-approve the PR? I hope it doesn't catch any more conflicts until we're ready for intergration. As soon as the JEP is targeted (sometime today, I think), tests are clean and approvals are there, I would like to integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2462834035 From coleenp at openjdk.org Thu Nov 7 17:46:11 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 7 Nov 2024 17:46:11 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Reapproving. Please wait for GHA to complete, when JEP is targeted to integrate. Thanks! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2421741026 From sspitsyn at openjdk.org Thu Nov 7 17:51:45 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 17:51:45 GMT Subject: RFR: 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:15:37 GMT, Kevin Walls wrote: > This test is sensitive to timing, and should not run with -Xcomp (like NotifReconnectDeadlockTest.java). > > With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but if we handle that, it can also fail on the first iteration through the loop, at the call: JMXConnector client = JMXConnectorFactory.connect(addr, env); > > This test sets a short timeout value for connections, and -Xcomp slows things down greatly. RMI is gone before the connection is established. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21884#pullrequestreview-2421751960 From stefank at openjdk.org Thu Nov 7 17:53:10 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 7 Nov 2024 17:53:10 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Marked as reviewed by stefank (Reviewer). Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2417620293 PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2421753879 From cjplummer at openjdk.org Thu Nov 7 18:06:42 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 7 Nov 2024 18:06:42 GMT Subject: RFR: 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:15:37 GMT, Kevin Walls wrote: > This test is sensitive to timing, and should not run with -Xcomp (like NotifReconnectDeadlockTest.java). > > With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but if we handle that, it can also fail on the first iteration through the loop, at the call: JMXConnector client = JMXConnectorFactory.connect(addr, env); > > This test sets a short timeout value for connections, and -Xcomp slows things down greatly. RMI is gone before the connection is established. Ok. Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21884#pullrequestreview-2421780061 From kevinw at openjdk.org Thu Nov 7 18:16:54 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 7 Nov 2024 18:16:54 GMT Subject: RFR: 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:15:37 GMT, Kevin Walls wrote: > This test is sensitive to timing, and should not run with -Xcomp (like NotifReconnectDeadlockTest.java). > > With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but if we handle that, it can also fail on the first iteration through the loop, at the call: JMXConnector client = JMXConnectorFactory.connect(addr, env); > > This test sets a short timeout value for connections, and -Xcomp slows things down greatly. RMI is gone before the connection is established. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21884#issuecomment-2462919164 From kevinw at openjdk.org Thu Nov 7 18:16:54 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 7 Nov 2024 18:16:54 GMT Subject: Integrated: 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 18:15:37 GMT, Kevin Walls wrote: > This test is sensitive to timing, and should not run with -Xcomp (like NotifReconnectDeadlockTest.java). > > With -Xcomp, this test can fail on the the conn.getDefaultDomain() call, but if we handle that, it can also fail on the first iteration through the loop, at the call: JMXConnector client = JMXConnectorFactory.connect(addr, env); > > This test sets a short timeout value for connections, and -Xcomp slows things down greatly. RMI is gone before the connection is established. This pull request has now been integrated. Changeset: 4f5a241e Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/4f5a241ec11981bcb5f8ab0936b0e821ec5a03ce Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod 8343491: javax/management/remote/mandatory/connection/DeadLockTest.java failing with NoSuchObjectException: no such object in table Reviewed-by: lmesnik, sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/21884 From sspitsyn at openjdk.org Thu Nov 7 18:33:14 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 18:33:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> References: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> Message-ID: On Thu, 7 Nov 2024 00:38:18 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount Thank you for updates! Looks good. Overall, it is a great job! test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp line 104: > 102: > 103: err = jvmti->GetMethodName(frameInfo[idx].method, &methodName, nullptr, nullptr); > 104: check_jvmti_status(jni, err, "event handler: error in JVMTI GetMethodName call"); Nit: There is the test library function `get_method_name()` in `jvmti_common.hpp` that can be used here. Also, the `methodName` is better to deallocate with the `deallocate() function. The same is in the `VirtualThreadMount` callback. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2421828032 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833167652 From sspitsyn at openjdk.org Thu Nov 7 18:33:14 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 18:33:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 00:38:57 GMT, Patricio Chilano Mateo wrote: >>> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark >>> >> Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both? > >> the function is_vthread_safe_to_preempt() does not need the vthread parameter >> > Removed. Thank you for the update! It looks okay to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833168776 From sspitsyn at openjdk.org Thu Nov 7 18:33:14 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 18:33:14 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com> References: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com> Message-ID: <8fsvkr2uAamrF-VvR5mNHGF4NF_FJkgMDzxLeVh1wNs=.54597efe-cc91-426d-ae86-f13d20a1f889@github.com> On Thu, 7 Nov 2024 00:40:26 GMT, Patricio Chilano Mateo wrote: >>> So at some point I think we need to figure out how to make them go away ... >> >> Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes. >> >>> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor... >> >> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though. >> >>> That's the path a virtual thread will take if pinned. >> >> Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend. > >> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior > needs to be considered as a bug. My understanding is that it is not easy to fix. >> > If we want to post the mount/unmount events here is actually simple if we also use `JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount`. I included it in the last commit. Thank you for the explanations and update. The update looks okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833171024 From kbarrett at openjdk.org Thu Nov 7 18:34:52 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 7 Nov 2024 18:34:52 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 08:32:16 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix backslides in test Looks good. The grep results are exactly as expected. Thanks for checking that. Now if we can just get the build to start checking for us, we can stop needing these periodic cleanups. I forget whether a JBS issue has been filed for that. If not, I will do so. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2421831752 From schernyshev at openjdk.org Thu Nov 7 18:35:01 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Thu, 7 Nov 2024 18:35:01 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v2] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision: - patch reimplemented - fix the logic that skips duplicate controller's mount points ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/c1c75896..6a761ca2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=00-01 Stats: 125 lines in 10 files changed: 3 ins; 75 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From sgehwolf at openjdk.org Thu Nov 7 18:35:01 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 7 Nov 2024 18:35:01 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 13:13:07 GMT, Sergey Chernyshev wrote: > As they're in fact mounting read-write, the logic picked up `rw` mount option and falsely detected "host mode". Also the `--privileged` creates `rw` mounts, so the entire approach needs correction. Yes. See https://bugs.openjdk.org/browse/JDK-8261242 for details. This patch shouldn't change it and the logic of `OSContainer::is_containerized()` shouldn't change semantically in all scenarios. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2454229684 From schernyshev at openjdk.org Thu Nov 7 18:35:01 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Thu, 7 Nov 2024 18:35:01 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev wrote: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Here's an updated version of the patch. The long standing behavior was to leave `_path` uninitialized when `_root` is not "`/`" and not equal to `cgroup_path`. The issue can be reproduced as follows. Create a new cgroup for memory sudo mkdir -p /sys/fs/cgroup/memory/test Run the following script docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m ubuntu:latest \ sh -c "sleep 10 ; /jdk/bin/java -Xlog:os+container=trace -version" | grep Memory\ Limit & sleep 10 HOSTPID=$(sudo ps -ef | awk '/container=trace/ && !/docker/ && !/awk/ { print $2 }') echo $HOSTPID | sudo tee /sys/fs/cgroup/memory/test/cgroup.procs sleep 10 In the above script, a containerized process (`/bin/sh`) is moved to cgroup `/test` before `/jdk/bin/java` gets executed. Java inherits cgroup `/test` from its parent process, its `_root` will be `/docker/`, `cgroup_path` will be `/test`. The result would be ($JAVA_HOME points to JDK before fix) 9804 [0.001s][trace][os,container] Memory Limit failed: -2 [0.001s][trace][os,container] Memory Limit failed: -2 [0.002s][trace][os,container] Memory Limit failed: -2 [0.043s][trace][os,container] Memory Limit failed: -2 JDK updated version: 10001 [0.001s][trace ][os,container] Memory Limit is: 419430400 [0.001s][trace ][os,container] Memory Limit is: 419430400 [0.002s][trace ][os,container] Memory Limit is: 419430400 [0.035s][trace ][os,container] Memory Limit is: 419430400 The updated version falls back to the mount point (only when `_root` is other than `"/"`). **Testing** - Standard tiers (1-3) - jtreg:test/jdk/jdk/internal/platform - jtreg:test/hotspot/jtreg/containers - gtest:cgroupTest ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2462243544 From sspitsyn at openjdk.org Thu Nov 7 18:38:07 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 7 Nov 2024 18:38:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> References: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> Message-ID: On Thu, 7 Nov 2024 00:38:18 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount src/hotspot/share/prims/jvmtiThreadState.cpp line 2: > 1: /* > 2: * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved. Nit: No need in the copyright update anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833174843 From kbarrett at openjdk.org Thu Nov 7 18:42:02 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 7 Nov 2024 18:42:02 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: <3Rg6yosMIl2HdD2FNR-dPM8dSWZiIS3irKW0uOxNnh8=.91ba8741-d3fb-4ecd-9651-325d4f06f9ca@github.com> On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. > @shipilev Sure, I can revert the `_stdcall` changes from here and put them in a a separate PR. Kim also expressed a similar wish. To be clear, I wished it had been done as a separate followup, but reviewed it here all the same, in the interest of limiting review and testing churn. If you back it out, that will be more churn that I don't think is particularly beneficial. I'll go along with whatever @magicus and @shipilev and @tstuefe decide to do about it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462963330 From pchilanomate at openjdk.org Thu Nov 7 19:15:50 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 19:15:50 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v3] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits: - Use get_method_name + copyright revert in jvmtiThreadState.cpp - Merge branch 'master' into JDK-8338383 - Add @requires vm.continuations to CancelTimerWithContention.java - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount - Use is_top_frame boolean in FreezeBase::check_valid_fast_path() - Move load of _lock_id in C2_MacroAssembler::fast_lock - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java - Update comment for _cont_fastpath - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() - ... and 74 more: https://git.openjdk.org/jdk/compare/d3c042f9...62b16c6a ------------- Changes: https://git.openjdk.org/jdk/pull/21565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02 Stats: 9939 lines in 247 files changed: 7131 ins; 1629 del; 1179 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Thu Nov 7 19:20:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 19:20:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v2] In-Reply-To: References: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com> Message-ID: On Thu, 7 Nov 2024 18:32:14 GMT, Serguei Spitsyn wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > > src/hotspot/share/prims/jvmtiThreadState.cpp line 2: > >> 1: /* >> 2: * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved. > > Nit: No need in the copyright update anymore. Fixed. > test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp line 104: > >> 102: >> 103: err = jvmti->GetMethodName(frameInfo[idx].method, &methodName, nullptr, nullptr); >> 104: check_jvmti_status(jni, err, "event handler: error in JVMTI GetMethodName call"); > > Nit: There is the test library function `get_method_name()` in `jvmti_common.hpp` that can be used here. > Also, the `methodName` is better to deallocate with the `deallocate() function. > The same is in the `VirtualThreadMount` callback. Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833226416 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833225816 From pchilanomate at openjdk.org Thu Nov 7 19:24:07 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 7 Nov 2024 19:24:07 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v3] In-Reply-To: <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com> References: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com> <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com> Message-ID: On Thu, 7 Nov 2024 09:45:40 GMT, Amit Kumar wrote: > > I think we can add @requires vm.continuations to this test. It's not useful to run with the alternative virtual thread implementation. > > Sure, that sounds ok. Thanks. > Added `@requires vm.continuations` to the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2463035166 From duke at openjdk.org Thu Nov 7 19:24:44 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Thu, 7 Nov 2024 19:24:44 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v3] In-Reply-To: References: Message-ID: On Wed, 30 Oct 2024 17:20:49 GMT, Larry Cable wrote: >> the implementation I originally provided does not in fact solve the issue! >> >> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). >> >> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach >> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. >> >> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). >> >> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. >> >> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". >> >> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". >> >> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). >> >> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. >> >> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. >> >> therefore an "attacher" has two choices when attempting to attach: >> >> - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) >> - this works with both peers and descendants >> >> - use /tmp >> - this only works if the "attacher" and "attachee" share a /tmp in common >> >> the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. >> >> I... > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8342449: fixed missing param in throws msg and renamed local var Good thinking @larry-cable! There's so many cases to keep in mind here.. I successfully ran this through the following tests locally (after merging in `master`, note the problem list variable for `TestJcmdWithSideCar`): $ make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="RUN_PROBLEM_LISTS=true; JAVA_OPTIONS=-Djdk.test.container.command=docker" $ make test TEST="jtreg:test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java" JTREG="RUN_PROBLEM_LISTS=true; JAVA_OPTIONS=-Djdk.test.container.command=podman" $ make test TEST="jtreg:test/hotspot/jtreg/serviceability" In addition to that, I verified that the "attach to systemd unit with elevated privileges" (more details in e.g. https://github.com/openjdk/jdk/pull/19055#issuecomment-2090136676) works with a JDK built from this change as the attacher. ------------- Marked as reviewed by slovdahl at github.com (no known OpenJDK username). PR Review: https://git.openjdk.org/jdk/pull/21688#pullrequestreview-2421924678 From duke at openjdk.org Thu Nov 7 19:28:55 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Thu, 7 Nov 2024 19:28:55 GMT Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes needlessly long to run [v3] In-Reply-To: References: Message-ID: On Wed, 9 Oct 2024 19:45:24 GMT, Kevin Walls wrote: >> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: >> >> Have EventGeneratorLoop end after a more predictable duration > > Yes OEL was Oracle Linux: > > Our CI tests with docker run on Oracle Linux 7, and they fail with elevated-true (i.e. with "--cap-add=NET_BIND_SERVICE"). > > Our CI runs with Oracle Linux 8 use podman and they are OK using "--cap-add=NET_BIND_SERVICE" @kevinjwalls WDYT, should we get this in so anyone running/investigating the root cause get to benefit from the speedup? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2463044033 From rkennke at openjdk.org Thu Nov 7 21:27:09 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 7 Nov 2024 21:27:09 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: <2xoAD2r5G_6IHT9gt8-uSkN_hPiRmIkJ6VhkB1GarfI=.4e3c65db-3aab-4926-b1fc-fc78599b2885@github.com> On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b GHA failures look like one unrelated timeout and one unrelated infra problem. Please confirm. I also run tier1 on x86_64 x aarch64 x -UCOH x + UCOH, with nothing sticking out (same timeout observed, though). ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2463245179 From kbarrett at openjdk.org Thu Nov 7 21:56:34 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 7 Nov 2024 21:56:34 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 18:31:51 GMT, Kim Barrett wrote: > The grep results are exactly as expected. Thanks for checking that. Now if we can just get the build to start checking for us, we can stop needing these periodic cleanups. I forget whether a JBS issue has been filed for that. If not, I will do so. II've filed these followup issues: https://bugs.openjdk.org/browse/JDK-8343802 Prevent NULL usage backsliding https://bugs.openjdk.org/browse/JDK-8343800 Cleanup definition of NULL_WORD https://bugs.openjdk.org/browse/JDK-8343801 Change string printed by nsk_null_string for null strings ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2463290137 From schernyshev at openjdk.org Thu Nov 7 22:31:21 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Thu, 7 Nov 2024 22:31:21 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into JDK-8343191 - patch reimplemented - fix the logic that skips duplicate controller's mount points - 8343191: Cgroup v1 subsystem fails to set subsystem path ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/6a761ca2..3bb779af Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=01-02 Stats: 137767 lines in 847 files changed: 107448 ins; 10821 del; 19498 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From dholmes at openjdk.org Fri Nov 8 01:55:51 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Nov 2024 01:55:51 GMT Subject: RFR: 8272780: ServerNotifForwarder.removeNotificationListener() incorrect exception handling In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 12:23:26 GMT, Kevin Walls wrote: > Long-standing nit where an Exception could fail to be reported. > One-character fix to a comparison. > Does not cause any different results in any javax/management tests. LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21950#pullrequestreview-2422530936 From dholmes at openjdk.org Fri Nov 8 02:16:02 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Nov 2024 02:16:02 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463619091 From amenkov at openjdk.org Fri Nov 8 02:38:17 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 8 Nov 2024 02:38:17 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Fri, 8 Nov 2024 02:13:09 GMT, David Holmes wrote: > Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: > > https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 > > I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. In the page you mentioned: Format of a C decorated name The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. It's also the decoration format that's used when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. **In a 64-bit environment, C or extern "C" functions are only decorated when using the __vectorcall calling convention**. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463636430 From sspitsyn at openjdk.org Fri Nov 8 03:05:13 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 8 Nov 2024 03:05:13 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v3] In-Reply-To: References: Message-ID: <-R7NADC_veb_n80hbfTME54iuMOvSj38dfBrT0KJQOw=.9345dfb0-58bd-4485-b92a-8c79b9114d25@github.com> On Thu, 7 Nov 2024 19:15:50 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits: > > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - Use is_top_frame boolean in FreezeBase::check_valid_fast_path() > - Move load of _lock_id in C2_MacroAssembler::fast_lock > - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java > - Update comment for _cont_fastpath > - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt > - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from() > - ... and 74 more: https://git.openjdk.org/jdk/compare/d3c042f9...62b16c6a Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2422590696 From iklam at openjdk.org Fri Nov 8 03:31:51 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 8 Nov 2024 03:31:51 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v9] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits: - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - reverted changes in modules.cpp to make it easy to merge with mainline - Fixed whitespace; fixed minimal build - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity" - fixed comments - ... and 165 more: https://git.openjdk.org/jdk/compare/f621f26c...7b06b7c7 ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=08 Stats: 7184 lines in 107 files changed: 6349 ins; 513 del; 322 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From jwaters at openjdk.org Fri Nov 8 05:34:19 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 8 Nov 2024 05:34:19 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com> On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov wrote: > Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: > > https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 > > I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. https://godbolt.org/z/xve7cbG1e ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463794511 From dholmes at openjdk.org Fri Nov 8 05:34:19 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Nov 2024 05:34:19 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov wrote: > In the page you mentioned: @alexmenkov that is for C functions, not C++. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463796536 From dholmes at openjdk.org Fri Nov 8 05:46:58 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Nov 2024 05:46:58 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com> Message-ID: On Fri, 8 Nov 2024 05:26:37 GMT, Julian Waters wrote: >>> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: >>> >>> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 >>> >>> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. >> >> In the page you mentioned: >> >> Format of a C decorated name >> The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. It's also the decoration format that's used when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. **In a 64-bit environment, C or extern "C" functions are only decorated when using the __vectorcall calling convention**. > >> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored: >> >> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170 >> >> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow. > > Not __stdcall: https://godbolt.org/z/nvjTP5WPc > __stdcall: https://godbolt.org/z/1KejW44vY Thanks @TheShermanTanker . I see the arguments do affect the encoding but the `__stdcall` makes no difference. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463816359 From dholmes at openjdk.org Fri Nov 8 05:51:28 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 8 Nov 2024 05:51:28 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <1D5bn5rgr4DaceNVvTisKsP3eAm-2R4D9DcZJ6gp1bk=.6add3137-d50a-488d-89e8-dd503d524e5c@github.com> On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME Clearing my "changes requested" status ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2422752388 From stuefe at openjdk.org Fri Nov 8 07:02:51 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 8 Nov 2024 07:02:51 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Merge looks good. build errors on MacOS unrelated. ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2422830379 From kevinw at openjdk.org Fri Nov 8 09:08:44 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 8 Nov 2024 09:08:44 GMT Subject: RFR: 8272780: ServerNotifForwarder.removeNotificationListener() incorrect exception handling In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 12:23:26 GMT, Kevin Walls wrote: > Long-standing nit where an Exception could fail to be reported. > One-character fix to a comparison. > Does not cause any different results in any javax/management tests. Thanks David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21950#issuecomment-2464176948 From kevinw at openjdk.org Fri Nov 8 09:08:45 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 8 Nov 2024 09:08:45 GMT Subject: Integrated: 8272780: ServerNotifForwarder.removeNotificationListener() incorrect exception handling In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 12:23:26 GMT, Kevin Walls wrote: > Long-standing nit where an Exception could fail to be reported. > One-character fix to a comparison. > Does not cause any different results in any javax/management tests. This pull request has now been integrated. Changeset: bf5c3ce2 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/bf5c3ce2808c65329ff0ea5ef37b980c3b3029df Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8272780: ServerNotifForwarder.removeNotificationListener() incorrect exception handling Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/21950 From ihse at openjdk.org Fri Nov 8 09:35:26 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 8 Nov 2024 09:35:26 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. @shipilev Could you consider accepting the existing `__stdcall` changes in this PR? That seems like the easiest way out of satisfying everyones opinions here.. As I said, I think they are just as safe as any other changes -- the only difference is that it is perhaps not as well-known in the community that they only affect x86. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464232813 From amenkov at openjdk.org Fri Nov 8 09:41:54 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 8 Nov 2024 09:41:54 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Fri, 8 Nov 2024 05:29:05 GMT, David Holmes wrote: > > In the page you mentioned: > > @alexmenkov that is for C functions, not C++. And also for `extern "C"` (AFAIU we export all C++ functions as extern "C") ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464243142 From jwaters at openjdk.org Fri Nov 8 09:44:22 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 8 Nov 2024 09:44:22 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v4] In-Reply-To: References: Message-ID: <9T3uwY8Yh-aRhSC-jxbbJDpYXUh4RAQH_U_wsmMpc7c=.a3e21c96-1606-46a8-a392-b22e15f3325d@github.com> On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove global memHandle, would've liked to keep it as a comment :( Bumping, awaiting jpackage review ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2464249727 From duke at openjdk.org Fri Nov 8 10:09:23 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 10:09:23 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v2] In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 14:56:10 GMT, Johan Sj?len wrote: >> theoweidmannoracle has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8342860 >> - Fix copyright year >> - 8342860: Fix more NULL usage backsliding > > Thank you, these changes looks good to me. @jdksjolen @TheShermanTanker It would be great if you could also take another look at the latest changes I made. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2464298298 From shade at openjdk.org Fri Nov 8 10:09:26 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Nov 2024 10:09:26 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com> Message-ID: On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove FIXME > > I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO. > @shipilev Could you consider accepting the existing `__stdcall` changes in this PR? That seems like the easiest way out of satisfying everyones opinions here.. Sure, fine. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464299781 From shade at openjdk.org Fri Nov 8 10:17:19 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 8 Nov 2024 10:17:19 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v31] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Remove FIXME Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2423300933 From sgehwolf at openjdk.org Fri Nov 8 10:26:30 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 8 Nov 2024 10:26:30 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into JDK-8343191 > - patch reimplemented > - fix the logic that skips duplicate controller's mount points > - 8343191: Cgroup v1 subsystem fails to set subsystem path Have you checked on cg v2? Is this a problem there as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2464339096 From jwaters at openjdk.org Fri Nov 8 10:30:21 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 8 Nov 2024 10:30:21 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 08:32:16 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix backslides in test Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2423332121 From ihse at openjdk.org Fri Nov 8 11:24:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 8 Nov 2024 11:24:52 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v32] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge branch 'master' into impl-JEP-479 - Remove FIXME - fix: jvm_md.h was included, but not jvm.h... - Update copyright years - Merge branch 'master' into impl-JEP-479 - JVM_EnqueueOperation do not need __stdcall name lookup anymore - [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them - Fix build_agent_function_name to not handle "@"-stdcall style names - buildJniFunctionName is now identical on Windows and Unix, so unify it - Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer - ... and 27 more: https://git.openjdk.org/jdk/compare/0c281acf...a9d56f2f ------------- Changes: https://git.openjdk.org/jdk/pull/21744/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=31 Stats: 1925 lines in 85 files changed: 86 ins; 1572 del; 267 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Fri Nov 8 11:31:40 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 8 Nov 2024 11:31:40 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Inline buildJniFunctionName ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21744/files - new: https://git.openjdk.org/jdk/pull/21744/files/a9d56f2f..445515e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=31-32 Stats: 14 lines in 1 file changed: 4 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21744.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744 PR: https://git.openjdk.org/jdk/pull/21744 From ihse at openjdk.org Fri Nov 8 11:31:41 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 8 Nov 2024 11:31:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v30] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com> Message-ID: <9-Gr4GhhtLOPX6w1PMSIcvx25_d9-MchNZtIId2mZLg=.79e4368a-412d-42c6-8db7-7288b50cb63e@github.com> On Wed, 6 Nov 2024 21:24:14 GMT, Kim Barrett wrote: >> @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already. > > The first part, eliminating the (IMO not actually helpful) helper function, I wanted done here. The second part, > cleaning up or commenting the calculation of the length and dealing with perhaps unneeded conditionals, I'm > okay with being in a followup. I guess I can live with the first part being in that followup too. Ok, fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834182702 From tschatzl at openjdk.org Fri Nov 8 12:46:29 2024 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Fri, 8 Nov 2024 12:46:29 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 08:32:16 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix backslides in test Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21826#pullrequestreview-2423710194 From duke at openjdk.org Fri Nov 8 12:57:30 2024 From: duke at openjdk.org (duke) Date: Fri, 8 Nov 2024 12:57:30 GMT Subject: RFR: 8342860: Fix more NULL usage backsliding [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 08:32:16 GMT, theoweidmannoracle wrote: >> - Changed several "NULL" in comments to "null" >> - Changed several `NULL` in code to `nullptr` > > theoweidmannoracle has updated the pull request incrementally with one additional commit since the last revision: > > Fix backslides in test @theoweidmannoracle Your change (at version e79b7bdeaf9bdd13e04814f51858e257ed0f1aa9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21826#issuecomment-2464687406 From asemenyuk at openjdk.org Fri Nov 8 13:14:46 2024 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 8 Nov 2024 13:14:46 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v4] In-Reply-To: References: Message-ID: On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove global memHandle, would've liked to keep it as a comment :( Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/windows/native/libjpackage/VersionInfo.cpp line 183: > 181: add32bitPadding(buf); // Padding2 > 182: > 183: // const DWORD neutralLangId = (0x04b0 | MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL) << 16); As ` neutralLangId` is unused, remove it instead of commenting it out. ------------- PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2423768191 PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1834382152 From duke at openjdk.org Fri Nov 8 13:36:34 2024 From: duke at openjdk.org (theoweidmannoracle) Date: Fri, 8 Nov 2024 13:36:34 GMT Subject: Integrated: 8342860: Fix more NULL usage backsliding In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 13:35:56 GMT, theoweidmannoracle wrote: > - Changed several "NULL" in comments to "null" > - Changed several `NULL` in code to `nullptr` This pull request has now been integrated. Changeset: 7d6a2f37 Author: theoweidmannoracle URL: https://git.openjdk.org/jdk/commit/7d6a2f3740bf42652bdf05bb922d1f2b2ae60d6a Stats: 32 lines in 13 files changed: 0 ins; 0 del; 32 mod 8342860: Fix more NULL usage backsliding Reviewed-by: kbarrett, jwaters, tschatzl, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/21826 From jwaters at openjdk.org Fri Nov 8 13:39:08 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 8 Nov 2024 13:39:08 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v5] In-Reply-To: References: Message-ID: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Remove neutralLangId in VersionInfo.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21616/files - new: https://git.openjdk.org/jdk/pull/21616/files/4d15fe78..68767cbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616 PR: https://git.openjdk.org/jdk/pull/21616 From jwaters at openjdk.org Fri Nov 8 13:39:09 2024 From: jwaters at openjdk.org (Julian Waters) Date: Fri, 8 Nov 2024 13:39:09 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v4] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:10:48 GMT, Alexey Semenyuk wrote: >> Julian Waters has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove global memHandle, would've liked to keep it as a comment :( > > src/jdk.jpackage/windows/native/libjpackage/VersionInfo.cpp line 183: > >> 181: add32bitPadding(buf); // Padding2 >> 182: >> 183: // const DWORD neutralLangId = (0x04b0 | MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL) << 16); > > As ` neutralLangId` is unused, remove it instead of commenting it out. Will do ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1834413246 From pchilanomate at openjdk.org Fri Nov 8 13:48:00 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 8 Nov 2024 13:48:00 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v4] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: - Fix in JvmtiEnvBase::get_locked_objects_in_frame() - Add ObjectWaiter::at_monitorenter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21565/files - new: https://git.openjdk.org/jdk/pull/21565/files/62b16c6a..3cdb8f86 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02-03 Stats: 44 lines in 5 files changed: 36 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Fri Nov 8 13:48:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 8 Nov 2024 13:48:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v4] In-Reply-To: References: Message-ID: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com> On Wed, 30 Oct 2024 17:23:31 GMT, Coleen Phillimore wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix in JvmtiEnvBase::get_locked_objects_in_frame() >> - Add ObjectWaiter::at_monitorenter > > src/hotspot/share/oops/stackChunkOop.inline.hpp line 189: > >> 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const { >> 188: ObjectWaiter* waiter = object_waiter(); >> 189: if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) { > > Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; } > > Not sure what this is excluding. I added method `at_monitorenter()` to ObjectWaiter. We are checking if the vthread is blocked trying to acquire (or re-acquire for the wait case) the monitor. While looking at these I also noticed we were missing a call to `current_waiting_monitor` in `JvmtiEnvBase::get_locked_objects_in_frame()` so I added it. We didn?t had a case for this so it went unnoticed. I extended JVMTI test `VThreadMonitorTest.java` to cover this case. > src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1657: > >> 1655: } >> 1656: >> 1657: template > > This function is kind of big, do we really want it duplicated to pass preempt as a template parameter? I checked and release build is same size and fast/slow debug difference is only about 16kb. Since it doesn?t hurt I would rather not touch the fast paths, but I see `ConfigT` has been unused for some time now so I can do a follow up cleanup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834427410 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834425311 From mullan at openjdk.org Fri Nov 8 13:49:55 2024 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 8 Nov 2024 13:49:55 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 224 commits: - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Move remaining JEP 486 failing tests into correct groups. - Move JEP 486 failing tests into hotspot_runtime group. - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=08 Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 del; 3843 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From pchilanomate at openjdk.org Fri Nov 8 13:48:03 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 8 Nov 2024 13:48:03 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v4] In-Reply-To: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com> References: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com> Message-ID: <4wpTgmx1V3RtcHOC0q-19yKgMwSg4og_30EdNvz6oA0=.d8be3ea5-7a30-4ec9-89cb-a013318189f2@github.com> On Fri, 8 Nov 2024 13:43:14 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/oops/stackChunkOop.inline.hpp line 189: >> >>> 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const { >>> 188: ObjectWaiter* waiter = object_waiter(); >>> 189: if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) { >> >> Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; } >> >> Not sure what this is excluding. > > I added method `at_monitorenter()` to ObjectWaiter. We are checking if the vthread is blocked trying to acquire (or re-acquire for the wait case) the monitor. While looking at these I also noticed we were missing a call to `current_waiting_monitor` in `JvmtiEnvBase::get_locked_objects_in_frame()` so I added it. We didn?t had a case for this so it went unnoticed. I extended JVMTI test `VThreadMonitorTest.java` to cover this case. Thanks for pointing at this code because I also realized there is a nice cleanup that can be done here. First these methods should be moved to `java_lang_VirtualThread` class where they naturally belong (these are the equivalent of the JavaThread methods but for an unmounted vthread). Also the `objectWaiter` field can be added to the VirtualThread class rather than the stackChunk, which not?only is more appropriate too and gives us the get/set symmetry for these methods, but we can also save memory since one virtual thread can have many stackChunks around. I have a patch for that but I?ll do it after this PR to avoid new changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834429835 From asemenyuk at openjdk.org Fri Nov 8 13:59:45 2024 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 8 Nov 2024 13:59:45 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v5] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:39:08 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove neutralLangId in VersionInfo.cpp Marked as reviewed by asemenyuk (Reviewer). jpackage changes look good. Thank you! ------------- PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2423878603 PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2464832211 From nbenalla at openjdk.org Fri Nov 8 15:34:30 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 8 Nov 2024 15:34:30 GMT Subject: RFR: 8343781: Add since checker test to the Serviceability area modules Message-ID: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Serviceability area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. TIA ------------- Commit messages: - remove backticks - 8343781 Add since checker test to the Serviceability area modules Changes: https://git.openjdk.org/jdk/pull/21983/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21983&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343781 Stats: 36 lines in 12 files changed: 0 ins; 0 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/21983.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21983/head:pull/21983 PR: https://git.openjdk.org/jdk/pull/21983 From alanb at openjdk.org Fri Nov 8 15:43:22 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 8 Nov 2024 15:43:22 GMT Subject: RFR: 8343781: Add since checker test to the Serviceability area modules In-Reply-To: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> References: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Message-ID: On Fri, 8 Nov 2024 15:20:00 GMT, Nizar Benalla wrote: > Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Serviceability area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. > > The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. > > The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. > > TIA test/jdk/tools/sincechecker/modules/jdk.jdwp.agent/JdkJdwpAgentCheckSince.java line 29: > 27: * @summary Test for @since in jdk.jdwp.agent module > 28: * @library /test/lib /test/jdk/tools/sincechecker > 29: * @run main SinceChecker jdk.jdwp.agent Just to say that there aren't any class files in jdk.jdwp but it does have a module-info.class, does the `@since` checker look at module-info too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21983#discussion_r1834601770 From stuefe at openjdk.org Fri Nov 8 16:10:56 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 8 Nov 2024 16:10:56 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Marked as reviewed by stuefe (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2424199289 From schernyshev at openjdk.org Fri Nov 8 16:13:42 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 8 Nov 2024 16:13:42 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into JDK-8343191 > - patch reimplemented > - fix the logic that skips duplicate controller's mount points > - 8343191: Cgroup v1 subsystem fails to set subsystem path Hi Severin, thanks for this question. I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only. I believe it's because v2 uses --cgroupns=private by default, in which cgroup is mounted at hierarchy leaf, so both `_root` and `cgroup_path` are `/`. It's an open question what happens if a process is moved between cgroups in v2 mode. I will look into it and file an issue if there are problems in v2. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2465146149 From phh at openjdk.org Fri Nov 8 16:15:14 2024 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 8 Nov 2024 16:15:14 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2424210008 From stefank at openjdk.org Fri Nov 8 16:26:28 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 8 Nov 2024 16:26:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Marked as reviewed by stefank (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2424260100 From coleenp at openjdk.org Fri Nov 8 16:26:28 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 8 Nov 2024 16:26:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Still looks good. Nice work! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/20677#pullrequestreview-2424274474 From nbenalla at openjdk.org Fri Nov 8 16:33:35 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 8 Nov 2024 16:33:35 GMT Subject: RFR: 8343781: Add since checker test to the Serviceability area modules In-Reply-To: References: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Message-ID: On Fri, 8 Nov 2024 15:40:28 GMT, Alan Bateman wrote: >> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Serviceability area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. >> >> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. >> >> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. >> >> TIA > > test/jdk/tools/sincechecker/modules/jdk.jdwp.agent/JdkJdwpAgentCheckSince.java line 29: > >> 27: * @summary Test for @since in jdk.jdwp.agent module >> 28: * @library /test/lib /test/jdk/tools/sincechecker >> 29: * @run main SinceChecker jdk.jdwp.agent > > Just to say that there aren't any class files in jdk.jdwp but it does have a module-info.class, does the `@since` checker look at module-info too? Yes it does check the `@since` in the module-info file. I will double check that it verifies it for `jdk.jdwp` as there are no classfiles, or if it exists immediately. It is a goal to automate testing all `@since` tags in all modules. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21983#discussion_r1834691970 From rkennke at openjdk.org Fri Nov 8 17:24:05 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 8 Nov 2024 17:24:05 GMT Subject: Integrated: 8305895: Implement JEP 450: Compact Object Headers (Experimental) In-Reply-To: References: Message-ID: On Thu, 22 Aug 2024 13:35:08 GMT, Roman Kennke wrote: > This is the main body of the JEP 450: Compact Object Headers (Experimental). > > It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. > > Main changes: > - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. > - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. > - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). > - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). > - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). > - Arrays will now store their length at offset 8. > - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _coh variants of CDS archiv... This pull request has now been integrated. Changeset: 44ec501a Author: Roman Kennke URL: https://git.openjdk.org/jdk/commit/44ec501a41f4794259dd03cd168838e79334890e Stats: 5212 lines in 218 files changed: 3585 ins; 864 del; 763 mod 8305895: Implement JEP 450: Compact Object Headers (Experimental) Co-authored-by: Sandhya Viswanathan Co-authored-by: Martin Doerr Co-authored-by: Hamlin Li Co-authored-by: Thomas Stuefe Co-authored-by: Amit Kumar Co-authored-by: Stefan Karlsson Co-authored-by: Coleen Phillimore Co-authored-by: Axel Boldt-Christmas Reviewed-by: coleenp, stefank, stuefe, phh, ihse, lmesnik, tschatzl, matsaave, rcastanedalo, vpaprotski, yzheng, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/20677 From rkennke at openjdk.org Fri Nov 8 17:45:40 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 8 Nov 2024 17:45:40 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Wed, 18 Sep 2024 12:22:34 GMT, Yudi Zheng wrote: >> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision: >> >> - CompressedKlassPointers::is_encodable shall be callable with -UseCCP >> - Johan review feedback > > Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2465413222 From yzheng at openjdk.org Fri Nov 8 17:52:05 2024 From: yzheng at openjdk.org (Yudi Zheng) Date: Fri, 8 Nov 2024 17:52:05 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote: >> Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? > > @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) @rkennke It is in the merge queue ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2465423342 From duke at openjdk.org Fri Nov 8 17:54:17 2024 From: duke at openjdk.org (Saint Wesonga) Date: Fri, 8 Nov 2024 17:54:17 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v13] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Wed, 30 Oct 2024 11:05:17 GMT, Magnus Ihse Bursie wrote: >> make/scripts/compare.sh line 1457: >> >>> 1455: THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip" >>> 1456: if [ "$OPENJDK_TARGET_OS" = "windows" ]; then >>> 1457: JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip" >> >> This is now being defined for windows-aarch64 too, when it previously wasn't. That seems wrong, >> given the "x64" suffix. > > Well... this was broken on windows-aarch64 before, too, since then it would have looked for `jgss-windows-i586-bin.zip`. > > I'm going to leave this as it is. Obviously there is a lot more work needed to get the compare script running on windows-aarch64, and I seriously doubt anyone care about that platform enough to spend that time (Microsoft themselves seems to have all but abandoned the windows-aarch64 port...). @magicus @kimbarrett @shipilev Thanks for catching this. We want to get this working on Windows AArch64. I have filed https://bugs.openjdk.org/browse/JDK-8343857. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834839335 From aivanov at openjdk.org Fri Nov 8 18:18:07 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 8 Nov 2024 18:18:07 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: On Tue, 29 Oct 2024 17:06:08 GMT, Harshitha Onkar wrote: >> src/java.desktop/share/classes/java/awt/MouseInfo.java line 68: >> >>> 66: * @throws SecurityException if a security manager exists and its >>> 67: * {@code checkPermission} method doesn't allow the operation >>> 68: * @see GraphicsConfiguration >> >> Is `GraphicsConfiguration` removed from the list because it's already mentioned and linked in the description above? Is it intentional? > >> Is it intentional? > > It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again? It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()). Without the `@see` tag, one has to read the entire description to find the link. It looks subtle. We can restore the `@see`-link later if deemed necessary. Does anyone else have an opinion? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826266398 From duke at openjdk.org Fri Nov 8 18:29:37 2024 From: duke at openjdk.org (Saint Wesonga) Date: Fri, 8 Nov 2024 18:29:37 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName src/hotspot/os/posix/include/jvm_md.h line 41: > 39: > 40: #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > 41: #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} are these changes related to the Windows 32-bit x86 port? src/hotspot/os/posix/os_posix.cpp line 699: > 697: } > 698: > 699: void os::print_jni_name_prefix_on(outputStream* st, int args_size) { are these changes related to the Windows 32-bit x86 port? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834878288 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834878195 From honkar at openjdk.org Fri Nov 8 18:36:29 2024 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 8 Nov 2024 18:36:29 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 20:26:45 GMT, Alexey Ivanov wrote: >>> Is it intentional? >> >> It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again? > > It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()). > > Without the `@see` tag, one has to read the entire description to find the link. > > It looks subtle. We can restore the `@see`-link later if deemed necessary. > > Does anyone else have an opinion? I can add it back if it is more convenient and readable to have the `@see` tag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1834883137 From kbarrett at openjdk.org Fri Nov 8 18:53:35 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Nov 2024 18:53:35 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: <8YGMIrEQv6aPy_9IXzP9VqZ6tB0CTSwnH1XkfkDlXzM=.c1dd03d4-6d33-4dc8-a8b1-691a0616a6a5@github.com> On Fri, 8 Nov 2024 18:26:25 GMT, Saint Wesonga wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Inline buildJniFunctionName > > src/hotspot/os/posix/include/jvm_md.h line 41: > >> 39: >> 40: #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> 41: #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > > are these changes related to the Windows 32-bit x86 port? After removal of Windows 32-bit x86 port, all definitions of these macros are identical, so are merged into jvm.h. There is additional followup work involving these: see https://bugs.openjdk.org/browse/JDK-8343703. > src/hotspot/os/posix/os_posix.cpp line 699: > >> 697: } >> 698: >> 699: void os::print_jni_name_prefix_on(outputStream* st, int args_size) { > > are these changes related to the Windows 32-bit x86 port? As part of removal of Windows 32-bit x86 port, these functions are no longer needed nor called, and all definitions removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834900456 PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834900337 From kbarrett at openjdk.org Fri Nov 8 18:53:34 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Fri, 8 Nov 2024 18:53:34 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName Still looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424652542 From acobbs at openjdk.org Fri Nov 8 19:07:34 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Fri, 8 Nov 2024 19:07:34 GMT Subject: RFR: 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) [v3] In-Reply-To: References: Message-ID: <_4If4-yI_2rJlVYS-46qWRN0jioXUaTQss5kwiKOZKA=.81964925-b455-49a3-b226-29a3c5052b35@github.com> > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'master' into SuppressWarningsCleanup-serviceability - Update copyright years. - Merge branch 'master' into SuppressWarningsCleanup-serviceability - Merge branch 'master' into SuppressWarningsCleanup-serviceability - Remove unnecessary @SuppressWarnings annotations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21857/files - new: https://git.openjdk.org/jdk/pull/21857/files/a8e438be..d41ae604 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21857&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21857&range=01-02 Stats: 131587 lines in 749 files changed: 103986 ins; 9680 del; 17921 mod Patch: https://git.openjdk.org/jdk/pull/21857.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21857/head:pull/21857 PR: https://git.openjdk.org/jdk/pull/21857 From kvn at openjdk.org Fri Nov 8 19:11:41 2024 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 8 Nov 2024 19:11:41 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName Re-approve. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424696022 From duke at openjdk.org Fri Nov 8 20:12:19 2024 From: duke at openjdk.org (Saint Wesonga) Date: Fri, 8 Nov 2024 20:12:19 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName Marked as reviewed by swesonga at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424836232 From almatvee at openjdk.org Fri Nov 8 20:37:21 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 8 Nov 2024 20:37:21 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v5] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:39:08 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Remove neutralLangId in VersionInfo.cpp src/jdk.jpackage/windows/native/libjpackage/VersionInfo.cpp line 1: > 1: /* Copyright year needs to be updated. "2020," -> "2020, 2024,". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1835031208 From iklam at openjdk.org Fri Nov 8 21:02:16 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 8 Nov 2024 21:02:16 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v10] In-Reply-To: References: Message-ID: <4wG_Fbrs_mcjApZOJqSgVNa5RUMflOwm9G3W4a4OzWQ=.6203c74f-0eaf-47dd-8121-a9e845153265@github.com> > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 177 commits: - fixed merge with UseCompactObjectHeaders - Merge branch 'master' into jep-483-candidate - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - reverted changes in modules.cpp to make it easy to merge with mainline - Fixed whitespace; fixed minimal build - ... and 167 more: https://git.openjdk.org/jdk/compare/44ec501a...ce4c93ee ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=09 Stats: 7193 lines in 107 files changed: 6358 ins; 513 del; 322 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From prr at openjdk.org Fri Nov 8 21:05:41 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Nov 2024 21:05:41 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:49:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 224 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2424915104 From prr at openjdk.org Fri Nov 8 21:05:42 2024 From: prr at openjdk.org (Phil Race) Date: Fri, 8 Nov 2024 21:05:42 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 18:06:47 GMT, Alexey Ivanov wrote: > > I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test. > > @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? > > The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`: > > https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198 I think I was just saying there appeared to be dead code in the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1835053637 From schernyshev at openjdk.org Fri Nov 8 21:20:46 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 8 Nov 2024 21:20:46 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: <-iPx4Rv3BEWIqj4KUMiPE4DI8CcRvEqy6jzZ3EMJCEY=.d8223257-466f-4a8b-aa9b-73cbcf6bd364@github.com> On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into JDK-8343191 > - patch reimplemented > - fix the logic that skips duplicate controller's mount points > - 8343191: Cgroup v1 subsystem fails to set subsystem path It looks to me that v2 mode is not affected, at least the way it is in v1. In v2 mode, cgroup is mounted either at leaf node (private namespace), or the complete hierarchy at /sys/fs/cgroup (host namespace). In host mode it works right away, as the full hierarchy is accessible. With a cgroup v2 created like this: sudo mkdir -p /sys/fs/cgroup/test echo 200000000 | sudo tee /sys/fs/cgroup/test/memory.max ``` The result would be [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups [0.001s][debug][os,container] Detected cgroups v2 unified hierarchy [0.001s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/test [0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/test/memory.max [0.001s][trace][os,container] Memory Limit is: 199999488 In the private namespace (it's a default setting in v2 hosts), it may fail migrating the process between cgroups (a docker issue?). It may look like the cgroup files are not mapped at all, while `cgroup_path` appears to be set relative to the old cgroup (the old cgroup isn't mapped though). [0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups [0.001s][debug][os,container] Detected cgroups v2 unified hierarchy [0.001s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/../../test [0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../../test/memory.max [0.001s][debug][os,container] Open of file /sys/fs/cgroup/../../test/memory.max failed, No such file or directory [0.001s][trace][os,container] Memory Limit failed: -2 [0.001s][trace][os,container] Memory Limit is: -2 [0.001s][debug][os,container] container memory limit failed: -2, using host value 4105613312 [0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../../memory.max [0.001s][debug][os,container] Open of file /sys/fs/cgroup/../../memory.max failed, No such file or directory [0.001s][trace][os,container] Memory Limit failed: -2 [0.001s][trace][os,container] Memory Limit is: -2 [0.001s][debug][os,container] container memory limit failed: -2, using host value 4105613312 [0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../memory.max [0.001s][debug][os,container] Open of file /sys/fs/cgroup/../memory.max failed, No such file or directory [0.001s][trace][os,container] Memory Limit failed: -2 [0.001s][trace][os,container] Memory Limit is: -2 [0.001s][debug][os,container] container memory limit failed: -2, using host value 4105613312 [0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/memory.max [0.001s][debug][os,container] Open of file /sys/fs/cgroup/memory.max failed, No such file or directory [0.001s][trace][os,container] Memory Limit failed: -2 The following script docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m ubuntu:latest \ sh -c "N=$(ls -la /sys/fs/cgroup | wc -l) ; sleep 10 ; echo $N ; ls -la /sys/fs/cgroup | wc -l" & sleep 10 HOSTPID=$(sudo ps -ef | awk '/cgroup/ && !/docker/ && !/awk/ && !/grep/ { print $2 }') echo $HOSTPID | sudo tee /sys/fs/cgroup/test/cgroup.procs > /dev/null sleep 5 will display 74 1 means there are no files in `/sys/fs/cgroup` after migration. It seems like it's not something that can be fixed in Java (and it hasn't much to do with this PR too). When moved into a subgroup, such as sudo docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m ubuntu:latest \ sh -c "sleep 10 ; /jdk/bin/java -Xlog:os+container=trace -version" & sleep 5 HOSTPID=$(sudo ps -ef | awk '/container=trace/ && !/docker/ && !/awk/ { print $2 }') CGPATH=$(cat /proc/$HOSTPID/cgroup | cut -f3 -d: ) sudo mkdir -p "/sys/fs/cgroup$CGPATH/test" echo $HOSTPID | sudo tee "/sys/fs/cgroup$CGPATH/test/cgroup.procs" > /dev/null sleep 10 the cgroup will be mounted /sys/fs/cgroup, and the correct memory limit is displayed (thanks to the conroller path adjustment) - inherited from the parent. [0.001s][debug][os,container] Detected cgroups v2 unified hierarchy [0.001s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/test [0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/test/memory.max [0.001s][debug][os,container] Open of file /sys/fs/cgroup/test/memory.max failed, No such file or directory [0.001s][trace][os,container] Memory Limit failed: -2 [0.001s][trace][os,container] Memory Limit is: -2 [0.001s][debug][os,container] container memory limit failed: -2, using host value 4105613312 [0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/memory.max [0.001s][trace][os,container] Memory Limit is: 419430400 ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2465764229 From kevinw at openjdk.org Fri Nov 8 22:47:24 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 8 Nov 2024 22:47:24 GMT Subject: RFR: 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException Message-ID: Looks like EmptyDomainNotificationTest has been working by accident for nearly 20 years. Removing notifications when not specifying a domain part of the ObjectName has actually been failing, but calling removeNotificationListener() without a domain has not been sharing the Exception. ServerNotifForwarder.removeNotificationListener DOES need to add a domain part to an ObjectName that does not have one. ServerNotifForwarder.addNotificationListener was changed in JDK-6238731, which is what this test is testing. There is a numeric ID, BUT it still calls removeNotificationListener(ObjectName name, Integer listenerID) it does matter that the ObjectName does not match. Maybe the failure to record and throw the Exceptions was the reason it was thought the numeric ID made the domain unnecessary. ------------- Commit messages: - 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException Changes: https://git.openjdk.org/jdk/pull/21993/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21993&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343838 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21993.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21993/head:pull/21993 PR: https://git.openjdk.org/jdk/pull/21993 From weijun at openjdk.org Sat Nov 9 00:57:23 2024 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 9 Nov 2024 00:57:23 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v9] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 13:49:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 224 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e Marked as reviewed by weijun (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2425106253 From jwaters at openjdk.org Sat Nov 9 04:26:55 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 9 Nov 2024 04:26:55 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v2] In-Reply-To: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com> References: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com> Message-ID: On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote: >>> I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem >> >> I'll also start looking into this in the meantime, unless you explicitly want me not to do so > >> > I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem >> >> I'll also start looking into this in the meantime, unless you explicitly want me not to do so > > Feel free to if you'd like to. Personally I don't consider it to be that important. @plummercj @alexeysemenyukoracle @sashamatveev reawaiting review ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2466039622 From jwaters at openjdk.org Sat Nov 9 04:26:55 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 9 Nov 2024 04:26:55 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v6] In-Reply-To: References: Message-ID: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did Julian Waters has updated the pull request incrementally with one additional commit since the last revision: Copyright in VersionInfo.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21616/files - new: https://git.openjdk.org/jdk/pull/21616/files/68767cbe..5e9039fb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616 PR: https://git.openjdk.org/jdk/pull/21616 From asemenyuk at openjdk.org Sat Nov 9 05:11:42 2024 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 9 Nov 2024 05:11:42 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v6] In-Reply-To: References: Message-ID: On Sat, 9 Nov 2024 04:26:55 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request incrementally with one additional commit since the last revision: > > Copyright in VersionInfo.cpp Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2425219022 From stuefe at openjdk.org Sat Nov 9 07:24:10 2024 From: stuefe at openjdk.org (Thomas Stuefe) Date: Sat, 9 Nov 2024 07:24:10 GMT Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port [v33] In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com> Message-ID: On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie wrote: >> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). >> >> This is the summary of JEP 479: >>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Inline buildJniFunctionName Still looks good to me. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2425254474 From syan at openjdk.org Sat Nov 9 09:52:31 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 9 Nov 2024 09:52:31 GMT Subject: RFR: 8336691: Test LongArgTest.java intermittent fails java.lang.NoClassDefFoundError: jdk/test/lib/Utils [v2] In-Reply-To: References: Message-ID: On Thu, 18 Jul 2024 07:30:47 GMT, SendaoYan wrote: >> Hi all, >> The testcase `serviceability/attach/LongArgTest.java` intermittent fails `java.lang.NoClassDefFoundError: jdk/test/lib/Utils`. Jtreg doesn't automatically compile `jdk/test/lib/Utils.class` and `jdk/test/lib/apps/LingeredApp.class` etc.. Maybe it's a jtreg framework bug. >> I think it's necessory to compile `jdk.test.lib.Utils` and `jdk.test.lib.apps.LingeredApp` explicitly. >> Only change the testcase, the change has been verified, no risk. > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > delete @build LongArgTest Need for investigate ------------- PR Comment: https://git.openjdk.org/jdk/pull/20228#issuecomment-2466150856 From dholmes at openjdk.org Sun Nov 10 23:13:24 2024 From: dholmes at openjdk.org (David Holmes) Date: Sun, 10 Nov 2024 23:13:24 GMT Subject: RFR: 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 20:46:52 GMT, Kevin Walls wrote: > Looks like EmptyDomainNotificationTest has been working by accident for nearly 20 years. > Removing notifications when not specifying a domain part of the ObjectName has actually been failing, but calling removeNotificationListener() without a domain has not been sharing the Exception. > > ServerNotifForwarder.removeNotificationListener DOES need to add a domain part to an ObjectName that does not have one. > > ServerNotifForwarder.addNotificationListener was changed in JDK-6238731, which is what this test is testing. > > There is a numeric ID, BUT it still calls removeNotificationListener(ObjectName name, Integer listenerID) it does matter that the ObjectName does not match. > > Maybe the failure to record and throw the Exceptions was the reason it was thought the numeric ID made the domain unnecessary. This seems reasonable. As we are approaching 400 failures of this test in the CI I'd like to see it integrated ASAP. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21993#pullrequestreview-2425883544 From dholmes at openjdk.org Mon Nov 11 01:31:16 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Nov 2024 01:31:16 GMT Subject: RFR: 8343894: ProblemList javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java Message-ID: This is causing hundreds of failures in our CI and [JDK-8343838](https://bugs.openjdk.org/browse/JDK-8343838) may not be fixed for a number of hours yet. Thanks ------------- Commit messages: - 8343894: ProblemList javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java Changes: https://git.openjdk.org/jdk/pull/22001/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22001&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343894 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22001.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22001/head:pull/22001 PR: https://git.openjdk.org/jdk/pull/22001 From jpai at openjdk.org Mon Nov 11 01:35:01 2024 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 11 Nov 2024 01:35:01 GMT Subject: RFR: 8343894: ProblemList javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 01:24:38 GMT, David Holmes wrote: > This is causing hundreds of failures in our CI and [JDK-8343838](https://bugs.openjdk.org/browse/JDK-8343838) may not be fixed for a number of hours yet. > > Thanks Looks reasonable and trivial to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22001#pullrequestreview-2425957977 From dholmes at openjdk.org Mon Nov 11 01:43:29 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Nov 2024 01:43:29 GMT Subject: RFR: 8343894: ProblemList javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 01:32:57 GMT, Jaikiran Pai wrote: >> This is causing hundreds of failures in our CI and [JDK-8343838](https://bugs.openjdk.org/browse/JDK-8343838) may not be fixed for a number of hours yet. >> >> Thanks > > Looks reasonable and trivial to me. Thanks @jaikiran ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22001#issuecomment-2467068277 From dholmes at openjdk.org Mon Nov 11 01:43:29 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Nov 2024 01:43:29 GMT Subject: Integrated: 8343894: ProblemList javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 01:24:38 GMT, David Holmes wrote: > This is causing hundreds of failures in our CI and [JDK-8343838](https://bugs.openjdk.org/browse/JDK-8343838) may not be fixed for a number of hours yet. > > Thanks This pull request has now been integrated. Changeset: 7b0f273e Author: David Holmes URL: https://git.openjdk.org/jdk/commit/7b0f273e37625461baa333a3ef20fbbd93647243 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8343894: ProblemList javax/management/remote/mandatory/notif/EmptyDomainNotificationTest.java Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/22001 From dholmes at openjdk.org Mon Nov 11 01:44:21 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Nov 2024 01:44:21 GMT Subject: RFR: 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 20:46:52 GMT, Kevin Walls wrote: > Looks like EmptyDomainNotificationTest has been working by accident for nearly 20 years. > Removing notifications when not specifying a domain part of the ObjectName has actually been failing, but calling removeNotificationListener() without a domain has not been sharing the Exception. > > ServerNotifForwarder.removeNotificationListener DOES need to add a domain part to an ObjectName that does not have one. > > ServerNotifForwarder.addNotificationListener was changed in JDK-6238731, which is what this test is testing. > > There is a numeric ID, BUT it still calls removeNotificationListener(ObjectName name, Integer listenerID) it does matter that the ObjectName does not match. > > Maybe the failure to record and throw the Exceptions was the reason it was thought the numeric ID made the domain unnecessary. I had to add the test to the ProblemList, so please remove it again. Thanks ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21993#pullrequestreview-2425962326 From kevinw at openjdk.org Mon Nov 11 09:18:34 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 11 Nov 2024 09:18:34 GMT Subject: RFR: 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException [v2] In-Reply-To: References: Message-ID: > Looks like EmptyDomainNotificationTest has been working by accident for nearly 20 years. > Removing notifications when not specifying a domain part of the ObjectName has actually been failing, but calling removeNotificationListener() without a domain has not been sharing the Exception. > > ServerNotifForwarder.removeNotificationListener DOES need to add a domain part to an ObjectName that does not have one. > > ServerNotifForwarder.addNotificationListener was changed in JDK-6238731, which is what this test is testing. > > There is a numeric ID, BUT it still calls removeNotificationListener(ObjectName name, Integer listenerID) it does matter that the ObjectName does not match. > > Maybe the failure to record and throw the Exceptions was the reason it was thought the numeric ID made the domain unnecessary. Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Update problemlist - Merge remote-tracking branch 'upstream/master' into 8343838_Notification - 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21993/files - new: https://git.openjdk.org/jdk/pull/21993/files/5c9db437..1996528c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21993&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21993&range=00-01 Stats: 7640 lines in 253 files changed: 5119 ins; 1462 del; 1059 mod Patch: https://git.openjdk.org/jdk/pull/21993.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21993/head:pull/21993 PR: https://git.openjdk.org/jdk/pull/21993 From jwaters at openjdk.org Mon Nov 11 09:51:35 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 11 Nov 2024 09:51:35 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v7] In-Reply-To: References: Message-ID: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Merge branch 'openjdk:master' into unused - Neater warning silencer in proc_md.h - Revert _WIN32 workaround in log_messages.c - Copyright in VersionInfo.cpp - Remove neutralLangId in VersionInfo.cpp - Remove global memHandle, would've liked to keep it as a comment :( - Merge branch 'master' into unused - 8342682 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21616/files - new: https://git.openjdk.org/jdk/pull/21616/files/5e9039fb..53036a65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=05-06 Stats: 200965 lines in 1998 files changed: 125072 ins; 52904 del; 22989 mod Patch: https://git.openjdk.org/jdk/pull/21616.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616 PR: https://git.openjdk.org/jdk/pull/21616 From jwaters at openjdk.org Mon Nov 11 09:51:36 2024 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 11 Nov 2024 09:51:36 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v2] In-Reply-To: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com> References: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com> Message-ID: On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer wrote: >>> I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem >> >> I'll also start looking into this in the meantime, unless you explicitly want me not to do so > >> > I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem >> >> I'll also start looking into this in the meantime, unless you explicitly want me not to do so > > Feel free to if you'd like to. Personally I don't consider it to be that important. Bumping, @plummercj I found that casting to void in MUTEX_LOCK and MUTEX_UNLOCK also works, and it seems neater to me. Is this ok with you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2467690492 From sgehwolf at openjdk.org Mon Nov 11 10:09:33 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 11 Nov 2024 10:09:33 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 16:11:37 GMT, Sergey Chernyshev wrote: > I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only. The JBS issue doesn't mention `NullPointerException`. It would be good to list the observed NPE issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2467736667 From sgehwolf at openjdk.org Mon Nov 11 10:26:49 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 11 Nov 2024 10:26:49 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 13:28:29 GMT, Sergey Chernyshev wrote: > Create a new cgroup for memory > > ``` > sudo mkdir -p /sys/fs/cgroup/memory/test > ``` > > Run the following script > > ``` > docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m ubuntu:latest \ > sh -c "sleep 10 ; /jdk/bin/java -Xlog:os+container=trace -version" | grep Memory\ Limit & > sleep 10 > HOSTPID=$(sudo ps -ef | awk '/container=trace/ && !/docker/ && !/awk/ { print $2 }') > echo $HOSTPID | sudo tee /sys/fs/cgroup/memory/test/cgroup.procs > sleep 10 > ``` > > In the above script, a containerized process (`/bin/sh`) is moved to cgroup `/test` before `/jdk/bin/java` gets executed. Java inherits cgroup `/test` from its parent process, its `_root` will be `/docker/`, `cgroup_path` will be `/test`. OK, but why is https://bugs.openjdk.org/browse/JDK-8322420 not in effect in such a case? > The result would be ($JAVA_HOME points to JDK before fix) > > ``` > 9804 > [0.001s][trace][os,container] Memory Limit failed: -2 > [0.001s][trace][os,container] Memory Limit failed: -2 > [0.002s][trace][os,container] Memory Limit failed: -2 > [0.043s][trace][os,container] Memory Limit failed: -2 > ``` > > JDK updated version: > > ``` > 10001 > [0.001s][trace ][os,container] Memory Limit is: 419430400 > [0.001s][trace ][os,container] Memory Limit is: 419430400 > [0.002s][trace ][os,container] Memory Limit is: 419430400 > [0.035s][trace ][os,container] Memory Limit is: 419430400 > ``` It would be good to see the full boot JVM output at the trace level. I'm wondering why the adjustment isn't sufficient for the use-case the bug describes. I.e. if the move happens *before* the JVM starts then there is a chance it works OK by detecting some limit. If not it would really be useful to understand it better. If, however, the cgroup move happens after the JVM has started, there is nothing in the JVM which "corrects" the detected physical memory (i.e. heap size et. al) and/or detected CPUs. It's not supported to do that dynamically. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2467779326 From sgehwolf at openjdk.org Mon Nov 11 10:26:49 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 11 Nov 2024 10:26:49 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 10:06:11 GMT, Severin Gehwolf wrote: > > I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only. > > The JBS issue doesn't mention `NullPointerException`. It would be good to list the observed NPE issue. I also wonder, then, if the issue is NPE if [JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) would fix that issue. The controller adjustment doesn't yet happen on the Java (Metrics) level. Only hotspot so far. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2467787891 From kevinw at openjdk.org Mon Nov 11 11:00:20 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 11 Nov 2024 11:00:20 GMT Subject: RFR: 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException [v2] In-Reply-To: References: Message-ID: <5bak2clhQ-QebN_OurdJe6ZyK0zYheHBCtSxosFO_cI=.a4eabfb5-5bbe-425d-aca4-e0ac39178b9a@github.com> On Mon, 11 Nov 2024 09:18:34 GMT, Kevin Walls wrote: >> Looks like EmptyDomainNotificationTest has been working by accident for nearly 20 years. >> Removing notifications when not specifying a domain part of the ObjectName has actually been failing, but calling removeNotificationListener() without a domain has not been sharing the Exception. >> >> ServerNotifForwarder.removeNotificationListener DOES need to add a domain part to an ObjectName that does not have one. >> >> ServerNotifForwarder.addNotificationListener was changed in JDK-6238731, which is what this test is testing. >> >> There is a numeric ID, BUT it still calls removeNotificationListener(ObjectName name, Integer listenerID) it does matter that the ObjectName does not match. >> >> Maybe the failure to record and throw the Exceptions was the reason it was thought the numeric ID made the domain unnecessary. > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Update problemlist > - Merge remote-tracking branch 'upstream/master' into 8343838_Notification > - 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException Updated with problemlist removal. Clean run from tier3 testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21993#issuecomment-2467883817 From dholmes at openjdk.org Mon Nov 11 12:30:25 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 11 Nov 2024 12:30:25 GMT Subject: RFR: 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException [v2] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 09:18:34 GMT, Kevin Walls wrote: >> Looks like EmptyDomainNotificationTest has been working by accident for nearly 20 years. >> Removing notifications when not specifying a domain part of the ObjectName has actually been failing, but calling removeNotificationListener() without a domain has not been sharing the Exception. >> >> ServerNotifForwarder.removeNotificationListener DOES need to add a domain part to an ObjectName that does not have one. >> >> ServerNotifForwarder.addNotificationListener was changed in JDK-6238731, which is what this test is testing. >> >> There is a numeric ID, BUT it still calls removeNotificationListener(ObjectName name, Integer listenerID) it does matter that the ObjectName does not match. >> >> Maybe the failure to record and throw the Exceptions was the reason it was thought the numeric ID made the domain unnecessary. > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Update problemlist > - Merge remote-tracking branch 'upstream/master' into 8343838_Notification > - 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21993#pullrequestreview-2427162816 From kevinw at openjdk.org Mon Nov 11 12:30:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 11 Nov 2024 12:30:25 GMT Subject: RFR: 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException [v2] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 09:18:34 GMT, Kevin Walls wrote: >> Looks like EmptyDomainNotificationTest has been working by accident for nearly 20 years. >> Removing notifications when not specifying a domain part of the ObjectName has actually been failing, but calling removeNotificationListener() without a domain has not been sharing the Exception. >> >> ServerNotifForwarder.removeNotificationListener DOES need to add a domain part to an ObjectName that does not have one. >> >> ServerNotifForwarder.addNotificationListener was changed in JDK-6238731, which is what this test is testing. >> >> There is a numeric ID, BUT it still calls removeNotificationListener(ObjectName name, Integer listenerID) it does matter that the ObjectName does not match. >> >> Maybe the failure to record and throw the Exceptions was the reason it was thought the numeric ID made the domain unnecessary. > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Update problemlist > - Merge remote-tracking branch 'upstream/master' into 8343838_Notification > - 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException Thanks David! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21993#issuecomment-2468055895 From kevinw at openjdk.org Mon Nov 11 12:30:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 11 Nov 2024 12:30:25 GMT Subject: Integrated: 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 20:46:52 GMT, Kevin Walls wrote: > Looks like EmptyDomainNotificationTest has been working by accident for nearly 20 years. > Removing notifications when not specifying a domain part of the ObjectName has actually been failing, but calling removeNotificationListener() without a domain has not been sharing the Exception. > > ServerNotifForwarder.removeNotificationListener DOES need to add a domain part to an ObjectName that does not have one. > > ServerNotifForwarder.addNotificationListener was changed in JDK-6238731, which is what this test is testing. > > There is a numeric ID, BUT it still calls removeNotificationListener(ObjectName name, Integer listenerID) it does matter that the ObjectName does not match. > > Maybe the failure to record and throw the Exceptions was the reason it was thought the numeric ID made the domain unnecessary. This pull request has now been integrated. Changeset: 50161322 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/5016132291b8cb94c37ffb9397282927df87a3c5 Stats: 15 lines in 2 files changed: 12 ins; 2 del; 1 mod 8343838: Test EmptyDomainNotificationTest.java fails with ListenerNotFoundException Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/21993 From kevinw at openjdk.org Mon Nov 11 12:39:37 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 11 Nov 2024 12:39:37 GMT Subject: RFR: 8343936: Adjust timeout in test javax/management/monitor/DerivedGaugeMonitorTest.java Message-ID: Test timeout change to cope with -Xcomp runs. Long-standing problemlisted test. With -Xcomp locally I could see a failure on the second attempt. After this change, ran more runs locally and 40 runs per platform in CI are OK. ------------- Commit messages: - Merge remote-tracking branch 'upstream/master' into 8042211_DerivedGaugeMonitorTest - 8042211: javax/management/monitor/DerivedGaugeMonitorTest.java AByte: Count down not reached Changes: https://git.openjdk.org/jdk/pull/22008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343936 Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22008/head:pull/22008 PR: https://git.openjdk.org/jdk/pull/22008 From dfuchs at openjdk.org Mon Nov 11 14:49:12 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 11 Nov 2024 14:49:12 GMT Subject: RFR: 8343936: Adjust timeout in test javax/management/monitor/DerivedGaugeMonitorTest.java In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 11:06:17 GMT, Kevin Walls wrote: > Test timeout change to cope with -Xcomp runs. > Long-standing problemlisted test. > > With -Xcomp locally I could see a failure on the second attempt. > After this change, ran more runs locally and 40 runs per platform in CI are OK. Looks reasonable to me. A possible alternative would be to use `jdk.test.lib.Utils.adjustTimeout(long)` to take into account the `timeoutFactor`. IIRC tests run with an icreased `timeoutFactor` when run with -Xcomp ------------- PR Review: https://git.openjdk.org/jdk/pull/22008#pullrequestreview-2427486147 From sgehwolf at openjdk.org Mon Nov 11 15:19:55 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 11 Nov 2024 15:19:55 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 10:20:02 GMT, Severin Gehwolf wrote: > > In the above script, a containerized process (/bin/sh) is moved to cgroup /test before /jdk/bin/java gets executed. Java inherits cgroup /test from its parent process, its _root will be /docker/, cgroup_path will be /test. > > OK, but why is https://bugs.openjdk.org/browse/JDK-8322420 not in effect in such a case? Answering my own question. Because the `set_subsystem_path()` function for cg v1 in this unusual setup returns `null`. [0.001s][trace][os,container] OSContainer::init: Initializing Container Support [0.001s][debug][os,container] Detected optional pids controller entry in /proc/cgroups [0.002s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers [0.002s][trace][os,container] Adjusting controller path for memory: (null) [0.002s][debug][os,container] read_string: subsystem path is null [0.002s][trace][os,container] Memory Limit failed: -2 [0.002s][debug][os,container] read_string: subsystem path is null [0.002s][trace][os,container] Memory Limit failed: -2 [0.002s][trace][os,container] No lower limit found for memory in hierarchy /sys/fs/cgroup/memory, adjusting to original path /test [0.002s][debug][os,container] OSContainer::init: is_containerized() = true because all controllers are mounted read-only (container case) [0.003s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us [0.003s][trace][os,container] CPU Quota is: -1 [0.003s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us [0.003s][trace][os,container] CPU Period is: 100000 [0.003s][trace][os,container] OSContainer::active_processor_count: 12 [0.003s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 12 [0.003s][trace][os,container] total physical memory: 67163226112 [0.003s][debug][os,container] read_string: subsystem path is null [0.003s][trace][os,container] Memory Limit failed: -2 [0.005s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 12 [0.021s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 12 openjdk 24-internal 2025-03-18 OpenJDK Runtime Environment (build 24-internal-adhoc.sgehwolf.jdk-jdk) OpenJDK 64-Bit Server VM (build 24-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing) On cg v2, on the other hand, `set_subsystem_path()` will never set the path to a `null` value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2468417142 From sgehwolf at openjdk.org Mon Nov 11 15:50:57 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 11 Nov 2024 15:50:57 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into JDK-8343191 > - patch reimplemented > - fix the logic that skips duplicate controller's mount points > - 8343191: Cgroup v1 subsystem fails to set subsystem path So on cg v1 you start out and end with a `subsystem_path() == null` and on cg v2 you start out and end with a `subsystem_path() == /../../../../../../test`. In both cases the memory limit of 400m won't be detected. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2468488527 From schernyshev at openjdk.org Mon Nov 11 16:50:43 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 11 Nov 2024 16:50:43 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 15:16:15 GMT, Severin Gehwolf wrote: > On cg v2, on the other hand, `set_subsystem_path()` will never set the path to a `null` value. Exactly. That's why JDK-8322420 is not in effect and also [JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) does not fix it on Java side (path stays uninitialized in certain conditions). ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2468614420 From aivanov at openjdk.org Mon Nov 11 17:43:07 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Mon, 11 Nov 2024 17:43:07 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 21:01:57 GMT, Phil Race wrote: >>> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test. >> >> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? >> >> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`: >> >> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198 > >> > I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test. >> >> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? >> >> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`: >> >> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198 > > I think I was just saying there appeared to be dead code in the test. > > @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`? > > I think I was just saying there appeared to be dead code in the test. Hmm? `createPrivateValue` had been called from the `main` method, so it had been used in the test until it was removed in https://github.com/openjdk/jdk/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea Since `MultiUIDefaults` is still used in `UIManager` and we're keeping the test, I'm for keeping a test for `createPrivateValue` too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1837009964 From kevinw at openjdk.org Mon Nov 11 17:45:02 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 11 Nov 2024 17:45:02 GMT Subject: RFR: 8343936: Adjust timeout in test javax/management/monitor/DerivedGaugeMonitorTest.java [v2] In-Reply-To: References: Message-ID: > Test timeout change to cope with -Xcomp runs. > Long-standing problemlisted test. > > With -Xcomp locally I could see a failure on the second attempt. > After this change, ran more runs locally and 40 runs per platform in CI are OK. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Use adjustTimeout / test.timeout.factor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22008/files - new: https://git.openjdk.org/jdk/pull/22008/files/84e285a5..1bb1cbba Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22008&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22008&range=00-01 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22008/head:pull/22008 PR: https://git.openjdk.org/jdk/pull/22008 From kevinw at openjdk.org Mon Nov 11 17:45:02 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 11 Nov 2024 17:45:02 GMT Subject: RFR: 8343936: Adjust timeout in test javax/management/monitor/DerivedGaugeMonitorTest.java [v2] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 14:46:28 GMT, Daniel Fuchs wrote: > `jdk.test.lib.Utils.adjustTimeout(long)` to take into account the `timeoutFactor`. IIRC tests run with an icreased `timeoutFactor` when run with -Xcomp OK sure 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22008#issuecomment-2468714269 From dfuchs at openjdk.org Mon Nov 11 17:50:20 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 11 Nov 2024 17:50:20 GMT Subject: RFR: 8343936: Adjust timeout in test javax/management/monitor/DerivedGaugeMonitorTest.java [v2] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 17:45:02 GMT, Kevin Walls wrote: >> Test timeout change to cope with -Xcomp runs. >> Long-standing problemlisted test. >> >> With -Xcomp locally I could see a failure on the second attempt. >> After this change, ran more runs locally and 40 runs per platform in CI are OK. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Use adjustTimeout / test.timeout.factor Marked as reviewed by dfuchs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22008#pullrequestreview-2427850408 From kevinw at openjdk.org Mon Nov 11 17:50:20 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 11 Nov 2024 17:50:20 GMT Subject: RFR: 8343936: Adjust timeout in test javax/management/monitor/DerivedGaugeMonitorTest.java [v2] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 17:45:02 GMT, Kevin Walls wrote: >> Test timeout change to cope with -Xcomp runs. >> Long-standing problemlisted test. >> >> With -Xcomp locally I could see a failure on the second attempt. >> After this change, ran more runs locally and 40 runs per platform in CI are OK. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Use adjustTimeout / test.timeout.factor Thanks Daniel! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22008#issuecomment-2468723167 From schernyshev at openjdk.org Mon Nov 11 18:31:16 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Mon, 11 Nov 2024 18:31:16 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 15:48:48 GMT, Severin Gehwolf wrote: > So on cg v1 you start out and end with a `subsystem_path() == null` and on cg v2 you start out and end with a `subsystem_path() == /../../../../../../test`. In both cases the memory limit of 400m won't be detected. Only when docker fails to mount the cgroup while moving process to an outer group or a sibling group. It's probably not the case with CloudFoundry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2468791946 From cjplummer at openjdk.org Mon Nov 11 22:17:18 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 11 Nov 2024 22:17:18 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v7] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'openjdk:master' into unused > - Neater warning silencer in proc_md.h > - Revert _WIN32 workaround in log_messages.c > - Copyright in VersionInfo.cpp > - Remove neutralLangId in VersionInfo.cpp > - Remove global memHandle, would've liked to keep it as a comment :( > - Merge branch 'master' into unused > - 8342682 Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2428256817 From ysr at openjdk.org Tue Nov 12 02:34:43 2024 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Tue, 12 Nov 2024 02:34:43 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v3] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 22 Oct 2024 17:12:38 GMT, Zhengyu Gu wrote: >> Congratulations! Good to see the great progress. I just built this PR for some testing and found something unexpected. I ran the genshen VS shenandoah(default) with jbb2015 on aarch64 N2 with 8 cores and Xmx8g. The critical-jOPS of genshen(5373) is behind shenandoah(6027). Do I miss something on the options? >> ```java -Xmx8g -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCHeuristics=adaptive -XX:ShenandoahGCMode=generational -Xlog:gc* -XX:MetaspaceSize=1g -jar specjbb2015.jar -m COMPOSITE``` > >> @mmyxym , Thank you for testing this out! I apologize for not responding to your comment sooner. We run specjbb2015 regularly in our integration pipeline. We see a slight improvement with the generational mode; certainly no regression: >> >> ``` >> Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3620, critical-jOPS = 2375 >> Gen: RUN RESULT: hbIR (max attempted) = 3934, hbIR (settled) = 3295, max-jOPS = 4013, critical-jOPS = 2470 >> Shen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3667, critical-jOPS = 2397 >> Gen: RUN RESULT: hbIR (max attempted) = 4701, hbIR (settled) = 3934, max-jOPS = 3996, critical-jOPS = 2414 >> ``` >> >> These results were produced with these arguments: >> >> ``` >> -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticV >> MOptions -XX:-TieredCompilation -XX:-ShenandoahPacing -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xmx10g -Xms10g -XX:ShenandoahGCMode=generational >> ``` >> >> These runs executed on a Graviton2 host with 4 cores, 16G. I'll run again on a host with more cores and with your exact command line parameters. > > What's the reason to disable tiered compilation? @zhengyu123 and @shipilev : could you please take another look and leave your review feedback and/or approval? We'd like to land the changes this week if possible. Currently internal testing is in progress after merging with the latest changes from tip. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2469466977 From pchilanomate at openjdk.org Tue Nov 12 02:59:59 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 12 Nov 2024 02:59:59 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: - Merge branch 'master' into JDK-8338383 - Test StopThreadTest.java: fix operator in condition + improve names - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java - Merge branch 'master' into JDK-8338383 - Fix in JvmtiEnvBase::get_locked_objects_in_frame() - Add ObjectWaiter::at_monitorenter - Use get_method_name + copyright revert in jvmtiThreadState.cpp - Merge branch 'master' into JDK-8338383 - Add @requires vm.continuations to CancelTimerWithContention.java - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 ------------- Changes: https://git.openjdk.org/jdk/pull/21565/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=04 Stats: 9984 lines in 249 files changed: 7169 ins; 1629 del; 1186 mod Patch: https://git.openjdk.org/jdk/pull/21565.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565 PR: https://git.openjdk.org/jdk/pull/21565 From pchilanomate at openjdk.org Tue Nov 12 03:04:35 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 12 Nov 2024 03:04:35 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: > > - Merge branch 'master' into JDK-8338383 > - Test StopThreadTest.java: fix operator in condition + improve names > - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java > - Merge branch 'master' into JDK-8338383 > - Fix in JvmtiEnvBase::get_locked_objects_in_frame() > - Add ObjectWaiter::at_monitorenter > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 I merged with master, including the changes for [JEP 450](https://github.com/openjdk/jdk/pull/20677), and run it through tiers1-8 in mach5 with no related failures. I would like to integrate tomorrow if I could get some re-approvals. Also, I filed JDK-8343957 to possibly improve the naming of `_lock_id/owner_from` as discussed in some of the comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2469493942 From dholmes at openjdk.org Tue Nov 12 07:09:12 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 12 Nov 2024 07:09:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: <3vfCjVBL-b8oC8v_8fW5QdXjAT1ssSjfPgFoNL1fNu0=.d7efc5eb-3e84-42b5-b8ce-9c9cc11900bf@github.com> On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: > > - Merge branch 'master' into JDK-8338383 > - Test StopThreadTest.java: fix operator in condition + improve names > - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java > - Merge branch 'master' into JDK-8338383 > - Fix in JvmtiEnvBase::get_locked_objects_in_frame() > - Add ObjectWaiter::at_monitorenter > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 Still good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2428723863 From swen at openjdk.org Tue Nov 12 07:53:44 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 07:53:44 GMT Subject: RFR: 8343984: Fix Unsafe address overflow Message-ID: In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. ------------- Commit messages: - fix unsafe address overflow Changes: https://git.openjdk.org/jdk/pull/22027/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343984 Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/22027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027 PR: https://git.openjdk.org/jdk/pull/22027 From swen at openjdk.org Tue Nov 12 07:53:45 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 07:53:45 GMT Subject: RFR: 8343984: Fix Unsafe address overflow In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen wrote: > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. There are two other possible address overflow issues that are difficult to fix: java.util.zip.CRC32C::updateBytes jdk.internal.util.ArraysSupport::mismatch ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2469804720 From pminborg at openjdk.org Tue Nov 12 08:18:31 2024 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 12 Nov 2024 08:18:31 GMT Subject: RFR: 8343984: Fix Unsafe address overflow In-Reply-To: References: Message-ID: <9K4lLRbHYMRCcy1Q0c6ADdAPVJyiQDwxJ41LeubLMqo=.89dd5f07-b921-49bc-a528-aa17c72b3d8a@github.com> On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen wrote: > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. src/java.base/share/classes/sun/nio/cs/StringUTF16.java line 35: > 33: public static char getChar(byte[] val, int index) { > 34: return unsafe.getChar(val, > 35: (long) ARRAY_BYTE_BASE_OFFSET + ARRAY_BYTE_INDEX_SCALE * index * 2L); This expression already contains `2L` which is a `long`. So, isn't the result of the multiplications of type `long`, and consequently, isn't the entire expression calculated with `long` precision as it is? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837653228 From swen at openjdk.org Tue Nov 12 08:26:44 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 08:26:44 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v2] In-Reply-To: References: Message-ID: > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: revert, from @minborg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22027/files - new: https://git.openjdk.org/jdk/pull/22027/files/8087831c..b9294369 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027 PR: https://git.openjdk.org/jdk/pull/22027 From swen at openjdk.org Tue Nov 12 08:26:46 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 08:26:46 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v2] In-Reply-To: <9K4lLRbHYMRCcy1Q0c6ADdAPVJyiQDwxJ41LeubLMqo=.89dd5f07-b921-49bc-a528-aa17c72b3d8a@github.com> References: <9K4lLRbHYMRCcy1Q0c6ADdAPVJyiQDwxJ41LeubLMqo=.89dd5f07-b921-49bc-a528-aa17c72b3d8a@github.com> Message-ID: On Tue, 12 Nov 2024 08:15:33 GMT, Per Minborg wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> revert, from @minborg > > src/java.base/share/classes/sun/nio/cs/StringUTF16.java line 35: > >> 33: public static char getChar(byte[] val, int index) { >> 34: return unsafe.getChar(val, >> 35: (long) ARRAY_BYTE_BASE_OFFSET + ARRAY_BYTE_INDEX_SCALE * index * 2L); > > This expression already contains `2L` which is a `long`. So, isn't the result of the multiplications of type `long`, and consequently, isn't the entire expression calculated with `long` precision as it is? You are right, there is no need to add an explicit type conversion here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837663142 From pminborg at openjdk.org Tue Nov 12 08:47:48 2024 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 12 Nov 2024 08:47:48 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v2] In-Reply-To: References: Message-ID: <_prE4LHsGuZK3LlsVUCgGOCjPIlLQ8XRfgZG37p9LGo=.32f61ce8-642f-46d9-b597-d4bcc1118ed9@github.com> On Tue, 12 Nov 2024 08:26:44 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > revert, from @minborg It would be good to add some tests to ensure `long` precision is used. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1006: > 1004: } > 1005: > 1006: private void writeBooleanArray(TypeArray array, int length) throws IOException { Note that the copyright year needs updating. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 4104: > 4102: @ForceInline > 4103: static long byteArrayAddress(byte[] a, int index) { > 4104: return (long) Unsafe.ARRAY_BYTE_BASE_OFFSET + index; These classes are generated via the `X-Vector.java.template` in the `java.incubator.vector` package. So, you only need to change one file here. ![image](https://github.com/user-attachments/assets/2dbda48c-ae17-4809-a46f-62065ee9eab3) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2469916847 PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837687593 PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837685399 From swen at openjdk.org Tue Nov 12 08:59:30 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 08:59:30 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v3] In-Reply-To: References: Message-ID: > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @minborg ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22027/files - new: https://git.openjdk.org/jdk/pull/22027/files/b9294369..c719c7d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=01-02 Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/22027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027 PR: https://git.openjdk.org/jdk/pull/22027 From alanb at openjdk.org Tue Nov 12 09:06:30 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 12 Nov 2024 09:06:30 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v3] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 08:59:30 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @minborg src/java.base/share/classes/java/lang/StringLatin1.java line 836: > 834: UNSAFE.putByte(val, address , (byte)(c1)); > 835: UNSAFE.putByte(val, address + 1, (byte)(c2)); > 836: UNSAFE.putByte(val, address + 2, (byte)(c3)); While you are here, I wonder if this should be renamed to offset to make it clearer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837720784 From pminborg at openjdk.org Tue Nov 12 09:12:05 2024 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 12 Nov 2024 09:12:05 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v3] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 08:59:30 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > from @minborg The generation of Java files works a bit differently from other places in the JDK (e.g. NIO). Now that the template has been changed, you also need to manually run the script `gen-src.sh` in order to regenerate the classes. So, they will then show up like they did in an earlier commit but share a single source of truth. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2469971317 From kevinw at openjdk.org Tue Nov 12 09:17:13 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 12 Nov 2024 09:17:13 GMT Subject: Integrated: 8343936: Adjust timeout in test javax/management/monitor/DerivedGaugeMonitorTest.java In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 11:06:17 GMT, Kevin Walls wrote: > Test timeout change to cope with -Xcomp runs. > Long-standing problemlisted test. > > With -Xcomp locally I could see a failure on the second attempt. > After this change, ran more runs locally and 40 runs per platform in CI are OK. This pull request has now been integrated. Changeset: 4fa760a1 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/4fa760a1ed24ad2e6fba6dca51c5cf7dc7436719 Stats: 9 lines in 2 files changed: 5 ins; 2 del; 2 mod 8343936: Adjust timeout in test javax/management/monitor/DerivedGaugeMonitorTest.java Reviewed-by: dfuchs ------------- PR: https://git.openjdk.org/jdk/pull/22008 From sgehwolf at openjdk.org Tue Nov 12 09:37:12 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 12 Nov 2024 09:37:12 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 18:28:11 GMT, Sergey Chernyshev wrote: > > So on cg v1 you start out and end with a `subsystem_path() == null` and on cg v2 you start out and end with a `subsystem_path() == /../../../../../../test`. In both cases the memory limit of 400m won't be detected. > > Only when docker fails to mount the cgroup while moving process to an outer group or a sibling group. It's probably not the case with CloudFoundry. The bug suggests it's a cg v1 only problem, but I'm able to reproduce in cg v2 too. We should handle both cases more gracefully. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2470033800 From swen at openjdk.org Tue Nov 12 09:55:17 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 09:55:17 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v4] In-Reply-To: References: Message-ID: <1bBT7IyN6vjZdTpD2gEs-yLSrR-QnRDabKs9TeQmcSs=.c9b61faf-0606-439e-b6de-1186c21d2b4f@github.com> > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision: - re gen-src - rename address to offset, from @AlanBateman ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22027/files - new: https://git.openjdk.org/jdk/pull/22027/files/c719c7d1..4e007699 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=02-03 Stats: 11 lines in 7 files changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/22027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027 PR: https://git.openjdk.org/jdk/pull/22027 From aboldtch at openjdk.org Tue Nov 12 10:16:15 2024 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Tue, 12 Nov 2024 10:16:15 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: > > - Merge branch 'master' into JDK-8338383 > - Test StopThreadTest.java: fix operator in condition + improve names > - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java > - Merge branch 'master' into JDK-8338383 > - Fix in JvmtiEnvBase::get_locked_objects_in_frame() > - Add ObjectWaiter::at_monitorenter > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 Marked as reviewed by aboldtch (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2429155294 From swen at openjdk.org Tue Nov 12 11:24:24 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 11:24:24 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v5] In-Reply-To: References: Message-ID: > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: rename address to offset, from @AlanBateman ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22027/files - new: https://git.openjdk.org/jdk/pull/22027/files/4e007699..f8f58546 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=03-04 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027 PR: https://git.openjdk.org/jdk/pull/22027 From pminborg at openjdk.org Tue Nov 12 11:37:17 2024 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 12 Nov 2024 11:37:17 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > rename address to offset, from @AlanBateman LGTM. If there are no additional tests, please label the JBS issue appropriately (i.e `noreg-*`) ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2429343536 From alanb at openjdk.org Tue Nov 12 12:13:23 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 12 Nov 2024 12:13:23 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > rename address to offset, from @AlanBateman Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2429423006 From swen at openjdk.org Tue Nov 12 12:20:10 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 12:20:10 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > rename address to offset, from @AlanBateman I want to add such a test case, but I am worried that it will consume too many resources during the build process. /** * @test * @bug 8343984 * @summary Test that the append capacity is close to Integer.MaxValue * @run main/othervm -Xms6g -Xmx6g HugeAppend */ public final class HugeAppend { public static void main(String[] args) { StringBuilder buf = new StringBuilder(); int loop4 = Integer.MAX_VALUE / 4; for (int i = 0; i < loop4; i++) { buf.append(true); } buf.setLength(0); int loop5 = Integer.MAX_VALUE / 5; for (int i = 0; i < loop5; i++) { buf.append(false); } } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470377122 From pminborg at openjdk.org Tue Nov 12 12:20:10 2024 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 12 Nov 2024 12:20:10 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v5] In-Reply-To: References: Message-ID: <6oLW76lwfUSTt2s40UvAeKqadewY7-_Bl8EoTk9Hkko=.2b081d05-ecbf-4348-8fd2-1151abd8cdb9@github.com> On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > rename address to offset, from @AlanBateman > I want to add such a test case, but I am worried that it will consume too many resources during the build process. > > ```java > /** > * @test > * @bug 8343984 > * @summary Test that the append capacity is close to Integer.MaxValue > * @run main/othervm -Xms6g -Xmx6g HugeAppend > */ > > public final class HugeAppend { > public static void main(String[] args) { > StringBuilder buf = new StringBuilder(); > int loop4 = Integer.MAX_VALUE / 4; > for (int i = 0; i < loop4; i++) { > buf.append(true); > } > > buf.setLength(0); > int loop5 = Integer.MAX_VALUE / 5; > for (int i = 0; i < loop5; i++) { > buf.append(false); > } > } > } > ``` Yeah. I think it is reasonable to leave out such tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470383131 From mullan at openjdk.org Tue Nov 12 13:01:33 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 13:01:33 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v10] In-Reply-To: References: Message-ID: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits: - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Move remaining JEP 486 failing tests into correct groups. - Move JEP 486 failing tests into hotspot_runtime group. - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40 ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=09 Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 del; 3843 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From swen at openjdk.org Tue Nov 12 13:48:35 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 13:48:35 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > rename address to offset, from @AlanBateman macos-aarch64 build error, I have been encountering this problem for the past two days. How do I solve it? Run # On macOS we need to install some dependencies for testing # On macOS we need to install some dependencies for testing brew install make sudo xcode-select --switch /Applications/Xcode_14.3.1.app/Contents/Developer # This will make GNU make available as 'make' and not only as 'gmake' echo '/usr/local/opt/make/libexec/gnubin' >> $GITHUB_PATH shell: /bin/bash --noprofile --norc -e -o pipefail {0} env: MSYS[2](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:2)_PATH_TYPE: minimal CHERE_INVOKING: 1 ==> Downloading https://ghcr.io/v2/homebrew/core/make/manifests/4.4.1-1 ==> Fetching make ==> Downloading https://ghcr.io/v2/homebrew/core/make/blobs/sha256:94[3](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:3)77dc5a364da305c75fd7aa923a[4](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:4)2897993de9edd1eb074428e13c3f2aaf93 ==> Pouring make--4.4.1.arm64_sonoma.bottle.1.tar.gz ==> Caveats GNU "make" has been installed as "gmake". If you need to use it as "make", you can add a "gnubin" directory to your PATH from your bashrc like: PATH="/opt/homebrew/opt/make/libexec/gnubin:$PATH" ==> Summary ? /opt/homebrew/Cellar/make/4.4.1: 1[7](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:7) files, 1.3MB xcode-select: error: invalid developer directory '/Applications/Xcode_14.3.1.app/Contents/Developer' Error: Process completed with exit code 1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470568595 From kevinw at openjdk.org Tue Nov 12 14:18:27 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 12 Nov 2024 14:18:27 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v10] In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> References: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> Message-ID: On Tue, 12 Nov 2024 13:01:33 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing > - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40 Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429727015 From swen at openjdk.org Tue Nov 12 14:22:11 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 14:22:11 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v5] In-Reply-To: <6oLW76lwfUSTt2s40UvAeKqadewY7-_Bl8EoTk9Hkko=.2b081d05-ecbf-4348-8fd2-1151abd8cdb9@github.com> References: <6oLW76lwfUSTt2s40UvAeKqadewY7-_Bl8EoTk9Hkko=.2b081d05-ecbf-4348-8fd2-1151abd8cdb9@github.com> Message-ID: On Tue, 12 Nov 2024 12:18:03 GMT, Per Minborg wrote: > I want to add such a test case, but I am worried that it will consume too many resources during the build process. > > ```java > /** > * @test > * @bug 8343984 > * @summary Test that the append capacity is close to Integer.MaxValue > * @run main/othervm -Xms6g -Xmx6g HugeAppend > */ > > public final class HugeAppend { > public static void main(String[] args) { > StringBuilder buf = new StringBuilder(); > int loop4 = Integer.MAX_VALUE / 4; > for (int i = 0; i < loop4; i++) { > buf.append(true); > } > > buf.setLength(0); > int loop5 = Integer.MAX_VALUE / 5; > for (int i = 0; i < loop5; i++) { > buf.append(false); > } > } > } > ``` In the master branch, this test will succeed in jtreg * jtreg make test TEST="jtreg:test/jdk/java/util/BitSet/HugeToString.java" * result ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:test/jdk/java/util/BitSet/HugeToString.java 1 1 0 0 ============================== TEST SUCCESS But running it directly will cause JVM Crash ~/git/jdk_x/build/macosx-aarch64-server-release/images/jdk/bin/java -Xms6g -Xmx6g HugeAppend ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470661592 From rriggs at openjdk.org Tue Nov 12 14:25:10 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Nov 2024 14:25:10 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v10] In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> References: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com> Message-ID: On Tue, 12 Nov 2024 13:01:33 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits: > > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing > - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40 Good to go! ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429741829 From mullan at openjdk.org Tue Nov 12 14:44:55 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 14:44:55 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: - Merge - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge branch 'master' into jep486 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 - Merge branch 'master' into jep486 - Move remaining JEP 486 failing tests into correct groups. - Move JEP 486 failing tests into hotspot_runtime group. - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e ------------- Changes: https://git.openjdk.org/jdk/pull/21498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=10 Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 del; 3843 mod Patch: https://git.openjdk.org/jdk/pull/21498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498 PR: https://git.openjdk.org/jdk/pull/21498 From kevinw at openjdk.org Tue Nov 12 14:48:36 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 12 Nov 2024 14:48:36 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429813961 From rriggs at openjdk.org Tue Nov 12 14:55:29 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Nov 2024 14:55:29 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429830332 From schernyshev at openjdk.org Tue Nov 12 15:03:36 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 12 Nov 2024 15:03:36 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 10:23:02 GMT, Severin Gehwolf wrote: > The JBS issue doesn't mention `NullPointerException`. It would be good to list the observed NPE issue. Example for NPE: public class Test { public static void main(String[] args) { java.lang.management.ManagementFactory.getPlatformMBeanServer(); System.out.println("PASSED."); } } Script (cg v1): sudo docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --volume=./classes:/classes:ro --memory 400m ubuntu:latest \ sh -c "sleep 10 ; /jdk/bin/java -cp .:/classes Test" & sleep 10; HOSTPID=$(sudo ps -ef | awk '/jdk/bin/java/ && !/docker/ && !/awk/ { print $2 }') echo $HOSTPID | sudo tee /sys/fs/cgroup/memory/test/cgroup.procs > /dev/null sleep 10 Result (cg v1 before patch): Exception in thread "main" java.lang.NullPointerException at java.base/java.util.Objects.requireNonNull(Objects.java:220) at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:296) at java.base/java.nio.file.Path.of(Path.java:148) at java.base/java.nio.file.Paths.get(Paths.java:69) at java.base/jdk.internal.platform.CgroupUtil.lambda$readStringValue$0(CgroupUtil.java:67) at java.base/java.security.AccessController.doPrivileged(AccessController.java:571) at java.base/jdk.internal.platform.CgroupUtil.readStringValue(CgroupUtil.java:69) at java.base/jdk.internal.platform.CgroupSubsystemController.getStringValue(CgroupSubsystemController.java:65) at java.base/jdk.internal.platform.CgroupSubsystemController.getLongValue(CgroupSubsystemController.java:124) at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getLongValue(CgroupV1Subsystem.java:190) at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getHierarchical(CgroupV1Subsystem.java:160) at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.initSubSystem(CgroupV1Subsystem.java:85) at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getInstance(CgroupV1Subsystem.java:61) at java.base/jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:119) at java.base/jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:89) at java.base/jdk.internal.platform.CgroupMetrics.getInstance(CgroupMetrics.java:198) at java.base/jdk.internal.platform.SystemMetrics.instance(SystemMetrics.java:29) at java.base/jdk.internal.platform.Metrics.systemMetrics(Metrics.java:58) at java.base/jdk.internal.platform.Container.metrics(Container.java:43) at jdk.management/com.sun.management.internal.OperatingSystemImpl.(OperatingSystemImpl.java:175) at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl.getOperatingSystemMXBean(PlatformMBeanProviderImpl.java:316) at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl$4.nameToMBeanMap(PlatformMBeanProviderImpl.java:235) at java.management/java.lang.management.ManagementFactory.lambda$getPlatformMBeanServer$0(ManagementFactory.java:489) at java.base/java.util.stream.ReferencePipeline$7$1FlatMap.accept(ReferencePipeline.java:289) at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197) at java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1788) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560) at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153) at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265) at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:636) at java.management/java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:490) at Test.main(Test.java:3) After patch: [0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/test] [0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/] [0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/] Nov 12, 2024 1:14:11 PM jdk.internal.platform.cgroupv1.CgroupV1SubsystemController setPath WARNING: Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/test]. PASSED. In cg v2 the NPE is not observed. > > Only when docker fails to mount the cgroup while moving process to an outer group or a sibling group. It's probably not the case with CloudFoundry. > > The bug suggests it's a cg v1 only problem, but I'm able to reproduce in cg v2 too. We should handle both cases more gracefully. what gets reproduced in cg v2 is in fact a different issue, the cgroup files are not mapped inside the container. Nothing can be done in Java to overcome this. There are no files in /sys/fs/cgroup. The only workaround is --cgroupns=host, then the correct limits are displayed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2470765864 From mullan at openjdk.org Tue Nov 12 15:05:09 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 15:05:09 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 18:31:13 GMT, Harshitha Onkar wrote: >> It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()). >> >> Without the `@see` tag, one has to read the entire description to find the link. >> >> It looks subtle. We can restore the `@see`-link later if deemed necessary. >> >> Does anyone else have an opinion? > > I can add it back if it is more convenient and readable to have the `@see` tag. This can be taken care of later after integration. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838260852 From mullan at openjdk.org Tue Nov 12 15:05:14 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 15:05:14 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v3] In-Reply-To: References: Message-ID: <-KIDgN-bR6eT5GTOj2hiyz0oLJXR7Ewx1taEzXeaRsw=.3d2f141a-8183-4f70-af74-c06b47f29478@github.com> On Thu, 24 Oct 2024 17:03:25 GMT, Alexey Ivanov wrote: >> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Merge >> - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module". >> - Remove println about Security Manager. >> - Remove unused static variable NEW_PROXY_IN_PKG. >> - Remove static variable `DEFAULT_POLICY` and unused imports. >> - Remove hasSM() method and code that calls it, and remove comment about >> running test manually with SM. >> - clientlibs: import order >> - warning-string >> - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java >> - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde > > test/jdk/java/beans/Introspector/7084904/Test7084904.java line 31: > >> 29: * @library .. >> 30: * @run main Test7084904 >> 31: * @author Sergey Malenkov > > The test below `Test4683761.java` removes the `@author` tag. Should it be removed here? This can be handled later in a more general cleanup task. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838259103 From mullan at openjdk.org Tue Nov 12 15:05:15 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 15:05:15 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v6] In-Reply-To: References: Message-ID: On Fri, 1 Nov 2024 19:40:03 GMT, Alexey Ivanov wrote: >> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits: >> >> - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 >> - Modify three RMI tests to work without the security manager: >> - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java >> - test/jdk/java/rmi/registry/readTest/CodebaseTest.java >> - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java >> Also remove them from the problem list. >> - Remove two obsolete RMI tests: >> - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java >> - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java >> Adjust two tests to run without the Security Manager: >> - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java >> - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java >> Remove all of these tests from the problem list. >> - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows. >> - Added API Notes to ProtectionDomain clarifying that the current policy always >> grants no permissions. A few other small changes to Policy and PD. >> - Merge branch 'master' into jep486 >> - JAXP tests: organize imports of a few tests >> - Improve description of Executors.privilegedThreadFactory >> - rename TestAppletLoggerContext.java as suggested in util test review >> - clientlibs: Javadoc cleanup >> - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b > > test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1: > >> 1: /* > > I wonder if we should add an Oracle copyright to the update test file. I don't think it is necessary for that small of a change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838256317 From pchilanomate at openjdk.org Tue Nov 12 15:16:12 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 12 Nov 2024 15:16:12 GMT Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo wrote: >> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. >> >> In order to make the code review easier the changes have been split into the following initial 4 commits: >> >> - Changes to allow unmounting a virtual thread that is currently holding monitors. >> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. >> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. >> - Changes to tests, JFR pinned event, and other changes in the JDK libraries. >> >> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. >> >> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. >> >> >> ## Summary of changes >> >> ### Unmount virtual thread while holding monitors >> >> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: >> >> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. >> >> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. >> >> #### General notes about this part: >> >> - Since virtual th... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: > > - Merge branch 'master' into JDK-8338383 > - Test StopThreadTest.java: fix operator in condition + improve names > - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java > - Merge branch 'master' into JDK-8338383 > - Fix in JvmtiEnvBase::get_locked_objects_in_frame() > - Add ObjectWaiter::at_monitorenter > - Use get_method_name + copyright revert in jvmtiThreadState.cpp > - Merge branch 'master' into JDK-8338383 > - Add @requires vm.continuations to CancelTimerWithContention.java > - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount > - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465 Many thanks to all reviewers and contributors of this JEP! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2470802813 From rriggs at openjdk.org Tue Nov 12 15:17:10 2024 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 12 Nov 2024 15:17:10 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429896801 From aivanov at openjdk.org Tue Nov 12 15:17:10 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 12 Nov 2024 15:17:10 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 15:02:12 GMT, Sean Mullan wrote: >> I can add it back if it is more convenient and readable to have the `@see` tag. > > This can be taken care of later after integration. Agreed! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838282210 From pchilanomate at openjdk.org Tue Nov 12 15:27:02 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 12 Nov 2024 15:27:02 GMT Subject: Integrated: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning In-Reply-To: References: Message-ID: On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo wrote: > This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details. > > In order to make the code review easier the changes have been split into the following initial 4 commits: > > - Changes to allow unmounting a virtual thread that is currently holding monitors. > - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor. > - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants. > - Changes to tests, JFR pinned event, and other changes in the JDK libraries. > > The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones. > > The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases. > > > ## Summary of changes > > ### Unmount virtual thread while holding monitors > > As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things: > > - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads. > > - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around. > > #### General notes about this part: > > - Since virtual threads don't need to worry about holding monitors anymo... This pull request has now been integrated. Changeset: 78b80150 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/78b80150e009745b8f28d36c3836f18ad0ca921f Stats: 9984 lines in 249 files changed: 7169 ins; 1629 del; 1186 mod 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning Co-authored-by: Patricio Chilano Mateo Co-authored-by: Alan Bateman Co-authored-by: Andrew Haley Co-authored-by: Fei Yang Co-authored-by: Coleen Phillimore Co-authored-by: Richard Reingruber Co-authored-by: Martin Doerr Reviewed-by: aboldtch, dholmes, coleenp, fbredberg, dlong, sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/21565 From swen at openjdk.org Tue Nov 12 15:54:00 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 15:54:00 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v6] In-Reply-To: References: Message-ID: <62AWophiRKc0GQ_HX3qQ57fqjVl4DuJPUfb4nNoLJ8A=.cfde82d0-b1a4-4137-a80b-cd7410312bae@github.com> > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: more fix unsafe address overflow ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22027/files - new: https://git.openjdk.org/jdk/pull/22027/files/f8f58546..97615464 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=04-05 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027 PR: https://git.openjdk.org/jdk/pull/22027 From swen at openjdk.org Tue Nov 12 15:54:00 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 15:54:00 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 12:10:07 GMT, Alan Bateman wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> rename address to offset, from @AlanBateman > > Marked as reviewed by alanb (Reviewer). @AlanBateman @minborg Sorry, after you approved it, I found that there are still offset overflows in ZipUtils and UnixUserDefinedFileAttributeView, so I submitted the changes again. Please help review it again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470896128 From lancea at openjdk.org Tue Nov 12 16:00:20 2024 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 12 Nov 2024 16:00:20 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Thank you for all of your hard work on this JEP Sean. ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430018834 From coffeys at openjdk.org Tue Nov 12 16:03:27 2024 From: coffeys at openjdk.org (Sean Coffey) Date: Tue, 12 Nov 2024 16:03:27 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by coffeys (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430024985 From aivanov at openjdk.org Tue Nov 12 16:11:19 2024 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 12 Nov 2024 16:11:19 GMT Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security Manager [v11] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan wrote: >> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. >> >> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. >> >> The code changes can be broken down into roughly the following categories: >> >> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. >> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. >> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. >> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). >> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. >> >> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. >> >> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). >> >> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ... > > Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits: > > - Merge > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge branch 'master' into jep486 > - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411 > - Merge branch 'master' into jep486 > - Move remaining JEP 486 failing tests into correct groups. > - Move JEP 486 failing tests into hotspot_runtime group. > - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430049235 From alanb at openjdk.org Tue Nov 12 16:25:39 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 12 Nov 2024 16:25:39 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v6] In-Reply-To: <62AWophiRKc0GQ_HX3qQ57fqjVl4DuJPUfb4nNoLJ8A=.cfde82d0-b1a4-4137-a80b-cd7410312bae@github.com> References: <62AWophiRKc0GQ_HX3qQ57fqjVl4DuJPUfb4nNoLJ8A=.cfde82d0-b1a4-4137-a80b-cd7410312bae@github.com> Message-ID: On Tue, 12 Nov 2024 15:54:00 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > more fix unsafe address overflow Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2430082452 From alanb at openjdk.org Tue Nov 12 16:25:40 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 12 Nov 2024 16:25:40 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v5] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 12:10:07 GMT, Alan Bateman wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> rename address to offset, from @AlanBateman > > Marked as reviewed by alanb (Reviewer). > @AlanBateman @minborg Sorry, after you approved it, I found that there are still offset overflows in ZipUtils and UnixUserDefinedFileAttributeView, so I submitted the changes again. Please help review it again. Looks good, can you bump the copyright header on UnixUserDefinedFileAttributeView too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470974166 From swen at openjdk.org Tue Nov 12 16:30:12 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 16:30:12 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v7] In-Reply-To: References: Message-ID: > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: fix copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22027/files - new: https://git.openjdk.org/jdk/pull/22027/files/97615464..980cb229 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027 PR: https://git.openjdk.org/jdk/pull/22027 From swen at openjdk.org Tue Nov 12 16:40:19 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 16:40:19 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v7] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright @liach provided a new idea, which is to change the type of jdk.internal.misc.Unsafe.ARRAY_XXX_OFFSET from int to long. I think @liach's idea is better, that is the way to completely solve this problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2471016555 From alanb at openjdk.org Tue Nov 12 16:46:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 12 Nov 2024 16:46:31 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v7] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 16:37:28 GMT, Shaojin Wen wrote: > @liach provided a new idea, which is to change the type of jdk.internal.misc.Unsafe.ARRAY_XXX_OFFSET from int to long. I think @liach's idea is better, that is the way to completely solve this problem. I discussed this briefly with him today, he's looking into the implications of doing that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2471038775 From liach at openjdk.org Tue Nov 12 16:52:23 2024 From: liach at openjdk.org (Chen Liang) Date: Tue, 12 Nov 2024 16:52:23 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v7] In-Reply-To: References: Message-ID: <00Pb2OkiKtnrABDOzIvqOFhuNoXn6UyPiy-P1Nu_Nhw=.8bd821bb-2cb6-44da-b39c-72047bad43b1@github.com> On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright I think this patch can go ahead: the change to internal unsafe will affect many other components and all use sites will get bytecode updates. The more comprehensive change will need more throughout investigation and testing, while the fixes here are straightforward and easy to verify. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2471054020 From mullan at openjdk.org Tue Nov 12 17:20:26 2024 From: mullan at openjdk.org (Sean Mullan) Date: Tue, 12 Nov 2024 17:20:26 GMT Subject: Integrated: 8338411: Implement JEP 486: Permanently Disable the Security Manager In-Reply-To: References: Message-ID: On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan wrote: > This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes. > > NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code. > > The code changes can be broken down into roughly the following categories: > > 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default. > 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled. > 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled. > 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916). > 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified. > > There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. > > Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc). > > I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f... This pull request has now been integrated. Changeset: db850905 Author: Sean Mullan URL: https://git.openjdk.org/jdk/commit/db85090553ab14a84c3ed0a2604dd56c5b6e6982 Stats: 68914 lines in 1889 files changed: 2475 ins; 62597 del; 3842 mod 8338411: Implement JEP 486: Permanently Disable the Security Manager Co-authored-by: Sean Mullan Co-authored-by: Alan Bateman Co-authored-by: Weijun Wang Co-authored-by: Aleksei Efimov Co-authored-by: Brian Burkhalter Co-authored-by: Daniel Fuchs Co-authored-by: Harshitha Onkar Co-authored-by: Joe Wang Co-authored-by: Jorn Vernee Co-authored-by: Justin Lu Co-authored-by: Kevin Walls Co-authored-by: Lance Andersen Co-authored-by: Naoto Sato Co-authored-by: Roger Riggs Co-authored-by: Brent Christian Co-authored-by: Stuart Marks Co-authored-by: Ian Graves Co-authored-by: Phil Race Co-authored-by: Erik Gahlin Co-authored-by: Jaikiran Pai Reviewed-by: kevinw, aivanov, rriggs, lancea, coffeys, dfuchs, ihse, erikj, cjplummer, coleenp, naoto, mchung, prr, weijun, joehw, azvegint, psadhukhan, bchristi, sundar, attila ------------- PR: https://git.openjdk.org/jdk/pull/21498 From cjplummer at openjdk.org Tue Nov 12 18:49:44 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 12 Nov 2024 18:49:44 GMT Subject: RFR: 8343781: Add since checker test to the Serviceability area modules In-Reply-To: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> References: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Message-ID: On Fri, 8 Nov 2024 15:20:00 GMT, Nizar Benalla wrote: > Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Serviceability area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. > > The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. > > The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. > > TIA Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21983#pullrequestreview-2430427570 From cjplummer at openjdk.org Tue Nov 12 18:58:45 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 12 Nov 2024 18:58:45 GMT Subject: RFR: 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) [v3] In-Reply-To: <_4If4-yI_2rJlVYS-46qWRN0jioXUaTQss5kwiKOZKA=.81964925-b455-49a3-b226-29a3c5052b35@github.com> References: <_4If4-yI_2rJlVYS-46qWRN0jioXUaTQss5kwiKOZKA=.81964925-b455-49a3-b226-29a3c5052b35@github.com> Message-ID: On Fri, 8 Nov 2024 19:07:34 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into SuppressWarningsCleanup-serviceability > - Update copyright years. > - Merge branch 'master' into SuppressWarningsCleanup-serviceability > - Merge branch 'master' into SuppressWarningsCleanup-serviceability > - Remove unnecessary @SuppressWarnings annotations. How were these discovered and what testing did you do? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21857#issuecomment-2471320752 From acobbs at openjdk.org Tue Nov 12 19:07:30 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Tue, 12 Nov 2024 19:07:30 GMT Subject: RFR: 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) [v3] In-Reply-To: References: <_4If4-yI_2rJlVYS-46qWRN0jioXUaTQss5kwiKOZKA=.81964925-b455-49a3-b226-29a3c5052b35@github.com> Message-ID: On Tue, 12 Nov 2024 18:54:30 GMT, Chris Plummer wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: >> >> - Merge branch 'master' into SuppressWarningsCleanup-serviceability >> - Update copyright years. >> - Merge branch 'master' into SuppressWarningsCleanup-serviceability >> - Merge branch 'master' into SuppressWarningsCleanup-serviceability >> - Remove unnecessary @SuppressWarnings annotations. > > How were these discovered and what testing did you do? Hi @plummercj, > How were these discovered See [this thread](https://mail.openjdk.org/pipermail/compiler-dev/2024-November/028573.html). There is a proposal to add a new compiler lint warning for unnecessary `@SuppressWarnings` annotations and these were flagged by the prototype. > and what testing did you do? The only testing done was verifying that the JDK still builds and passes the Github checks without them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21857#issuecomment-2471340369 From schernyshev at openjdk.org Tue Nov 12 19:13:15 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 12 Nov 2024 19:13:15 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into JDK-8343191 > - patch reimplemented > - fix the logic that skips duplicate controller's mount points > - 8343191: Cgroup v1 subsystem fails to set subsystem path > Edit: Yet, cg v2 will get into trouble since there, for example on rootless podman on cg v2 you'd end up with this instead: > > ``` > [0.008s][trace][os,container] OSContainer::init: Initializing Container Support > [0.008s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > [0.008s][debug][os,container] Detected cgroups v2 unified hierarchy > [0.008s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/../../../../../../test > [0.008s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../../../../../../test/memory.max > [0.008s][debug][os,container] Open of file /sys/fs/cgroup/../../../../../../test/memory.max failed, No such file or directory > [0.008s][trace][os,container] Memory Limit failed: -2 > ... > [0.009s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/memory.max > [0.009s][debug][os,container] Open of file /sys/fs/cgroup/memory.max failed, No such file or directory > [0.009s][trace][os,container] Memory Limit failed: -2 > [0.009s][trace][os,container] Memory Limit is: -2 > ``` Here, the path `/sys/fs/cgroup/memory.max` would normally point to the actual memory limit inside the container. In this particular case, the directory `/sys/fs/cgroup` is empty. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2471350885 From aturbanov at openjdk.org Tue Nov 12 19:24:40 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 12 Nov 2024 19:24:40 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v7] In-Reply-To: References: Message-ID: <013IDnPHZGWmc4UzSBT7XqM75Z1A75thB8ddw7WyULs=.66fd0968-f736-48c3-8aaf-d50d1d115b1f@github.com> On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > fix copyright src/java.base/share/classes/java/lang/StringLatin1.java line 833: > 831: assert index >= 0 && index + 3 < length(val) : "Trusted caller missed bounds check"; > 832: // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores. > 833: long offset = (long) Unsafe.ARRAY_BYTE_BASE_OFFSET + index; Suggestion: long offset = (long) Unsafe.ARRAY_BYTE_BASE_OFFSET + index; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1838642848 From sspitsyn at openjdk.org Tue Nov 12 19:26:13 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 12 Nov 2024 19:26:13 GMT Subject: RFR: 8343781: Add since checker test to the Serviceability area modules In-Reply-To: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> References: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Message-ID: On Fri, 8 Nov 2024 15:20:00 GMT, Nizar Benalla wrote: > Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Serviceability area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. > > The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. > > The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. > > TIA test/jdk/tools/sincechecker/modules/jdk.jconsole/JdkJconsoleCheckSince.java line 29: > 27: * @summary Test for @since in jdk.jconsole module > 28: * @library /test/lib /test/jdk/tools/sincechecker > 29: * @run main SinceChecker jdk.jartool Q: Should it be `jdk.console` instead of `jdk.jartool`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21983#discussion_r1838642855 From sgehwolf at openjdk.org Tue Nov 12 19:43:28 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 12 Nov 2024 19:43:28 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 19:09:54 GMT, Sergey Chernyshev wrote: > > Edit: Yet, cg v2 will get into trouble since there, for example on rootless podman on cg v2 you'd end up with this instead: > > ``` > > [0.008s][trace][os,container] OSContainer::init: Initializing Container Support > > [0.008s][debug][os,container] Detected optional pids controller entry in /proc/cgroups > > [0.008s][debug][os,container] Detected cgroups v2 unified hierarchy > > [0.008s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/../../../../../../test > > [0.008s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../../../../../../test/memory.max > > [0.008s][debug][os,container] Open of file /sys/fs/cgroup/../../../../../../test/memory.max failed, No such file or directory > > [0.008s][trace][os,container] Memory Limit failed: -2 > > ... > > [0.009s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/memory.max > > [0.009s][debug][os,container] Open of file /sys/fs/cgroup/memory.max failed, No such file or directory > > [0.009s][trace][os,container] Memory Limit failed: -2 > > [0.009s][trace][os,container] Memory Limit is: -2 > > ``` > > Here, the path `/sys/fs/cgroup/memory.max` would normally point to the actual memory limit inside the container. In this particular case, the directory `/sys/fs/cgroup` is empty. Yes. I believe we need to issue a `warning` log message if the `cgroup_path` includes `../` mentioning that memory limits might be wrong. There is nothing more we can do here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2471414814 From cjplummer at openjdk.org Tue Nov 12 19:49:36 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 12 Nov 2024 19:49:36 GMT Subject: RFR: 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) [v3] In-Reply-To: <_4If4-yI_2rJlVYS-46qWRN0jioXUaTQss5kwiKOZKA=.81964925-b455-49a3-b226-29a3c5052b35@github.com> References: <_4If4-yI_2rJlVYS-46qWRN0jioXUaTQss5kwiKOZKA=.81964925-b455-49a3-b226-29a3c5052b35@github.com> Message-ID: On Fri, 8 Nov 2024 19:07:34 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into SuppressWarningsCleanup-serviceability > - Update copyright years. > - Merge branch 'master' into SuppressWarningsCleanup-serviceability > - Merge branch 'master' into SuppressWarningsCleanup-serviceability > - Remove unnecessary @SuppressWarnings annotations. Marked as reviewed by cjplummer (Reviewer). Ok. I suppose this is really only a build concern and not a testing concern, so passing the builds should be enough. ------------- PR Review: https://git.openjdk.org/jdk/pull/21857#pullrequestreview-2430534537 PR Comment: https://git.openjdk.org/jdk/pull/21857#issuecomment-2471425071 From sgehwolf at openjdk.org Tue Nov 12 19:53:42 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 12 Nov 2024 19:53:42 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into JDK-8343191 > - patch reimplemented > - fix the logic that skips duplicate controller's mount points > - 8343191: Cgroup v1 subsystem fails to set subsystem path We really need to consider adding container tests for this use-case. Perhaps we can require root perms for it. The tricky part would be adding appropriate synchronization for the cgroup move of the shell process and subsequent `java` runs. src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54: > 52: ss.print_raw(_mount_point); > 53: if (strcmp(_root, "/") == 0) { > 54: // host processes / containers w/private cgroup namespace Suggestion: // host processes and containers with cgroupns=private src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 62: > 60: // containers only, warn if doesn't match > 61: log_warning(os, container)("Cgroup v1 controller (%s) mounting root [%s] doesn't match cgroup [%s]", > 62: _mount_point, _root, cgroup_path); Why this warning? It appears it would make more sense to produce this warning when `cgroup_path` contains `../` and falling back to the `mount_path` for the subsystem path which indicates we have a `cgroupns=private` deployment on CG v1, but would likely get away with it since `memory.limit_in_bytes` will be present at the mount root. If `cgroup_path` doesn't contain `../` we should append the `cgroup_path` to the `_mount_point` similar to what we do for cg v2. In the cloudflare case we'd end up with a subsystem path of `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c`. Since the `cgroup_path != _root` we trigger path adjustment increasing the chance to detect any lower limit in any of the paths down to the mount point. src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 46: > 44: } > 45: > 46: public void setPath(String cgroupPath) { This should behave the same as Hotspot and also append the cgroup path to the mount point. Then let [JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) kick in to reduce it down to the mount point (if necessary). ------------- PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2430488512 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1838641975 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1838656361 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1838666453 From sgehwolf at openjdk.org Tue Nov 12 19:53:42 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 12 Nov 2024 19:53:42 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 14:59:41 GMT, Sergey Chernyshev wrote: > > The JBS issue doesn't mention `NullPointerException`. It would be good to list the observed NPE issue. > > Example for NPE: > > ``` > public class Test { > public static void main(String[] args) { > java.lang.management.ManagementFactory.getPlatformMBeanServer(); > System.out.println("PASSED."); > } > } > ``` > > Script (cg v1): > > ``` > sudo docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --volume=./classes:/classes:ro --memory 400m ubuntu:latest \ > sh -c "sleep 10 ; /jdk/bin/java -cp .:/classes Test" & > sleep 10; > HOSTPID=$(sudo ps -ef | awk '/jdk/bin/java/ && !/docker/ && !/awk/ { print $2 }') > echo $HOSTPID | sudo tee /sys/fs/cgroup/memory/test/cgroup.procs > /dev/null > sleep 10 > ``` > > Result (cg v1 before patch): > > ``` > Exception in thread "main" java.lang.NullPointerException > at java.base/java.util.Objects.requireNonNull(Objects.java:220) > at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:296) > at java.base/java.nio.file.Path.of(Path.java:148) > at java.base/java.nio.file.Paths.get(Paths.java:69) > at java.base/jdk.internal.platform.CgroupUtil.lambda$readStringValue$0(CgroupUtil.java:67) > at java.base/java.security.AccessController.doPrivileged(AccessController.java:571) > at java.base/jdk.internal.platform.CgroupUtil.readStringValue(CgroupUtil.java:69) > at java.base/jdk.internal.platform.CgroupSubsystemController.getStringValue(CgroupSubsystemController.java:65) > at java.base/jdk.internal.platform.CgroupSubsystemController.getLongValue(CgroupSubsystemController.java:124) > at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getLongValue(CgroupV1Subsystem.java:190) > at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getHierarchical(CgroupV1Subsystem.java:160) > at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.initSubSystem(CgroupV1Subsystem.java:85) > at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getInstance(CgroupV1Subsystem.java:61) > at java.base/jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:119) > at java.base/jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:89) > at java.base/jdk.internal.platform.CgroupMetrics.getInstance(CgroupMetrics.java:198) > at java.base/jdk.internal.platform.SystemMetrics.instance(SystemMetrics.java:29) > at java.base/jdk.internal.platform.Metrics.systemMetrics(Metrics.java:58) > at java.base/jdk.internal.platform.Container.metrics(Container.java:43) > at jdk.management/com.sun.management.internal.OperatingSystemImpl.(OperatingSystemImpl.java:175) > at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl.getOperatingSystemMXBean(PlatformMBeanProviderImpl.java:316) > at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl$4.nameToMBeanMap(PlatformMBeanProviderImpl.java:235) > at java.management/java.lang.management.ManagementFactory.lambda$getPlatformMBeanServer$0(ManagementFactory.java:489) > at java.base/java.util.stream.ReferencePipeline$7$1FlatMap.accept(ReferencePipeline.java:289) > at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197) > at java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1788) > at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570) > at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560) > at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153) > at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176) > at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265) > at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:636) > at java.management/java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:490) > at Test.main(Test.java:3) > ``` Thanks! > After patch: > > ``` > [0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/test] > [0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/] > [0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/] > Nov 12, 2024 1:14:11 PM jdk.internal.platform.cgroupv1.CgroupV1SubsystemController setPath > WARNING: Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/test]. > PASSED. > ``` > > In cg v2 the NPE is not observed. > > > > Only when docker fails to mount the cgroup while moving process to an outer group or a sibling group. It's probably not the case with CloudFoundry. > > > > > > The bug suggests it's a cg v1 only problem, but I'm able to reproduce in cg v2 too. We should handle both cases more gracefully. > > what gets reproduced in cg v2 is in fact a different issue, the cgroup files are not mapped inside the container. Nothing can be done in Java to overcome this. There are no files in /sys/fs/cgroup. Yes. A warning in that case would be good. > The only workaround is --cgroupns=host, then the correct limits are displayed. Right. We should aim for cg v1 to behave similar to this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2471433485 From schernyshev at openjdk.org Tue Nov 12 19:56:25 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 12 Nov 2024 19:56:25 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v4] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp Co-authored-by: Severin Gehwolf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/3bb779af..c808ad49 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From amenkov at openjdk.org Tue Nov 12 20:27:04 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 12 Nov 2024 20:27:04 GMT Subject: Integrated: 8343344: Windows attach logic failed to handle a failed open on a pipe In-Reply-To: References: Message-ID: On Tue, 5 Nov 2024 00:42:23 GMT, Alex Menkov wrote: > The fix adds correct handling of "could not open pipe" errors in attach listener instead of assert which causes target VM crash. > > testing: tier1,tier2,hs-tier5-svc This pull request has now been integrated. Changeset: a4e2c208 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/a4e2c20849008d5b560f94b58fe70ef8e58c8d4c Stats: 27 lines in 2 files changed: 14 ins; 0 del; 13 mod 8343344: Windows attach logic failed to handle a failed open on a pipe Reviewed-by: kevinw, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/21888 From duke at openjdk.org Tue Nov 12 20:39:55 2024 From: duke at openjdk.org (Larry Cable) Date: Tue, 12 Nov 2024 20:39:55 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v4] In-Reply-To: References: Message-ID: > the implementation I originally provided does not in fact solve the issue! > > the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). > > "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach > handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. > > with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). > > in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. > > In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". > > In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". > > since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). > > thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. > > thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. > > therefore an "attacher" has two choices when attempting to attach: > > - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) > - this works with both peers and descendants > > - use /tmp > - this only works if the "attacher" and "attachee" share a /tmp in common > > the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. > > In these circumstances, the "attacher" can only resort to /tmp wh... Larry Cable has updated the pull request incrementally with one additional commit since the last revision: JDK-8342449: minor changes in response to previous review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21688/files - new: https://git.openjdk.org/jdk/pull/21688/files/2e89bd53..7f43e376 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21688&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21688&range=02-03 Stats: 11 lines in 1 file changed: 0 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/21688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21688/head:pull/21688 PR: https://git.openjdk.org/jdk/pull/21688 From almatvee at openjdk.org Tue Nov 12 21:24:37 2024 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 12 Nov 2024 21:24:37 GMT Subject: RFR: 8342682: Errors related to unused code on Windows after 8339120 in dt_shmem jdwp security and jpackage [v7] In-Reply-To: References: Message-ID: On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters wrote: >> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Merge branch 'openjdk:master' into unused > - Neater warning silencer in proc_md.h > - Revert _WIN32 workaround in log_messages.c > - Copyright in VersionInfo.cpp > - Remove neutralLangId in VersionInfo.cpp > - Remove global memHandle, would've liked to keep it as a comment :( > - Merge branch 'master' into unused > - 8342682 jpackage changes looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2430719530 From schernyshev at openjdk.org Tue Nov 12 23:33:33 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Tue, 12 Nov 2024 23:33:33 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 19:41:50 GMT, Severin Gehwolf wrote: >> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8343191 >> - patch reimplemented >> - fix the logic that skips duplicate controller's mount points >> - 8343191: Cgroup v1 subsystem fails to set subsystem path > > src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 46: > >> 44: } >> 45: >> 46: public void setPath(String cgroupPath) { > > This should behave the same as Hotspot and also append the cgroup path to the mount point. Then let [JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) kick in to reduce it down to the mount point (if necessary). Correct. I double checked the behavior in cg v2: sudo cgcreate -g memory:/test sudo cgcreate -g memory:/test/test sudo cgset -r memory.max=50m test sudo cgset -r memory.swap.max=0 test sudo cgset -r memory.max=100m test/test sudo cgset -r memory.swap.max=0 test/test with the above setup, allocations smaller than the outer group size will work, bigger will be oom-killed. $ sudo cgexec -g memory:/test/test sh -c "head -c 45m /dev/zero | tail | wc -c" 47185920 $ sudo cgexec -g memory:/test/test sh -c "head -c 55m /dev/zero | tail | wc -c" 0 Killed I'll update the PR next week. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1838979707 From sspitsyn at openjdk.org Tue Nov 12 23:33:33 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 12 Nov 2024 23:33:33 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v4] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 20:39:55 GMT, Larry Cable wrote: >> the implementation I originally provided does not in fact solve the issue! >> >> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). >> >> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach >> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. >> >> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). >> >> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. >> >> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". >> >> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". >> >> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). >> >> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. >> >> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. >> >> therefore an "attacher" has two choices when attempting to attach: >> >> - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) >> - this works with both peers and descendants >> >> - use /tmp >> - this only works if the "attacher" and "attachee" share a /tmp in common >> >> the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. >> >> I... > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8342449: minor changes in response to previous review comments It looks okay to me. But I've posted one question/request. We may need to file an RFE on it. What mach5 tests were run to make sure the fix caused no regression? ------------- PR Review: https://git.openjdk.org/jdk/pull/21688#pullrequestreview-2431038648 From sspitsyn at openjdk.org Tue Nov 12 23:33:33 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 12 Nov 2024 23:33:33 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v3] In-Reply-To: References: Message-ID: <6g2vMdADvwrnh8Kq_vXweS6SlJ9-h69-c3bzcYN9kik=.ab09fe57-e3e0-4777-aaf8-b13e20606a2c@github.com> On Thu, 7 Nov 2024 04:48:28 GMT, Serguei Spitsyn wrote: >> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8342449: fixed missing param in throws msg and renamed local var > > src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 268: > >> 266: * however we can also check the target pid's signal masks to see if it catches SIGQUIT and only do so if in >> 267: * fact it does ... this reduces the risk of killing an innocent process in the current ns as opposed to >> 268: * attaching to the actual target JVM ... c.f: checkCatchesAndSendQuitTo() below. > > This still looks pretty risky and dangerous. I'm thinking if it'd make sense to check that the target process is a VM process. At least, we know how VM processes can use the signal mask. Another concern is that the target VM process might be not exactly the same VM the client was expecting to attach. I don't know what can be done to ensure this correctness. It should be okay to file a bug/rfe on this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1838967163 From swen at openjdk.org Tue Nov 12 23:34:48 2024 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 12 Nov 2024 23:34:48 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v8] In-Reply-To: References: Message-ID: > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/lang/StringLatin1.java Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22027/files - new: https://git.openjdk.org/jdk/pull/22027/files/980cb229..e66578ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22027.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027 PR: https://git.openjdk.org/jdk/pull/22027 From larry.cable at oracle.com Tue Nov 12 23:45:51 2024 From: larry.cable at oracle.com (Laurence Cable) Date: Tue, 12 Nov 2024 15:45:51 -0800 Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v3] In-Reply-To: <6g2vMdADvwrnh8Kq_vXweS6SlJ9-h69-c3bzcYN9kik=.ab09fe57-e3e0-4777-aaf8-b13e20606a2c@github.com> References: <6g2vMdADvwrnh8Kq_vXweS6SlJ9-h69-c3bzcYN9kik=.ab09fe57-e3e0-4777-aaf8-b13e20606a2c@github.com> Message-ID: <3a73aaa6-628d-46fe-affa-44cdff294a4a@oracle.com> On 11/12/24 3:33 PM, Serguei Spitsyn wrote: > On Thu, 7 Nov 2024 04:48:28 GMT, Serguei Spitsyn wrote: > >>> Larry Cable has updated the pull request incrementally with one additional commit since the last revision: >>> >>> JDK-8342449: fixed missing param in throws msg and renamed local var >> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java line 268: >> >>> 266: * however we can also check the target pid's signal masks to see if it catches SIGQUIT and only do so if in >>> 267: * fact it does ... this reduces the risk of killing an innocent process in the current ns as opposed to >>> 268: * attaching to the actual target JVM ... c.f: checkCatchesAndSendQuitTo() below. >> This still looks pretty risky and dangerous. I'm thinking if it'd make sense to check that the target process is a VM process. At least, we know how VM processes can use the signal mask. Another concern is that the target VM process might be not exactly the same VM the client was expecting to attach. I don't know what can be done to ensure this correctness. > It should be okay to file a bug/rfe on this. it is not feasible to introspect on the target process to determine if it is a JVM or not, this is the best case not to send SIGQUIT to a process that is neither catching nor blocking it, where the default is to terminate it! > > ------------- > > PR Review Comment: https://git.openjdk.org/jdk/pull/21688#discussion_r1838967163 From larry.cable at oracle.com Tue Nov 12 23:51:27 2024 From: larry.cable at oracle.com (Laurence Cable) Date: Tue, 12 Nov 2024 15:51:27 -0800 Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v3] In-Reply-To: <3a73aaa6-628d-46fe-affa-44cdff294a4a@oracle.com> References: <6g2vMdADvwrnh8Kq_vXweS6SlJ9-h69-c3bzcYN9kik=.ab09fe57-e3e0-4777-aaf8-b13e20606a2c@github.com> <3a73aaa6-628d-46fe-affa-44cdff294a4a@oracle.com> Message-ID: <488af0ee-0052-4d04-a202-49e34a4c9c21@oracle.com> I should also note that on other *nix'es (where there is no /proc to introspect) the default behavior is simply to send the QUIT regardless. In the case of Linux, this addition obviates the chance of an attach killing the target should it not be catching QUIT! On 11/12/24 3:45 PM, Laurence Cable wrote: > > > > On 11/12/24 3:33 PM, Serguei Spitsyn wrote: >> On Thu, 7 Nov 2024 04:48:28 GMT, Serguei Spitsyn >> wrote: >> >>>> Larry Cable has updated the pull request incrementally with one >>>> additional commit since the last revision: >>>> >>>> ?? JDK-8342449: fixed missing param in throws msg and renamed local >>>> var >>> src/jdk.attach/linux/classes/sun/tools/attach/VirtualMachineImpl.java >>> line 268: >>> >>>> 266:????????? * however we can also check the target pid's signal >>>> masks to see if it catches SIGQUIT and only do so if in >>>> 267:????????? * fact it does ... this reduces the risk of killing >>>> an innocent process in the current ns as opposed to >>>> 268:????????? * attaching to the actual target JVM ... c.f: >>>> checkCatchesAndSendQuitTo() below. >>> This still looks pretty risky and dangerous. I'm thinking if it'd >>> make sense to check that the target process is a VM process. At >>> least, we know how VM processes can use the signal mask. Another >>> concern is that the target VM process might be not exactly the same >>> VM the client was expecting to attach. I don't know what can be done >>> to ensure this correctness. >> It should be okay to file a bug/rfe on this. > > it is not feasible to introspect on the target process to determine if > it is a JVM or not, this is the best case not to send SIGQUIT to a > process that is neither catching nor blocking it, where the default is > to terminate it! >> >> ------------- >> >> PR Review Comment: >> https://git.openjdk.org/jdk/pull/21688#discussion_r1838967163 > From sspitsyn at openjdk.org Wed Nov 13 02:21:48 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 13 Nov 2024 02:21:48 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid In-Reply-To: <488af0ee-0052-4d04-a202-49e34a4c9c21@oracle.com> References: <488af0ee-0052-4d04-a202-49e34a4c9c21@oracle.com> Message-ID: On Tue, 12 Nov 2024 23:52:35 GMT, Laurence Cable wrote: > t is not feasible to introspect on the target process to determine if it is a JVM or not, this is the best case not to send SIGQUIT to a process that is neither catching nor blocking it, where the default is to terminate it! Even if the target process is not terminated with the SIGQUIT it would still be more safe to make sure it is a VM process before sending the SIGQUIT signal. I wonder if the JDP (Java Discovery Protocol) can be used. Anyway, this discussion can be separated from this fix. There is still this question: > What mach5 tests were run to make sure the fix caused no regression? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21688#issuecomment-2472207465 From alanb at openjdk.org Wed Nov 13 07:40:55 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 13 Nov 2024 07:40:55 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v8] In-Reply-To: References: Message-ID: <6bApISnYnGNmKlxN1xUIGgD6t1Ncf1EtAUvD8lYteE4=.39eb53a0-9643-4dcb-a133-bd80297389fd@github.com> On Tue, 12 Nov 2024 23:34:48 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/StringLatin1.java > > Co-authored-by: Andrey Turbanov Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2432158366 From pminborg at openjdk.org Wed Nov 13 07:48:32 2024 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 13 Nov 2024 07:48:32 GMT Subject: RFR: 8343984: Fix Unsafe address overflow [v8] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 23:34:48 GMT, Shaojin Wen wrote: >> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/classes/java/lang/StringLatin1.java > > Co-authored-by: Andrey Turbanov Great with the additional fixes. ------------- Marked as reviewed by pminborg (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2432171697 From ihse at openjdk.org Wed Nov 13 09:47:13 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 13 Nov 2024 09:47:13 GMT Subject: Integrated: 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com> Message-ID: On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie wrote: > This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479). > > This is the summary of JEP 479: >> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release. This pull request has now been integrated. Changeset: 79345bbb Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/79345bbbae2564f9f523859d1227a1784293b20f Stats: 1922 lines in 85 files changed: 82 ins; 1573 del; 267 mod 8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port Reviewed-by: kbarrett, kvn, stuefe, shade, erikj ------------- PR: https://git.openjdk.org/jdk/pull/21744 From coleenp at openjdk.org Wed Nov 13 11:47:54 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 13 Nov 2024 11:47:54 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests Message-ID: Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. Tested with tier1-4. ------------- Commit messages: - Remove some more includes. - 8341916: Remove ProtectionDomain related hotspot code and tests Changes: https://git.openjdk.org/jdk/pull/22064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341916 Stats: 1267 lines in 42 files changed: 1 ins; 1104 del; 162 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From shade at openjdk.org Wed Nov 13 12:48:04 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 13 Nov 2024 12:48:04 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Mon, 4 Nov 2024 19:52:30 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: > > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates > > Reviewed-by: kdnilsen > - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational > > Reviewed-by: ysr > - 8342919: GenShen: Fix whitespace > > Reviewed-by: xpeng, kdnilsen > - 8342927: GenShen: Guarantee slices of time for coalesce and filling > > Reviewed-by: kdnilsen > - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java > > Reviewed-by: kdnilsen, ysr > - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode > > Reviewed-by: wkemper > - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 I read about half, here is a dump of my current observations. I'll read the second half a bit later. src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 474: > 472: // elision safe. > 473: return; > 474: } Why is this safe for Shenandoah? I suspect it needs `CardTableBarrierSet::on_slowpath_allocation_exit` to work. `G1BarrierSetC2` gets it by subclassing `CardTableBarrierSetC2`. But `ShenandoahBarrierSetC2` does not. Should it? src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 67: > 65: _region_data[i].clear(); > 66: } > 67: #endif I understand this is to make sure `union_tag` works well. But why don't we extend `clear` to initialize all fields, and do this block without `ASSERT`? This does not look like frequently used path. Generally, doing these inits only for debug modes might hide some assertion failures that would indicate a problem in product builds. src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 118: > 116: #ifdef ASSERT > 117: assert(_union_tag != is_uninitialized, "Cannot fetch region from uninialized RegionData"); > 118: #endif Style: No point in wrapping single-line `assert`-s in `#ifdef ASSERT`. src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp line 238: > 236: #define shenandoah_assert_control_or_vm_thread_at_safepoint() > 237: #define shenandoah_assert_generational() > 238: #define shenandoah_assert_generations_reconciled() \ There seems to be dangling `` on this line. src/hotspot/share/gc/shenandoah/shenandoahCardStats.hpp line 47: > 45: CARD_STAT_UPDATE_REFS, > 46: MAX_CARD_STAT_LOG_TYPE > 47: }; These are in global namespace. There is a risk they would clash with some other symbol elsewhere. Do you need them to be global, or can they go into `ShenandoahCardStats`? src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp line 77: > 75: return reinterpret_cast(context); > 76: } else { > 77: if (_heap->is_concurrent_weak_root_in_progress()) { Comprehension check: We flips this because in generational mode we _can_ have both concurrent weak roots and concurrent mark in progress at the same time, and we need to prioritize evacs, right? src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 50: > 48: switch (generation_type) { \ > 49: case NON_GEN: \ > 50: return prefix " (NON-GENERATIONAL)" postfix; \ In the interest of keeping the non-generational Shenandoah logging intact, should we drop ` (NON-GENERATIONAL)` here? src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp line 83: > 81: void VM_ShenandoahInitMark::doit() { > 82: ShenandoahGCPauseMark mark(_gc_id, "Init Mark", SvcGCMarker::CONCURRENT); > 83: set_active_generation(); Why is it here, and not down in `entry_*` methods, probably in helper classes? src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp line 41: > 39: // - VM_ShenandoahInitUpdateRefs: initiate update references > 40: // - VM_ShenandoahFinalUpdateRefs: finish up update references > 41: // - VM_ShenandoahFinalRoots If we add it here, let's provide a comment: // - VM_ShenandoahFinalRoots: finish up the roots, shortcut cycle src/hotspot/share/jfr/metadata/metadata.xml line 1221: > 1219: > 1220: > 1221: Not sure if we _need_ this JFR event as part of GenShen? This bit is what forces us to do CSR, right? test/hotspot/jtreg/ProblemList.txt line 98: > 96: gc/TestAlwaysPreTouchBehavior.java#Epsilon 8334513 generic-all > 97: gc/stress/gclocker/TestExcessGCLockerCollections.java 8229120 generic-all > 98: This change is unnecessary. test/hotspot/jtreg/gc/shenandoah/oom/TestThreadFailure.java line 61: > 59: // case that the previously instantiated NastyThread accumulated more than SheanndoahNoProgressThreshold > 60: // unproductive GC cycles before failing, the main thread may not try a Full GC before it experiences > 61: // OutOfMemoryError exception. Do you really need comments in this test? ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2429755115 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1839969170 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1839985542 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840008742 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840173090 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840153151 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840187886 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840195628 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840199905 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840201386 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1840096925 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1838665756 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1838196649 From kevinw at openjdk.org Wed Nov 13 13:47:13 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 13 Nov 2024 13:47:13 GMT Subject: RFR: 8344105: Remove SecurityManager and related calls from jdk.attach and jdk.hotspot.agent Message-ID: Remove redundant SecurityManager, AccessController references (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). ------------- Commit messages: - Property fetch update - 8344105: Remove SecurityManager and related calls from jdk.attach and jdk.hotspot.agent Changes: https://git.openjdk.org/jdk/pull/22067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344105 Stats: 77 lines in 9 files changed: 0 ins; 67 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/22067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22067/head:pull/22067 PR: https://git.openjdk.org/jdk/pull/22067 From larry.cable at oracle.com Wed Nov 13 15:55:33 2024 From: larry.cable at oracle.com (Laurence Cable) Date: Wed, 13 Nov 2024 07:55:33 -0800 Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid In-Reply-To: References: <488af0ee-0052-4d04-a202-49e34a4c9c21@oracle.com> Message-ID: <295f635b-3b9d-4347-a91c-1a31764a21af@oracle.com> On 11/12/24 6:21 PM, Serguei Spitsyn wrote: > On Tue, 12 Nov 2024 23:52:35 GMT, Laurence Cable wrote: > >> t is not feasible to introspect on the target process to determine if > it is a JVM or not, this is the best case not to send SIGQUIT to a > process that is neither catching nor blocking it, where the default is > to terminate it! > > Even if the target process is not terminated with the SIGQUIT it would still be more safe to make sure it is a VM process before sending the SIGQUIT signal. I wonder if the JDP (Java Discovery Protocol) can be used. it cant since its optional... > Anyway, this discussion can be separated from this fix. > > There is still this question: >> What mach5 tests were run to make sure the fix caused no regression? > ------------- > > PR Comment: https://git.openjdk.org/jdk/pull/21688#issuecomment-2472207465 From acobbs at openjdk.org Wed Nov 13 17:00:45 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 13 Nov 2024 17:00:45 GMT Subject: RFR: 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) [v3] In-Reply-To: <_4If4-yI_2rJlVYS-46qWRN0jioXUaTQss5kwiKOZKA=.81964925-b455-49a3-b226-29a3c5052b35@github.com> References: <_4If4-yI_2rJlVYS-46qWRN0jioXUaTQss5kwiKOZKA=.81964925-b455-49a3-b226-29a3c5052b35@github.com> Message-ID: On Fri, 8 Nov 2024 19:07:34 GMT, Archie Cobbs wrote: >> Please review this patch which removes unnecessary `@SuppressWarnings` annotations. > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'master' into SuppressWarningsCleanup-serviceability > - Update copyright years. > - Merge branch 'master' into SuppressWarningsCleanup-serviceability > - Merge branch 'master' into SuppressWarningsCleanup-serviceability > - Remove unnecessary @SuppressWarnings annotations. Thanks for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21857#issuecomment-2474200300 From acobbs at openjdk.org Wed Nov 13 17:00:45 2024 From: acobbs at openjdk.org (Archie Cobbs) Date: Wed, 13 Nov 2024 17:00:45 GMT Subject: Integrated: 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) In-Reply-To: References: Message-ID: On Sat, 2 Nov 2024 16:04:10 GMT, Archie Cobbs wrote: > Please review this patch which removes unnecessary `@SuppressWarnings` annotations. This pull request has now been integrated. Changeset: a5f11b5f Author: Archie Cobbs URL: https://git.openjdk.org/jdk/commit/a5f11b5f775be6c1d9593562ba65912261efdf52 Stats: 35 lines in 16 files changed: 0 ins; 16 del; 19 mod 8343483: Remove unnecessary @SuppressWarnings annotations (serviceability) Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/21857 From jjg at openjdk.org Wed Nov 13 18:11:11 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 13 Nov 2024 18:11:11 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Without looking in detail at the changes, this is indeed a welcome and long-overdue change! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474339519 From ihse at openjdk.org Wed Nov 13 18:11:11 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 13 Nov 2024 18:11:11 GMT Subject: RFR: 8344056: Use markdown format for man pages Message-ID: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. ------------- Commit messages: - Replace tabs with spaces - Remove logic for copying .1 man pages - Insert GPL header - Add missing Windows man pages for kerberos and accessibility - Replace generated troff man pages with markdown version Changes: https://git.openjdk.org/jdk/pull/22081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344056 Stats: 41443 lines in 65 files changed: 18943 ins; 22500 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081 PR: https://git.openjdk.org/jdk/pull/22081 From wkemper at openjdk.org Wed Nov 13 19:32:53 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 19:32:53 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: - Merge branch 'merge-latest' into great-genshen-pr-redux - Use new CompactHeader forwarding APIs in generational mode - Merge remote-tracking branch 'jdk/master' into merge-latest - Merge - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines Reviewed-by: wkemper - Merge - 8343227: GenShen: Fold resource mark into management of preselected regions Reviewed-by: kdnilsen - Merge openjdk/jdk tip into great-genshen-pr-redux - Merge remote-tracking branch 'jdk/master' into merge-latest - Merge remote-tracking branch 'jdk/master' into merge-latest - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=06 Stats: 22977 lines in 231 files changed: 21234 ins; 886 del; 857 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From kevinw at openjdk.org Wed Nov 13 20:21:08 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 13 Nov 2024 20:21:08 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. I think this means the one-true-master copy of a man page is now the public .md file. All contributors can now change and improve man pages, and would be expected to make necessary man page updates when making other changes. (Which is great, I just didn't see it being explicitly said.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474701337 From amenkov at openjdk.org Wed Nov 13 20:29:29 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 13 Nov 2024 20:29:29 GMT Subject: RFR: 8344105: Remove SecurityManager and related calls from jdk.attach and jdk.hotspot.agent In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:53:26 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22067#pullrequestreview-2434341764 From cstein at openjdk.org Wed Nov 13 20:56:51 2024 From: cstein at openjdk.org (Christian Stein) Date: Wed, 13 Nov 2024 20:56:51 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. So glad to see progress here! https://github.com/openjdk/jdk/blob/1484153c1a092cefc20270b35aa1e508280843a4/test/langtools/jdk/javadoc/tool/CheckManPageOptions.java#L141 should read `return findRootDir().resolve("src/jdk.javadoc/share/man/javadoc.md");` now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474760888 From jjg at openjdk.org Wed Nov 13 21:21:32 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Wed, 13 Nov 2024 21:21:32 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 20:17:24 GMT, Kevin Walls wrote: > I think this means the one-true-master copy of a man page is now the public .md file. All contributors can now change and improve man pages, and would be expected to make necessary man page updates when making other changes. (Which is great, I just didn't see it being explicitly said.) Yes, related: Non-trivial updates to these pages should be approved in a CSR, maybe along with any code changes that may make such an update necessary. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474804913 From iklam at openjdk.org Wed Nov 13 21:23:37 2024 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 13 Nov 2024 21:23:37 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v11] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 178 commits: - Merge branch 'master' into jep-483-candidate - fixed merge with UseCompactObjectHeaders - Merge branch 'master' into jep-483-candidate - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - reverted changes in modules.cpp to make it easy to merge with mainline - ... and 168 more: https://git.openjdk.org/jdk/compare/5e01c40b...fc86c00e ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=10 Stats: 7192 lines in 107 files changed: 6358 ins; 513 del; 321 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From sspitsyn at openjdk.org Wed Nov 13 21:25:23 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 13 Nov 2024 21:25:23 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid In-Reply-To: <295f635b-3b9d-4347-a91c-1a31764a21af@oracle.com> References: <295f635b-3b9d-4347-a91c-1a31764a21af@oracle.com> Message-ID: On Wed, 13 Nov 2024 15:57:35 GMT, Laurence Cable wrote: > it cant since its optional... You are right. The `ldd` could be used to check for `libjvm` but `libjvm` can be statically linked. So, let's skip this for now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21688#issuecomment-2474810484 From dholmes at openjdk.org Wed Nov 13 21:35:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 13 Nov 2024 21:35:39 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Great to finally see this happen! Just one glitch with the GPL headers. Thanks src/java.base/share/man/java.md line 9: > 7: # published by the Free Software Foundation. Oracle designates this > 8: # particular file as subject to the "Classpath" exception as provided > 9: # by Oracle in the LICENSE file that accompanied this code. Documentation files should not have the Classpath exception. make/data/license-templates/gpl-header ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2434474132 PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1841189067 From cstein at openjdk.org Wed Nov 13 21:35:40 2024 From: cstein at openjdk.org (Christian Stein) Date: Wed, 13 Nov 2024 21:35:40 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. A missing `.1` to `.md` file extension change in `javadoc`'s manpage self-test `CheckManPageOptions.java` is causing the CI to fail. Details in https://github.com/openjdk/jdk/pull/22081#issuecomment-2474760888 ------------- Changes requested by cstein (Committer). PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2434491865 From cjplummer at openjdk.org Wed Nov 13 21:49:26 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 13 Nov 2024 21:49:26 GMT Subject: RFR: 8344105: Remove SecurityManager and related calls from jdk.attach and jdk.hotspot.agent In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:53:26 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22067#pullrequestreview-2434520045 From iris at openjdk.org Wed Nov 13 21:59:34 2024 From: iris at openjdk.org (Iris Clark) Date: Wed, 13 Nov 2024 21:59:34 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 21:27:02 GMT, David Holmes wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > src/java.base/share/man/java.md line 9: > >> 7: # published by the Free Software Foundation. Oracle designates this >> 8: # particular file as subject to the "Classpath" exception as provided >> 9: # by Oracle in the LICENSE file that accompanied this code. > > Documentation files should not have the Classpath exception. > > make/data/license-templates/gpl-header Agree. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1841231909 From iklam at openjdk.org Wed Nov 13 22:33:23 2024 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 13 Nov 2024 22:33:23 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. LGTM. Good to see all this code deleted. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2434607860 From wkemper at openjdk.org Wed Nov 13 23:10:51 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:10:51 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Tue, 12 Nov 2024 14:25:30 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > test/hotspot/jtreg/gc/shenandoah/oom/TestThreadFailure.java line 61: > >> 59: // case that the previously instantiated NastyThread accumulated more than SheanndoahNoProgressThreshold >> 60: // unproductive GC cycles before failing, the main thread may not try a Full GC before it experiences >> 61: // OutOfMemoryError exception. > > Do you really need comments in this test? This test was a sore spot for us and we spent quite some time to make it pass. I don't think the code is very clear on its face about what the test expects, so I'd prefer to keep this comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841302676 From swen at openjdk.org Wed Nov 13 23:21:51 2024 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 13 Nov 2024 23:21:51 GMT Subject: Integrated: 8343984: Fix Unsafe address overflow In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen wrote: > In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash. This pull request has now been integrated. Changeset: 0dab920b Author: Shaojin Wen URL: https://git.openjdk.org/jdk/commit/0dab920b70560a5aea8b068080655a292908b646 Stats: 34 lines in 11 files changed: 0 ins; 0 del; 34 mod 8343984: Fix Unsafe address overflow Reviewed-by: pminborg, alanb ------------- PR: https://git.openjdk.org/jdk/pull/22027 From wkemper at openjdk.org Wed Nov 13 23:24:32 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:24:32 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 12:23:26 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp line 238: > >> 236: #define shenandoah_assert_control_or_vm_thread_at_safepoint() >> 237: #define shenandoah_assert_generational() >> 238: #define shenandoah_assert_generations_reconciled() \ > > There seems to be dangling `` on this line. Good catch. > src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp line 77: > >> 75: return reinterpret_cast(context); >> 76: } else { >> 77: if (_heap->is_concurrent_weak_root_in_progress()) { > > Comprehension check: We flips this because in generational mode we _can_ have both concurrent weak roots and concurrent mark in progress at the same time, and we need to prioritize evacs, right? Correct. Although no old marking threads will ever run during a young collection. > src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 50: > >> 48: switch (generation_type) { \ >> 49: case NON_GEN: \ >> 50: return prefix " (NON-GENERATIONAL)" postfix; \ > > In the interest of keeping the non-generational Shenandoah logging intact, should we drop ` (NON-GENERATIONAL)` here? No objections here. @ysramakrishna , @kdnilsen ? > src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp line 83: > >> 81: void VM_ShenandoahInitMark::doit() { >> 82: ShenandoahGCPauseMark mark(_gc_id, "Init Mark", SvcGCMarker::CONCURRENT); >> 83: set_active_generation(); > > Why is it here, and not down in `entry_*` methods, probably in helper classes? I think it's here for the same reason `propagate_gc_state_to_java_threads` is here. Having it here makes it easier to see that this critical synchronization step happens for every safepoint. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841308265 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841308915 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841310699 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841313192 From wkemper at openjdk.org Wed Nov 13 23:35:28 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:35:28 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 23:14:23 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahAsserts.hpp line 238: >> >>> 236: #define shenandoah_assert_control_or_vm_thread_at_safepoint() >>> 237: #define shenandoah_assert_generational() >>> 238: #define shenandoah_assert_generations_reconciled() \ >> >> There seems to be dangling `` on this line. > > Good catch. https://bugs.openjdk.org/browse/JDK-8344151 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841320809 From wkemper at openjdk.org Wed Nov 13 23:35:29 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:35:29 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Tue, 12 Nov 2024 19:41:14 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > test/hotspot/jtreg/ProblemList.txt line 98: > >> 96: gc/TestAlwaysPreTouchBehavior.java#Epsilon 8334513 generic-all >> 97: gc/stress/gclocker/TestExcessGCLockerCollections.java 8229120 generic-all >> 98: > > This change is unnecessary. https://bugs.openjdk.org/browse/JDK-8344151 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841321018 From wkemper at openjdk.org Wed Nov 13 23:35:28 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:35:28 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 11:01:59 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 118: > >> 116: #ifdef ASSERT >> 117: assert(_union_tag != is_uninitialized, "Cannot fetch region from uninialized RegionData"); >> 118: #endif > > Style: No point in wrapping single-line `assert`-s in `#ifdef ASSERT`. https://bugs.openjdk.org/browse/JDK-8344151 > src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp line 41: > >> 39: // - VM_ShenandoahInitUpdateRefs: initiate update references >> 40: // - VM_ShenandoahFinalUpdateRefs: finish up update references >> 41: // - VM_ShenandoahFinalRoots > > If we add it here, let's provide a comment: > > > // - VM_ShenandoahFinalRoots: finish up the roots, shortcut cycle https://bugs.openjdk.org/browse/JDK-8344151 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841320875 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841320596 From wkemper at openjdk.org Wed Nov 13 23:44:43 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 13 Nov 2024 23:44:43 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 10:57:08 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 67: > >> 65: _region_data[i].clear(); >> 66: } >> 67: #endif > > I understand this is to make sure `union_tag` works well. But why don't we extend `clear` to initialize all fields, and do this block without `ASSERT`? This does not look like frequently used path. Generally, doing these inits only for debug modes might hide some assertion failures that would indicate a problem in product builds. https://bugs.openjdk.org/browse/JDK-8344152 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841326159 From nbenalla at openjdk.org Thu Nov 14 00:53:08 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 14 Nov 2024 00:53:08 GMT Subject: RFR: 8343781: Add since checker test to the Serviceability area modules [v2] In-Reply-To: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> References: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Message-ID: > Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Serviceability area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. > > The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. > > The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. > > TIA Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - fix mistake in module name passed to jdk.jconsole test - Add backticks to mentions of `@since`, to avoid jtreg mistaking it with a jtreg tag Revert "remove backticks" This reverts commit 0abe3080391e83cae62253f56c28d98efa0ed253. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21983/files - new: https://git.openjdk.org/jdk/pull/21983/files/0abe3080..4aa468f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21983&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21983&range=00-01 Stats: 13 lines in 12 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/21983.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21983/head:pull/21983 PR: https://git.openjdk.org/jdk/pull/21983 From nbenalla at openjdk.org Thu Nov 14 00:53:08 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 14 Nov 2024 00:53:08 GMT Subject: RFR: 8343781: Add since checker test to the Serviceability area modules [v2] In-Reply-To: References: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Message-ID: <48pMpTmWT8Xw84ygfooxCfiQH-DPSZAmVqrEr2cQz6A=.7720d087-f08b-4ff8-a7ec-3c60c5efd7d7@github.com> On Tue, 12 Nov 2024 19:21:08 GMT, Serguei Spitsyn wrote: >> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: >> >> - fix mistake in module name passed to jdk.jconsole test >> - Add backticks to mentions of `@since`, to avoid jtreg mistaking it with a jtreg tag >> >> Revert "remove backticks" >> >> This reverts commit 0abe3080391e83cae62253f56c28d98efa0ed253. > > test/jdk/tools/sincechecker/modules/jdk.jconsole/JdkJconsoleCheckSince.java line 29: > >> 27: * @summary Test for @since in jdk.jconsole module >> 28: * @library /test/lib /test/jdk/tools/sincechecker >> 29: * @run main SinceChecker jdk.jartool > > Q: Should it be `jdk.console` instead of `jdk.jartool`? It should indeed be `jdk.console`. Fixed in [4aa468f](https://github.com/openjdk/jdk/pull/21983/commits/4aa468f0b6117879687343ecff84daf32e3a9acb), Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21983#discussion_r1841373957 From sspitsyn at openjdk.org Thu Nov 14 01:01:38 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 14 Nov 2024 01:01:38 GMT Subject: RFR: 8343781: Add since checker test to the Serviceability area modules [v2] In-Reply-To: References: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Message-ID: <1CVXjuRs5sjhajcH78x7DZtQn6NmhAxl29PjNaSjrS8=.40a6ce99-891c-4439-a956-b60d3c29ec9a@github.com> On Thu, 14 Nov 2024 00:53:08 GMT, Nizar Benalla wrote: >> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Serviceability area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. >> >> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. >> >> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - fix mistake in module name passed to jdk.jconsole test > - Add backticks to mentions of `@since`, to avoid jtreg mistaking it with a jtreg tag > > Revert "remove backticks" > > This reverts commit 0abe3080391e83cae62253f56c28d98efa0ed253. Thank you for the update. Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21983#pullrequestreview-2434766357 From prr at openjdk.org Thu Nov 14 04:37:13 2024 From: prr at openjdk.org (Phil Race) Date: Thu, 14 Nov 2024 04:37:13 GMT Subject: RFR: 8343490: Update copyright year for JDK-8341692 In-Reply-To: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> References: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> Message-ID: <9R5gF8dIqwO0TbBhICMDC7c2g4gvY0tXA82LcvmAEpI=.4159e63b-4899-48d9-9829-0f13c6307446@github.com> On Tue, 5 Nov 2024 01:41:00 GMT, SendaoYan wrote: > Hi all, > The copyright year of some files which has been changed by [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update correctly. This PR update the copyright year of [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk. FWIW this whole PR seems like a waste of a bug id. Copyright year is implied anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21891#issuecomment-2475394959 From syan at openjdk.org Thu Nov 14 06:16:22 2024 From: syan at openjdk.org (SendaoYan) Date: Thu, 14 Nov 2024 06:16:22 GMT Subject: Withdrawn: 8343490: Update copyright year for JDK-8341692 In-Reply-To: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> References: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com> Message-ID: On Tue, 5 Nov 2024 01:41:00 GMT, SendaoYan wrote: > Hi all, > The copyright year of some files which has been changed by [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update correctly. This PR update the copyright year of [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21891 From dholmes at openjdk.org Thu Nov 14 06:20:03 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 06:20:03 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. @coleenp it is great to see all this code go but I'm unclear about the uses of "protection domain" that have been removed, compared to those that still remain in the hotspot code in particular how CDS still uses it. To be fair I'm unclear what role PD still plays on the JDK side and would not be surprised if it is destined for removal at some point. How do we recognise that the remaining uses of and reference to the PD are still needed and not something we could now delete? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2475502902 From alanb at openjdk.org Thu Nov 14 07:05:23 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 07:05:23 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: <9odgI41Erhmy3c5sk7YgS_NR61BaYO933G0HwPHRJNw=.54e7cb3b-98bf-4ec8-94f7-8032b52eb773@github.com> On Thu, 14 Nov 2024 06:16:56 GMT, David Holmes wrote: > To be fair I'm unclear what role PD still plays on the JDK side and would not be surprised if it is destined for removal at some point. PD is not deprecated as PD::getCodeSource is widely used. It may be that an alternative means is introduced in the future to expose the code location but nothing specific at this time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2475563544 From dholmes at openjdk.org Thu Nov 14 07:44:30 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 07:44:30 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. This is a great cleanup! I may have missed something, but it seems to me that `java_security_AccessControlContext` is all dead code now too. Thanks src/hotspot/share/ci/ciEnv.cpp line 1613: > 1611: > 1612: // The very first entry is the InstanceKlass of the root method of the current compilation in order to get the right > 1613: // (class loader???) protection domain to load subsequent classes during replay compilation. Suggestion: simply have: // The very first entry is the InstanceKlass of the root method of the current compilation . The rest of the comment doesn't really make sense even before your change as this method basically just prints the class name src/hotspot/share/classfile/dictionary.cpp line 80: > 78: > 79: void Dictionary::Config::free_node(void* context, void* memory, Value const& value) { > 80: delete value; // Call DictionaryEntry destructor `using Value = XXX` seems like an unwanted/unnecessary abstraction in this code, because depending on what `XX` is you either will or won't need to call `delete`. That is a more general cleanup though. src/hotspot/share/classfile/javaClasses.hpp line 1545: > 1543: static int _static_security_offset; > 1544: static int _static_allow_security_offset; > 1545: static int _static_never_offset; Guess these were missed by the main PR as they are unused. :) src/hotspot/share/classfile/systemDictionary.hpp line 239: > 237: // compute java_mirror (java.lang.Class instance) for a type ("I", "[[B", "LFoo;", etc.) > 238: // Either the accessing_klass or the CL can be non-null, but not both. > 239: // callee will fill in CL from AK, if they are needed Suggestion: // Callee will fill in CL from accessing_klass, if they are needed. src/hotspot/share/logging/logTag.hpp line 163: > 161: LOG_TAG(preview) /* Trace loading of preview feature types */ \ > 162: LOG_TAG(promotion) \ > 163: LOG_TAG(protectiondomain) /* "Trace protection domain verification" */ \ Not 100% sure about this. We don't really have a policy for "deprecating" or removing log tags. I think it unlikely anyone enables this logging "just because", so it seems okay for this case. ------------- PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2435096096 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841595529 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841597831 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841688595 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841691487 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1841698260 From dholmes at openjdk.org Thu Nov 14 07:56:15 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 14 Nov 2024 07:56:15 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: <9odgI41Erhmy3c5sk7YgS_NR61BaYO933G0HwPHRJNw=.54e7cb3b-98bf-4ec8-94f7-8032b52eb773@github.com> References: <9odgI41Erhmy3c5sk7YgS_NR61BaYO933G0HwPHRJNw=.54e7cb3b-98bf-4ec8-94f7-8032b52eb773@github.com> Message-ID: On Thu, 14 Nov 2024 07:01:54 GMT, Alan Bateman wrote: > > To be fair I'm unclear what role PD still plays on the JDK side and would not be surprised if it is destined for removal at some point. > > PD is not deprecated as PD::getCodeSource is widely used. It may be that an alternative means is introduced in the future to expose the code location but nothing specific at this time. Okay but I still remain unclear about the role of PD in the VM, in particular how CDS is using it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2475647661 From kevinw at openjdk.org Thu Nov 14 08:03:39 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 14 Nov 2024 08:03:39 GMT Subject: RFR: 8344105: Remove SecurityManager and related calls from jdk.attach and jdk.hotspot.agent In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:53:26 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Thanks for the reviews. Tier1 - 3 completed, and local jtreg testing of tests that mention "attach". ------------- PR Comment: https://git.openjdk.org/jdk/pull/22067#issuecomment-2475658268 From david.holmes at oracle.com Thu Nov 14 08:28:15 2024 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Nov 2024 18:28:15 +1000 Subject: Win32AttachOperationRequest seems to be using global new? In-Reply-To: <8ec38c62-69d5-4821-b160-0148c41581ea@oracle.com> References: <8ec38c62-69d5-4821-b160-0148c41581ea@oracle.com> Message-ID: That didn't work so cc'ing serviceability-dev I think it was just an oversight. David On 14/11/2024 6:24 pm, David Holmes wrote: > It was added by JDK-8339289 so cc'ing Alex. > > David > > On 14/11/2024 5:33 pm, Julian Waters wrote: >> Bumping, I'm still curious about this issue >> >> best regards, >> Julian >> >> On Tue, Nov 12, 2024 at 10:20?PM Julian Waters >> wrote: >>> Hi all, >>> >>> Win32AttachOperationRequest is created via new, but doesn't specify a >>> custom new inside the class definition. The result seems to be that >>> we use global new on Windows: >>> >>> ?? for (int i=0; i>> ???? Win32AttachOperationRequest* op = new >>> Win32AttachOperationRequest(); >>> ?????? f1: b9 28 0d 00 00?????? mov??? ecx,0xd28 >>> ?????? f6: e8 00 00 00 00?????? call?? fb >>> >>> f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long) >>> >>> Stepping away from gcc's objdump and using the Microsoft dumpbin >>> alongside cl.exe instead, the result is this: >>> >>> ?? 0000000000000264: B9 28 0D 00 00???? mov???????? ecx,0D28h >>> ?? 0000000000000269: E8 00 00 00 00???? call??????? ??2 at YAPEAX_K@Z >>> ?? 000000000000026E: 48 89 44 24 28???? mov???????? qword ptr >>> [rsp+28h],rax >>> ?? 0000000000000273: 48 83 7C 24 28 00? cmp???????? qword ptr >>> [rsp+28h],0 >>> ?? 0000000000000279: 74 11????????????? je????????? 000000000000028C >>> ?? 000000000000027B: 48 8B 4C 24 28???? mov???????? rcx,qword ptr >>> [rsp+28h] >>> ?? 0000000000000280: E8 00 00 00 00???? call??????? ?? >>> 0Win32AttachOperationRequest@@QEAA at XZ >>> >>> undname "??2 at YAPEAX_K@Z" >>> Microsoft (R) C++ Name Undecorator >>> Copyright (C) Microsoft Corporation. All rights reserved. >>> >>> Undecoration of :- "??2 at YAPEAX_K@Z" >>> is :- "void * __ptr64 __cdecl operator new(unsigned __int64)" >>> >>> undname "??0Win32AttachOperationRequest@@QEAA at XZ" >>> Microsoft (R) C++ Name Undecorator >>> Copyright (C) Microsoft Corporation. All rights reserved. >>> >>> Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ" >>> is :- "public: __cdecl >>> Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64" >>> >>> Visual Studio, lacking the nm utility, obviously doesn't catch this. >>> What was more surprising is that the gcc Link Time check also fails >>> to catch it as well. I had to manually check the output of nm after >>> an unrelated failure and happened to stumble across the symbols _Znwy >>> and _ZdlPvy which both correspond to >>> >>> operator new(unsigned long long) >>> operator delete(void*, unsigned long long) >>> >>> The delete can be ignored, it's the result of a bug on my >>> experimental branch (It was first discovered there, then I tested it >>> on master). I'm more interested about the new, since it seems to be >>> violating a HotSpot rule. Is this an intentional exception to the >>> rule, or an oversight? >>> >>> best regards, >>> Julian From alanb at openjdk.org Thu Nov 14 08:31:32 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 08:31:32 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. @coleenp Do you plan a follow-up to purge the remaining refs to AccessController and AccessControlContext? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2475708718 From dfuchs at openjdk.org Thu Nov 14 09:05:42 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 14 Nov 2024 09:05:42 GMT Subject: RFR: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. The jwebserver.md looks OK to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2435435938 From shade at openjdk.org Thu Nov 14 10:43:15 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Nov 2024 10:43:15 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 23:07:02 GMT, William Kemper wrote: >> test/hotspot/jtreg/gc/shenandoah/oom/TestThreadFailure.java line 61: >> >>> 59: // case that the previously instantiated NastyThread accumulated more than SheanndoahNoProgressThreshold >>> 60: // unproductive GC cycles before failing, the main thread may not try a Full GC before it experiences >>> 61: // OutOfMemoryError exception. >> >> Do you really need comments in this test? > > This test was a sore spot for us and we spent quite some time to make it pass. I don't think the code is very clear on its face about what the test expects, so I'd prefer to keep this comment. OK, fine! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1841996383 From ihse at openjdk.org Thu Nov 14 11:11:54 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 14 Nov 2024 11:11:54 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Fix CheckManPageOptions test - Remove classpath exception ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22081/files - new: https://git.openjdk.org/jdk/pull/22081/files/ffb41ba0..a8d4ea50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=00-01 Stats: 106 lines in 36 files changed: 0 ins; 70 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/22081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081 PR: https://git.openjdk.org/jdk/pull/22081 From ihse at openjdk.org Thu Nov 14 11:12:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 14 Nov 2024 11:12:52 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Wed, 13 Nov 2024 21:55:53 GMT, Iris Clark wrote: >> src/java.base/share/man/java.md line 9: >> >>> 7: # published by the Free Software Foundation. Oracle designates this >>> 8: # particular file as subject to the "Classpath" exception as provided >>> 9: # by Oracle in the LICENSE file that accompanied this code. >> >> Documentation files should not have the Classpath exception. >> >> make/data/license-templates/gpl-header > > Agree. Yeah, sorry for that, and thanks for catching it. I just copied the header from a build file, since it was conveniently already formatted with the leading `#`. I just assumed that this was the pure GPL and did not check close enough to verify. But it turns out that most of the build system files actually have the classpath exception, which makes no sense. I've filed https://bugs.openjdk.org/browse/JDK-8344191 to deal with that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1842039722 From coleenp at openjdk.org Thu Nov 14 12:26:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 12:26:58 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Thanks for looking through these changes. Thanks @AlanBateman for answering the question about remaining uses of protection domain. When we create an instance of java.lang.Class, the VM stores the protection domain given in resolve_from_stream. I may have already said this somewhere. So we need to pass it through that path. ------------- PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2435924412 From coleenp at openjdk.org Thu Nov 14 12:26:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 12:26:58 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 08:28:14 GMT, Alan Bateman wrote: > Do you plan a follow-up to purge the remaining refs to AccessController and AccessControlContext? I was unclear if they were still needed in the places they appear. Maybe I should do a follow-up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476223492 From coleenp at openjdk.org Thu Nov 14 12:26:58 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 12:26:58 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 05:42:51 GMT, David Holmes wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > src/hotspot/share/ci/ciEnv.cpp line 1613: > >> 1611: >> 1612: // The very first entry is the InstanceKlass of the root method of the current compilation in order to get the right >> 1613: // (class loader???) protection domain to load subsequent classes during replay compilation. > > Suggestion: simply have: > > // The very first entry is the InstanceKlass of the root method of the current compilation . > > The rest of the comment doesn't really make sense even before your change as this method basically just prints the class name Thanks for noticing this. Updated comment that didn't make sense to me either. > src/hotspot/share/classfile/javaClasses.hpp line 1545: > >> 1543: static int _static_security_offset; >> 1544: static int _static_allow_security_offset; >> 1545: static int _static_never_offset; > > Guess these were missed by the main PR as they are unused. :) Yes, they are dead code. > src/hotspot/share/classfile/systemDictionary.hpp line 239: > >> 237: // compute java_mirror (java.lang.Class instance) for a type ("I", "[[B", "LFoo;", etc.) >> 238: // Either the accessing_klass or the CL can be non-null, but not both. >> 239: // callee will fill in CL from AK, if they are needed > > Suggestion: > > // Callee will fill in CL from accessing_klass, if they are needed. fixed. All these comments could use capitalization, but I won't do that here. > src/hotspot/share/logging/logTag.hpp line 163: > >> 161: LOG_TAG(preview) /* Trace loading of preview feature types */ \ >> 162: LOG_TAG(promotion) \ >> 163: LOG_TAG(protectiondomain) /* "Trace protection domain verification" */ \ > > Not 100% sure about this. We don't really have a policy for "deprecating" or removing log tags. I think it unlikely anyone enables this logging "just because", so it seems okay for this case. Given that I'm probably the only one that has ever used this tag (or maybe also Ioi), I think it's safe to remove. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1842123715 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1842124581 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1842126691 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1842127430 From ihse at openjdk.org Thu Nov 14 12:28:23 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 14 Nov 2024 12:28:23 GMT Subject: RFR: 8344191: Build code should not have classpath exception Message-ID: In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data. The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception. This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience) ------------- Commit messages: - Update build tools, data and IDE support - Update makefiles, autoconf, shell scripts, properties files and configuration files Changes: https://git.openjdk.org/jdk/pull/22104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344191 Stats: 2054 lines in 555 files changed: 0 ins; 1118 del; 936 mod Patch: https://git.openjdk.org/jdk/pull/22104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22104/head:pull/22104 PR: https://git.openjdk.org/jdk/pull/22104 From cstein at openjdk.org Thu Nov 14 12:31:46 2024 From: cstein at openjdk.org (Christian Stein) Date: Thu, 14 Nov 2024 12:31:46 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). A candidate for an ignore list as fixing it is out of scope of this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2476233883 From ihse at openjdk.org Thu Nov 14 12:44:45 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 14 Nov 2024 12:44:45 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 12:29:38 GMT, Christian Stein wrote: > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). *sigh* > A candidate for an ignore list as fixing it is out of scope of this PR? Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2476258243 From coleenp at openjdk.org Thu Nov 14 13:02:22 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 13:02:22 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v2] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: - More purging of AccessController, AccessControlContext and some stackwalking questions. - David comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/c7b5fd13..79831e0d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=00-01 Stats: 79 lines in 8 files changed: 3 ins; 73 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From coleenp at openjdk.org Thu Nov 14 13:11:13 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 13:11:13 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 08:28:14 GMT, Alan Bateman wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > @coleenp Do you plan a follow-up to purge the remaining refs to AccessController and AccessControlContext? @AlanBateman there was that AccessControlContext in the stack that I asked about in the main review that I can't find the answer to. Is it obsolete now? See the change for where I asked this question. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476311805 From coleenp at openjdk.org Thu Nov 14 13:11:14 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 13:11:14 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v2] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:02:22 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with two additional commits since the last revision: > > - More purging of AccessController, AccessControlContext and some stackwalking questions. > - David comments. hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env); I think this is obsolete too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476314927 From alanb at openjdk.org Thu Nov 14 13:23:29 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 13:23:29 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v2] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:07:55 GMT, Coleen Phillimore wrote: > hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env); > > I think this is obsolete too. As part of the JEP 486 work, I changed SecurityManager::getClassContext to use StackWalker, the native method that called into JVM_GetClassContext is removed. So more cleanup here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476341813 From alanb at openjdk.org Thu Nov 14 13:27:18 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 13:27:18 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v2] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:20:23 GMT, Alan Bateman wrote: >> hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env); >> >> I think this is obsolete too. > >> hotspot/share/include/jvm.h:JVM_GetClassContext(JNIEnv *env); >> >> I think this is obsolete too. > > As part of the JEP 486 work, I changed SecurityManager::getClassContext to use StackWalker, the native method that called into JVM_GetClassContext is removed. So more cleanup here. > @AlanBateman there was that AccessControlContext in the stack that I asked about in the main review that I can't find the answer to. Is it obsolete now? See the change for where I asked this question. Thank you! The stack walk that stopped when it found a privileged frame is removed. I can't think of any scenario now where the VM will be interested in the AccessControlContext. Also AccessController is re-implemented to just invoke the actions so there should be no reason for the VM to know about AccessController either. Note that we need to keep JVM_EnsureMaterializedForStackWalk as that is needed for ScopedValue when recovering from SOE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476351280 From duke at openjdk.org Thu Nov 14 13:34:44 2024 From: duke at openjdk.org (Abdelhak Zaaim) Date: Thu, 14 Nov 2024 13:34:44 GMT Subject: RFR: 8344191: Build code should not have classpath exception In-Reply-To: References: Message-ID: <_LlSFeUxsE5NIZ1tl6Fx_PV0NiHyVfwlkYD-91GkfOQ=.a5f09f9e-6116-4f3b-8860-c1e21474e213@github.com> On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie wrote: > In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. > > I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data. > > The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception. > > This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience) Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/22104#pullrequestreview-2436096366 From coleenp at openjdk.org Thu Nov 14 13:40:22 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 13:40:22 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v3] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Found more obsolete security manager code. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/79831e0d..11337a0e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=01-02 Stats: 50 lines in 4 files changed: 0 ins; 49 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From coleenp at openjdk.org Thu Nov 14 14:03:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 14:03:50 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v4] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/11337a0e..ca34fc5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=02-03 Stats: 23 lines in 3 files changed: 0 ins; 18 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From coleenp at openjdk.org Thu Nov 14 14:03:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 14:03:50 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v3] In-Reply-To: References: Message-ID: <_S0DqGV0FJQFKuv9ynZDQZOfMLy8Ab6vE0mlwuKSLmw=.44646b28-d183-4209-8e2e-55afd28bf024@github.com> On Thu, 14 Nov 2024 13:40:22 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Found more obsolete security manager code. The stack walk ignoring AccessControlContext was in some logging code, so now removed. Also, I saw that getClassContext was rewritten, so removed that bit too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476430158 From stooke at openjdk.org Thu Nov 14 14:16:33 2024 From: stooke at openjdk.org (Simon Tooke) Date: Thu, 14 Nov 2024 14:16:33 GMT Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v2] In-Reply-To: <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com> References: <8UXrdYtdb5XAew1MJaHTi_RcrVEHkzFR5XnKdeZEsJs=.8b514ff2-6767-4c8c-be58-31c82fc0af7b@github.com> Message-ID: On Mon, 4 Nov 2024 14:04:58 GMT, Thomas Stuefe wrote: >>> Looking good, small nits remain. Could you share an example output (maybe one run with G1, one with ZGC?) >> >> @tstuefe, Sample output for G1 and ZGC has been attached to the description (and I fixed the ZGC test) > > Hi @stooke, > > nice. There are some aspects about the output that is surprising, though. I expect reserved-only memory to be mapped with MAP_NORESERVE and no access rights. I expect committed memory to be mapped without MAP_NORESERVE and write- or executable access. > > - (G1) I only see one segment for JAVAHEAP. I would expect at least two, one reserved-only, one reserved and committed. Or did you precommit the heap (start JVM with -Xmx==-Xms)? Can you please test that with ParallelGC and without specifying Xms, we should see four java heap mappings side by side, for young and old gen, each with a committed part (rw) and a reserved part (not accessible). Like we do now for the CODE section. Please also countercheck that the address ranges are correct against the heap range (easiest, run jcmd .. VM.info and look for the Heap section, it tells you the address ranges). > - The 64K META and CLASS blocks confuse me. For one, they are too small. A Metaspace node is 64M sized. It can contain multiple committed and reserved sections, so typically spreads over multiple lines, but usually not many. Here (G1 file), I see many that are 64K in size, spanning in total just about 5MB. You can counter-check the META blocks with `jcmd .. VM.metaspace vslist` - it prints the virtual space node list at the start. > - Another thing that is strange is that the MEAT lines are not coalesced, though the properties displayed seem to be the same. But that can be the result of hidden properties being different. > > Also, could you rename the OS-specific names to `[lowercase-something]`? The `[UPPERCASE]` names are easily confused with the uppercase NMT tags. > > Thanks! Hello, @tstuefe , and thanks for your comments. I'll address a few here while I work on the others. I have changed the os-specific names to lowercase, but I don't think it makes them stand out more. The square brackets were intended to do that. Might I change this back? I think there is only one JAVAHEAP segment because due to an issue with my build[1] there was no CDS archive available. I will look at the META and CLASS entries and see if there are hidden properties that I can surface, or if there's another reason for so many entries. [1] I had given a target architecture to the configure command, which turned on cross-compiles (which disables CDS archive building) even when building on the target platform. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20953#issuecomment-2476459287 From alanb at openjdk.org Thu Nov 14 14:45:29 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 14 Nov 2024 14:45:29 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v4] In-Reply-To: References: Message-ID: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> On Thu, 14 Nov 2024 14:03:50 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). I see a few left over refs to SecurityManager in vmSymbols.hpp, vmClassMacros.hpp, and a comment in logDiagnosticCommand.hpp. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476531284 From jjg at openjdk.org Thu Nov 14 15:26:22 2024 From: jjg at openjdk.org (Jonathan Gibbons) Date: Thu, 14 Nov 2024 15:26:22 GMT Subject: RFR: 8344191: Build code should not have classpath exception In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie wrote: > In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. > > I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data. > > The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception. > > This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience) The policy has long been to use Classpath Exception in the `src` and `make` directories, but not in the `test` directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2476698524 From coleenp at openjdk.org Thu Nov 14 16:02:56 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 16:02:56 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Purge last references to SecurityManager. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/ca34fc5b..aee8efd3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=03-04 Stats: 4 lines in 3 files changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From nbenalla at openjdk.org Thu Nov 14 16:38:14 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 14 Nov 2024 16:38:14 GMT Subject: RFR: 8343781: Add since checker test to the Serviceability area modules [v2] In-Reply-To: References: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Message-ID: On Thu, 14 Nov 2024 00:53:08 GMT, Nizar Benalla wrote: >> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Serviceability area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. >> >> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. >> >> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. >> >> TIA > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - fix mistake in module name passed to jdk.jconsole test > - Add backticks to mentions of `@since`, to avoid jtreg mistaking it with a jtreg tag > > Revert "remove backticks" > > This reverts commit 0abe3080391e83cae62253f56c28d98efa0ed253. Thanks all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21983#issuecomment-2476887796 From nbenalla at openjdk.org Thu Nov 14 16:38:15 2024 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 14 Nov 2024 16:38:15 GMT Subject: Integrated: 8343781: Add since checker test to the Serviceability area modules In-Reply-To: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> References: <_OUHHdUrgmF9aXYPQqtDTOG3CH24NqG1UHD4Z64gi2w=.f804c932-1246-43c8-aa20-00e5b5e2c30f@github.com> Message-ID: On Fri, 8 Nov 2024 15:20:00 GMT, Nizar Benalla wrote: > Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Serviceability area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442. > > The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. > > The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. > > TIA This pull request has now been integrated. Changeset: e12f5141 Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/e12f5141201a5142325936650f4a417d27e814ae Stats: 36 lines in 12 files changed: 0 ins; 0 del; 36 mod 8343781: Add since checker test to the Serviceability area modules Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/21983 From coleenp at openjdk.org Thu Nov 14 17:02:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 17:02:33 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v4] In-Reply-To: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> References: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> Message-ID: On Thu, 14 Nov 2024 14:42:30 GMT, Alan Bateman wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > > I see a few left over refs to SecurityManager in vmSymbols.hpp, vmClassMacros.hpp, and a comment in logDiagnosticCommand.hpp. Thanks @AlanBateman There's a DCmd permissions() function that talks about DiagnosticCommandMBean security. I don't know what that is so I'm leaving it. Edit: appears unrelated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2476948391 From iklam at openjdk.org Thu Nov 14 18:07:16 2024 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 14 Nov 2024 18:07:16 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: <9odgI41Erhmy3c5sk7YgS_NR61BaYO933G0HwPHRJNw=.54e7cb3b-98bf-4ec8-94f7-8032b52eb773@github.com> Message-ID: On Thu, 14 Nov 2024 07:53:32 GMT, David Holmes wrote: > > > To be fair I'm unclear what role PD still plays on the JDK side and would not be surprised if it is destined for removal at some point. > > > > > > PD is not deprecated as PD::getCodeSource is widely used. It may be that an alternative means is introduced in the future to expose the code location but nothing specific at this time. > > Okay but I still remain unclear about the role of PD in the VM, in particular how CDS is using it. CDS just emulates what the Java code does -- to ensure that Class.getProtectionDomain() would get the same answer as if the class was loaded from bytecodes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2477083960 From iris at openjdk.org Thu Nov 14 18:43:38 2024 From: iris at openjdk.org (Iris Clark) Date: Thu, 14 Nov 2024 18:43:38 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception Thanks for updating all the licenses to GPL. ------------- PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2436927254 From coleenp at openjdk.org Thu Nov 14 19:20:21 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 19:20:21 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass Message-ID: This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. Tested with tier1-4. ------------- Commit messages: - 8330606: Redefinition doesn't but should verify the new klass Changes: https://git.openjdk.org/jdk/pull/22116/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22116&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330606 Stats: 140 lines in 2 files changed: 132 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22116.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22116/head:pull/22116 PR: https://git.openjdk.org/jdk/pull/22116 From cjplummer at openjdk.org Thu Nov 14 19:26:18 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 14 Nov 2024 19:26:18 GMT Subject: RFR: 8253440: serviceability/sa/TestJhsdbJstackLineNumbers.java failed with "Didn't find enough line numbers" Message-ID: The test is checking to make sure SA will use what is in the bcp register to determine the current line number rather than just use frame->bcp, which often is not up to date. It spawns a debuggee that sits in a loop that is 10 lines of source. The test executes jstack on the debuggee and determines the current line number from the output. It does this 25 times and expectesto see at least 5 of the 10 line numbers being hit. There's no guarantee it will hit at least five. The chances of this not happening are very very low, but apparently the test has failed a couple of times because only 4 unique lines were hit. I decided to do the simple fix and just lower the threshhold to 4 lines. Ran locally on linux-x64. Tier1 in progress. ------------- Commit messages: - lower required number of line numbers from 5 to 4 Changes: https://git.openjdk.org/jdk/pull/22117/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22117&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8253440 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22117.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22117/head:pull/22117 PR: https://git.openjdk.org/jdk/pull/22117 From shade at openjdk.org Thu Nov 14 19:34:14 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Nov 2024 19:34:14 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 23:17:44 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp line 50: >> >>> 48: switch (generation_type) { \ >>> 49: case NON_GEN: \ >>> 50: return prefix " (NON-GENERATIONAL)" postfix; \ >> >> In the interest of keeping the non-generational Shenandoah logging intact, should we drop ` (NON-GENERATIONAL)` here? > > No objections here. @ysramakrishna , @kdnilsen ? See, with current code, default Shenandoah prints this: [0.025s][info][gc] GC(0) Concurrent reset (NON-GENERATIONAL) (unload classes) 0.135ms [0.025s][info][gc] GC(0) Pause Init Mark (NON-GENERATIONAL) (unload classes) 0.018ms [0.025s][info][gc] GC(0) Concurrent marking roots 0.097ms [0.029s][info][gc] GC(0) Concurrent marking (NON-GENERATIONAL) (unload classes) 4.050ms [0.029s][info][gc] GC(0) Pause Final Mark (NON-GENERATIONAL) (unload classes) 0.123ms [0.029s][info][gc] GC(0) Concurrent thread roots 0.205ms [0.029s][info][gc] GC(0) Concurrent weak references (NON-GENERATIONAL) (unload classes) 0.014ms [0.029s][info][gc] GC(0) Concurrent weak roots (NON-GENERATIONAL) (unload classes) 0.047ms [0.029s][info][gc] GC(0) Concurrent cleanup (NON-GENERATIONAL) (unload classes) 40M->40M(2064M) 0.006ms [0.029s][info][gc] GC(0) Concurrent class unloading 0.035ms [0.029s][info][gc] GC(0) Concurrent strong roots 0.119ms This is not great: experimental GenShen should not affect the logging for current product code. There is a risk we would be breaking some GC parsers if we change it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842764603 From shade at openjdk.org Thu Nov 14 19:34:15 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Nov 2024 19:34:15 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Thu, 14 Nov 2024 19:12:25 GMT, Aleksey Shipilev wrote: >> No objections here. @ysramakrishna , @kdnilsen ? > > See, with current code, default Shenandoah prints this: > > > [0.025s][info][gc] GC(0) Concurrent reset (NON-GENERATIONAL) (unload classes) 0.135ms > [0.025s][info][gc] GC(0) Pause Init Mark (NON-GENERATIONAL) (unload classes) 0.018ms > [0.025s][info][gc] GC(0) Concurrent marking roots 0.097ms > [0.029s][info][gc] GC(0) Concurrent marking (NON-GENERATIONAL) (unload classes) 4.050ms > [0.029s][info][gc] GC(0) Pause Final Mark (NON-GENERATIONAL) (unload classes) 0.123ms > [0.029s][info][gc] GC(0) Concurrent thread roots 0.205ms > [0.029s][info][gc] GC(0) Concurrent weak references (NON-GENERATIONAL) (unload classes) 0.014ms > [0.029s][info][gc] GC(0) Concurrent weak roots (NON-GENERATIONAL) (unload classes) 0.047ms > [0.029s][info][gc] GC(0) Concurrent cleanup (NON-GENERATIONAL) (unload classes) 40M->40M(2064M) 0.006ms > [0.029s][info][gc] GC(0) Concurrent class unloading 0.035ms > [0.029s][info][gc] GC(0) Concurrent strong roots 0.119ms > > > This is not great: experimental GenShen should not affect the logging for current product code. There is a risk we would be breaking some GC parsers if we change it. While we are at it, we should probably replace `YOUNG` -> `Young`, etc, and figure out if `Transition from`, `Heuristics request`, and ` Periodic Sample:` should be in `gc=debug`, so logs are cleaner: [7.514s][info][gc] Transition from: normal to: idle [7.617s][info][gc] Trigger (YOUNG): Average GC time (123.52 ms) is above the time for average allocation rate (2868 MB/s) to deplete free headroom (350M) (margin of error = 1.79) [7.617s][info][gc] Transition from: idle to: normal [7.617s][info][gc] Heuristics request for young collection accepted [7.618s][info][gc] GC(31) Concurrent reset (YOUNG) 1.095ms [7.618s][info][gc] GC(31) Pause Init Mark (YOUNG) 0.026ms [7.618s][info][gc] GC(31) Concurrent remembered set scanning 0.148ms [7.618s][info][gc] GC(31) Concurrent marking roots 0.217ms [7.680s][info][gc] GC(31) Concurrent marking (YOUNG) 61.990ms [7.681s][info][gc] GC(31) Transfer 1 region(s) from OLD to YOUNG, yielding increased size: 1021M [7.681s][info][gc] GC(31) Transfer 1 region(s) from YOUNG to OLD, yielding increased size: 3584K [7.681s][info][gc] GC(31) Pause Final Mark (YOUNG) 0.246ms [7.681s][info][gc] GC(31) Concurrent thread roots 0.041ms [7.728s][info][gc] GC(31) Concurrent weak references (YOUNG) 47.278ms [7.728s][info][gc] GC(31) Concurrent weak roots (YOUNG) 0.114ms [7.728s][info][gc] GC(31) Concurrent cleanup (YOUNG) 674M->658M(1024M) 0.014ms [7.728s][info][gc] GC(31) Concurrent strong roots 0.217ms [7.730s][info][gc] GC(31) Concurrent evacuation 1.879ms [7.730s][info][gc] GC(31) Pause Init Update Refs 0.010ms [7.730s][info][gc] GC(31) Transfer 1 region(s) from OLD to YOUNG, yielding increased size: 1021M [7.739s][info][gc] GC(31) Concurrent update references 8.651ms [7.739s][info][gc] GC(31) Concurrent update thread roots 0.069ms [7.739s][info][gc] GC(31) Transfer 1 region(s) from YOUNG to OLD, yielding increased size: 3584K [7.739s][info][gc] GC(31) Pause Final Update Refs 0.076ms [7.739s][info][gc] GC(31) Concurrent cleanup (YOUNG) 690M->135M(1024M) 0.078ms ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842769207 From shade at openjdk.org Thu Nov 14 19:34:13 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 14 Nov 2024 19:34:13 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 More reviews... src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.cpp line 141: > 139: dst->increase_capacity(bytes_to_transfer); > 140: const size_t new_size = dst->max_capacity(); > 141: log_info(gc)("Transfer " SIZE_FORMAT " region(s) from %s to %s, yielding increased size: " PROPERFMT, This should not be `log_info(gc)`. In fact, please look at other places where you print logging. Generally, `log_info(gc)` should provide _only_ the high-level GC info: which phases were running. Everything else should go under `log_debug(gc)`. src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 140: > 138: break; > 139: } > 140: case OLD: Are we not doing OLD STW mark? Deserves a comment. src/hotspot/share/gc/shenandoah/shenandoahYoungGeneration.hpp line 54: > 52: void parallel_heap_region_iterate(ShenandoahHeapRegionClosure* cl) override; > 53: > 54: void parallel_region_iterate_free(ShenandoahHeapRegionClosure* cl) override; Is this a sibling of `parallel_heap_region_iterate`? Shouldn't these be called `parallel_heap_region_iterate_free`? ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2436882261 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842779639 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842701030 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1842704295 From cjplummer at openjdk.org Thu Nov 14 20:33:27 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 14 Nov 2024 20:33:27 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass In-Reply-To: References: Message-ID: <6iqjTBjVbqzvmCxkhOqUwSWCPJ9q8t8jK5nqT5O-G5I=.ceb62fe9-b451-426b-82a4-2e5d5a5c2bc7@github.com> On Thu, 14 Nov 2024 19:03:18 GMT, Coleen Phillimore wrote: > This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. > Tested with tier1-4. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 124: > 122: try { > 123: RedefineClassHelper.redefineClass(verifyErrorMirror, dump()); > 124: VerifyError err = new VerifyError("verify me now"); Which of these two lines are expected to throw a VerifyError? Is the VerifyError because you can't redefine VerifyError, or is there something invalid about the how the class is redefined? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1842849416 From stooke at openjdk.org Thu Nov 14 20:37:57 2024 From: stooke at openjdk.org (Simon Tooke) Date: Thu, 14 Nov 2024 20:37:57 GMT Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v7] In-Reply-To: References: Message-ID: > This is a port of #16301 to macOS. > > System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit. > > The System.map tests are also reworked to be cleaner for the three implementations. > > [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt) > [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt) Simon Tooke has updated the pull request incrementally with one additional commit since the last revision: lowercase tag names, display dll addresses ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20953/files - new: https://git.openjdk.org/jdk/pull/20953/files/8e19b687..d63fa562 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=05-06 Stats: 143 lines in 1 file changed: 106 ins; 0 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/20953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20953/head:pull/20953 PR: https://git.openjdk.org/jdk/pull/20953 From coleenp at openjdk.org Thu Nov 14 21:35:52 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 21:35:52 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: Message-ID: > This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Updated the test with some comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22116/files - new: https://git.openjdk.org/jdk/pull/22116/files/667232c7..af6b1e12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22116&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22116&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22116.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22116/head:pull/22116 PR: https://git.openjdk.org/jdk/pull/22116 From coleenp at openjdk.org Thu Nov 14 21:35:53 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 14 Nov 2024 21:35:53 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: <6iqjTBjVbqzvmCxkhOqUwSWCPJ9q8t8jK5nqT5O-G5I=.ceb62fe9-b451-426b-82a4-2e5d5a5c2bc7@github.com> References: <6iqjTBjVbqzvmCxkhOqUwSWCPJ9q8t8jK5nqT5O-G5I=.ceb62fe9-b451-426b-82a4-2e5d5a5c2bc7@github.com> Message-ID: On Thu, 14 Nov 2024 20:28:01 GMT, Chris Plummer wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated the test with some comments. > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 124: > >> 122: try { >> 123: RedefineClassHelper.redefineClass(verifyErrorMirror, dump()); >> 124: VerifyError err = new VerifyError("verify me now"); > > Which of these two lines are expected to throw a VerifyError? > > Is the VerifyError because you can't redefine VerifyError, or is there something invalid about the how the class is redefined? We call the verifier during redefinition with the 'true' parameter, so the redefinition will throw VerifyError when it's loading the new class file version. There's a broken stackmap in the new version of this VerifyError class (ie. I asmifyied it and commented out something in it). I updated the test with some comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1842913318 From cjplummer at openjdk.org Thu Nov 14 21:54:21 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 14 Nov 2024 21:54:21 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: <6iqjTBjVbqzvmCxkhOqUwSWCPJ9q8t8jK5nqT5O-G5I=.ceb62fe9-b451-426b-82a4-2e5d5a5c2bc7@github.com> Message-ID: On Thu, 14 Nov 2024 21:31:53 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 124: >> >>> 122: try { >>> 123: RedefineClassHelper.redefineClass(verifyErrorMirror, dump()); >>> 124: VerifyError err = new VerifyError("verify me now"); >> >> Which of these two lines are expected to throw a VerifyError? >> >> Is the VerifyError because you can't redefine VerifyError, or is there something invalid about the how the class is redefined? > > We call the verifier during redefinition with the 'true' parameter, so the redefinition will throw VerifyError when it's loading the new class file version. There's a broken stackmap in the new version of this VerifyError class (ie. I asmifyied it and commented out something in it). I updated the test with some comments. Ok. You got rid of the `new VerifyError()`, which is what I figured my next request was going to be. :) The test looks fine. I don't really have the background to review the native code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1842930758 From cjplummer at openjdk.org Thu Nov 14 22:20:55 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 14 Nov 2024 22:20:55 GMT Subject: RFR: 8343529: serviceability/sa/ClhsdbWhere.java fails AssertionFailure: Corrupted constant pool Message-ID: These two tests both do stack dumps with one or more active threads. This can result in SA throwing an exception if the thread is in a bad state. However, SA will still generate stack traces for all other threads, and the tests should still pass all the output checks, so we can safely ignore these exceptions and not fail the test as a result of them. Tested by running all SA tests 50 times on all supported platforms. Tier1 testing in progress. ------------- Commit messages: - Ignore SA errors Changes: https://git.openjdk.org/jdk/pull/22123/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22123&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343529 Stats: 25 lines in 3 files changed: 16 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22123.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22123/head:pull/22123 PR: https://git.openjdk.org/jdk/pull/22123 From pchilanomate at openjdk.org Thu Nov 14 22:51:18 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 14 Nov 2024 22:51:18 GMT Subject: RFR: 8344247: Move objectWaiter field to VirtualThread instance Message-ID: Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. Tested by running mach5 tiers1-3. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/22124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344247 Stats: 115 lines in 12 files changed: 39 ins; 62 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/22124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22124/head:pull/22124 PR: https://git.openjdk.org/jdk/pull/22124 From mdoerr at openjdk.org Thu Nov 14 23:43:50 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 14 Nov 2024 23:43:50 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr Probably not a show-stopper. Should the test be adapted or disabled for this platform? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2477628609 From ihse at openjdk.org Fri Nov 15 00:10:24 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 00:10:24 GMT Subject: RFR: 8344191: Build code should not have classpath exception In-Reply-To: References: Message-ID: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com> On Thu, 14 Nov 2024 15:23:35 GMT, Jonathan Gibbons wrote: > The policy has long been to use Classpath Exception in the src and make directories, but not in the test directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down. I did not know there was such a policy. My understanding is that the classpath exception only makes sense for java files that are distributed as part of the JDK. That `test` was excluded from classpath should therefore be a logical consequence that it is not distributed. And `src` is not generally using CPE; for instance, Hotspot does not have CPE. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2477665315 From wkemper at openjdk.org Fri Nov 15 00:15:59 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 00:15:59 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> Message-ID: On Thu, 14 Nov 2024 23:39:08 GMT, Martin Doerr wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: > > Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" > > java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr > > Probably not a show-stopper. Should the test be adapted or disabled for this platform? @TheRealMDoerr - do you have the logs from the test failure? If so, could you open a ticket with them in JBS? Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2477671400 From dholmes at openjdk.org Fri Nov 15 01:25:30 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 01:25:30 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception LGTM! ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2437489438 From wkemper at openjdk.org Fri Nov 15 01:27:59 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 01:27:59 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Thu, 14 Nov 2024 19:26:12 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.cpp line 141: > >> 139: dst->increase_capacity(bytes_to_transfer); >> 140: const size_t new_size = dst->max_capacity(); >> 141: log_info(gc)("Transfer " SIZE_FORMAT " region(s) from %s to %s, yielding increased size: " PROPERFMT, > > This should not be `log_info(gc)`. In fact, please look at other places where you print logging. Generally, `log_info(gc)` should provide _only_ the high-level GC info: which phases were running. Everything else should go under `log_debug(gc)`. https://bugs.openjdk.org/browse/JDK-8344263 > src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 140: > >> 138: break; >> 139: } >> 140: case OLD: > > Are we not doing OLD STW mark? Deserves a comment. https://bugs.openjdk.org/browse/JDK-8344264 > src/hotspot/share/gc/shenandoah/shenandoahYoungGeneration.hpp line 54: > >> 52: void parallel_heap_region_iterate(ShenandoahHeapRegionClosure* cl) override; >> 53: >> 54: void parallel_region_iterate_free(ShenandoahHeapRegionClosure* cl) override; > > Is this a sibling of `parallel_heap_region_iterate`? Shouldn't these be called `parallel_heap_region_iterate_free`? https://bugs.openjdk.org/browse/JDK-8344264 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843073877 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843075157 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843075212 From wkemper at openjdk.org Fri Nov 15 01:28:00 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 01:28:00 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: <9UFMM5ji_G1XTowN-oY6n3JS5Enw_IFv9x8JShC1yhQ=.26f05071-7945-4268-8932-3486c319c139@github.com> On Thu, 14 Nov 2024 19:16:30 GMT, Aleksey Shipilev wrote: >> See, with current code, default Shenandoah prints this: >> >> >> [0.025s][info][gc] GC(0) Concurrent reset (NON-GENERATIONAL) (unload classes) 0.135ms >> [0.025s][info][gc] GC(0) Pause Init Mark (NON-GENERATIONAL) (unload classes) 0.018ms >> [0.025s][info][gc] GC(0) Concurrent marking roots 0.097ms >> [0.029s][info][gc] GC(0) Concurrent marking (NON-GENERATIONAL) (unload classes) 4.050ms >> [0.029s][info][gc] GC(0) Pause Final Mark (NON-GENERATIONAL) (unload classes) 0.123ms >> [0.029s][info][gc] GC(0) Concurrent thread roots 0.205ms >> [0.029s][info][gc] GC(0) Concurrent weak references (NON-GENERATIONAL) (unload classes) 0.014ms >> [0.029s][info][gc] GC(0) Concurrent weak roots (NON-GENERATIONAL) (unload classes) 0.047ms >> [0.029s][info][gc] GC(0) Concurrent cleanup (NON-GENERATIONAL) (unload classes) 40M->40M(2064M) 0.006ms >> [0.029s][info][gc] GC(0) Concurrent class unloading 0.035ms >> [0.029s][info][gc] GC(0) Concurrent strong roots 0.119ms >> >> >> This is not great: experimental GenShen should not affect the logging for current product code. There is a risk we would be breaking some GC parsers if we change it. > > While we are at it, we should probably replace `YOUNG` -> `Young`, etc, and figure out if `Transition from`, `Heuristics request`, and ` Periodic Sample:` should be in `gc=debug`, so logs are cleaner: > > > [7.514s][info][gc] Transition from: normal to: idle > [7.617s][info][gc] Trigger (YOUNG): Average GC time (123.52 ms) is above the time for average allocation rate (2868 MB/s) to deplete free headroom (350M) (margin of error = 1.79) > [7.617s][info][gc] Transition from: idle to: normal > [7.617s][info][gc] Heuristics request for young collection accepted > [7.618s][info][gc] GC(31) Concurrent reset (YOUNG) 1.095ms > [7.618s][info][gc] GC(31) Pause Init Mark (YOUNG) 0.026ms > [7.618s][info][gc] GC(31) Concurrent remembered set scanning 0.148ms > [7.618s][info][gc] GC(31) Concurrent marking roots 0.217ms > [7.680s][info][gc] GC(31) Concurrent marking (YOUNG) 61.990ms > [7.681s][info][gc] GC(31) Transfer 1 region(s) from OLD to YOUNG, yielding increased size: 1021M > [7.681s][info][gc] GC(31) Transfer 1 region(s) from YOUNG to OLD, yielding increased size: 3584K > [7.681s][info][gc] GC(31) Pause Final Mark (YOUNG) 0.246ms > [7.681s][info][gc] GC(31) Concurrent thread roots 0.041ms > [7.728s][info][gc] GC(31) Concurrent weak references (YOUNG) 47.278ms > [7.728s][info][gc] GC(31) Concurrent weak roots (YOUNG) 0.114ms > [7.728s][info][gc] GC(31) Concurrent cleanup (YOUNG) 674M->658M(1024M) 0.014ms > [7.728s][info][gc] GC(31) Concurrent strong roots 0.217ms > [7.730s][info][gc] GC(31) Concurrent evacuation 1.879ms > [7.730s][info][gc] GC(31) Pause Init Update Refs 0.010ms > [7.730s][info][gc] GC(31) Transfer 1 region(s) from OLD to YOUNG, yielding increased size: 1021M > [7.739s][info][gc] GC(31) Concurrent update references 8.651ms > [7.739s][info][gc] GC(31) Concurrent update thread roots 0.069ms > [7.739s][info][gc] GC(31) Transfer 1 region(s) from YOUNG to OLD, yielding increased size: 3584K > [7.739s][info][gc] GC(31) Pause Final Update Refs 0.076ms > [7.739s][info][gc] GC(31) Concurrent cleanup (YOUNG) 690M->135M(1024M) 0.078ms https://bugs.openjdk.org/browse/JDK-8344263 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843074126 From dholmes at openjdk.org Fri Nov 15 01:29:49 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 01:29:49 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com> On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception > > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). > > _sigh_ > > > A candidate for an ignore list as fixing it is out of scope of this PR? > > Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix. I'm somewhat surprised that the full src tree is available to this test when it runs. I was expecting it to examine the .1 files in the JDK image. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2477764902 From alexey.menkov at oracle.com Fri Nov 15 02:10:59 2024 From: alexey.menkov at oracle.com (Alexey Menkov) Date: Fri, 15 Nov 2024 02:10:59 +0000 Subject: Win32AttachOperationRequest seems to be using global new? In-Reply-To: References: <8ec38c62-69d5-4821-b160-0148c41581ea@oracle.com> Message-ID: <1eae0151-9904-49f2-b595-3d7e9d5b5964@oracle.com> Sorry, didn't noticed the message before. Yes, this is oversight. Filed https://bugs.openjdk.org/browse/JDK-8344262 Thank you for the finding Julian. --alex On 14.11.2024 0:28, David Holmes wrote: > That didn't work so cc'ing serviceability-dev > > I think it was just an oversight. > > David > > > On 14/11/2024 6:24 pm, David Holmes wrote: >> It was added by JDK-8339289 so cc'ing Alex. >> >> David >> >> On 14/11/2024 5:33 pm, Julian Waters wrote: >>> Bumping, I'm still curious about this issue >>> >>> best regards, >>> Julian >>> >>> On Tue, Nov 12, 2024 at 10:20?PM Julian Waters >>> wrote: >>>> Hi all, >>>> >>>> Win32AttachOperationRequest is created via new, but doesn't specify >>>> a custom new inside the class definition. The result seems to be >>>> that we use global new on Windows: >>>> >>>> ?? for (int i=0; i>>> ???? Win32AttachOperationRequest* op = new >>>> Win32AttachOperationRequest(); >>>> ?????? f1: b9 28 0d 00 00?????? mov??? ecx,0xd28 >>>> ?????? f6: e8 00 00 00 00?????? call?? fb >>>> >>>> f7: IMAGE_REL_AMD64_REL32 operator new(unsigned long long) >>>> >>>> Stepping away from gcc's objdump and using the Microsoft dumpbin >>>> alongside cl.exe instead, the result is this: >>>> >>>> ?? 0000000000000264: B9 28 0D 00 00???? mov???????? ecx,0D28h >>>> ?? 0000000000000269: E8 00 00 00 00???? call??????? ??2 at YAPEAX_K@Z >>>> ?? 000000000000026E: 48 89 44 24 28???? mov???????? qword ptr >>>> [rsp+28h],rax >>>> ?? 0000000000000273: 48 83 7C 24 28 00? cmp???????? qword ptr >>>> [rsp+28h],0 >>>> ?? 0000000000000279: 74 11????????????? je????????? 000000000000028C >>>> ?? 000000000000027B: 48 8B 4C 24 28???? mov???????? rcx,qword ptr >>>> [rsp+28h] >>>> ?? 0000000000000280: E8 00 00 00 00???? call??????? ?? >>>> 0Win32AttachOperationRequest@@QEAA at XZ >>>> >>>> undname "??2 at YAPEAX_K@Z" >>>> Microsoft (R) C++ Name Undecorator >>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>> >>>> Undecoration of :- "??2 at YAPEAX_K@Z" >>>> is :- "void * __ptr64 __cdecl operator new(unsigned __int64)" >>>> >>>> undname "??0Win32AttachOperationRequest@@QEAA at XZ" >>>> Microsoft (R) C++ Name Undecorator >>>> Copyright (C) Microsoft Corporation. All rights reserved. >>>> >>>> Undecoration of :- "??0Win32AttachOperationRequest@@QEAA at XZ" >>>> is :- "public: __cdecl >>>> Win32AttachOperationRequest::Win32AttachOperationRequest(void) __ptr64" >>>> >>>> Visual Studio, lacking the nm utility, obviously doesn't catch this. >>>> What was more surprising is that the gcc Link Time check also fails >>>> to catch it as well. I had to manually check the output of nm after >>>> an unrelated failure and happened to stumble across the symbols >>>> _Znwy and _ZdlPvy which both correspond to >>>> >>>> operator new(unsigned long long) >>>> operator delete(void*, unsigned long long) >>>> >>>> The delete can be ignored, it's the result of a bug on my >>>> experimental branch (It was first discovered there, then I tested it >>>> on master). I'm more interested about the new, since it seems to be >>>> violating a HotSpot rule. Is this an intentional exception to the >>>> rule, or an oversight? >>>> >>>> best regards, >>>> Julian > From dholmes at openjdk.org Fri Nov 15 02:52:30 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 02:52:30 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 16:02:56 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Purge last references to SecurityManager. src/hotspot/share/classfile/javaClasses.cpp line 1617: > 1615: macro(_holder_offset, k, "holder", thread_fieldholder_signature, false); \ > 1616: macro(_name_offset, k, vmSymbols::name_name(), string_signature, false); \ > 1617: macro(_contextClassLoader_offset, k, "contextClassLoader", classloader_signature, false); \ I didn't think the context class loader was related to SM in any way. ?? src/hotspot/share/logging/logDiagnosticCommand.hpp line 62: > 60: } > 61: > 62: static const JavaPermission permission() { Is any of this permission stuff still relevant? I couldn't figure out what ultimately looks at them. ?? src/hotspot/share/prims/jvm.cpp line 154: > 152: */ > 153: > 154: extern void trace_class_resolution(Klass* to_class) { why `extern` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843117025 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843121894 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843122642 From dholmes at openjdk.org Fri Nov 15 04:52:04 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 04:52:04 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java line 1: This file was reduced to empty but not actually deleted. Can you fix it please. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1843185719 From dholmes at openjdk.org Fri Nov 15 05:28:49 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 05:28:49 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:35:52 GMT, Coleen Phillimore wrote: >> This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Updated the test with some comments. Sorry but I don't see how these changes deal with "redefinition should but doesn't verify the new klass" - the only change here is to not skip Object/Class/String/Throwable. ?? src/hotspot/share/classfile/verifier.cpp line 280: > 278: > 279: return (should_verify_class && > 280: // return if the class is a bootstrapping class This method should have a comment explaining what the eligibility criteria is and how/why `should_verify_class` should be set in different conditions. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 68: > 66: classWriter.visit(52, ACC_SUPER | ACC_PUBLIC, "java/lang/VerifyError", null, "java/lang/LinkageError", null); > 67: { > 68: fieldVisitor = classWriter.visitField(ACC_PRIVATE | ACC_FINAL | ACC_STATIC, "serialVersionUID", "J", null, new Long(7001962396098498785L)); Why do we need a serialVersionUID in this test class? test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 71: > 69: fieldVisitor.visitEnd(); > 70: } > 71: { Please add a comment showing the Java code this asm is implementing. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 90: > 88: } > 89: > 90: { // broken method Please add a comment showing the Java code this asm is implementing. ------------- PR Review: https://git.openjdk.org/jdk/pull/22116#pullrequestreview-2437674162 PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1843201864 PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1843203365 PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1843203716 PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1843203836 From dholmes at openjdk.org Fri Nov 15 05:28:50 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 15 Nov 2024 05:28:50 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 05:23:13 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated the test with some comments. > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 71: > >> 69: fieldVisitor.visitEnd(); >> 70: } >> 71: { > > Please add a comment showing the Java code this asm is implementing. Actually why do you even need this constructor now? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1843204345 From iklam at openjdk.org Fri Nov 15 05:48:27 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 05:48:27 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v12] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 179 commits: - Merge branch 'master' into jep-483-candidate - Merge branch 'master' into jep-483-candidate - fixed merge with UseCompactObjectHeaders - Merge branch 'master' into jep-483-candidate - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - Merge branch 'master' into jep-483-candidate - 8343493: Perform module checks during MetaspaceShared::map_archives() - ... and 169 more: https://git.openjdk.org/jdk/compare/db56266a...77b253cf ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=11 Stats: 7192 lines in 107 files changed: 6358 ins; 513 del; 321 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From jrose at openjdk.org Fri Nov 15 07:19:52 2024 From: jrose at openjdk.org (John R Rose) Date: Fri, 15 Nov 2024 07:19:52 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v12] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 05:48:27 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 179 commits: > > - Merge branch 'master' into jep-483-candidate > - Merge branch 'master' into jep-483-candidate > - fixed merge with UseCompactObjectHeaders > - Merge branch 'master' into jep-483-candidate > - fixed merge > - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline > - @DanHeidinga comment -- exit VM when runtimeSetup() fails > - fixed merge > - Merge branch 'master' into jep-483-candidate > - 8343493: Perform module checks during MetaspaceShared::map_archives() > - ... and 169 more: https://git.openjdk.org/jdk/compare/db56266a...77b253cf Re-reviewed. I compared the current diffs with the diffs from my last review. All new changes look good. Lilliput conflict resolution looks good. I assume we test that path. Nice work. One typo in `make/RunTests.gmk`: > The AOT cache file to be usd to wun the test with ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2437843167 From jsjolen at openjdk.org Fri Nov 15 09:37:06 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 15 Nov 2024 09:37:06 GMT Subject: Withdrawn: 8335701: Make GrowableArray templated by an Index In-Reply-To: References: Message-ID: On Thu, 4 Jul 2024 11:34:23 GMT, Johan Sj?len wrote: > Hi, > > Today the GrowableArray has a set index type of `int`, this PR makes it so that you can set your own index type through a template parameter. > > This opens up for a few new design choices: > > - Do you know that you have a very small array? Use an `uint8_t` for len and cap, each. > - Do you have a very large one? Use an `uint64_t`. > > The code has opted for `int` being default, as to keep identical semantics for all existing code and to let users not have to worry about the index if they don't care. > > One "major" change that I don't want to get lost in the review: I've changed the mid-point calculation to be overflow insensitive without casting. > > > > // Old > mid = ((max + min) / 2); > // New > mid = min + ((max - min) / 2); > > Some semi-rigorous thinking: > min \in [0, len) > max \in [0, len) > min <= max > max - min / 2 \in [0, len/2) > Maximizing min and max => len + 0 > Maximizing max, minimizing min => len/2 > Minimizing max, maximizing min => max = min => min > > > // Proof that they're identical when m, h, l \in N > (1) m = l + (h - l) / 2 <=> > 2m = 2l + h - l = h + l > > (2) m = (h + l) / 2 <=> > 2m = h + l > (1) = (2) > QED This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20031 From kevinw at openjdk.org Fri Nov 15 10:34:01 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 15 Nov 2024 10:34:01 GMT Subject: RFR: 8253440: serviceability/sa/TestJhsdbJstackLineNumbers.java failed with "Didn't find enough line numbers" In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 19:20:55 GMT, Chris Plummer wrote: > The test is checking to make sure SA will use what is in the bcp register to determine the current line number rather than just use frame->bcp, which often is not up to date. It spawns a debuggee that sits in a loop that is 10 lines of source. The test executes jstack on the debuggee and determines the current line number from the output. It does this 25 times and expectesto see at least 5 of the 10 line numbers being hit. There's no guarantee it will hit at least five. The chances of this not happening are very very low, but apparently the test has failed a couple of times because only 4 unique lines were hit. I decided to do the simple fix and just lower the threshhold to 4 lines. > > Ran locally on linux-x64. Tier1 in progress. aha yes that test is a bit of a gamble, we want to see n different numbers, with a range of 10 or less. If the line number is not being reported correctly, it seems unlikely we will see 4 different values, unless they just become random... 8-) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22117#pullrequestreview-2438244558 From jsjolen at openjdk.org Fri Nov 15 10:36:42 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 15 Nov 2024 10:36:42 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: Message-ID: <6UVcL2ZOtoalJCQVS3_GXu9pn6BvfdcMnMpTZsBdRH0=.7a1b9469-c266-4d35-9d1d-bb49fc4a3dd4@github.com> On Thu, 14 Nov 2024 21:35:52 GMT, Coleen Phillimore wrote: >> This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Updated the test with some comments. Hi Coleen, I agree with David here, I've no clue how this fixes the problem :). Could you expand on how this fix works? src/hotspot/share/classfile/verifier.cpp line 114: > 112: } > 113: > 114: // This method determines whether we allow package access in access checks in reflection. Style: "This method" prefix isn't necessary. Maybe just "Determine whether..."? or "Do we ...?" or "Returns true if and only if ..." ------------- PR Review: https://git.openjdk.org/jdk/pull/22116#pullrequestreview-2438240723 PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1843558145 From kevinw at openjdk.org Fri Nov 15 10:43:22 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 15 Nov 2024 10:43:22 GMT Subject: RFR: 8343529: serviceability/sa/ClhsdbWhere.java fails AssertionFailure: Corrupted constant pool In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:15:29 GMT, Chris Plummer wrote: > These two tests both do stack dumps with one or more active threads. This can result in SA throwing an exception if the thread is in a bad state. However, SA will still generate stack traces for all other threads, and the tests should still pass all the output checks, so we can safely ignore these exceptions and not fail the test as a result of them. > > Tested by running all SA tests 50 times on all supported platforms. Tier1 testing in progress. Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22123#pullrequestreview-2438262142 From coleenp at openjdk.org Fri Nov 15 12:08:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 12:08:50 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 05:45:48 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Purge last references to SecurityManager. > > src/hotspot/share/classfile/dictionary.cpp line 80: > >> 78: >> 79: void Dictionary::Config::free_node(void* context, void* memory, Value const& value) { >> 80: delete value; // Call DictionaryEntry destructor > > `using Value = XXX` seems like an unwanted/unnecessary abstraction in this code, because depending on what `XX` is you either will or won't need to call `delete`. That is a more general cleanup though. This is sort of the standard way we use the CHT. > src/hotspot/share/classfile/javaClasses.cpp line 1617: > >> 1615: macro(_holder_offset, k, "holder", thread_fieldholder_signature, false); \ >> 1616: macro(_name_offset, k, vmSymbols::name_name(), string_signature, false); \ >> 1617: macro(_contextClassLoader_offset, k, "contextClassLoader", classloader_signature, false); \ > > I didn't think the context class loader was related to SM in any way. ?? It isn't. This symbol was near the ones I deleted, and I deleted it by mistake, so I moved it here. > src/hotspot/share/logging/logDiagnosticCommand.hpp line 62: > >> 60: } >> 61: >> 62: static const JavaPermission permission() { > > Is any of this permission stuff still relevant? I couldn't figure out what ultimately looks at them. ?? I don't know that. It is passed by the MBean code. It might be another (different) opportunity for a cleanup if the MBean code doesn't use it anymore. > src/hotspot/share/prims/jvm.cpp line 154: > >> 152: */ >> 153: >> 154: extern void trace_class_resolution(Klass* to_class) { > > why `extern` ? jni.cpp functions call this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843665871 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843668071 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843668939 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1843667220 From coleenp at openjdk.org Fri Nov 15 12:28:43 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 12:28:43 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 05:23:24 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated the test with some comments. > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 90: > >> 88: } >> 89: >> 90: { // broken method > > Please add a comment showing the Java code this asm is implementing. This test came from asmifying java.lang.VerifyError and hacking it to have a VerifyError. The code it's implementing is a lot of code and not interesting. I can try cutting some things out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1843688929 From coleenp at openjdk.org Fri Nov 15 12:34:57 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 12:34:57 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 05:22:40 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated the test with some comments. > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 68: > >> 66: classWriter.visit(52, ACC_SUPER | ACC_PUBLIC, "java/lang/VerifyError", null, "java/lang/LinkageError", null); >> 67: { >> 68: fieldVisitor = classWriter.visitField(ACC_PRIVATE | ACC_FINAL | ACC_STATIC, "serialVersionUID", "J", null, new Long(7001962396098498785L)); > > Why do we need a serialVersionUID in this test class? TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.UnsupportedOperationException: class redefinition failed: attempted to change the schema (add/remove fields) Because it's a field in VerifyError ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1843695396 From ihse at openjdk.org Fri Nov 15 12:49:19 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 12:49:19 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b test/hotspot/jtreg/runtime/FieldLayout/ArrayBaseOffsets.java line 1: > 1: /* This file too suffered the same fate; all contents were removed but the file was not deleted. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1843710074 From stooke at openjdk.org Fri Nov 15 13:31:40 2024 From: stooke at openjdk.org (Simon Tooke) Date: Fri, 15 Nov 2024 13:31:40 GMT Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v8] In-Reply-To: References: Message-ID: > This is a port of #16301 to macOS. > > System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit. > > The System.map tests are also reworked to be cleaner for the three implementations. > > [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt) > [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt) Simon Tooke has updated the pull request incrementally with one additional commit since the last revision: some rework and fix core dump ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20953/files - new: https://git.openjdk.org/jdk/pull/20953/files/d63fa562..64a1f12a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=06-07 Stats: 54 lines in 1 file changed: 38 ins; 7 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/20953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20953/head:pull/20953 PR: https://git.openjdk.org/jdk/pull/20953 From alanb at openjdk.org Fri Nov 15 13:53:53 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Nov 2024 13:53:53 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v4] In-Reply-To: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> References: <2sSkqM0XA_sKandGlnJJDEjBzCSQuaOj4UTHQVEbBII=.6a6ea3c3-2c01-447f-8cbf-cc70dbc6df04@github.com> Message-ID: On Thu, 14 Nov 2024 14:42:30 GMT, Alan Bateman wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > > I see a few left over refs to SecurityManager in vmSymbols.hpp, vmClassMacros.hpp, and a comment in logDiagnosticCommand.hpp. > Thanks @AlanBateman There's a DCmd permissions() function that talks about DiagnosticCommandMBean security. I don't know what that is so I'm leaving it. Edit: appears unrelated. Right, no need to change anything there. MBeanServer's spec was changed by JEP 486 to still allow a security exception when access is not authorized. DiagnosticCommandMBean still supports permissions. Kevin Walls is doing a clean-up pass over the java.management and jdk.management to remove vestiges of the security manager but I don't know if he plans to check the VM code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2478883319 From ihse at openjdk.org Fri Nov 15 14:46:33 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 14:46:33 GMT Subject: RFR: 8344056: Use markdown format for man pages [v3] In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix regexes in CheckManPageOptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22081/files - new: https://git.openjdk.org/jdk/pull/22081/files/a8d4ea50..dbef493e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=01-02 Stats: 12 lines in 1 file changed: 3 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081 PR: https://git.openjdk.org/jdk/pull/22081 From ihse at openjdk.org Fri Nov 15 14:46:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 14:46:34 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix CheckManPageOptions test > - Remove classpath exception The CheckManPageOptions test had regexps that were not up to date with the latest changes in the markdown file. I fixed those and now the test passes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2479038178 From ihse at openjdk.org Fri Nov 15 14:46:34 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 14:46:34 GMT Subject: RFR: 8344056: Use markdown format for man pages [v2] In-Reply-To: <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com> Message-ID: On Fri, 15 Nov 2024 01:25:43 GMT, David Holmes wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix CheckManPageOptions test >> - Remove classpath exception > >> > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). >> >> _sigh_ >> >> > A candidate for an ignore list as fixing it is out of scope of this PR? >> >> Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix. > > I'm somewhat surprised that the full src tree is available to this test when it runs. I was expecting it to examine the .1 files in the JDK image. @dholmes-ora > I was expecting it to examine the .1 files in the JDK image. It's been like that since the test was created in https://bugs.openjdk.org/browse/JDK-8274211, so there is no change in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2479042569 From shade at openjdk.org Fri Nov 15 14:49:11 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 15 Nov 2024 14:49:11 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 Sonar findings: src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.cpp line 39: > 37: if (_use_age_table) { > 38: _age_table = new AgeTable(false); > 39: } Sonar caught it: Initialize `_age_table` to `nullptr` for extra safety. Current uses seem to be gated by `_use_age_table`, though. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1505: > 1503: size_t transferred_regions = 0; > 1504: ShenandoahLeftRightIterator iterator(&_partitions, which_collector, true); > 1505: idx_t rightmost = _partitions.rightmost_empty(which_collector); Sonar: `rightmost` is not used. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1567: > 1565: <= _partitions.rightmost(ShenandoahFreeSetPartitionId::Collector))) { > 1566: ShenandoahHeapLocker locker(_heap->lock()); > 1567: max_xfer_regions -= Sonar: Value stored to `max_xfer_regions` here is not used. src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1856: > 1854: size_t consumed_old_collector = 0; > 1855: size_t consumed_mutator = 0; > 1856: size_t available_old = 0; Sonar: `available_old` is not used. `available_young` is not used. src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 380: > 378: > 379: size_t old_evacuated = collection_set->get_old_bytes_reserved_for_evacuation(); > 380: size_t old_evacuated_committed = (size_t) (ShenandoahOldEvacWaste * old_evacuated); Sonar: implicit conversion from 'size_t' (aka 'unsigned long') to 'double' may lose precision Not sure if it breaks any math. src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 455: > 453: // excess_old < unaffiliated old: we can give back MIN(excess_old/region_size_bytes, unaffiliated_old_regions) > 454: size_t excess_regions = excess_old / region_size_bytes; > 455: size_t regions_to_xfer = MIN2(excess_regions, unaffiliated_old_regions); Sonar: Value stored to 'regions_to_xfer' during its initialization is never read src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 549: > 547: } > 548: if (r->age() >= tenuring_threshold) { > 549: if ((r->garbage() < old_garbage_threshold)) { Sonar: double parentheses. src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 276: > 274: // where abundance is defined as >= ShenGenHeap::plab_min_size(). In the former case, we try shrinking the > 275: // desired PLAB size to the minimum and retry PLAB allocation to avoid cascading of shared memory allocations. > 276: if (plab->words_remaining() < plab_min_size()) { Sonar caught it: There is a `plab != nullptr` check above at L267, which implies `plab` can be `nullptr` here? This would SEGV. src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 656: > 654: // may not evacuate the entirety of unprocessed candidates in a single mixed evacuation. > 655: const size_t max_evac_need = (size_t) > 656: (old_generation()->unprocessed_collection_candidates_live_memory() * ShenandoahOldEvacWaste); Sonar: implicit conversion from 'size_t' (aka 'unsigned long') to 'double' may lose precision Since this is a heuristics calculation, should we be precise here? src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 1003: > 1001: } > 1002: > 1003: namespace ShenandoahCompositeRegionClosure { We usually avoid `namespace`-s. See Hotspot style guide: https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.md#namespaces src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 89: > 87: } > 88: > 89: HeapWord* ShenandoahHeapRegion::allocate(size_t size, ShenandoahAllocRequest req) { Sonar caught it: `ShenandoahAllocRequest` should be passed by reference here? src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.hpp line 99: > 97: size_t region_size, size_t protocolVersion); > 98: > 99: uint _count = 0; Sonar caught it: this `_count` field does not seem to be used. src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 157: > 155: size_t card_at_start = _rs->card_index_for_addr(address); > 156: HeapWord* card_start_address = _rs->addr_for_card_index(card_at_start); > 157: uint8_t offset_in_card = address - card_start_address; Sonar: implicit conversion loses integer precision: 'long' to 'uint8_t' (aka 'unsigned char'). This looks risky. Should probably be `checked_cast(pointer_delta(address, card_start_address, 1))`? src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 889: > 887: size_t previous_group_span = _group_entries[0] * _group_chunk_size[0]; > 888: for (size_t i = 1; i < _num_groups; i++) { > 889: size_t previous_group_entries = (i == 1)? _group_entries[0]: (_group_entries[i-1] - _group_entries[i-2]); Sonar: Value stored to `previous_group_entries` during its initialization is never read ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2438690431 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843878467 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843904346 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843905277 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843912193 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843933121 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843906258 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843898116 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843857836 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843931737 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843872870 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843886835 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843892961 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843928920 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843907601 From ihse at openjdk.org Fri Nov 15 14:50:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 14:50:21 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: It's somewhat nicer to use \\s instead of space character in regex ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22081/files - new: https://git.openjdk.org/jdk/pull/22081/files/dbef493e..7cba61b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081 PR: https://git.openjdk.org/jdk/pull/22081 From cstein at openjdk.org Fri Nov 15 15:04:51 2024 From: cstein at openjdk.org (Christian Stein) Date: Fri, 15 Nov 2024 15:04:51 GMT Subject: RFR: 8344056: Use markdown format for man pages [v3] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Fri, 15 Nov 2024 14:46:33 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Fix regexes in CheckManPageOptions test/langtools/jdk/javadoc/tool/CheckManPageOptions.java line 277: > 275: > 276: // In the defining areas, option names are represented as follows: > 277: // `OPTION` or `OPTION` `OPTION` or `OPTION` ... where's the difference? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1843959156 From ihse at openjdk.org Fri Nov 15 15:11:46 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 15 Nov 2024 15:11:46 GMT Subject: RFR: 8344056: Use markdown format for man pages [v3] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: <_OybV6gt9rVOlg2n8GG48jDzgFsqLQ6GLi4R5TvZWTI=.b1f68ebb-dcd5-4fe1-b001-21628221d218@github.com> On Fri, 15 Nov 2024 15:00:39 GMT, Christian Stein wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix regexes in CheckManPageOptions > > test/langtools/jdk/javadoc/tool/CheckManPageOptions.java line 277: > >> 275: >> 276: // In the defining areas, option names are represented as follows: >> 277: // `OPTION` or `OPTION` > > `OPTION` or `OPTION` ... where's the difference? Some options have multiple variants displayed on a single row, like: `--classpath` or `-cp` This was handled in the troff format but not updated for markdown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1843969778 From shade at openjdk.org Fri Nov 15 15:18:09 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 15 Nov 2024 15:18:09 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 361: > 359: // frequently than last byte. This is true when number of clean cards is greater than number of dirty cards. > 360: static const uint16_t ObjectStartsInCardRegion = 0x80; > 361: static const uint16_t FirstStartBits = 0x7f; I see these are used to do operations against `uint8_t` (`....offsets.first`). Any reason why these should not be `uint8_t`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1843980993 From mdoerr at openjdk.org Fri Nov 15 15:18:09 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 15 Nov 2024 15:18:09 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> Message-ID: On Thu, 14 Nov 2024 23:39:08 GMT, Martin Doerr wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: > > Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" > > java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr > > Probably not a show-stopper. Should the test be adapted or disabled for this platform? > @TheRealMDoerr - do you have the logs from the test failure? If so, could you open a ticket with them in JBS? Thank you! Filed [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). In addition, we see the following tests failing with "java.lang.OutOfMemoryError: Java heap space" on all Shenandoah platforms: gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#default gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#generational Can you reproduce those? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2479110413 From coleenp at openjdk.org Fri Nov 15 15:30:05 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 15:30:05 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: > This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22116/files - new: https://git.openjdk.org/jdk/pull/22116/files/af6b1e12..5ce8068b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22116&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22116&range=01-02 Stats: 67 lines in 4 files changed: 18 ins; 47 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22116.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22116/head:pull/22116 PR: https://git.openjdk.org/jdk/pull/22116 From coleenp at openjdk.org Fri Nov 15 15:30:06 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 15:30:06 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: <6UVcL2ZOtoalJCQVS3_GXu9pn6BvfdcMnMpTZsBdRH0=.7a1b9469-c266-4d35-9d1d-bb49fc4a3dd4@github.com> References: <6UVcL2ZOtoalJCQVS3_GXu9pn6BvfdcMnMpTZsBdRH0=.7a1b9469-c266-4d35-9d1d-bb49fc4a3dd4@github.com> Message-ID: <9WndY_bhsyG1dvNHk6TlyrAg7vkkzg4CGwOD7xHwPGY=.78cf3247-e0e5-4504-9ff9-f1bb4f75626f@github.com> On Fri, 15 Nov 2024 10:29:33 GMT, Johan Sj?len wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Updated the test with some comments. > > src/hotspot/share/classfile/verifier.cpp line 114: > >> 112: } >> 113: >> 114: // This method determines whether we allow package access in access checks in reflection. > > Style: "This method" prefix isn't necessary. Maybe just "Determine whether..."? or "Do we ...?" or "Returns true if and only if ..." I added "This method" because the two methods right next to each other look the same but are different. I want to say this one does one thing and this other one does something subtly different. And it makes it a complete sentence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1844024244 From coleenp at openjdk.org Fri Nov 15 15:30:07 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 15:30:07 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 05:24:17 GMT, David Holmes wrote: >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 71: >> >>> 69: fieldVisitor.visitEnd(); >>> 70: } >>> 71: { >> >> Please add a comment showing the Java code this asm is implementing. > > Actually why do you even need this constructor now? For redefinition, you can't add or delete methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1844020681 From iklam at openjdk.org Fri Nov 15 16:02:46 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 16:02:46 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v13] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 181 commits: - Merge branch 'master' into jep-483-candidate - fixed typo in make/RunTests.gmk comments - Merge branch 'master' into jep-483-candidate - Merge branch 'master' into jep-483-candidate - fixed merge with UseCompactObjectHeaders - Merge branch 'master' into jep-483-candidate - fixed merge - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline - @DanHeidinga comment -- exit VM when runtimeSetup() fails - fixed merge - ... and 171 more: https://git.openjdk.org/jdk/compare/40a055eb...b317b4b5 ------------- Changes: https://git.openjdk.org/jdk/pull/21642/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=12 Stats: 7192 lines in 107 files changed: 6358 ins; 513 del; 321 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From cstein at openjdk.org Fri Nov 15 16:04:19 2024 From: cstein at openjdk.org (Christian Stein) Date: Fri, 15 Nov 2024 16:04:19 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > It's somewhat nicer to use \\s instead of space character in regex Marked as reviewed by cstein (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2439039366 From iklam at openjdk.org Fri Nov 15 16:38:20 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 16:38:20 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v14] In-Reply-To: References: Message-ID: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed test after security manager removal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21642/files - new: https://git.openjdk.org/jdk/pull/21642/files/b317b4b5..5d9a6677 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=12-13 Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/21642.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642 PR: https://git.openjdk.org/jdk/pull/21642 From jrose at openjdk.org Fri Nov 15 17:04:59 2024 From: jrose at openjdk.org (John R Rose) Date: Fri, 15 Nov 2024 17:04:59 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v14] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test after security manager removal Reviewed again. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2439181309 From wkemper at openjdk.org Fri Nov 15 17:20:11 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 17:20:11 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 15 Nov 2024 14:05:51 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 276: > >> 274: // where abundance is defined as >= ShenGenHeap::plab_min_size(). In the former case, we try shrinking the >> 275: // desired PLAB size to the minimum and retry PLAB allocation to avoid cascading of shared memory allocations. >> 276: if (plab->words_remaining() < plab_min_size()) { > > Sonar caught it: There is a `plab != nullptr` check above at L267, which implies `plab` can be `nullptr` here? This would SEGV. https://bugs.openjdk.org/browse/JDK-8344320 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844209761 From wkemper at openjdk.org Fri Nov 15 17:29:08 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 17:29:08 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 15 Nov 2024 14:11:10 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahEvacTracker.cpp line 39: > >> 37: if (_use_age_table) { >> 38: _age_table = new AgeTable(false); >> 39: } > > Sonar caught it: Initialize `_age_table` to `nullptr` for extra safety. Current uses seem to be gated by `_use_age_table`, though. https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1856: > >> 1854: size_t consumed_old_collector = 0; >> 1855: size_t consumed_mutator = 0; >> 1856: size_t available_old = 0; > > Sonar: `available_old` is not used. `available_young` is not used. https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 380: > >> 378: >> 379: size_t old_evacuated = collection_set->get_old_bytes_reserved_for_evacuation(); >> 380: size_t old_evacuated_committed = (size_t) (ShenandoahOldEvacWaste * old_evacuated); > > Sonar: implicit conversion from 'size_t' (aka 'unsigned long') to 'double' may lose precision > > Not sure if it breaks any math. https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 656: > >> 654: // may not evacuate the entirety of unprocessed candidates in a single mixed evacuation. >> 655: const size_t max_evac_need = (size_t) >> 656: (old_generation()->unprocessed_collection_candidates_live_memory() * ShenandoahOldEvacWaste); > > Sonar: implicit conversion from 'size_t' (aka 'unsigned long') to 'double' may lose precision > > Since this is a heuristics calculation, should we be precise here? https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 89: > >> 87: } >> 88: >> 89: HeapWord* ShenandoahHeapRegion::allocate(size_t size, ShenandoahAllocRequest req) { > > Sonar caught it: `ShenandoahAllocRequest` should be passed by reference here? https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.hpp line 99: > >> 97: size_t region_size, size_t protocolVersion); >> 98: >> 99: uint _count = 0; > > Sonar caught it: this `_count` field does not seem to be used. https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 157: > >> 155: size_t card_at_start = _rs->card_index_for_addr(address); >> 156: HeapWord* card_start_address = _rs->addr_for_card_index(card_at_start); >> 157: uint8_t offset_in_card = address - card_start_address; > > Sonar: implicit conversion loses integer precision: 'long' to 'uint8_t' (aka 'unsigned char'). > > This looks risky. Should probably be `checked_cast(pointer_delta(address, card_start_address, 1))`? https://bugs.openjdk.org/browse/JDK-8344321 > src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 889: > >> 887: size_t previous_group_span = _group_entries[0] * _group_chunk_size[0]; >> 888: for (size_t i = 1; i < _num_groups; i++) { >> 889: size_t previous_group_entries = (i == 1)? _group_entries[0]: (_group_entries[i-1] - _group_entries[i-2]); > > Sonar: Value stored to `previous_group_entries` during its initialization is never read https://bugs.openjdk.org/browse/JDK-8344321 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844218002 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219136 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219821 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219644 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844218123 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844218269 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219351 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844219014 From alanb at openjdk.org Fri Nov 15 17:58:37 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 15 Nov 2024 17:58:37 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.lang.instrument In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:03:28 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > test/jdk/java/lang/instrument/ still passing. src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 484: > 482: // reflected object (for example, a method) > 483: private static void setAccessible(final AccessibleObject ao, final boolean accessible) { > 484: ao.setAccessible(accessible); I think you can remove this method, and instead change the usage in loadClassAndStartAgent to just call setAccessible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22106#discussion_r1842363414 From kevinw at openjdk.org Fri Nov 15 17:58:38 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 15 Nov 2024 17:58:38 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.lang.instrument In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 14:53:44 GMT, Alan Bateman wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> test/jdk/java/lang/instrument/ still passing. > > src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 484: > >> 482: // reflected object (for example, a method) >> 483: private static void setAccessible(final AccessibleObject ao, final boolean accessible) { >> 484: ao.setAccessible(accessible); > > I think you can remove this method, and instead change the usage in loadClassAndStartAgent to just call setAccessible. will do, yes it is trivial now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22106#discussion_r1842367446 From kevinw at openjdk.org Fri Nov 15 17:58:37 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 15 Nov 2024 17:58:37 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.lang.instrument Message-ID: Remove redundant SecurityManager, AccessController references (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). test/jdk/java/lang/instrument/ still passing. ------------- Commit messages: - update - 8344187: Remove SecurityManager and related calls from java.instrument Changes: https://git.openjdk.org/jdk/pull/22106/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344187 Stats: 31 lines in 2 files changed: 0 ins; 25 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22106.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22106/head:pull/22106 PR: https://git.openjdk.org/jdk/pull/22106 From kevinw at openjdk.org Fri Nov 15 18:11:16 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 15 Nov 2024 18:11:16 GMT Subject: RFR: 8344105: Remove SecurityManager and related calls from jdk.attach and jdk.hotspot.agent [v2] In-Reply-To: References: Message-ID: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into 8344105_post_sm - Property fetch update - 8344105: Remove SecurityManager and related calls from jdk.attach and jdk.hotspot.agent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22067/files - new: https://git.openjdk.org/jdk/pull/22067/files/3110091d..72b29b80 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22067&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22067&range=00-01 Stats: 20872 lines in 657 files changed: 10218 ins; 7055 del; 3599 mod Patch: https://git.openjdk.org/jdk/pull/22067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22067/head:pull/22067 PR: https://git.openjdk.org/jdk/pull/22067 From lmesnik at openjdk.org Fri Nov 15 20:55:06 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 20:55:06 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks Message-ID: Hi Could you please "pre-review" this fix that add locks information. I want to get some preliminary feedback before completing the changes. Here is the motivation for this rfe and explanation why I add it into SA now. The information about current owners of Hotspot Mutex is often very useful for dealock investigations. The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. Also the debugger solution is OS specifc. The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. The example of output: [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 Attaching to process ID 1620533, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24-internal-adhoc.lmesnik.open Deadlock Detection: No deadlocks found. Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 ----------------- 1620559 ----------------- "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked 0x00007f8cff11e88d syscall + 0x1d 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b ..... ----------------- 1620554 ----------------- "LockerThread" #31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition [0x00007f8cc1dfe000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked 0x00007f8cff091117 __GI___futex_abstimed_wait_cancelable64 + 0xe7 0x00007f8cff093a41 __GI___pthread_cond_wait + 0x211 ------------- Commit messages: - years updated - fixed spaces - Merge branch 'master' of https://github.com/openjdk/jdk into sa-lock - Merge branch 'sa-lock' of https://github.com/lmesnik/jdk into sa-lock - Merge branch 'master' into sa-lock - spaces fixed - fixed product builds - updated test - ident - polish - ... and 10 more: https://git.openjdk.org/jdk/compare/c388455d...606dcc03 Changes: https://git.openjdk.org/jdk/pull/21943/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21943&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343741 Stats: 457 lines in 14 files changed: 383 ins; 69 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21943/head:pull/21943 PR: https://git.openjdk.org/jdk/pull/21943 From sspitsyn at openjdk.org Fri Nov 15 20:55:06 2024 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 15 Nov 2024 20:55:06 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 01:11:14 GMT, Leonid Mesnik wrote: > Hi > Could you please "pre-review" this fix that add locks information. I want to get some preliminary feedback before completing the changes. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" #31 prio=5 tid=0x00007f8cf8309a00 nid=16... src/hotspot/share/runtime/mutex.cpp line 270: > 268: } > 269: > 270: static const int MAX_NUM_MUTEX = 1204; Q: Is the number `1204` intentional or it was supposed to be `1024`? :) src/hotspot/share/runtime/mutex.cpp line 275: > 273: int Mutex::_num_mutex = 0; > 274: > 275: void Mutex::add_mutex(Mutex* var) { Nit: Why `var` but not `arg`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21943#discussion_r1839729824 PR Review Comment: https://git.openjdk.org/jdk/pull/21943#discussion_r1839731580 From lmesnik at openjdk.org Fri Nov 15 20:55:06 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 20:55:06 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 08:26:57 GMT, Serguei Spitsyn wrote: >> Hi >> Could you please "pre-review" this fix that add locks information. I want to get some preliminary feedback before completing the changes. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> -------... > > src/hotspot/share/runtime/mutex.cpp line 270: > >> 268: } >> 269: >> 270: static const int MAX_NUM_MUTEX = 1204; > > Q: Is the number `1204` intentional or it was supposed to be `1024`? :) This codes with MAX_NUM_MUTEX = 1204 and void Mutex::add_mutex(Mutex* var) { has been just moved from mutexLocker. I haven't changed it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21943#discussion_r1841198179 From amenkov at openjdk.org Fri Nov 15 21:10:24 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 15 Nov 2024 21:10:24 GMT Subject: RFR: 8344262: Win32AttachOperationRequest objects are created by using global new Message-ID: The issue was introduced by [JDK-8339289](https://bugs.openjdk.org/browse/JDK-8339289). The fix makes `Win32AttachOperationRequest` successor of `CHeapObj`, so `Win32AttachOperationRequest` inherits its `new` operator testing: tier1..tier4 ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/22166/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22166&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344262 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22166.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22166/head:pull/22166 PR: https://git.openjdk.org/jdk/pull/22166 From lmesnik at openjdk.org Fri Nov 15 21:28:42 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 21:28:42 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v2] In-Reply-To: References: Message-ID: > Hi > Could you please review this fix that add locks information. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" #31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition [0x00007f8cc1dfe000] > java.lang.Thread.State: RU... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: test updated ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21943/files - new: https://git.openjdk.org/jdk/pull/21943/files/606dcc03..4fcd6eeb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21943&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21943&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21943/head:pull/21943 PR: https://git.openjdk.org/jdk/pull/21943 From lmesnik at openjdk.org Fri Nov 15 21:28:43 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 21:28:43 GMT Subject: Withdrawn: 8343741: SA jstack --mixed should print information about VM locks In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 01:11:14 GMT, Leonid Mesnik wrote: > Hi > Could you please review this fix that add locks information. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" #28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" #31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition [0x00007f8cc1dfe000] > java.lang.Thread.State: RU... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/21943 From iklam at openjdk.org Fri Nov 15 22:22:49 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 22:22:49 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v14] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test after security manager removal Thanks everyone for the review and support! I ran tiers 1~8 several times in the past few days when merging with mainline. No regressions found. GHA error is timeout and seems to be unrelated. Integrating now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2480037673 From iklam at openjdk.org Fri Nov 15 22:31:55 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 22:31:55 GMT Subject: Integrated: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking In-Reply-To: References: Message-ID: <4xos88WJsJcF3QMs1xI1sEacUTohEe70qrJZQHEczXY=.05b9a85a-2a2e-40bc-aeac-fb682fff88ff@github.com> On Tue, 22 Oct 2024 16:19:48 GMT, Ioi Lam wrote: > This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). > > ---- > Note: this is a combined PR of the following individual PRs > - https://github.com/openjdk/jdk/pull/20516 > - https://github.com/openjdk/jdk/pull/20517 > - https://github.com/openjdk/jdk/pull/20843 > - https://github.com/openjdk/jdk/pull/20958 > - https://github.com/openjdk/jdk/pull/20959 > - https://github.com/openjdk/jdk/pull/21049 > - https://github.com/openjdk/jdk/pull/21143 This pull request has now been integrated. Changeset: 41a2d49f Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/41a2d49f0a1ed298b8ab023ce634335464454fe7 Stats: 7188 lines in 107 files changed: 6354 ins; 513 del; 321 mod 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking Reviewed-by: jrose, kvn, heidinga, asmehra, vlivanov ------------- PR: https://git.openjdk.org/jdk/pull/21642 From lmesnik at openjdk.org Fri Nov 15 23:41:13 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 15 Nov 2024 23:41:13 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks Message-ID: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Hi Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. Here is the motivation for this rfe and explanation why I add it into SA now. The information about current owners of Hotspot Mutex is often very useful for dealock investigations. The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. Also the debugger solution is OS specifc. The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. The example of output: [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 Attaching to process ID 1620533, please wait... Debugger attached successfully. Server compiler detected. JVM version is 24-internal-adhoc.lmesnik.open Deadlock Detection: No deadlocks found. Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 ----------------- 1620559 ----------------- "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked 0x00007f8cff11e88d syscall + 0x1d 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b ..... ----------------- 1620554 ----------------- "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition [0x00007f8cc1dfe000] java.lang.Thread.State: RUNNABLE JavaThread state: _thread_blocked 0x00007f8cff091117 __GI___futex_abstimed_wait_cancelable64 + 0xe7 0x00007f8cff093a41 __GI___pthread_cond_wait + 0x211 ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/22171/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343741 Stats: 452 lines in 14 files changed: 379 ins; 69 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From coleenp at openjdk.org Fri Nov 15 23:43:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 15 Nov 2024 23:43:33 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Handle merge conflicts in new resolve_instance_class calls. - Merge branch 'master' into protection-domain - Purge last references to SecurityManager. - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). - Found more obsolete security manager code. - More purging of AccessController, AccessControlContext and some stackwalking questions. - David comments. - Remove some more includes. - 8341916: Remove ProtectionDomain related hotspot code and tests ------------- Changes: https://git.openjdk.org/jdk/pull/22064/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=05 Stats: 1416 lines in 48 files changed: 1 ins; 1245 del; 170 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From iklam at openjdk.org Fri Nov 15 23:46:49 2024 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 15 Nov 2024 23:46:49 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 23:43:33 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Handle merge conflicts in new resolve_instance_class calls. > - Merge branch 'master' into protection-domain > - Purge last references to SecurityManager. > - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > - Found more obsolete security manager code. > - More purging of AccessController, AccessControlContext and some stackwalking questions. > - David comments. > - Remove some more includes. > - 8341916: Remove ProtectionDomain related hotspot code and tests LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2439937392 From wkemper at openjdk.org Fri Nov 15 23:55:08 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 15 Nov 2024 23:55:08 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> Message-ID: On Fri, 15 Nov 2024 15:12:30 GMT, Martin Doerr wrote: >> The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: >> >> Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" >> >> java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr >> >> Probably not a show-stopper. Should the test be adapted or disabled for this platform? > >> @TheRealMDoerr - do you have the logs from the test failure? If so, could you open a ticket with them in JBS? Thank you! > > Filed [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). > > In addition, we see the following tests failing with "java.lang.OutOfMemoryError: Java heap space" on all Shenandoah platforms: > gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#default > gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#generational > Can you reproduce those? @TheRealMDoerr - Yes, those tests failed for me. I'll look into them. I'm also working to get my hands on a PPC64 machine to investigate [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). We appreciate your help here! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2480152786 From vaivanov at openjdk.org Sat Nov 16 00:41:20 2024 From: vaivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 16 Nov 2024 00:41:20 GMT Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be optimized Message-ID: Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement. ------------- Commit messages: - 8341481: [perf] vframeStreamCommon constructor may be optimized - 8341481 [Perf] vframeStreamCommon constructor may be optimized Changes: https://git.openjdk.org/jdk/pull/22173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341481 Stats: 31 lines in 5 files changed: 11 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/22173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22173/head:pull/22173 PR: https://git.openjdk.org/jdk/pull/22173 From lmesnik at openjdk.org Sat Nov 16 02:49:35 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 16 Nov 2024 02:49:35 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v2] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: added short sleep into the loop. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/c302f918..93229db3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From jrose at openjdk.org Sat Nov 16 02:50:58 2024 From: jrose at openjdk.org (John R Rose) Date: Sat, 16 Nov 2024 02:50:58 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: Message-ID: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> On Fri, 15 Nov 2024 23:43:33 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Handle merge conflicts in new resolve_instance_class calls. > - Merge branch 'master' into protection-domain > - Purge last references to SecurityManager. > - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > - Found more obsolete security manager code. > - More purging of AccessController, AccessControlContext and some stackwalking questions. > - David comments. > - Remove some more includes. > - 8341916: Remove ProtectionDomain related hotspot code and tests Changes requested by jrose (Reviewer). src/hotspot/share/classfile/systemDictionary.hpp line 41: > 39: // represented as null. > 40: > 41: // The underlying data structure is an concurrent hash table (Dictionary) per typo: s/an concurrent/a concurrent/ src/hotspot/share/classfile/systemDictionary.hpp line 245: > 243: // compute java_mirror (java.lang.Class instance) for a type ("I", "[[B", "LFoo;", etc.) > 244: // Either the accessing_klass or the CL can be non-null, but not both. > 245: // Callee will fill in CL from the accessing klass, if they are needed. The two comment lines ("Either ? Callee ?") should be one line: + // Callee will fill in CL from the accessing klass, if the CL is needed. src/hotspot/share/prims/jvm.cpp line 169: > 167: while (!vfst.at_end()) { > 168: Method* m = vfst.method(); > 169: if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())) { We are no longer skipping AC frames, but user code will continue to use AC calls, even if they are silly. Will this affect any existing caller-sensitive calculations? The failure mode would be that a "get-caller-class" query would return AC.class, not the caller of the AC method. ------------- PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2440266470 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844882878 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844883410 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844884671 From jrose at openjdk.org Sat Nov 16 03:29:32 2024 From: jrose at openjdk.org (John R Rose) Date: Sat, 16 Nov 2024 03:29:32 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 23:43:33 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Handle merge conflicts in new resolve_instance_class calls. > - Merge branch 'master' into protection-domain > - Purge last references to SecurityManager. > - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). > - Found more obsolete security manager code. > - More purging of AccessController, AccessControlContext and some stackwalking questions. > - David comments. > - Remove some more includes. > - 8341916: Remove ProtectionDomain related hotspot code and tests Except for a couple of suggested tweaks to comments, it all looks correct. Thanks! ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2440284811 From jrose at openjdk.org Sat Nov 16 03:29:33 2024 From: jrose at openjdk.org (John R Rose) Date: Sat, 16 Nov 2024 03:29:33 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> References: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> Message-ID: On Sat, 16 Nov 2024 02:48:09 GMT, John R Rose wrote: >> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - Handle merge conflicts in new resolve_instance_class calls. >> - Merge branch 'master' into protection-domain >> - Purge last references to SecurityManager. >> - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). >> - Found more obsolete security manager code. >> - More purging of AccessController, AccessControlContext and some stackwalking questions. >> - David comments. >> - Remove some more includes. >> - 8341916: Remove ProtectionDomain related hotspot code and tests > > src/hotspot/share/prims/jvm.cpp line 169: > >> 167: while (!vfst.at_end()) { >> 168: Method* m = vfst.method(); >> 169: if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())) { > > We are no longer skipping AC frames, but user code will continue to use AC calls, even if they are silly. Will this affect any existing caller-sensitive calculations? The failure mode would be that a "get-caller-class" query would return AC.class, not the caller of the AC method. (Wait, I think my comment is in the wrong place. This is just tracing code, but I thought I saw a similar change for the general walker code?) Right, cancel the previous comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844892667 From jwaters at openjdk.org Sat Nov 16 05:20:10 2024 From: jwaters at openjdk.org (Julian Waters) Date: Sat, 16 Nov 2024 05:20:10 GMT Subject: RFR: 8344262: Win32AttachOperationRequest objects are created by using global new In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 21:05:21 GMT, Alex Menkov wrote: > The issue was introduced by [JDK-8339289](https://bugs.openjdk.org/browse/JDK-8339289). > The fix makes `Win32AttachOperationRequest` successor of `CHeapObj`, so `Win32AttachOperationRequest` inherits its `new` operator > > testing: tier1..tier4 Ah, you beat me to it. Thanks for the fix! ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/22166#pullrequestreview-2440305957 From lmesnik at openjdk.org Sat Nov 16 05:21:40 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sat, 16 Nov 2024 05:21:40 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v3] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: make test more robust ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/93229db3..0fb641c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=01-02 Stats: 35 lines in 3 files changed: 21 ins; 1 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From dholmes at openjdk.org Sat Nov 16 12:24:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Sat, 16 Nov 2024 12:24:42 GMT Subject: RFR: 8344191: Build code should not have classpath exception In-Reply-To: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com> References: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com> Message-ID: On Fri, 15 Nov 2024 00:07:07 GMT, Magnus Ihse Bursie wrote: > The policy has long been to use Classpath Exception in the `src` and `make` directories, but not in the `test` directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down. What policy is that? The Classpath exception is for executing classfiles. It is meaningless in any other context. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2480542305 From coleenp at openjdk.org Sat Nov 16 14:25:30 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 16 Nov 2024 14:25:30 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v7] In-Reply-To: References: Message-ID: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: Fix comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22064/files - new: https://git.openjdk.org/jdk/pull/22064/files/14e11e59..dd1766ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22064&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22064.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22064/head:pull/22064 PR: https://git.openjdk.org/jdk/pull/22064 From coleenp at openjdk.org Sat Nov 16 14:25:32 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 16 Nov 2024 14:25:32 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> References: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> Message-ID: On Sat, 16 Nov 2024 02:41:59 GMT, John R Rose wrote: >> Coleen Phillimore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - Handle merge conflicts in new resolve_instance_class calls. >> - Merge branch 'master' into protection-domain >> - Purge last references to SecurityManager. >> - More obsolete code. Fix trace_class_resolution (doesn't throw exception - shouldn't take TRAPS). >> - Found more obsolete security manager code. >> - More purging of AccessController, AccessControlContext and some stackwalking questions. >> - David comments. >> - Remove some more includes. >> - 8341916: Remove ProtectionDomain related hotspot code and tests > > src/hotspot/share/classfile/systemDictionary.hpp line 41: > >> 39: // represented as null. >> 40: >> 41: // The underlying data structure is an concurrent hash table (Dictionary) per > > typo: s/an concurrent/a concurrent/ Fixed. > src/hotspot/share/classfile/systemDictionary.hpp line 245: > >> 243: // compute java_mirror (java.lang.Class instance) for a type ("I", "[[B", "LFoo;", etc.) >> 244: // Either the accessing_klass or the CL can be non-null, but not both. >> 245: // Callee will fill in CL from the accessing klass, if they are needed. > > The two comment lines ("Either ? Callee ?") should be one line: > > > + // Callee will fill in CL from the accessing klass, if the CL is needed. One line would be too long and the comment doesn't make any sense anyway. The accessing_klass is never null and the callee doesn't do anything with the class loader, ie it doesn't pass it in. So I deleted the last two comment lines. We should clean this up later to reflect reality. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844986641 PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844986893 From coleenp at openjdk.org Sat Nov 16 14:25:33 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Sat, 16 Nov 2024 14:25:33 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v6] In-Reply-To: References: <7I8Yw-5pVWAHnlsEIVKq54gRMuLHd0K3l7zSdKJH9L8=.5ab13bd7-9c27-4bda-9a60-8bd30c9a6fd6@github.com> Message-ID: On Sat, 16 Nov 2024 03:22:01 GMT, John R Rose wrote: >> src/hotspot/share/prims/jvm.cpp line 169: >> >>> 167: while (!vfst.at_end()) { >>> 168: Method* m = vfst.method(); >>> 169: if (!vfst.method()->method_holder()->is_subclass_of(vmClasses::ClassLoader_klass())) { >> >> We are no longer skipping AC frames, but user code will continue to use AC calls, even if they are silly. Will this affect any existing caller-sensitive calculations? The failure mode would be that a "get-caller-class" query would return AC.class, not the caller of the AC method. > > (Wait, I think my comment is in the wrong place. This is just tracing code, but I thought I saw a similar change for the general walker code?) > > Right, cancel the previous comment. Yes, we still have the security stack walk without this using the caller sensitive mechanism. This was only for logging. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1844986976 From kdnilsen at openjdk.org Sat Nov 16 17:57:01 2024 From: kdnilsen at openjdk.org (Kelvin Nilsen) Date: Sat, 16 Nov 2024 17:57:01 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Wed, 13 Nov 2024 23:21:24 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp line 83: >> >>> 81: void VM_ShenandoahInitMark::doit() { >>> 82: ShenandoahGCPauseMark mark(_gc_id, "Init Mark", SvcGCMarker::CONCURRENT); >>> 83: set_active_generation(); >> >> Why is it here, and not down in `entry_*` methods, probably in helper classes? > > I think it's here for the same reason `propagate_gc_state_to_java_threads` is here. Having it here makes it easier to see that this critical synchronization step happens for every safepoint. I'm inclined to leave as is, not wanting to disrupt stability of code that is known to be working. But if there is strong preference otherwise, we can make a change... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1845149976 From mbaesken at openjdk.org Sun Nov 17 02:09:38 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Sun, 17 Nov 2024 02:09:38 GMT Subject: RFR: 8344298: Test tools/sincechecker/modules/jdk.hotspot.agent/JdkHotspotAgentCheckSince.java fails on platforms without sa Message-ID: E.g. on AIx we run into this test failure : error: module not found: jdk.hotspot.agent Unable to retrieve `@since` for Module: module: jdk.hotspot.agent java.lang.Exception: The `@since` checker found 1 problems at SinceChecker.checkModule(SinceChecker.java:284) at SinceChecker.main(SinceChecker.java:145) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) at java.base/java.lang.reflect.Method.invoke(Method.java:565) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1447) So we should probably limit the execution of this test to jdk with sa support. ------------- Commit messages: - JDK-8344298 Changes: https://git.openjdk.org/jdk/pull/22146/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344298 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22146/head:pull/22146 PR: https://git.openjdk.org/jdk/pull/22146 From lucy at openjdk.org Sun Nov 17 02:09:38 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Sun, 17 Nov 2024 02:09:38 GMT Subject: RFR: 8344298: Test tools/sincechecker/modules/jdk.hotspot.agent/JdkHotspotAgentCheckSince.java fails on platforms without sa In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 12:04:08 GMT, Matthias Baesken wrote: > E.g. on AIx we run into this test failure : > error: module not found: jdk.hotspot.agent > Unable to retrieve `@since` for Module: module: jdk.hotspot.agent > java.lang.Exception: The `@since` checker found 1 problems > at SinceChecker.checkModule(SinceChecker.java:284) > at SinceChecker.main(SinceChecker.java:145) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) > at java.base/java.lang.Thread.run(Thread.java:1447) > > So we should probably limit the execution of this test to jdk with sa support. LGTM. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22146#pullrequestreview-2438432058 From rsunderbabu at openjdk.org Sun Nov 17 04:37:18 2024 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Sun, 17 Nov 2024 04:37:18 GMT Subject: RFR: 8318668: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java fails with Xcomp Message-ID: Trivial change to exclude the test from running with Xcomp flag. The test fails because the number of GCs as reported by the MXBean doesn't match the expected number. This is due to the additional GC happening due to CodeCache crossing its threshold. We could increase the code cache or restrict the specific compiler that fills the cache. But this will not completely eliminate the possibility as cache size could be overridden or the same failure can happen for a different compiler. So, it is better to restrict the Xcomp flag as a whole. Testing: Only local testing done as it is trivial change. One run with Xcomp and another without any flags. ------------- Commit messages: - Excluding the test for Xcomp Changes: https://git.openjdk.org/jdk/pull/22180/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22180&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318668 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22180/head:pull/22180 PR: https://git.openjdk.org/jdk/pull/22180 From eirbjo at openjdk.org Sun Nov 17 18:29:15 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 17 Nov 2024 18:29:15 GMT Subject: RFR: 8344364: Remove unused SecurityManager-related imports from java.lang.instrument.ClassFileTransformer Message-ID: <4dyuFoNkbEj857BGKdeA-EiYsXb5TiqjunpCDvbrlpg=.c1be84bb-1af8-4587-9d55-5353df76a87a@github.com> Please review this trivial cleanup which removes unused imports of `java.security.AccessController` and `java.security.PrivilegedAction` from `java.lang.instrument.ClassFileTransformer`. History: These imports came with the new transform method introduced by the module system implementation in JDK-8142968 and were left unused when JDK-8159147 instead added a ClassLoader parameter to the new transform method. Verification: `make images` succeeds. ------------- Commit messages: - Remove unused imports Changes: https://git.openjdk.org/jdk/pull/22184/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22184&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344364 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22184.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22184/head:pull/22184 PR: https://git.openjdk.org/jdk/pull/22184 From iris at openjdk.org Mon Nov 18 01:35:07 2024 From: iris at openjdk.org (Iris Clark) Date: Mon, 18 Nov 2024 01:35:07 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > It's somewhat nicer to use \\s instead of space character in regex Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2441317522 From dholmes at openjdk.org Mon Nov 18 02:44:43 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 02:44:43 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 12:32:14 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 68: >> >>> 66: classWriter.visit(52, ACC_SUPER | ACC_PUBLIC, "java/lang/VerifyError", null, "java/lang/LinkageError", null); >>> 67: { >>> 68: fieldVisitor = classWriter.visitField(ACC_PRIVATE | ACC_FINAL | ACC_STATIC, "serialVersionUID", "J", null, new Long(7001962396098498785L)); >> >> Why do we need a serialVersionUID in this test class? > > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.UnsupportedOperationException: class redefinition failed: attempted to change the schema (add/remove fields) > > Because it's a field in VerifyError Got it. >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 90: >> >>> 88: } >>> 89: >>> 90: { // broken method >> >> Please add a comment showing the Java code this asm is implementing. > > This test came from asmifying java.lang.VerifyError and hacking it to have a VerifyError. The code it's implementing is a lot of code and not interesting. I can try cutting some things out. I hadn't quite grasped the basic operation of the test - I get it now. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1845770225 PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1845772256 From dholmes at openjdk.org Mon Nov 18 02:44:44 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 02:44:44 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v2] In-Reply-To: References: Message-ID: <4dK0XnlqC2QWMBBdX5Elobeiuz9ZOOz446qh1ezb2uw=.5e4e7bd3-e9e6-444e-9bff-e33d37a1f7d8@github.com> On Fri, 15 Nov 2024 15:26:26 GMT, Coleen Phillimore wrote: >> Actually why do you even need this constructor now? > > For redefinition, you can't add or delete methods. Got it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1845770342 From dholmes at openjdk.org Mon Nov 18 03:04:48 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 03:04:48 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v7] In-Reply-To: References: Message-ID: On Sat, 16 Nov 2024 14:25:30 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22064#pullrequestreview-2441407116 From dholmes at openjdk.org Mon Nov 18 03:04:49 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 03:04:49 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 12:04:37 GMT, Coleen Phillimore wrote: >> src/hotspot/share/prims/jvm.cpp line 154: >> >>> 152: */ >>> 153: >>> 154: extern void trace_class_resolution(Klass* to_class) { >> >> why `extern` ? > > jni.cpp functions call this. I don't see any difference in the callers in relation to this PR and the function is not presently declared `extern`. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1845791576 From dholmes at openjdk.org Mon Nov 18 05:37:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 05:37:55 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v3] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Sat, 16 Nov 2024 05:21:40 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > make test more robust Just a couple of drive-by comments/suggestions. The functionality seems like a reasonable addition. Thanks src/hotspot/share/prims/whitebox.cpp line 190: > 188: WB_END > 189: > 190: WB_ENTRY(jint, WB_LockAndStuckInSafepoint(JNIEnv* env, jobject wb)) Suggestion: WB_ENTRY(jint, WB_TakeLockAndHangInSafepoint(JNIEnv* env, jobject wb)) src/hotspot/share/runtime/vmOperations.hpp line 64: > 62: > 63: // used by whitebox API to emulate VM issues > 64: // when VM can't operate and doesn't respond to jcm Suggestion: // when VM can't operate and doesn't respond to jcmd src/hotspot/share/runtime/vmOperations.hpp line 65: > 63: // used by whitebox API to emulate VM issues > 64: // when VM can't operate and doesn't respond to jcm > 65: class VM_ForceSafepointStuck: public VM_Operation { Suggestion: class VM_HangInSafepoint: public VM_Operation { src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 70: > 68: public String name() { return CStringUtilities.getString(addr.getAddressAt(nameFieldOffset)); } > 69: > 70: public Address owner() { return addr.getAddressAt(ownerFieldOffset); } Printing the `osThread()->thread_id()` might be more useful than printing the address. ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2441565041 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1845903441 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1845900385 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1845900921 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1845902671 From dholmes at openjdk.org Mon Nov 18 05:43:44 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 05:43:44 GMT Subject: RFR: 8344247: Move objectWaiter field to VirtualThread instance In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:34:24 GMT, Patricio Chilano Mateo wrote: > Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. > Tested by running mach5 tiers1-3. > > Thanks, > Patricio LGTM! Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22124#pullrequestreview-2441576476 From dholmes at openjdk.org Mon Nov 18 05:45:49 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 18 Nov 2024 05:45:49 GMT Subject: RFR: 8344262: Win32AttachOperationRequest objects are created by using global new In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 21:05:21 GMT, Alex Menkov wrote: > The issue was introduced by [JDK-8339289](https://bugs.openjdk.org/browse/JDK-8339289). > The fix makes `Win32AttachOperationRequest` successor of `CHeapObj`, so `Win32AttachOperationRequest` inherits its `new` operator > > testing: tier1..tier4 LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22166#pullrequestreview-2441578844 From alanb at openjdk.org Mon Nov 18 06:58:45 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 18 Nov 2024 06:58:45 GMT Subject: RFR: 8344364: Remove unused SecurityManager-related imports from java.lang.instrument.ClassFileTransformer In-Reply-To: <4dyuFoNkbEj857BGKdeA-EiYsXb5TiqjunpCDvbrlpg=.c1be84bb-1af8-4587-9d55-5353df76a87a@github.com> References: <4dyuFoNkbEj857BGKdeA-EiYsXb5TiqjunpCDvbrlpg=.c1be84bb-1af8-4587-9d55-5353df76a87a@github.com> Message-ID: On Sun, 17 Nov 2024 18:04:57 GMT, Eirik Bj?rsn?s wrote: > Please review this trivial cleanup which removes unused imports of `java.security.AccessController` and `java.security.PrivilegedAction` from `java.lang.instrument.ClassFileTransformer`. > > History: These imports came with the new transform method introduced by the module system implementation in JDK-8142968 and were left unused when JDK-8159147 instead added a ClassLoader parameter to the new transform method. > > Verification: `make images` succeeds. JDK-8344187 has the changes for the java.instrument module, Kevin has a PR coming with the changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22184#issuecomment-2482102001 From alanb at openjdk.org Mon Nov 18 07:29:47 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 18 Nov 2024 07:29:47 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.lang.instrument In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:03:28 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > test/jdk/java/lang/instrument/ still passing. Marked as reviewed by alanb (Reviewer). src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 661: > 659: static final StackWalker walker; > 660: static { > 661: walker = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE); If you want, you could remove the static block, but what you have is okay too. ------------- PR Review: https://git.openjdk.org/jdk/pull/22106#pullrequestreview-2441725031 PR Review Comment: https://git.openjdk.org/jdk/pull/22106#discussion_r1846005325 From mbaesken at openjdk.org Mon Nov 18 07:45:48 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 18 Nov 2024 07:45:48 GMT Subject: RFR: 8344298: Test tools/sincechecker/modules/jdk.hotspot.agent/JdkHotspotAgentCheckSince.java fails on platforms without sa In-Reply-To: References: Message-ID: <1AVwBTSnblvkCEqQkfeqG7nmCBUro7S0STF-jtSGZ2Y=.2b1b6663-1412-44cb-989b-a941d841e935@github.com> On Fri, 15 Nov 2024 12:04:08 GMT, Matthias Baesken wrote: > E.g. on AIx we run into this test failure : > error: module not found: jdk.hotspot.agent > Unable to retrieve `@since` for Module: module: jdk.hotspot.agent > java.lang.Exception: The `@since` checker found 1 problems > at SinceChecker.checkModule(SinceChecker.java:284) > at SinceChecker.main(SinceChecker.java:145) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) > at java.base/java.lang.Thread.run(Thread.java:1447) > > So we should probably limit the execution of this test to jdk with sa support. Thanks for the review ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22146#issuecomment-2482171101 From mbaesken at openjdk.org Mon Nov 18 07:45:48 2024 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 18 Nov 2024 07:45:48 GMT Subject: Integrated: 8344298: Test tools/sincechecker/modules/jdk.hotspot.agent/JdkHotspotAgentCheckSince.java fails on platforms without sa In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 12:04:08 GMT, Matthias Baesken wrote: > E.g. on AIx we run into this test failure : > error: module not found: jdk.hotspot.agent > Unable to retrieve `@since` for Module: module: jdk.hotspot.agent > java.lang.Exception: The `@since` checker found 1 problems > at SinceChecker.checkModule(SinceChecker.java:284) > at SinceChecker.main(SinceChecker.java:145) > at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104) > at java.base/java.lang.reflect.Method.invoke(Method.java:565) > at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) > at java.base/java.lang.Thread.run(Thread.java:1447) > > So we should probably limit the execution of this test to jdk with sa support. This pull request has now been integrated. Changeset: 543e355b Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/543e355bd92d74bcb5a408ccefd8e2e0d9a0552f Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8344298: Test tools/sincechecker/modules/jdk.hotspot.agent/JdkHotspotAgentCheckSince.java fails on platforms without sa Reviewed-by: lucy ------------- PR: https://git.openjdk.org/jdk/pull/22146 From eirbjo at openjdk.org Mon Nov 18 08:40:06 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 18 Nov 2024 08:40:06 GMT Subject: RFR: 8344364: Remove unused SecurityManager-related imports from java.lang.instrument.ClassFileTransformer In-Reply-To: References: <4dyuFoNkbEj857BGKdeA-EiYsXb5TiqjunpCDvbrlpg=.c1be84bb-1af8-4587-9d55-5353df76a87a@github.com> Message-ID: On Mon, 18 Nov 2024 06:56:12 GMT, Alan Bateman wrote: > JDK-8344187 has the changes for the java.instrument module, Kevin has a PR coming with the changes. Thanks, withdrawing this PR. Added label `jep486` to JDK-8344187. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22184#issuecomment-2482277509 From eirbjo at openjdk.org Mon Nov 18 08:40:07 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 18 Nov 2024 08:40:07 GMT Subject: Withdrawn: 8344364: Remove unused SecurityManager-related imports from java.lang.instrument.ClassFileTransformer In-Reply-To: <4dyuFoNkbEj857BGKdeA-EiYsXb5TiqjunpCDvbrlpg=.c1be84bb-1af8-4587-9d55-5353df76a87a@github.com> References: <4dyuFoNkbEj857BGKdeA-EiYsXb5TiqjunpCDvbrlpg=.c1be84bb-1af8-4587-9d55-5353df76a87a@github.com> Message-ID: On Sun, 17 Nov 2024 18:04:57 GMT, Eirik Bj?rsn?s wrote: > Please review this trivial cleanup which removes unused imports of `java.security.AccessController` and `java.security.PrivilegedAction` from `java.lang.instrument.ClassFileTransformer`. > > History: These imports came with the new transform method introduced by the module system implementation in JDK-8142968 and were left unused when JDK-8159147 instead added a ClassLoader parameter to the new transform method. > > Verification: `make images` succeeds. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22184 From kevinw at openjdk.org Mon Nov 18 09:23:58 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 09:23:58 GMT Subject: RFR: 8318668: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java fails with Xcomp In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 04:32:39 GMT, Ramkumar Sunderbabu wrote: > Trivial change to exclude the test from running with Xcomp flag. > > The test fails because the number of GCs as reported by the MXBean doesn't match the expected number. This is due to the additional GC happening due to CodeCache crossing its threshold. > We could increase the code cache or restrict the specific compiler that fills the cache. But this will not completely eliminate the possibility as cache size could be overridden or the same failure can happen for a different compiler. > > So, it is better to restrict the Xcomp flag as a whole. > > Testing: > Only local testing done as it is trivial change. One run with Xcomp and another without any flags. Agreed, looks good. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22180#pullrequestreview-2441962585 From kevinw at openjdk.org Mon Nov 18 09:26:59 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 09:26:59 GMT Subject: Integrated: 8344105: Remove SecurityManager and related calls from jdk.attach and jdk.hotspot.agent In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:53:26 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). This pull request has now been integrated. Changeset: 00ff6a38 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/00ff6a38ce28f94f866f4c120a04e9b0ffb7bda5 Stats: 77 lines in 9 files changed: 0 ins; 67 del; 10 mod 8344105: Remove SecurityManager and related calls from jdk.attach and jdk.hotspot.agent Reviewed-by: amenkov, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/22067 From ihse at openjdk.org Mon Nov 18 09:29:52 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 09:29:52 GMT Subject: Integrated: 8344056: Use markdown format for man pages In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: <_LM2L_tT9Q4OZvoeWztNyLUkzQcLPQIE_En639Pu_lA=.31310c87-64b4-4b97-bb0c-f044e312e9ef@github.com> On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie wrote: > Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. > > Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. > > This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. This pull request has now been integrated. Changeset: 475feb06 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/475feb064bb6b9dfd34fc52762e3e0ab825254ec Stats: 41386 lines in 66 files changed: 18876 ins; 22500 del; 10 mod 8344056: Use markdown format for man pages Reviewed-by: cstein, iris, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/22081 From kevinw at openjdk.org Mon Nov 18 10:50:24 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 10:50:24 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.lang.instrument [v2] In-Reply-To: References: Message-ID: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > test/jdk/java/lang/instrument/ still passing. Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - static block not needed - Merge remote-tracking branch 'upstream/master' into 8344187_PostSM_instrument - update - 8344187: Remove SecurityManager and related calls from java.instrument ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22106/files - new: https://git.openjdk.org/jdk/pull/22106/files/99e5f003..f9699b08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22106&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22106&range=00-01 Stats: 62940 lines in 759 files changed: 31070 ins; 29188 del; 2682 mod Patch: https://git.openjdk.org/jdk/pull/22106.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22106/head:pull/22106 PR: https://git.openjdk.org/jdk/pull/22106 From alanb at openjdk.org Mon Nov 18 10:50:24 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 18 Nov 2024 10:50:24 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.lang.instrument [v2] In-Reply-To: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> References: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> Message-ID: On Mon, 18 Nov 2024 10:45:44 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> test/jdk/java/lang/instrument/ still passing. > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - static block not needed > - Merge remote-tracking branch 'upstream/master' into 8344187_PostSM_instrument > - update > - 8344187: Remove SecurityManager and related calls from java.instrument Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22106#pullrequestreview-2442248988 From kevinw at openjdk.org Mon Nov 18 10:50:24 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 10:50:24 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.lang.instrument In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:03:28 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > test/jdk/java/lang/instrument/ still passing. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22106#issuecomment-2482659341 From kevinw at openjdk.org Mon Nov 18 10:50:25 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 10:50:25 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.lang.instrument [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 07:27:07 GMT, Alan Bateman wrote: >> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - static block not needed >> - Merge remote-tracking branch 'upstream/master' into 8344187_PostSM_instrument >> - update >> - 8344187: Remove SecurityManager and related calls from java.instrument > > src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 661: > >> 659: static final StackWalker walker; >> 660: static { >> 661: walker = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE); > > If you want, you could remove the static block, but what you have is okay too. may as well 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22106#discussion_r1846357861 From kevinw at openjdk.org Mon Nov 18 11:10:28 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 11:10:28 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent Message-ID: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Remove redundant SecurityManager, AccessController references (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. ------------- Commit messages: - oops - 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent Changes: https://git.openjdk.org/jdk/pull/22155/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22155&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344181 Stats: 119 lines in 9 files changed: 0 ins; 78 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/22155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22155/head:pull/22155 PR: https://git.openjdk.org/jdk/pull/22155 From kevinw at openjdk.org Mon Nov 18 11:10:49 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 11:10:49 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from src/java.management Message-ID: Remove redundant SecurityManager, AccessController references (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). ------------- Commit messages: - 8344177: Remove SecurityManager and related calls from src/java.management Changes: https://git.openjdk.org/jdk/pull/22100/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344177 Stats: 1439 lines in 51 files changed: 10 ins; 1240 del; 189 mod Patch: https://git.openjdk.org/jdk/pull/22100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100 PR: https://git.openjdk.org/jdk/pull/22100 From kevinw at openjdk.org Mon Nov 18 11:29:52 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 11:29:52 GMT Subject: RFR: 8344364: Remove unused SecurityManager-related imports from java.lang.instrument.ClassFileTransformer In-Reply-To: References: <4dyuFoNkbEj857BGKdeA-EiYsXb5TiqjunpCDvbrlpg=.c1be84bb-1af8-4587-9d55-5353df76a87a@github.com> Message-ID: On Mon, 18 Nov 2024 08:36:57 GMT, Eirik Bj?rsn?s wrote: >> JDK-8344187 has the changes for the java.instrument module, Kevin has a PR coming with the changes. > >> JDK-8344187 has the changes for the java.instrument module, Kevin has a PR coming with the changes. > > Thanks, withdrawing this PR. Added label `jep486` to JDK-8344187. Thanks @eirbjo 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22184#issuecomment-2482766483 From coleenp at openjdk.org Mon Nov 18 12:41:52 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 12:41:52 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: Message-ID: <44duw-bwTlAaNhATsWQA0Fn13fAK0gaCTCsrSGBzibg=.eb7fbcdf-6229-4d13-a3d8-0df6a948c4f5@github.com> On Mon, 18 Nov 2024 03:00:36 GMT, David Holmes wrote: >> jni.cpp functions call this. > > I don't see any difference in the callers in relation to this PR and the function is not presently declared `extern`. ?? There was an extern trace_class_resolution() function that called this _impl function that I removed, so renamed this impl function to trace_class_resolution(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1846515884 From coleenp at openjdk.org Mon Nov 18 12:52:01 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 12:52:01 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v7] In-Reply-To: References: Message-ID: On Sat, 16 Nov 2024 14:25:30 GMT, Coleen Phillimore wrote: >> Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Fix comments. Thanks for the reviews, Ioi, John and David. Thanks also for the comments and more code deletion suggestions, Alan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2482948507 PR Comment: https://git.openjdk.org/jdk/pull/22064#issuecomment-2482949665 From coleenp at openjdk.org Mon Nov 18 12:52:02 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 12:52:02 GMT Subject: Integrated: 8341916: Remove ProtectionDomain related hotspot code and tests In-Reply-To: References: Message-ID: On Wed, 13 Nov 2024 11:42:11 GMT, Coleen Phillimore wrote: > Remove Hotspot code that passes protection_domain around class loading so that checkPackageAccess can be called and the result stored. With the removal of the Security Manager in JEP 486, this code no longer does anything. > > Tested with tier1-4. This pull request has now been integrated. Changeset: dfddbcaa Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/dfddbcaab886b9baa731cd748bb7f547e1903b64 Stats: 1415 lines in 48 files changed: 0 ins; 1246 del; 169 mod 8341916: Remove ProtectionDomain related hotspot code and tests Reviewed-by: dholmes, iklam, jrose ------------- PR: https://git.openjdk.org/jdk/pull/22064 From coleenp at openjdk.org Mon Nov 18 13:06:50 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 13:06:50 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: <1BBSbOS5dfX9XQZcA4PRM4z1uNiEDsgZuWJ-5Mzaync=.8a045b71-fa1e-461f-8f3e-eafe702f5c9d@github.com> On Fri, 15 Nov 2024 05:19:58 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. > > src/hotspot/share/classfile/verifier.cpp line 280: > >> 278: >> 279: return (should_verify_class && >> 280: // return if the class is a bootstrapping class > > This method should have a comment explaining what the eligibility criteria is and how/why `should_verify_class` should be set in different conditions. I moved the function near should_verify_for, so it would be clear what this does and why, and added a comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1846549059 From epeter at openjdk.org Mon Nov 18 14:08:18 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:08:18 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: <_8-9ZYtVnjHTl3zce1wjZUCJZ6j1I5LgVfmUT4VKkm8=.74799b71-4c26-4c6c-8299-2efd02292548@github.com> On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote: >> Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? > > @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) @rkennke I have now looked more into the SuperWord collateral damage: [JDK-8340010](https://bugs.openjdk.org/browse/JDK-8340010): Fix vectorization tests with compact headers Do we care about `AlignVector` and `UseCompactObjectHeaders` enabled together? If so, we have a serious issue with mixed type examples. There are actually now some failing cases: Failed IR Rules (3) of Methods (3) ---------------------------------- 1) Method "public char[] compiler.vectorization.runner.ArrayTypeConvertTest.convertFloatToChar()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "avx2", "true"}, counts={"_#V#VECTOR_CAST_F2S#_", "_ at min(max_float, max_char)", ">0"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(VectorCastF2X.*)+(\\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 2) Method "public short[] compiler.vectorization.runner.ArrayTypeConvertTest.convertFloatToShort()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "avx2", "true"}, counts={"_#V#VECTOR_CAST_F2S#_", "_ at min(max_float, max_short)", ">0"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(VectorCastF2X.*)+(\\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 3) Method "public float[] compiler.vectorization.runner.ArrayTypeConvertTest.convertShortToFloat()" - [Failed IR rules: 1]: * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"asimd", "true", "avx2", "true"}, counts={"_#V#VECTOR_CAST_S2F#_", "_ at min(max_short, max_float)", ">0"}, applyIfPlatform={}, applyIfPlatformOr={}, failOn={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\\d+(\\s){2}(VectorCastS2X.*)+(\\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! Let me explain: If we enable AlignVector, we need 8-byte alignment. As long as `UseCompactObjectHeaders` is disabled, all of these are `=16`: UNSAFE.ARRAY_BYTE_BASE_OFFSET UNSAFE.ARRAY_SHORT_BASE_OFFSET UNSAFE.ARRAY_CHAR_BASE_OFFSET UNSAFE.ARRAY_INT_BASE_OFFSET UNSAFE.ARRAY_LONG_BASE_OFFSET UNSAFE.ARRAY_FLOAT_BASE_OFFSET UNSAFE.ARRAY_DOUBLE_BASE_OFFSET However, with `UseCompactObjectHeaders` endabled, these are now 12: UNSAFE.ARRAY_BYTE_BASE_OFFSET UNSAFE.ARRAY_SHORT_BASE_OFFSET UNSAFE.ARRAY_CHAR_BASE_OFFSET UNSAFE.ARRAY_INT_BASE_OFFSET UNSAFE.ARRAY_FLOAT_BASE_OFFSET And these still 16: UNSAFE.ARRAY_LONG_BASE_OFFSET UNSAFE.ARRAY_DOUBLE_BASE_OFFSET Now let's try to get that 8-byte alignment in some example, one from the above: public short[] convertFloatToShort() { short[] res = new short[SIZE]; for (int i = 0; i < SIZE; i++) { res[i] = (short) floats[i]; } return res; } Let's look at the two addresses with `UseCompactObjectHeaders=false`, where we **can** vectorize: F_adr = base + 16 + 4 * i -> aligned for: i % 2 = 0 S_adr = base + 16 + 2 * i -> aligned for: i % 4 = 0 -> solution for both: i % 4 = 0, i.e. we have alignment for both vector accesses every 4th iteration. Let's look at the two addresses with `UseCompactObjectHeaders=true`, where we **cannot** vectorize: F_adr = base + 12 + 4 * i -> aligned for: i % 2 = 1 S_adr = base + 12 + 2 * i -> aligned for: i % 4 = 2 -> There is no solution to satisfy both alignment constraints! It's a little sad that I only just realized this now... but oh well. The issue is that we apparently did not run testing for these examples, so I did not see the impact immediately. So my question: do we care about `UseCompactObjectHeaders` and `AlignVector` enabled at the same time? If so, we have to accept that some examples with mixed types simply will not vectorize. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483138198 From epeter at openjdk.org Mon Nov 18 14:12:21 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:12:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote: >> Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? > > @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483153279 From rkennke at openjdk.org Mon Nov 18 14:16:26 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 14:16:26 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Fri, 8 Nov 2024 17:42:24 GMT, Roman Kennke wrote: >> Could you please cherry pick https://github.com/mur47x111/jdk/commit/c45ebc2a89d0b25a3dd8cc46386e37a635ff9af2 for the JVMCI support? > > @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) > @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483162512 From epeter at openjdk.org Mon Nov 18 14:20:20 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:20:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: <55hlCTAhtpoZT9LDQUkHwPQ5UUTylLzfNDYiFaBTXes=.9d9d6874-2f59-4833-9226-9e7f6410ca8d@github.com> On Mon, 18 Nov 2024 14:13:17 GMT, Roman Kennke wrote: >> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) > >> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? > > For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483170957 From rkennke at openjdk.org Mon Nov 18 14:28:20 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 14:28:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:13:17 GMT, Roman Kennke wrote: >> @mur47x111 it's now intergrated in jdk24. do your magic in Graal ;-) > >> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? > > For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. > @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483195304 From epeter at openjdk.org Mon Nov 18 14:28:20 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:28:20 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke wrote: >>> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? >> >> For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. > >> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. > > BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. > > What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. @rkennke It just will (silently) not vectorize, thus running slower but still correct. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483202341 From ihse at openjdk.org Mon Nov 18 14:40:03 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 14:40:03 GMT Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking [v14] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam wrote: >> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483). >> >> ---- >> Note: this is a combined PR of the following individual PRs >> - https://github.com/openjdk/jdk/pull/20516 >> - https://github.com/openjdk/jdk/pull/20517 >> - https://github.com/openjdk/jdk/pull/20843 >> - https://github.com/openjdk/jdk/pull/20958 >> - https://github.com/openjdk/jdk/pull/20959 >> - https://github.com/openjdk/jdk/pull/21049 >> - https://github.com/openjdk/jdk/pull/21143 > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test after security manager removal make/RunTests.gmk line 706: > 704: endef > 705: > 706: This PR was not tagged with the `build` label, and was therefore not brought to the attention of the build team. This file contains a large number of unacceptable changes. :-( It would under no circumstance have been approved as it looks. Please make sure that the Github labels actually matches the set of files that are changed in the PR. Skara tooling will assist in this, but the ultimate responsibility lies with the Author and Reviewers of the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1846696988 From epeter at openjdk.org Mon Nov 18 14:41:21 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke wrote: >>> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? >> >> For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. > >> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. > > BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. > > What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. @rkennke > BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. Sure. But I guess some people will want to run both `AlignVector` and `UseCompactObjectHeaders` in the future. Some machines simply do require strict alignment. So they will have to live with that tradeoff. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483225393 From qamai at openjdk.org Mon Nov 18 14:41:21 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:31:52 GMT, Emanuel Peter wrote: >>> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. >> >> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. >> >> What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. > > @rkennke >> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. > > Sure. But I guess some people will want to run both `AlignVector` and `UseCompactObjectHeaders` in the future. Some machines simply do require strict alignment. So they will have to live with that tradeoff. @eme64 Tbh I don't see how `AlignVector` can mitigate the issue if strict alignment is required unless the object base is guaranteed to be aligned at least as much as the vector length. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483230986 From rkennke at openjdk.org Mon Nov 18 14:41:21 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:23:24 GMT, Roman Kennke wrote: >>> @rkennke How important is the 4-byte saving on `byte, char, short, int, float` arrays? I'd assume they are not generally that small, at least a few elements? So could we make an exception, and have a `16-byte` offset to the payload of all these primitive (and maybe all) arrays, at least under `AlignVector`? >> >> For byte[] and to some extend for char[] it is quite important, because those are the backing types for String and related classes, and Java apps often have *many* of them, and also quite small. I would not want to to sacrifize them for vectorization, especially not for the relatively uncommon (I think) case of mixed type access. > >> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. > > BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. > > What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. > @rkennke It just will (silently) not vectorize, thus running slower but still correct. Ok, I think we can live with that for now. As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. The tests need fixing, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483234723 From epeter at openjdk.org Mon Nov 18 14:41:21 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:34:13 GMT, Quan Anh Mai wrote: >> @rkennke >>> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. >> >> Sure. But I guess some people will want to run both `AlignVector` and `UseCompactObjectHeaders` in the future. Some machines simply do require strict alignment. So they will have to live with that tradeoff. > > @eme64 Tbh I don't see how `AlignVector` can mitigate the issue if strict alignment is required unless the object base is guaranteed to be aligned at least as much as the vector length. @merykitty the object base is always at least `8-byte` aligned, see `ObjectAlignmentInBytes` - this also holds for all arrays. But the issue is the offset from the object base to the array payload. @rkennke yes, working on fixing the tests :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483236250 From qamai at openjdk.org Mon Nov 18 14:41:21 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 14:41:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:36:17 GMT, Emanuel Peter wrote: >> @eme64 Tbh I don't see how `AlignVector` can mitigate the issue if strict alignment is required unless the object base is guaranteed to be aligned at least as much as the vector length. > > @merykitty the object base is always at least `8-byte` aligned, see `ObjectAlignmentInBytes` - this also holds for all arrays. But the issue is the offset from the object base to the array payload. > > @rkennke yes, working on fixing the tests :) @eme64 Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483241445 From epeter at openjdk.org Mon Nov 18 14:41:22 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:41:22 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:35:41 GMT, Roman Kennke wrote: >>> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. >> >> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. >> >> What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. > >> @rkennke It just will (silently) not vectorize, thus running slower but still correct. > > Ok, I think we can live with that for now. > > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. > > The tests need fixing, though. @rkennke > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. Ah. So we would eventually have not a `12-byte` but `8-byte` offset from base to payload? Would that happen in all cases? And could that happen before `UseCompactObjectHeaders` leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of `UseCompactObjectHeaders + AlignVector`. Though I can surely do it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483242899 From dfuchs at openjdk.org Mon Nov 18 14:42:02 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 18 Nov 2024 14:42:02 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 10:39:33 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerAccessController.java line 77: > 75: *

An MBean could possibly be a CassLoader. > 76: * Users who do want an MBean which could be a ClassLoader should not permit > 77: * MBean creation.

Did you mean "who do not want" ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1846701835 From epeter at openjdk.org Mon Nov 18 14:44:19 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:44:19 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:38:20 GMT, Quan Anh Mai wrote: >> @merykitty the object base is always at least `8-byte` aligned, see `ObjectAlignmentInBytes` - this also holds for all arrays. But the issue is the offset from the object base to the array payload. >> >> @rkennke yes, working on fixing the tests :) > > @eme64 Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. @merykitty > Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. First: without `AlignVector`, the vector instructions can have completely free alignment. On x64 and aarch64 generally I think most machines do not need alignment at all. And as far as I know there is also no performance penalty on modern CPUs for misalignment. I could be wrong here. On older CPUs alignment was important for performance though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483249163 From kevinw at openjdk.org Mon Nov 18 14:51:12 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 14:51:12 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:39:05 GMT, Daniel Fuchs wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerAccessController.java line 77: > >> 75: *

An MBean could possibly be a CassLoader. >> 76: * Users who do want an MBean which could be a ClassLoader should not permit >> 77: * MBean creation.

> > Did you mean "who do not want" ? A CassLoader also, will clarify! 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1846716243 From qamai at openjdk.org Mon Nov 18 14:56:28 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 14:56:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: On Mon, 18 Nov 2024 14:41:25 GMT, Emanuel Peter wrote: >> @eme64 Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. > > @merykitty >> Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. > > First: without `AlignVector`, the vector instructions can have completely free alignment. On x64 and aarch64 generally I think most machines do not need alignment at all. And as far as I know there is also no performance penalty on modern CPUs for misalignment. I could be wrong here. On older CPUs alignment was important for performance though. @eme64 You will need the alignment for the whole vector (which means 32 bytes for a `ymm` load), not alignment only on its elements. Vector element is the artefact of ALU units, not the load/store units that actually care about alignment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483255086 From epeter at openjdk.org Mon Nov 18 14:56:28 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 14:56:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> Message-ID: <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> On Mon, 18 Nov 2024 14:43:48 GMT, Quan Anh Mai wrote: >> @merykitty >>> Please correct me if I'm wrong but the issue is you need the base to be aligned at 32 bytes on AVX2 machines for any alignment for vector instruction to be meaningful, so I don't see the value of vector alignment at all. >> >> First: without `AlignVector`, the vector instructions can have completely free alignment. On x64 and aarch64 generally I think most machines do not need alignment at all. And as far as I know there is also no performance penalty on modern CPUs for misalignment. I could be wrong here. On older CPUs alignment was important for performance though. > > @eme64 You will need the alignment for the whole vector (which means 32 bytes for a `ymm` load), not alignment only on its elements. Vector element is the artefact of ALU units, not the load/store units that actually care about alignment. @merykitty I don't think I understand. When and for what do I need the full 32-byte alignment? @merykitty In `AlignmentSolver::solve` / `src/hotspot/share/opto/vectorization.cpp` you can see how I compute if vectors can be aligned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483261148 PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483266962 From qamai at openjdk.org Mon Nov 18 14:56:28 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 14:56:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> Message-ID: <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> On Mon, 18 Nov 2024 14:48:22 GMT, Emanuel Peter wrote: >> @eme64 You will need the alignment for the whole vector (which means 32 bytes for a `ymm` load), not alignment only on its elements. Vector element is the artefact of ALU units, not the load/store units that actually care about alignment. > > @merykitty In `AlignmentSolver::solve` / `src/hotspot/share/opto/vectorization.cpp` you can see how I compute if vectors can be aligned. @eme64 If you load a 32-byte (256-bit) vector, then the load is aligned if the address is divisible by 32, otherwise the load is misaligned. That's why [`vmovdqua`](https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64) requires 16-byte alignment for 16-byte loads/stores, 32-byte alignment for 32-byte loads/stores, 64-byte alignment for 64-byte loads/stores. As a result, I don't see how you can align a vector load/store if the object base is only guaranteed to align at 8-byte boundaries. I mean there is no use trying to align an access if you cannot align it at the access size, the access is going to be misaligned anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483275575 From chen.l.liang at oracle.com Mon Nov 18 01:07:23 2024 From: chen.l.liang at oracle.com (Chen Liang) Date: Mon, 18 Nov 2024 01:07:23 +0000 Subject: [External] : Re: Introductions / JDWP JVM Crashes In-Reply-To: References: Message-ID: Hi Adam, I have marked the bug as new for re-triage by the serviceability engineers: the closing was indeed weird, that we do not usually close a bug because we don't plan to fix it in the short term or low priority. You can submit a patch for it. For getting assigned to the JBS: for new contributors, the assignee is usually the sponsor of your patch. Unfortunately I do not understand native code well enough to sponsor your patch, but I will forward this to serviceability-dev list and see if any engineer there can help. I think you can create a PR with the title "6726901: JDWP: ReferenceType.GetValues crashes jvm in case non-static fields are passed" now. P.S. When you reply to someone's reply to the list, remember to reply-all instead of just reply, so the list receives your reply email too. Regards, Chen Liang ________________________________ From: Adam Bruce Sent: Sunday, November 17, 2024 9:18 AM To: Chen Liang Subject: [External] : Re: Introductions / JDWP JVM Crashes Hi Chen, Thanks for the detailed reply. I have found some matching bugs in JBS, however they have been marked as closed with a resolution of Won't Fix. e.g. https://bugs.openjdk.org/browse/JDK-6726901 Would I be allowed to create a PR for the bug? I believe it was marked as Won't Fix due to low priority. Also, as I am not an Author, is there a process for getting assigned to a ticket in JBS, or shall I proceed with creating a PR anyway? Cheers, Adam On Saturday, November 16th, 2024 at 11:34 PM, Chen Liang wrote: Hi Adam, I believe serviceability-dev at openjdk.org is the correct list for jdwp and Java agents. I know it takes care of agents, and a peek into its archives shows it takes care of jdwp as well. For patches, you usually first submit a bug through https://bugs.java.com/; once you find no duplicate, you can create a new bug. (Note the component will be "core serviceability" which the serviceability-dev list manages. It takes a day or two for the bug to be triaged and moved from incident JI-9XXXXXX to an official bug JDK-8XXXXXX that you can submit a patch for. (Alternatively, you can ask on the serviceability-dev list, and contributors with bug system access may create issues for you instead). Once you have a bug number, follow the process in https://openjdk.org/guide/. Note that JDK project prefers to review ready-to-merge patches; so you should open a draft PR and move it out of draft if you want to open a PR with prototype work, otherwise the commit or review updates to the PR will spam the mailing lists. Also if you haven't signed the Oracle Contributor Agreement, the automated process will ask you to, but it will take a few days to process, so best to sign it ahead at https://oca.opensource.oracle.com/. Regards, Chen Liang ________________________________ From: discuss on behalf of Adam Bruce Sent: Saturday, November 16, 2024 12:24 PM To: discuss at openjdk.org Subject: Introductions / JDWP JVM Crashes Hi everyone, My name is Adam Bruce and I'm a software engineer with an interest in JVM internals. I'm currently working on a project involving JDWP and have identified some bugs in the OpenJDK protocol implementation which lead to JVM crashes due to segmentation faults. I understand that this is not a mailing list for technical discussions, so I was wondering if anybody could point me in the right direction for reporting and discussing this issue (I don't believe there is a mailing list specifically for JDWP or java agents). Additionally, it would be great if someone could advise on the best way to suggest a patch for these bugs as I have developed a fix for the issue locally and would like to suggest the changes as possible solutions. Many thanks, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From rkennke at openjdk.org Mon Nov 18 15:04:25 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 15:04:25 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 14:35:41 GMT, Roman Kennke wrote: >>> @rkennke Ok, fair enough. As far as I know, we at Oracle do not super care about strict alignment `AlignVector`. But maybe other people care, and have to make that tradeoff between vectorization and small object headers. >> >> BTW, this problem is not specific to UseCompactObjectHeaders - I think the same problem would happen with -UseCompressedClassPointers. With uncompressed class-pointers, byte[] would start at offset 20, while long[] start at offset 24. But nobody cares about -UCCP I think. >> >> What is the failure mode, though? When running with -UCOH and +AlignVector, would it crash or misbehave? Or would it (silently?) not vectorize? I think we could live with the latter, but not with the former. > >> @rkennke It just will (silently) not vectorize, thus running slower but still correct. > > Ok, I think we can live with that for now. > > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. > > The tests need fixing, though. > @rkennke > > > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. > > Ah. So we would eventually have not a `12-byte` but `8-byte` offset from base to payload? Would that happen in all cases? And could that happen before `UseCompactObjectHeaders` leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of `UseCompactObjectHeaders + AlignVector`. Though I can surely do it. I am not sure if and when this is going to happen. When I presented the idea at JVMLS, I got some resistance. I am also not sure if we first leave experimental status for UCOH, and then introduce 4-byte headers under a new flag (or no flag?), or if we first do 4-byte headers and only leave experimental status once that is done. The latter sounds more reasonable to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483304257 From epeter at openjdk.org Mon Nov 18 15:04:25 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 15:04:25 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> Message-ID: On Mon, 18 Nov 2024 14:50:51 GMT, Quan Anh Mai wrote: >> @merykitty In `AlignmentSolver::solve` / `src/hotspot/share/opto/vectorization.cpp` you can see how I compute if vectors can be aligned. > > @eme64 If you load a 32-byte (256-bit) vector, then the load is aligned if the address is divisible by 32, otherwise the load is misaligned. That's why [`vmovdqua`](https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64) requires 16-byte alignment for 16-byte loads/stores, 32-byte alignment for 32-byte loads/stores, 64-byte alignment for 64-byte loads/stores. > > As a result, I don't see how you can align a vector load/store if the object base is only guaranteed to align at 8-byte boundaries. I mean there is no use trying to align an access if you cannot align it at the access size, the access is going to be misaligned anyway. @merykitty I guess we can always use [vmovdqu](https://www.felixcloutier.com/x86/movdqu:vmovdqu8:vmovdqu16:vmovdqu32:vmovdqu64). And in fact that is exactly what we do: public class Test { static int RANGE = 1024*1024; public static void main(String[] args) { byte[] aB = new byte[RANGE]; byte[] bB = new byte[RANGE]; for (int i = 0; i < 100_000; i++) { test1(aB, bB); } } static void test1(byte[] a, byte[] b) { for (int i = 0; i < RANGE; i++) { a[i] = b[i]; } } } `../java -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printcompilation,Test::test* -XX:+TraceLoopOpts -XX:-TraceSuperWord -XX:+TraceNewVectors -Xbatch -XX:+AlignVector -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printassembly,Test::test* Test.java` ;; B20: # out( B20 B21 ) <- in( B19 B20 ) Loop( B20-B20 inner main of N178 strip mined) Freq: 8.13586e+09 0x00007fc3a4bb0780: movslq %ebx,%rdi 0x00007fc3a4bb0783: movslq %ebx,%r14 0x00007fc3a4bb0786: vmovdqu32 0x10(%r13,%r14,1),%zmm1 0x00007fc3a4bb0791: vmovdqu32 %zmm1,0x10(%r9,%r14,1) 0x00007fc3a4bb079c: vmovdqu32 0x50(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07a7: vmovdqu32 %zmm1,0x50(%r9,%rdi,1) 0x00007fc3a4bb07b2: vmovdqu32 0x90(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07bd: vmovdqu32 %zmm1,0x90(%r9,%rdi,1) 0x00007fc3a4bb07c8: vmovdqu32 0xd0(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07d3: vmovdqu32 %zmm1,0xd0(%r9,%rdi,1) 0x00007fc3a4bb07de: vmovdqu32 0x110(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07e9: vmovdqu32 %zmm1,0x110(%r9,%rdi,1) 0x00007fc3a4bb07f4: vmovdqu32 0x150(%r13,%rdi,1),%zmm1 0x00007fc3a4bb07ff: vmovdqu32 %zmm1,0x150(%r9,%rdi,1) 0x00007fc3a4bb080a: vmovdqu32 0x190(%r13,%rdi,1),%zmm1 0x00007fc3a4bb0815: vmovdqu32 %zmm1,0x190(%r9,%rdi,1) 0x00007fc3a4bb0820: vmovdqu32 0x1d0(%r13,%rdi,1),%zmm1 0x00007fc3a4bb082b: vmovdqu32 %zmm1,0x1d0(%r9,%rdi,1) ;*bastore {reexecute=0 rethrow=0 return_oop=0} ; - Test::test1 at 14 (line 14) 0x00007fc3a4bb0836: add $0x200,%ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} ; - Test::test1 at 15 (line 13) 0x00007fc3a4bb083c: cmp %r11d,%ebx 0x00007fc3a4bb083f: jl 0x00007fc3a4bb0780 ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483305049 From dfuchs at openjdk.org Mon Nov 18 15:04:52 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 18 Nov 2024 15:04:52 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 10:39:33 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 448: > 446: { return super.loadClass(name, resolve); } > 447: } > 448: : null; I suspect we could just return `parent` here but that might require some deeper investigation. src/java.management/share/classes/sun/management/ManagementFactoryHelper.java line 454: > 452: * otherwise, just return. > 453: */ > 454: @SuppressWarnings("removal") Do you still need the `@SuppressWarnings` annotation here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1846739026 PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1846741416 From kevinw at openjdk.org Mon Nov 18 15:17:33 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 15:17:33 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v2] In-Reply-To: References: Message-ID: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - remove missed suppression - comment correction ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22100/files - new: https://git.openjdk.org/jdk/pull/22100/files/6ea63d5c..f8062515 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100 PR: https://git.openjdk.org/jdk/pull/22100 From kevinw at openjdk.org Mon Nov 18 15:17:33 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 15:17:33 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 15:01:45 GMT, Daniel Fuchs wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove missed suppression >> - comment correction > > src/java.management/share/classes/sun/management/ManagementFactoryHelper.java line 454: > >> 452: * otherwise, just return. >> 453: */ >> 454: @SuppressWarnings("removal") > > Do you still need the `@SuppressWarnings` annotation here? thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1846761847 From qamai at openjdk.org Mon Nov 18 15:23:34 2024 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 18 Nov 2024 15:23:34 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> Message-ID: On Mon, 18 Nov 2024 15:01:09 GMT, Emanuel Peter wrote: >> @eme64 If you load a 32-byte (256-bit) vector, then the load is aligned if the address is divisible by 32, otherwise the load is misaligned. That's why [`vmovdqua`](https://www.felixcloutier.com/x86/movdqa:vmovdqa32:vmovdqa64) requires 16-byte alignment for 16-byte loads/stores, 32-byte alignment for 32-byte loads/stores, 64-byte alignment for 64-byte loads/stores. >> >> As a result, I don't see how you can align a vector load/store if the object base is only guaranteed to align at 8-byte boundaries. I mean there is no use trying to align an access if you cannot align it at the access size, the access is going to be misaligned anyway. > > @merykitty I guess we can always use [vmovdqu](https://www.felixcloutier.com/x86/movdqu:vmovdqu8:vmovdqu16:vmovdqu32:vmovdqu64). > > And in fact that is exactly what we do: > > public class Test { > static int RANGE = 1024*1024; > > public static void main(String[] args) { > byte[] aB = new byte[RANGE]; > byte[] bB = new byte[RANGE]; > for (int i = 0; i < 100_000; i++) { > test1(aB, bB); > } > } > > static void test1(byte[] a, byte[] b) { > for (int i = 0; i < RANGE; i++) { > a[i] = b[i]; > } > } > } > > `../java -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printcompilation,Test::test* -XX:+TraceLoopOpts -XX:-TraceSuperWord -XX:+TraceNewVectors -Xbatch -XX:+AlignVector -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printassembly,Test::test* Test.java` > > > ;; B20: # out( B20 B21 ) <- in( B19 B20 ) Loop( B20-B20 inner main of N178 strip mined) Freq: 8.13586e+09 > 0x00007fc3a4bb0780: movslq %ebx,%rdi > 0x00007fc3a4bb0783: movslq %ebx,%r14 > 0x00007fc3a4bb0786: vmovdqu32 0x10(%r13,%r14,1),%zmm1 > 0x00007fc3a4bb0791: vmovdqu32 %zmm1,0x10(%r9,%r14,1) > 0x00007fc3a4bb079c: vmovdqu32 0x50(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07a7: vmovdqu32 %zmm1,0x50(%r9,%rdi,1) > 0x00007fc3a4bb07b2: vmovdqu32 0x90(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07bd: vmovdqu32 %zmm1,0x90(%r9,%rdi,1) > 0x00007fc3a4bb07c8: vmovdqu32 0xd0(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07d3: vmovdqu32 %zmm1,0xd0(%r9,%rdi,1) > 0x00007fc3a4bb07de: vmovdqu32 0x110(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07e9: vmovdqu32 %zmm1,0x110(%r9,%rdi,1) > 0x00007fc3a4bb07f4: vmovdqu32 0x150(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb07ff: vmovdqu32 %zmm1,0x150(%r9,%rdi,1) > 0x00007fc3a4bb080a: vmovdqu32 0x190(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb0815: vmovdqu32 %zmm1,0x190(%r9,%rdi,1) > 0x00007fc3a4bb0820: vmovdqu32 0x1d0(%r13,%rdi,1),%zmm1 > 0x00007fc3a4bb082b: vmovdqu32 %zmm1,0x1d0(%r9,%rdi,1) ;*bastore {reexecute=0 rethrow=0 return_oop=0} > ; - Test::test1 at 14 (line 14) > 0x00007fc3a4bb0836: add $0x200,%ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} > ; - Test::test1 at 15 (line 13) > 0x00007fc3a4bb083c: c... @eme64 What I mean here is that `AlignVector` seems useless because the accesses are going to be misaligned either way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483356306 From ihse at openjdk.org Mon Nov 18 15:32:21 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 18 Nov 2024 15:32:21 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 04:49:51 GMT, David Holmes wrote: >> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: >> >> - Merge branch 'master' into JDK-8305895-v4 >> - Merge tag 'jdk-25+23' into JDK-8305895-v4 >> >> Added tag jdk-24+23 for changeset c0e6c3b9 >> - Fix gen-ZGC removal >> - Merge tag 'jdk-24+22' into JDK-8305895-v4 >> >> Added tag jdk-24+22 for changeset 388d44fb >> - Enable riscv in CompressedClassPointersEncodingScheme test >> - s390 port >> - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test >> - Update copyright >> - Avoid assert/endless-loop in JFR code >> - Update copyright headers >> - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b > > test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java line 1: > > > This file was reduced to empty but not actually deleted. Can you fix it please. @rkennke Just making sure this is not being missed. Can you please open a JBS issue to correct this and the file below? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1846790097 From dfuchs at openjdk.org Mon Nov 18 16:10:02 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 18 Nov 2024 16:10:02 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v2] In-Reply-To: References: Message-ID: <8moxYy-RsLK-QWmGrUX8ryO7Udcd-3f_uo0iNJcMwCw=.005222c5-8321-4ded-9bb6-a263a2b97cbf@github.com> On Mon, 18 Nov 2024 15:17:33 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - remove missed suppression > - comment correction src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerAccessController.java line 181: > 179: if (sm == null) { > 180: Object object = getMBeanServer().instantiate(className); > 181: checkClassLoader(object); I believe we should keep these calls to `checkClassLoader(object)` in place for now. What to do in this case will require some more thinking - I'd suggest handling that part in a separate PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1846868850 From lmesnik at openjdk.org Mon Nov 18 16:10:04 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 16:10:04 GMT Subject: RFR: 8318668: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java fails with Xcomp In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 04:32:39 GMT, Ramkumar Sunderbabu wrote: > Trivial change to exclude the test from running with Xcomp flag. > > The test fails because the number of GCs as reported by the MXBean doesn't match the expected number. This is due to the additional GC happening due to CodeCache crossing its threshold. > We could increase the code cache or restrict the specific compiler that fills the cache. But this will not completely eliminate the possibility as cache size could be overridden or the same failure can happen for a different compiler. > > So, it is better to restrict the Xcomp flag as a whole. > > Testing: > Only local testing done as it is trivial change. One run with Xcomp and another without any flags. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22180#pullrequestreview-2443071900 From duke at openjdk.org Mon Nov 18 16:10:05 2024 From: duke at openjdk.org (duke) Date: Mon, 18 Nov 2024 16:10:05 GMT Subject: RFR: 8318668: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java fails with Xcomp In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 04:32:39 GMT, Ramkumar Sunderbabu wrote: > Trivial change to exclude the test from running with Xcomp flag. > > The test fails because the number of GCs as reported by the MXBean doesn't match the expected number. This is due to the additional GC happening due to CodeCache crossing its threshold. > We could increase the code cache or restrict the specific compiler that fills the cache. But this will not completely eliminate the possibility as cache size could be overridden or the same failure can happen for a different compiler. > > So, it is better to restrict the Xcomp flag as a whole. > > Testing: > Only local testing done as it is trivial change. One run with Xcomp and another without any flags. @rsunderbabu Your change (at version 25118b07d632cb5633faf1cda90fe7cf79c49bfd) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22180#issuecomment-2483479411 From dfuchs at openjdk.org Mon Nov 18 16:15:45 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 18 Nov 2024 16:15:45 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 15:17:33 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - remove missed suppression > - comment correction src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerAccessController.java line 76: > 74: * > 75: *

An MBean could possibly be a ClassLoader. Users who do not want an > 76: * MBean which could be a ClassLoader should not permit MBean creation.

Maybe we should just refuse to create an MBean which is a ClassLoader for now (see further comments below) and handle that part in a dedicated PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1846876232 From epeter at openjdk.org Mon Nov 18 16:20:34 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 16:20:34 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: <3rKTyNEnmn0CsKA-GlyyzcxyD6hu9lulWO8N0GYO4vA=.8bfdde20-62a7-467d-8b79-dc3d3bb625f2@github.com> <7h8Il7V3a1tbo_U2y2GyUY2tH8UPXtKc3we3ZZi47d4=.4a4cbe88-92a5-43cf-a6a9-48d0bed41cf7@github.com> <6rwCNBLV4-VemVsKR8KWYEgSIKfHQxS_RuxsPwX7TZo=.5fe167a3-1f97-408d-9d41-23d4d0fb42df@github.com> Message-ID: <-uhyD7i_oXhrCIMqAvFf7nt6DsjM6OY-_erP6UDAitg=.bb94ed2c-75f1-4d7a-b45a-113a5886a268@github.com> On Mon, 18 Nov 2024 15:20:17 GMT, Quan Anh Mai wrote: >> @merykitty I guess we can always use [vmovdqu](https://www.felixcloutier.com/x86/movdqu:vmovdqu8:vmovdqu16:vmovdqu32:vmovdqu64). >> >> And in fact that is exactly what we do: >> >> public class Test { >> static int RANGE = 1024*1024; >> >> public static void main(String[] args) { >> byte[] aB = new byte[RANGE]; >> byte[] bB = new byte[RANGE]; >> for (int i = 0; i < 100_000; i++) { >> test1(aB, bB); >> } >> } >> >> static void test1(byte[] a, byte[] b) { >> for (int i = 0; i < RANGE; i++) { >> a[i] = b[i]; >> } >> } >> } >> >> `../java -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printcompilation,Test::test* -XX:+TraceLoopOpts -XX:-TraceSuperWord -XX:+TraceNewVectors -Xbatch -XX:+AlignVector -XX:CompileCommand=compileonly,Test::test* -XX:CompileCommand=printassembly,Test::test* Test.java` >> >> >> ;; B20: # out( B20 B21 ) <- in( B19 B20 ) Loop( B20-B20 inner main of N178 strip mined) Freq: 8.13586e+09 >> 0x00007fc3a4bb0780: movslq %ebx,%rdi >> 0x00007fc3a4bb0783: movslq %ebx,%r14 >> 0x00007fc3a4bb0786: vmovdqu32 0x10(%r13,%r14,1),%zmm1 >> 0x00007fc3a4bb0791: vmovdqu32 %zmm1,0x10(%r9,%r14,1) >> 0x00007fc3a4bb079c: vmovdqu32 0x50(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07a7: vmovdqu32 %zmm1,0x50(%r9,%rdi,1) >> 0x00007fc3a4bb07b2: vmovdqu32 0x90(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07bd: vmovdqu32 %zmm1,0x90(%r9,%rdi,1) >> 0x00007fc3a4bb07c8: vmovdqu32 0xd0(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07d3: vmovdqu32 %zmm1,0xd0(%r9,%rdi,1) >> 0x00007fc3a4bb07de: vmovdqu32 0x110(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07e9: vmovdqu32 %zmm1,0x110(%r9,%rdi,1) >> 0x00007fc3a4bb07f4: vmovdqu32 0x150(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb07ff: vmovdqu32 %zmm1,0x150(%r9,%rdi,1) >> 0x00007fc3a4bb080a: vmovdqu32 0x190(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb0815: vmovdqu32 %zmm1,0x190(%r9,%rdi,1) >> 0x00007fc3a4bb0820: vmovdqu32 0x1d0(%r13,%rdi,1),%zmm1 >> 0x00007fc3a4bb082b: vmovdqu32 %zmm1,0x1d0(%r9,%rdi,1) ;*bastore {reexecute=0 rethrow=0 return_oop=0} >> ; - Test::test1 at 14 (line 14) >> 0x00007fc3a4bb0836: add $0x200,%ebx ;*iinc {reexecute=0 rethrow=0 return_oop=0} >> ... > > @eme64 What I mean here is that `AlignVector` seems useless because the accesses are going to be misaligned either way. @merykitty FYI: `src/hotspot/share/opto/vectorization.hpp: static bool vectors_should_be_aligned() { return !Matcher::misaligned_vectors_ok() || AlignVector; }` The relevant code: src/hotspot/cpu/x86/matcher_x86.hpp: static constexpr bool misaligned_vectors_ok() { // x86 supports misaligned vectors store/load. static constexpr bool misaligned_vectors_ok() { return true; } src/hotspot/cpu/ppc/matcher_ppc.hpp: static constexpr bool misaligned_vectors_ok() { // PPC implementation uses VSX load/store instructions (if // SuperwordUseVSX) which support 4 byte but not arbitrary alignment static constexpr bool misaligned_vectors_ok() { return false; } src/hotspot/cpu/aarch64/matcher_aarch64.hpp: static constexpr bool misaligned_vectors_ok() { // aarch64 supports misaligned vectors store/load. static constexpr bool misaligned_vectors_ok() { return true; } src/hotspot/cpu/s390/matcher_s390.hpp: static constexpr bool misaligned_vectors_ok() { // z/Architecture does support misaligned store/load at minimal extra cost. static constexpr bool misaligned_vectors_ok() { return true; } src/hotspot/cpu/arm/matcher_arm.hpp: static constexpr bool misaligned_vectors_ok() { // ARM doesn't support misaligned vectors store/load. static constexpr bool misaligned_vectors_ok() { return false; } src/hotspot/cpu/riscv/matcher_riscv.hpp: static constexpr bool misaligned_vectors_ok() { // riscv supports misaligned vectors store/load. static constexpr bool misaligned_vectors_ok() { return true; } We can see that only PPC and ARM32 have such strict alignment requirements. And it turns out that PPC only needs 4-byte alignment, and ARM32 is fine with 8-byte alignment. So all of our platforms do not necessarily need full vector-width alignment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483505834 From rsunderbabu at openjdk.org Mon Nov 18 16:20:58 2024 From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu) Date: Mon, 18 Nov 2024 16:20:58 GMT Subject: Integrated: 8318668: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java fails with Xcomp In-Reply-To: References: Message-ID: On Sun, 17 Nov 2024 04:32:39 GMT, Ramkumar Sunderbabu wrote: > Trivial change to exclude the test from running with Xcomp flag. > > The test fails because the number of GCs as reported by the MXBean doesn't match the expected number. This is due to the additional GC happening due to CodeCache crossing its threshold. > We could increase the code cache or restrict the specific compiler that fills the cache. But this will not completely eliminate the possibility as cache size could be overridden or the same failure can happen for a different compiler. > > So, it is better to restrict the Xcomp flag as a whole. > > Testing: > Only local testing done as it is trivial change. One run with Xcomp and another without any flags. This pull request has now been integrated. Changeset: 162d66ad Author: Ramkumar Sunderbabu Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/162d66adacf71e500c85382a155c7449a4f9ba55 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8318668: java/lang/management/MemoryMXBean/CollectionUsageThreshold.java fails with Xcomp Reviewed-by: kevinw, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/22180 From epeter at openjdk.org Mon Nov 18 16:32:28 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 16:32:28 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b Ah there are some exceptions: x86: `src/hotspot/cpu/x86/vm_version_x86.cpp: AlignVector = !UseUnalignedLoadStores;` if (supports_sse4_2()) { // new ZX cpus if (FLAG_IS_DEFAULT(UseUnalignedLoadStores)) { UseUnalignedLoadStores = true; // use movdqu on newest ZX cpus } } So I suppose some older platforms may be affected, though I have not seen one yet. They would have to be missing the unaligned `movdqu` instructions. aarch64: `src/hotspot/cpu/aarch64/vm_version_aarch64.cpp: AlignVector = AvoidUnalignedAccesses;` // Ampere eMAG if (_cpu == CPU_AMCC && (_model == CPU_MODEL_EMAG) && (_variant == 0x3)) { if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } and // ThunderX if (_cpu == CPU_CAVIUM && (_model == 0xA1)) { guarantee(_variant != 0, "Pre-release hardware no longer supported."); if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } and // ThunderX2 if ((_cpu == CPU_CAVIUM && (_model == 0xAF)) || (_cpu == CPU_BROADCOM && (_model == 0x516))) { if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } and // HiSilicon TSV110 if (_cpu == CPU_HISILICON && _model == 0xd01) { if (FLAG_IS_DEFAULT(AvoidUnalignedAccesses)) { FLAG_SET_DEFAULT(AvoidUnalignedAccesses, true); } So yes, some platforms are affected. But they seem to be the exception. And again: we have only had `ObjectAlignmentInBytes=8` alignment for vectors since forever - and no platform vendor has ever complained about that. Arrays never had a stronger alignment guarantee than that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483528037 PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483531916 From kevinw at openjdk.org Mon Nov 18 16:47:51 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 16:47:51 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v2] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 16:11:57 GMT, Daniel Fuchs wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove missed suppression >> - comment correction > > src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerAccessController.java line 76: > >> 74: * >> 75: *

An MBean could possibly be a ClassLoader. Users who do not want an >> 76: * MBean which could be a ClassLoader should not permit MBean creation.

> > Maybe we should just refuse to create an MBean which is a ClassLoader for now (see further comments below) and handle that part in a dedicated PR. Yes agreed I'm going to update again with checkClassLoader put back. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1846925982 From epeter at openjdk.org Mon Nov 18 16:52:22 2024 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 18 Nov 2024 16:52:22 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 15:00:51 GMT, Roman Kennke wrote: >>> @rkennke It just will (silently) not vectorize, thus running slower but still correct. >> >> Ok, I think we can live with that for now. >> >> As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. >> >> The tests need fixing, though. > >> @rkennke >> >> > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. >> >> Ah. So we would eventually have not a `12-byte` but `8-byte` offset from base to payload? Would that happen in all cases? And could that happen before `UseCompactObjectHeaders` leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of `UseCompactObjectHeaders + AlignVector`. Though I can surely do it. > > I am not sure if and when this is going to happen. When I presented the idea at JVMLS, I got some resistance. I am also not sure if we first leave experimental status for UCOH, and then introduce 4-byte headers under a new flag (or no flag?), or if we first do 4-byte headers and only leave experimental status once that is done. The latter sounds more reasonable to me. @rkennke Filed a bug to track this (we may close it as NotAnIssue, but this way people are aware / can find the analysis): [JDK-8344424](https://bugs.openjdk.org/browse/JDK-8344424): C2 SuperWord: mixed type loops do not vectorize with UseCompactObjectHeaders and AlignVector ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483579571 From rkennke at openjdk.org Mon Nov 18 17:00:24 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 17:00:24 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 15:30:14 GMT, Magnus Ihse Bursie wrote: >> test/hotspot/jtreg/gtest/MetaspaceUtilsGtests.java line 1: >> >> >> This file was reduced to empty but not actually deleted. Can you fix it please. > > @rkennke Just making sure this is not being missed. Can you please open a JBS issue to correct this and the file below? I filed: https://bugs.openjdk.org/browse/JDK-8344425 @tstuefe is working on it (mostly checking that nothing important has been removed) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/20677#discussion_r1846945329 From kevinw at openjdk.org Mon Nov 18 17:08:21 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 17:08:21 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v3] In-Reply-To: References: Message-ID: <2WLyt4xY4IoGlFLTsUuFg8CvRrW6KMQ2suYEBY9CcLk=.60bc29c9-7061-4108-93ef-b7b1f5489ec9@github.com> > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: add back checkClassLoader ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22100/files - new: https://git.openjdk.org/jdk/pull/22100/files/f8062515..df6ee04c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=01-02 Stats: 18 lines in 1 file changed: 15 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100 PR: https://git.openjdk.org/jdk/pull/22100 From rkennke at openjdk.org Mon Nov 18 17:09:24 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 18 Nov 2024 17:09:24 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v19] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 15:00:51 GMT, Roman Kennke wrote: >>> @rkennke It just will (silently) not vectorize, thus running slower but still correct. >> >> Ok, I think we can live with that for now. >> >> As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. >> >> The tests need fixing, though. > >> @rkennke >> >> > As said elsewhere, we are currently working on 4-byte-headers, which would make that problem go away. >> >> Ah. So we would eventually have not a `12-byte` but `8-byte` offset from base to payload? Would that happen in all cases? And could that happen before `UseCompactObjectHeaders` leaves experimental status? Because it is going to be a little annoying to adjust all vectorization tests for the special case of `UseCompactObjectHeaders + AlignVector`. Though I can surely do it. > > I am not sure if and when this is going to happen. When I presented the idea at JVMLS, I got some resistance. I am also not sure if we first leave experimental status for UCOH, and then introduce 4-byte headers under a new flag (or no flag?), or if we first do 4-byte headers and only leave experimental status once that is done. The latter sounds more reasonable to me. > @rkennke Filed a bug to track this (we may close it as NotAnIssue, but this way people are aware / can find the analysis): [JDK-8344424](https://bugs.openjdk.org/browse/JDK-8344424): C2 SuperWord: mixed type loops do not vectorize with UseCompactObjectHeaders and AlignVector Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2483619681 From kevinw at openjdk.org Mon Nov 18 17:11:44 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 17:11:44 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v3] In-Reply-To: <8moxYy-RsLK-QWmGrUX8ryO7Udcd-3f_uo0iNJcMwCw=.005222c5-8321-4ded-9bb6-a263a2b97cbf@github.com> References: <8moxYy-RsLK-QWmGrUX8ryO7Udcd-3f_uo0iNJcMwCw=.005222c5-8321-4ded-9bb6-a263a2b97cbf@github.com> Message-ID: On Mon, 18 Nov 2024 16:07:13 GMT, Daniel Fuchs wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> add back checkClassLoader > > src/java.management/share/classes/com/sun/jmx/remote/security/MBeanServerAccessController.java line 181: > >> 179: if (sm == null) { >> 180: Object object = getMBeanServer().instantiate(className); >> 181: checkClassLoader(object); > > I believe we should keep these calls to `checkClassLoader(object)` in place for now. What to do in this case will require some more thinking - I'd suggest handling that part in a separate PR. Yes agreed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1846962532 From kevinw at openjdk.org Mon Nov 18 17:23:43 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 17:23:43 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v3] In-Reply-To: <2WLyt4xY4IoGlFLTsUuFg8CvRrW6KMQ2suYEBY9CcLk=.60bc29c9-7061-4108-93ef-b7b1f5489ec9@github.com> References: <2WLyt4xY4IoGlFLTsUuFg8CvRrW6KMQ2suYEBY9CcLk=.60bc29c9-7061-4108-93ef-b7b1f5489ec9@github.com> Message-ID: On Mon, 18 Nov 2024 17:08:21 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > add back checkClassLoader MBeanServerAccessController.java: The access controller will refuse to create an MBean that is a ClassLoader. Previously, setting a SecurityManager would bypass this check. Without SM, keeping this restriction is a compatible and reasonable thing to do. If there do exist any MBeans which are ClassLoaders, then they have always required a SecurityManager, and therefore have more migration work to do. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22100#issuecomment-2483652181 From coleenp at openjdk.org Mon Nov 18 17:58:42 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 18 Nov 2024 17:58:42 GMT Subject: RFR: 8344247: Move objectWaiter field to VirtualThread instance In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:34:24 GMT, Patricio Chilano Mateo wrote: > Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. > Tested by running mach5 tiers1-3. > > Thanks, > Patricio This is a nice cleanup. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22124#pullrequestreview-2443328377 From amenkov at openjdk.org Mon Nov 18 19:08:50 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 18 Nov 2024 19:08:50 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.instrument [v2] In-Reply-To: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> References: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> Message-ID: On Mon, 18 Nov 2024 10:50:24 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> test/jdk/java/lang/instrument/ still passing. > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - static block not needed > - Merge remote-tracking branch 'upstream/master' into 8344187_PostSM_instrument > - update > - 8344187: Remove SecurityManager and related calls from java.instrument Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22106#pullrequestreview-2443475581 From kevinw at openjdk.org Mon Nov 18 19:21:00 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 19:21:00 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.instrument [v2] In-Reply-To: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> References: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> Message-ID: On Mon, 18 Nov 2024 10:50:24 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> test/jdk/java/lang/instrument/ still passing. > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - static block not needed > - Merge remote-tracking branch 'upstream/master' into 8344187_PostSM_instrument > - update > - 8344187: Remove SecurityManager and related calls from java.instrument Thanks Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22106#issuecomment-2483902201 From kevinw at openjdk.org Mon Nov 18 19:21:00 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 18 Nov 2024 19:21:00 GMT Subject: Integrated: 8344187: Remove SecurityManager and related calls from java.instrument In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 13:03:28 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > test/jdk/java/lang/instrument/ still passing. This pull request has now been integrated. Changeset: 70eb95f8 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/70eb95f8488aa39c22ee404c1a4756ecf5db7af6 Stats: 34 lines in 2 files changed: 0 ins; 28 del; 6 mod 8344187: Remove SecurityManager and related calls from java.instrument Reviewed-by: alanb, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/22106 From amenkov at openjdk.org Mon Nov 18 19:41:54 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Mon, 18 Nov 2024 19:41:54 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent In-Reply-To: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: On Fri, 15 Nov 2024 17:36:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java > There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... > > src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java > Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java line 72: > 70: Field f = cl.getDeclaredField("builder"); > 71: f.setAccessible(true); > 72: builder = (GcInfoBuilder) f.get(gcNotifInfo.getGcInfo()); Suggestion: builder = (GcInfoBuilder)f.get(gcNotifInfo.getGcInfo()); src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java line 77: > 75: Field f = cl.getDeclaredField("builder"); > 76: f.setAccessible(true); > 77: builder = (GcInfoBuilder)f.get(info); Suggestion: builder = (GcInfoBuilder)f.get(info); src/jdk.management/share/classes/com/sun/management/internal/HotSpotDiagnostic.java line 52: > 50: > 51: String propertyName = "jdk.management.heapdump.allowAnyFileSuffix"; > 52: boolean allowAnyFileSuffix = Boolean.parseBoolean(System.getProperty(propertyName, "false")); can be simplified to `Boolean.getBoolean(propertyName)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1847129967 PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1847133367 PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1847140386 From lmesnik at openjdk.org Mon Nov 18 19:53:30 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 19:53:30 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v4] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/runtime/vmOperations.hpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/0fb641c9..55f0682c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Mon Nov 18 20:00:09 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 20:00:09 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v5] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: added printing of native id, renamed variables ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/55f0682c..2f1e3d71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=03-04 Stats: 18 lines in 5 files changed: 10 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Mon Nov 18 20:00:10 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 20:00:10 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v3] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Mon, 18 Nov 2024 05:32:52 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> make test more robust > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 70: > >> 68: public String name() { return CStringUtilities.getString(addr.getAddressAt(nameFieldOffset)); } >> 69: >> 70: public Address owner() { return addr.getAddressAt(ownerFieldOffset); } > > Printing the `osThread()->thread_id()` might be more useful than printing the address. sa updated to print native id for all threads, and address ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1847167169 From duke at openjdk.org Mon Nov 18 20:47:49 2024 From: duke at openjdk.org (Larry Cable) Date: Mon, 18 Nov 2024 20:47:49 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v4] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 20:39:55 GMT, Larry Cable wrote: >> the implementation I originally provided does not in fact solve the issue! >> >> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). >> >> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach >> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. >> >> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). >> >> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. >> >> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". >> >> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". >> >> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). >> >> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. >> >> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. >> >> therefore an "attacher" has two choices when attempting to attach: >> >> - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) >> - this works with both peers and descendants >> >> - use /tmp >> - this only works if the "attacher" and "attachee" share a /tmp in common >> >> the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. >> >> I... > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8342449: minor changes in response to previous review comments passed: open/test/hotspot/jtreg/serviceability/attach open/test/jdk/com/sun/tools/attach/ ------------- PR Comment: https://git.openjdk.org/jdk/pull/21688#issuecomment-2484094142 From pchilanomate at openjdk.org Mon Nov 18 20:51:47 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 18 Nov 2024 20:51:47 GMT Subject: RFR: 8344247: Move objectWaiter field to VirtualThread instance In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:34:24 GMT, Patricio Chilano Mateo wrote: > Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. > Tested by running mach5 tiers1-3. > > Thanks, > Patricio Thanks for the reviews David and Coleen! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22124#issuecomment-2484098204 From pchilanomate at openjdk.org Mon Nov 18 20:51:47 2024 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Mon, 18 Nov 2024 20:51:47 GMT Subject: Integrated: 8344247: Move objectWaiter field to VirtualThread instance In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:34:24 GMT, Patricio Chilano Mateo wrote: > Small follow-up change after JDK-8338383. This moves the `objectWaiter` field from the stackChunk to the VirtualThread instance. Only the top stackChunk uses this field so we could save some memory by just saving it in the virtual thread instance instead. Also, related methods `stackChunkOopDesc::current_pending_monitor` and `stackChunkOopDesc::current_waiting_monitor` are moved to the `java_lang_VirtualThread` class where they naturally belong, since these are the equivalent of the JavaThread methods but for an unmounted vthread. > Tested by running mach5 tiers1-3. > > Thanks, > Patricio This pull request has now been integrated. Changeset: f6366748 Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/f636674889f925d4feb9a8d2be811e66f9b3a0ac Stats: 115 lines in 12 files changed: 39 ins; 62 del; 14 mod 8344247: Move objectWaiter field to VirtualThread instance Reviewed-by: dholmes, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/22124 From lmesnik at openjdk.org Mon Nov 18 20:56:27 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 20:56:27 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v6] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: tests using osthread fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/2f1e3d71..056ec87a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=04-05 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From cjplummer at openjdk.org Mon Nov 18 22:01:55 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 18 Nov 2024 22:01:55 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v4] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 20:45:14 GMT, Larry Cable wrote: > passed: > open/test/hotspot/jtreg/serviceability/attach > open/test/jdk/com/sun/tools/attach/ You might want to add test/hotspot/jtreg/serviceability/dcmd ------------- PR Comment: https://git.openjdk.org/jdk/pull/21688#issuecomment-2484219189 From lmesnik at openjdk.org Mon Nov 18 22:27:44 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 18 Nov 2024 22:27:44 GMT Subject: RFR: 8253440: serviceability/sa/TestJhsdbJstackLineNumbers.java failed with "Didn't find enough line numbers" In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 19:20:55 GMT, Chris Plummer wrote: > The test is checking to make sure SA will use what is in the bcp register to determine the current line number rather than just use frame->bcp, which often is not up to date. It spawns a debuggee that sits in a loop that is 10 lines of source. The test executes jstack on the debuggee and determines the current line number from the output. It does this 25 times and expectesto see at least 5 of the 10 line numbers being hit. There's no guarantee it will hit at least five. The chances of this not happening are very very low, but apparently the test has failed a couple of times because only 4 unique lines were hit. I decided to do the simple fix and just lower the threshhold to 4 lines. > > Ran locally on linux-x64. Tier1 in progress. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22117#pullrequestreview-2443859014 From wkemper at openjdk.org Mon Nov 18 22:32:02 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 18 Nov 2024 22:32:02 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <2m-YJkwNcpIEDdVElZOw2uqbTD6eOoBM0cRGoSFdADM=.86118c91-b8dd-4da9-b691-5ffe0643f51d@github.com> Message-ID: On Fri, 15 Nov 2024 15:12:30 GMT, Martin Doerr wrote: >> The new test TestAllocOutOfMemory.java#large failed on some PPC64 machines: >> >> Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "main" >> >> java.lang.RuntimeException: 'java.lang.OutOfMemoryError: Java heap space' missing from stdout/stderr >> >> Probably not a show-stopper. Should the test be adapted or disabled for this platform? > >> @TheRealMDoerr - do you have the logs from the test failure? If so, could you open a ticket with them in JBS? Thank you! > > Filed [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). > > In addition, we see the following tests failing with "java.lang.OutOfMemoryError: Java heap space" on all Shenandoah platforms: > gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#default > gc/stress/jfr/TestStressBigAllocationGCEventsWithShenandoah.java#generational > Can you reproduce those? @TheRealMDoerr , it looks like @ysramakrishna has [filed a ticket already](https://bugs.openjdk.org/browse/JDK-8342786) for the `TestStressBigAllocationGCEventsWithShenandoah` failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2484266111 From amenkov at openjdk.org Tue Nov 19 00:09:12 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 19 Nov 2024 00:09:12 GMT Subject: RFR: 8342995: Enhance Attach API to support arbitrary length arguments - Linux Message-ID: The fix updates Linux (and server-side of macosx) implementation to support Attach API v2 (shared code and Windows implementation were introduced by #20782) Testing: tier1,tier2,tier3,tier4,hs-tier5-svc manually tested backward compatibility (old tools can attach to current VMs, current tools can attach to older VMs) with jdk21 and jdk8. ------------- Commit messages: - attach_v2_linux Changes: https://git.openjdk.org/jdk/pull/22223/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22223&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342995 Stats: 323 lines in 5 files changed: 98 ins; 193 del; 32 mod Patch: https://git.openjdk.org/jdk/pull/22223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22223/head:pull/22223 PR: https://git.openjdk.org/jdk/pull/22223 From amenkov at openjdk.org Tue Nov 19 00:11:49 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 19 Nov 2024 00:11:49 GMT Subject: Integrated: 8344262: Win32AttachOperationRequest objects are created by using global new In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 21:05:21 GMT, Alex Menkov wrote: > The issue was introduced by [JDK-8339289](https://bugs.openjdk.org/browse/JDK-8339289). > The fix makes `Win32AttachOperationRequest` successor of `CHeapObj`, so `Win32AttachOperationRequest` inherits its `new` operator > > testing: tier1..tier4 This pull request has now been integrated. Changeset: dd863690 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/dd8636908c6a604a9b191d7dcce8490fa8e3eb4d Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8344262: Win32AttachOperationRequest objects are created by using global new Reviewed-by: jwaters, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/22166 From lmesnik at openjdk.org Tue Nov 19 00:45:25 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Nov 2024 00:45:25 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT Message-ID: The jcmd VM.events max parameter type is changed to INT. Also,I noted the max <= 0 is ignored, so I updated documentation and set "0" as a default value. The jcmd exists if parameter is negative now. The `max` is `int` while really it is the unsigned int. However I don't think it makes sense to change it to `size_t` or `unsigned int` in all places where 'max' is used. ------------- Commit messages: - max_value -> max - parameter changed to log Changes: https://git.openjdk.org/jdk/pull/22224/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22224&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340334 Stats: 10 lines in 2 files changed: 0 ins; 4 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/22224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22224/head:pull/22224 PR: https://git.openjdk.org/jdk/pull/22224 From duke at openjdk.org Tue Nov 19 02:31:44 2024 From: duke at openjdk.org (Larry Cable) Date: Tue, 19 Nov 2024 02:31:44 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v4] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 20:39:55 GMT, Larry Cable wrote: >> the implementation I originally provided does not in fact solve the issue! >> >> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). >> >> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach >> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. >> >> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). >> >> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. >> >> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". >> >> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". >> >> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). >> >> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. >> >> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. >> >> therefore an "attacher" has two choices when attempting to attach: >> >> - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) >> - this works with both peers and descendants >> >> - use /tmp >> - this only works if the "attacher" and "attachee" share a /tmp in common >> >> the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. >> >> I... > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8342449: minor changes in response to previous review comments ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR jtreg:open/test/hotspot/jtreg/serviceability/dcmd 49 49 0 0 ============================== TEST SUCCESS ------------- PR Comment: https://git.openjdk.org/jdk/pull/21688#issuecomment-2484575517 From dholmes at openjdk.org Tue Nov 19 06:58:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Nov 2024 06:58:53 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT In-Reply-To: References: Message-ID: <-poZAS8WKk-DCPCO3UdlAvOLkFw11w_knbXBg7ZY-DU=.e2425d1d-929c-4f5c-bf2f-b312592e21d6@github.com> On Tue, 19 Nov 2024 00:40:09 GMT, Leonid Mesnik wrote: > The jcmd VM.events max parameter type is changed to INT. > Also,I noted the max <= 0 is ignored, so I updated documentation and set "0" as a default value. > The jcmd exists if parameter is negative now. > > The `max` is `int` while really it is the unsigned int. However I don't think it makes sense to change it to `size_t` or `unsigned int` in all places where 'max' is used. I always struggle seeing the full code path for DCmd arguments, if you no longer parse the STRING to get an int, then where is the parsing now happening? src/hotspot/share/services/diagnosticCommand.hpp line 892: > 890: protected: > 891: DCmdArgument _log; > 892: DCmdArgument _max; Why `jlong` and not `jint`? ------------- PR Review: https://git.openjdk.org/jdk/pull/22224#pullrequestreview-2444425042 PR Review Comment: https://git.openjdk.org/jdk/pull/22224#discussion_r1847736544 From dholmes at openjdk.org Tue Nov 19 07:08:53 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Nov 2024 07:08:53 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: <44duw-bwTlAaNhATsWQA0Fn13fAK0gaCTCsrSGBzibg=.eb7fbcdf-6229-4d13-a3d8-0df6a948c4f5@github.com> References: <44duw-bwTlAaNhATsWQA0Fn13fAK0gaCTCsrSGBzibg=.eb7fbcdf-6229-4d13-a3d8-0df6a948c4f5@github.com> Message-ID: On Mon, 18 Nov 2024 12:39:32 GMT, Coleen Phillimore wrote: >> I don't see any difference in the callers in relation to this PR and the function is not presently declared `extern`. ?? > > There was an extern trace_class_resolution() function that called this _impl function that I removed, so renamed this impl function to trace_class_resolution(). > It's declared extern in jvm.hp file, and this 'extern' qualifier is added so it's easy to see that this is used externally. Sorry but not seeing that. It is declared in `jvm_misc.hpp` but not as `extern`. The original version was not `extern`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1847747913 From dholmes at openjdk.org Tue Nov 19 07:34:57 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 19 Nov 2024 07:34:57 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v6] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <2L7z3oaJ_Dqa2Zx675YdrECyfC-8ZzfoGLPsl33dTyA=.d2c5df4f-74bf-4274-ae75-a8cb134f5664@github.com> On Mon, 18 Nov 2024 20:56:27 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > tests using osthread fixed Thanks for updates. svc folk will need to do actual Review though. ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2444494159 From aph at openjdk.org Tue Nov 19 09:45:24 2024 From: aph at openjdk.org (Andrew Haley) Date: Tue, 19 Nov 2024 09:45:24 GMT Subject: RFR: 8305895: Implement JEP 450: Compact Object Headers (Experimental) [v57] In-Reply-To: References: Message-ID: On Thu, 7 Nov 2024 17:25:40 GMT, Roman Kennke wrote: >> This is the main body of the JEP 450: Compact Object Headers (Experimental). >> >> It is also a follow-up to #20640, which now also includes (and supersedes) #20603 and #20605, plus the Tiny Class-Pointers parts that have been previously missing. >> >> Main changes: >> - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag. The purpose of the flag is to provide a fallback, in case that users unexpectedly observe problems with the new implementation. The intention is that this flag will remain experimental and opt-in for at least one release, then make it on-by-default and diagnostic (?), and eventually deprecate and obsolete it. However, there are a few unknowns in that plan, specifically, we may want to further improve compact headers to 4 bytes, we are planning to enhance the Klass* encoding to support virtually unlimited number of Klasses, at which point we could also obsolete UseCompressedClassPointers. >> - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are add some changes to GC forwarding (see below) to protect the relevant (upper 22) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded. >> - Self-forwarding in GCs (which is used to deal with promotion failure) now uses a bit to indicate 'self-forwarding'. This is needed to preserve the crucial Klass* bits in the header. This also allows to get rid of preserved-header machinery in SerialGC and G1 (Parallel GC abuses preserved-marks to also find all other relevant oops). >> - Full GC forwarding now uses an encoding similar to compressed-oops. We have 40 bits for that, and can encode up to 8TB of heap. When exceeding 8TB, we turn off UseCompressedClassPointers (except in ZGC, which doesn't use the GC forwarding at all). >> - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16). >> - Arrays will now store their length at offset 8. >> - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders. Some build machinery is added so that _co... > > Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 107 commits: > > - Merge branch 'master' into JDK-8305895-v4 > - Merge tag 'jdk-25+23' into JDK-8305895-v4 > > Added tag jdk-24+23 for changeset c0e6c3b9 > - Fix gen-ZGC removal > - Merge tag 'jdk-24+22' into JDK-8305895-v4 > > Added tag jdk-24+22 for changeset 388d44fb > - Enable riscv in CompressedClassPointersEncodingScheme test > - s390 port > - Conditionalize platform specific parts of CompressedClassPointersEncodingScheme test > - Update copyright > - Avoid assert/endless-loop in JFR code > - Update copyright headers > - ... and 97 more: https://git.openjdk.org/jdk/compare/d3c042f9...c1a6323b > So yes, some platforms [have alignment requirements for vectors]. But they seem to be the exception. All AArch64 implementations work with unaligned vectors ? that's in the architecture spec ? but some designs thaht were made years ago performed badly. It's not a problem with new designs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20677#issuecomment-2485185002 From kevinw at openjdk.org Tue Nov 19 10:16:46 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 10:16:46 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT In-Reply-To: <-poZAS8WKk-DCPCO3UdlAvOLkFw11w_knbXBg7ZY-DU=.e2425d1d-929c-4f5c-bf2f-b312592e21d6@github.com> References: <-poZAS8WKk-DCPCO3UdlAvOLkFw11w_knbXBg7ZY-DU=.e2425d1d-929c-4f5c-bf2f-b312592e21d6@github.com> Message-ID: On Tue, 19 Nov 2024 06:54:57 GMT, David Holmes wrote: >> The jcmd VM.events max parameter type is changed to INT. >> Also,I noted the max <= 0 is ignored, so I updated documentation and set "0" as a default value. >> The jcmd exists if parameter is negative now. >> >> The `max` is `int` while really it is the unsigned int. However I don't think it makes sense to change it to `size_t` or `unsigned int` in all places where 'max' is used. > > src/hotspot/share/services/diagnosticCommand.hpp line 892: > >> 890: protected: >> 891: DCmdArgument _log; >> 892: DCmdArgument _max; > > Why `jlong` and not `jint`? Everything which parses an integer option uses DCmdArgument (e.g. heap dump parallelism, etc...) DCmdArgument::parse_value(..) does the parsing, we have never had a definition for DCmdArgument ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22224#discussion_r1848047861 From kevinw at openjdk.org Tue Nov 19 10:20:21 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 10:20:21 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT In-Reply-To: References: Message-ID: <6Rkf8akqpp7Y2PTOrT5C5svHfE4OWiWrXEblbKJ0_fE=.4d62ef1c-24e4-4476-a659-dd2f0e0d6a62@github.com> On Tue, 19 Nov 2024 00:40:09 GMT, Leonid Mesnik wrote: > The jcmd VM.events max parameter type is changed to INT. > Also,I noted the max <= 0 is ignored, so I updated documentation and set "0" as a default value. > The jcmd exists if parameter is negative now. > > The `max` is `int` while really it is the unsigned int. However I don't think it makes sense to change it to `size_t` or `unsigned int` in all places where 'max' is used. Looks good. Right, the all integer parsing is signed, and long, and we don't express any more detail in the man page or the MBean, it's just "INT" for an integral value. OK, speaking of man pages... 8-) (that could be updated here or separately) ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22224#pullrequestreview-2444977753 From eirbjo at openjdk.org Tue Nov 19 12:09:52 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 19 Nov 2024 12:09:52 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.instrument [v2] In-Reply-To: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> References: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> Message-ID: On Mon, 18 Nov 2024 10:50:24 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> test/jdk/java/lang/instrument/ still passing. > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - static block not needed > - Merge remote-tracking branch 'upstream/master' into 8344187_PostSM_instrument > - update > - 8344187: Remove SecurityManager and related calls from java.instrument src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 40: > 38: import java.net.URL; > 39: import java.security.CodeSource; > 40: import java.security.PrivilegedAction; A note for future cleanups in this area: This `java.security.PrivilegedAction` import should probably have been removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22106#discussion_r1848231895 From coleenp at openjdk.org Tue Nov 19 12:25:56 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 12:25:56 GMT Subject: RFR: 8341916: Remove ProtectionDomain related hotspot code and tests [v5] In-Reply-To: References: <44duw-bwTlAaNhATsWQA0Fn13fAK0gaCTCsrSGBzibg=.eb7fbcdf-6229-4d13-a3d8-0df6a948c4f5@github.com> Message-ID: <61JEPJpF_UdZN0n4kaX5N6uYuD7iVsTunoGZFjJdWcE=.a48a091c-bbb3-4a23-95cc-305a948e7a93@github.com> On Tue, 19 Nov 2024 07:06:15 GMT, David Holmes wrote: >> There was an extern trace_class_resolution() function that called this _impl function that I removed, so renamed this impl function to trace_class_resolution(). >> It's declared extern in jvm.hp file, and this 'extern' qualifier is added so it's easy to see that this is used externally. > > Sorry but not seeing that. It is declared in `jvm_misc.hpp` but not as `extern`. The original version was not `extern`. You're right, it has extern linkage but not declared with extern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22064#discussion_r1848255968 From kevinw at openjdk.org Tue Nov 19 12:32:03 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 12:32:03 GMT Subject: RFR: 8344187: Remove SecurityManager and related calls from java.instrument [v2] In-Reply-To: References: <5Hw35lY9zkZbdvWv7NVbkyt48tJ1tmHpl2VKk3RvfLk=.ad30b8ba-3c25-4ab6-b562-000dcf017013@github.com> Message-ID: On Tue, 19 Nov 2024 12:06:51 GMT, Eirik Bj?rsn?s wrote: >> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: >> >> - static block not needed >> - Merge remote-tracking branch 'upstream/master' into 8344187_PostSM_instrument >> - update >> - 8344187: Remove SecurityManager and related calls from java.instrument > > src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java line 40: > >> 38: import java.net.URL; >> 39: import java.security.CodeSource; >> 40: import java.security.PrivilegedAction; > > A note for future cleanups in this area: This `java.security.PrivilegedAction` import should probably have been removed. thanks 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22106#discussion_r1848264566 From coleenp at openjdk.org Tue Nov 19 13:05:44 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 13:05:44 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: <_LhNj_7aiKdyarux6QG5NP1C8PhNrfvdrr6MxtgR1Vk=.2c6cb2a2-1062-4b73-81de-2037d2d1e26a@github.com> On Fri, 15 Nov 2024 15:30:05 GMT, Coleen Phillimore wrote: >> This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. >> >> The fix for always verifying redefined classes was actually pushed with JDK-8341094, where the verifier code respected the parameter "should_verify_class". By default this parameter follows the -Xverify setting. For redefinition, this is passed as true. The rest of the fix removes the special bootstrap loader cases that may have failed early on in the JDK development with -Xverify:all but now no longer do. If someone tries to redefine these classes, they should also do the verification on the redefined bytecodes. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. I added to the description to explain how the fix works. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-2485660080 From aturbanov at openjdk.org Tue Nov 19 13:29:49 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 19 Nov 2024 13:29:49 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v6] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Mon, 18 Nov 2024 20:56:27 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > tests using osthread fixed src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 39: > 37: > 38: private static AddressField mutex_array; > 39: private static int maxNum; Let's align with `mutex_array` src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 52: > 50: > 51: private static synchronized void initialize(TypeDataBase db) throws WrongTypeException { > 52: Type type = db.lookupType("Mutex"); Suggestion: Type type = db.lookupType("Mutex"); src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 60: > 58: ownerFieldOffset = f.getOffset(); > 59: mutex_array = type.getAddressField("_mutex_array"); > 60: maxNum = type.getCIntegerField("_num_mutex").getJInt(); Suggestion: maxNum = type.getCIntegerField("_num_mutex").getJInt(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1848364844 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1848365330 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1848365177 From sgehwolf at openjdk.org Tue Nov 19 13:37:25 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 19 Nov 2024 13:37:25 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v13] In-Reply-To: References: Message-ID: > Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. > > For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). > > This patch addresses this issue by: > > 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. > 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). > > As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. > > This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. > > Thoughts? > > Testing: > > - [x] GHA > - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems > - [x] Some manual testing using systemd slices Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits: - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Add exclusive access dirs directive for systemd tests - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Merge branch 'master' into jdk-8336881-metrics-systemd-slice - Improve systemd slice test for non-root on cg v2 - Fix unit tests - Add JVM_HostActiveProcessorCount using JVM api - ... and 28 more: https://git.openjdk.org/jdk/compare/23597361...b56fc7b7 ------------- Changes: https://git.openjdk.org/jdk/pull/20280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=12 Stats: 1595 lines in 27 files changed: 1344 ins; 152 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/20280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280 PR: https://git.openjdk.org/jdk/pull/20280 From kevinw at openjdk.org Tue Nov 19 14:24:15 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 14:24:15 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v2] In-Reply-To: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java > There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... > > src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java > Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - space - Missed getBoolean ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22155/files - new: https://git.openjdk.org/jdk/pull/22155/files/6922bce4..39ae0074 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22155&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22155&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22155/head:pull/22155 PR: https://git.openjdk.org/jdk/pull/22155 From kevinw at openjdk.org Tue Nov 19 14:24:16 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 14:24:16 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v2] In-Reply-To: References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: <3kuJKDnBK8DoOcHtAZLhSBEuBld0wnwDYQUWHXL-tbU=.694bca26-4722-47ee-969d-21c0f0da5252@github.com> On Mon, 18 Nov 2024 19:25:36 GMT, Alex Menkov wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - space >> - Missed getBoolean > > src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java line 77: > >> 75: Field f = cl.getDeclaredField("builder"); >> 76: f.setAccessible(true); >> 77: builder = (GcInfoBuilder)f.get(info); > > Suggestion: > > builder = (GcInfoBuilder)f.get(info); done > src/jdk.management/share/classes/com/sun/management/internal/HotSpotDiagnostic.java line 52: > >> 50: >> 51: String propertyName = "jdk.management.heapdump.allowAnyFileSuffix"; >> 52: boolean allowAnyFileSuffix = Boolean.parseBoolean(System.getProperty(propertyName, "false")); > > can be simplified to `Boolean.getBoolean(propertyName)` Yes, missed that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1848455057 PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1848454800 From kevinw at openjdk.org Tue Nov 19 14:29:55 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 14:29:55 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v2] In-Reply-To: References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: On Mon, 18 Nov 2024 19:22:30 GMT, Alex Menkov wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - space >> - Missed getBoolean > > src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java line 72: > >> 70: Field f = cl.getDeclaredField("builder"); >> 71: f.setAccessible(true); >> 72: builder = (GcInfoBuilder) f.get(gcNotifInfo.getGcInfo()); > > Suggestion: > > builder = (GcInfoBuilder)f.get(gcNotifInfo.getGcInfo()); OK, it was missing the space before, when moving it around I added the space, as that's what we normally have. In this directory there is a mixture of the two styles, with and without spaces. I hope it's OK to let this one migrate to the more modern style. 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1848465465 From kevinw at openjdk.org Tue Nov 19 14:40:00 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 14:40:00 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v4] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 20:39:55 GMT, Larry Cable wrote: >> the implementation I originally provided does not in fact solve the issue! >> >> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). >> >> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach >> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. >> >> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). >> >> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. >> >> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". >> >> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". >> >> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). >> >> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. >> >> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. >> >> therefore an "attacher" has two choices when attempting to attach: >> >> - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) >> - this works with both peers and descendants >> >> - use /tmp >> - this only works if the "attacher" and "attachee" share a /tmp in common >> >> the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. >> >> I... > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8342449: minor changes in response to previous review comments Updates look good. ------------- Marked as reviewed by kevinw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21688#pullrequestreview-2445671967 From aturbanov at openjdk.org Tue Nov 19 14:56:00 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Tue, 19 Nov 2024 14:56:00 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v3] In-Reply-To: <2WLyt4xY4IoGlFLTsUuFg8CvRrW6KMQ2suYEBY9CcLk=.60bc29c9-7061-4108-93ef-b7b1f5489ec9@github.com> References: <2WLyt4xY4IoGlFLTsUuFg8CvRrW6KMQ2suYEBY9CcLk=.60bc29c9-7061-4108-93ef-b7b1f5489ec9@github.com> Message-ID: On Mon, 18 Nov 2024 17:08:21 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > add back checkClassLoader src/java.management/share/classes/sun/management/ManagementFactoryHelper.java line 194: > 192: if (logging.isPresent()) { > 193: return Class.forName(logging.get(), className); > 194: } else { Suggestion: } else { src/java.management/share/classes/sun/management/VMManagementImpl.java line 249: > 247: > 248: // construct PerfInstrumentation object > 249: Perf perf = Perf.getPerf(); Suggestion: Perf perf = Perf.getPerf(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1848511628 PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1848512131 From kevinw at openjdk.org Tue Nov 19 15:28:17 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 15:28:17 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v4] In-Reply-To: References: Message-ID: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - space - space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22100/files - new: https://git.openjdk.org/jdk/pull/22100/files/df6ee04c..3a524945 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=02-03 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100 PR: https://git.openjdk.org/jdk/pull/22100 From kevinw at openjdk.org Tue Nov 19 15:28:18 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 15:28:18 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v3] In-Reply-To: References: <2WLyt4xY4IoGlFLTsUuFg8CvRrW6KMQ2suYEBY9CcLk=.60bc29c9-7061-4108-93ef-b7b1f5489ec9@github.com> Message-ID: On Tue, 19 Nov 2024 14:52:21 GMT, Andrey Turbanov wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> add back checkClassLoader > > src/java.management/share/classes/sun/management/ManagementFactoryHelper.java line 194: > >> 192: if (logging.isPresent()) { >> 193: return Class.forName(logging.get(), className); >> 194: } else { > > Suggestion: > > } else { ok thanks > src/java.management/share/classes/sun/management/VMManagementImpl.java line 249: > >> 247: >> 248: // construct PerfInstrumentation object >> 249: Perf perf = Perf.getPerf(); > > Suggestion: > > Perf perf = Perf.getPerf(); ok yes, an existing double-space but we'll fix it 8-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1848571615 PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1848572302 From shade at openjdk.org Tue Nov 19 16:08:32 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Nov 2024 16:08:32 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 Some more stuff. 180/230 files done %) src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 420: > 418: } > 419: int gc_state = _heap->gc_state(); > 420: if ((gc_state & ShenandoahHeap::YOUNG_MARKING) != 0) { It is not very clear this works fine with single-gen mode. Does `MARKING` imply `YOUNG_MARKING` in single-gen mode? I think we better make it abundantly clear with `is_generational()` checks. src/hotspot/share/gc/shenandoah/shenandoahCollectionSetPreselector.hpp line 34: > 32: ShenandoahCollectionSet* _cset; > 33: bool* _pset; > 34: ResourceMark _rm; Not necessarily for this PR, but something to rectify going forward. It is generally not safe to hide `ResourceMark`-s like this in the objects. Sometimes the callers return stuff allocated in resource area, and if the object like this leaves the scope, it would corrupt the memory. Normally, when we develop resource-area-returning paths, we look around near `ResourceMark`-s to see is any thing fishy is going on. It does not help when `RM` is hidden in the object like this. src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 276: > 274: log_info(gc)("GC cancellation took %.3fs", cancel_time); > 275: _cancel_requested_time = 0; > 276: } Do we need this? Is this useful? src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 49: > 47: const char* cns = PerfDataManager::name_space("shenandoah", "regions"); > 48: _name_space = NEW_C_HEAP_ARRAY(char, strlen(cns)+1, mtGC); > 49: strcpy(_name_space, cns); // copy cns into _name_space Suggestion: strcpy(_name_space, cns); (The comment is self-obvious) src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 57: > 55: PerfDataManager::create_constant(SUN_GC, cname, PerfData::U_None, num_regions, CHECK); > 56: > 57: cname = PerfDataManager::counter_name(_name_space, "protocol_version"); //creating new protocol_version Suggestion: cname = PerfDataManager::counter_name(_name_space, "protocol_version"); src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp line 193: > 191: Phase phase = Phase(pi); > 192: if (is_worker_phase(phase)) { > 193: double sum = uninitialized(); I think you can avoid changing this method to limit the churn. src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 455: > 453: // Note: would be sufficient to mark only the card that holds the start of this Reference object. > 454: heap->old_generation()->card_scan()->mark_range_as_dirty(cast_from_oop(reference), reference->size()); > 455: } Two things: a) This sounds like `card_table_barrier(reference, raw_referent)`? Since this code is getting called for every dropped reference, just checking a `ShenandoahCardBarrier` flag sounds more efficient. b) Is there a point in dirtying up to `reference->size()`? src/hotspot/share/gc/shenandoah/shenandoahSharedVariables.hpp line 125: > 123: ShenandoahSharedValue ov = Atomic::load_acquire(&value); > 124: // We require all bits of mask_val to be set > 125: if ((ov & mask_val) == mask_val) { This looks like a pre-existing bug, right? I assume this does not affect current Shenandoah, since we do not set multiple bits. I am fine with doing this in this PR, but it would probably be good to backport this fix in earlier releases too. ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2439178281 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848286637 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1846888999 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844183614 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844187355 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1844186936 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1846892659 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1846923725 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848264678 From eirbjo at openjdk.org Tue Nov 19 16:30:50 2024 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 19 Nov 2024 16:30:50 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie wrote: >> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. >> >> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. >> >> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > It's somewhat nicer to use \\s instead of space character in regex Is the warning log when pandoc is not installed a bit loud? % make images Building target 'images' in configuration 'macosx-x86_64-server-release' Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Warning: pandoc not found. Not generating man pages Finished building target 'images' in configuration 'macosx-x86_64-server-release' ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2486187436 From lmesnik at openjdk.org Tue Nov 19 18:30:37 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Nov 2024 18:30:37 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed spaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/056ec87a..0fbafab4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From bpb at openjdk.org Tue Nov 19 18:35:25 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 19 Nov 2024 18:35:25 GMT Subject: RFR: 8344562: Remove security manager dependency from module jdk.jdi Message-ID: Trivial removal of the use of the `SecurityManager` from a single class. ------------- Commit messages: - 8344562: Remove security manager dependency from module jdk.jdi Changes: https://git.openjdk.org/jdk/pull/22251/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22251&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344562 Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22251/head:pull/22251 PR: https://git.openjdk.org/jdk/pull/22251 From duke at openjdk.org Tue Nov 19 18:42:58 2024 From: duke at openjdk.org (duke) Date: Tue, 19 Nov 2024 18:42:58 GMT Subject: RFR: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid [v4] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 20:39:55 GMT, Larry Cable wrote: >> the implementation I originally provided does not in fact solve the issue! >> >> the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). >> >> "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach >> handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. >> >> with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). >> >> in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. >> >> In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". >> >> In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". >> >> since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). >> >> thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. >> >> thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. >> >> therefore an "attacher" has two choices when attempting to attach: >> >> - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) >> - this works with both peers and descendants >> >> - use /tmp >> - this only works if the "attacher" and "attachee" share a /tmp in common >> >> the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. >> >> I... > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8342449: minor changes in response to previous review comments @larry-cable Your change (at version 7f43e37653991d7537befb667daa3eea8d504ae4) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21688#issuecomment-2486472247 From duke at openjdk.org Tue Nov 19 18:48:54 2024 From: duke at openjdk.org (Larry Cable) Date: Tue, 19 Nov 2024 18:48:54 GMT Subject: Integrated: 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid In-Reply-To: References: Message-ID: On Thu, 24 Oct 2024 16:07:50 GMT, Larry Cable wrote: > the implementation I originally provided does not in fact solve the issue! > > the attach protocol initiation "handshake" requires that the "attacher" (the caller of this code) and the "attachee"(the target JVM to be "attached" to) *must* share a "/tmp" (or access to the attachee's `cwd`) in common in order to rendezvous on the "attach" socket (created in the /tmp or attachee `cwd` filesystem). > > "attacher" and "attachee" JVM processes are guaranteed to share a common directory/filesystem when thy occupy the same "mount namespace", this is the environment in which "peers" exist, and the attach > handshake (initiated by the attacher) can use "/tmp" to establish the socket connection with the attachee. > > with the advent of "containers" (implemented in Linux via various namespaces, e.g.: pid & mount) another "attacher" and "attachee" relationship exists, that of "attacher" (namespace ancestor) and "attachee" (namespace descendant). > > in this environment it is possible (and highly probable) that the "attacher" and the "attachee" do not share a directory in common. > > In this scenario the "attacher" must resort to handshaking with the attachee via the /proc filesystem in order to access the "attachee's" directory from the "attacher". > > In order to achieve this rendezvous, the "attachee" must occupy a descendant, or same, (pid) namespace of, or as, the "attacher". > > since (pid) namespaces are hierarchical, a descendant process (in its own descendent pid namespace) will also occupy all its ancestor (pid) namespaces (between it and the 'root' or 'host' pid namespace) with a unique pid in each of those "interstitial" (pid) namespace(s). > > thus the "attachee" directory is accessible, via an "ancestor's" (or peer's) /proc filesystem using the pid of the "attachee" that is associated with it in that (pid) namespace. > > thus an "ancestor" "attacher" can handshake with a descendant "attachee" in this fashion. > > therefore an "attacher" has two choices when attempting to attach: > > - use the /proc//root/tmp path to the "attachee's" /tmp (or its cwd) > - this works with both peers and descendants > > - use /tmp > - this only works if the "attacher" and "attachee" share a /tmp in common > > the obvious choice is to default to /proc//root/tmp (or cwd) however there is an issue with this; should the attachee have elevated privileges, the attacher may not have r/w permission on the attachee's /proc//root (or cwd) path. > > In these circumstances, the "attacher" can only resort to /tmp wh... This pull request has now been integrated. Changeset: 93e889b4 Author: Larry Cable Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/93e889b48cb6eb6872201a28ee19d8fd17c5d821 Stats: 169 lines in 1 file changed: 70 ins; 65 del; 34 mod 8342449: reimplement: JDK-8327114 Attach in Linux may have wrong behavior when pid == ns_pid Reviewed-by: kevinw ------------- PR: https://git.openjdk.org/jdk/pull/21688 From cjplummer at openjdk.org Tue Nov 19 19:00:25 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 19 Nov 2024 19:00:25 GMT Subject: RFR: 8253440: serviceability/sa/TestJhsdbJstackLineNumbers.java failed with "Didn't find enough line numbers" In-Reply-To: References: Message-ID: <0nGXlpv925OtMoAWh0431c5RzONDh_UuS1aiATCpTeQ=.0ab77546-63ec-43e7-a026-50c0626fa9b7@github.com> On Thu, 14 Nov 2024 19:20:55 GMT, Chris Plummer wrote: > The test is checking to make sure SA will use what is in the bcp register to determine the current line number rather than just use frame->bcp, which often is not up to date. It spawns a debuggee that sits in a loop that is 10 lines of source. The test executes jstack on the debuggee and determines the current line number from the output. It does this 25 times and expectesto see at least 5 of the 10 line numbers being hit. There's no guarantee it will hit at least five. The chances of this not happening are very very low, but apparently the test has failed a couple of times because only 4 unique lines were hit. I decided to do the simple fix and just lower the threshhold to 4 lines. > > Ran locally on linux-x64. Tier1 in progress. Thanks for the reviews Kevin and Leonid! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22117#issuecomment-2486504481 From cjplummer at openjdk.org Tue Nov 19 19:00:25 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 19 Nov 2024 19:00:25 GMT Subject: Integrated: 8253440: serviceability/sa/TestJhsdbJstackLineNumbers.java failed with "Didn't find enough line numbers" In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 19:20:55 GMT, Chris Plummer wrote: > The test is checking to make sure SA will use what is in the bcp register to determine the current line number rather than just use frame->bcp, which often is not up to date. It spawns a debuggee that sits in a loop that is 10 lines of source. The test executes jstack on the debuggee and determines the current line number from the output. It does this 25 times and expectesto see at least 5 of the 10 line numbers being hit. There's no guarantee it will hit at least five. The chances of this not happening are very very low, but apparently the test has failed a couple of times because only 4 unique lines were hit. I decided to do the simple fix and just lower the threshhold to 4 lines. > > Ran locally on linux-x64. Tier1 in progress. This pull request has now been integrated. Changeset: 0b1f5710 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/0b1f57105d5af72b2cd47fa5c9a2b4e2961318cd Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod 8253440: serviceability/sa/TestJhsdbJstackLineNumbers.java failed with "Didn't find enough line numbers" Reviewed-by: kevinw, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/22117 From kevinw at openjdk.org Tue Nov 19 19:01:13 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 19 Nov 2024 19:01:13 GMT Subject: RFR: 8344562: Remove security manager dependency from module jdk.jdi In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 18:29:33 GMT, Brian Burkhalter wrote: > Trivial removal of the use of the `SecurityManager` from a single class. Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22251#pullrequestreview-2446342689 From wkemper at openjdk.org Tue Nov 19 19:57:07 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 19:57:07 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 15 Nov 2024 17:01:29 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 276: > >> 274: log_info(gc)("GC cancellation took %.3fs", cancel_time); >> 275: _cancel_requested_time = 0; >> 276: } > > Do we need this? Is this useful? We could log this at debug? I believe it is useful because this time (currently) is not accounted for in the heuristic's notion of 'cycle time'. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848979381 From shade at openjdk.org Tue Nov 19 20:18:20 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 19 Nov 2024 20:18:20 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 Dropping the rest of my comments from today's read before I sign off. I have reviewed 200/230 files, will continue tomorrow. src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp line 76: > 74: void vmop_entry_final_roots(); > 75: > 76: private: Feel free to just make all these `protected`. It is more fuzz to try to provide the minimal possible visibility, especially if it gives the ragged visibility blocks in source. The real reason these are `private` is to protect them from accidental external use. `protected` is also good for this. src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.hpp line 34: > 32: class ShenandoahHeapRegion; > 33: > 34: class ShenandoahFinalMarkUpdateRegionStateClosure : public ShenandoahHeapRegionClosure { There is the `shenandoahHeapRegionClosures.hpp` for these, no? src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 44: > 42: for (size_t idx = 0; idx < num_regions; idx++) { > 43: ShenandoahHeapRegion* r = heap->get_region(idx); > 44: if (r->is_affiliated() && heap->is_bitmap_slice_committed(r) && !is_bitmap_clear_range(r->bottom(), r->end())) { I don't understand this for single gen mode. In that mode `is_affiliated() == false` always, right? So this check never passes, and `is_bitmap_clear` always returns `true`? src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 657: > 655: _generation(nullptr) { > 656: if (_options._verify_marked == ShenandoahVerifier::_verify_marked_complete_satb_empty) { > 657: Threads::change_thread_claim_token(); It is fairly odd to see Verifier touching the claim token, since the bug _may be_ somewhere in parallel thread oop iteration infra. I think it is fine to just use `Threads::threads_do` (non-parallel version), which AFAIU does not require token modifications. ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2445988182 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848675048 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848786419 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848781508 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1848711178 From coleenp at openjdk.org Tue Nov 19 22:17:56 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 19 Nov 2024 22:17:56 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: On Mon, 4 Nov 2024 09:02:10 GMT, David Holmes wrote: >> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. >> >> There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. >> >> Testing: >> - tier 1-3 (sanity) >> >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Restore previous behaviour for zero length strings Okay, I understand the change now. Looks good. src/hotspot/share/interpreter/linkResolver.cpp line 328: > 326: > 327: // Names are all known to be < 64k so we know this formatted message is not excessively large. > 328: Can you move this comment to before the first fthrow call at 331? The other fthrow has a msg so doesn't really apply and the comment looks better as just one line like the other places. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21867#pullrequestreview-2446760257 PR Review Comment: https://git.openjdk.org/jdk/pull/21867#discussion_r1849122316 From lmesnik at openjdk.org Tue Nov 19 22:57:09 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 19 Nov 2024 22:57:09 GMT Subject: RFR: 8344562: Remove security manager dependency from module jdk.jdi In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 18:29:33 GMT, Brian Burkhalter wrote: > Trivial removal of the use of the `SecurityManager` from a single class. Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22251#pullrequestreview-2446814097 From wkemper at openjdk.org Tue Nov 19 23:02:22 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:02:22 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 18 Nov 2024 16:22:31 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp line 193: > >> 191: Phase phase = Phase(pi); >> 192: if (is_worker_phase(phase)) { >> 193: double sum = uninitialized(); > > I think you can avoid changing this method to limit the churn. Hmm, I find the version in the PR much more readable. How about we upstream these changes separately? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849160336 From wkemper at openjdk.org Tue Nov 19 23:10:34 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:10:34 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 17:31:15 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 44: > >> 42: for (size_t idx = 0; idx < num_regions; idx++) { >> 43: ShenandoahHeapRegion* r = heap->get_region(idx); >> 44: if (r->is_affiliated() && heap->is_bitmap_slice_committed(r) && !is_bitmap_clear_range(r->bottom(), r->end())) { > > I don't understand this for single gen mode. In that mode `is_affiliated() == false` always, right? So this check never passes, and `is_bitmap_clear` always returns `true`? No, in single gen mode regions that are not `FREE` are affiliated with `YOUNG`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849165775 From wkemper at openjdk.org Tue Nov 19 23:20:39 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:20:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 17:35:14 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.hpp line 34: > >> 32: class ShenandoahHeapRegion; >> 33: >> 34: class ShenandoahFinalMarkUpdateRegionStateClosure : public ShenandoahHeapRegionClosure { > > There is the `shenandoahHeapRegionClosures.hpp` for these, no? It wasn't the intention that `shenandoahHeapRegionClosures.hpp` should become home to all of the `*HeapRegionClosures`. `ShenandoahFinalMarkUpdateRegionStateClosure` is shared in a couple of implementation files, but not the same as the ones using `shenandoahHeapRegionClosures.hpp`. I think `ShenandoahUpdateCensusZeroCohortClosure` should be moved into the only implementation file that uses it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849213506 From wkemper at openjdk.org Tue Nov 19 23:50:38 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:50:38 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <9VBIb_uybg8Or00efuFMAfa2JbZ3RVzE6avnR5u3mBs=.bcd6bf33-b37c-4c9f-aa4b-5d540c258fdd@github.com> On Mon, 18 Nov 2024 16:20:09 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahCollectionSetPreselector.hpp line 34: > >> 32: ShenandoahCollectionSet* _cset; >> 33: bool* _pset; >> 34: ResourceMark _rm; > > Not necessarily for this PR, but something to rectify going forward. It is generally not safe to hide `ResourceMark`-s like this in the objects. Sometimes the callers return stuff allocated in resource area, and if the object like this leaves the scope, it would corrupt the memory. Normally, when we develop resource-area-returning paths, we look around near `ResourceMark`-s to see is any thing fishy is going on. It does not help when `RM` is hidden in the object like this. Understood. This change was requested earlier in the PR. > src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp line 76: > >> 74: void vmop_entry_final_roots(); >> 75: >> 76: private: > > Feel free to just make all these `protected`. It is more fuzz to try to provide the minimal possible visibility, especially if it gives the ragged visibility blocks in source. The real reason these are `private` is to protect them from accidental external use. `protected` is also good for this. https://bugs.openjdk.org/browse/JDK-8344592 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 49: > >> 47: const char* cns = PerfDataManager::name_space("shenandoah", "regions"); >> 48: _name_space = NEW_C_HEAP_ARRAY(char, strlen(cns)+1, mtGC); >> 49: strcpy(_name_space, cns); // copy cns into _name_space > > Suggestion: > > strcpy(_name_space, cns); > > > (The comment is self-obvious) https://bugs.openjdk.org/browse/JDK-8344592 > src/hotspot/share/gc/shenandoah/shenandoahHeapRegionCounters.cpp line 57: > >> 55: PerfDataManager::create_constant(SUN_GC, cname, PerfData::U_None, num_regions, CHECK); >> 56: >> 57: cname = PerfDataManager::counter_name(_name_space, "protocol_version"); //creating new protocol_version > > Suggestion: > > cname = PerfDataManager::counter_name(_name_space, "protocol_version"); https://bugs.openjdk.org/browse/JDK-8344592 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849309543 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849308822 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849309104 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849309202 From wkemper at openjdk.org Tue Nov 19 23:59:36 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 19 Nov 2024 23:59:36 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 18 Nov 2024 16:42:50 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 455: > >> 453: // Note: would be sufficient to mark only the card that holds the start of this Reference object. >> 454: heap->old_generation()->card_scan()->mark_range_as_dirty(cast_from_oop(reference), reference->size()); >> 455: } > > Two things: > a) This sounds like `card_table_barrier(reference, raw_referent)`? Since this code is getting called for every dropped reference, just checking a `ShenandoahCardBarrier` flag sounds more efficient. > b) Is there a point in dirtying up to `reference->size()`? Will test this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849315332 From dholmes at openjdk.org Wed Nov 20 00:03:14 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 00:03:14 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: On Wed, 6 Nov 2024 05:16:47 GMT, David Holmes wrote: >> src/hotspot/share/utilities/exceptions.cpp line 264: >> >>> 262: // will be within reasonable limits - specifically we will never hit the INT_MAX limit >>> 263: // of os::vsnprintf when it tries to report how big a buffer is needed. Even so we >>> 264: // further limit the formatted output to 1024 characters. >> >> If we're chopping off the message at 1024 characters, why do we have to audit the callers? Is it because vsnprintf will overflow before truncating the message? Seems like it could be easy to add a caller that breaks this. There's no way to check here? > > Thanks for looking at this @coleenp . > > Yes it is because vsnprintf will try to tell you how big a buffer you would actually need when you pass a smaller size buffer. > > There is no way to know how big the formatted message would be without actually expanding it - which of course is only done by vsnprintf. > > So this comes down to doing a basic audit like this and then remembering to pay attention with new code. > > The alternative would be to define some global max string size, like the 1024 used here, and then have every caller of `fthrow` use `%*s` passing that max. But that is extremely intrusive if you look at how we end up calling `fthrow`. We have code in the classfile parser/error code where one function creates the message with the `%s` and a lower function actually supplies the argument. It is doable, but it is a lot of code churn to put up a safety rail that this code can't run into anyway. I've updated the description to clarify the problem. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21867#discussion_r1849317566 From ysr at openjdk.org Wed Nov 20 00:04:40 2024 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 20 Nov 2024 00:04:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: <0FH7N5Xa3DLDGZcWdxwWQHivNSTxGj9w3p-hWFSgMIs=.654c7bd9-90bb-436d-aedd-08d9fa77efc8@github.com> On Wed, 13 Nov 2024 10:51:48 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 503 commits: >> >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8342861: GenShen: Old generation in unexpected state when abandoning mixed gc candidates >> >> Reviewed-by: kdnilsen >> - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational >> >> Reviewed-by: ysr >> - 8342919: GenShen: Fix whitespace >> >> Reviewed-by: xpeng, kdnilsen >> - 8342927: GenShen: Guarantee slices of time for coalesce and filling >> >> Reviewed-by: kdnilsen >> - 8342924: GenShen: Problem list gc/shenandoah/TestReferenceRefersToShenandoah.java >> >> Reviewed-by: kdnilsen, ysr >> - 8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode >> >> Reviewed-by: wkemper >> - ... and 493 more: https://git.openjdk.org/jdk/compare/1c448347...19b25bc3 > > src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 474: > >> 472: // elision safe. >> 473: return; >> 474: } > > Why is this safe for Shenandoah? I suspect it needs `CardTableBarrierSet::on_slowpath_allocation_exit` to work. `G1BarrierSetC2` gets it by subclassing `CardTableBarrierSetC2`. But `ShenandoahBarrierSetC2` does not. Should it? Good question. I'm tracking at https://bugs.openjdk.org/browse/JDK-8344593 , and will follow up there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849318244 From dholmes at openjdk.org Wed Nov 20 00:09:15 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 00:09:15 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v2] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 22:14:45 GMT, Coleen Phillimore wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Restore previous behaviour for zero length strings > > Okay, I understand the change now. Looks good. Thanks for the review @coleenp . I will re-merge and re-test then seek second review. > src/hotspot/share/interpreter/linkResolver.cpp line 328: > >> 326: >> 327: // Names are all known to be < 64k so we know this formatted message is not excessively large. >> 328: > > Can you move this comment to before the first fthrow call at 331? The other fthrow has a msg so doesn't really apply and the comment looks better as just one line like the other places. The comment still applies to the msg created by: char* msg = Reflection::verify_class_access_msg(ref_klass, InstanceKlass::cast(base_klass), vca_result); which is also known to be limited by class name symbol lengths. That is why I placed the comment prior to both fthrow calls. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21867#issuecomment-2487016585 PR Review Comment: https://git.openjdk.org/jdk/pull/21867#discussion_r1849319949 From wkemper at openjdk.org Wed Nov 20 00:16:36 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 20 Nov 2024 00:16:36 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 12:38:59 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 420: > >> 418: } >> 419: int gc_state = _heap->gc_state(); >> 420: if ((gc_state & ShenandoahHeap::YOUNG_MARKING) != 0) { > > It is not very clear this works fine with single-gen mode. Does `MARKING` imply `YOUNG_MARKING` in single-gen mode? I think we better make it abundantly clear with `is_generational()` checks. Yes, in single gen mode we set `MARKING` and `YOUNG_MARKING` together. See https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp#L81 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849325345 From wkemper at openjdk.org Wed Nov 20 00:22:40 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 20 Nov 2024 00:22:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 16:46:36 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 657: > >> 655: _generation(nullptr) { >> 656: if (_options._verify_marked == ShenandoahVerifier::_verify_marked_complete_satb_empty) { >> 657: Threads::change_thread_claim_token(); > > It is fairly odd to see Verifier touching the claim token, since the bug _may be_ somewhere in parallel thread oop iteration infra. I think it is fine to just use `Threads::threads_do` (non-parallel version), which AFAIU does not require token modifications. Will test this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1849329578 From dholmes at openjdk.org Wed Nov 20 00:33:31 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 00:33:31 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v3] In-Reply-To: References: Message-ID: > This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. > > There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. > > Just to clarify the issue. The size 1024 is an internal buffer limit that `fthrow` uses - it is an implementation detail and not something the caller should think about. It is also not relevant to the underlying problem, which is the size of the buffer needed for the fully expanded format string, which `os::vsnprintf` will try to calculate and report. The intent is to check callers can't hit that underlying `vsnprintf` INT_MAX limit. When your format string only deals with a few symbols and symbols are always < 64K then we know we are nowhere near that INT_MAX limit. If your format string can take a potentially arbitrary (usually from outside) string then it needs to put its own size guard in place using `%*s`. > > Testing: > - tier 1-3 (sanity) > > Thanks David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into 8339134-fthrow - Restore previous behaviour for zero length strings - 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21867/files - new: https://git.openjdk.org/jdk/pull/21867/files/f0e285da..acff14ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21867&range=01-02 Stats: 316694 lines in 4333 files changed: 167153 ins; 118341 del; 31200 mod Patch: https://git.openjdk.org/jdk/pull/21867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21867/head:pull/21867 PR: https://git.openjdk.org/jdk/pull/21867 From dholmes at openjdk.org Wed Nov 20 03:50:16 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 20 Nov 2024 03:50:16 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 15:30:05 GMT, Coleen Phillimore wrote: >> This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. >> >> The fix for always verifying redefined classes was actually pushed with JDK-8341094, where the verifier code respected the parameter "should_verify_class". By default this parameter follows the -Xverify setting. For redefinition, this is passed as true. The rest of the fix removes the special bootstrap loader cases that may have failed early on in the JDK development with -Xverify:all but now no longer do. If someone tries to redefine these classes, they should also do the verification on the redefined bytecodes. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. Thanks for explaining how the main fix was done elsewhere. A couple of comments below but changes seem okay. Thanks src/hotspot/share/oops/method.cpp line 339: > 337: int Method::validate_bci(int bci) const { > 338: // Called from the verifier, and should return -1 if not valid. > 339: return ((is_native() && bci == 0) || (!is_native() && 0 <= bci && bci < code_size())) ? bci : -1; This expansion seems more correct, but it also seems unrelated to the main changes. test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 96: > 94: throw new RuntimeException("This should throw VerifyError"); > 95: } catch (VerifyError e) { > 96: // JVMTI recreates the VerifyError so the verification message is lost. I'm not clear why JVMTI would mess with the `VerifyError` that the verifier should have raised, and which explains the reason why verification failed. Not that your changes impact that. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22116#pullrequestreview-2447281814 PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1849463768 PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1849460625 From cjplummer at openjdk.org Wed Nov 20 04:46:15 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 04:46:15 GMT Subject: RFR: 8344562: Remove security manager dependency from module jdk.jdi In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 18:29:33 GMT, Brian Burkhalter wrote: > Trivial removal of the use of the `SecurityManager` from a single class. Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22251#pullrequestreview-2447381122 From cjplummer at openjdk.org Wed Nov 20 05:03:18 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 05:03:18 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v2] In-Reply-To: References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: On Tue, 19 Nov 2024 14:24:15 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java >> There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... >> >> src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java >> Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - space > - Missed getBoolean Changes requested by cjplummer (Reviewer). src/jdk.management/share/classes/com/sun/management/internal/HotSpotDiagnostic.java line 189: > 187: if (cause instanceof RuntimeException e) > 188: throw e; > 189: throw new RuntimeException(cause); I think you've made an assumption that these are all related to lack of prividleges. I don't think that is the case, and they are all exceptions that can result from calling dumpThreads(). I think you need a try block around the dumpThreads() call that handles all these exceptions in the same manner. ------------- PR Review: https://git.openjdk.org/jdk/pull/22155#pullrequestreview-2447385562 PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1849535744 From cjplummer at openjdk.org Wed Nov 20 05:06:18 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 05:06:18 GMT Subject: RFR: 8343529: serviceability/sa/ClhsdbWhere.java fails AssertionFailure: Corrupted constant pool In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:15:29 GMT, Chris Plummer wrote: > These two tests both do stack dumps with one or more active threads. This can result in SA throwing an exception if the thread is in a bad state. However, SA will still generate stack traces for all other threads, and the tests should still pass all the output checks, so we can safely ignore these exceptions and not fail the test as a result of them. > > Tested by running all SA tests 50 times on all supported platforms. Tier1 testing in progress. Looking for 1 more review. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22123#issuecomment-2487458903 From cjplummer at openjdk.org Wed Nov 20 05:13:19 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 05:13:19 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 00:40:09 GMT, Leonid Mesnik wrote: > The jcmd VM.events max parameter type is changed to INT. > Also,I noted the max <= 0 is ignored, so I updated documentation and set "0" as a default value. > The jcmd exists if parameter is negative now. > > The `max` is `int` while really it is the unsigned int. However I don't think it makes sense to change it to `size_t` or `unsigned int` in all places where 'max' is used. Looks good, but I agree that the docs should be updated with this PR - src/jdk.jcmd/share/man/jcmd.md ------------- PR Review: https://git.openjdk.org/jdk/pull/22224#pullrequestreview-2447416788 From cjplummer at openjdk.org Wed Nov 20 05:22:19 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 05:22:19 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v2] In-Reply-To: References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: <6lSK4gg7iYXgLFOq0cNUUy0cNh7KWAqdNUyppdMQZrA=.46163af1-3b92-4844-86e3-298633fe7c06@github.com> On Tue, 19 Nov 2024 14:24:15 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java >> There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... >> >> src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java >> Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - space > - Missed getBoolean src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java line 39: > 37: import java.net.UnknownHostException; > 38: import java.nio.BufferUnderflowException; > 39: import java.security.PrivilegedAction; It doesn't look like java.security.PrivilegedAction is needed. src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java line 152: > 150: > 151: public String execute(String[] args) { > 152: if (permission != null) { There is a lot of code that remains related to assigning a value to `permission`. It looks like it should also be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1849523979 PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1849529065 From cjplummer at openjdk.org Wed Nov 20 05:44:18 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 05:44:18 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Tue, 19 Nov 2024 18:30:37 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed spaces > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. Can you explain what the issue was? For the most part what I can tell is you moved a lot of code from MutexLocker to Mutex, but the reason isn't clear. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22171#issuecomment-2487500151 From cjplummer at openjdk.org Wed Nov 20 05:50:18 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 05:50:18 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Tue, 19 Nov 2024 18:30:37 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed spaces src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 58: > 56: > 57: f = type.getField("_owner"); > 58: ownerFieldOffset = f.getOffset(); Rather than repurpose `f` I could suggest declaring nameField and ownerField. Makes the code a bit easier to read. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 61: > 59: mutex_array = type.getAddressField("_mutex_array"); > 60: maxNum = type.getCIntegerField("_num_mutex").getJInt(); > 61: empty line not needed. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Mutex.java line 76: > 74: public static int maxNum() { return maxNum; } > 75: > 76: empty lines not needed src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMLocksPrinter.java line 54: > 52: if (thread.getAddress().equals(addr)) { > 53: return thread.getThreadName(); > 54: } Instead of searching for the thread address in the list of threads, can't you just create a JavaThread using Threads.createJavaThreadWrapper(addr) and directly fetch the thread name from it? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMLocksPrinter.java line 58: > 56: return "Unknown thread"; > 57: } > 58: public void printVMLocks() { Add newline before this line. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/PStack.java line 85: > 83: > 84: VMLocksPrinter vmLocksPrinter = new VMLocksPrinter(out); > 85: vmLocksPrinter.printVMLocks(); It would be best to catch all exceptions here and continue on after a warning message. We do the same in the loop below as we iterate over each thread. This is a safety net in case some structures are currently in an inconsistent state. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 32: > 30: /** > 31: * @test > 32: * @summary Test verifies that jstack --mixed print information about VM locks Suggestion: * @summary Test verifies that jstack --mixed prints information about VM locks test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 50: > 48: try { > 49: theApp = new LingeredAppWithLockInVM(); > 50: String classPath = System.getProperty("test.class.path"); Unused test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 51: > 49: theApp = new LingeredAppWithLockInVM(); > 50: String classPath = System.getProperty("test.class.path"); > 51: LingeredApp.startAppExactJvmOpts(theApp, Why use startAppExactJvmOpts and limit testing to just this one config (with vm.flagless)? Can't these be added arguments? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849552939 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849553124 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849553513 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849559366 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849559568 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849549464 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849565537 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849571429 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1849570238 From aturbanov at openjdk.org Wed Nov 20 07:01:17 2024 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 20 Nov 2024 07:01:17 GMT Subject: RFR: 8344562: Remove security manager dependency from module jdk.jdi In-Reply-To: References: Message-ID: <0V1E0NQZx_49NYr-5Tt3Elel5DZJUpSrS-ZCPNY4Yyw=.dd110754-ef6c-4719-978e-dd12e5dc7bcc@github.com> On Tue, 19 Nov 2024 18:29:33 GMT, Brian Burkhalter wrote: > Trivial removal of the use of the `SecurityManager` from a single class. src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 65: > 63: SecurityManager sm = System.getSecurityManager(); > 64: if (sm != null) { > 65: JDIPermission vmmPermission = `JDIPermission` is now unused ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22251#discussion_r1849655914 From kevinw at openjdk.org Wed Nov 20 10:32:27 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 10:32:27 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v2] In-Reply-To: <6lSK4gg7iYXgLFOq0cNUUy0cNh7KWAqdNUyppdMQZrA=.46163af1-3b92-4844-86e3-298633fe7c06@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> <6lSK4gg7iYXgLFOq0cNUUy0cNh7KWAqdNUyppdMQZrA=.46163af1-3b92-4844-86e3-298633fe7c06@github.com> Message-ID: On Wed, 20 Nov 2024 04:51:44 GMT, Chris Plummer wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - space >> - Missed getBoolean > > src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java line 152: > >> 150: >> 151: public String execute(String[] args) { >> 152: if (permission != null) { > > There is a lot of code that remains related to assigning a value to `permission`. It looks like it should also be removed. Right, Permission in the class Wrapper, commandDescriptor manipulates a map with permission info, there's native code that passes this between the JVM and library code.... Would like to do that separately in: JDK-8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1850042500 From kevinw at openjdk.org Wed Nov 20 12:17:21 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 12:17:21 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v2] In-Reply-To: References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: On Wed, 20 Nov 2024 05:00:13 GMT, Chris Plummer wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - space >> - Missed getBoolean > > src/jdk.management/share/classes/com/sun/management/internal/HotSpotDiagnostic.java line 189: > >> 187: if (cause instanceof RuntimeException e) >> 188: throw e; >> 189: throw new RuntimeException(cause); > > I think you've made an assumption that these are all related to lack of prividleges. I don't think that is the case, and they are all exceptions that can result from calling dumpThreads(). I think you need a try block around the dumpThreads() call that handles all these exceptions in the same manner. OK yes it looks that way but I think we're OK: Previously, IOException and RuntimeException were rethrown, and that is I think everything we expected to see wrapped in an PrivilegedActionException. Anything else was wrapped in a RuntimeException, but outside of IOException which was declared to be thrown, surely it's going to be an unchecked RuntimeException... Here in dumpThreads we declare IOException and Runtime is unchecked. So those two get thrown as before, not sure if we need to catch anything else. Experimenting: invoking dumpHeap through the HotSpotDiagnostic MBean, I can see: javax.management.RuntimeMBeanException: java.lang.IllegalArgumentException: heapdump file must have .hprof extension or javax.management.MBeanException: java.io.IOException: Permission denied It looks like IO or IAException (which is a RuntimeException) get handled OK, and the MBean invocation, which called dumpHeap, wraps them in other exceptions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1850214900 From kevinw at openjdk.org Wed Nov 20 12:22:56 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 12:22:56 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v2] In-Reply-To: <6lSK4gg7iYXgLFOq0cNUUy0cNh7KWAqdNUyppdMQZrA=.46163af1-3b92-4844-86e3-298633fe7c06@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> <6lSK4gg7iYXgLFOq0cNUUy0cNh7KWAqdNUyppdMQZrA=.46163af1-3b92-4844-86e3-298633fe7c06@github.com> Message-ID: On Wed, 20 Nov 2024 04:46:32 GMT, Chris Plummer wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - space >> - Missed getBoolean > > src/jdk.management.agent/share/classes/jdk/internal/agent/Agent.java line 39: > >> 37: import java.net.UnknownHostException; >> 38: import java.nio.BufferUnderflowException; >> 39: import java.security.PrivilegedAction; > > It doesn't look like java.security.PrivilegedAction is needed. thanks, and found one more in PlatformMBeanProviderImpl.java, will add it to the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1850219824 From kevinw at openjdk.org Wed Nov 20 12:22:55 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 12:22:55 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v3] In-Reply-To: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: <9k99zxpp-SH2SDFAOI4QmZbrMiK5o4s4ffL-MrvuJnI=.591b3e47-d8be-466b-8940-8df928753b6a@github.com> > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java > There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... > > src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java > Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: missed PrivAction removal ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22155/files - new: https://git.openjdk.org/jdk/pull/22155/files/39ae0074..be4dfc4f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22155&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22155&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22155/head:pull/22155 PR: https://git.openjdk.org/jdk/pull/22155 From coleenp at openjdk.org Wed Nov 20 12:26:18 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 20 Nov 2024 12:26:18 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 03:46:46 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. > > src/hotspot/share/oops/method.cpp line 339: > >> 337: int Method::validate_bci(int bci) const { >> 338: // Called from the verifier, and should return -1 if not valid. >> 339: return ((is_native() && bci == 0) || (!is_native() && 0 <= bci && bci < code_size())) ? bci : -1; > > This expansion seems more correct, but it also seems unrelated to the main changes. This expansion was the fix to a bug that I hit while testing the main change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1850227299 From kevinw at openjdk.org Wed Nov 20 12:39:59 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 12:39:59 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v5] In-Reply-To: References: Message-ID: <4CNj4BVL9miynC0_YSpjvN236z12DqYcmRjGpeDH9II=.945d8d72-db3e-4388-95c4-248b06e1f8a0@github.com> > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: mostly removing imports ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22100/files - new: https://git.openjdk.org/jdk/pull/22100/files/3a524945..9c512b22 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=03-04 Stats: 29 lines in 7 files changed: 0 ins; 29 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100 PR: https://git.openjdk.org/jdk/pull/22100 From coleenp at openjdk.org Wed Nov 20 12:55:26 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 20 Nov 2024 12:55:26 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 03:42:57 GMT, David Holmes wrote: >> Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: >> >> Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. > > test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 96: > >> 94: throw new RuntimeException("This should throw VerifyError"); >> 95: } catch (VerifyError e) { >> 96: // JVMTI recreates the VerifyError so the verification message is lost. > > I'm not clear why JVMTI would mess with the `VerifyError` that the verifier should have raised, and which explains the reason why verification failed. Not that your changes impact that. The JVMTI code for redefinition returns JVMTI_ERROR_FAILS_VERIFICATION and not the pending exception to the caller. The agent eventually in java.instrument/share/native/libinstrument/JavaExceptions.c will recreate the VerifyError based on the JVMTI error code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1850265592 From coleenp at openjdk.org Wed Nov 20 12:58:30 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 20 Nov 2024 12:58:30 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 12:23:09 GMT, Coleen Phillimore wrote: >> src/hotspot/share/oops/method.cpp line 339: >> >>> 337: int Method::validate_bci(int bci) const { >>> 338: // Called from the verifier, and should return -1 if not valid. >>> 339: return ((is_native() && bci == 0) || (!is_native() && 0 <= bci && bci < code_size())) ? bci : -1; >> >> This expansion seems more correct, but it also seems unrelated to the main changes. > > This expansion was the fix to a bug that I hit while testing the main change. I removed all the code for the VerifyError code to reduce the test case, so the failing BCI was 0 and the verifier reporting tested whether this was a valid bytecode, then asserted a couple lines further that it wasn't a valid bytecode. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1850270304 From mullan at openjdk.org Wed Nov 20 13:36:19 2024 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 20 Nov 2024 13:36:19 GMT Subject: RFR: 8344562: Remove security manager dependency from module jdk.jdi In-Reply-To: <0V1E0NQZx_49NYr-5Tt3Elel5DZJUpSrS-ZCPNY4Yyw=.dd110754-ef6c-4719-978e-dd12e5dc7bcc@github.com> References: <0V1E0NQZx_49NYr-5Tt3Elel5DZJUpSrS-ZCPNY4Yyw=.dd110754-ef6c-4719-978e-dd12e5dc7bcc@github.com> Message-ID: On Wed, 20 Nov 2024 06:58:36 GMT, Andrey Turbanov wrote: >> Trivial removal of the use of the `SecurityManager` from a single class. > > src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 65: > >> 63: SecurityManager sm = System.getSecurityManager(); >> 64: if (sm != null) { >> 65: JDIPermission vmmPermission = > > `JDIPermission` is now unused It is a standard API, so we cannot remove it unless we go through a deprecation process, and it is ok to leave it for now. We will consider deprecating it (and other `Permission` subclasses) for removal in JDK 25. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22251#discussion_r1850326305 From kevinw at openjdk.org Wed Nov 20 14:37:54 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 14:37:54 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v6] In-Reply-To: References: Message-ID: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - Remove checkPackageAccess calls - Remove Util.check... calls ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22100/files - new: https://git.openjdk.org/jdk/pull/22100/files/9c512b22..16852a03 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=04-05 Stats: 71 lines in 13 files changed: 0 ins; 61 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/22100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100 PR: https://git.openjdk.org/jdk/pull/22100 From kevinw at openjdk.org Wed Nov 20 14:41:16 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 14:41:16 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v6] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 14:37:54 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - Remove checkPackageAccess calls > - Remove Util.check... calls src/java.management/share/classes/sun/management/Util.java: The checkXXX Permission methods are called by at least jdk.management code outside this module, so leaving in place temporarily, can be removed once other changes are settled. MBeanServerFileAccessController still has its own "check" methods, for file-based permissions (not SM-based). Also removing ReflectUtil.checkPackageAccess() calls. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22100#issuecomment-2488758487 From alanb at openjdk.org Wed Nov 20 14:46:17 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 20 Nov 2024 14:46:17 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v6] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 14:37:54 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - Remove checkPackageAccess calls > - Remove Util.check... calls Maybe follow-up, but can you check the usage of ReflectUtil.forName in MBeanServerFactory.loadBuilderClass. It looks like it wants to try the boot loader when the CCL is not set, in which case this can be changed to use the 3-arg forName a loader of null. If we can make this go away then I think it may be the last usage of ReflectUtil by the java.management module. It would be nice if we could make the qualified export of sun.reflect.misc to java.management go away if we can. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22100#issuecomment-2488771956 From kevinw at openjdk.org Wed Nov 20 14:53:54 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 14:53:54 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v4] In-Reply-To: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java > There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... > > src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java > Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove a Util.checkControlAccess ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22155/files - new: https://git.openjdk.org/jdk/pull/22155/files/be4dfc4f..84d59ac3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22155&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22155&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22155/head:pull/22155 PR: https://git.openjdk.org/jdk/pull/22155 From alanb at openjdk.org Wed Nov 20 15:00:38 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 20 Nov 2024 15:00:38 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v4] In-Reply-To: References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: On Wed, 20 Nov 2024 14:53:54 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java >> There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... >> >> src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java >> Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove a Util.checkControlAccess src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 62: > 60: @Override > 61: public final void setParallelism(int size) { > 62: Util.checkControlAccess(); Dropping this means that we don't need setParallelism in the base class no need for implSetParallelism. In its place we just rename implSetParallelism to setParallelism in the subclasses. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1850469072 From kevinw at openjdk.org Wed Nov 20 15:08:17 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 15:08:17 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v6] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 14:43:31 GMT, Alan Bateman wrote: > Maybe follow-up, but can you check the usage of ReflectUtil.forName in MBeanServerFactory.loadBuilderClass. Happy to do that, yes as it may change module xports maybe it's better I look at that separately. Actually I've missed a few ReflectUtil imports here in java.management that can go, will update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22100#issuecomment-2488827678 From lucy at openjdk.org Wed Nov 20 15:53:26 2024 From: lucy at openjdk.org (Lutz Schmidt) Date: Wed, 20 Nov 2024 15:53:26 GMT Subject: RFR: 8341927: Replace hardcoded security providers with new test.provider.name system property [v7] In-Reply-To: References: <9_7TTgZryCxc9I6cuB9eHW6J6eA-NPSn56giRfqGHe8=.a620474d-4e77-4e39-ab1d-dad3e1bc741c@github.com> Message-ID: On Wed, 30 Oct 2024 18:12:30 GMT, Matthew Donovan wrote: >> In this PR, I removed hard-coded security providers and replaced them with a system property, test.provider.name. If the property is not specified, the provider originally used in the test is used: >> >> Cipher c = Cipher.getInstance("AES/GCM/NoPadding", System.getProperty("test.provider.name", "SunJCE")); > > Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision: > > included additional services in testing.md While reviewing the backport PR to jdk17, I stumbled across a potential functional incompleteness. There are a few tests which use more than one security provider. This works well when only the default providers are used. One example of such a test is `test/jdk/java/security/Signature/TestCloneable.java`. There are three providers by default: String dsaProviderName = System.getProperty("test.provider.name", "SUN"); String ecProviderName = System.getProperty("test.provider.name", "SunEC"); String rsaProviderName = System.getProperty("test.provider.name", "SunRsaSign"); If the `test.provider.name` property is specified for a test run, all three name strings are set to the same provider name. The test will only succeed if the specified provider can handle the combined set of algorithms of all three default providers. These are the tests I found to be affected. The list is **not** believed to be complete. test/jdk/java/security/Signature/TestCloneable.java test/jdk/java/security/SignedObject/Chain.java test/jdk/java/security/KexGenerator/TestGetInstance.java test/jdk/java/security/Mac/TestGetInstance.java test/jdk/java/security/auth/login/Configuration/GetInstance.java test/jdk/java/security/X509/X509CertImpl/Verify.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/21551#issuecomment-2488947679 From bpb at openjdk.org Wed Nov 20 16:04:41 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 20 Nov 2024 16:04:41 GMT Subject: Integrated: 8344562: Remove security manager dependency from module jdk.jdi In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 18:29:33 GMT, Brian Burkhalter wrote: > Trivial removal of the use of the `SecurityManager` from a single class. This pull request has now been integrated. Changeset: c4c6b1fe Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/c4c6b1fe0629d313e7b7bd6b7dc92f8c7d18ec8f Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod 8344562: Remove security manager dependency from module jdk.jdi Reviewed-by: kevinw, lmesnik, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/22251 From bpb at openjdk.org Wed Nov 20 16:04:40 2024 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 20 Nov 2024 16:04:40 GMT Subject: RFR: 8344562: Remove security manager dependency from module jdk.jdi In-Reply-To: References: <0V1E0NQZx_49NYr-5Tt3Elel5DZJUpSrS-ZCPNY4Yyw=.dd110754-ef6c-4719-978e-dd12e5dc7bcc@github.com> Message-ID: On Wed, 20 Nov 2024 13:33:27 GMT, Sean Mullan wrote: >> src/jdk.jdi/share/classes/com/sun/tools/jdi/VirtualMachineManagerImpl.java line 65: >> >>> 63: SecurityManager sm = System.getSecurityManager(); >>> 64: if (sm != null) { >>> 65: JDIPermission vmmPermission = >> >> `JDIPermission` is now unused > > It is a standard API, so we cannot remove it unless we go through a deprecation process, and it is ok to leave it for now. We will consider deprecating it (and other `Permission` subclasses) for removal in JDK 25. Leaving as is. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22251#discussion_r1850586043 From ihse at openjdk.org Wed Nov 20 16:24:30 2024 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 20 Nov 2024 16:24:30 GMT Subject: RFR: 8344056: Use markdown format for man pages [v4] In-Reply-To: References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com> Message-ID: On Tue, 19 Nov 2024 16:27:54 GMT, Eirik Bj?rsn?s wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: >> >> It's somewhat nicer to use \\s instead of space character in regex > > Is the warning log when pandoc is not installed a bit loud? > > > % make images > Building target 'images' in configuration 'macosx-x86_64-server-release' > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Warning: pandoc not found. Not generating man pages > Finished building target 'images' in configuration 'macosx-x86_64-server-release' @eirbjo Yes, that was not intentional. https://bugs.openjdk.org/browse/JDK-8344559. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2489029819 From kevinw at openjdk.org Wed Nov 20 17:06:41 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 17:06:41 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v7] In-Reply-To: References: Message-ID: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: ReflectUtil removals ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22100/files - new: https://git.openjdk.org/jdk/pull/22100/files/16852a03..a330df5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=05-06 Stats: 12 lines in 7 files changed: 0 ins; 10 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100 PR: https://git.openjdk.org/jdk/pull/22100 From alanb at openjdk.org Wed Nov 20 17:25:18 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 20 Nov 2024 17:25:18 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v7] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 17:06:41 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > ReflectUtil removals Does the latest update mean that java.base's module-info can be updated to not export sun.reflect.misc to java.management? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22100#issuecomment-2489164582 From kevinw at openjdk.org Wed Nov 20 18:09:17 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 20 Nov 2024 18:09:17 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v7] In-Reply-To: References: Message-ID: <851fKix7zSHaTuBsBOMTEyJ46kFztvorsz7W3iulmY8=.f6b75117-80eb-4531-b022-61c3fd2f335c@github.com> On Wed, 20 Nov 2024 17:22:25 GMT, Alan Bateman wrote: > Does the latest update mean that java.base's module-info can be updated to not export sun.reflect.misc to java.management? Not quite, there is use of sun.reflect.misc.MethodUtil and sun.reflect.misc.ConstructorUtil by java.management. A few places call MethodUtil.invoke(). java.management.rmi will be done with its use of sun.reflect.misc after the separate change 8344394. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22100#issuecomment-2489241704 From duke at openjdk.org Wed Nov 20 18:33:43 2024 From: duke at openjdk.org (Adam Bruce) Date: Wed, 20 Nov 2024 18:33:43 GMT Subject: RFR: 6726901: JDWP: ReferenceType.GetValues crashes jvm in case non-static fields are passed Message-ID: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> This PR fixes a long-standing bug in JDWP where the access flags of a field are not checked before attempting to read it's value. Prior to this change, attempting to read a non-static field would cause a JVM crash, this change corrects that behaviour by returning `INVALID_FIELDID` instead. This is my first PR to OpenJDK, so please let me know if I've made any mistakes in the process. Cheers, Adam ------------- Commit messages: - Check for ACC_STATIC before writing static field value Changes: https://git.openjdk.org/jdk/pull/22280/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22280&range=00 Issue: https://bugs.openjdk.org/browse/JDK-6726901 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22280/head:pull/22280 PR: https://git.openjdk.org/jdk/pull/22280 From wkemper at openjdk.org Wed Nov 20 19:59:42 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 20 Nov 2024 19:59:42 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 23:56:56 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 455: >> >>> 453: // Note: would be sufficient to mark only the card that holds the start of this Reference object. >>> 454: heap->old_generation()->card_scan()->mark_range_as_dirty(cast_from_oop(reference), reference->size()); >>> 455: } >> >> Two things: >> a) This sounds like `card_table_barrier(reference, raw_referent)`? Since this code is getting called for every dropped reference, just checking a `ShenandoahCardBarrier` flag sounds more efficient. >> b) Is there a point in dirtying up to `reference->size()`? > > Will test this. https://bugs.openjdk.org/browse/JDK-8344640 >> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 657: >> >>> 655: _generation(nullptr) { >>> 656: if (_options._verify_marked == ShenandoahVerifier::_verify_marked_complete_satb_empty) { >>> 657: Threads::change_thread_claim_token(); >> >> It is fairly odd to see Verifier touching the claim token, since the bug _may be_ somewhere in parallel thread oop iteration infra. I think it is fine to just use `Threads::threads_do` (non-parallel version), which AFAIU does not require token modifications. > > Will test this. https://bugs.openjdk.org/browse/JDK-8344638 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850900559 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850901137 From shade at openjdk.org Wed Nov 20 20:22:27 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 20 Nov 2024 20:22:27 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <_9t4lSh7P6yPIZtllm4hVRuZ7kqyhWcyCfrKh37B8fA=.fb510cc5-c9db-4c31-ba90-6189789f10b8@github.com> On Wed, 13 Nov 2024 19:32:53 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: > > - Merge branch 'merge-latest' into great-genshen-pr-redux > - Use new CompactHeader forwarding APIs in generational mode > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge > - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines > > Reviewed-by: wkemper > - Merge > - 8343227: GenShen: Fold resource mark into management of preselected regions > > Reviewed-by: kdnilsen > - Merge openjdk/jdk tip into great-genshen-pr-redux > - Merge remote-tracking branch 'jdk/master' into merge-latest > - Merge remote-tracking branch 'jdk/master' into merge-latest > - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 Almost there, 220/230 reviewed. src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 62: > 60: void work(uint worker_id) { > 61: ShenandoahHeap* heap = ShenandoahHeap::heap(); > 62: ShenandoahParallelWorkerSession worker_session(worker_id); Why this needs to be `ShenandoahParallelWorkerSession`, not `ShenandoahConcurrentWorkerSession`? This is a concurrent step, is it? ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2449189030 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850899803 From shade at openjdk.org Wed Nov 20 20:22:28 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 20 Nov 2024 20:22:28 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <86FIc0saJkWuxy228AuIYA6VKDYhwQCd5bH31sBK6Ws=.aa86fa8d-6c88-4edb-ac89-c89b68e65f29@github.com> On Tue, 19 Nov 2024 23:07:21 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 44: >> >>> 42: for (size_t idx = 0; idx < num_regions; idx++) { >>> 43: ShenandoahHeapRegion* r = heap->get_region(idx); >>> 44: if (r->is_affiliated() && heap->is_bitmap_slice_committed(r) && !is_bitmap_clear_range(r->bottom(), r->end())) { >> >> I don't understand this for single gen mode. In that mode `is_affiliated() == false` always, right? So this check never passes, and `is_bitmap_clear` always returns `true`? > > No, in single gen mode regions that are not `FREE` are affiliated with `YOUNG`. That's weird. We have `Young`, `Old` and `Global` generations. Why affiliation is not `Free`, `Young`, `Old`, and `Global` then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850665665 From wkemper at openjdk.org Wed Nov 20 20:22:29 2024 From: wkemper at openjdk.org (William Kemper) Date: Wed, 20 Nov 2024 20:22:29 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <86FIc0saJkWuxy228AuIYA6VKDYhwQCd5bH31sBK6Ws=.aa86fa8d-6c88-4edb-ac89-c89b68e65f29@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <86FIc0saJkWuxy228AuIYA6VKDYhwQCd5bH31sBK6Ws=.aa86fa8d-6c88-4edb-ac89-c89b68e65f29@github.com> Message-ID: On Wed, 20 Nov 2024 16:47:20 GMT, Aleksey Shipilev wrote: >> No, in single gen mode regions that are not `FREE` are affiliated with `YOUNG`. > > That's weird. We have `Young`, `Old` and `Global` generations. Why affiliation is not `Free`, `Young`, `Old`, and `Global` then? Yes, it's a little weird. It didn't seem necessary to have a `Global` affiliation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1850927526 From cjplummer at openjdk.org Wed Nov 20 20:33:14 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 20:33:14 GMT Subject: RFR: 6726901: JDWP: ReferenceType.GetValues crashes jvm in case non-static fields are passed In-Reply-To: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> References: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> Message-ID: On Wed, 20 Nov 2024 18:09:08 GMT, Adam Bruce wrote: > This PR fixes a long-standing bug in JDWP where the access flags of a field are not checked before attempting to read it's value. > > Prior to this change, attempting to read a non-static field would cause a JVM crash, this change corrects that behaviour by returning `INVALID_FIELDID` instead. > > This is my first PR to OpenJDK, so please let me know if I've made any mistakes in the process. > > Cheers, > Adam Hi Adam. Thank you for your contribution. I think the fix should be moved to sharedGetFieldValues(), and should verify that the isStatic flag matches the STATIC modifier of the field. Right now you are only catching ReferenceType.GetValues of a non-static field. You also need to catch ObjectReference.GetValues of a static field. The other option is to add a similar fix to writeFieldValue(). Note that the JDI ObjectReference.getValues() allows access to both static and instance fields, but JDWP ObjectReference.GetValues only allows access to instance fields, not static fields. This is all handled in the JDI implementation of ObjectReferenceImpl.getValues(), which separately uses both ReferenceType.GetValue for static fields and ObjectReference.GetValues for instance fields. I think JDI might need some fixes to the exception handling. Currently in ReferenceTypeImpl.getValues(), any JDWP exception goes through toJDIException() to convert it to a JDI exception, and it does not handle INVALID_FRAMEID. You'll need to special case it to throw IllegalArgumentException. Same is true in ObjectReferenceImpl.getValues(). You'll need to add tests cases as part of this PR. Please make sure all of the following tests pass: test/jdk/com/sun/jdi test/hotspot/jtreg/vmTestbase/nsk/jdi test/hotspot/jtreg/vmTestbase/nsk/jdwp test/hotspot/jtreg/vmTestbase/nsk/jdb ------------- PR Comment: https://git.openjdk.org/jdk/pull/22280#issuecomment-2489486881 From lmesnik at openjdk.org Wed Nov 20 21:50:15 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Nov 2024 21:50:15 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <8Mrds88Q8y5Vp8uHxCH226INVFHccBvFvjAsXC6m9Zo=.a157d0f3-600d-46b6-964e-0a8d77e40f18@github.com> On Wed, 20 Nov 2024 05:45:35 GMT, Chris Plummer wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed spaces > > test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 51: > >> 49: theApp = new LingeredAppWithLockInVM(); >> 50: String classPath = System.getProperty("test.class.path"); >> 51: LingeredApp.startAppExactJvmOpts(theApp, > > Why use startAppExactJvmOpts and limit testing to just this one config (with vm.flagless)? Can't these be added arguments? Updated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851023806 From lmesnik at openjdk.org Wed Nov 20 21:55:00 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Nov 2024 21:55:00 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v8] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: Updates after Chris feeback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/0fbafab4..b85daff7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=06-07 Stats: 21 lines in 3 files changed: 7 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Wed Nov 20 21:55:00 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Nov 2024 21:55:00 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <5PTfFZBfjr_4b__p4LJzXQNtj4FYbXfzpdRJpXK4BgY=.fe38b09f-78b1-46b8-8378-377a2c2d8644@github.com> On Wed, 20 Nov 2024 05:41:23 GMT, Chris Plummer wrote: > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > Can you explain what the issue was? For the most part what I can tell is you moved a lot of code from MutexLocker to Mutex, but the reason isn't clear. IIUC The VMStructs can read classes only, so I moved _mutex_array to be a static member of Mutex. All other refactoring just needed for this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22171#issuecomment-2489610303 From cjplummer at openjdk.org Wed Nov 20 22:20:05 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 22:20:05 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: <5PTfFZBfjr_4b__p4LJzXQNtj4FYbXfzpdRJpXK4BgY=.fe38b09f-78b1-46b8-8378-377a2c2d8644@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> <5PTfFZBfjr_4b__p4LJzXQNtj4FYbXfzpdRJpXK4BgY=.fe38b09f-78b1-46b8-8378-377a2c2d8644@github.com> Message-ID: On Wed, 20 Nov 2024 21:50:27 GMT, Leonid Mesnik wrote: > > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > > > > > Can you explain what the issue was? For the most part what I can tell is you moved a lot of code from MutexLocker to Mutex, but the reason isn't clear. > > IIUC The VMStructs can read classes only, so I moved _mutex_array to be a static member of Mutex. All other refactoring just needed for this change. Ok, that makes sense. I remember now you mentioning to me a couple of weeks ago that SA can't access globals via VMStructs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22171#issuecomment-2489627100 From cjplummer at openjdk.org Wed Nov 20 22:20:08 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 20 Nov 2024 22:20:08 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v4] In-Reply-To: References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: On Wed, 20 Nov 2024 14:53:54 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java >> There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... >> >> src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java >> Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove a Util.checkControlAccess Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22155#pullrequestreview-2449801031 From lmesnik at openjdk.org Wed Nov 20 22:20:07 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 20 Nov 2024 22:20:07 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: <8Mrds88Q8y5Vp8uHxCH226INVFHccBvFvjAsXC6m9Zo=.a157d0f3-600d-46b6-964e-0a8d77e40f18@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> <8Mrds88Q8y5Vp8uHxCH226INVFHccBvFvjAsXC6m9Zo=.a157d0f3-600d-46b6-964e-0a8d77e40f18@github.com> Message-ID: On Wed, 20 Nov 2024 21:47:30 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 51: >> >>> 49: theApp = new LingeredAppWithLockInVM(); >>> 50: String classPath = System.getProperty("test.class.path"); >>> 51: LingeredApp.startAppExactJvmOpts(theApp, >> >> Why use startAppExactJvmOpts and limit testing to just this one config (with vm.flagless)? Can't these be added arguments? > > Updated. I also changed lock to avoid false positive failures. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851041298 From cjplummer at openjdk.org Thu Nov 21 00:00:22 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 00:00:22 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v7] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> <8Mrds88Q8y5Vp8uHxCH226INVFHccBvFvjAsXC6m9Zo=.a157d0f3-600d-46b6-964e-0a8d77e40f18@github.com> Message-ID: On Wed, 20 Nov 2024 22:05:44 GMT, Leonid Mesnik wrote: >> Updated. > > I also changed lock to avoid false positive failures. I think you still need to push your recent changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851136997 From lmesnik at openjdk.org Thu Nov 21 00:02:32 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 00:02:32 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT [v2] In-Reply-To: References: Message-ID: > The jcmd VM.events max parameter type is changed to INT. > Also,I noted the max <= 0 is ignored, so I updated documentation and set "0" as a default value. > The jcmd exists if parameter is negative now. > > The `max` is `int` while really it is the unsigned int. However I don't think it makes sense to change it to `size_t` or `unsigned int` in all places where 'max' is used. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: doc fixed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22224/files - new: https://git.openjdk.org/jdk/pull/22224/files/3e80f1b5..39f04207 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22224&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22224&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22224/head:pull/22224 PR: https://git.openjdk.org/jdk/pull/22224 From lmesnik at openjdk.org Thu Nov 21 00:04:52 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 00:04:52 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v9] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: lock changed and flagless requires removed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/b85daff7..4ed1d57e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=07-08 Stats: 7 lines in 2 files changed: 1 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From cjplummer at openjdk.org Thu Nov 21 00:06:18 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 00:06:18 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT [v2] In-Reply-To: References: Message-ID: <_N_16wLg9-9abQfxlecVlk9mr2kWiplQkHEffAp0f_s=.268872f8-8c28-403f-b1ac-c0eed6784f90@github.com> On Thu, 21 Nov 2024 00:02:32 GMT, Leonid Mesnik wrote: >> The jcmd VM.events max parameter type is changed to INT. >> Also,I noted the max <= 0 is ignored, so I updated documentation and set "0" as a default value. >> The jcmd exists if parameter is negative now. >> >> The `max` is `int` while really it is the unsigned int. However I don't think it makes sense to change it to `size_t` or `unsigned int` in all places where 'max' is used. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > doc fixed Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22224#pullrequestreview-2449954991 From wkemper at openjdk.org Thu Nov 21 00:36:41 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 00:36:41 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <_9t4lSh7P6yPIZtllm4hVRuZ7kqyhWcyCfrKh37B8fA=.fb510cc5-c9db-4c31-ba90-6189789f10b8@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <_9t4lSh7P6yPIZtllm4hVRuZ7kqyhWcyCfrKh37B8fA=.fb510cc5-c9db-4c31-ba90-6189789f10b8@github.com> Message-ID: On Wed, 20 Nov 2024 19:55:35 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 510 commits: >> >> - Merge branch 'merge-latest' into great-genshen-pr-redux >> - Use new CompactHeader forwarding APIs in generational mode >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge >> - 8343649: Shenandoah: ShenandoahEvacInfo event does not follow JFR guidelines >> >> Reviewed-by: wkemper >> - Merge >> - 8343227: GenShen: Fold resource mark into management of preselected regions >> >> Reviewed-by: kdnilsen >> - Merge openjdk/jdk tip into great-genshen-pr-redux >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - Merge remote-tracking branch 'jdk/master' into merge-latest >> - ... and 500 more: https://git.openjdk.org/jdk/compare/889f9062...5e02b5d8 > > src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 62: > >> 60: void work(uint worker_id) { >> 61: ShenandoahHeap* heap = ShenandoahHeap::heap(); >> 62: ShenandoahParallelWorkerSession worker_session(worker_id); > > Why this needs to be `ShenandoahParallelWorkerSession`, not `ShenandoahConcurrentWorkerSession`? This is a concurrent step, is it? Yes, https://bugs.openjdk.org/browse/JDK-8344670 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851158343 From wkemper at openjdk.org Thu Nov 21 00:59:27 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 00:59:27 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - 8344670: GenShen: Use concurrent worker session for concurrent mark phase Reviewed-by: kdnilsen - 8344640: GenShen: Reuse existing card mark barrier function when dropping references Reviewed-by: shade, ysr - 8344592: GenShen: Remove unnecessary comments and changes Reviewed-by: kdnilsen - 8344263: GenShen: Reduce extraneous log messages at INFO level Reviewed-by: ysr, shade - 8344638: GenShen: Verifier should not touch claim token Reviewed-by: shade - Merge - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap Reviewed-by: wkemper, ysr - 8344321: GenShen: Fix various sonar scan warnings Reviewed-by: kdnilsen, shade - 8344264: GenShen: Improve comments and method names Reviewed-by: shade - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=07 Stats: 22960 lines in 230 files changed: 21196 ins; 892 del; 872 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From cjplummer at openjdk.org Thu Nov 21 01:27:16 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 01:27:16 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v9] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <4-xJP_OF53uk0Ll2zOCIfCoS0nzDw2choPX7sqDG2NI=.1a439b8e-e965-44e7-8bbb-16d3edbbd41c@github.com> On Thu, 21 Nov 2024 00:04:52 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > lock changed and flagless requires removed Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2450033629 From lmesnik at openjdk.org Thu Nov 21 01:35:18 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 01:35:18 GMT Subject: Integrated: 8340334: Update jcmd VM.events max parameter to be INT In-Reply-To: References: Message-ID: <7zIKaXS_NxKQSRqKudJs2Y8-otbQFz1APmEYjYzt9jA=.e71bd8fe-9bdf-42b5-b176-bdd2e2a4eefb@github.com> On Tue, 19 Nov 2024 00:40:09 GMT, Leonid Mesnik wrote: > The jcmd VM.events max parameter type is changed to INT. > Also,I noted the max <= 0 is ignored, so I updated documentation and set "0" as a default value. > The jcmd exists if parameter is negative now. > > The `max` is `int` while really it is the unsigned int. However I don't think it makes sense to change it to `size_t` or `unsigned int` in all places where 'max' is used. This pull request has now been integrated. Changeset: 13439113 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/13439113c361dcb0629ece37844443cbf99ef704 Stats: 11 lines in 3 files changed: 0 ins; 4 del; 7 mod 8340334: Update jcmd VM.events max parameter to be INT Reviewed-by: cjplummer, kevinw ------------- PR: https://git.openjdk.org/jdk/pull/22224 From amenkov at openjdk.org Thu Nov 21 02:34:24 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 21 Nov 2024 02:34:24 GMT Subject: RFR: 8343529: serviceability/sa/ClhsdbWhere.java fails AssertionFailure: Corrupted constant pool In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:15:29 GMT, Chris Plummer wrote: > These two tests both do stack dumps with one or more active threads. This can result in SA throwing an exception if the thread is in a bad state. However, SA will still generate stack traces for all other threads, and the tests should still pass all the output checks, so we can safely ignore these exceptions and not fail the test as a result of them. > > Tested by running all SA tests 50 times on all supported platforms. Tier1 testing in progress. Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22123#pullrequestreview-2450096444 From lmesnik at openjdk.org Thu Nov 21 02:35:15 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 02:35:15 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v10] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated time between attempts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/4ed1d57e..015546b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=08-09 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From cjplummer at openjdk.org Thu Nov 21 02:45:15 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 02:45:15 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v10] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Thu, 21 Nov 2024 02:35:15 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated time between attempts Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2450105729 From cjplummer at openjdk.org Thu Nov 21 03:04:15 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 03:04:15 GMT Subject: RFR: 6726901: JDWP: ReferenceType.GetValues crashes jvm in case non-static fields are passed In-Reply-To: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> References: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> Message-ID: On Wed, 20 Nov 2024 18:09:08 GMT, Adam Bruce wrote: > This PR fixes a long-standing bug in JDWP where the access flags of a field are not checked before attempting to read it's value. > > Prior to this change, attempting to read a non-static field would cause a JVM crash, this change corrects that behaviour by returning `INVALID_FIELDID` instead. > > This is my first PR to OpenJDK, so please let me know if I've made any mistakes in the process. > > Cheers, > Adam The following two tests would be good starting points for writing new test cases. You can clone them and then modify them to expect errors due to static mismatch. test/hotspot/jtreg/vmTestbase/nsk/jdwp/ObjectReference/GetValues/getvalues001.java test/hotspot/jtreg/vmTestbase/nsk/jdwp/ReferenceType/GetValues/getvalues001.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/22280#issuecomment-2489967303 From lmesnik at openjdk.org Thu Nov 21 05:08:06 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 05:08:06 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v11] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: SA test doesn't work with ZGC ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/015546b4..39b374f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=09-10 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From dholmes at openjdk.org Thu Nov 21 05:15:17 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Nov 2024 05:15:17 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 12:52:45 GMT, Coleen Phillimore wrote: >> test/hotspot/jtreg/serviceability/jvmti/RedefineClasses/RedefineVerifyError.java line 96: >> >>> 94: throw new RuntimeException("This should throw VerifyError"); >>> 95: } catch (VerifyError e) { >>> 96: // JVMTI recreates the VerifyError so the verification message is lost. >> >> I'm not clear why JVMTI would mess with the `VerifyError` that the verifier should have raised, and which explains the reason why verification failed. Not that your changes impact that. > > The JVMTI code for redefinition returns JVMTI_ERROR_FAILS_VERIFICATION and not the pending exception to the caller. The agent eventually in java.instrument/share/native/libinstrument/JavaExceptions.c will recreate the VerifyError based on the JVMTI error code. Wow that is pretty developer unfriendly. Hopefully exception logging will still show what the error is in detail. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1851367760 From dholmes at openjdk.org Thu Nov 21 05:25:23 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 21 Nov 2024 05:25:23 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT [v2] In-Reply-To: References: <-poZAS8WKk-DCPCO3UdlAvOLkFw11w_knbXBg7ZY-DU=.e2425d1d-929c-4f5c-bf2f-b312592e21d6@github.com> Message-ID: On Tue, 19 Nov 2024 10:12:15 GMT, Kevin Walls wrote: >> src/hotspot/share/services/diagnosticCommand.hpp line 892: >> >>> 890: protected: >>> 891: DCmdArgument _log; >>> 892: DCmdArgument _max; >> >> Why `jlong` and not `jint`? > > Everything which parses an integer option uses > > DCmdArgument > > (e.g. heap dump parallelism, etc...) > > > DCmdArgument::parse_value(..) > > does the parsing, we have never had a definition for > > DCmdArgument Okay but just to be clear, this change means that the maximum value of this parameter is no longer limited to a 32-bit integer maximum, but is now a 64-bit maximum - the old `parse_integer` function was passed `int` not `jlong`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22224#discussion_r1851374996 From lmesnik at openjdk.org Thu Nov 21 06:36:19 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 06:36:19 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT [v2] In-Reply-To: References: <-poZAS8WKk-DCPCO3UdlAvOLkFw11w_knbXBg7ZY-DU=.e2425d1d-929c-4f5c-bf2f-b312592e21d6@github.com> Message-ID: On Thu, 21 Nov 2024 05:22:46 GMT, David Holmes wrote: >> Everything which parses an integer option uses >> >> DCmdArgument >> >> (e.g. heap dump parallelism, etc...) >> >> >> DCmdArgument::parse_value(..) >> >> does the parsing, we have never had a definition for >> >> DCmdArgument > > Okay but just to be clear, this change means that the maximum value of this parameter is no longer limited to a 32-bit integer maximum, but is now a 64-bit maximum - the old `parse_integer` function was passed `int` not `jlong`. As I understand, the "INT" as parsed as jlong in jcmd. It is not limited by 32-bit. So that's ok. I thought to change max from int to size_t as it done in many cases or check if it too big for jint. However, I doubt that anyone is going to use so huge numbers there. The VM.events prints several latest event, remembered by Hotspot. The max number is set by LogEventsBufferEntries and is 20 by default and 250 for ZGC. The hard-limit is 1*M. So any value more then LogEventsBufferEntries doesn't limit anything. Might be makes sense to treat all values > MAX_INT just as unlimited just in case someone made mistake? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22224#discussion_r1851440006 From cjplummer at openjdk.org Thu Nov 21 07:22:15 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Thu, 21 Nov 2024 07:22:15 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v11] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Thu, 21 Nov 2024 05:08:06 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > SA test doesn't work with ZGC Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2450464051 From stefank at openjdk.org Thu Nov 21 08:34:18 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 21 Nov 2024 08:34:18 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v11] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Thu, 21 Nov 2024 05:08:06 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > SA test doesn't work with ZGC Instead of putting this inside of Mutex, could you instead create a class that is the container of this array? I think that would make a cleaner split between the code that operates on a specific Mutex vs code that is dealing with the set of registered Mutexes. Maybe name it MutexSet, MutexList, MutexArray, RegisteredMutexes, ...? If you don't like that suggestion I'd prefer if you fixed the nits I mention below. src/hotspot/share/runtime/mutex.cpp line 536: > 534: } > 535: #endif // ASSERT > 536: // Print all mutexes/monitors that are currently owned by a thread; called Please, leave a blank line between the pre-existing functions and the ones you are moving. Suggestion: // Print all mutexes/monitors that are currently owned by a thread; called src/hotspot/share/runtime/mutex.hpp line 54: > 52: class Mutex : public CHeapObj { > 53: > 54: friend class VMStructs; Suggestion: friend class VMStructs; src/hotspot/share/runtime/mutex.hpp line 138: > 136: > 137: public: > 138: static void add_mutex(Mutex* var); This adds a function to a part of the class that previously only held variables. Could this move to a block where we have functions instead? src/hotspot/share/runtime/mutex.hpp line 207: > 205: // by fatal error handler. > 206: static void print_owned_locks_on_error(outputStream* st); > 207: static void print_lock_ranks(outputStream* st); This splits print_on_error from print_on. Could you move this before print_on_err and make sure that there's a blank line before print_on_error. ------------- Changes requested by stefank (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2450579123 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851562349 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851564286 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851567414 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1851568394 From kevinw at openjdk.org Thu Nov 21 10:17:36 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 21 Nov 2024 10:17:36 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v5] In-Reply-To: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: <9_6BfhJv7DEZuPS9S-hdF35DufF3018wMK3EFkgca90=.c345a98a-9a5b-4844-8ebf-181996896504@github.com> > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java > There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... > > src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java > Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: - newline - remove implSetParallelism from VSThreadSchedulers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22155/files - new: https://git.openjdk.org/jdk/pull/22155/files/84d59ac3..7149d173 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22155&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22155&range=03-04 Stats: 10 lines in 1 file changed: 1 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22155/head:pull/22155 PR: https://git.openjdk.org/jdk/pull/22155 From kevinw at openjdk.org Thu Nov 21 10:17:36 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 21 Nov 2024 10:17:36 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v5] In-Reply-To: References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: On Wed, 20 Nov 2024 14:57:12 GMT, Alan Bateman wrote: >> Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: >> >> - newline >> - remove implSetParallelism from VSThreadSchedulers > > src/jdk.management/share/classes/com/sun/management/internal/VirtualThreadSchedulerImpls.java line 62: > >> 60: @Override >> 61: public final void setParallelism(int size) { >> 62: Util.checkControlAccess(); > > Dropping this means that we don't need setParallelism in the base class no need for implSetParallelism. In its place we just rename implSetParallelism to setParallelism in the subclasses. Got it, yes can remove implSetParallelism. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22155#discussion_r1851754072 From coleenp at openjdk.org Thu Nov 21 12:05:16 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Nov 2024 12:05:16 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Thu, 21 Nov 2024 05:12:20 GMT, David Holmes wrote: >> The JVMTI code for redefinition returns JVMTI_ERROR_FAILS_VERIFICATION and not the pending exception to the caller. The agent eventually in java.instrument/share/native/libinstrument/JavaExceptions.c will recreate the VerifyError based on the JVMTI error code. > > Wow that is pretty developer unfriendly. Hopefully exception logging will still show what the error is in detail. Yes, logging does show the detailed verify error. The test has -Xlog:exceptions also that shows where it came from. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22116#discussion_r1851930130 From jsjolen at openjdk.org Thu Nov 21 12:09:17 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 21 Nov 2024 12:09:17 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 15:30:05 GMT, Coleen Phillimore wrote: >> This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. >> >> The fix for always verifying redefined classes was actually pushed with JDK-8341094, where the verifier code respected the parameter "should_verify_class". By default this parameter follows the -Xverify setting. For redefinition, this is passed as true. The rest of the fix removes the special bootstrap loader cases that may have failed early on in the JDK development with -Xverify:all but now no longer do. If someone tries to redefine these classes, they should also do the verification on the redefined bytecodes. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. LGTM ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22116#pullrequestreview-2451178078 From coleenp at openjdk.org Thu Nov 21 12:19:24 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Nov 2024 12:19:24 GMT Subject: RFR: 8330606: Redefinition doesn't but should verify the new klass [v3] In-Reply-To: References: Message-ID: On Fri, 15 Nov 2024 15:30:05 GMT, Coleen Phillimore wrote: >> This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. >> >> The fix for always verifying redefined classes was actually pushed with JDK-8341094, where the verifier code respected the parameter "should_verify_class". By default this parameter follows the -Xverify setting. For redefinition, this is passed as true. The rest of the fix removes the special bootstrap loader cases that may have failed early on in the JDK development with -Xverify:all but now no longer do. If someone tries to redefine these classes, they should also do the verification on the redefined bytecodes. >> >> Tested with tier1-4. > > Coleen Phillimore has updated the pull request incrementally with one additional commit since the last revision: > > Reduce test, fix bug in verifier, move and add comments to is_eligible_for_verification. Thanks David and Johan for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22116#issuecomment-2490975908 From coleenp at openjdk.org Thu Nov 21 12:19:26 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 21 Nov 2024 12:19:26 GMT Subject: Integrated: 8330606: Redefinition doesn't but should verify the new klass In-Reply-To: References: Message-ID: <8Yx0Z0L78-we3910vLedVmoNap6tdN_zId4YCo4xyBM=.6aec857a-85d5-41e6-bca7-2f88dc06643d@github.com> On Thu, 14 Nov 2024 19:03:18 GMT, Coleen Phillimore wrote: > This change adds a couple of comments, removes some ancient bootstrapping code, and adds an old test that we call the verifier for redefining a class, even one in the bootclass path. > > The fix for always verifying redefined classes was actually pushed with JDK-8341094, where the verifier code respected the parameter "should_verify_class". By default this parameter follows the -Xverify setting. For redefinition, this is passed as true. The rest of the fix removes the special bootstrap loader cases that may have failed early on in the JDK development with -Xverify:all but now no longer do. If someone tries to redefine these classes, they should also do the verification on the redefined bytecodes. > > Tested with tier1-4. This pull request has now been integrated. Changeset: 8f22db23 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/8f22db23a50fe537d8ef369e92f0d5f9970d98f0 Stats: 141 lines in 4 files changed: 118 ins; 22 del; 1 mod 8330606: Redefinition doesn't but should verify the new klass Reviewed-by: dholmes, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/22116 From shade at openjdk.org Thu Nov 21 13:57:46 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 13:57:46 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> On Thu, 21 Nov 2024 00:59:27 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344670: GenShen: Use concurrent worker session for concurrent mark phase > > Reviewed-by: kdnilsen > - 8344640: GenShen: Reuse existing card mark barrier function when dropping references > > Reviewed-by: shade, ysr > - 8344592: GenShen: Remove unnecessary comments and changes > > Reviewed-by: kdnilsen > - 8344263: GenShen: Reduce extraneous log messages at INFO level > > Reviewed-by: ysr, shade > - 8344638: GenShen: Verifier should not touch claim token > > Reviewed-by: shade > - Merge > - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap > > Reviewed-by: wkemper, ysr > - 8344321: GenShen: Fix various sonar scan warnings > > Reviewed-by: kdnilsen, shade > - 8344264: GenShen: Improve comments and method names > > Reviewed-by: shade > - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 229/229 files read! This is an impressive, monumental piece of work, kudos. More comments from this read follow. I am going to circle back to some open threads in this PR. I am also running local tests, and in my ad-hoc performance tests generational mode performs admirably well. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 881: > 879: // update costs on slow path. > 880: monitoring_support()->notify_heap_changed(); > 881: _heap_changed.set(); Why not leave `try_set` intact? This alleviates contention on the shared counter, AFAICS. src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1972: > 1970: // Check that if concurrent weak root is set then active_gen isn't null > 1971: assert(!is_concurrent_weak_root_in_progress() || active_generation() != nullptr, "Error"); > 1972: shenandoah_assert_generations_reconciled(); Why all of this is checked here? I would have thought `gc_state` machinery should only check things related to gc-state. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 134: > 132: bool is_thread_safe() override { return true; } > 133: }; > 134: This looks like belonging in one of the `*closures.hpp` header. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 514: > 512: > 513: public: > 514: ShenandoahController* control_thread() { return _control_thread; } This method and field is probably `controller` then, right? src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 663: > 661: // ---------- CDS archive support > 662: > 663: bool can_load_archived_objects() const override { return !ShenandoahCardBarrier; } This means CDS heap loading is not yet working with generational Shenandoah? This looks OK for the experimental code. Please submit a bug for this and assign it to me. I will take a look at it some time later. src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 754: > 752: oop try_evacuate_object(oop src, Thread* thread, ShenandoahHeapRegion* from_region, ShenandoahAffiliation target_gen); > 753: public: > 754: I think this new line should be before `public:` src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 64: > 62: } > 63: } > 64: return _mark_bit_map.is_bitmap_clear_range(start, end); Comprehension check: this seems to bail out the moment it discovers an uncommitted slice. Does it really happen? More worryingly, if there is a mix of committed and uncommitted chunks, this method returns `true`, even if committed chunks are not actually clean? ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2450709063 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852054187 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852075850 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851646208 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851763351 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851761345 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1851765188 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852139996 From lmesnik at openjdk.org Thu Nov 21 16:11:45 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 16:11:45 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v12] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <5aVuHszNeKs5mD74oHjzeVd2raM5dFuPdmmnx4N5ed4=.3dca242b-7667-4a0b-971e-dfa5a1ec9e22@github.com> > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/runtime/mutex.hpp Co-authored-by: Stefan Karlsson - Update src/hotspot/share/runtime/mutex.cpp Co-authored-by: Stefan Karlsson ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/39b374f3..dae3d86d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=10-11 Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Thu Nov 21 16:19:04 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 16:19:04 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v13] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: <40aXhGIn_ZSESqN69PsemM4BKC1MYgH5qso09BExFJY=.398b0609-23e6-4771-9c08-ac97cb500e1a@github.com> > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: fixed decl ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/dae3d86d..e0290f7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=11-12 Stats: 11 lines in 1 file changed: 6 ins; 5 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From shade at openjdk.org Thu Nov 21 17:02:37 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 17:02:37 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> Message-ID: On Sat, 16 Nov 2024 17:54:01 GMT, Kelvin Nilsen wrote: >> I think it's here for the same reason `propagate_gc_state_to_java_threads` is here. Having it here makes it easier to see that this critical synchronization step happens for every safepoint. > > I'm inclined to leave as is, not wanting to disrupt stability of code that is known to be working. But if there is strong preference otherwise, we can make a change... OK, but file a bug for it to clean up. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852524191 From shade at openjdk.org Thu Nov 21 17:05:44 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 17:05:44 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <8p63u9MBsujLClN-XXtWMs5OOIUKV4E-foooFIqdyYA=.442aee6c-8733-488e-a050-1c2459d30631@github.com> On Tue, 19 Nov 2024 19:54:45 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 276: >> >>> 274: log_info(gc)("GC cancellation took %.3fs", cancel_time); >>> 275: _cancel_requested_time = 0; >>> 276: } >> >> Do we need this? Is this useful? > > We could log this at debug? I believe it is useful because this time (currently) is not accounted for in the heuristic's notion of 'cycle time'. Yeah, `gc=debug` would be okay for this. >> src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp line 193: >> >>> 191: Phase phase = Phase(pi); >>> 192: if (is_worker_phase(phase)) { >>> 193: double sum = uninitialized(); >> >> I think you can avoid changing this method to limit the churn. > > Hmm, I find the version in the PR much more readable. How about we upstream these changes separately? Yes, let's do that, if you have cycles. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852533117 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852533548 From wkemper at openjdk.org Thu Nov 21 18:12:45 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 18:12:45 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 10:15:27 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 663: > >> 661: // ---------- CDS archive support >> 662: >> 663: bool can_load_archived_objects() const override { return !ShenandoahCardBarrier; } > > This means CDS heap loading is not yet working with generational Shenandoah? This looks OK for the experimental code. Please submit a bug for this and assign it to me. I will take a look at it some time later. Yes, we have: https://bugs.openjdk.org/browse/JDK-8339182 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852633232 From wkemper at openjdk.org Thu Nov 21 18:15:42 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 18:15:42 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: <41m15WV5CgJ9hVyFzomp3dsrutwUTkoWsTu95JuYUiI=.6fd92984-1d04-4c78-858b-c16a98fcc382@github.com> On Thu, 21 Nov 2024 10:16:16 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 514: > >> 512: >> 513: public: >> 514: ShenandoahController* control_thread() { return _control_thread; } > > This method and field is probably `controller` then, right? Left the accessor and field with the same name to reduce churn. Clients of this method don't really need to change because in most (all?) cases, the public API of `ShenandoahControlThread` is declared in `ShenandoahController`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852636871 From stefank at openjdk.org Thu Nov 21 18:21:20 2024 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 21 Nov 2024 18:21:20 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v13] In-Reply-To: <40aXhGIn_ZSESqN69PsemM4BKC1MYgH5qso09BExFJY=.398b0609-23e6-4771-9c08-ac97cb500e1a@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> <40aXhGIn_ZSESqN69PsemM4BKC1MYgH5qso09BExFJY=.398b0609-23e6-4771-9c08-ac97cb500e1a@github.com> Message-ID: <_o3VptFYU0qOLHN771E5GptH9jhqzRpi3Ov9bkK_MEM=.a5b90653-3a5d-49d1-b396-9debc5eea09e@github.com> On Thu, 21 Nov 2024 16:19:04 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > fixed decl A couple more nits. src/hotspot/share/runtime/mutex.cpp line 592: > 590: #endif // ASSERT > 591: } > 592: Extra blank space Suggestion: src/hotspot/share/runtime/vmStructs.cpp line 1026: > 1024: \ > 1025: nonstatic_field(UpcallStub::FrameData, jfa, JavaFrameAnchor) \ > 1026: nonstatic_field(Mutex, _name, const char*) \ Other classes have their own section. Mutex should also have its own section. Suggestion: nonstatic_field(Mutex, _name, const char*) \ ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2452287831 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1852637155 PR Review Comment: https://git.openjdk.org/jdk/pull/22171#discussion_r1852643301 From kevinw at openjdk.org Thu Nov 21 18:24:45 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 21 Nov 2024 18:24:45 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi Message-ID: Remove redundant SecurityManager, AccessController references (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). ------------- Commit messages: - imports - unwrap, exception handling - ReflectUtil removal - tweak - 8344394: Remove SecurityManager and related calls from java.management.rmi Changes: https://git.openjdk.org/jdk/pull/22270/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22270&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344394 Stats: 290 lines in 3 files changed: 52 ins; 198 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/22270.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22270/head:pull/22270 PR: https://git.openjdk.org/jdk/pull/22270 From kevinw at openjdk.org Thu Nov 21 18:24:45 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 21 Nov 2024 18:24:45 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi In-Reply-To: References: Message-ID: <9gDJu0vJFzvcSuNi1s5HIB9EFU4PzT15PvHrDdv2984=.ca936c70-d367-47c4-a42f-96e7e86d6f50@github.com> On Wed, 20 Nov 2024 10:14:40 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Notes: 1 RMIConnectionImpl.java In the method unwrap(..) at the old line 1565 We used to be able to return null from this method: when you catch a PrivActionException, get the cause, and it's not IOException (which we throw) or ClassNotFoundException, which we throw in an UnmarshalException. Other exceptions, we may log, and return null. We have tests that check the behaviour of these exceptions, and what I have here passes it all. Trying to reinstate something that can return a null has so far failed! 2 RMIConnectionImpl.java There is still a local method named doPrivilegedOperation in here, but it no longer uses AccessController.doPrivileged. It is now not correctly named, should be cleaned up. As there are so many call sites and there is much Exception-handling here, I'd like to do that further tidyup separately. i.e. fully remove PrivilegedActionException. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22270#issuecomment-2491958271 From lmesnik at openjdk.org Thu Nov 21 18:32:13 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 18:32:13 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v14] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with two additional commits since the last revision: - Update src/hotspot/share/runtime/mutex.cpp Co-authored-by: Stefan Karlsson - Update src/hotspot/share/runtime/vmStructs.cpp Co-authored-by: Stefan Karlsson ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/e0290f7a..186beb0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=12-13 Stats: 2 lines in 2 files changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From shade at openjdk.org Thu Nov 21 18:33:42 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 18:33:42 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Wed, 20 Nov 2024 00:13:13 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 420: >> >>> 418: } >>> 419: int gc_state = _heap->gc_state(); >>> 420: if ((gc_state & ShenandoahHeap::YOUNG_MARKING) != 0) { >> >> It is not very clear this works fine with single-gen mode. Does `MARKING` imply `YOUNG_MARKING` in single-gen mode? I think we better make it abundantly clear with `is_generational()` checks. > > Yes, in single gen mode we set `MARKING` and `YOUNG_MARKING` together. See https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp#L81 We should really either predicate it on generational mode (we already poll it a few lines below) and check for `MARKING` specifically, or assert it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852659199 From wkemper at openjdk.org Thu Nov 21 19:14:39 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 19:14:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 09:14:57 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 134: > >> 132: bool is_thread_safe() override { return true; } >> 133: }; >> 134: > > This looks like belonging in one of the `*closures.hpp` header. https://bugs.openjdk.org/browse/JDK-8344779 > src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 754: > >> 752: oop try_evacuate_object(oop src, Thread* thread, ShenandoahHeapRegion* from_region, ShenandoahAffiliation target_gen); >> 753: public: >> 754: > > I think this new line should be before `public:` Sneaking this into: https://bugs.openjdk.org/browse/JDK-8344779 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852709552 PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852711083 From wkemper at openjdk.org Thu Nov 21 19:14:40 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 19:14:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 19 Nov 2024 23:17:48 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.hpp line 34: >> >>> 32: class ShenandoahHeapRegion; >>> 33: >>> 34: class ShenandoahFinalMarkUpdateRegionStateClosure : public ShenandoahHeapRegionClosure { >> >> There is the `shenandoahHeapRegionClosures.hpp` for these, no? > > It wasn't the intention that `shenandoahHeapRegionClosures.hpp` should become home to all of the `*HeapRegionClosures`. `ShenandoahFinalMarkUpdateRegionStateClosure` is shared in a couple of implementation files, but not the same as the ones using `shenandoahHeapRegionClosures.hpp`. I think `ShenandoahUpdateCensusZeroCohortClosure` should be moved into the only implementation file that uses it. https://bugs.openjdk.org/browse/JDK-8344779 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852709824 From shade at openjdk.org Thu Nov 21 19:33:42 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 21 Nov 2024 19:33:42 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <41m15WV5CgJ9hVyFzomp3dsrutwUTkoWsTu95JuYUiI=.6fd92984-1d04-4c78-858b-c16a98fcc382@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> <41m15WV5CgJ9hVyFzomp3dsrutwUTkoWsTu95JuYUiI=.6fd92984-1d04-4c78-858b-c16a98fcc382@github.com> Message-ID: <87AIGvZXmJftw8Sj68WTINanxXFtPVb7ITiRQLv1LsU=.68baafe0-87ce-4e4c-b02e-63ac460d7434@github.com> On Thu, 21 Nov 2024 18:12:43 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 514: >> >>> 512: >>> 513: public: >>> 514: ShenandoahController* control_thread() { return _control_thread; } >> >> This method and field is probably `controller` then, right? > > Left the accessor and field with the same name to reduce churn. Clients of this method don't really need to change because in most (all?) cases, the public API of `ShenandoahControlThread` is declared in `ShenandoahController`. OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852731729 From lmesnik at openjdk.org Thu Nov 21 19:43:40 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 21 Nov 2024 19:43:40 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v15] In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: added \ to the line ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22171/files - new: https://git.openjdk.org/jdk/pull/22171/files/186beb0a..45c712b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22171&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22171.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22171/head:pull/22171 PR: https://git.openjdk.org/jdk/pull/22171 From wkemper at openjdk.org Thu Nov 21 20:13:44 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 20:13:44 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 13:50:42 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 64: > >> 62: } >> 63: } >> 64: return _mark_bit_map.is_bitmap_clear_range(start, end); > > Comprehension check: this seems to bail out the moment it discovers an uncommitted slice. Does it really happen? More worryingly, if there is a mix of committed and uncommitted chunks, this method returns `true`, even if committed chunks are not actually clean? In all (3) usages of this method, the `start` and `end` are within the same region, so it isn't really iterating across regions. I'll rewrite it to handle this case more clearly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852802615 From ysr at openjdk.org Thu Nov 21 20:23:40 2024 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Thu, 21 Nov 2024 20:23:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 13:34:51 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1972: > >> 1970: // Check that if concurrent weak root is set then active_gen isn't null >> 1971: assert(!is_concurrent_weak_root_in_progress() || active_generation() != nullptr, "Error"); >> 1972: shenandoah_assert_generations_reconciled(); > > Why all of this is checked here? I would have thought `gc_state` machinery should only check things related to gc-state. Likely debugging detritus that I unintentionally left behind. Feel free to delete. I think the `shenandoah_assert_generations_reconciled()` is already checked in a most spots where it's needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852820087 From duke at openjdk.org Thu Nov 21 21:26:01 2024 From: duke at openjdk.org (Adam Bruce) Date: Thu, 21 Nov 2024 21:26:01 GMT Subject: RFR: 6726901: JDWP: ReferenceType.GetValues crashes jvm in case non-static fields are passed [v2] In-Reply-To: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> References: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> Message-ID: > This PR fixes a long-standing bug in JDWP where the access flags of a field are not checked before attempting to read it's value. > > Prior to this change, attempting to read a non-static field would cause a JVM crash, this change corrects that behaviour by returning `INVALID_FIELDID` instead. > > This is my first PR to OpenJDK, so please let me know if I've made any mistakes in the process. > > Cheers, > Adam Adam Bruce has updated the pull request incrementally with one additional commit since the last revision: Move static check to sharedGetFieldValues, add JDWP tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22280/files - new: https://git.openjdk.org/jdk/pull/22280/files/336bcdf4..88cd6e2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22280&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22280&range=00-01 Stats: 1113 lines in 8 files changed: 1097 ins; 12 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22280.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22280/head:pull/22280 PR: https://git.openjdk.org/jdk/pull/22280 From duke at openjdk.org Thu Nov 21 21:35:14 2024 From: duke at openjdk.org (Adam Bruce) Date: Thu, 21 Nov 2024 21:35:14 GMT Subject: RFR: 6726901: JDWP: ReferenceType.GetValues crashes jvm in case non-static fields are passed [v2] In-Reply-To: References: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> Message-ID: On Thu, 21 Nov 2024 21:26:01 GMT, Adam Bruce wrote: >> This PR fixes a long-standing bug in JDWP where the access flags of a field are not checked before attempting to read it's value. >> >> Prior to this change, attempting to read a non-static field would cause a JVM crash, this change corrects that behaviour by returning `INVALID_FIELDID` instead. >> >> This is my first PR to OpenJDK, so please let me know if I've made any mistakes in the process. >> >> Cheers, >> Adam > > Adam Bruce has updated the pull request incrementally with one additional commit since the last revision: > > Move static check to sharedGetFieldValues, add JDWP tests Thanks for the feedback, I've moved the check into sharedGetFieldValues. Unfortunately, this requires an allocation, as we need to check the fields before the length is written meaning we need to read the field IDs into an array so we have access to them after checking them. My initial change was also not suitable as writeStaticFieldValue and writeFieldValue were called after the length had been written. I've added some additional JDWP tests based on the two tests you suggested above. They use the exact same test classes but with all static fields converted to instance fields and vice versa. They also send a command for each field, to ensure the correct error is returned for all field types. I also added an additional helper method to verify that the expected error is present on ReplyPacket. I've also verified that all of the tests you listed above pass on my local machine (Linux) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22280#issuecomment-2492380425 From wkemper at openjdk.org Thu Nov 21 21:50:39 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 21:50:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 13:22:42 GMT, Aleksey Shipilev wrote: >> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 524 commits: >> >> - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux >> - 8344670: GenShen: Use concurrent worker session for concurrent mark phase >> >> Reviewed-by: kdnilsen >> - 8344640: GenShen: Reuse existing card mark barrier function when dropping references >> >> Reviewed-by: shade, ysr >> - 8344592: GenShen: Remove unnecessary comments and changes >> >> Reviewed-by: kdnilsen >> - 8344263: GenShen: Reduce extraneous log messages at INFO level >> >> Reviewed-by: ysr, shade >> - 8344638: GenShen: Verifier should not touch claim token >> >> Reviewed-by: shade >> - Merge >> - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap >> >> Reviewed-by: wkemper, ysr >> - 8344321: GenShen: Fix various sonar scan warnings >> >> Reviewed-by: kdnilsen, shade >> - 8344264: GenShen: Improve comments and method names >> >> Reviewed-by: shade >> - ... and 514 more: https://git.openjdk.org/jdk/compare/95a00f8a...7ab16403 > > src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 881: > >> 879: // update costs on slow path. >> 880: monitoring_support()->notify_heap_changed(); >> 881: _heap_changed.set(); > > Why not leave `try_set` intact? This alleviates contention on the shared counter, AFAICS. https://bugs.openjdk.org/browse/JDK-8344797 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852952949 From wkemper at openjdk.org Thu Nov 21 21:50:39 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 21:50:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 20:20:12 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1972: >> >>> 1970: // Check that if concurrent weak root is set then active_gen isn't null >>> 1971: assert(!is_concurrent_weak_root_in_progress() || active_generation() != nullptr, "Error"); >>> 1972: shenandoah_assert_generations_reconciled(); >> >> Why all of this is checked here? I would have thought `gc_state` machinery should only check things related to gc-state. > > Likely debugging detritus that I unintentionally left behind. Feel free to delete. > I think the `shenandoah_assert_generations_reconciled()` is already checked in a most spots where it's needed. https://bugs.openjdk.org/browse/JDK-8344797 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852949534 From wkemper at openjdk.org Thu Nov 21 21:50:40 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 21:50:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v8] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <5hEAJIG9hrrYUlCc2bSeh67dMfE56wt8JcFfzdpF8aw=.4f6a03e8-f5fe-4a91-9003-e04c3abbec0f@github.com> Message-ID: On Thu, 21 Nov 2024 20:10:20 GMT, William Kemper wrote: >> src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp line 64: >> >>> 62: } >>> 63: } >>> 64: return _mark_bit_map.is_bitmap_clear_range(start, end); >> >> Comprehension check: this seems to bail out the moment it discovers an uncommitted slice. Does it really happen? More worryingly, if there is a mix of committed and uncommitted chunks, this method returns `true`, even if committed chunks are not actually clean? > > In all (3) usages of this method, the `start` and `end` are within the same region, so it isn't really iterating across regions. I'll rewrite it to handle this case more clearly. https://bugs.openjdk.org/browse/JDK-8344797 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852949662 From wkemper at openjdk.org Thu Nov 21 22:14:37 2024 From: wkemper at openjdk.org (William Kemper) Date: Thu, 21 Nov 2024 22:14:37 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: <8p63u9MBsujLClN-XXtWMs5OOIUKV4E-foooFIqdyYA=.442aee6c-8733-488e-a050-1c2459d30631@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <8p63u9MBsujLClN-XXtWMs5OOIUKV4E-foooFIqdyYA=.442aee6c-8733-488e-a050-1c2459d30631@github.com> Message-ID: On Thu, 21 Nov 2024 17:02:58 GMT, Aleksey Shipilev wrote: >> Hmm, I find the version in the PR much more readable. How about we upstream these changes separately? > > Yes, let's do that, if you have cycles. https://bugs.openjdk.org/browse/JDK-8344797 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1852976446 From dholmes at openjdk.org Fri Nov 22 06:41:20 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 22 Nov 2024 06:41:20 GMT Subject: RFR: 8340334: Update jcmd VM.events max parameter to be INT [v2] In-Reply-To: References: <-poZAS8WKk-DCPCO3UdlAvOLkFw11w_knbXBg7ZY-DU=.e2425d1d-929c-4f5c-bf2f-b312592e21d6@github.com> Message-ID: On Thu, 21 Nov 2024 06:33:30 GMT, Leonid Mesnik wrote: >> Okay but just to be clear, this change means that the maximum value of this parameter is no longer limited to a 32-bit integer maximum, but is now a 64-bit maximum - the old `parse_integer` function was passed `int` not `jlong`. > > As I understand, the "INT" as parsed as jlong in jcmd. It is not limited by 32-bit. So that's ok. I thought to change max from int to size_t as it done in many cases or check if it too big for jint. > However, I doubt that anyone is going to use so huge numbers there. > The VM.events prints several latest event, remembered by Hotspot. The max number is set by LogEventsBufferEntries and is 20 by default and 250 for ZGC. The hard-limit is 1*M. > So any value more then LogEventsBufferEntries doesn't limit anything. > Might be makes sense to treat all values > MAX_INT just as unlimited just in case someone made mistake? const char* max_value = _max.value(); int max = -1; if (max_value != nullptr) { char* endptr = nullptr; if (!parse_integer(max_value, &max)) { `parse_integer` is a template function and it was passed an `int` so it limits to int values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22224#discussion_r1853356424 From schernyshev at openjdk.org Fri Nov 22 09:57:44 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 22 Nov 2024 09:57:44 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Tue, 12 Nov 2024 23:29:47 GMT, Sergey Chernyshev wrote: >> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 46: >> >>> 44: } >>> 45: >>> 46: public void setPath(String cgroupPath) { >> >> This should behave the same as Hotspot and also append the cgroup path to the mount point. Then let [JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) kick in to reduce it down to the mount point (if necessary). > > Correct. I double checked the behavior in cg v2: > > > sudo cgcreate -g memory:/test > sudo cgcreate -g memory:/test/test > sudo cgset -r memory.max=50m test > sudo cgset -r memory.swap.max=0 test > sudo cgset -r memory.max=100m test/test > sudo cgset -r memory.swap.max=0 test/test > > with the above setup, allocations smaller than the outer group size will work, bigger will be oom-killed. > > > $ sudo cgexec -g memory:/test/test sh -c "head -c 45m /dev/zero | tail | wc -c" > > 47185920 > > $ sudo cgexec -g memory:/test/test sh -c "head -c 55m /dev/zero | tail | wc -c" > > 0 > Killed > > > I'll update the PR next week. When a process is moved to a subgroup (cg v1), such as with the command docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --privileged ubuntu:latest \ sh -c "mkdir -p /sys/fs/cgroup/memory/test ; echo 100m > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; /jdk/bin/java -Xlog:os+container=trace -version" the hierarchical limits may fail to be detected because of an issue in the code below https://github.com/openjdk/jdk/blob/b9bf447209db5d7f6bb16a0310421dbe4170500c/src/hotspot/os/linux/cgroupUtil_linux.cpp#L64-L75 Here, `limit` at line 64 is not stored as a possible lowest limit, so if the inner group has lower limit than the outer group, it won't be detected (cg v2 is affected too). The cgroup path will be adjusted to the outer group (when it's limited). Another issue is in the loop at line 66 that reduces the path. In cg v1 in `cgroupns=host` mode (default) the cgroup_path includes the base cgroup and the subgroup (when moved). It may be not quite obvious which part of the path is the actual subgroup (and the CloudFoundry case has demonstrated it). It is suggested to determine the actual subgroup (path suffix) before reducing the group path. Please see the updated patch. I also added a new test case (TestMemoryWithSubgroups.java). The issue affects also Java Metrics. Maybe you could consider adding a similar fix in the path adjustment and a test case in the Metrics update ([JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881)), here's an example for Metrics test: private static void testMemoryLimitSubgroupV1(String innerSize, String outerGroupMemorySize, boolean privateNamespace) throws Exception { Common.logNewTestCase("testMemoryLimitSubgroup, innerSize = " + innerSize); DockerRunOptions opts = new DockerRunOptions(imageName, "sh", "-c"); opts.javaOpts = new ArrayList<>(); opts.appendTestJavaOptions = false; opts.addDockerOpts("--volume", Utils.TEST_CLASSES + ":/test-classes/") .addDockerOpts("--privileged") .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host")) .addDockerOpts("--memory", outerGroupMemorySize); opts.addClassOptions("mkdir -p /sys/fs/cgroup/memory/test ; " + "echo " + innerSize + " > /sys/fs/cgroup/memory/test/memory.limit_in_bytes ; " + "echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; " + "/jdk/bin/java -XX:+ErrorFileToStderr -cp /test-classes/ " + "--add-exports java.base/jdk.internal.platform=ALL-UNNAMED " + "MetricsMemoryTester memory " + innerSize); DockerTestUtils.dockerRunJava(opts).shouldHaveExitValue(0).shouldContain("TEST PASSED!!!"); } private static void testMemoryLimitSubgroupV2(String innerSize, String outerGroupMemorySize, boolean privateNamespace) throws Exception { Common.logNewTestCase("testMemoryLimitSubgroup, innerSize = " + innerSize); DockerRunOptions opts = new DockerRunOptions(imageName, "sh", "-c"); opts.javaOpts = new ArrayList<>(); opts.appendTestJavaOptions = false; opts.addDockerOpts("--volume", Utils.TEST_CLASSES + ":/test-classes/") .addDockerOpts("--privileged") .addDockerOpts("--cgroupns=" + (privateNamespace ? "private" : "host")) .addDockerOpts("--memory", outerGroupMemorySize); opts.addClassOptions("mkdir -p /sys/fs/cgroup/memory/test ; " + "echo $$ > /sys/fs/cgroup/memory/test/cgroup.procs ; " + "echo '+memory' > /sys/fs/cgroup/cgroup.subtree_control ; " + "echo '+memory' > /sys/fs/cgroup/memory/cgroup.subtree_control ; " + "echo " + innerSize + " > /sys/fs/cgroup/memory/test/memory.max ; " + "/jdk/bin/java -XX:+ErrorFileToStderr -cp /test-classes/ " + "--add-exports java.base/jdk.internal.platform=ALL-UNNAMED " + "MetricsMemoryTester memory " + innerSize); DockerTestUtils.dockerRunJava(opts).shouldHaveExitValue(0).shouldContain("TEST PASSED!!!"); } In cg v2 the way to enable memory controller is to move the process out of the group. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1853650100 From schernyshev at openjdk.org Fri Nov 22 09:57:44 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 22 Nov 2024 09:57:44 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v5] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: - Merge branch 'master' into JDK-8343191 - warn wenn ../ encountered, update path adjustment - Update src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp Co-authored-by: Severin Gehwolf - Merge branch 'master' into JDK-8343191 - patch reimplemented - fix the logic that skips duplicate controller's mount points - 8343191: Cgroup v1 subsystem fails to set subsystem path ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/c808ad49..30df5f09 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=03-04 Stats: 193640 lines in 4140 files changed: 65442 ins; 112750 del; 15448 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From sgehwolf at openjdk.org Fri Nov 22 11:00:20 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 22 Nov 2024 11:00:20 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v5] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:57:44 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Merge branch 'master' into JDK-8343191 > - warn wenn ../ encountered, update path adjustment > - Update src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp > > Co-authored-by: Severin Gehwolf > - Merge branch 'master' into JDK-8343191 > - patch reimplemented > - fix the logic that skips duplicate controller's mount points > - 8343191: Cgroup v1 subsystem fails to set subsystem path I like the added testing. One thing to note is that the new test requires root privileges (AFAIK). We should skip the test if we are being run as root. The added complexity is a concern. I hope we can reduce it a bit (on the expense of a longer hierarchy walk). ------------- PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2454136634 From sgehwolf at openjdk.org Fri Nov 22 11:00:21 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 22 Nov 2024 11:00:21 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:54:39 GMT, Sergey Chernyshev wrote: > Here, `limit` at line 64 is not stored as a possible lowest limit, so if the inner group has lower limit than the outer group, it won't be detected (cg v2 is affected too). Good spot! How about this to fix it? jlong limit = mem->read_memory_limit_in_bytes(phys_mem); jlong lowest_limit = limit < 0 ? phys_mem: limit; > The cgroup path will be adjusted to the outer group (when it's limited). Another issue is in the loop at line 66 that reduces the path. In cg v1 in `cgroupns=host` mode (default) the cgroup_path includes the base cgroup and the subgroup (when moved). It may be not quite obvious which part of the path is the actual subgroup (and the CloudFoundry case has demonstrated it). It is suggested to determine the actual subgroup (path suffix) before reducing the group path. Please see the updated patch. I'm worried about the added complexity. 1.) Is this something that's needed in cg v2 too? If no, we are changing cg version agnostic code for a version specific issue. 2.) Wouldn't setting the cgroup path to `/` achieve the same thing, when it's currently `null` (in current master)? After all, those are corner cases which don't seem very common. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1853729062 From kevinw at openjdk.org Fri Nov 22 12:24:42 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 22 Nov 2024 12:24:42 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands Message-ID: Remove redundant SecurityManager Permission references (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). ------------- Commit messages: - 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands Changes: https://git.openjdk.org/jdk/pull/22315/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334493 Stats: 402 lines in 17 files changed: 0 ins; 386 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/22315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22315/head:pull/22315 PR: https://git.openjdk.org/jdk/pull/22315 From coleenp at openjdk.org Fri Nov 22 12:31:14 2024 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 22 Nov 2024 12:31:14 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Looks good! ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22315#pullrequestreview-2454314366 From schernyshev at openjdk.org Fri Nov 22 13:03:17 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 22 Nov 2024 13:03:17 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: Message-ID: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> On Fri, 22 Nov 2024 10:54:34 GMT, Severin Gehwolf wrote: > Good spot! How about this to fix it? > > ``` > jlong limit = mem->read_memory_limit_in_bytes(phys_mem); > jlong lowest_limit = limit < 0 ? phys_mem: limit; > ``` Make sense to me. > I'm worried about the added complexity. 1.) Is this something that's needed in cg v2 too? If no, we are changing cg version agnostic code for a version specific issue. 2.) Wouldn't setting the cgroup path to `/` achieve the same thing, when it's currently `null` (in current master)? The added complexity only kicks in in cg v1 when `_root != cgroup_path`, so exactly in that corner case. In cg v2 it only works with `--cgroupns=host`, it ends up calling stat() once and then continues normally, so the added overhead is minimal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1853881528 From schernyshev at openjdk.org Fri Nov 22 15:11:22 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Fri, 22 Nov 2024 15:11:22 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v5] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 10:57:31 GMT, Severin Gehwolf wrote: > One thing to note is that the new test requires root privileges (AFAIK). We should skip the test if we are being run as root. The test works just like other docker tests, root privileges are not required. In systems that can't run docker for any reason, it should be skipped. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2493973317 From dfuchs at openjdk.org Fri Nov 22 16:22:17 2024 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 22 Nov 2024 16:22:17 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 10:14:40 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 32: > 30: import java.rmi.UnmarshalException; > 31: import java.rmi.server.Unreferenced; > 32: import java.security.PrivilegedActionException; should this be removed too? src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1286: > 1284: > 1285: /** @throws UnsupportedOperationException {@inheritDoc} */ > 1286: private Object doPrivilegedOperation(final int operation, Maybe rename "doPrivilegedOperation" into an overload of "doOperation" ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1854188609 PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1854196303 From sgehwolf at openjdk.org Fri Nov 22 16:50:17 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 22 Nov 2024 16:50:17 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> References: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> Message-ID: On Fri, 22 Nov 2024 13:00:14 GMT, Sergey Chernyshev wrote: >>> Here, `limit` at line 64 is not stored as a possible lowest limit, so if the inner group has lower limit than the outer group, it won't be detected (cg v2 is affected too). >> >> Good spot! How about this to fix it? >> >> >> jlong limit = mem->read_memory_limit_in_bytes(phys_mem); >> jlong lowest_limit = limit < 0 ? phys_mem: limit; >> >> >>> The cgroup path will be adjusted to the outer group (when it's limited). Another issue is in the loop at line 66 that reduces the path. In cg v1 in `cgroupns=host` mode (default) the cgroup_path includes the base cgroup and the subgroup (when moved). It may be not quite obvious which part of the path is the actual subgroup (and the CloudFoundry case has demonstrated it). It is suggested to determine the actual subgroup (path suffix) before reducing the group path. Please see the updated patch. >> >> I'm worried about the added complexity. 1.) Is this something that's needed in cg v2 too? If no, we are changing cg version agnostic code for a version specific issue. 2.) Wouldn't setting the cgroup path to `/` achieve the same thing, when it's currently `null` (in current master)? >> >> After all, those are corner cases which don't seem very common. > >> Good spot! How about this to fix it? >> >> ``` >> jlong limit = mem->read_memory_limit_in_bytes(phys_mem); >> jlong lowest_limit = limit < 0 ? phys_mem: limit; >> ``` > > Make sense to me. > >> I'm worried about the added complexity. 1.) Is this something that's needed in cg v2 too? If no, we are changing cg version agnostic code for a version specific issue. 2.) Wouldn't setting the cgroup path to `/` achieve the same thing, when it's currently `null` (in current master)? > > The added complexity only kicks in in cg v1 when `_root != cgroup_path`, so exactly in that corner case. In cg v2 it only works with `--cgroupns=host`, it ends up calling stat() once and then continues normally, so the added overhead is minimal. The added code in `CgroupUtil::adjust_controller` runs for cg v1 and cg v2 when path adjustment is deemed needed. So I'm not clear why it's needed for cg v2. I thought we have established that for cg v2 && `--cgroupns=host` the current path adjustment is sufficient? What am I missing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1854277359 From cjplummer at openjdk.org Fri Nov 22 17:29:23 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 22 Nov 2024 17:29:23 GMT Subject: RFR: 8343529: serviceability/sa/ClhsdbWhere.java fails AssertionFailure: Corrupted constant pool In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 22:15:29 GMT, Chris Plummer wrote: > These two tests both do stack dumps with one or more active threads. This can result in SA throwing an exception if the thread is in a bad state. However, SA will still generate stack traces for all other threads, and the tests should still pass all the output checks, so we can safely ignore these exceptions and not fail the test as a result of them. > > Tested by running all SA tests 50 times on all supported platforms. Tier1 testing in progress. Thanks for the reviews Kevin and Alex! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22123#issuecomment-2494364959 From cjplummer at openjdk.org Fri Nov 22 17:29:24 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 22 Nov 2024 17:29:24 GMT Subject: Integrated: 8343529: serviceability/sa/ClhsdbWhere.java fails AssertionFailure: Corrupted constant pool In-Reply-To: References: Message-ID: <0kzvvIUOL08NIDSLg3Xi0InU4Lot05hfHKI7Zw-RwFw=.2536446b-cd1e-40a7-a4da-1b283c640a00@github.com> On Thu, 14 Nov 2024 22:15:29 GMT, Chris Plummer wrote: > These two tests both do stack dumps with one or more active threads. This can result in SA throwing an exception if the thread is in a bad state. However, SA will still generate stack traces for all other threads, and the tests should still pass all the output checks, so we can safely ignore these exceptions and not fail the test as a result of them. > > Tested by running all SA tests 50 times on all supported platforms. Tier1 testing in progress. This pull request has now been integrated. Changeset: 21e0fb86 Author: Chris Plummer URL: https://git.openjdk.org/jdk/commit/21e0fb8648d61f041a04d44ad6c46fc5efd86261 Stats: 25 lines in 3 files changed: 16 ins; 0 del; 9 mod 8343529: serviceability/sa/ClhsdbWhere.java fails AssertionFailure: Corrupted constant pool 8307318: Test serviceability/sa/ClhsdbCDSJstackPrintAll.java failed: ArrayIndexOutOfBoundsException Reviewed-by: kevinw, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/22123 From kevinw at openjdk.org Fri Nov 22 17:32:18 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 22 Nov 2024 17:32:18 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 10:14:40 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Thanks @dfuch - both comments relate to my note: There are still some PrivilegedActionException references at this point, where an Exception is wrapped in a PrivilegedActionException as it always has been. Ideally (for me) would be to update that in a separate change, and leaving the method called doPrivilegedOperation will force me to come back here and change that. 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/22270#issuecomment-2494377049 From drwhite at openjdk.org Fri Nov 22 18:11:17 2024 From: drwhite at openjdk.org (Derek White) Date: Fri, 22 Nov 2024 18:11:17 GMT Subject: RFR: 8341481: [perf] vframeStreamCommon constructor may be optimized In-Reply-To: References: Message-ID: On Sat, 16 Nov 2024 00:20:10 GMT, Vladimir Ivanov wrote: > Optimize constructor to skip extra copy for registers. The tier1 tests are OK. The Specjvm2008 benchmark reports ~1% improvement. @kimbarrett - Hi! This is the issue with copy constructors that I mentioned in the parking lot a while back. The existing code for stack walking by vFrames is allocating multiple KB for 2 temporary RegisterMap structs, and copying between them via default copy constructors. The temps are unnecessary. We believe the performance boost in SPECjbb and SPECjvm:serial are more due to not polluting the L1 cache (improving cache hit rates of other code) than the actual instruction overhead of the copy. I tried to make the RegisterMap copy constructor private so no one would use it, but there are one or two cases that still use the copy constructor that we didn't have a fix for - maybe you'll see something. Oops, I can't find the examples right off. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22173#issuecomment-2494459792 From amenkov at openjdk.org Fri Nov 22 19:10:29 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 22 Nov 2024 19:10:29 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v5] In-Reply-To: <9_6BfhJv7DEZuPS9S-hdF35DufF3018wMK3EFkgca90=.c345a98a-9a5b-4844-8ebf-181996896504@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> <9_6BfhJv7DEZuPS9S-hdF35DufF3018wMK3EFkgca90=.c345a98a-9a5b-4844-8ebf-181996896504@github.com> Message-ID: On Thu, 21 Nov 2024 10:17:36 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java >> There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... >> >> src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java >> Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - newline > - remove implSetParallelism from VSThreadSchedulers Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22155#pullrequestreview-2455435291 From kevinw at openjdk.org Fri Nov 22 19:19:38 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 22 Nov 2024 19:19:38 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 10:14:40 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). As mentioned in https://github.com/openjdk/jdk/pull/22100 java.management.rmi is be done with its use of sun.reflect.misc, updating to remove the last import. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22270#issuecomment-2494615946 From kevinw at openjdk.org Fri Nov 22 19:19:37 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Fri, 22 Nov 2024 19:19:37 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi [v2] In-Reply-To: References: Message-ID: <1A8GHsmbepdWb6Q86waU06UJRRBYF-4qhd1WnWmdY_k=.d593bc0f-c73d-4230-b9b3-7e9cb2c7fa00@github.com> > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove last import sun.reflect.misc.ReflectUtil ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22270/files - new: https://git.openjdk.org/jdk/pull/22270/files/3e4a7179..8582eb97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22270&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22270&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22270.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22270/head:pull/22270 PR: https://git.openjdk.org/jdk/pull/22270 From cjplummer at openjdk.org Fri Nov 22 19:24:32 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 22 Nov 2024 19:24:32 GMT Subject: RFR: 8343741: SA jstack --mixed should print information about VM locks [v15] In-Reply-To: References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Thu, 21 Nov 2024 19:43:40 GMT, Leonid Mesnik wrote: >> Hi >> Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. >> >> Here is the motivation for this rfe and explanation why I add it into SA now. >> >> The information about current owners of Hotspot Mutex is often very useful for dealock investigations. >> >> The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. >> >> The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. >> >> The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. >> Also the debugger solution is OS specifc. >> >> The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. >> >> The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. >> The example of output: >> >> [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 >> Attaching to process ID 1620533, please wait... >> Debugger attached successfully. >> Server compiler detected. >> JVM version is 24-internal-adhoc.lmesnik.open >> Deadlock Detection: >> >> No deadlocks found. >> >> Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 >> Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 >> ----------------- 1620559 ----------------- >> "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] >> java.lang.Thread.State: RUNNABLE >> JavaThread state: _thread_blocked >> 0x00007f8cff11e88d syscall + 0x1d >> 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e >> 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 >> 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 >> 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 >> 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 >> 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 >> 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc >> 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe >> 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b >> ..... >> ----------------- 1620554 ----------------- >> "LockerThread" https://... > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > added \ to the line Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22171#pullrequestreview-2455458026 From lmesnik at openjdk.org Fri Nov 22 19:24:34 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 22 Nov 2024 19:24:34 GMT Subject: Integrated: 8343741: SA jstack --mixed should print information about VM locks In-Reply-To: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> References: <1o_5bVemyPSS18iVGUM4ay_Lt7qMFYJxgKvWaHB28Ew=.9f24e9c3-1d6b-4b35-b922-6cc66834762c@github.com> Message-ID: On Fri, 15 Nov 2024 23:36:37 GMT, Leonid Mesnik wrote: > Hi > Could you please review the the fix that add locks information into SA jhsdb stack --mixed output. > > Here is the motivation for this rfe and explanation why I add it into SA now. > > The information about current owners of Hotspot Mutex is often very useful for dealock investigations. > > The jcmd usually doesn't work because VM can't reach or exit safepoints. So it doesn't respond to jcmd. > > The SA 'jstack --mixed' provides information about stacktraces on Java and non-Java Threads. So having information about locks along with stack traces might significantly help to identify issues. > > The gdb allows to provide stacktraces, but the debug symbols are required to get info about locks. These symbols are often absent during execution. > Also the debugger solution is OS specifc. > > The significant part of fix is refacotorrng of mutex_array to be vmStructs compatible. > > The adding support of non-JavaThreads into SA might be implemented later to obtain more info about their names. > The example of output: > > [2024-11-06T21:32:48.897414435Z] Gathering output for process 1620563 > Attaching to process ID 1620533, please wait... > Debugger attached successfully. > Server compiler detected. > JVM version is 24-internal-adhoc.lmesnik.open > Deadlock Detection: > > No deadlocks found. > > Internal VM Mutex Threads_lock is owned by Unknnown thread (Might be non-Java Thread) with address: 0x00007f8cf825b190 > Internal VM Mutex Compile_lock is owned by LockerThread with address: 0x00007f8cf8309a00 > ----------------- 1620559 ----------------- > "C1 CompilerThread4" https://github.com/openjdk/jdk/pull/28 daemon prio=9 tid=0x00007f8c300566a0 nid=1620559 runnable [0x0000000000000000] > java.lang.Thread.State: RUNNABLE > JavaThread state: _thread_blocked > 0x00007f8cff11e88d syscall + 0x1d > 0x00007f8cfe6c99de LinuxWaitBarrier::wait(int) + 0x8e > 0x00007f8cfe2be409 SafepointMechanism::process(JavaThread*, bool, bool) + 0x79 > 0x00007f8cfd53ea91 ThreadInVMfromNative::ThreadInVMfromNative(JavaThread*) + 0xc1 > 0x00007f8cfd534a00 ciEnv::cache_jvmti_state() + 0x30 > 0x00007f8cfd679614 CompileBroker::invoke_compiler_on_method(CompileTask*) + 0x204 > 0x00007f8cfd67adc8 CompileBroker::compiler_thread_loop() + 0x5c8 > 0x00007f8cfdb4426c JavaThread::thread_main_inner() + 0xcc > 0x00007f8cfe5a0bbe Thread::call_run() + 0xbe > 0x00007f8cfe16813b thread_native_entry(Thread*) + 0x12b > ..... > ----------------- 1620554 ----------------- > "LockerThread" https://github.com/openjdk/jdk/pull/31 prio=5 tid=0x00007f8cf8309a00 nid=1620554 waiting on condition ... This pull request has now been integrated. Changeset: 98b66783 Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/98b667834c4a8f0d0ab54b8133061bc475674732 Stats: 494 lines in 19 files changed: 415 ins; 70 del; 9 mod 8343741: SA jstack --mixed should print information about VM locks Reviewed-by: cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/22171 From lmesnik at openjdk.org Fri Nov 22 19:43:14 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 22 Nov 2024 19:43:14 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22315#pullrequestreview-2455494106 From lmesnik at openjdk.org Fri Nov 22 21:59:22 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 22 Nov 2024 21:59:22 GMT Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes needlessly long to run [v3] In-Reply-To: References: Message-ID: <1eb5l0npiMc5dJW2MbTHuudDH_5fdrNZbU3P2ASgpds=.f3554b76-b6ac-4077-acae-e5a0ef4ea49e@github.com> On Mon, 7 Oct 2024 19:37:51 GMT, Sebastian L?vdahl wrote: >> The fix is twofold. >> >> 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting. >> >> 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration. >> >> On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s. >> >> Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it. >> >> Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both >> `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`. >> >> https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help. > > Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: > > Have EventGeneratorLoop end after a more predictable duration Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21331#pullrequestreview-2455814864 From amenkov at openjdk.org Fri Nov 22 22:29:17 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Fri, 22 Nov 2024 22:29:17 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi [v2] In-Reply-To: <1A8GHsmbepdWb6Q86waU06UJRRBYF-4qhd1WnWmdY_k=.d593bc0f-c73d-4230-b9b3-7e9cb2c7fa00@github.com> References: <1A8GHsmbepdWb6Q86waU06UJRRBYF-4qhd1WnWmdY_k=.d593bc0f-c73d-4230-b9b3-7e9cb2c7fa00@github.com> Message-ID: On Fri, 22 Nov 2024 19:19:37 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove last import sun.reflect.misc.ReflectUtil src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 108: > 106: ClassLoaderRepository repository = mbeanServer.getClassLoaderRepository(); > 107: this.classLoaderWithRepository = new ClassLoaderWithRepository(repository, dcl); > 108: this.defaultContextClassLoader = new CombinedClassLoader(Thread.currentThread().getContextClassLoader(), dcl); `this.` are not needed src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1231: > 1229: return getServerNotifFwd().fetchNotifs(clientSequenceNumber, timeout, maxNotifications); > 1230: } else { > 1231: return Subject.callAs(subject, () -> getServerNotifFwd().fetchNotifs(clientSequenceNumber, timeout, maxNotifications)); This call may throw CompletionException instead of PrivilegedActionException That's strange that this case does not go through standard `doPrivilegedOperation` way. I think this class needs to be improved (most likely as a separate PR). For most of operations it created "operation id" and creates array of arguments, but then `doOperation` parses the id and arguments and performs required action. It would be much simpler if doPrivilegedOperation/doOperation accept Callable. src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1313: > 1311: Throwable e = ce.getCause(); > 1312: if (e instanceof SecurityException) { > 1313: throw (SecurityException) e; Suggestion: if (e instanceof SecurityException se) { throw se; src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1315: > 1313: throw (SecurityException) e; > 1314: } else if (e instanceof Exception) { > 1315: throw new PrivilegedActionException((Exception) e); Suggestion: } else if (e instanceof Exception e1) { throw new PrivilegedActionException(e1); src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1484: > 1482: setCcl(old); > 1483: } > 1484: } catch (Exception e) { Need to handle CompletionException (or maybe at Subject.callAs call)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1854766377 PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1854784308 PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1854786790 PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1854787507 PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1854789725 From wkemper at openjdk.org Fri Nov 22 22:38:02 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 22 Nov 2024 22:38:02 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v9] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: <4AQkQIp1NjzLOj76FbXQ8HRcLhkjATlIHV4122VHjSE=.1fd8a480-070c-4133-acfd-0e051e9bdbce@github.com> > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 528 commits: - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - Merge - 8344779: GenShen: Consolidate shared heap region closures into one header Reviewed-by: kdnilsen, ysr - 8344797: GenShen: Update and rename confusing method Reviewed-by: ysr, kdnilsen - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - 8344670: GenShen: Use concurrent worker session for concurrent mark phase Reviewed-by: kdnilsen - 8344640: GenShen: Reuse existing card mark barrier function when dropping references Reviewed-by: shade, ysr - 8344592: GenShen: Remove unnecessary comments and changes Reviewed-by: kdnilsen - 8344263: GenShen: Reduce extraneous log messages at INFO level Reviewed-by: ysr, shade - 8344638: GenShen: Verifier should not touch claim token Reviewed-by: shade - ... and 518 more: https://git.openjdk.org/jdk/compare/4fbf2720...7eea1d5c ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=08 Stats: 22940 lines in 229 files changed: 21170 ins; 911 del; 859 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From schernyshev at openjdk.org Sat Nov 23 00:09:15 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Sat, 23 Nov 2024 00:09:15 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> Message-ID: On Fri, 22 Nov 2024 16:48:04 GMT, Severin Gehwolf wrote: > The added code in `CgroupUtil::adjust_controller` runs for cg v1 and cg v2 when path adjustment is deemed needed. So I'm not clear why it's needed for cg v2 It looks like there's no way to see at this point, if we are in cgroup v1 or v2 - if I am not mistaken. > I thought we have established that for cg v2 && `--cgroupns=host` the current path adjustment is sufficient? What am I missing? The current path adjustment still needs correction of `lowest_limit` in cg v2. Also allocating `limit_cg_path` is important, that's why I added the if block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1854921422 From alanb at openjdk.org Sat Nov 23 10:03:31 2024 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 23 Nov 2024 10:03:31 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). This is a change to the spec of a JDK specific API so I think should be tracked by a CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2495367950 From schernyshev at openjdk.org Sat Nov 23 10:31:14 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Sat, 23 Nov 2024 10:31:14 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> Message-ID: <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com> On Sat, 23 Nov 2024 00:06:26 GMT, Sergey Chernyshev wrote: > It looks like there's no way to see at this point, if we are in cgroup v1 or v2 - if I am not mistaken. On the other hand, a type parameter can be added to `CgroupUtil::adjust_controller()`. Would you recommend doing so? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1855167450 From syan at openjdk.org Sat Nov 23 13:12:48 2024 From: syan at openjdk.org (SendaoYan) Date: Sat, 23 Nov 2024 13:12:48 GMT Subject: RFR: 8344903: Test TestJhsdbJstackPrintVMLocks.java intermittemt fails getProcess() is null Message-ID: Hi all, The newly added test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java` intermittent fails `the return value of "jdk.test.lib.apps.LingeredApp.getProcess()" is null`. This PR check `getProcess()` is null or not before invoke `destroyForcibly`. Test-fix only, the change has been verified locally, no risk. ------------- Commit messages: - 8344903: Test TestJhsdbJstackPrintVMLocks.java intermittemt fails getProcess() is null - 8344903: Test TestJhsdbJstackPrintVMLocks.java intermittemt fails getProcess() is null Changes: https://git.openjdk.org/jdk/pull/22342/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22342&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344903 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22342.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22342/head:pull/22342 PR: https://git.openjdk.org/jdk/pull/22342 From lmesnik at openjdk.org Sun Nov 24 01:44:15 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 24 Nov 2024 01:44:15 GMT Subject: RFR: 8344903: Test TestJhsdbJstackPrintVMLocks.java intermittemt fails getProcess() is null In-Reply-To: References: Message-ID: <8qXIHvfAPPaKjcZU294HL-gBomO0fBZ8MZgzlz2BkPU=.ced193e8-c11b-40f4-9d3e-1a43ccc502f7@github.com> On Sat, 23 Nov 2024 13:08:13 GMT, SendaoYan wrote: > Hi all, > The newly added test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java` intermittent fails `the return value of "jdk.test.lib.apps.LingeredApp.getProcess()" is null`. This PR check `getProcess()` is null or not before invoke `destroyForcibly`. Test-fix only, the change has been verified locally, no risk. test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 82: > 80: throw new RuntimeException("Not able to find lock"); > 81: } finally { > 82: if (theApp.getProcess() != null) { This a really nice and usefule improvement, however doesn't fix the failure. It is unclear why the process is null. Some exception should have been thrown, but we don't see it. The exception from finally block override the real problem. So after your fix the test should start failing with real exception. If you can reproduce, investigate and fix the problem then you can make it in this PR. Otherwise, make sense to rename summary to something like: `Improve error handling TestJhsdbJstackPrintVMLocks.java ` and investigate the problem later when failure has more info ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22342#discussion_r1855325891 From lmesnik at openjdk.org Sun Nov 24 04:05:19 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Sun, 24 Nov 2024 04:05:19 GMT Subject: RFR: 8344903: Improve error handling TestJhsdbJstackPrintVMLocks.java In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 13:08:13 GMT, SendaoYan wrote: > Hi all, > The newly added test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java` intermittent fails `the return value of "jdk.test.lib.apps.LingeredApp.getProcess()" is null`. This PR check `getProcess()` is null or not before invoke `destroyForcibly`. Test-fix only, the change has been verified locally, no risk. Thanks for fixing this! ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22342#pullrequestreview-2456607722 From syan at openjdk.org Sun Nov 24 04:09:27 2024 From: syan at openjdk.org (SendaoYan) Date: Sun, 24 Nov 2024 04:09:27 GMT Subject: RFR: 8344903: Improve error handling TestJhsdbJstackPrintVMLocks.java In-Reply-To: <8qXIHvfAPPaKjcZU294HL-gBomO0fBZ8MZgzlz2BkPU=.ced193e8-c11b-40f4-9d3e-1a43ccc502f7@github.com> References: <8qXIHvfAPPaKjcZU294HL-gBomO0fBZ8MZgzlz2BkPU=.ced193e8-c11b-40f4-9d3e-1a43ccc502f7@github.com> Message-ID: <3yIkVbO--ja7U4rkQTitgsjmawZ3VGzH3Q3iHzgshoc=.7a0b14d9-d43b-446a-8b7c-032c68366693@github.com> On Sun, 24 Nov 2024 01:39:30 GMT, Leonid Mesnik wrote: >> Hi all, >> The newly added test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java` intermittent fails `the return value of "jdk.test.lib.apps.LingeredApp.getProcess()" is null`. This PR check `getProcess()` is null or not before invoke `destroyForcibly`. Test-fix only, the change has been verified locally, no risk. > > test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java line 82: > >> 80: throw new RuntimeException("Not able to find lock"); >> 81: } finally { >> 82: if (theApp.getProcess() != null) { > > This a really nice and usefule improvement, however doesn't fix the failure. > It is unclear why the process is null. Some exception should have been thrown, but we don't see it. The exception from finally block override the real problem. > So after your fix the test should start failing with real exception. If you can reproduce, investigate and fix the problem then you can make it in this PR. > Otherwise, make sense to rename summary to something like: > `Improve error handling TestJhsdbJstackPrintVMLocks.java > ` > and investigate the problem later when failure has more info Agree that this PR doesn't fix the failure of LingeredApp throw exception during the intialization. I have run this test standalone many times and can't reproduce the same failure. Maybe the failure only occur when run with other tests. The summary has been renamed according your advice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22342#discussion_r1855350530 From dholmes at openjdk.org Mon Nov 25 00:57:13 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Nov 2024 00:57:13 GMT Subject: RFR: 8344903: Improve error handling TestJhsdbJstackPrintVMLocks.java In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 13:08:13 GMT, SendaoYan wrote: > Hi all, > The newly added test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java` intermittent fails `the return value of "jdk.test.lib.apps.LingeredApp.getProcess()" is null`. This PR check `getProcess()` is null or not before invoke `destroyForcibly`. Test-fix only, the change has been verified locally, no risk. Okay, lets get this integrated so we can see what the real problem is. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22342#pullrequestreview-2456924665 From syan at openjdk.org Mon Nov 25 01:34:26 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 25 Nov 2024 01:34:26 GMT Subject: RFR: 8344903: Improve error handling TestJhsdbJstackPrintVMLocks.java In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 13:08:13 GMT, SendaoYan wrote: > Hi all, > The newly added test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java` intermittent fails `the return value of "jdk.test.lib.apps.LingeredApp.getProcess()" is null`. This PR check `getProcess()` is null or not before invoke `destroyForcibly`. Test-fix only, the change has been verified locally, no risk. Thanks all for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22342#issuecomment-2496497056 From syan at openjdk.org Mon Nov 25 01:34:27 2024 From: syan at openjdk.org (SendaoYan) Date: Mon, 25 Nov 2024 01:34:27 GMT Subject: Integrated: 8344903: Improve error handling TestJhsdbJstackPrintVMLocks.java In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 13:08:13 GMT, SendaoYan wrote: > Hi all, > The newly added test `test/hotspot/jtreg/serviceability/sa/TestJhsdbJstackPrintVMLocks.java` intermittent fails `the return value of "jdk.test.lib.apps.LingeredApp.getProcess()" is null`. This PR check `getProcess()` is null or not before invoke `destroyForcibly`. Test-fix only, the change has been verified locally, no risk. This pull request has now been integrated. Changeset: 8f08020f Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/8f08020fa452b15709f68a702abb5edec191dee2 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8344903: Improve error handling TestJhsdbJstackPrintVMLocks.java Reviewed-by: lmesnik, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/22342 From duke at openjdk.org Mon Nov 25 09:07:21 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Mon, 25 Nov 2024 09:07:21 GMT Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes needlessly long to run [v3] In-Reply-To: <1eb5l0npiMc5dJW2MbTHuudDH_5fdrNZbU3P2ASgpds=.f3554b76-b6ac-4077-acae-e5a0ef4ea49e@github.com> References: <1eb5l0npiMc5dJW2MbTHuudDH_5fdrNZbU3P2ASgpds=.f3554b76-b6ac-4077-acae-e5a0ef4ea49e@github.com> Message-ID: On Fri, 22 Nov 2024 21:56:40 GMT, Leonid Mesnik wrote: >> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: >> >> Have EventGeneratorLoop end after a more predictable duration > > Marked as reviewed by lmesnik (Reviewer). Thanks @lmesnik! Would you like to sponsor it too? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2497337017 From kevinw at openjdk.org Mon Nov 25 09:16:28 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 25 Nov 2024 09:16:28 GMT Subject: RFR: 8341436: containers/docker/TestJcmdWithSideCar.java takes needlessly long to run [v3] In-Reply-To: References: Message-ID: On Wed, 9 Oct 2024 19:45:24 GMT, Kevin Walls wrote: >> Sebastian L?vdahl has updated the pull request incrementally with one additional commit since the last revision: >> >> Have EventGeneratorLoop end after a more predictable duration > > Yes OEL was Oracle Linux: > > Our CI tests with docker run on Oracle Linux 7, and they fail with elevated-true (i.e. with "--cap-add=NET_BIND_SERVICE"). > > Our CI runs with Oracle Linux 8 use podman and they are OK using "--cap-add=NET_BIND_SERVICE" > @kevinjwalls WDYT, should we get this in so anyone running/investigating the root cause get to benefit from the speedup? Sure, got additional review now, we should go ahead with this. 8-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/21331#issuecomment-2497354110 From duke at openjdk.org Mon Nov 25 09:16:28 2024 From: duke at openjdk.org (Sebastian =?UTF-8?B?TMO2dmRhaGw=?=) Date: Mon, 25 Nov 2024 09:16:28 GMT Subject: Integrated: 8341436: containers/docker/TestJcmdWithSideCar.java takes needlessly long to run In-Reply-To: References: Message-ID: On Thu, 3 Oct 2024 19:13:46 GMT, Sebastian L?vdahl wrote: > The fix is twofold. > > 1. Stop the main container after an iteration is done. The main container is started with its runtime defined as 120 seconds, which means that each iteration takes 120 seconds. In reality, one iteration takes a few seconds while 115 seconds is spent waiting on the main container exiting. > > 2. Change the name of the main container to be unique per iteration. Containers are started with `--rm`, which means they are removed after exiting. However, the removal is done asynchronously _after_ the `stop` command has returned. This means that the second iteration may get an error if the same container name is used if the removal was not done before the container is started in the next iteration. > > On my machine, this cuts down the test runtime using Podman from 4m 13s to 17s. Using Docker, the runtime goes from 4m 15s to 41s. > > Podman only runs half the test cases (since JDK-8341310) which explain some of the difference. But there is also something strange going on in the Docker case; every `docker stop` call takes 10 seconds, and I have not been able to figure out what exactly causes it. > > Doing a manual `kill [container Java process PID]` gracefully terminates the Java process and container, but `docker stop` never does. Instead, it blocks for 10 seconds before abruptly killing the process using `SIGKILL`. I confirmed this with a simplified case and both > `strace -e 'trace=!all' docker run --init eclipse-temurin:23 java ..` and `strace -e 'trace=!all' docker run eclipse-temurin:23 java ..`, no signals were ever visible when calling either `docker stop` or `docker kill`. > > https://www.docker.com/blog/docker-best-practices-choosing-between-run-cmd-and-entrypoint/ and "What is PID 1 and why does it matter?" talks about why [`--init`](https://docs.docker.com/reference/cli/docker/container/run/#init) is supposed to help. This pull request has now been integrated. Changeset: da4b7a8c Author: Sebastian L?vdahl Committer: Kevin Walls URL: https://git.openjdk.org/jdk/commit/da4b7a8c56f56c6051d463bc34e51e35781fe1a8 Stats: 57 lines in 3 files changed: 18 ins; 12 del; 27 mod 8341436: containers/docker/TestJcmdWithSideCar.java takes needlessly long to run Reviewed-by: kevinw, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/21331 From sgehwolf at openjdk.org Mon Nov 25 09:42:17 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 25 Nov 2024 09:42:17 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com> References: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com> Message-ID: <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizxpQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com> On Sat, 23 Nov 2024 10:28:42 GMT, Sergey Chernyshev wrote: >>> The added code in `CgroupUtil::adjust_controller` runs for cg v1 and cg v2 when path adjustment is deemed needed. So I'm not clear why it's needed for cg v2 >> >> It looks like there's no way to see at this point, if we are in cgroup v1 or v2 - if I am not mistaken. >> >>> I thought we have established that for cg v2 && `--cgroupns=host` the current path adjustment is sufficient? What am I missing? >> >> The current path adjustment still needs correction of `lowest_limit` in cg v2. Also allocating `limit_cg_path` is important, that's why I added the if block. > >> It looks like there's no way to see at this point, if we are in cgroup v1 or v2 - if I am not mistaken. > > On the other hand, a type parameter can be added to `CgroupUtil::adjust_controller()`. Would you recommend doing so? @sercher I wouldn't recommend adding a type parameter. `CgroupUtil::adjust_controller` should stay cgroup version agnostic. Version specific code can be had in `set_subsystem_path()` of the corresponding impl (like an earlier version of your patch). `lowest_limit` and `limit_cg_path` fixes are version agnostic and can and should be fixed in `CgroupUtil::adjust_controller`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1856241432 From sgehwolf at openjdk.org Mon Nov 25 09:47:16 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 25 Nov 2024 09:47:16 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v5] In-Reply-To: References: Message-ID: <5FguneT4xc5crqbD5akMgnNt18XjGzq4BW9ycSvZDoY=.d4b5d0bd-2c04-4427-9c25-8325b3eae495@github.com> On Fri, 22 Nov 2024 15:08:18 GMT, Sergey Chernyshev wrote: > > One thing to note is that the new test requires root privileges (AFAIK). We should skip the test if we are being run as root. > > The test works just like other docker tests, root privileges are not required. In systems that can't run docker for any reason, it should be skipped. The new tests directly write into the cgroup interface files (does away with relying on the container framework doing it). For example: "echo '+memory' > /sys/fs/cgroup/memory/cgroup.subtree_control ; " ... relies on the user in the container image to be `root`. So depending on which base image is being used - by means of `-Djdk.test.docker.image.name=XXX -Djdk.test.docker.image.version=XX` - it might fail unexpectedly with permission errors. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2497440576 From kevinw at openjdk.org Mon Nov 25 09:54:15 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 25 Nov 2024 09:54:15 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 06:37:23 GMT, Alan Bateman wrote: > This is a change to the spec of a JDK specific API so I think should be tracked by a CSR. OK yes, I was looking for opinions on whether this needed a CSR. To be clear, the interface jdk.management / com.sun.management.DiagnosticCommandMBean has a method getDescriptor() which returns a Descriptor, which "is a collection of fields containing additional meta-data for a JMX element". This unfortunately does not say any of the metadata are optional, so now that a permission is meaningless we want to remove dcmd.permissionName, dcmd.permissionAction, dcmd.arguments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2497457131 From kevinw at openjdk.org Mon Nov 25 12:43:22 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 25 Nov 2024 12:43:22 GMT Subject: RFR: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent [v5] In-Reply-To: <9_6BfhJv7DEZuPS9S-hdF35DufF3018wMK3EFkgca90=.c345a98a-9a5b-4844-8ebf-181996896504@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> <9_6BfhJv7DEZuPS9S-hdF35DufF3018wMK3EFkgca90=.c345a98a-9a5b-4844-8ebf-181996896504@github.com> Message-ID: On Thu, 21 Nov 2024 10:17:36 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). >> >> src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java >> There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... >> >> src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java >> Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. > > Kevin Walls has updated the pull request incrementally with two additional commits since the last revision: > > - newline > - remove implSetParallelism from VSThreadSchedulers Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22155#issuecomment-2497915512 From kevinw at openjdk.org Mon Nov 25 12:56:23 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 25 Nov 2024 12:56:23 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi [v2] In-Reply-To: References: <1A8GHsmbepdWb6Q86waU06UJRRBYF-4qhd1WnWmdY_k=.d593bc0f-c73d-4230-b9b3-7e9cb2c7fa00@github.com> Message-ID: <8pSgf4L0CduRgaLjKqAZbUucVtkb2CqGgxjypmfqHGc=.87e39a00-de46-4f33-b820-3c7f0fd82c0b@github.com> On Fri, 22 Nov 2024 21:50:12 GMT, Alex Menkov wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove last import sun.reflect.misc.ReflectUtil > > src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 108: > >> 106: ClassLoaderRepository repository = mbeanServer.getClassLoaderRepository(); >> 107: this.classLoaderWithRepository = new ClassLoaderWithRepository(repository, dcl); >> 108: this.defaultContextClassLoader = new CombinedClassLoader(Thread.currentThread().getContextClassLoader(), dcl); > > `this.` are not needed Sure, they are the way it already was but happy to take them out. "this.mbeanServer =" does not need the "this" either, but I'm not touching that line so it would be odd to remove it now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1856568255 From kevinw at openjdk.org Mon Nov 25 12:59:19 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 25 Nov 2024 12:59:19 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi [v2] In-Reply-To: References: <1A8GHsmbepdWb6Q86waU06UJRRBYF-4qhd1WnWmdY_k=.d593bc0f-c73d-4230-b9b3-7e9cb2c7fa00@github.com> Message-ID: On Fri, 22 Nov 2024 22:08:28 GMT, Alex Menkov wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove last import sun.reflect.misc.ReflectUtil > > src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1231: > >> 1229: return getServerNotifFwd().fetchNotifs(clientSequenceNumber, timeout, maxNotifications); >> 1230: } else { >> 1231: return Subject.callAs(subject, () -> getServerNotifFwd().fetchNotifs(clientSequenceNumber, timeout, maxNotifications)); > > This call may throw CompletionException instead of PrivilegedActionException > That's strange that this case does not go through standard `doPrivilegedOperation` way. > I think this class needs to be improved (most likely as a separate PR). > For most of operations it created "operation id" and creates array of arguments, but then `doOperation` parses the id and arguments and performs required action. It would be much simpler if doPrivilegedOperation/doOperation accept Callable. Yes thanks, can unwrap CompletionException here like in the other callAs() usage in doPrivilegedOperation(). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1856572506 From kevinw at openjdk.org Mon Nov 25 13:53:22 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 25 Nov 2024 13:53:22 GMT Subject: Integrated: 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent In-Reply-To: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> References: <-488Kn_ugScUVK5D0Qujk_sx0ZSRD-xYs-Z5bcPSYGA=.d5b26be9-b913-45ce-9d32-3b7437ffb878@github.com> Message-ID: <4RqizkVZN8QWjmke3vqaOrKtJjwLQ3BsfCnSdObCts4=.8c07a12a-1610-4bb3-a1c5-f9b2013f3974@github.com> On Fri, 15 Nov 2024 17:36:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > src/jdk.management/share/classes/com/sun/management/internal/GarbageCollectionNotifInfoCompositeData.java > There is an existing theoretical path where GcInfoBuilder stays null, should never happen, "com.sun.management.GcInfo" exists... > > src/jdk.management/share/classes/com/sun/management/internal/GcInfoCompositeData.java > Similarly there is an existing assumption that Class.forName("com.sun.management.GcInfo") succeeds. This pull request has now been integrated. Changeset: e29b0edc Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/e29b0edc9739801c8371ac601a466428916d60b4 Stats: 134 lines in 10 files changed: 1 ins; 89 del; 44 mod 8344181: Remove SecurityManager and related calls from jdk.management and jdk.management.agent Reviewed-by: amenkov, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/22155 From kevinw at openjdk.org Mon Nov 25 14:47:00 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 25 Nov 2024 14:47:00 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi [v3] In-Reply-To: References: Message-ID: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: - Exeption handling feedback - Merge remote-tracking branch 'upstream/master' into 8344394_Management_rmi_post_sm - Remove last import sun.reflect.misc.ReflectUtil - imports - unwrap, exception handling - ReflectUtil removal - tweak - 8344394: Remove SecurityManager and related calls from java.management.rmi ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22270/files - new: https://git.openjdk.org/jdk/pull/22270/files/8582eb97..9d0b6a8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22270&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22270&range=01-02 Stats: 36812 lines in 984 files changed: 15943 ins; 16668 del; 4201 mod Patch: https://git.openjdk.org/jdk/pull/22270.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22270/head:pull/22270 PR: https://git.openjdk.org/jdk/pull/22270 From kevinw at openjdk.org Mon Nov 25 14:47:00 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Mon, 25 Nov 2024 14:47:00 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi [v2] In-Reply-To: <1A8GHsmbepdWb6Q86waU06UJRRBYF-4qhd1WnWmdY_k=.d593bc0f-c73d-4230-b9b3-7e9cb2c7fa00@github.com> References: <1A8GHsmbepdWb6Q86waU06UJRRBYF-4qhd1WnWmdY_k=.d593bc0f-c73d-4230-b9b3-7e9cb2c7fa00@github.com> Message-ID: On Fri, 22 Nov 2024 19:19:37 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove last import sun.reflect.misc.ReflectUtil Thanks @alexmenkov - I'm making the callAs calls handle and unwrap the CompletionException, and pass it on to existing exception handling. Yes, the existing fetchNotifications() doesn't use the doPrivOperation style. Seems relevant that it is part of RMIConnection interface, but not part of MBeanServerConnection. RMIConnector defines an RMINotifClient to loop, calling fetchNotifications, i.e. it's not what user code normally calls. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22270#issuecomment-2498210052 From duke at openjdk.org Mon Nov 25 16:22:48 2024 From: duke at openjdk.org (Larry Cable) Date: Mon, 25 Nov 2024 16:22:48 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command Message-ID: c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) Summary ------- Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. Problem ------- The JDK is lacking tooling to diagnose issues with virtual threads. Solution -------- Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. Here is sample output. The output is intended for experts and is not intended for automated parsing. Virtual thread scheduler: java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] Timeout schedulers: [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] Read I/O pollers: [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] Write I/O pollers: [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] Thread groupings: [platform threads = 11, virtual threads = 0] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845 [platform threads = 1, virtual threads = 0] The "Virtual thread scheduler" section show the target parallelism, the number of threads in the scheduler's pool, and other useful counters. The "Timeout schedulers" section provides information on the usage of the ScheduledThreadPoolExecutor used to support virtual thread doing timed operations. The "I/O pollers" section will vary by OS. The sample output here is macOS which, by default, has a one read and one write poller. This is useful to see how many blocking network I/O operations on virtual threads are in progress. The "Thread groupings" appears a support people to get a sense of how the virtual threads are grouped. Virtual threads created directly with the Thread API are in the "root" grouping. Some servers may have one or more ThreadPerTaskExecutor instances. For now, this section doesn't print the tree of thread groupings that arises when using the Structured Concurrency API. Specification ------------- The output from `jcmd Thread.vthread_summary -help` is: Thread.vthread_summary` Print the virtual thread scheduler, timeout schedulers, I/O pollers, and thread groupings. Impact: Low ------------- Commit messages: - JDK-8337199: removed thread groupings iimpl from dcmd as per Alan B, and disabled asssociated tests - JDK-8337199: merge master - Sync with loom repo - Sync up from loom repo - Update from loom repo - Initial commit Changes: https://git.openjdk.org/jdk/pull/22121/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22121&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337199 Stats: 466 lines in 11 files changed: 456 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22121.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22121/head:pull/22121 PR: https://git.openjdk.org/jdk/pull/22121 From alanb at openjdk.org Mon Nov 25 16:52:20 2024 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 25 Nov 2024 16:52:20 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable wrote: > c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) > > Summary > ------- > > Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. > > > Problem > ------- > > The JDK is lacking tooling to diagnose issues with virtual threads. > > > Solution > -------- > > Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. > > Here is sample output. The output is intended for experts and is not intended for automated parsing. > > > Virtual thread scheduler: > java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] > > Timeout schedulers: > [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] > [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > > Read I/O pollers: > [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] > > Write I/O pollers: > [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] > > Thread groupings: > [platform threads = 11, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] > ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] > ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0] > java.util.concurrent.Scheduled... In the CSR I think we've agreed to drop the thread groupings from this command. Can you update the Solution section so the sample output aligns with that? The PR shows merge conflicts, can you sync up the branch to closer to main line? The man page update moves from jcmd.1 to jcmd.md. Drop "thread groupings" from the description, and also VThreadSummaryDCmd::description (diagnosticCommand.hpp). I see the commit to comment out printing the thread groupings but I think better to remove the unused code. You can grab the latest VThreadSummary.java and VThreadSummaryTest.java from the loom repo. Also can you grab Poller.java too as it has the correct merge with JEP 491. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22121#issuecomment-2498536459 From duke at openjdk.org Mon Nov 25 17:56:16 2024 From: duke at openjdk.org (Larry Cable) Date: Mon, 25 Nov 2024 17:56:16 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: <0yLHRaZWc0Uk2tRWAP7vnbIq-Kl_zi03ICWBvjC5f_w=.b97538c7-11b4-44c6-b3f9-26b23bddb220@github.com> On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable wrote: > c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) > > Summary > ------- > > Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. > > > Problem > ------- > > The JDK is lacking tooling to diagnose issues with virtual threads. > > > Solution > -------- > > Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. > > Here is sample output. The output is intended for experts and is not intended for automated parsing. > > > Virtual thread scheduler: > java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] > > Timeout schedulers: > [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] > [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > > Read I/O pollers: > [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] > > Write I/O pollers: > [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] > > Thread groupings: > [platform threads = 11, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] > ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] > ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0] > java.util.concurrent.Scheduled... ok On 11/25/24 8:50 AM, Alan Bateman wrote: > > In the CSR I think we've agreed to drop the thread groupings from this > command. Can you update the Solution section so the sample output > aligns with that? > > The PR shows merge conflicts, can you sync up the branch to closer to > main line? The man page update moves from jcmd.1 to jcmd.md. Drop > "thread groupings" from the description, and also > VThreadSummaryDCmd::description (diagnosticCommand.hpp). > > I see the commit to comment out printing the thread groupings but I > think better to remove the unused code. You can grab the latest > VThreadSummary.java and VThreadSummaryTest.java from the loom repo. > Also can you grab Poller.java too as it has the correct merge with JEP > 491. > > ? > Reply to this email directly, view it on GitHub > , > or unsubscribe > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> > --------------43A07On2mpTNaH2Wy6LHFItz Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit ok

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

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

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

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

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


--------------43A07On2mpTNaH2Wy6LHFItz-- ------------- PR Comment: https://git.openjdk.org/jdk/pull/22121#issuecomment-2498677452 From wkemper at openjdk.org Mon Nov 25 18:01:40 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 25 Nov 2024 18:01:40 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Thu, 21 Nov 2024 18:30:31 GMT, Aleksey Shipilev wrote: >> Yes, in single gen mode we set `MARKING` and `YOUNG_MARKING` together. See https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahGlobalGeneration.cpp#L81 > > We should really either predicate it on generational mode (we already poll it a few lines below) and check for `MARKING` specifically, or assert it. I'll make some adjustments here. Note that `OLD_MARKING` also implies (and sets) `MARKING`, and - unlike `YOUNG_MARKING` - is not exclusive with `EVACUTION` and `UPDATEREFS`. Perhaps an explanatory comment is the best option here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1857098111 From shade at openjdk.org Mon Nov 25 18:25:39 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 25 Nov 2024 18:25:39 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 25 Nov 2024 17:59:05 GMT, William Kemper wrote: >> We should really either predicate it on generational mode (we already poll it a few lines below) and check for `MARKING` specifically, or assert it. > > I'll make some adjustments here. Note that `OLD_MARKING` also implies (and sets) `MARKING`, and - unlike `YOUNG_MARKING` - is not exclusive with `EVACUTION` and `UPDATEREFS`. Perhaps an explanatory comment is the best option here? Thing is, the description for `MARKING` says "marking is in progress" (for any mode), while `YOUNG_MARKING` says that it is only true for yougn marking. So for a casual reader, checking for `YOUNG_MARKING` in non-generational code looks weird. I don't know the best way out of this, really. I think this is the only place when we check `YOUNG_MARKING` for non-gen mode? If so, we should probably fix it right here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1857151960 From wkemper at openjdk.org Mon Nov 25 19:40:25 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 25 Nov 2024 19:40:25 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v10] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request incrementally with one additional commit since the last revision: Remove incomplete test case ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21273/files - new: https://git.openjdk.org/jdk/pull/21273/files/7eea1d5c..381af0cd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=08-09 Stats: 50 lines in 1 file changed: 0 ins; 50 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From wkemper at openjdk.org Mon Nov 25 19:40:26 2024 From: wkemper at openjdk.org (William Kemper) Date: Mon, 25 Nov 2024 19:40:26 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v7] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 25 Nov 2024 18:22:09 GMT, Aleksey Shipilev wrote: >> I'll make some adjustments here. Note that `OLD_MARKING` also implies (and sets) `MARKING`, and - unlike `YOUNG_MARKING` - is not exclusive with `EVACUTION` and `UPDATEREFS`. Perhaps an explanatory comment is the best option here? > > Thing is, the description for `MARKING` says "marking is in progress" (for any mode), while `YOUNG_MARKING` says that it is only true for yougn marking. So for a casual reader, checking for `YOUNG_MARKING` in non-generational code looks weird. I don't know the best way out of this, really. I think this is the only place when we check `YOUNG_MARKING` for non-gen mode? If so, we should probably fix it right here? Something like this maybe: https://bugs.openjdk.org/browse/JDK-8344985? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1857241797 From jsjolen at openjdk.org Mon Nov 25 19:50:18 2024 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 25 Nov 2024 19:50:18 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v3] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 00:33:31 GMT, David Holmes wrote: >> This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. >> >> There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. >> >> Just to clarify the issue. The size 1024 is an internal buffer limit that `fthrow` uses - it is an implementation detail and not something the caller should think about. It is also not relevant to the underlying problem, which is the size of the buffer needed for the fully expanded format string, which `os::vsnprintf` will try to calculate and report. The intent is to check callers can't hit that underlying `vsnprintf` INT_MAX limit. When your format string only deals with a few symbols and symbols are always < 64K then we know we are nowhere near that INT_MAX limit. If your format string can take a potentially arbitrary (usually from outside) string then it needs to put its own size guard in place using `%*s`. >> >> Testing: >> - tier 1-3 (sanity) >> >> Thanks > > David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into 8339134-fthrow > - Restore previous behaviour for zero length strings > - 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf OK, LGTM ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21867#pullrequestreview-2459486538 From dholmes at openjdk.org Mon Nov 25 19:58:24 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Nov 2024 19:58:24 GMT Subject: RFR: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 19:47:38 GMT, Johan Sj?len wrote: >> David Holmes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'master' into 8339134-fthrow >> - Restore previous behaviour for zero length strings >> - 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf > > OK, LGTM Thanks for the review @jdksjolen ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/21867#issuecomment-2498907288 From dholmes at openjdk.org Mon Nov 25 19:58:24 2024 From: dholmes at openjdk.org (David Holmes) Date: Mon, 25 Nov 2024 19:58:24 GMT Subject: Integrated: 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf In-Reply-To: References: Message-ID: <75uPxPy-t2hfO8dqxIya_lHR9gHf-fOPAz6jx6pDfZA=.2f29ef0b-5f85-4694-8319-15792faf0d2f@github.com> On Mon, 4 Nov 2024 07:00:38 GMT, David Holmes wrote: > This is mostly an audit of the callers of `Exceptions::fthrow` to ensure unbounded strings can't appear. > > There is a code change in DiagnosticCmd parsing to extend the string length limit already used in part of that code. > > Just to clarify the issue. The size 1024 is an internal buffer limit that `fthrow` uses - it is an implementation detail and not something the caller should think about. It is also not relevant to the underlying problem, which is the size of the buffer needed for the fully expanded format string, which `os::vsnprintf` will try to calculate and report. The intent is to check callers can't hit that underlying `vsnprintf` INT_MAX limit. When your format string only deals with a few symbols and symbols are always < 64K then we know we are nowhere near that INT_MAX limit. If your format string can take a potentially arbitrary (usually from outside) string then it needs to put its own size guard in place using `%*s`. > > Testing: > - tier 1-3 (sanity) > > Thanks This pull request has now been integrated. Changeset: 8de158ae Author: David Holmes URL: https://git.openjdk.org/jdk/commit/8de158aefe64d493e107ef310f510bab57beb251 Stats: 50 lines in 9 files changed: 44 ins; 1 del; 5 mod 8339134: Callers of Exceptions::fthrow should ensure exception message lengths avoid the INT_MAX limits of os::vsnprintf Reviewed-by: coleenp, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/21867 From cjplummer at openjdk.org Mon Nov 25 21:36:38 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 25 Nov 2024 21:36:38 GMT Subject: RFR: 6726901: JDWP: ReferenceType.GetValues crashes jvm in case non-static fields are passed [v2] In-Reply-To: References: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> Message-ID: <30TRmBvuRDPyLXAI2FbZlLfus8wuXvBa84LxGmOMnWE=.2cf4f119-783a-4e8a-9768-6a70fdbe3cda@github.com> On Thu, 21 Nov 2024 21:26:01 GMT, Adam Bruce wrote: >> This PR fixes a long-standing bug in JDWP where the access flags of a field are not checked before attempting to read it's value. >> >> Prior to this change, attempting to read a non-static field would cause a JVM crash, this change corrects that behaviour by returning `INVALID_FIELDID` instead. >> >> This is my first PR to OpenJDK, so please let me know if I've made any mistakes in the process. >> >> Cheers, >> Adam > > Adam Bruce has updated the pull request incrementally with one additional commit since the last revision: > > Move static check to sharedGetFieldValues, add JDWP tests test/hotspot/jtreg/vmTestbase/nsk/share/jdwp/ReplyPacket.java line 149: > 147: } > 148: } > 149: Rather than adding this, you could have the test call getReply(), which is implemented in the TestDebuggerType1 superclass. This would replace a lot of code in the test, including the allocation of the ReplyPacket, the call to transport.read(), the verification of the packet, and the logging. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22280#discussion_r1857371671 From cjplummer at openjdk.org Mon Nov 25 21:46:57 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 25 Nov 2024 21:46:57 GMT Subject: RFR: 6726901: JDWP: ReferenceType.GetValues crashes jvm in case non-static fields are passed [v2] In-Reply-To: References: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> Message-ID: On Thu, 21 Nov 2024 21:26:01 GMT, Adam Bruce wrote: >> This PR fixes a long-standing bug in JDWP where the access flags of a field are not checked before attempting to read it's value. >> >> Prior to this change, attempting to read a non-static field would cause a JVM crash, this change corrects that behaviour by returning `INVALID_FIELDID` instead. >> >> This is my first PR to OpenJDK, so please let me know if I've made any mistakes in the process. >> >> Cheers, >> Adam > > Adam Bruce has updated the pull request incrementally with one additional commit since the last revision: > > Move static check to sharedGetFieldValues, add JDWP tests I mentioned the following above: > I think JDI might need some fixes to the exception handling. Currently in ReferenceTypeImpl.getValues(), any JDWP exception goes through toJDIException() to convert it to a JDI exception, and it does not handle INVALID_FRAMEID. You'll need to special case it to throw IllegalArgumentException. Same is true in ObjectReferenceImpl.getValues(). This still needs to be addressed and will also need a JDI test case. Note ObjectReferenceImpl.getValues() probably doesn't need this fix as stated, since it separates the fields into separate arrays of static and non-static, so It should never see INVALID_FRAMEID. So I think maybe nothing needs to be done for it, but ReferenceTypeImpl.getValues() does need to be fixed and needs a test case. You might be able to modify nsk/jdi/ReferenceType/getValue/getvalue004.java to do this, or use it as a starting point for a new test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22280#issuecomment-2499098017 From cjplummer at openjdk.org Mon Nov 25 22:00:38 2024 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 25 Nov 2024 22:00:38 GMT Subject: RFR: 6726901: JDWP: ReferenceType.GetValues crashes jvm in case non-static fields are passed [v2] In-Reply-To: References: <24duAKhrEKg9gA4Bu_lkExd_khh1YkCWcq63YH1y7H4=.5e962328-e6c6-4507-981c-53ca243c5336@github.com> Message-ID: On Thu, 21 Nov 2024 21:26:01 GMT, Adam Bruce wrote: >> This PR fixes a long-standing bug in JDWP where the access flags of a field are not checked before attempting to read it's value. >> >> Prior to this change, attempting to read a non-static field would cause a JVM crash, this change corrects that behaviour by returning `INVALID_FIELDID` instead. >> >> This is my first PR to OpenJDK, so please let me know if I've made any mistakes in the process. >> >> Cheers, >> Adam > > Adam Bruce has updated the pull request incrementally with one additional commit since the last revision: > > Move static check to sharedGetFieldValues, add JDWP tests src/jdk.jdwp.agent/share/native/libjdwp/util.c line 516: > 514: > 515: if (!isStatic) { > 516: clazz = JNI_FUNC_PTR(env,GetObjectClass)(env, object); You need to free the jobject before exiting this function. Note you only do this if clazz is allocated here. The assignment to clazz above is from a jobject that the debug agent is managing (as part of mapping JDWP ObjectIDs to jobjects), so it should not be freed for the static case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22280#discussion_r1857397453 From amenkov at openjdk.org Tue Nov 26 00:04:41 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 26 Nov 2024 00:04:41 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 14:47:00 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Exeption handling feedback > - Merge remote-tracking branch 'upstream/master' into 8344394_Management_rmi_post_sm > - Remove last import sun.reflect.misc.ReflectUtil > - imports > - unwrap, exception handling > - ReflectUtil removal > - tweak > - 8344394: Remove SecurityManager and related calls from java.management.rmi Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22270#pullrequestreview-2459861552 From wkemper at openjdk.org Tue Nov 26 00:37:32 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 26 Nov 2024 00:37:32 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request incrementally with two additional commits since the last revision: - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - 8344985: GenShen: Refactor arraycopy barrier for generational mode Reviewed-by: shade ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21273/files - new: https://git.openjdk.org/jdk/pull/21273/files/381af0cd..08b59bc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=09-10 Stats: 14 lines in 1 file changed: 6 ins; 7 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From dholmes at openjdk.org Tue Nov 26 01:49:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 01:49:42 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Thu, 14 Nov 2024 21:34:08 GMT, Larry Cable wrote: > c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) > > Summary > ------- > > Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. > > > Problem > ------- > > The JDK is lacking tooling to diagnose issues with virtual threads. > > > Solution > -------- > > Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. > > Here is sample output. The output is intended for experts and is not intended for automated parsing. > > > Virtual thread scheduler: > java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] > > Timeout schedulers: > [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] > [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] > > Read I/O pollers: > [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] > > Write I/O pollers: > [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] > > Thread groupings: > [platform threads = 11, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] > ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] > java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] > java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] > ForkJoinPool-1/jdk.internal.vm.SharedThreadContainer at 48a03463 [platform threads = 2, virtual threads = 0] > java.util.concurrent.Scheduled... Generally looks like a good addition. We need to finalize names and content as per CSR request. A few coding/style issues that I've flagged. Thanks. src/hotspot/share/services/diagnosticCommand.cpp line 1124: > 1122: Symbol* sym = vmSymbols::jdk_internal_vm_VThreadSummary(); > 1123: Klass* k = SystemDictionary::resolve_or_fail(sym, true, CHECK); > 1124: if (HAS_PENDING_EXCEPTION) { You can never reach line 1124 if there is a pending exception because the `CHECK` macro will do a return from the method. I see the same problem pre-exists in the other DCmd code. If you want to handle exceptions directly then you want to use `THREAD` not `CHECK`. src/hotspot/share/services/diagnosticCommand.cpp line 1150: > 1148: oop res = cast_to_oop(result.get_jobject()); > 1149: assert(res->is_typeArray(), "just checking"); > 1150: assert(TypeArrayKlass::cast(res->klass())->element_type() == T_BYTE, "just checking"); I just called this out in another PR. These assertions are completely unnecessary unless you are trying to check the basic JavaCall operation - which you should not be. You are calling a method that returns a `byte[]` and that is what you will get back. src/hotspot/share/services/diagnosticCommand.hpp line 434: > 432: static const char* name() { return "Thread.print"; } > 433: static const char* description() { > 434: return "Print all platform threads with stacktraces."; Probably best not hide this correction in this PR but file a separate issue for it. src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 75: > 73: private static void printSchedulers(StringBuilder sb) { > 74: sb.append("Virtual thread scheduler:") > 75: .append(System.lineSeparator()); Can't you just do: sb.append("Virtual thread scheduler:\n") ? src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 77: > 75: .append(System.lineSeparator()); > 76: sb.append(JLA.virtualThreadDefaultScheduler()) > 77: .append(System.lineSeparator()); Stylistically it is common/customary to align the dot operator in chained method calls. src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 106: > 104: .append(masterPoller) > 105: .append(System.lineSeparator()); > 106: sb.append(System.lineSeparator()); Is this style trying to draw attention to the blank lines between sections? It looks odd to me to not chain the final append as well. src/java.base/share/classes/sun/nio/ch/Poller.java line 280: > 278: public String toString() { > 279: return Objects.toIdentityString(this) + " [registered = " + map.size() + "]"; > 280: } Why did you move this and "inline" the content of `registered()`? src/jdk.jcmd/share/man/jcmd.1 line 1: > 1: .\" Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved. The `.1` nroff files are no longer in the repo, you need to edit the markdown source instead. test/hotspot/jtreg/serviceability/dcmd/thread/VThreadSummaryTest.java line 74: > 72: .shouldContain(Objects.toIdentityString(defaultScheduler())) > 73: .shouldContain("Timeout schedulers:") > 74: .shouldContain("[0] " + ScheduledThreadPoolExecutor.class.getName()); Again please align dots on chained calls. ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22121#pullrequestreview-2459949901 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857550460 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857551670 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857552627 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857554925 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857554142 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857561627 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857562945 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857563813 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857564382 From dholmes at openjdk.org Tue Nov 26 02:10:39 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 02:10:39 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 01:38:55 GMT, David Holmes wrote: >> c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) >> >> Summary >> ------- >> >> Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. >> >> >> Problem >> ------- >> >> The JDK is lacking tooling to diagnose issues with virtual threads. >> >> >> Solution >> -------- >> >> Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. >> >> Here is sample output. The output is intended for experts and is not intended for automated parsing. >> >> >> Virtual thread scheduler: >> java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] >> >> Timeout schedulers: >> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] >> [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> >> Read I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] >> >> Write I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] >> >> Thread groupings: >> [platform threads = 11, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] >> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] >> ForkJoinPool-1/jdk.internal.vm.SharedThreadC... > > src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 75: > >> 73: private static void printSchedulers(StringBuilder sb) { >> 74: sb.append("Virtual thread scheduler:") >> 75: .append(System.lineSeparator()); > > Can't you just do: > > sb.append("Virtual thread scheduler:\n") > > ? Sorry I was thinking about `%n` but you can't use that here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857616753 From alanb at openjdk.org Tue Nov 26 06:39:45 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 26 Nov 2024 06:39:45 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 01:37:33 GMT, David Holmes wrote: >> c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) >> >> Summary >> ------- >> >> Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. >> >> >> Problem >> ------- >> >> The JDK is lacking tooling to diagnose issues with virtual threads. >> >> >> Solution >> -------- >> >> Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. >> >> Here is sample output. The output is intended for experts and is not intended for automated parsing. >> >> >> Virtual thread scheduler: >> java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] >> >> Timeout schedulers: >> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] >> [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> >> Read I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] >> >> Write I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] >> >> Thread groupings: >> [platform threads = 11, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] >> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] >> ForkJoinPool-1/jdk.internal.vm.SharedThreadC... > > src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 77: > >> 75: .append(System.lineSeparator()); >> 76: sb.append(JLA.virtualThreadDefaultScheduler()) >> 77: .append(System.lineSeparator()); > > Stylistically it is common/customary to align the dot operator in chained method calls. It's just a style thing, it was done this way because the first string is the heading, the strings that follow go under the heading. > src/jdk.jcmd/share/man/jcmd.1 line 1: > >> 1: .\" Copyright (c) 2012, 2024, Oracle and/or its affiliates. All rights reserved. > > The `.1` nroff files are no longer in the repo, you need to edit the markdown source instead. That was already pointed out, I think the PR was merged from an older version. > test/hotspot/jtreg/serviceability/dcmd/thread/VThreadSummaryTest.java line 74: > >> 72: .shouldContain(Objects.toIdentityString(defaultScheduler())) >> 73: .shouldContain("Timeout schedulers:") >> 74: .shouldContain("[0] " + ScheduledThreadPoolExecutor.class.getName()); > > Again please align dots on chained calls. and the IDE will of course re-align it at next edit :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857881180 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857881767 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857882356 From dholmes at openjdk.org Tue Nov 26 06:42:09 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 06:42:09 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 Message-ID: After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} are all singletons and so the actual strings can just be inlined directly into the code that uses them. Testing: - GHA - Tiers 1-4 sanity - Thanks ------------- Commit messages: - 8343703: Symbol name cleanups after JEP 479 Changes: https://git.openjdk.org/jdk/pull/22380/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343703 Stats: 95 lines in 5 files changed: 7 ins; 49 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/22380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22380/head:pull/22380 PR: https://git.openjdk.org/jdk/pull/22380 From alanb at openjdk.org Tue Nov 26 06:47:40 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 26 Nov 2024 06:47:40 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_summary diagnostic command In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 01:41:34 GMT, David Holmes wrote: >> c.f: [https://bugs.openjdk.org/browse/JDK-8339420](https://bugs.openjdk.org/browse/JDK-8339420) >> >> Summary >> ------- >> >> Add `jcmd Thread.vthread_summary` to print summary information that is useful when trying to diagnose issues with virtual threads. >> >> >> Problem >> ------- >> >> The JDK is lacking tooling to diagnose issues with virtual threads. >> >> >> Solution >> -------- >> >> Add a new command that the `jcmd` command line tool can use to print information about virtual threads. The output includes the virtual thread scheduler, the schedulers used to support timeouts, and the I/O pollers used to support virtual threads doing socket I/O, and a summary of the thread groupings. >> >> Here is sample output. The output is intended for experts and is not intended for automated parsing. >> >> >> Virtual thread scheduler: >> java.util.concurrent.ForkJoinPool at 4a624db0[Running, parallelism = 16, size = 2, active = 0, running = 0, steals = 2, tasks = 0, submissions = 0] >> >> Timeout schedulers: >> [0] java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [1] java.util.concurrent.ScheduledThreadPoolExecutor at 6193b845[Running, pool size = 1, active threads = 0, queued tasks = 1, completed tasks = 0] >> [2] java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> [3] java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef[Running, pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 0] >> >> Read I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 524bf25 [registered = 1] >> >> Write I/O pollers: >> [0] sun.nio.ch.KQueuePoller at 25c41da2 [registered = 0] >> >> Thread groupings: >> [platform threads = 11, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at c4437c4 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 3f91beef [platform threads = 0, virtual threads = 0] >> ForkJoinPool.commonPool/jdk.internal.vm.SharedThreadContainer at 4fa374ea [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPoolExecutor at 506e1b77 [platform threads = 1, virtual threads = 0] >> java.util.concurrent.ScheduledThreadPoolExecutor at 1f17ae12 [platform threads = 0, virtual threads = 0] >> java.util.concurrent.ThreadPerTaskExecutor at 24155ffc [platform threads = 0, virtual threads = 2] >> ForkJoinPool-1/jdk.internal.vm.SharedThreadC... > > src/java.base/share/classes/jdk/internal/vm/VThreadSummary.java line 106: > >> 104: .append(masterPoller) >> 105: .append(System.lineSeparator()); >> 106: sb.append(System.lineSeparator()); > > Is this style trying to draw attention to the blank lines between sections? It looks odd to me to not chain the final append as well. It is a blank line, shouldn't be chained to the previous statement. > src/java.base/share/classes/sun/nio/ch/Poller.java line 280: > >> 278: public String toString() { >> 279: return Objects.toIdentityString(this) + " [registered = " + map.size() + "]"; >> 280: } > > Why did you move this and "inline" the content of `registered()`? I think that is PR merge issue, it's correct in the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857890217 PR Review Comment: https://git.openjdk.org/jdk/pull/22121#discussion_r1857890689 From dholmes at openjdk.org Tue Nov 26 07:31:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 07:31:42 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks Something is broken ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/22380#issuecomment-2499867992 From dholmes at openjdk.org Tue Nov 26 07:31:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Tue, 26 Nov 2024 07:31:42 GMT Subject: Withdrawn: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22380 From shade at openjdk.org Tue Nov 26 09:44:02 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 26 Nov 2024 09:44:02 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade I checked all review threads, and I think my review feedback was appropriately addressed. I see no (new) test failures in my local testing as well. Thank you all, this is a huge piece of engineering work, and it looks good for experimental feature. We would probably make a few touchups and simplifications after the integration. I hope this would stabilize in the future releases to become a new default mode for Shenandoah! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2460929110 From rkennke at openjdk.org Tue Nov 26 11:16:07 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Tue, 26 Nov 2024 11:16:07 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade I also looked again at any new changes since I reviewed last time. Still looks good. Ship it! This is great work! Roman ------------- Marked as reviewed by rkennke (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2461152113 From kevinw at openjdk.org Tue Nov 26 11:16:14 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 26 Nov 2024 11:16:14 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v8] In-Reply-To: References: Message-ID: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: - Exception handling - tidyup - Suppression tidyup - unnecessary variables - remove redundant method - Merge remote-tracking branch 'upstream/master' into java_management_post_sm - ReflectUtil removals - Remove checkPackageAccess calls - Remove Util.check... calls - mostly removing imports - ... and 6 more: https://git.openjdk.org/jdk/compare/2b351ce8...9628234f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22100/files - new: https://git.openjdk.org/jdk/pull/22100/files/a330df5f..9628234f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22100&range=06-07 Stats: 112504 lines in 1858 files changed: 54747 ins; 48923 del; 8834 mod Patch: https://git.openjdk.org/jdk/pull/22100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22100/head:pull/22100 PR: https://git.openjdk.org/jdk/pull/22100 From kevinw at openjdk.org Tue Nov 26 11:16:15 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 26 Nov 2024 11:16:15 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v7] In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 17:06:41 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > ReflectUtil removals A few updates. Triggered by investigating this, I've logged these future cleanup items (not for jdk-24): 8344966: Remove the allowNonPublic MBean compatibility property 8344969: Remove the jmx.mxbean.multiname compatibility property 8344976: Remove the jmx.invoke.getters compatibility property 8345045: Remove the jmx.remote.x.buffer.size JMX notification property 8345048: Remove the jmx.extend.open.types compatibility property 8345049: Remove the jmx.tabular.data.hash.map compatibility property ------------- PR Comment: https://git.openjdk.org/jdk/pull/22100#issuecomment-2500337871 From kevinw at openjdk.org Tue Nov 26 11:16:15 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 26 Nov 2024 11:16:15 GMT Subject: RFR: 8344177: Remove SecurityManager and related calls from java.management [v8] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 15:00:22 GMT, Daniel Fuchs wrote: >> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision: >> >> - Exception handling >> - tidyup >> - Suppression tidyup >> - unnecessary variables >> - remove redundant method >> - Merge remote-tracking branch 'upstream/master' into java_management_post_sm >> - ReflectUtil removals >> - Remove checkPackageAccess calls >> - Remove Util.check... calls >> - mostly removing imports >> - ... and 6 more: https://git.openjdk.org/jdk/compare/2b351ce8...9628234f > > src/java.management/share/classes/javax/management/remote/JMXConnectorFactory.java line 448: > >> 446: { return super.loadClass(name, resolve); } >> 447: } >> 448: : null; > > I suspect we could just return `parent` here but that might require some deeper investigation. Agreed, not sure if this is really needed. It has only one usage. Have left as is for now... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22100#discussion_r1858285043 From alanb at openjdk.org Tue Nov 26 17:05:48 2024 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 26 Nov 2024 17:05:48 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java line 112: > 110: this.cmd = cmd; > 111: this.info = info; > 112: Exception cause = null; I assume cause can be deleted too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22315#discussion_r1858929672 From mdoerr at openjdk.org Tue Nov 26 17:43:06 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 26 Nov 2024 17:43:06 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade Can you also add the platform code contributors to the Contributors, please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2501563056 From wkemper at openjdk.org Tue Nov 26 19:52:03 2024 From: wkemper at openjdk.org (William Kemper) Date: Tue, 26 Nov 2024 19:52:03 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade Thank you for getting us started: Thank you for the PPC64 port: Thank you for the RISCV port: ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2501791242 From kevinw at openjdk.org Tue Nov 26 20:47:45 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 26 Nov 2024 20:47:45 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi [v3] In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 14:47:00 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager, AccessController references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: > > - Exeption handling feedback > - Merge remote-tracking branch 'upstream/master' into 8344394_Management_rmi_post_sm > - Remove last import sun.reflect.misc.ReflectUtil > - imports > - unwrap, exception handling > - ReflectUtil removal > - tweak > - 8344394: Remove SecurityManager and related calls from java.management.rmi The follow-on for further Exceptional cleanup is https://bugs.openjdk.org/browse/JDK-8345079 ------------- PR Comment: https://git.openjdk.org/jdk/pull/22270#issuecomment-2501902128 From kevinw at openjdk.org Tue Nov 26 21:31:52 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 26 Nov 2024 21:31:52 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: Remove 'cause' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22315/files - new: https://git.openjdk.org/jdk/pull/22315/files/d173aec7..8486bbe4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22315&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22315&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22315/head:pull/22315 PR: https://git.openjdk.org/jdk/pull/22315 From kevinw at openjdk.org Tue Nov 26 21:31:53 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Tue, 26 Nov 2024 21:31:53 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 17:03:22 GMT, Alan Bateman wrote: >> Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove 'cause' > > src/jdk.management/share/classes/com/sun/management/internal/DiagnosticCommandImpl.java line 112: > >> 110: this.cmd = cmd; >> 111: this.info = info; >> 112: Exception cause = null; > > I assume cause can be deleted too. Yes, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22315#discussion_r1859250311 From darcy at openjdk.org Tue Nov 26 23:25:39 2024 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 26 Nov 2024 23:25:39 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Mon, 25 Nov 2024 09:51:10 GMT, Kevin Walls wrote: > > This is a change to the spec of a JDK specific API so I think should be tracked by a CSR. > > OK yes, I was looking for opinions on whether this needed a CSR. > > To be clear, the interface jdk.management / com.sun.management.DiagnosticCommandMBean has a method getDescriptor() which returns a Descriptor, which "is a collection of fields containing additional meta-data for a JMX element". > > This unfortunately does not say any of the metadata are optional, so now that a permission is meaningless we want to remove dcmd.permissionName, dcmd.permissionAction, dcmd.arguments. Yes; please file a quick CSR. Thanks for asking. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2502171504 From dholmes at openjdk.org Wed Nov 27 01:05:42 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 01:05:42 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks Re-opened. There was a testing glitch caused by a change not part of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22380#issuecomment-2502378940 From amenkov at openjdk.org Wed Nov 27 01:46:39 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 27 Nov 2024 01:46:39 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks Marked as reviewed by amenkov (Reviewer). src/java.base/share/native/libjava/NativeLibraries.c line 76: > 74: > 75: // sym + '_' + cname + '\0' > 76: if ((len = (cname != NULL ? (strlen(cname) + 1) : 0) + strlen(sym) + 1) > To match the updated comment: Suggestion: if ((len = strlen(sym) + (cname != NULL ? (strlen(cname) + 1) : 0) + 1) > ------------- PR Review: https://git.openjdk.org/jdk/pull/22380#pullrequestreview-2463375580 PR Review Comment: https://git.openjdk.org/jdk/pull/22380#discussion_r1859629230 From ysr at openjdk.org Wed Nov 27 02:30:01 2024 From: ysr at openjdk.org (Y. Srinivas Ramakrishna) Date: Wed, 27 Nov 2024 02:30:01 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v6] In-Reply-To: <0FH7N5Xa3DLDGZcWdxwWQHivNSTxGj9w3p-hWFSgMIs=.654c7bd9-90bb-436d-aedd-08d9fa77efc8@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> <-XAjLoN795CLkoG36JK_Xsb64u55hizy5ym3e6qsfVE=.fbbdc54c-e117-4b84-bad1-e9593f2c048c@github.com> <0FH7N5Xa3DLDGZcWdxwWQHivNSTxGj9w3p-hWFSgMIs=.654c7bd9-90bb-436d-aedd-08d9fa77efc8@github.com> Message-ID: On Wed, 20 Nov 2024 00:01:49 GMT, Y. Srinivas Ramakrishna wrote: >> src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 474: >> >>> 472: // elision safe. >>> 473: return; >>> 474: } >> >> Why is this safe for Shenandoah? I suspect it needs `CardTableBarrierSet::on_slowpath_allocation_exit` to work. `G1BarrierSetC2` gets it by subclassing `CardTableBarrierSetC2`. But `ShenandoahBarrierSetC2` does not. Should it? > > Good question. I'm tracking at https://bugs.openjdk.org/browse/JDK-8344593 , and will follow up there. A code review indicates that the code is fine, but the comment could be improved. A quick test of performance didn't indicate (with specjbb) any difference in performance (done only for GenShen) but a more complete suite of performance tests is being run to assess the efficacy of the optimization. I'm inclined to leave this in, since eliding card-marks doesn't hurt, even if it doesn't seem to help much either. The comment will be adjusted as part of the above ticket. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21273#discussion_r1859698145 From dholmes at openjdk.org Wed Nov 27 05:20:16 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 05:20:16 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks David Holmes has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/native/libjava/NativeLibraries.c Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22380/files - new: https://git.openjdk.org/jdk/pull/22380/files/e7081932..c38bb48f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22380/head:pull/22380 PR: https://git.openjdk.org/jdk/pull/22380 From dholmes at openjdk.org Wed Nov 27 05:20:16 2024 From: dholmes at openjdk.org (David Holmes) Date: Wed, 27 Nov 2024 05:20:16 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: <1b1f_xG8E-rg3dYcYQIqZSlF8LLW6ZbSehDD2ZRC5Pg=.de226ac3-9641-4795-919b-d8d6975b496e@github.com> On Wed, 27 Nov 2024 01:43:34 GMT, Alex Menkov wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/native/libjava/NativeLibraries.c >> >> Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> > > Marked as reviewed by amenkov (Reviewer). Thanks for the review @alexmenkov ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22380#issuecomment-2502827946 From schernyshev at openjdk.org Wed Nov 27 09:11:22 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 27 Nov 2024 09:11:22 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v6] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: adjust path suffix in cgroup (v1) version specific code, when root != cgroup ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/30df5f09..f27175a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=04-05 Stats: 61 lines in 2 files changed: 15 ins; 41 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From schernyshev at openjdk.org Wed Nov 27 09:11:22 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 27 Nov 2024 09:11:22 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizxpQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com> References: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com> <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizx pQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com> Message-ID: On Mon, 25 Nov 2024 09:40:03 GMT, Severin Gehwolf wrote: > Version specific code can be had in `set_subsystem_path()` of the corresponding impl (like an earlier version of your patch). `lowest_limit` and `limit_cg_path` fixes are version agnostic and can and should be fixed in `CgroupUtil::adjust_controller`. Done. Please see the updated PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860265208 From schernyshev at openjdk.org Wed Nov 27 09:11:22 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 27 Nov 2024 09:11:22 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v5] In-Reply-To: <5FguneT4xc5crqbD5akMgnNt18XjGzq4BW9ycSvZDoY=.d4b5d0bd-2c04-4427-9c25-8325b3eae495@github.com> References: <5FguneT4xc5crqbD5akMgnNt18XjGzq4BW9ycSvZDoY=.d4b5d0bd-2c04-4427-9c25-8325b3eae495@github.com> Message-ID: On Mon, 25 Nov 2024 09:44:33 GMT, Severin Gehwolf wrote: > ``` > "echo '+memory' > /sys/fs/cgroup/memory/cgroup.subtree_control ; " > ``` > > ... relies on the user in the container image to be `root`. So depending on which base image is being used - by means of `-Djdk.test.docker.image.name=XXX -Djdk.test.docker.image.version=XX` - it might fail unexpectedly with permission errors. The default base image in the test library is "ubuntu:latest" with `root` as the default user. `--privileged` ensures the cgroup files are mounted read-write. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2503316548 From mdoerr at openjdk.org Wed Nov 27 09:44:04 2024 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 27 Nov 2024 09:44:04 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade Thanks! I've run another round of tests on all our platforms and the only failure I have seen is [JDK-8344312](https://bugs.openjdk.org/browse/JDK-8344312). I can do more stress testing by making GenShen the default GC. But that can still be done after integration. Could you please add the failing test to the problem list to avoid failures in our CI? gc/shenandoah/oom/TestAllocOutOfMemory.java 8344312 linux-ppc64le ------------- PR Comment: https://git.openjdk.org/jdk/pull/21273#issuecomment-2503393423 From kevinw at openjdk.org Wed Nov 27 09:57:42 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Wed, 27 Nov 2024 09:57:42 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Sat, 23 Nov 2024 06:37:23 GMT, Alan Bateman wrote: >> Remove redundant SecurityManager Permission references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > This is a change to the spec of a JDK specific API so I think should be tracked by a CSR. Thanks, (@AlanBateman and @jddarcy), have added the diff of the doc to the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2503427053 From schernyshev at openjdk.org Wed Nov 27 10:55:22 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 27 Nov 2024 10:55:22 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v7] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: updated test (path is reduced) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/f27175a8..ec5fef0a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From schernyshev at openjdk.org Wed Nov 27 10:59:42 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 27 Nov 2024 10:59:42 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com> <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizx pQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com> Message-ID: On Wed, 27 Nov 2024 09:08:30 GMT, Sergey Chernyshev wrote: > Done. Please see the updated PR. The metrics part still needs the update - in the cgroup version specific `setPath()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860451322 From sgehwolf at openjdk.org Wed Nov 27 11:10:47 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 27 Nov 2024 11:10:47 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v6] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 09:11:22 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > adjust path suffix in cgroup (v1) version specific code, when root != cgroup src/hotspot/os/linux/cgroupUtil_linux.cpp line 70: > 68: os::free(limit_cg_path); // handles nullptr > 69: limit_cg_path = os::strdup(cg_path); > 70: } We can avoid the duplicate copy of the original cgroup path, which is already captured in `orig` by using: jlong lowest_limit = limit < 0 ? phys_mem : limit; julong orig_limit = ((julong)lowest_limit) != phys_mem ? lowest_limit : phys_mem; And on line 91 we change the condition from: if ((julong)lowest_limit != phys_mem) { to: if ((julong)lowest_limit != orig_limit) { src/hotspot/os/linux/cgroupUtil_linux.cpp line 129: > 127: lowest_limit = cpus; > 128: os::free(limit_cg_path); // handles nullptr > 129: limit_cg_path = os::strdup(cg_path); Same here with the extra allocation of `cg_path`; src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 320: > 318: ss.print_raw(cgroup_path); > 319: if (strstr((char*)cgroup_path, "../") != nullptr) { > 320: log_warning(os, container)("Cgroup v2 path at [%s] is [%s], cgroup limits can be wrong.", Suggestion: log_warning(os, container)("Cgroup cpu/memory controller path includes '../', detected limits won't be accurate", src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 322: > 320: log_warning(os, container)("Cgroup v2 path at [%s] is [%s], cgroup limits can be wrong.", > 321: mount_path, cgroup_path); > 322: } Why the cast to `char*`? We should probably move this warning to `CgroupUtil::adjust_controller`, right before we've determined that we actually need to adjust. I wonder, though, if we should just print the warning and set the cgroup_path to `/` and return early. Otherwise, path adjustment will run with no different result. src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 66: > 64: // Rely on path adjustment that determines the actual suffix. > 65: path += cgroupPath; > 66: } This seems a simpler solution than the hotspot one. While I prefer this one, please make them consistent at the least. test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 39: > 37: * @modules java.base/jdk.internal.platform > 38: * @library /test/lib > 39: * @build jdk.test.whitebox.WhiteBox CheckOperatingSystemMXBean `CheckOperatingSystemMXBean` seems unused. test/jdk/jdk/internal/platform/cgroup/CgroupV1SubsystemControllerTest.java line 93: > 91: > 92: @Test > 93: public void testCgPathFallbackToMountPoint() { Suggestion: public void testCgPathToMovedPath() { test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 479: > 477: cgroupv1MemoryController.setPath(cpuInfo.getCgroupPath()); > 478: String actualPath = cgroupv1MemoryController.path(); > 479: assertNotNull("Controller path should not have been null", actualPath); Suggestion: assertNotNull(actualPath); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860392728 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860401209 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860438020 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860430948 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860449131 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860453472 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860455992 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860458236 From alanb at openjdk.org Wed Nov 27 17:44:40 2024 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 27 Nov 2024 17:44:40 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 21:31:52 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager Permission references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove 'cause' Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22315#pullrequestreview-2465652474 From lmesnik at openjdk.org Wed Nov 27 17:52:38 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 27 Nov 2024 17:52:38 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 21:31:52 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager Permission references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove 'cause' Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22315#pullrequestreview-2465666546 From amenkov at openjdk.org Wed Nov 27 18:57:37 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 27 Nov 2024 18:57:37 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 05:20:16 GMT, David Holmes wrote: >> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: >> >> #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} >> #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} >> #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} >> >> are all singletons and so the actual strings can just be inlined directly into the code that uses them. >> >> Testing: >> - GHA >> - Tiers 1-4 sanity >> - >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/native/libjava/NativeLibraries.c > > Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> Marked as reviewed by amenkov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22380#pullrequestreview-2465773079 From phh at openjdk.org Wed Nov 27 23:09:05 2024 From: phh at openjdk.org (Paul Hohensee) Date: Wed, 27 Nov 2024 23:09:05 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v11] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Tue, 26 Nov 2024 00:37:32 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request incrementally with two additional commits since the last revision: > > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2466068316 From liach at openjdk.org Wed Nov 27 23:19:23 2024 From: liach at openjdk.org (Chen Liang) Date: Wed, 27 Nov 2024 23:19:23 GMT Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after JDK-83324714 Message-ID: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests. The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself. Now there is fewer than 100 `@enablePreview` in the `test` directory. To reviewers, there are some redundant changes and notes: - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API. - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are: - `BoundAttribute::payloadLen` for javac attribute tests - Annotation reading/writing for javac annotation tests - Line number changes to: - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java - Move from legacy jdk.internal.classfile to java.lang.classfile in: - test/langtools/tools/javac/NoStringToLower.java and - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview. Testing: did a quick tier 1-2 locally, waiting for CI on tier 1-3. Please inform me if any of these tests belong to higher tiers. ------------- Commit messages: - 8334733: Remove obsolete @enablePreview from tests after JDK-83324714 Changes: https://git.openjdk.org/jdk/pull/22420/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22420&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334733 Stats: 635 lines in 360 files changed: 2 ins; 556 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/22420.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22420/head:pull/22420 PR: https://git.openjdk.org/jdk/pull/22420 From amenkov at openjdk.org Thu Nov 28 01:44:18 2024 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 28 Nov 2024 01:44:18 GMT Subject: RFR: 8345148: Fix for JDK-8337317 is incomplete Message-ID: <3WOIoXjRlNGyRRgOe5N5aiw98AkJjLN4SHTZikRBYrg=.b011d890-bd7f-4da0-b933-0add4a8882dd@github.com> Fix for JDK-8337317 (#20699) updated serviceability/jvmti/HiddenClass and serviceability/jvmti/VMObjectAlloc tests adding guards against JVMTI_ERROR_WRONG_PHASE errors, but missed to enable JVMTI_EVENT_VM_DEATH events. This fix adds the missed part. Testing: hotspot/jtreg/serviceability/jvmti on all platforms Manually verified test outputs contain "VMDeath" notification from VMDeath callback ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/22426/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22426&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345148 Stats: 12 lines in 2 files changed: 10 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/22426.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22426/head:pull/22426 PR: https://git.openjdk.org/jdk/pull/22426 From kbarrett at openjdk.org Thu Nov 28 01:56:38 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 28 Nov 2024 01:56:38 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 05:20:16 GMT, David Holmes wrote: >> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: >> >> #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} >> #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} >> #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} >> >> are all singletons and so the actual strings can just be inlined directly into the code that uses them. >> >> Testing: >> - GHA >> - Tiers 1-4 sanity >> - >> Thanks > > David Holmes has updated the pull request incrementally with one additional commit since the last revision: > > Update src/java.base/share/native/libjava/NativeLibraries.c > > Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> Changes requested by kbarrett (Reviewer). src/java.base/share/native/libjava/NativeLibraries.c line 88: > 86: if (cname != NULL) { > 87: strcat(jniFunctionName, "_"); > 88: strcat(jniFunctionName, cname); Should be using 4-space indentation, rather than HotSpot's 2 space indentation. ------------- PR Review: https://git.openjdk.org/jdk/pull/22380#pullrequestreview-2466185432 PR Review Comment: https://git.openjdk.org/jdk/pull/22380#discussion_r1861413410 From dholmes at openjdk.org Thu Nov 28 02:21:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Nov 2024 02:21:55 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v3] In-Reply-To: References: Message-ID: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks David Holmes has updated the pull request incrementally with two additional commits since the last revision: - Merge branch '8343703-jni-symbol' of github.com:dholmes-ora/jdk into 8343703-jni-symbol - Fix indent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22380/files - new: https://git.openjdk.org/jdk/pull/22380/files/c38bb48f..64ecc3b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22380&range=01-02 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22380.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22380/head:pull/22380 PR: https://git.openjdk.org/jdk/pull/22380 From dholmes at openjdk.org Thu Nov 28 02:21:55 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Nov 2024 02:21:55 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v2] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 01:54:10 GMT, Kim Barrett wrote: >> David Holmes has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/java.base/share/native/libjava/NativeLibraries.c >> >> Co-authored-by: Alex Menkov <69548902+alexmenkov at users.noreply.github.com> > > src/java.base/share/native/libjava/NativeLibraries.c line 88: > >> 86: if (cname != NULL) { >> 87: strcat(jniFunctionName, "_"); >> 88: strcat(jniFunctionName, cname); > > Should be using 4-space indentation, rather than HotSpot's 2 space indentation. Good catch! Thanks for reviewing Kim. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22380#discussion_r1861426578 From kbarrett at openjdk.org Thu Nov 28 02:27:46 2024 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 28 Nov 2024 02:27:46 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v3] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 02:21:55 GMT, David Holmes wrote: >> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: >> >> #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} >> #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} >> #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} >> >> are all singletons and so the actual strings can just be inlined directly into the code that uses them. >> >> Testing: >> - GHA >> - Tiers 1-4 sanity >> - >> Thanks > > David Holmes has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8343703-jni-symbol' of github.com:dholmes-ora/jdk into 8343703-jni-symbol > - Fix indent Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/22380#pullrequestreview-2466212066 From dholmes at openjdk.org Thu Nov 28 02:27:46 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Nov 2024 02:27:46 GMT Subject: RFR: 8343703: Symbol name cleanups after JEP 479 [v3] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 02:21:55 GMT, David Holmes wrote: >> After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: >> >> #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} >> #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} >> #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} >> #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} >> #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} >> #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} >> >> are all singletons and so the actual strings can just be inlined directly into the code that uses them. >> >> Testing: >> - GHA >> - Tiers 1-4 sanity >> - >> Thanks > > David Holmes has updated the pull request incrementally with two additional commits since the last revision: > > - Merge branch '8343703-jni-symbol' of github.com:dholmes-ora/jdk into 8343703-jni-symbol > - Fix indent Thanks Kim! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22380#issuecomment-2505139073 From dholmes at openjdk.org Thu Nov 28 02:27:47 2024 From: dholmes at openjdk.org (David Holmes) Date: Thu, 28 Nov 2024 02:27:47 GMT Subject: Integrated: 8343703: Symbol name cleanups after JEP 479 In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 06:36:44 GMT, David Holmes wrote: > After JEP 479 ([JDK-8339783](https://bugs.openjdk.org/browse/JDK-8339783) was integrated, the handling of certain symbol lookup code can be simplified. The old code needed to support 32-bit Windows, where names had a trailing `@`. When this special case now is removed, some streamlining is possible. Specifically these arrays: > > #define JNI_ONLOAD_SYMBOLS {"JNI_OnLoad"} > #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"} > #define JVM_ONLOAD_SYMBOLS {"JVM_OnLoad"} > #define AGENT_ONLOAD_SYMBOLS {"Agent_OnLoad"} > #define AGENT_ONUNLOAD_SYMBOLS {"Agent_OnUnload"} > #define AGENT_ONATTACH_SYMBOLS {"Agent_OnAttach"} > > are all singletons and so the actual strings can just be inlined directly into the code that uses them. > > Testing: > - GHA > - Tiers 1-4 sanity > - > Thanks This pull request has now been integrated. Changeset: 1a07d542 Author: David Holmes URL: https://git.openjdk.org/jdk/commit/1a07d542ec810282eb78653698d098a24b35686f Stats: 95 lines in 5 files changed: 7 ins; 49 del; 39 mod 8343703: Symbol name cleanups after JEP 479 Reviewed-by: kbarrett, amenkov ------------- PR: https://git.openjdk.org/jdk/pull/22380 From lmesnik at openjdk.org Thu Nov 28 02:51:43 2024 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 28 Nov 2024 02:51:43 GMT Subject: RFR: 8345148: Fix for JDK-8337317 is incomplete In-Reply-To: <3WOIoXjRlNGyRRgOe5N5aiw98AkJjLN4SHTZikRBYrg=.b011d890-bd7f-4da0-b933-0add4a8882dd@github.com> References: <3WOIoXjRlNGyRRgOe5N5aiw98AkJjLN4SHTZikRBYrg=.b011d890-bd7f-4da0-b933-0add4a8882dd@github.com> Message-ID: On Thu, 28 Nov 2024 01:30:58 GMT, Alex Menkov wrote: > Fix for JDK-8337317 (#20699) updated serviceability/jvmti/HiddenClass and serviceability/jvmti/VMObjectAlloc tests adding guards against JVMTI_ERROR_WRONG_PHASE errors, but missed to enable JVMTI_EVENT_VM_DEATH events. > This fix adds the missed part. > > Testing: hotspot/jtreg/serviceability/jvmti on all platforms > Manually verified test outputs contain "VMDeath" notification from VMDeath callback Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22426#pullrequestreview-2466231574 From asotona at openjdk.org Thu Nov 28 07:16:40 2024 From: asotona at openjdk.org (Adam Sotona) Date: Thu, 28 Nov 2024 07:16:40 GMT Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after JDK-83324714 In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> Message-ID: <-obkcdGi1-P2yLOYnCFIDo6z_ldLIDE90jbM847BRAU=.87b21383-ded7-4296-8d85-8b256dce0980@github.com> On Wed, 27 Nov 2024 23:10:15 GMT, Chen Liang wrote: > Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests. The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself. Now there is fewer than 100 `@enablePreview` in the `test` directory. > > To reviewers, there are some redundant changes and notes: > > - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API. > - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are: > - `BoundAttribute::payloadLen` for javac attribute tests > - Annotation reading/writing for javac annotation tests > - Line number changes to: > - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java > - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java > - Move from legacy jdk.internal.classfile to java.lang.classfile in: > - test/langtools/tools/javac/NoStringToLower.java and > - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java > - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java > > - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview. > > Testing: tier 1-5. Please inform me if any of these tests belong to higher tiers. I would give a go to all trivial removals of `@enablePreview` after a brief check the tests pass. However all the more complex changes potentially affecting various parts of the JDK infrastructure require deeper review and probably involve more reviewers. My recommendation for easier review would be to split this 360-files patch into a patch with trivial removals of `@enablePreview` and one or more patches focused on particular area. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2505408069 From liach at openjdk.org Thu Nov 28 07:47:37 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 28 Nov 2024 07:47:37 GMT Subject: RFR: 8334733: Remove obsolete @enablePreview from tests after JDK-83324714 In-Reply-To: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> References: <3FonQjV3pn1bynQC4dT-Mo2ttwRkmxuAkY0y9TbB0u8=.5ea6d9ce-068b-4d1d-81e1-548f59761641@github.com> Message-ID: On Wed, 27 Nov 2024 23:10:15 GMT, Chen Liang wrote: > Remove the redundant `@enablePreview` and `--enable-preview` flags for enabling ClassFile API in the tests. The remainder of these flags in all tests seem to serve preview APIs (such as ScopedValue) or language features (primitive pattern, module imports, etc.), or testing the enable preview flag itself. Now there is fewer than 100 `@enablePreview` in the `test` directory. > > To reviewers, there are some redundant changes and notes: > > - There's one security test that used `ModuleInfoWriter` that depends on ClassFile API. > - Removed unnecessary exports of `jdk.internal.classfile.impl`. Remaining uses are: > - `BoundAttribute::payloadLen` for javac attribute tests > - Annotation reading/writing for javac annotation tests > - Line number changes to: > - test/langtools/tools/javac/linenumbers/NestedLineNumberTest.java > - test/langtools/tools/javac/linenumbers/NullCheckLineNumberTest.java > - Move from legacy jdk.internal.classfile to java.lang.classfile in: > - test/langtools/tools/javac/NoStringToLower.java and > - test/langtools/tools/javac/T8003967/DetectMutableStaticFields.java > - Weird annotation processor behavior in test/langtools/tools/javac/annotations/parameter/ParameterAnnotations.java > > - Without preview and using explicit file name, the javac task fails; using the builder live AP object works both with and without preview. > > Testing: tier 1-5. Please inform me if any of these tests belong to higher tiers. I think the simple removal of `@enablePreview` already require multiple areas of engineers, so to involve a bit more changes to fix them throughoutly is fine; these are all test-only, so we can wait and this can go in after RDP1 began. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22420#issuecomment-2505451198 From kevinw at openjdk.org Thu Nov 28 09:57:42 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 09:57:42 GMT Subject: RFR: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands [v2] In-Reply-To: References: Message-ID: On Tue, 26 Nov 2024 21:31:52 GMT, Kevin Walls wrote: >> Remove redundant SecurityManager Permission references >> (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). > > Kevin Walls has updated the pull request incrementally with one additional commit since the last revision: > > Remove 'cause' Thanks for all the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/22315#issuecomment-2505697101 From kevinw at openjdk.org Thu Nov 28 09:57:42 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 09:57:42 GMT Subject: Integrated: 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 09:14:30 GMT, Kevin Walls wrote: > Remove redundant SecurityManager Permission references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). This pull request has now been integrated. Changeset: d33ad07c Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/d33ad07c32f23aee799750c9964ab26d0cbe56f4 Stats: 396 lines in 17 files changed: 0 ins; 380 del; 16 mod 8334493: Remove SecurityManager Permissions infrastructure from DiagnosticCommands Reviewed-by: lmesnik, alanb, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/22315 From alanb at openjdk.org Thu Nov 28 10:25:18 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 28 Nov 2024 10:25:18 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands Message-ID: Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. ------------- Commit messages: - Improve vthread_pollers output - Merge branch 'master' into JDK-8337199 - Initial commit Changes: https://git.openjdk.org/jdk/pull/22414/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337199 Stats: 405 lines in 11 files changed: 400 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22414/head:pull/22414 PR: https://git.openjdk.org/jdk/pull/22414 From liach at openjdk.org Thu Nov 28 10:25:18 2024 From: liach at openjdk.org (Chen Liang) Date: Thu, 28 Nov 2024 10:25:18 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands In-Reply-To: References: Message-ID: <7KzZ2pke6ZA4kpWBvLEXsAd1p2KflLWHZ0Jgq5uCC-M=.7abe6b24-fdad-4846-abdc-f75da15f06be@github.com> On Wed, 27 Nov 2024 15:59:17 GMT, Alan Bateman wrote: > Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. > > This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. > > The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 2: > 1: /* > 2: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 62: > 60: @Test > 61: void testVThreadScheduler() { > 62: // ensure default scheduler are timeout schedulers are initialized Suggestion: // ensure default scheduler and timeout schedulers are initialized test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 96: > 94: .shouldContain("Read I/O pollers:") > 95: .shouldContain("Write I/O pollers:") > 96: .shouldContain("[0] sun.nio.ch"); Suggestion: .shouldContain("[0] sun.nio.ch."); As unlikely as this is, I recommend always use a trailing separator for package names - there are corner cases like `java.lang.ref` vs `java.lang.reflect` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1861358889 PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1861358950 PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1861359883 From alanb at openjdk.org Thu Nov 28 10:25:18 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 28 Nov 2024 10:25:18 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands In-Reply-To: <7KzZ2pke6ZA4kpWBvLEXsAd1p2KflLWHZ0Jgq5uCC-M=.7abe6b24-fdad-4846-abdc-f75da15f06be@github.com> References: <7KzZ2pke6ZA4kpWBvLEXsAd1p2KflLWHZ0Jgq5uCC-M=.7abe6b24-fdad-4846-abdc-f75da15f06be@github.com> Message-ID: On Thu, 28 Nov 2024 00:04:53 GMT, Chen Liang wrote: >> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. >> >> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. >> >> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. > > test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 2: > >> 1: /* >> 2: * Copyright (c) 2023, 2024, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved. The feature + test were initially created in Oct 2023. It might look like a new test for main line but I think we are supposed to keep the original creation date. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1861620057 From sgehwolf at openjdk.org Thu Nov 28 13:27:46 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 28 Nov 2024 13:27:46 GMT Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics [v13] In-Reply-To: References: Message-ID: On Tue, 19 Nov 2024 13:37:25 GMT, Severin Gehwolf wrote: >> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. >> >> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). >> >> This patch addresses this issue by: >> >> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. >> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). >> >> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. >> >> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. >> >> Thoughts? >> >> Testing: >> >> - [x] GHA >> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems >> - [x] Some manual testing using systemd slices > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits: > > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Add exclusive access dirs directive for systemd tests > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Merge branch 'master' into jdk-8336881-metrics-systemd-slice > - Improve systemd slice test for non-root on cg v2 > - Fix unit tests > - Add JVM_HostActiveProcessorCount using JVM api > - ... and 28 more: https://git.openjdk.org/jdk/compare/23597361...b56fc7b7 Keep open bot. ------------- PR Comment: https://git.openjdk.org/jdk/pull/20280#issuecomment-2506124479 From kevinw at openjdk.org Thu Nov 28 14:24:38 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 14:24:38 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 15:59:17 GMT, Alan Bateman wrote: > Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. > > This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. > > The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 96: > 94: .shouldContain("Read I/O pollers:") > 95: .shouldContain("Write I/O pollers:") > 96: .shouldMatch("^\\[0\\] sun.nio.ch..+ \\[registered = [\\d]+, owner = .+\\]$"); Just a nit but are there three dots here in sun.nio.ch. that should literally match, so need the \\ and then the other two other dots with a plus sign, to match one or more characters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1862284094 From kevinw at openjdk.org Thu Nov 28 14:40:47 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 14:40:47 GMT Subject: RFR: 8344394: Remove SecurityManager and related calls from java.management.rmi [v3] In-Reply-To: References: Message-ID: On Fri, 22 Nov 2024 16:04:34 GMT, Daniel Fuchs wrote: >> Kevin Walls has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision: >> >> - Exeption handling feedback >> - Merge remote-tracking branch 'upstream/master' into 8344394_Management_rmi_post_sm >> - Remove last import sun.reflect.misc.ReflectUtil >> - imports >> - unwrap, exception handling >> - ReflectUtil removal >> - tweak >> - 8344394: Remove SecurityManager and related calls from java.management.rmi > > src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 32: > >> 30: import java.rmi.UnmarshalException; >> 31: import java.rmi.server.Unreferenced; >> 32: import java.security.PrivilegedActionException; > > should this be removed too? To be addressed in JDK-8345079 > src/java.management.rmi/share/classes/javax/management/remote/rmi/RMIConnectionImpl.java line 1286: > >> 1284: >> 1285: /** @throws UnsupportedOperationException {@inheritDoc} */ >> 1286: private Object doPrivilegedOperation(final int operation, > > Maybe rename "doPrivilegedOperation" into an overload of "doOperation" To be addressed in JDK-8345079 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1862310359 PR Review Comment: https://git.openjdk.org/jdk/pull/22270#discussion_r1862310553 From alanb at openjdk.org Thu Nov 28 15:54:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 28 Nov 2024 15:54:54 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: > Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. > > This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. > > The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Improve regex for matching poller String representation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22414/files - new: https://git.openjdk.org/jdk/pull/22414/files/c888b2fd..2e9619a1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22414/head:pull/22414 PR: https://git.openjdk.org/jdk/pull/22414 From alanb at openjdk.org Thu Nov 28 15:54:54 2024 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 28 Nov 2024 15:54:54 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 14:21:50 GMT, Kevin Walls wrote: >> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve regex for matching poller String representation > > test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 96: > >> 94: .shouldContain("Read I/O pollers:") >> 95: .shouldContain("Write I/O pollers:") >> 96: .shouldMatch("^\\[0\\] sun.nio.ch..+ \\[registered = [\\d]+, owner = .+\\]$"); > > Just a nit but are there three dots here in sun.nio.ch. that should literally match, so need the \\ > and then the other two other dots with a plus sign, to match one or more characters. Well spotted, these should be escaped although it not doing so won't impact the match here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1862420265 From kevinw at openjdk.org Thu Nov 28 16:01:46 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 16:01:46 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: <8OE5KUwMGefu8U3SipE5GBmABHn7BMsNzn5bpXL2CTg=.838462ff-bf15-4b7c-8072-0be01721411d@github.com> On Thu, 28 Nov 2024 15:54:54 GMT, Alan Bateman wrote: >> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. >> >> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. >> >> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Improve regex for matching poller String representation Marked as reviewed by kevinw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/22414#pullrequestreview-2468508549 From kevinw at openjdk.org Thu Nov 28 16:01:47 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 16:01:47 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: <3sSlC2KatxWRgj1LpAZxyTMGyxuQu7Ze_2pp-DByEQ0=.4dce1212-516f-4635-9f33-3aad7d78bf35@github.com> On Thu, 28 Nov 2024 15:52:01 GMT, Alan Bateman wrote: >> test/hotspot/jtreg/serviceability/dcmd/thread/VThreadCommandsTest.java line 96: >> >>> 94: .shouldContain("Read I/O pollers:") >>> 95: .shouldContain("Write I/O pollers:") >>> 96: .shouldMatch("^\\[0\\] sun.nio.ch..+ \\[registered = [\\d]+, owner = .+\\]$"); >> >> Just a nit but are there three dots here in sun.nio.ch. that should literally match, so need the \\ >> and then the other two other dots with a plus sign, to match one or more characters. > > Well spotted, these should be escaped although it not doing so won't impact the match here. Yes -it was almost the definitive bikeshedding comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22414#discussion_r1862430118 From kevinw at openjdk.org Thu Nov 28 17:19:44 2024 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 28 Nov 2024 17:19:44 GMT Subject: Integrated: 8344394: Remove SecurityManager and related calls from java.management.rmi In-Reply-To: References: Message-ID: On Wed, 20 Nov 2024 10:14:40 GMT, Kevin Walls wrote: > Remove redundant SecurityManager, AccessController references > (following on from JDK-8338411: Implement JEP 486: Permanently Disable the Security Manager). This pull request has now been integrated. Changeset: fd742af0 Author: Kevin Walls URL: https://git.openjdk.org/jdk/commit/fd742af0b76bdd7e6e14bd02ddc0d9bd921c90b2 Stats: 314 lines in 4 files changed: 74 ins; 200 del; 40 mod 8344394: Remove SecurityManager and related calls from java.management.rmi Reviewed-by: amenkov ------------- PR: https://git.openjdk.org/jdk/pull/22270 From duke at openjdk.org Thu Nov 28 19:26:46 2024 From: duke at openjdk.org (duke) Date: Thu, 28 Nov 2024 19:26:46 GMT Subject: Withdrawn: 8334234: NMT: Re-evaluate MallocMemory and VirtualMemory counter classes In-Reply-To: References: Message-ID: <8uFZNaQVmpbKBAFzUa8jIgyxQn2xtPms82i-_IlEFmg=.02ebc274-b41c-431b-ae5b-c3828c922dd2@github.com> On Mon, 12 Aug 2024 14:01:29 GMT, Robert Toyonaga wrote: > ### Summary > This PR splits up NMT memory counter classes into "live" and "flat" versions. Currently, the same classes are used and reused in both live (recording) and snapshotted (reporting) contexts. However, after counters have been shapshotted, they no longer need to be atomic or require things like peak updating. "Live" classes are now atomic and have methods needed for recording allocation/dealocation and updating peaks. "Flat" classes basically just hold data to later be reported, are not atomic, and only have methods for retrieving data. > > I've also made all counters in `LiveVirtualMemory` update atomically, when previously only the peaks in `VirtualMemory` were updated atomically. > > **Testing** > - tier1 > - jdk/test/hotspot/jtreg/gtest/NMTGtests.java > - jdk/test/jdk/jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20550 From dholmes at openjdk.org Fri Nov 29 04:51:48 2024 From: dholmes at openjdk.org (David Holmes) Date: Fri, 29 Nov 2024 04:51:48 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: On Thu, 28 Nov 2024 15:54:54 GMT, Alan Bateman wrote: >> Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. >> >> This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. >> >> The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Improve regex for matching poller String representation The two new `execute` methods differ only in the Symbol naming the method to call. Can we not at least define a static helper in the file so that we don't need to duplicate everything? ------------- PR Review: https://git.openjdk.org/jdk/pull/22414#pullrequestreview-2469079738 From alanb at openjdk.org Fri Nov 29 11:12:22 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 29 Nov 2024 11:12:22 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v3] In-Reply-To: References: Message-ID: > Adds `jcmd Thread.vthread_scheduler` to print the virtual thread scheduler and `jcmd Thread.vthread_pollers` to print the I/O pollers that support virtual threads doing blocking network I/O operations. > > This is a subset of the diagnostics that we've had in the loom repo for a long time. @larry-cable proposed a PR recently ([pull/22121](https://github.com/openjdk/jdk/pull/22121)) to bring a version of same into main line but it was based on an older proposal. This new PR supplants that effort. > > The jtreg failure handler is updated to execute Thread.vthread_scheduler, useful capture when a test fails or times out. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into JDK-8337199 - VThread*Dcmd::execute changes to use helper function - Improve regex for matching poller String representation - Improve vthread_pollers output - Merge branch 'master' into JDK-8337199 - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22414/files - new: https://git.openjdk.org/jdk/pull/22414/files/2e9619a1..ea7df830 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22414&range=01-02 Stats: 2120 lines in 75 files changed: 842 ins; 1052 del; 226 mod Patch: https://git.openjdk.org/jdk/pull/22414.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22414/head:pull/22414 PR: https://git.openjdk.org/jdk/pull/22414 From alanb at openjdk.org Fri Nov 29 11:12:23 2024 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 29 Nov 2024 11:12:23 GMT Subject: RFR: 8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands [v2] In-Reply-To: References: Message-ID: On Fri, 29 Nov 2024 04:48:57 GMT, David Holmes wrote: > The two new `execute` methods differ only in the Symbol naming the method to call. Can we not at least define a static helper in the file so that we don't need to duplicate everything? Okay, esp. as we'll likely add more. At some point I think Larry is doing to replace all this with other infrastructure for commands in Java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22414#issuecomment-2507590830 From wkemper at openjdk.org Fri Nov 29 16:00:52 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 29 Nov 2024 16:00:52 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v12] In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 533 commits: - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux - Problem list Shenandoah TestAllocOutOfMemory on ppc64 - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - 8344985: GenShen: Refactor arraycopy barrier for generational mode Reviewed-by: shade - Remove incomplete test case - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - Merge - 8344779: GenShen: Consolidate shared heap region closures into one header Reviewed-by: kdnilsen, ysr - 8344797: GenShen: Update and rename confusing method Reviewed-by: ysr, kdnilsen - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux - ... and 523 more: https://git.openjdk.org/jdk/compare/a80ccf2c...f29d741c ------------- Changes: https://git.openjdk.org/jdk/pull/21273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21273&range=11 Stats: 22878 lines in 229 files changed: 21122 ins; 913 del; 843 mod Patch: https://git.openjdk.org/jdk/pull/21273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21273/head:pull/21273 PR: https://git.openjdk.org/jdk/pull/21273 From shade at openjdk.org Fri Nov 29 16:57:03 2024 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 29 Nov 2024 16:57:03 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v12] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 29 Nov 2024 16:00:52 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 533 commits: > > - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux > - Problem list Shenandoah TestAllocOutOfMemory on ppc64 > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade > - Remove incomplete test case > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - Merge > - 8344779: GenShen: Consolidate shared heap region closures into one header > > Reviewed-by: kdnilsen, ysr > - 8344797: GenShen: Update and rename confusing method > > Reviewed-by: ysr, kdnilsen > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - ... and 523 more: https://git.openjdk.org/jdk/compare/a80ccf2c...f29d741c Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2470311607 From rkennke at openjdk.org Fri Nov 29 17:58:01 2024 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 29 Nov 2024 17:58:01 GMT Subject: RFR: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) [v12] In-Reply-To: References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Fri, 29 Nov 2024 16:00:52 GMT, William Kemper wrote: >> This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. > > William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 533 commits: > > - Merge remote-tracking branch 'jdk/master' into great-genshen-pr-redux > - Problem list Shenandoah TestAllocOutOfMemory on ppc64 > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - 8344985: GenShen: Refactor arraycopy barrier for generational mode > > Reviewed-by: shade > - Remove incomplete test case > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - Merge > - 8344779: GenShen: Consolidate shared heap region closures into one header > > Reviewed-by: kdnilsen, ysr > - 8344797: GenShen: Update and rename confusing method > > Reviewed-by: ysr, kdnilsen > - Merge remote-tracking branch 'shenandoah/master' into great-genshen-pr-redux > - ... and 523 more: https://git.openjdk.org/jdk/compare/a80ccf2c...f29d741c Marked as reviewed by rkennke (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/21273#pullrequestreview-2470373501 From stooke at openjdk.org Fri Nov 29 20:10:53 2024 From: stooke at openjdk.org (Simon Tooke) Date: Fri, 29 Nov 2024 20:10:53 GMT Subject: RFR: 8319875: Add macOS implementation for jcmd System.map [v9] In-Reply-To: References: Message-ID: > This is a port of #16301 to macOS. > > System.map and System.dump_map are implemented using the macOS API and provide roughly the same information in the same format. Most of the heavy lifting was implemented by @tstuefe in https://github.com/openjdk/jdk/pull/16301 - this PR adds the macOS implementation and enables the common code for macOS 64 bit. > > The System.map tests are also reworked to be cleaner for the three implementations. > > [sample output using G1GC](https://github.com/user-attachments/files/17558064/g1_map.txt) > [sample output using ZGC](https://github.com/user-attachments/files/17558067/zgc_map.txt) Simon Tooke has updated the pull request incrementally with one additional commit since the last revision: change format strings to display all digits properly ------------- Changes: - all: https://git.openjdk.org/jdk/pull/20953/files - new: https://git.openjdk.org/jdk/pull/20953/files/64a1f12a..38021267 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20953&range=07-08 Stats: 13 lines in 1 file changed: 10 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/20953.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20953/head:pull/20953 PR: https://git.openjdk.org/jdk/pull/20953 From wkemper at openjdk.org Fri Nov 29 20:56:04 2024 From: wkemper at openjdk.org (William Kemper) Date: Fri, 29 Nov 2024 20:56:04 GMT Subject: Integrated: 8337511: Implement JEP 404: Generational Shenandoah (Experimental) In-Reply-To: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> References: <8N7AiGx8AZc-d6MgBEKVw5R-qk8J_1FBZH-SbzmydGg=.d7ac9a04-5fa3-47e3-8d24-c8efd28a51f7@github.com> Message-ID: On Mon, 30 Sep 2024 22:02:45 GMT, William Kemper wrote: > This PR merges JEP 404, a generational mode for the Shenandoah garbage collector. The JEP can be viewed here: https://openjdk.org/jeps/404. We would like to target JDK24 with this PR. This pull request has now been integrated. Changeset: 28ae281b Author: William Kemper URL: https://git.openjdk.org/jdk/commit/28ae281b42cd00f471e275db544a5d23a42df59c Stats: 22878 lines in 229 files changed: 21122 ins; 913 del; 843 mod 8337511: Implement JEP 404: Generational Shenandoah (Experimental) Co-authored-by: Kelvin Nilsen Co-authored-by: Y. Srinivas Ramakrishna Co-authored-by: Bernd Mathiske Co-authored-by: Martin Doerr Co-authored-by: Fei Yang Reviewed-by: rkennke, shade, phh ------------- PR: https://git.openjdk.org/jdk/pull/21273 From schernyshev at openjdk.org Sat Nov 30 00:30:02 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Sat, 30 Nov 2024 00:30:02 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v8] In-Reply-To: References: Message-ID: > Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. > > The relevant /proc/self/mountinfo line is > > > 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct > > > /proc/self/cgroup: > > > 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c > > > Here, Java runs inside containerized process that is being moved cgroups due to load balancing. > > Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 > It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). > > The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: > > Example input > > _root = "/a" > cgroup_path = "/a/b" > _mount_point = "/sys/fs/cgroup/cpu,cpuacct" > > > result _path > > "/sys/fs/cgroup/cpu,cpuacct/b" > > > Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: > > > ... > /proc/pid/cgroup (since Linux 2.6.24) > This file describes control groups to which the process > with the corresponding PID belongs. The displayed > information differs for cgroups version 1 and version 2 > hierarchies. > For each cgroup hierarchy of which the process is a > member, there is one entry containing three colon- > separated fields: > > hierarchy-ID:controller-list:cgroup-path > > For example: > > 5:cpuacct,cpu,cpuset:/daemons > ... > [3] This field contains the pathname of the control group > in the hierarchy to which the process belongs. This > pathname is relative to the mount point of the > hierarchy. > > > This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been > > > /sys/fs/cgroup/cpu,cpuacct/a/b > > > Howe... Sergey Chernyshev has updated the pull request incrementally with three additional commits since the last revision: - update cgroup v1 in metrics - Apply suggestions from code review Co-authored-by: Severin Gehwolf - updated test (path is reduced) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21808/files - new: https://git.openjdk.org/jdk/pull/21808/files/ec5fef0a..60f1eea3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=06-07 Stats: 204 lines in 11 files changed: 143 ins; 27 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/21808.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808 PR: https://git.openjdk.org/jdk/pull/21808 From schernyshev at openjdk.org Sat Nov 30 00:30:02 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Sat, 30 Nov 2024 00:30:02 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v6] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 10:18:24 GMT, Severin Gehwolf wrote: >> Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: >> >> adjust path suffix in cgroup (v1) version specific code, when root != cgroup > > src/hotspot/os/linux/cgroupUtil_linux.cpp line 70: > >> 68: os::free(limit_cg_path); // handles nullptr >> 69: limit_cg_path = os::strdup(cg_path); >> 70: } > > We can avoid the duplicate copy of the original cgroup path, which is already captured in `orig` by using: > > > jlong lowest_limit = limit < 0 ? phys_mem : limit; > julong orig_limit = ((julong)lowest_limit) != phys_mem ? lowest_limit : phys_mem; > > > And on line 91 we change the condition from: > > > if ((julong)lowest_limit != phys_mem) { > > > to: > > > if ((julong)lowest_limit != orig_limit) { Thanks! Accepted. > src/hotspot/os/linux/cgroupUtil_linux.cpp line 129: > >> 127: lowest_limit = cpus; >> 128: os::free(limit_cg_path); // handles nullptr >> 129: limit_cg_path = os::strdup(cg_path); > > Same here with the extra allocation of `cg_path`; done. > src/hotspot/os/linux/cgroupV2Subsystem_linux.cpp line 322: > >> 320: log_warning(os, container)("Cgroup v2 path at [%s] is [%s], cgroup limits can be wrong.", >> 321: mount_path, cgroup_path); >> 322: } > > Why the cast to `char*`? > > We should probably move this warning to `CgroupUtil::adjust_controller`, right before we've determined that we actually need to adjust. I wonder, though, if we should just print the warning and set the cgroup_path to `/` and return early. Otherwise, path adjustment will run with no different result. Removed extra (char*) cast. > We should probably move this warning to `CgroupUtil::adjust_controller`, right before we've determined that we actually need to adjust. I wonder, though, if we should just print the warning and set the cgroup_path to `/` and return early. Otherwise, path adjustment will run with no different result. "../" only appears in corner case with cgroupns=private and the process moved to the outer group. In that specific case we should avoid concatenating with whatever starts with "../". > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 39: > >> 37: * @modules java.base/jdk.internal.platform >> 38: * @library /test/lib >> 39: * @build jdk.test.whitebox.WhiteBox CheckOperatingSystemMXBean > > `CheckOperatingSystemMXBean` seems unused. fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1863595789 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1863596132 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1863607722 PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1863608362 From sgehwolf at openjdk.org Sat Nov 30 00:30:03 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Sat, 30 Nov 2024 00:30:03 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com> <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizx pQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com> Message-ID: On Wed, 27 Nov 2024 10:56:57 GMT, Sergey Chernyshev wrote: >>> Version specific code can be had in `set_subsystem_path()` of the corresponding impl (like an earlier version of your patch). `lowest_limit` and `limit_cg_path` fixes are version agnostic and can and should be fixed in `CgroupUtil::adjust_controller`. >> >> Done. Please see the updated PR. > >> Done. Please see the updated PR. > > The metrics part still needs the update - in the cgroup version specific `setPath()`. Right. I'm still not convinced this extra reduction buys us much. The adjust controller logic will handle it if kept as is in the Metrics version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860465637 From schernyshev at openjdk.org Sat Nov 30 00:30:03 2024 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Sat, 30 Nov 2024 00:30:03 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com> <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizx pQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com> Message-ID: On Wed, 27 Nov 2024 11:07:18 GMT, Severin Gehwolf wrote: > Right. I'm still not convinced this extra reduction buys us much. The adjust controller logic will handle it if kept as is in the Metrics version. The adjust controller logic won't handle it, because it reduces the path from child to parent. It's goal is to locate the smallest limit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1863625245 From sgehwolf at openjdk.org Sat Nov 30 00:30:03 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Sat, 30 Nov 2024 00:30:03 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3] In-Reply-To: References: <1mQxBTLUhFT0I287gSUPH_4WC5wdMNFWOXVcOhVAiZM=.beb33b86-3f8c-4f1f-a8bd-edc39ba02e2d@github.com> <1dAge8JwrDA2pyHNwDO7IChqlVclZEe5UeZN3A7gClI=.5f50fd42-27e0-41f0-b263-0c2cba0e32ad@github.com> <5g41x8oOZCIjAyXAUby27i4rpdhKkX4kizx pQmejUGA=.cdbc9144-2b60-4cfd-956e-d4f2086e31e5@github.com> Message-ID: On Fri, 29 Nov 2024 14:47:13 GMT, Sergey Chernyshev wrote: > > Right. I'm still not convinced this extra reduction buys us much. The adjust controller logic will handle it if kept as is in the Metrics version. > > The adjust controller logic won't handle it, because it reduces the path from child to parent. It's goal is to locate the smallest limit. It's goal is to find the path for a specific controller that has the lowest limit and keeps that path for that controller for the rest of the run-time of the JVM. Consider a case where this reduction currently happens in `set_subsystem_path()`. Instead of the manual work of setting it to a path where the directory actually exists we set it to `/`. In the cloudflare case we'd end up with a subsystem path of `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c`. Since the cgroup_path != _root we trigger path adjustment increasing the chance to detect any lower limit in any of the paths down to the mount point. By doing so **and** there is a lower limit in the hierarchy we know the path exists as well and that is being used from then on. So if `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden` existed and has a limit it would be used. I thought this is the reason why cg v2 didn't need the same fix when `--cgroupns=host` is used. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1863797758 From sgehwolf at openjdk.org Sat Nov 30 00:30:03 2024 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Sat, 30 Nov 2024 00:30:03 GMT Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v6] In-Reply-To: References: Message-ID: On Wed, 27 Nov 2024 09:11:22 GMT, Sergey Chernyshev wrote: >> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems. >> >> The relevant /proc/self/mountinfo line is >> >> >> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct >> >> >> /proc/self/cgroup: >> >> >> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c >> >> >> Here, Java runs inside containerized process that is being moved cgroups due to load balancing. >> >> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72 >> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). >> >> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: >> >> Example input >> >> _root = "/a" >> cgroup_path = "/a/b" >> _mount_point = "/sys/fs/cgroup/cpu,cpuacct" >> >> >> result _path >> >> "/sys/fs/cgroup/cpu,cpuacct/b" >> >> >> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states: >> >> >> ... >> /proc/pid/cgroup (since Linux 2.6.24) >> This file describes control groups to which the process >> with the corresponding PID belongs. The displayed >> information differs for cgroups version 1 and version 2 >> hierarchies. >> For each cgroup hierarchy of which the process is a >> member, there is one entry containing three colon- >> separated fields: >> >> hierarchy-ID:controller-list:cgroup-path >> >> For example: >> >> 5:cpuacct,cpu,cpuset:/daemons >> ... >> [3] This field contains the pathname of the control group >> in the hierarchy to which the process belongs. This >> pathname is relative to the mount point of the >> hierarchy. >> >> >> This explicitly states the "pathname is relative t... > > Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision: > > adjust path suffix in cgroup (v1) version specific code, when root != cgroup test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 481: > 479: assertNotNull("Controller path should not have been null", actualPath); > 480: String expectedPath = expectedMountPoint + cpuInfo.getCgroupPath(); > 481: assertEquals("Should be equal to the mount point path", expectedPath, actualPath); Suggestion: assertEquals("Should be equal to the mount point with cg path appended", expectedPath, actualPath); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1860461756