Hi Richard,
On 2020/08/28 17:54, Reingruber, Richard wrote:
Hi Yasumasa,
VM_DeoptimizeFrame can be replaced too I'd think.
The scope of this change is JVMTI, so I don't want to change VM_DeoptimizeFrame
now.
Of course it would be nice if other VM operations (includes VM_DeoptimizeFrame)
are replaced to direct handshake in future, but I think it is another RFE.
Cheers,
Yasumasa
Cheers, Richard.
-----Original Message-----
From: Yasumasa Suenaga <[email protected]>
Sent: Freitag, 28. August 2020 10:42
To: Reingruber, Richard <[email protected]>; David Holmes
<[email protected]>; serviceability-dev <[email protected]>
Subject: Re: 8242427: JVMTI frame pop operations should use Thread-Local
Handshakes
Hi Richard,
On 2020/08/28 17:11, Reingruber, Richard wrote:
Hi David, hi Yasumasa,
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.
VM_GetOrSetLocal can be replaced with a handshake too, I'd say.
VM_GetOrSetLocal::doit() might call Deoptimization::deoptimize_frame() - it
would exec VM_DeoptimizeFrame. It is VMop in direct handshake. If it is safe,
we can replace VM_GetOrSetLocal, but I'm not sure.
Thanks,
Yasumasa
On 28/08/2020 11:45 am, Yasumasa Suenaga wrote:
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.
I agree with this motivation - we want to eradicate as many safepoint VM
operations as possible, even if the usage would not really benefit from
the lack of stop-the-world pauses. That said, of course this has to be
tempered against the complexity of the change. But we are establishing a
pattern for coding up JVMTI operation as direct handshakes, which should
make things generally more easy to understand.
I still don't see the point in optimizing the uncommon case making it more
complex. But if it's just me...
Cheers, Richard.
-----Original Message-----
From: David Holmes <[email protected]>
Sent: Freitag, 28. August 2020 03:53
To: Yasumasa Suenaga <[email protected]>; Reingruber, Richard
<[email protected]>; serviceability-dev <[email protected]>
Subject: Re: 8242427: JVMTI frame pop operations should use Thread-Local
Handshakes
On 28/08/2020 11:45 am, Yasumasa Suenaga wrote:
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.
I agree with this motivation - we want to eradicate as many safepoint VM
operations as possible, even if the usage would not really benefit from
the lack of stop-the-world pauses. That said, of course this has to be
tempered against the complexity of the change. But we are establishing a
pattern for coding up JVMTI operation as direct handshakes, which should
make things generally more easy to understand.
Cheers,
David
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
