On Thu, 3 Apr 2025 17:58:30 GMT, Leonid Mesnik <lmes...@openjdk.org> wrote:
>> Serguei Spitsyn has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> some cleanup
>
> src/hotspot/share/prims/jvmtiEnv.cpp line 1078:
>
>> 1076: JvmtiEnv::ResumeThread(jthread thread) {
>> 1077: // resume thread with handshake
>> 1078: ResumeThreadClosure op(/* single_resume */ true);
>
> Could you please explain how thread is protected from racing with
> mounting<->unmounting operations with resume_thread operations?
> It might be unlikely happens for suspended threads, but for alive threads the
> results are not defined.
Thank you for the question. The `JvmtiHanshake::execute()` has a
`JvmtiVTMSTransitionDisabler` installed:
JvmtiHandshake::execute(JvmtiUnitedHandshakeClosure* hs_cl, jthread target) {
JavaThread* current = JavaThread::current();
HandleMark hm(current);
JvmtiVTMSTransitionDisabler disabler(target); <= !!!!!!!
. . .
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1759:
>
>> 1757: Handle thread_h(current, thread_oop);
>> 1758: bool is_virtual = java_lang_VirtualThread::is_instance(thread_h());
>> 1759: bool is_thread_carrying = is_thread_carrying_vthread(java_thread,
>> thread_h());
>
> I think that somewhere in this place should be an explanation of
> suspend<->resume synchronization. As I understand the hadshake can't be
> executed and clear suspend state while suspend_thread is done for the same
> thread. How it is guaranteed that suspend_thread flag cann't be updated?
> It is not obvious and also put some restrictions on the suspend_thread
> implementation to keep this behaviour.
Thank you for reviewing and this suggestion.
Yes, you are right. I'll try to find a good place to add such a comment.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2028158825
PR Review Comment: https://git.openjdk.org/jdk/pull/24269#discussion_r2028161088
