Thread Local Handshake in JVMTI functions

[Daniel D. Daugherty]

Add Robbin to this thread...


This reminded of the following RFE that Robbin filed:

     JDK-8201641 JVMTI: GetThreadListStackTraces should use Thread-Local 
Handshakes
     https://bugs.openjdk.java.net/browse/JDK-8201641

We could update 8201641 to include everything that Yasumasa-san is 
requesting.
Would be a good place to track it...

Dan


On 3/31/20 7:40 AM, Yasumasa Suenaga wrote:
> Hi David,
>
> On 2020/03/31 19:16, David Holmes wrote:
>> Hi Yasumasa,
>>
>> On 31/03/2020 8:06 pm, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> Many JVMTI functions uses VM Operation to get information. However 
>>> some of them need to stop only one thread - they don't need to stop 
>>> all threads.
>>> So I think we can use Thread Local Handshake as this webrev. It is 
>>> example for GetOneCurrentContendedMonitor().
>>
>> True, but at the moment handshakes involve the VMThread. There is 
>> work being done to support direct thread-to-thread handshakes and 
>> once that is done this kind of conversion should be more easily done. 
>> It might be worth waiting for that.
>
> Thanks, I will be back to this topic when thread-to-thread handshake 
> is done.
> I wondered at first why VMThread involves handshake. Its improvement 
> is welcome for me ;)
>
>
> Cheers,
>
> Yasumasa
>
>
>>> http://cr.openjdk.java.net/~ysuenaga/jvmti-thread-local-handshake/
>>
>> An observation, it seems to me that calling_thread is not used when 
>> this is not a VMOperation.
>>
>> Cheers,
>> David
>>
>>> Also I think we can replace following VM Operations to Thread Local 
>>> Handshake:
>>>
>>> class VM_GetCurrentLocation
>>> class VM_EnterInterpOnlyMode
>>> class VM_UpdateForPopTopFrame
>>> class VM_SetFramePop
>>> class VM_GetOwnedMonitorInfo
>>> class VM_GetCurrentContendedMonitor
>>> class VM_GetFrameCount
>>> class VM_GetFrameLocation
>>>
>>> What do you think?
>>> It it is acceptable, I will file it to JBS and send review request.
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa