Excellent. Thanks! Richard. -----Original Message----- From: serguei.spit...@oracle.com <serguei.spit...@oracle.com> Sent: Dienstag, 2. Juni 2020 20:02 To: Reingruber, Richard <richard.reingru...@sap.com>; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net; hotspot-gc-...@openjdk.java.net Subject: Re: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Richard, On 6/2/20 10:57, Reingruber, Richard wrote: > Hi Serguei, > >> This looks good to me. > Thanks! > > From an earlier mail: > >> I'm thinking it would be more safe to run full tier5. > I guess we're done with reviewing. Would be good if you could run full tier5 > now. After that I would > like to push. Okay, I'll submit a mach5 job with your fix and let you know about the results. Thanks, Serguei > Thanks, Richard. > > -----Original Message----- > From: serguei.spit...@oracle.com <serguei.spit...@oracle.com> > Sent: Dienstag, 2. Juni 2020 18:55 > To: Vladimir Kozlov <vladimir.koz...@oracle.com>; Reingruber, Richard > <richard.reingru...@sap.com>; serviceability-dev@openjdk.java.net; > hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net; > hotspot-gc-...@openjdk.java.net > Subject: Re: RFR(S) 8238585: Use handshake for > JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled > methods on stack not_entrant > > Hi Richard, > > This looks good to me. > > Thanks, > Serguei > > > On 5/28/20 09:02, Vladimir Kozlov wrote: >> Vladimir Ivanov is on break currently. >> It looks good to me. >> >> Thanks, >> Vladimir K >> >> On 5/26/20 7:31 AM, Reingruber, Richard wrote: >>> Hi Vladimir, >>> >>>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>>> Not an expert in JVMTI code base, so can't comment on the actual >>>> changes. >>>> From JIT-compilers perspective it looks good. >>> I put out webrev.1 a while ago [1]: >>> >>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/ >>> Webrev(delta): >>> http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/ >>> >>> You originally suggested to use a handshake to switch a thread into >>> interpreter mode [2]. I'm using >>> a direct handshake now, because I think it is the best fit. >>> >>> May I ask if webrev.1 still looks good to you from JIT-compilers >>> perspective? >>> >>> Can I list you as (partial) Reviewer? >>> >>> Thanks, Richard. >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/031245.html >>> [2] >>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030340.html >>> >>> -----Original Message----- >>> From: Vladimir Ivanov <vladimir.x.iva...@oracle.com> >>> Sent: Freitag, 7. Februar 2020 09:19 >>> To: Reingruber, Richard <richard.reingru...@sap.com>; >>> serviceability-dev@openjdk.java.net; >>> hotspot-compiler-...@openjdk.java.net >>> Subject: Re: RFR(S) 8238585: Use handshake for >>> JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make >>> compiled methods on stack not_entrant >>> >>> >>>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ >>> Not an expert in JVMTI code base, so can't comment on the actual >>> changes. >>> >>> From JIT-compilers perspective it looks good. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8238585 >>>> >>>> The change avoids making all compiled methods on stack not_entrant >>>> when switching a java thread to >>>> interpreter only execution for jvmti purposes. It is sufficient to >>>> deoptimize the compiled frames on stack. >>>> >>>> Additionally a handshake is used instead of a vm operation to walk >>>> the stack and do the deoptimizations. >>>> >>>> Testing: JCK and JTREG tests, also in Xcomp mode with fastdebug and >>>> release builds on all platforms. >>>> >>>> Thanks, Richard. >>>> >>>> See also my question if anyone knows a reason for making the >>>> compiled methods not_entrant: >>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-January/030339.html >>>> >>>>
