RFR: 8297286: runtime/vthread tests crashing after JDK-8296324 [v5]

Leonid Mesnik lmesnik at openjdk.org
Thu Mar 23 22:29:51 UTC 2023


On Thu, 23 Mar 2023 05:54:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> The fix is to enable virtual threads support for late binding JVMTI agents.
>> The fix includes:
>> - New function `JvmtiEnvBase::enable_virtual_threads_notify_jvmti()` which does enabling JVMTI VTMS transition notifications in case of agent loaded into running VM. This function executes a VM operation counting VTMS transition bits in all `JavaThread`'s to correctly set the static counter `_VTMS_transition_count` needed for VTMS transition protocol.
>> - New function `JvmtiEnvBase::disable_virtual_threads_notify_jvmti()` which is needed for testing. It is used by the `WhiteBox` API.
>> - New WhiteBox function `WB_SetVirtualThreadsNotifyJvmtiMode(JNIEnv* env, jobject wb, jboolean enable)` needed for testing of this update.
>> - New regression test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> 
>> Testing:
>> - New test: `serviceability/jvmti/vthread/ToggleNotifyJvmtiTest`
>> - The originally failed tests are expected to pass now:
>>   `runtime/vthread/RedefineClass.java`
>>   `runtime/vthread/TestObjectAllocationSampleEvent.java` 
>> - In progress: Run the tiers 1-6 to make sure there are no regression.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comment: remove unneeded function

There are few comments in the code.
Also, I think it would be nice to have a high-level comment about sync of VTMTDisable and lately attached agent. What is set and why VMOp is needed.
BTW why VMOp and not handshake is used?

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1581:

> 1579:     return false;
> 1580:   }
> 1581:   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {

shouldn't be
 if (!JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
here?

src/hotspot/share/prims/whitebox.cpp line 2537:

> 2535:   }
> 2536: #endif
> 2537:   return result;

The test never check results, so it might be better to generate fatal error and fail here/throw exception to catch bug earlier?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/ToggleNotifyJvmtiTest.java line 82:

> 80:         try {
> 81:             while (!threadReady) {
> 82:                 sleep(1);

Use ToggleNotifyJvmtiTest.sleep(1);?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 77:

> 75: 
> 76:     err = jvmti->AddCapabilities(&caps);
> 77:     if (err != JVMTI_ERROR_NONE) {

Can you use check_jvmti_status to ensure that result is not error?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 82:

> 80:     }
> 81:     err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, JVMTI_EVENT_VIRTUAL_THREAD_START, NULL);
> 82:     if (err != JVMTI_ERROR_NONE) {

2nd Can you use check_jvmti_status to ensure that result is not error?

test/hotspot/jtreg/serviceability/jvmti/vthread/ToggleNotifyJvmtiTest/libToggleNotifyJvmtiTest.cpp line 89:

> 87:   LOG("Agent init: can_support_virtual_threads capability: %d\n",  caps.can_support_virtual_threads);
> 88: 
> 89:   err = jvmti->SetEventCallbacks(&callbacks, (jint)sizeof(callbacks));

3rd Can you use check_jvmti_status to ensure that result is not error?

-------------

Changes requested by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13133#pullrequestreview-1355740399
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146929861
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146934499
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146936003
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146938334
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146938504
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1146938603


More information about the serviceability-dev mailing list