From alanb at openjdk.java.net Wed Jun 1 06:04:14 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Wed, 1 Jun 2022 06:04:14 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v3] In-Reply-To: References: Message-ID: > This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: > > 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) > 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) > > The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Fixed another typo in comment - Merge - Fix typos in comments - Allowing linking without intrinsic stub, contributed-by: rehn - Continuation clinit should fail if no continuations support - Fix merge issue with test - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION - Update - Expend test coverage - Merge - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6 ------------- Changes: https://git.openjdk.java.net/jdk/pull/8939/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8939&range=02 Stats: 747 lines in 72 files changed: 574 ins; 53 del; 120 mod Patch: https://git.openjdk.java.net/jdk/pull/8939.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8939/head:pull/8939 PR: https://git.openjdk.java.net/jdk/pull/8939 From dholmes at openjdk.java.net Wed Jun 1 06:29:29 2022 From: dholmes at openjdk.java.net (David Holmes) Date: Wed, 1 Jun 2022 06:29:29 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v3] In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 06:04:14 GMT, Alan Bateman wrote: >> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: >> >> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) >> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) >> >> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Fixed another typo in comment > - Merge > - Fix typos in comments > - Allowing linking without intrinsic stub, contributed-by: rehn > - Continuation clinit should fail if no continuations support > - Fix merge issue with test > - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION > - Update > - Expend test coverage > - Merge > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6 src/java.base/share/classes/java/lang/Thread.java line 742: > 740: * @param name thread name, can be null > 741: * @param characteristics thread characteristics > 742: * @param bound true when bound to an OS thread Nit: s/OS/VM/ ? ------------- PR: https://git.openjdk.java.net/jdk/pull/8939 From sgehwolf at openjdk.java.net Wed Jun 1 09:27:22 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Wed, 1 Jun 2022 09:27:22 GMT Subject: RFR: 8287007: [cgroups] Consistently use stringStream throughout parsing code Message-ID: Please review this cleanup change in the cgroup subsystem which used to use hard-coded stack allocated buffers for concatenating strings in memory. We can use `stringStream` instead which doesn't have the issue of hard-coding maximum lengths (and related checks) and makes the code, thus, easier to read. While at it, I've written basic `gtests` verifying current behaviour (and the same for the JDK code). From a functionality point of view this is a no-op (modulo the one bug in the substring case which seems to be there since day one). I'd prefer if we could defer any change in functionality to a separate bug as this is meant to only use stringStream throughout the cgroups code. Testing: - [x] Container tests on Linux x86_64 cgroups v1 and cgroups v2 - [x] Added tests, which I've verified also pass before the stringStream change Thoughts? ------------- Commit messages: - Add cgroups v2 java test - use stringStream in cgroups v2 - Add gtest for cgroups v2 code path - 8287007: [cgroups] Consistently use stringStream throughout parsing code - 8287007: [cgroups] Consistently use stringStream throughout parsing code Changes: https://git.openjdk.java.net/jdk/pull/8969/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8969&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287007 Stats: 270 lines in 5 files changed: 235 ins; 19 del; 16 mod Patch: https://git.openjdk.java.net/jdk/pull/8969.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8969/head:pull/8969 PR: https://git.openjdk.java.net/jdk/pull/8969 From daniel.daugherty at oracle.com Wed Jun 1 17:43:59 2022 From: daniel.daugherty at oracle.com (daniel.daugherty at oracle.com) Date: Wed, 1 Jun 2022 13:43:59 -0400 Subject: Concurrent heap monitoring In-Reply-To: <1653689549469.91000@amazon.com> References: <1653083191904.40109@amazon.com> <1653689549469.91000@amazon.com> Message-ID: <857be0fe-c8c9-fcaf-d5ed-28a2655252e6@oracle.com> Hi William, How does this proposal interact with JVM/TI or with: ??? JEP 331: Low-Overhead Heap Profiling http://openjdk.java.net/jeps/331 ??? JDK-8171119 JEP 331: Low-Overhead Heap Profiling https://bugs.openjdk.java.net/browse/JDK-8171119 ??? JDK-8203394 Implementation of JEP 331: Low-Overhead Heap Profiling https://bugs.openjdk.java.net/browse/JDK-8203394 Dan On 5/27/22 6:12 PM, Kemper, William wrote: > > The feature is independent from GCs, but it is aware of GC activity > and it may be preempted by the GC at any time (which causes the loss > of any work in progress). We have only tested it with G1, but we > expect it to work with Parallel and Serial collectors. It is meant to > stay out of the way of GC, but?it is not yet aware of the?concurrent > phases of G1, Shenandoah and ZGC, so there is more work to be done here. > > > Thank you for the questions, > > William > > > ------------------------------------------------------------------------ > *From:* Volker Simonis > *Sent:* Saturday, May 21, 2022 12:49 AM > *To:* Kemper, William > *Cc:* serviceability-dev > *Subject:* RE: [EXTERNAL]Concurrent heap monitoring > > *CAUTION*: This email originated from outside of the organization. Do > not click links or open attachments unless you can confirm the sender > and know the content is safe. > > > This sounds very interesting. Does this feature work with every GC or? > does the implementation depend on specific GCs (and if the latter, > which GCs does your prototype currently support). > > Kemper, William schrieb am Fr., 20. Mai 2022, 23:46: > > Taking a heap dump is a stop the world event. Garbage collection > events can provide heap utilization information only after a cycle > completes. We've found that detailed heap occupancy data (such as > heap inspections provide) are too expensive to use for production > monitoring.? Similarly, we find that heap statistics generated > from collection cycles?may come too late and may not provide > enough detail (young collections do not reflect the state of the > old generation). We have developed a /prototype/ feature to > provide detailed heap metrics /concurrently//, without barriers./ > It therefore provides only an estimate as changes to the object > graph may cause it to miss objects. We would like to hear the > thoughts of serviceability experts on such a thing. It is only at > the proof of concept phase, but it is able to run popular > benchmarks (specjbb, dacapo) with minimal overhead and the > estimates are sufficiently accurate for our use cases (monitoring > heap and object?growth rates). > > > Thank you for reading, > > William > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dcubed at openjdk.java.net Wed Jun 1 19:03:33 2022 From: dcubed at openjdk.java.net (Daniel D.Daugherty) Date: Wed, 1 Jun 2022 19:03:33 GMT Subject: RFR: 8286960: Test serviceability/jvmti/vthread/SuspendResume2 crashed: missing ThreadsListHandle in calling context In-Reply-To: References: Message-ID: On Wed, 25 May 2022 07:23:36 GMT, Serguei Spitsyn wrote: > A part of this issue was contributed with the following changeset: > > commit ea23e7333e03abb4aca3e9f3854bab418a4b70e2 > Author: Daniel D. Daugherty <[dcubed at openjdk.org](mailto:dcubed at openjdk.org)> > Date: Mon Nov 8 14:45:04 2021 +0000 > > 8249004: Reduce ThreadsListHandle overhead in relation to direct handshakes > Reviewed-by: coleenp, sspitsyn, dholmes, rehn > > The following change in `src/hotspot/share/runtime/thread.cpp` added new assert: > > bool JavaThread::java_suspend() { > - ThreadsListHandle tlh; > - if (!tlh.includes(this)) { > - log_trace(thread, suspend)("JavaThread:" INTPTR_FORMAT " not on ThreadsList, no suspension", p2i(this)); > - return false; > - } > + guarantee(Thread::is_JavaThread_protected(this, /* checkTLHOnly */ true), > + "missing ThreadsListHandle in calling context."); > return this->handshake_state()->suspend(); > } > > This new assert misses a check for target thread as being current `JavaThread`. > > Also, the JVMTI SuspendThread is protected with TLH: > > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > ThreadsListHandle tlh(current); <= TLS defined here!!! > > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > > > However, it is possible that a new carrier thread (and an associated `JavaThread`) can be created after the `TLH` was set and the target virtual thread can be mounted on new carrier thread. Then target virtual thread will be associated with newly created `JavaThread` which is unprotected by the TLH. > The right way to be protected from this situation it is to prevent mount state transitions with `JvmtiVTMSTransitionDisabler` before the TLH is set as in the change below: > > > @@ -929,13 +929,13 @@ JvmtiEnv::GetAllThreads(jint* threads_count_ptr, jthread** threads_ptr) { > jvmtiError > JvmtiEnv::SuspendThread(jthread thread) { > JavaThread* current = JavaThread::current(); > - ThreadsListHandle tlh(current); > > jvmtiError err; > JavaThread* java_thread = NULL; > oop thread_oop = NULL; > { > JvmtiVTMSTransitionDisabler disabler(true); > + ThreadsListHandle tlh(current); > > err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread, &thread_oop); > if (err != JVMTI_ERROR_NONE) { > > > > This problem exist in all JVMTI Suspend functions: > `SuspendThread`, `SuspendThreadList` and `SuspendAllVirtualThreads`. Before Loom, there was a TLH in the outer JVM/TI SuspendThread() entry point so the current thread was already protected. Here's the relevant code from build/macosx-x86_64-normal-server-release/hotspot/variant-server/gensrc/jvmtifiles/jvmtiEnter.cpp in JDK18: static jvmtiError JNICALL jvmti_SuspendThread(jvmtiEnv* env, jthread thread) { #if !INCLUDE_JVMTI return JVMTI_ERROR_NOT_AVAILABLE; #else if(!JvmtiEnv::is_vm_live()) { return JVMTI_ERROR_WRONG_PHASE; } Thread* this_thread = Thread::current_or_null(); if (this_thread == NULL || !this_thread->is_Java_thread()) { return JVMTI_ERROR_UNATTACHED_THREAD; } JavaThread* current_thread = JavaThread::cast(this_thread); MACOS_AARCH64_ONLY(ThreadWXEnable __wx(WXWrite, current_thread)); ThreadInVMfromNative __tiv(current_thread); VM_ENTRY_BASE(jvmtiError, jvmti_SuspendThread , current_thread) debug_only(VMNativeEntryWrapper __vew;) PreserveExceptionMark __em(this_thread); JvmtiEnv* jvmti_env = JvmtiEnv::JvmtiEnv_from_jvmti_env(env); if (!jvmti_env->is_valid()) { return JVMTI_ERROR_INVALID_ENVIRONMENT; } if (jvmti_env->get_capabilities()->can_suspend == 0) { return JVMTI_ERROR_MUST_POSSESS_CAPABILITY; } jvmtiError err; JavaThread* java_thread = NULL; ThreadsListHandle tlh(this_thread); if (thread == NULL) { java_thread = current_thread; } else { err = JvmtiExport::cv_external_thread_to_JavaThread(tlh.list(), thread, &java_thread, NULL); if (err != JVMTI_ERROR_NONE) { return err; } } err = jvmti_env->SuspendThread(java_thread); return err; #endif // INCLUDE_JVMTI } so it was definitely my intent that the current thread be protected by the TLH that was in the entry code. Yes, that protection is not needed, but that's the way I implemented it when is_JavaThread_protected_by_TLH() was added to the system. ------------- PR: https://git.openjdk.java.net/jdk/pull/8878 From aturbanov at openjdk.java.net Wed Jun 1 20:44:04 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Wed, 1 Jun 2022 20:44:04 GMT Subject: RFR: 8287695: Use String.contains() instead of String.indexOf() in jdk.hotspot.agent Message-ID: `String.contains` was introduced in Java 5. Some code in jdk.hotspot.agent still uses old approach with `String.indexOf` to check if String contains specified substring. I propose to migrate such usages. Makes code shorter and easier to read. ------------- Commit messages: - [PATCH] Use String.contains() instead of String.indexOf() in jdk.hotspot.agent Changes: https://git.openjdk.java.net/jdk/pull/8966/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8966&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287695 Stats: 19 lines in 4 files changed: 0 ins; 7 del; 12 mod Patch: https://git.openjdk.java.net/jdk/pull/8966.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8966/head:pull/8966 PR: https://git.openjdk.java.net/jdk/pull/8966 From cjplummer at openjdk.java.net Wed Jun 1 21:03:33 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Wed, 1 Jun 2022 21:03:33 GMT Subject: RFR: 8287695: Use String.contains() instead of String.indexOf() in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 07:52:50 GMT, Andrey Turbanov wrote: > `String.contains` was introduced in Java 5. > Some code in jdk.hotspot.agent still uses old approach with `String.indexOf` to check if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to read. Please make sure you run the SA tests. ------------- Marked as reviewed by cjplummer (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8966 From alanb at openjdk.java.net Thu Jun 2 06:41:30 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 2 Jun 2022 06:41:30 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v3] In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 06:26:23 GMT, David Holmes wrote: >> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Fixed another typo in comment >> - Merge >> - Fix typos in comments >> - Allowing linking without intrinsic stub, contributed-by: rehn >> - Continuation clinit should fail if no continuations support >> - Fix merge issue with test >> - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION >> - Update >> - Expend test coverage >> - Merge >> - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6 > > src/java.base/share/classes/java/lang/Thread.java line 742: > >> 740: * @param name thread name, can be null >> 741: * @param characteristics thread characteristics >> 742: * @param bound true when bound to an OS thread > > Nit: s/OS/VM/ ? I think it would be confusing to use "VM" here. The intention is that "true" means the virtual thread will be bound to an OS thread once it has started. Yes, technically it's whatever the VM implements but I think that is too much to try to explain in the parameter description. ------------- PR: https://git.openjdk.java.net/jdk/pull/8939 From alanb at openjdk.java.net Thu Jun 2 09:07:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 2 Jun 2022 09:07:32 GMT Subject: Integrated: 8287496: Alternative virtual thread implementation that maps to OS thread In-Reply-To: References: Message-ID: On Sun, 29 May 2022 14:46:39 GMT, Alan Bateman wrote: > This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: > > 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) > 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) > > The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. This pull request has now been integrated. Changeset: 6ff2d89e Author: Alan Bateman URL: https://git.openjdk.java.net/jdk/commit/6ff2d89ea11934bb13c8a419e7bad4fd40f76759 Stats: 747 lines in 72 files changed: 574 ins; 53 del; 120 mod 8287496: Alternative virtual thread implementation that maps to OS thread Reviewed-by: rehn, mchung ------------- PR: https://git.openjdk.java.net/jdk/pull/8939 From shade at openjdk.java.net Thu Jun 2 09:58:37 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 2 Jun 2022 09:58:37 GMT Subject: RFR: 8287496: Alternative virtual thread implementation that maps to OS thread [v3] In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 06:04:14 GMT, Alan Bateman wrote: >> This patch adds an alternative virtual thread implementation where each virtual thread is backed by an OS thread. It doesn't scale but it can be used by ports that don't have continuations support in the VM. Aside from scalability, the lack of continuations support means: >> >> 1. JVM TI is not supported when running with --enable-preview (the JVM TI spec allows for this) >> 2. jshell --enable-preview can't be used (as jshell uses the debugger APIs and so needs JVM TI) >> >> The VM option "VMContinuations" is added as an experimental option so it can be used by tests. A number of tests are changed to re-run with -XX:-VMContinuations. A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. > > Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Fixed another typo in comment > - Merge > - Fix typos in comments > - Allowing linking without intrinsic stub, contributed-by: rehn > - Continuation clinit should fail if no continuations support > - Fix merge issue with test > - Change VMContinuations to be experimental option, ensure JNI GetEnv returns EVERSION > - Update > - Expend test coverage > - Merge > - ... and 1 more: https://git.openjdk.java.net/jdk/compare/3deb58a8...a5c06cb6 > A new jtreg property is added so that tests that need the underlying VM support to be present can use "@requires vm.continuations" in the test description. A follow-up change would be to add "@requires vm.continuations" to the ~70 serviceability/jvmti/vthread that run with preview features enabled. See #8990. ------------- PR: https://git.openjdk.java.net/jdk/pull/8939 From aturbanov at openjdk.java.net Thu Jun 2 10:00:34 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 2 Jun 2022 10:00:34 GMT Subject: RFR: 8287695: Use String.contains() instead of String.indexOf() in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Wed, 1 Jun 2022 20:59:41 GMT, Chris Plummer wrote: > Please make sure you run the SA tests. This one, `test/hotspot/jtreg/serviceability` right? ------------- PR: https://git.openjdk.java.net/jdk/pull/8966 From shade at openjdk.java.net Thu Jun 2 10:01:13 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 2 Jun 2022 10:01:13 GMT Subject: RFR: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 Message-ID: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the alternative Loom implementation that can be used by ports as the fallback. That fallback does not support JVMTI entirely, so lots of tests fail. Some JVMTI is still supported, so cutting off at `@requires vm.jvmti` seems too broad. They should be predicated with `@requires vm.continuations` to be skipped when fallback is used. This also allows reverting x86_32 problemlist exclusions, which serves a proof of concept that [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) indeed works. Additional testing: - [x] Linux x86_32 fastdebug, `serviceability/jvmti` works, many tests skipped - [ ] Linux x86_64 fastdebug, `serviceability/jvmti` still works, with all current tests executing ------------- Commit messages: - Only trim down JVMTI tests from x86_32 problemlists - Fix Changes: https://git.openjdk.java.net/jdk/pull/8990/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8990&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287726 Stats: 138 lines in 69 files changed: 69 ins; 69 del; 0 mod Patch: https://git.openjdk.java.net/jdk/pull/8990.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8990/head:pull/8990 PR: https://git.openjdk.java.net/jdk/pull/8990 From alanb at openjdk.java.net Thu Jun 2 11:07:31 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 2 Jun 2022 11:07:31 GMT Subject: RFR: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 In-Reply-To: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> References: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> Message-ID: On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote: > [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the alternative Loom implementation that can be used by ports as the fallback. That fallback does not support JVMTI entirely, so lots of tests fail. Some JVMTI is still supported, so cutting off at `@requires vm.jvmti` seems too broad. They should be predicated with `@requires vm.continuations` to be skipped when fallback is used. > > This also allows reverting relevant x86_32 problemlist exclusions. > > Additional testing: > - [x] Linux x86_32 fastdebug, `serviceability/jvmti` works, many tests skipped > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` still works, with all current tests executing I expect you can unexclude the runtime/* tests from this section too. Also the same section in test/jdk/ProblemList.txt that excludes the tests on x86_32 can be cleaned up too, maybe a separate PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8990 From shade at openjdk.java.net Thu Jun 2 11:11:34 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 2 Jun 2022 11:11:34 GMT Subject: RFR: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 In-Reply-To: References: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> Message-ID: On Thu, 2 Jun 2022 11:05:30 GMT, Alan Bateman wrote: > I expect you can unexclude the runtime/* tests from this section too. Also the same section in test/jdk/ProblemList.txt that excludes the tests on x86_32 can be cleaned up too, maybe a separate PR. Yes, in separate PR. In this PR, I want to deal with JVMTI tests specifically. We can take JVMTI tests off the problemlist exactly because of `@requires vm.continuations` added in this PR. ------------- PR: https://git.openjdk.java.net/jdk/pull/8990 From alanb at openjdk.java.net Thu Jun 2 11:37:32 2022 From: alanb at openjdk.java.net (Alan Bateman) Date: Thu, 2 Jun 2022 11:37:32 GMT Subject: RFR: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 In-Reply-To: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> References: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> Message-ID: On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote: > [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the alternative Loom implementation that can be used by ports as the fallback. That fallback does not support JVMTI entirely, so lots of tests fail. Some JVMTI is still supported, so cutting off at `@requires vm.jvmti` seems too broad. They should be predicated with `@requires vm.continuations` to be skipped when fallback is used. > > This also allows reverting relevant x86_32 problemlist exclusions. > > Additional testing: > - [x] Linux x86_32 fastdebug, `serviceability/jvmti` works, many tests skipped > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` still works, with all current tests executing Marked as reviewed by alanb (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8990 From rehn at openjdk.java.net Thu Jun 2 12:33:30 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 2 Jun 2022 12:33:30 GMT Subject: RFR: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 In-Reply-To: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> References: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> Message-ID: On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote: > [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the alternative Loom implementation that can be used by ports as the fallback. That fallback does not support JVMTI entirely, so lots of tests fail. Some JVMTI is still supported, so cutting off at `@requires vm.jvmti` seems too broad. They should be predicated with `@requires vm.continuations` to be skipped when fallback is used. > > This also allows reverting relevant x86_32 problemlist exclusions. > > Additional testing: > - [x] Linux x86_32 fastdebug, `serviceability/jvmti` works, many tests skipped > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` still works, with all current tests executing Marked as reviewed by rehn (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8990 From rehn at openjdk.java.net Thu Jun 2 13:55:56 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 2 Jun 2022 13:55:56 GMT Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case of target thread being current In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 13:47:23 GMT, Johan Sj?l?n wrote: > Please review this PR for fixing JDK-8287281. > > I chose a different solution than the one suggested. Looking at all callers of `Handshake::execute`, it seems that only one depends on `target == current`. The rest special case that by calling `is_handshake_safe_for` and `do_thread` directly. I converted the only instance of `Handshake::execute` with `target == current` to just directly call `do_thread`. > > Furthermore we now explicitly check for this case in `Handshake::execute` with an assert and document that this should not be done. > > Finally: Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this. > > > Currently running tier1-5 to check if I'm missing something. I agree, thanks for fixing. ------------- Marked as reviewed by rehn (Reviewer). PR: https://git.openjdk.java.net/jdk/pull/8992 From duke at openjdk.java.net Thu Jun 2 13:55:56 2022 From: duke at openjdk.java.net (Johan =?UTF-8?B?U2rDtmzDqW4=?=) Date: Thu, 2 Jun 2022 13:55:56 GMT Subject: RFR: 8287281: adjust guarantee in Handshake::execute for the case of target thread being current Message-ID: Please review this PR for fixing JDK-8287281. I chose a different solution than the one suggested. Looking at all callers of `Handshake::execute`, it seems that only one depends on `target == current`. The rest special case that by calling `is_handshake_safe_for` and `do_thread` directly. I converted the only instance of `Handshake::execute` with `target == current` to just directly call `do_thread`. Furthermore we now explicitly check for this case in `Handshake::execute` with an assert and document that this should not be done. Finally: Should `VirtualThreadGetThreadClosure` and its `do_thread()` body be inlined instead? We can do this in this PR, imho, but I'm hoping to get some input on this. Currently running tier1-5 to check if I'm missing something. ------------- Commit messages: - Disallow handshaking with self Changes: https://git.openjdk.java.net/jdk/pull/8992/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8992&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287281 Stats: 8 lines in 3 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8992.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8992/head:pull/8992 PR: https://git.openjdk.java.net/jdk/pull/8992 From sgehwolf at openjdk.java.net Thu Jun 2 14:40:58 2022 From: sgehwolf at openjdk.java.net (Severin Gehwolf) Date: Thu, 2 Jun 2022 14:40:58 GMT Subject: RFR: 8287663 Add a regression test for JDK-8287073 Message-ID: This adds a regression test for a recent fix (JDK-8287073). I've restructured the linux specific JDK code to call a separate static function to enable this test. It'll help future tests too. Testing: - [x] Container tests continue to pass + GHA - [x] New regression test fails prior the code fix of JDK-8287073 and passes with it ------------- Commit messages: - 8287663 Add a regression test for JDK-8287073 Changes: https://git.openjdk.java.net/jdk/pull/8993/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8993&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8287663 Stats: 36 lines in 2 files changed: 35 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8993.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8993/head:pull/8993 PR: https://git.openjdk.java.net/jdk/pull/8993 From lmesnik at openjdk.java.net Thu Jun 2 14:43:25 2022 From: lmesnik at openjdk.java.net (Leonid Mesnik) Date: Thu, 2 Jun 2022 14:43:25 GMT Subject: RFR: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 In-Reply-To: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> References: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> Message-ID: On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote: > [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the alternative Loom implementation that can be used by ports as the fallback. That fallback does not support JVMTI entirely, so lots of tests fail. Some JVMTI is still supported, so cutting off at `@requires vm.jvmti` seems too broad. They should be predicated with `@requires vm.continuations` to be skipped when fallback is used. > > This also allows reverting relevant x86_32 problemlist exclusions. > > Additional testing: > - [x] Linux x86_32 fastdebug, `serviceability/jvmti` works, many tests skipped > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` still works, with all current tests executing Marked as reviewed by lmesnik (Reviewer). ------------- PR: https://git.openjdk.java.net/jdk/pull/8990 From shade at openjdk.java.net Thu Jun 2 14:43:26 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 2 Jun 2022 14:43:26 GMT Subject: RFR: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 In-Reply-To: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> References: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> Message-ID: <7ZRoSUJf80AwyWWV_MerlpNxcbQVL2HKfD__faMPAXU=.96059504-1b81-4d37-98a5-745ae668b8de@github.com> On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote: > [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the alternative Loom implementation that can be used by ports as the fallback. That fallback does not support JVMTI entirely, so lots of tests fail. Some JVMTI is still supported, so cutting off at `@requires vm.jvmti` seems too broad. They should be predicated with `@requires vm.continuations` to be skipped when fallback is used. > > This also allows reverting relevant x86_32 problemlist exclusions. > > Additional testing: > - [x] Linux x86_32 fastdebug, `serviceability/jvmti` works, many tests skipped > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` still works, with all current tests executing Trivial, or? I would like to have this integrated sooner to clean up our testing. ------------- PR: https://git.openjdk.java.net/jdk/pull/8990 From rehn at openjdk.java.net Thu Jun 2 14:43:26 2022 From: rehn at openjdk.java.net (Robbin Ehn) Date: Thu, 2 Jun 2022 14:43:26 GMT Subject: RFR: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 In-Reply-To: <7ZRoSUJf80AwyWWV_MerlpNxcbQVL2HKfD__faMPAXU=.96059504-1b81-4d37-98a5-745ae668b8de@github.com> References: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> <7ZRoSUJf80AwyWWV_MerlpNxcbQVL2HKfD__faMPAXU=.96059504-1b81-4d37-98a5-745ae668b8de@github.com> Message-ID: On Thu, 2 Jun 2022 14:38:31 GMT, Aleksey Shipilev wrote: > Trivial, or? I would like to have this integrated sooner to clean up our testing. Ship it under trivial, thanks. ------------- PR: https://git.openjdk.java.net/jdk/pull/8990 From mkartashev at openjdk.java.net Thu Jun 2 14:54:32 2022 From: mkartashev at openjdk.java.net (Maxim Kartashev) Date: Thu, 2 Jun 2022 14:54:32 GMT Subject: RFR: 8287663 Add a regression test for JDK-8287073 In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 14:32:28 GMT, Severin Gehwolf wrote: > This adds a regression test for a recent fix (JDK-8287073). I've restructured the linux specific JDK code to call a separate static function to enable this test. It'll help future tests too. > > Testing: > - [x] Container tests continue to pass + GHA > - [x] New regression test fails prior the code fix of JDK-8287073 and passes with it @jerboaa Thanks for taking care of the test! I'm not a reviewer, but FWIW the test looks good to me. ------------- PR: https://git.openjdk.java.net/jdk/pull/8993 From shade at openjdk.java.net Thu Jun 2 16:01:15 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 2 Jun 2022 16:01:15 GMT Subject: RFR: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 In-Reply-To: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> References: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> Message-ID: On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote: > [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the alternative Loom implementation that can be used by ports as the fallback. That fallback does not support JVMTI entirely, so lots of tests fail. Some JVMTI is still supported, so cutting off at `@requires vm.jvmti` seems too broad. They should be predicated with `@requires vm.continuations` to be skipped when fallback is used. > > This also allows reverting relevant x86_32 problemlist exclusions. > > Additional testing: > - [x] Linux x86_32 fastdebug, `serviceability/jvmti` works, many tests skipped > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` still works, with all current tests executing Thank you! ------------- PR: https://git.openjdk.java.net/jdk/pull/8990 From shade at openjdk.java.net Thu Jun 2 16:01:16 2022 From: shade at openjdk.java.net (Aleksey Shipilev) Date: Thu, 2 Jun 2022 16:01:16 GMT Subject: Integrated: 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 In-Reply-To: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> References: <1v57pM7V4Ato-XBkOfq0VEV8t123LHqbqE9bKOFybn8=.32035a69-7f02-4549-88b2-8c3c68362f6e@github.com> Message-ID: On Thu, 2 Jun 2022 09:54:31 GMT, Aleksey Shipilev wrote: > [JDK-8287496](https://bugs.openjdk.java.net/browse/JDK-8287496) brought the alternative Loom implementation that can be used by ports as the fallback. That fallback does not support JVMTI entirely, so lots of tests fail. Some JVMTI is still supported, so cutting off at `@requires vm.jvmti` seems too broad. They should be predicated with `@requires vm.continuations` to be skipped when fallback is used. > > This also allows reverting relevant x86_32 problemlist exclusions. > > Additional testing: > - [x] Linux x86_32 fastdebug, `serviceability/jvmti` works, many tests skipped > - [x] Linux x86_64 fastdebug, `serviceability/jvmti` still works, with all current tests executing This pull request has now been integrated. Changeset: 3cfd38ca Author: Aleksey Shipilev URL: https://git.openjdk.java.net/jdk/commit/3cfd38caf10c18f71c0fc8c9a09c0d1179373ce7 Stats: 138 lines in 69 files changed: 69 ins; 69 del; 0 mod 8287726: Fix JVMTI tests with "requires vm.continuations" after JDK-8287496 Reviewed-by: alanb, rehn, lmesnik ------------- PR: https://git.openjdk.java.net/jdk/pull/8990 From cjplummer at openjdk.java.net Thu Jun 2 18:20:26 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 2 Jun 2022 18:20:26 GMT Subject: RFR: 8287695: Use String.contains() instead of String.indexOf() in jdk.hotspot.agent In-Reply-To: References: Message-ID: On Thu, 2 Jun 2022 09:57:10 GMT, Andrey Turbanov wrote: > > Please make sure you run the SA tests. > > This one, `test/hotspot/jtreg/serviceability` right? You can just do the `test/hotspot/jtreg/serviceability/sa` subdirectory, but there is also `test/jdk/sun/tools/jhsdb` ------------- PR: https://git.openjdk.java.net/jdk/pull/8966 From aturbanov at openjdk.java.net Thu Jun 2 19:31:32 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 2 Jun 2022 19:31:32 GMT Subject: RFR: 8287695: Use String.contains() instead of String.indexOf() in jdk.hotspot.agent In-Reply-To: References: Message-ID: <2N3q1B4r0GyIogtHFqdy1yAu86iY1zXg9IMN_U8bohs=.8fc48014-0c6c-49c4-aa23-4e75844577f0@github.com> On Wed, 1 Jun 2022 07:52:50 GMT, Andrey Turbanov wrote: > `String.contains` was introduced in Java 5. > Some code in jdk.hotspot.agent still uses old approach with `String.indexOf` to check if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to read. All green. Thank you for review! ------------- PR: https://git.openjdk.java.net/jdk/pull/8966 From aturbanov at openjdk.java.net Thu Jun 2 19:31:32 2022 From: aturbanov at openjdk.java.net (Andrey Turbanov) Date: Thu, 2 Jun 2022 19:31:32 GMT Subject: Integrated: 8287695: Use String.contains() instead of String.indexOf() in jdk.hotspot.agent In-Reply-To: References: Message-ID: <_zlHEy2MfnRMq6zuV5Fm7bikP0i396MPp2ZrmVHINvo=.b7f034ce-25e3-44aa-a2c2-8fa55a8b0f7f@github.com> On Wed, 1 Jun 2022 07:52:50 GMT, Andrey Turbanov wrote: > `String.contains` was introduced in Java 5. > Some code in jdk.hotspot.agent still uses old approach with `String.indexOf` to check if String contains specified substring. > I propose to migrate such usages. Makes code shorter and easier to read. This pull request has now been integrated. Changeset: 26048ea2 Author: Andrey Turbanov URL: https://git.openjdk.java.net/jdk/commit/26048ea21e0da6505d8452bd33a4d37b1bd5ce74 Stats: 19 lines in 4 files changed: 0 ins; 7 del; 12 mod 8287695: Use String.contains() instead of String.indexOf() in jdk.hotspot.agent Reviewed-by: cjplummer ------------- PR: https://git.openjdk.java.net/jdk/pull/8966 From cjplummer at openjdk.java.net Thu Jun 2 21:27:35 2022 From: cjplummer at openjdk.java.net (Chris Plummer) Date: Thu, 2 Jun 2022 21:27:35 GMT Subject: RFR: 8286983: rename jdb -trackvthreads and debug agent enumeratevthreads options and clarify "Preview Feature" nature of these options [v5] In-Reply-To: References: Message-ID: On Tue, 31 May 2022 18:14:51 GMT, Chris Plummer wrote: >> As part of the loom integration, jdb added `-trackvthreads` and the debug agent added `enumeratevthreads`. These options are being renamed to `-trackallthreads` and `includevirtualthreads` (the shorthand `vthreads` should not have been used). Also, the help text for these options now calls out that virtual threads are a Preview Feature. >> >> After the update to help text, wlil look as follows: >> >> jdb doc (search for "trackallthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/jdb.html >> debug agent doc (seach for "includevirtualthreads"): http://cr.openjdk.java.net/~cjplummer/8286983/conninv.html >> >> >> $ jdb -listconnectors >> ... >> Connector: com.sun.jdi.CommandLineLaunch Transport: dt_socket >> description: Launches target using Sun Java VM command line and attaches to it >> ... >> Argument: includevirtualthreads Default value: n >> description: List of all threads includes virtual threads as well as platform threads. Virtual threads are a preview feature of the Java platform. >> >> >> >> $ jdb -help >> Usage: jdb >> >> where options include: >> ... >> -dbgtrace [flags] print info for debugging jdb >> -trackallthreads Track all threads, including virtual threads. >> Virtual threads are a preview feature of the Java platform. >> -tclient run the application in the HotSpot(TM) Client Compiler >> ... >> >> >> >> $ man -M ./build/linux-x64-debug/images/jdk/man/ jdb >> ... >> -tclient >> Runs the application in the Java HotSpot VM client. >> >> -trackallthreads >> Track all threads as they are created, including Virtual >> Threads. See Working With Virtual Threads below. Virtual >> threads are a preview feature of the Java platform. >> >> -tserver >> Runs the application in the Java HotSpot VM server. >> ... >> WORKING WITH VIRTUAL THREADS >> Virtual threads are a preview feature of the Java platform. Preview >> features may be removed in a future release, or upgraded to permanent >> features of the Java platform. >> >> Often virtual theads are created in such large numbers and frequency >> ... >> >> >> >> $ java -agentlib:jdwp=help >> Java Debugger JDWP Agent Library >> -------------------------------- >> >> (See the "VM Invocation Options" section of the JPDA >> "Connection and Invocation Details" document for more information.) >> >> jdwp usage: java -agentlib:jdwp=[help]|[