On Thu, 28 Sep 2023 21:04:58 GMT, Leonid Mesnik <[email protected]> wrote:
>> The test fails because ThreadDeath is raised during class >> jdk.internal.misc.VirtualThreads initialization. The proposed fix is to >> pre-initialize this step to avoid such failures. See more details in the bug. >> I reproduced the original problem and verified that it is not reproduced >> after fix. >> Tested with tier5 and running nsk/jvmti tests with and without virtual test >> thread factory. >> >> I don't think that more complex fix is needed. There is a plan to review >> nsk/jvmti stopThread tests and see if >> ./serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java >> might be improved to cover them. > > Leonid Mesnik has updated the pull request incrementally with one additional > commit since the last revision: > > missed import added. jdk.internal.misc.VirtualThreads is a supporting class for LockSupport.park/unpark. It came about because of bootstrapping issues with LockSupport being loaded early in the startup. A lot of code has changed since it was added and it might be time to look at it again, meaning LockSupport changed to use the JLA shared secret and checking for startup/bootstrapping issues. On the class loading. If a virtual thread parks with LockSupport.park then it will trigger any supporting classes to be loaded on first usage. It looks like this test involves a virtual thread being unparked with LockSupport.unpark before it parks with LockSupport.park. This scenario does lead to the supporting class being loaded when unparking, problematic in this test because of JVMTI StopThread and the async exception. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15966#issuecomment-1741704053
