Hi Yasumasa,
Yes, this works needs to be done.
I'll take look at you webrev.
Thanks,
Serguei
On 3/31/20 07:41, Daniel D. Daugherty wrote:
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
