On Fri, 17 Feb 2023 05:09:25 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> The rank of JvmtiVTMSTransition_lock is better to be safepoint instead of
>> nosafepoint.
>> The fix includes removal of the function
>> `check_vthread_and_suspend_at_safepoint` which is not needed anymore.
>>
>> Testing:
>> mach5 jobs are in progress:
>> Kitchensink, tiers1-6 (all JVMTI, JDWP, JDI and JDB tests have to be
>> included)
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 952:
>
>> 950: }
>> 951: // protect thread_oop as a safepoint can be reached in disabler
>> destructor
>> 952: self_tobj = Handle(current, thread_oop);
>
> If you move this after line 953 then you can delete line 932 and just have:
>
> Handle self_tobj = Handle(current, thread_oop);
Thank you for looking at this PR, David!
Please, note a disabler at L938. A safepont can be reached in its destructor.
Also, see the comment at L952:
937 {
938 JvmtiVTMSTransitionDisabler disabler(true);
939 ThreadsListHandle tlh(current);
940
941 err = get_threadOop_and_JavaThread(tlh.list(), thread, &java_thread,
&thread_oop);
942 if (err != JVMTI_ERROR_NONE) {
943 return err;
944 }
945
946 // Do not use JvmtiVTMSTransitionDisabler in context of self suspend
to avoid deadlocks.
947 if (java_thread != current) {
948 err = suspend_thread(thread_oop, java_thread, /* single_suspend */
true, nullptr);
949 return err;
950 }
951 // protect thread_oop as a safepoint can be reached in disabler
destructor
952 self_tobj = Handle(current, thread_oop);
953 }
-------------
PR: https://git.openjdk.org/jdk/pull/12550
