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

[Yasumasa Suenaga]

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 <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
>>