On Wed, 19 Apr 2023 22:54:35 GMT, Serguei Spitsyn <sspit...@openjdk.org> wrote:
> This enhancement adds support of virtual threads to the JVMTI `StopThread` > function. > In preview releases before this enhancement the StopThread returned the > JVMTI_ERROR_UNSUPPORTED_OPERATION error code for virtual threads. > > The `StopThread` supports sending an asynchronous exception to a virtual > thread only if it is current or suspended at mounted state. For instance, a > virtual thread can be suspended at a JVMTI event. If the virtual thread is > not suspended and is not current then the `JVMTI_ERROR_THREAD_NOT_SUSPENDED` > error code is returned. If the virtual thread was suspended at unmounted > state then the `JVMTI_ERROR_OPAQUE_FRAME` error code is returned. > > The `StopThread` has the following description for `JVMTI_ERROR_OPAQUE_FRAME` > error code: >> The thread is a suspended virtual thread and the implementation >> was unable to throw an asynchronous exception from this frame. > > A couple of the `serviceability/jvmti/vthread` tests has been updated to > adopt to new `StopThread` behavior. > > The CSR is: https://bugs.openjdk.org/browse/JDK-8306434 > > Testing: > The mach5 tears 1-6 are in progress. > Preliminary test runs were good in general. > The JDB test `vmTestbase/nsk/jdb/kill/kill001/kill001.java` has been > problem-listed and will be fixed by the corresponding debugger enhancement > which is going to adopt JDWP/JDI specs to new behavior of the JVMTI > `StopThread` related to virtual threads. > > Also, two JCK JVMTI tests are failing in the tier-6 : >> vm/jvmti/StopThread/stop001/stop00103/stop00103.html >> vm/jvmti/StopThread/stop001/stop00103/stop00103a.html > > These two tests will be excluded from the test runs by the JCK team and then > adjusted to new `StopThread` behavior. Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 38: > 36: * > 37: * @requires vm.continuations > 38: * @compile --enable-preview -source ${jdk.version} StopThreadTest.java --enable-preview is not needed anymore. test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/StopThreadTest.java line 48: > 46: static final int JVMTI_ERROR_NONE = 0; > 47: static final int THREAD_NOT_SUSPENDED = 13; > 48: static final int PASSED = 0; I think it would be better to don't use statuses and just throw exception after first failure. Usually the other results of other test cases might be corrupted and output just confuse user. test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/libStopThreadTest.cpp line 135: > 133: check_jvmti_status(jni, err, "prepareAgent: Failed in JVMTI > SetBreakpoint"); > 134: > 135: err = jvmti->SetEventNotificationMode(JVMTI_ENABLE, > JVMTI_EVENT_BREAKPOINT, NULL); We have set_event_notification_mode() in jvmti_h. test/hotspot/jtreg/serviceability/jvmti/vthread/StopThreadTest/libStopThreadTest.cpp line 151: > 149: Java_StopThreadTest_resumeThread(JNIEnv *jni, jclass cls, jthread > thread) { > 150: LOG("Main: resumeThread\n"); > 151: jvmtiError err = jvmti->ResumeThread(thread); there is suspend_thread/resume_thread() in jvmti.h ------------- PR Review: https://git.openjdk.org/jdk/pull/13546#pullrequestreview-1393079770 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1171991173 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1172026145 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1171995417 PR Review Comment: https://git.openjdk.org/jdk/pull/13546#discussion_r1171994042
