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