Hi Yasumasa, VM_DeoptimizeFrame can be replaced too I'd think.
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 >>>>
