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

Fri Aug 28 08:41:34 UTC 2020

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