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