8242427: JVMTI frame pop operations should use Thread-Local Handshakes

[Reingruber, Richard]

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 <suenaga at oss.nttdata.com> 
Sent: Donnerstag, 27. August 2020 01:30
To: Reingruber, Richard <richard.reingruber at sap.com>; serviceability-dev <serviceability-dev at openjdk.java.net>
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 <serviceability-dev-retn at openjdk.java.net> On Behalf Of Yasumasa Suenaga
> Sent: Montag, 24. August 2020 04:40
> To: serviceability-dev <serviceability-dev at openjdk.java.net>
> 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
>