On Mon, 15 May 2023 21:44:37 GMT, Chris Plummer <cjplum...@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
