RFR: 8304303: implement VirtualThread class notifyJvmti methods as C2 intrinsics [v4]

Alan Bateman alanb at openjdk.org
Sat Mar 18 11:27:20 UTC 2023


On Fri, 17 Mar 2023 10:31:46 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is needed for future performance/scalability improvements in JVMTI support of virtual threads.
>> The update includes the following:
>> 
>> 1. Refactored the `VirtualThread` native methods:
>>     `notifyJvmtiMountBegin`     and `notifyJvmtiMountEnd`      => `notifyJvmtiMount`
>>     `notifyJvmtiUnmountBegin` and `notifyJvmtiUnmountEnd` => `notifyJvmtiUnmount`
>> 2. Still useful implementation of old native methods is moved from `jvm.cpp` to `jvmtiThreadState.cpp`:
>>      `JVM_VirtualThreadMountStart`       => `VTMS_mount_begin`
>>      `JVM_VirtualThreadMountEnd`         => `VTMS_mount_end`
>>      `JVM_VirtualThreadUnmountStart`  = > `VTMS_unmount_begin`
>>      `JVM_VirtualThreadUnmountEnd`    => `VTMS_mount_end`
>> 3. Intrinsified the `VirtualThread` native methods: `notifyJvmtiMount`, `notifyJvmtiUnmount`, `notifyJvmtiHideFrames`.
>> 4. Removed the`VirtualThread` static boolean state variable `notifyJvmtiEvents` and its support in `javaClasses`.
>> 5. Added static boolean state variable `_VTMS_notify_jvmti_events` to the jvmtiVTMSTransitionDisabler class as a replacement of the `VirtualThread` `notifyJvmtiEvents` variable.
>> 
>> Implementing the same methods as C1 intrinsics can be needed in the future but is a low priority for now.  
>> 
>> Testing:
>>  - Ran mach5 tiers 1-6. No regressions were found.
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor tweaks in intrisics implementation

The most important case is when there is no JVMTI env. If I read the changes correctly, the overhead for park/continue changes from one volatile-read (notifyJvmtiEvents) to two plain-writes (JavaThread::_is_in_VTMS_transition).

If a JVMTI env has been created then there is no benefit for the moment as there is still a call into the runtime to interact with JvmtiVTMSTransitionDisabler. So I think you are saying that is for follow-on PRs.

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

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


More information about the serviceability-dev mailing list