Hi Richard,
Unfortunately I do not have any benchmark for this change, however I think it
is worth to do it for consistency. All of VM operations which do not need
global lock in JVMTI are replaced to direct handshake if this enhancement is
merged.
I think VM operations should be replaced to direct handshake if we can. VM
operations should be just used for operations which needs global lock. It will
help all of programmers who are interested in HotSpot when they try to know the
operation.
Thanks,
Yasumasa
On 2020/08/27 16:43, Reingruber, Richard wrote:
Hi Yasumasa,
I've described the motivation on JDK-8201641 (it is a parent task of
JDK-8242427)
```
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 the goal is better performance. For PopFrame IMHO it is not worth the effort,
the future effort in maintaining the related code, and the risk.
I think so because PopFrame is a hardly ever used. I honestly never used it
(have you?). In IDEs it is well hidden. Graal does not even bother to support
it. On the other side the change affects other operations that are commonly
used.
In the rare cases when a PopFrame is requested it will be in interactive
sessions: someone found the well-hidden PopFrame button in the debugger and
pressed it. Probably she won't do it again. At least not at a high frequency. So
she will not notice the effect of the optimization.
If you have a large cloud of JVMs where every second a PopFrame is executed,
even then I would doubt that the resource savings are measurable. And I would
also doubt that a cloud with PopFrames at that rate exists.
I see there are rare events like full GCs that can do harm. But in the case of
PopFrame I can't see a problem because the pause for the vm operation will be
extremely short.
Is there a scenario or a not too artificial benchmark that would show an
improvement?
Thanks,
Richard.
-----Original Message-----
From: Yasumasa Suenaga <[email protected]>
Sent: Donnerstag, 27. August 2020 01:30
To: Reingruber, Richard <[email protected]>; serviceability-dev
<[email protected]>
Subject: Re: 8242427: JVMTI frame pop operations should use Thread-Local
Handshakes
Hi Richard,
I've described the motivation on JDK-8201641 (it is a parent task of
JDK-8242427)
```
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.
```
I aimed to improve JVMTI monitor operation with TLS at first, but I found other
JVMTI operations can be improved with same process. So I've tried to fix them.
I proposed it to serviceability-dev [1], then Dan told me similar enhancement
is already filed to JBS [2]. So I created subtasks in it.
Thanks,
Yasumasa
[1]
https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030890.html
[2]
https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-March/030897.html
On 2020/08/27 5:33, Reingruber, Richard wrote:
Hi Yasumasa,
Could you explain a little bit the motivation to replace these vm operations
with handshakes?
Would be good, if you could add the goals as well to the JBS item.
Thanks, Richard.
-----Original Message-----
From: serviceability-dev <[email protected]> On Behalf
Of Yasumasa Suenaga
Sent: Montag, 24. August 2020 04:40
To: serviceability-dev <[email protected]>
Subject: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes
Hi all,
I want to hear your opinions about the change for JDK-8242427.
I'm trying to migrate following operations to direct handshake.
- VM_UpdateForPopTopFrame
- VM_SetFramePop
- VM_GetCurrentLocation
Some operations (VM_GetCurrentLocation and EnterInterpOnlyModeClosure) might be
called at safepoint, so I want to use JavaThread::active_handshaker() in
production VM to detect the process is in direct handshake or not.
However this function is available in debug VM only, so I want to hear the
reason why it is for debug VM only, and there are no problem to use it in
production VM. Of course another solutions are welcome.
webrev is here. It passed jtreg tests (vmTestbase/nsk/{jdi,jdwp,jvmti}
serviceability/{jdwp,jvmti})
http://cr.openjdk.java.net/~ysuenaga/JDK-8242427/proposal/
Thanks,
Yasumasa
