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 <suen...@oss.nttdata.com> Sent: Freitag, 28. August 2020 15:15 To: Reingruber, Richard <richard.reingru...@sap.com>; David Holmes <david.hol...@oracle.com>; serviceability-dev <serviceability-dev@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 <suen...@oss.nttdata.com> > Sent: Freitag, 28. August 2020 10:42 > To: Reingruber, Richard <richard.reingru...@sap.com>; David Holmes > <david.hol...@oracle.com>; serviceability-dev > <serviceability-dev@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.hol...@oracle.com> >> Sent: Freitag, 28. August 2020 03:53 >> To: Yasumasa Suenaga <suen...@oss.nttdata.com>; Reingruber, Richard >> <richard.reingru...@sap.com>; serviceability-dev >> <serviceability-dev@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 <suen...@oss.nttdata.com> >>>> Sent: Donnerstag, 27. August 2020 01:30 >>>> To: Reingruber, Richard <richard.reingru...@sap.com>; >>>> serviceability-dev <serviceability-dev@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-r...@openjdk.java.net> >>>>> On Behalf Of Yasumasa Suenaga >>>>> Sent: Montag, 24. August 2020 04:40 >>>>> To: serviceability-dev <serviceability-dev@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 >>>>>
