RFR: 8308429: jvmti/StopThread/stopthrd007 failed with "NoClassDefFoundError: Could not initialize class jdk.internal.misc.VirtualThreads" [v2]

[Alan Bateman]

On Thu, 28 Sep 2023 21:04:58 GMT, Leonid Mesnik <lmesnik at openjdk.org> 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.

One other general comment is that "stop" has been removed from the user-facing APIs for several releases. The use-case for JVMTI StopThread (and the JDWP/JDI equivalents) is mostly the debugger scenario where a thread is at a breakpoint and the developer wants to test how the code behaves when an exception is thrown, e.g. ask the debugger to throw IllegalArgumentException or SQLException at this point. This is a bit more controlled than shooting an arrow at the executing code as that leads to very unpredictable behavior. So I guess my point is that there may be merit is "degrading" StopThread to only require that it be supported when the target thread is suspended at an event. This would align it where we got to with virtual threads.  There may also be merit is re-examining the tests that are sending async exceptions as sending the terminally deprecated ThreadDeath is troublesome, it may be better to have tests for StopThread focus on cases where the target thread is suspended at an 
 event.

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

PR Comment: https://git.openjdk.org/jdk/pull/15966#issuecomment-1741723936