RFR: 8299240: rank of JvmtiVTMSTransition_lock can be safepoint

David Holmes dholmes at openjdk.org
Fri Feb 17 05:14:59 UTC 2023


On Tue, 14 Feb 2023 05:37:51 GMT, Serguei Spitsyn <sspitsyn at 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)

This looks a lot cleaner have the `JvmtiVTMSTransition_lock` be a normal safepoint-honouring monitor, but that said, it means there are now many places that can block for safepoints that previously wouldn't and it is very to hard to tell if that is okay or not.

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);

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

PR: https://git.openjdk.org/jdk/pull/12550


More information about the serviceability-dev mailing list