RFR: 8298853: JvmtiVTMSTransitionDisabler should support disabling one virtual thread transitions
Serguei Spitsyn
sspitsyn at openjdk.org
Mon Dec 19 11:36:49 UTC 2022
On Fri, 16 Dec 2022 02:10:09 GMT, David Holmes <dholmes at openjdk.org> wrote:
>> Now the `JvmtiVTMSTransitionDisabler` mechanism supports disabling VTMS transitions for all virtual threads only. It should also support disabling transitions for any specific virtual thread as well. This will improve scalability of the JVMTI functions operating on target virtual threads as the functions can be executed concurrently without blocking each other execution when target virtual threads are different.
>> New constructor `JvmtiVTMSTransitionDisabler(jthread vthread)` is added which has jthread parameter of the target virtual thread.
>>
>> Testing:
>> mach5 jobs are TBD (preliminary testing was completed):
>> - all JVMTI, JDWP, JDI and JDB tests have to be run
>> - Kitchensink
>> - tier5
>
> src/hotspot/share/classfile/javaClasses.cpp line 1745:
>
>> 1743: int val = VTMS_transition_disable_count(java_thread);
>> 1744: java_thread->int_field_put(_jvmti_VTMS_transition_disable_count_offset, val - 1);
>> 1745: }
>
> These are not thread-safe functions. What constraints exist for using these methods safely?
> Update: looks like they must be called with the lock held so we should assert that.
> Should also assert the count never goes negative (which I assume would be an error?).
Each of these two functions is called just once with the lock held.
I feel that asserting this would be an overkill but I can add it if you still think it is important.
I've added assert for negative count.
> src/hotspot/share/prims/jvmtiThreadState.cpp line 252:
>
>> 250: return; // JvmtiVTMSTransitionDisabler is no-op without virtual threads
>> 251: }
>> 252: if (Thread::current_or_null() == NULL) {
>
> Nit: please use `nullptr` in new code
Done.
-------------
PR: https://git.openjdk.org/jdk/pull/11690
More information about the hotspot-dev
mailing list