[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-serviceability-dev
Subject: RE: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes
From: "Reingruber, Richard" <richard.reingruber () sap ! com>
Date: 2020-08-28 13:45:47
Message-ID: AM6PR0202MB3333F459A4D0112ADB276A0A9B520 () AM6PR0202MB3333 ! eurprd02 ! prod ! outlook ! com
[Download RAW message or body]
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 <suenaga@oss.nttdata.com>
Sent: Freitag, 28. August 2020 15:15
To: Reingruber, Richard <richard.reingruber@sap.com>; David Holmes \
<david.holmes@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 <suenaga@oss.nttdata.com>
> Sent: Freitag, 28. August 2020 10:42
> To: Reingruber, Richard <richard.reingruber@sap.com>; David Holmes \
> <david.holmes@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.holmes@oracle.com>
> > Sent: Freitag, 28. August 2020 03:53
> > To: Yasumasa Suenaga <suenaga@oss.nttdata.com>; Reingruber, Richard \
> > <richard.reingruber@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 <suenaga@oss.nttdata.com>
> > > > Sent: Donnerstag, 27. August 2020 01:30
> > > > To: Reingruber, Richard <richard.reingruber@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-retn@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
> > > > >
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic