RFR: 8307968: serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java timed out
Serguei Spitsyn
sspitsyn at openjdk.org
Tue May 16 01:13:47 UTC 2023
On Mon, 15 May 2023 21:44:37 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:
>> This is newly integrated test times out because it has a race in in the Test #A.1 and #A.2.
>> The main root cause is a print statement which can case target virtual thread to unpark and unmount.
>> This causes that the `StopThreads` unexpectedly fails with the `JVMTI_ERROR_OPAQUE_FRAME` error code.
>> The target thread can be in some other unexpected states if JVMTI `StopThread`
>> is called before the target thread method `A()` reached the synchronized statement.
>>
>> The fix is to replace the `ensureStarted()` with the `ensureAtPointA()`.
>> The fix also includes some simplifications related to clearing the target thread interrupt status.
>>
>> Testing:
>> Hundreds of mach5 runs of `serviceability/jvmti/vthread` tests which include the fixed `StopThreadTest`.
>> TBD: To run mack5 tiers1-3.
>
> test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 243:
>
>> 241: static void A() {
>> 242: log("TestTask.A: started");
>> 243: atPointA = true;
>
> What happens if we are at the point where this flag has been set true, but we have not yet executed the monitorenter? Will the test pass if the StopThread is done a bit early here?
Yes, the test will pass.
#A.1: The `StopThread` should still return the JVMTI_ERROR_THREAD_NOT_SUSPENDED error code.
#A.2: The `StopThread` should return the JVMTI_ERROR_NONE as the target virtual thread has been mounted.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/13969#discussion_r1194495790
More information about the serviceability-dev
mailing list