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

Fri Aug 28 13:45:47 UTC 2020

Hi Yasumasa,

then this was a misunderstanding. I thought you were saying you covered all vm
operations in the JVMTI subsystem that can be replaced with handshakes.

I wanted to state that I think that local variable access does not require
global synchronization (i.e. a safepoint) and that it is feasible to use
handshakes for it.

Cheers, Richard.

-----Original Message-----
From: Yasumasa Suenaga <suenaga at oss.nttdata.com> 
Sent: Freitag, 28. August 2020 15:15
To: Reingruber, Richard <richard.reingruber at sap.com>; David Holmes <david.holmes at oracle.com>; serviceability-dev <serviceability-dev at openjdk.java.net>
Subject: Re: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes

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 <suenaga at oss.nttdata.com>
> Sent: Freitag, 28. August 2020 10:42
> To: Reingruber, Richard <richard.reingruber at sap.com>; David Holmes <david.holmes at oracle.com>; serviceability-dev <serviceability-dev at openjdk.java.net>
> 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 <david.holmes at oracle.com>
>> Sent: Freitag, 28. August 2020 03:53
>> To: Yasumasa Suenaga <suenaga at oss.nttdata.com>; 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
>>
>> 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 <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
>>>>>