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

Chris Plummer cjplummer at openjdk.org
Thu Mar 30 22:34:28 UTC 2023


On Thu, 30 Mar 2023 17:10:16 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:
> 
>   review: tweak in count_transitions_and_correct_jvmti_thread_states

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

> 43: // to have sleep() calls to provide yielding as some frequency of virtual
> 44: // thread mount state transitions is needed for this test scenario.
> 45: class TestedThread extends Thread {

Shouldn't this be a Runnable instead of a Thread? I would also suggest not using  the term "thread" here. Maybe "task"? Otherwise code like the following is misleading:


                TestedThread thread = threads[i];
                thread.letFinish();

There are no threads being referenced in this code, yet the term "thread" is used 4 times.

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

> 168:         // Disable notifyJvmti events mode at test cycle start.
> 169:         // It is unsafe to do so if any virtual threads are executed.
> 170:         setVirtualThreadsNotifyJvmtiMode(iter, false);

What happens if the main thread is a virtual thread because the virtual thread wrapper is being used? Is there any concern with disabling notifications in this case?

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

> 170:         setVirtualThreadsNotifyJvmtiMode(iter, false);
> 171: 
> 172:         Thread tt = Thread.ofPlatform().name("StartThreadsTest").start(ToggleNotifyJvmtiTest::startThreads);

Why does each test  cycle need to be run in a separate platform thread? Can't you just use the main test thread?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153845337
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153850702
PR Review Comment: https://git.openjdk.org/jdk/pull/13133#discussion_r1153849125


More information about the serviceability-dev mailing list