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

Fri Aug 28 08:11:31 UTC 2020

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.

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