RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
> Hi Richard, > I suspect this one fell off the radar due to the extended review period. > The actual review started last December (there was prior discussion > IIRC) and only seemed to get partial reviews. I only looked at some > parts. Robbin may have given things a deeper look, but seemed focused on > the handshake aspects. Vladimir said he would do a full review but I > can't find it. Eventually Martin and Goetz took over reviewing and > everyone else dropped off. :( That's how it went I reckon. I repeatedly asked for feedback and reviews, and also tried to keep Vladimir, Robbin, and you in the loop addressing you directly (e.g. [1]) > As this covers a number of areas it really does need "approval" from > each area (and yes the hotspot wiki should reflect this). I agree. The wiki should define that in a clear manner. And the community should be involved in that definition. > I will try to take another look while we await Serguei's return (and I > never did follow up on the problem I had with the nested lock > elimination handling. :( ). Thanks for doing it. > Meanwhile this will need to be converted to a PR in any case. I hope to get the PR out later but we've got a team outing today... we haven't seen each other since months... :) Cheers, Richard. [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/030911.html -Original Message- From: David Holmes Sent: Mittwoch, 9. September 2020 00:29 To: Reingruber, Richard ; Marty Thompson ; Daniel Daugherty ; serviceability-dev ; hotspot-compiler-...@openjdk.java.net; Hotspot dev runtime ; Robbin Ehn ; Vladimir Kozlov Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, I suspect this one fell off the radar due to the extended review period. The actual review started last December (there was prior discussion IIRC) and only seemed to get partial reviews. I only looked at some parts. Robbin may have given things a deeper look, but seemed focused on the handshake aspects. Vladimir said he would do a full review but I can't find it. Eventually Martin and Goetz took over reviewing and everyone else dropped off. :( As this covers a number of areas it really does need "approval" from each area (and yes the hotspot wiki should reflect this). I will try to take another look while we await Serguei's return (and I never did follow up on the problem I had with the nested lock elimination handling. :( ). Meanwhile this will need to be converted to a PR in any case. Thanks, David On 9/09/2020 3:02 am, Reingruber, Richard wrote: > Hello Marty, > > Sure. I'd be happy if Serguei could review the change. > > Thanks, Richard. > > -Original Message- > From: Marty Thompson > Sent: Dienstag, 8. September 2020 18:55 > To: Reingruber, Richard ; Daniel Daugherty > ; serviceability-dev > ; hotspot-compiler-...@openjdk.java.net; > Hotspot dev runtime > Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in > the Presence of JVMTI Agents > > Hello Richard, > > It would be good if Serguei Spitsyn could review before this is pushed. > Serguei is out this week. Can you wait until Serguei is back in the office > the week of Sept 14? > > Regards, > > Marty > >> -Original Message- >> From: Reingruber, Richard >> Sent: Tuesday, September 8, 2020 9:45 AM >> To: Daniel Daugherty ; serviceability-dev >> ; hotspot-compiler- >> d...@openjdk.java.net; Hotspot dev runtime > d...@openjdk.java.net> >> Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance >> in the Presence of JVMTI Agents >> >> Hi Dan, >> >> I'd be very happy about a review from somebody on the Serviceability team. >> I have asked for reviews many times (kindly I hope). And the change is for >> review for more than a year now. >> >> According to [1] I'd think all requirements to push are met already. But >> maybe I missed something? >> >> After renaming of methods in SafepointMechanism the change needs to be >> rebased (already done). I'll publish a pull request as soon as possible. >> >> Thanks, Richard. >> >> [1] >> https://wiki.openjdk.java.net/display/HotSpot/Pushing+a+HotSpot+change >> >> -Original Message- >> From: Daniel D. Daugherty >> Sent: Dienstag, 8. September 2020 18:16 >> To: Reingruber, Richard ; serviceability-dev >> ; hotspot-compiler- >> d...@openjdk.java.net; Hotspot dev runtime > d...@openjdk.java.net> >> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance >> in the P
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hello Marty, Sure. I'd be happy if Serguei could review the change. Thanks, Richard. -Original Message- From: Marty Thompson Sent: Dienstag, 8. September 2020 18:55 To: Reingruber, Richard ; Daniel Daugherty ; serviceability-dev ; hotspot-compiler-...@openjdk.java.net; Hotspot dev runtime Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hello Richard, It would be good if Serguei Spitsyn could review before this is pushed. Serguei is out this week. Can you wait until Serguei is back in the office the week of Sept 14? Regards, Marty > -Original Message- > From: Reingruber, Richard > Sent: Tuesday, September 8, 2020 9:45 AM > To: Daniel Daugherty ; serviceability-dev > ; hotspot-compiler- > d...@openjdk.java.net; Hotspot dev runtime d...@openjdk.java.net> > Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance > in the Presence of JVMTI Agents > > Hi Dan, > > I'd be very happy about a review from somebody on the Serviceability team. > I have asked for reviews many times (kindly I hope). And the change is for > review for more than a year now. > > According to [1] I'd think all requirements to push are met already. But > maybe I missed something? > > After renaming of methods in SafepointMechanism the change needs to be > rebased (already done). I'll publish a pull request as soon as possible. > > Thanks, Richard. > > [1] > https://wiki.openjdk.java.net/display/HotSpot/Pushing+a+HotSpot+change > > -Original Message- > From: Daniel D. Daugherty > Sent: Dienstag, 8. September 2020 18:16 > To: Reingruber, Richard ; serviceability-dev > ; hotspot-compiler- > d...@openjdk.java.net; Hotspot dev runtime d...@openjdk.java.net> > Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance > in the Presence of JVMTI Agents > > Hi Richard, > > I haven't seen a review from anyone on the Serviceability team and I think > you should get a review from them since JVM/TI is involved. > Perhaps I missed it... > > Dan > > > On 9/7/20 10:09 AM, Reingruber, Richard wrote: > > Hi, > > > > I would like to close the review of this change. > > > > It has received a lot of helpful feedback during the process and 2 > > full Reviews. Thanks everybody! > > > > I'm planning to push it this week on Thursday as solution for JBS items: > > > > https://bugs.openjdk.java.net/browse/JDK-8227745 > > https://bugs.openjdk.java.net/browse/JDK-8233915 > > > > Version to be pushed: > > > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > > > Hope to get my GIT/Skara setup going until then... :) > > > > Thanks, Richard. > > > > -Original Message- > > From: hotspot-compiler-dev > > On Behalf Of Reingruber, > > Richard > > Sent: Mittwoch, 2. September 2020 23:27 > > To: Robbin Ehn ; serviceability-dev > > ; > > hotspot-compiler-...@openjdk.java.net; Hotspot dev runtime > > > > Subject: [CAUTION] RE: RFR(L) 8227745: Enable Escape Analysis for > > Better Performance in the Presence of JVMTI Agents > > > > Hi Robin, > > > >> On 2020-09-02 15:48, Reingruber, Richard wrote: > >>> Hi Robbin, > >>> > >>> // taking the discussion back to the mailing lists > >>> > >>> > I still don't understand why you don't deoptimize the objects inside > the > >>> > handshake/safepoint instead? > >> So for handshakes using asynch handshake and allowing blocking inside > >> would fix that. (future fix, I'm working on that now) > > Just to make it clear: I'm not fond of the extra suspension mechanism > > currently used for JDK-8227745 either. I want to get rid of it and I > > will work on it. Asynch handshakes (JDK-8238761) could be a > > replacement for it. At least I think they can be used to suspend the target > thread. > > > >> For safepoint, since we have suspended all threads, ~'safepointed them' > >> with a JavaThread, you _could_ just execute the action directly (e.g. > >> skipping VM_HeapWalkOperation safepoint) since they are suppose to be > >> safely suspended until the destructor of EB, no? > > Yes, this should be possible. This would be an advanced change though. > > I would like EscapeBarriers to be a no-op and fall back to current > > implementation, if C2-EscapeAnalysis/Graal are disabled. > > > >> So I suggest future work to instead just execute the safepoint with >
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Dan, I'd be very happy about a review from somebody on the Serviceability team. I have asked for reviews many times (kindly I hope). And the change is for review for more than a year now. According to [1] I'd think all requirements to push are met already. But maybe I missed something? After renaming of methods in SafepointMechanism the change needs to be rebased (already done). I'll publish a pull request as soon as possible. Thanks, Richard. [1] https://wiki.openjdk.java.net/display/HotSpot/Pushing+a+HotSpot+change -Original Message- From: Daniel D. Daugherty Sent: Dienstag, 8. September 2020 18:16 To: Reingruber, Richard ; serviceability-dev ; hotspot-compiler-...@openjdk.java.net; Hotspot dev runtime Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, I haven't seen a review from anyone on the Serviceability team and I think you should get a review from them since JVM/TI is involved. Perhaps I missed it... Dan On 9/7/20 10:09 AM, Reingruber, Richard wrote: > Hi, > > I would like to close the review of this change. > > It has received a lot of helpful feedback during the process and 2 full > Reviews. Thanks everybody! > > I'm planning to push it this week on Thursday as solution for JBS items: > > https://bugs.openjdk.java.net/browse/JDK-8227745 > https://bugs.openjdk.java.net/browse/JDK-8233915 > > Version to be pushed: > > http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ > > Hope to get my GIT/Skara setup going until then... :) > > Thanks, Richard. > > -Original Message- > From: hotspot-compiler-dev On > Behalf Of Reingruber, Richard > Sent: Mittwoch, 2. September 2020 23:27 > To: Robbin Ehn ; serviceability-dev > ; hotspot-compiler-...@openjdk.java.net; > Hotspot dev runtime > Subject: [CAUTION] RE: RFR(L) 8227745: Enable Escape Analysis for Better > Performance in the Presence of JVMTI Agents > > Hi Robin, > >> On 2020-09-02 15:48, Reingruber, Richard wrote: >>> Hi Robbin, >>> >>> // taking the discussion back to the mailing lists >>> >>> > I still don't understand why you don't deoptimize the objects inside >>> the >>> > handshake/safepoint instead? >> So for handshakes using asynch handshake and allowing blocking inside >> would fix that. (future fix, I'm working on that now) > Just to make it clear: I'm not fond of the extra suspension mechanism > currently > used for JDK-8227745 either. I want to get rid of it and I will work on it. > Asynch > handshakes (JDK-8238761) could be a replacement for it. At least I think they > can be used to suspend the target thread. > >> For safepoint, since we have suspended all threads, ~'safepointed them' >> with a JavaThread, you _could_ just execute the action directly (e.g. >> skipping VM_HeapWalkOperation safepoint) since they are suppose to be >> safely suspended until the destructor of EB, no? > Yes, this should be possible. This would be an advanced change though. I would > like EscapeBarriers to be a no-op and fall back to current implementation, if > C2-EscapeAnalysis/Graal are disabled. > >> So I suggest future work to instead just execute the safepoint with the >> requesting JT instead of having a this special safepoiting mechanism. >> Since you are missing above functionality I see why you went this way. >> If you need to push it, it's fine by me. > We will work on further improvements. Top of the list would > be eliminating the extra suspend mechanism. > > The implementation has matured for more than 12 months now [1]. It's been > tested > extensively at SAP over that time and passed also extended testing at Oracle > kindly conducted by Vladimir Kozlov. We've got two full Reviews and > incorporated > extensive feedback from a number of OpenJDK Reviewers (including you, > thanks!). Based on that I reckon we're good to push the change as enhancement > (JDK-8227745) and bug fix (JDK-8233915). > >> Thanks for explaining once again :) > Pleasure :) > > Thanks, Richard. > > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-July/028729.html > > -Original Message- > From: Robbin Ehn > Sent: Mittwoch, 2. September 2020 16:54 > To: Reingruber, Richard ; serviceability-dev > ; hotspot-compiler-...@openjdk.java.net; > Hotspot dev runtime > Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in > the Presence of JVMTI Agents > > Hi Richard, > > On 2020-09-02 15:48, Reingruber, Richard wrote: >> Hi Robbin, >> >> // takin
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi, I would like to close the review of this change. It has received a lot of helpful feedback during the process and 2 full Reviews. Thanks everybody! I'm planning to push it this week on Thursday as solution for JBS items: https://bugs.openjdk.java.net/browse/JDK-8227745 https://bugs.openjdk.java.net/browse/JDK-8233915 Version to be pushed: http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/ Hope to get my GIT/Skara setup going until then... :) Thanks, Richard. -Original Message- From: hotspot-compiler-dev On Behalf Of Reingruber, Richard Sent: Mittwoch, 2. September 2020 23:27 To: Robbin Ehn ; serviceability-dev ; hotspot-compiler-...@openjdk.java.net; Hotspot dev runtime Subject: [CAUTION] RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Robin, > On 2020-09-02 15:48, Reingruber, Richard wrote: > > Hi Robbin, > > > > // taking the discussion back to the mailing lists > > > >> I still don't understand why you don't deoptimize the objects inside > > the > >> handshake/safepoint instead? > So for handshakes using asynch handshake and allowing blocking inside > would fix that. (future fix, I'm working on that now) Just to make it clear: I'm not fond of the extra suspension mechanism currently used for JDK-8227745 either. I want to get rid of it and I will work on it. Asynch handshakes (JDK-8238761) could be a replacement for it. At least I think they can be used to suspend the target thread. > For safepoint, since we have suspended all threads, ~'safepointed them' > with a JavaThread, you _could_ just execute the action directly (e.g. > skipping VM_HeapWalkOperation safepoint) since they are suppose to be > safely suspended until the destructor of EB, no? Yes, this should be possible. This would be an advanced change though. I would like EscapeBarriers to be a no-op and fall back to current implementation, if C2-EscapeAnalysis/Graal are disabled. > So I suggest future work to instead just execute the safepoint with the > requesting JT instead of having a this special safepoiting mechanism. > Since you are missing above functionality I see why you went this way. > If you need to push it, it's fine by me. We will work on further improvements. Top of the list would be eliminating the extra suspend mechanism. The implementation has matured for more than 12 months now [1]. It's been tested extensively at SAP over that time and passed also extended testing at Oracle kindly conducted by Vladimir Kozlov. We've got two full Reviews and incorporated extensive feedback from a number of OpenJDK Reviewers (including you, thanks!). Based on that I reckon we're good to push the change as enhancement (JDK-8227745) and bug fix (JDK-8233915). > Thanks for explaining once again :) Pleasure :) Thanks, Richard. [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-July/028729.html -Original Message- From: Robbin Ehn Sent: Mittwoch, 2. September 2020 16:54 To: Reingruber, Richard ; serviceability-dev ; hotspot-compiler-...@openjdk.java.net; Hotspot dev runtime Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, On 2020-09-02 15:48, Reingruber, Richard wrote: > Hi Robbin, > > // taking the discussion back to the mailing lists > >> I still don't understand why you don't deoptimize the objects inside the >> handshake/safepoint instead? So for handshakes using asynch handshake and allowing blocking inside would fix that. (future fix, I'm working on that now) For safepoint, since we have suspended all threads, ~'safepointed them' with a JavaThread, you _could_ just execute the action directly (e.g. skipping VM_HeapWalkOperation safepoint) since they are suppose to be safely suspended until the destructor of EB, no? So I suggest future work to instead just execute the safepoint with the requesting JT instead of having a this special safepoiting mechanism. Since you are missing above functionality I see why you went this way. If you need to push it, it's fine by me. Thanks for explaining once again :) /Robbin > > This is unfortunately not possible. Deoptimizing objects includes reallocating > scalar replaced objects, i.e. calling Deoptimization::realloc_objects(). This > cannot be done at a safepoint or handshake. > > 1. The vm thread is not allowed to allocate on the java heap > See for instance assertions in ParallelScavengeHeap::mem_allocate() > > https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/4c73e045ce815d52abcdc99499266ccf2e6e9b4c/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp*L258__;Iw!!GqivPVa7Brio!K0f5chjtePI6MKBSBOoBKya9YZTJlVhsExQYMDO96v3Af_Klc_E4R26_d
RE: RFR(XS) 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT
Hi David, > > > > Furthermore I have corrected the type of the parameter waitCycles of > > Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocal() to be jint. Now it > > matches the declaration in GetLocalWithoutSuspendTest.java. > Hmmm ... could this mean that the attempt to read a 64-bit value where > only a 32-bit value had actually been pushed as a parameter, could > result in reading a junk value that sometimes caused the loop to exit > immediately? On Linux x86_64 32 bit integers would be sign extended to 64 bit integers [1][2] except if passing in register [3]. The 4th parameter would be passed in a register. And that's only the native wrapper case. For the interpreter I couldn't figure it out in 5min. Long story short: maybe. I conducted tests (40x concurrently) where the target never waited in native but did not get a JVMTI_ERROR_INVALID_SLOT. The string construction for the log() calls is the only code I see that could produce the error. But I'd expect the stack to be too shallow there. targetDepth is usually well above 1000. So we would get JVMTI_ERROR_NO_MORE_FRAMES. I'm unsure what happens if the safepoint stops the target thread at a poll return (CompiledMethod::is_at_poll_return()). I will try that also. Likely not before monday. Thanks, Richard. [1] Passing 32 bit value to native function https://github.com/openjdk/jdk/blob/57a27a6fb981a474ce7a6fbad0ec9e4f7164857e/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L2383 [2] move32_64 https://github.com/openjdk/jdk/blob/57a27a6fb981a474ce7a6fbad0ec9e4f7164857e/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1126 [3] move32_64 register to register https://github.com/openjdk/jdk/blob/57a27a6fb981a474ce7a6fbad0ec9e4f7164857e/src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp#L1145 -Original Message- From: David Holmes Sent: Donnerstag, 3. September 2020 00:24 To: Reingruber, Richard ; serviceability-dev Subject: Re: RFR(XS) 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT Hi Richard, On 3/09/2020 12:37 am, Reingruber, Richard wrote: > Hi, > > please help review this fix for a TESTBUG in > serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8252593/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8252593 > > With this change the JVMTI test agent silently accepts > JVMTI_ERROR_INVALID_SLOT as result of a JVMTI GetLocalObject() call. > The target frame of the call varies because the target thread is running. In > rare cases it might not be one of the many frames of > GetLocalWithoutSuspendTest.recursiveMethod() as intended but the frame > of a static method without parameters which the target thread might call > after > returning from all the recursive calls. This would result in > JVMTI_ERROR_INVALID_SLOT. > > Anyway JVMTI_ERROR_INVALID_SLOT has to be expected and should be silently > ignored. > > Furthermore I have corrected the type of the parameter waitCycles of > Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocal() to be jint. Now it > matches the declaration in GetLocalWithoutSuspendTest.java. Hmmm ... could this mean that the attempt to read a 64-bit value where only a 32-bit value had actually been pushed as a parameter, could result in reading a junk value that sometimes caused the loop to exit immediately? David > Thanks, Richard. >
RE: RFR(XS) 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT
Hi Serguei, > This looks reasonable to me. Thanks! > The only question is about the quality of this testing. > How are we sure these errors are caused by races but not bugs in the > GetLocalObject implementation? I'm not sure. Unfortunately I cannot reproduce it even though I tried. I had 40 instances of the test running concurrently over night without failure. I did the GetLocalObject call for every frame on stack while the target was sleeping in Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocal(). My best guess would be that the harness methods on stack are compiled differently @Oracle, e.g. without local variable table. Or the test is run with -Xcomp (tried that also). Can we get the jtr file of the failure? Would be nice if we could add some tracing to the vm. Thanks, Richard. From: serguei.spit...@oracle.com Sent: Mittwoch, 2. September 2020 20:06 To: Reingruber, Richard ; serviceability-dev Subject: Re: RFR(XS) 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT Hi Richard, This looks reasonable to me. The only question is about the quality of this testing. How are we sure these errors are caused by races but not bugs in the GetLocalObject implementation? Thanks, Serguei On 9/2/20 07:37, Reingruber, Richard wrote: Hi, please help review this fix for a TESTBUG in serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8252593/webrev.0/ Bug:https://bugs.openjdk.java.net/browse/JDK-8252593 With this change the JVMTI test agent silently accepts JVMTI_ERROR_INVALID_SLOT as result of a JVMTI GetLocalObject() call. The target frame of the call varies because the target thread is running. In rare cases it might not be one of the many frames of GetLocalWithoutSuspendTest.recursiveMethod() as intended but the frame of a static method without parameters which the target thread might call after returning from all the recursive calls. This would result in JVMTI_ERROR_INVALID_SLOT. Anyway JVMTI_ERROR_INVALID_SLOT has to be expected and should be silently ignored. Furthermore I have corrected the type of the parameter waitCycles of Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocal() to be jint. Now it matches the declaration in GetLocalWithoutSuspendTest.java. Thanks, Richard.
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Robin, > On 2020-09-02 15:48, Reingruber, Richard wrote: > > Hi Robbin, > > > > // taking the discussion back to the mailing lists > > > >> I still don't understand why you don't deoptimize the objects inside > > the > >> handshake/safepoint instead? > So for handshakes using asynch handshake and allowing blocking inside > would fix that. (future fix, I'm working on that now) Just to make it clear: I'm not fond of the extra suspension mechanism currently used for JDK-8227745 either. I want to get rid of it and I will work on it. Asynch handshakes (JDK-8238761) could be a replacement for it. At least I think they can be used to suspend the target thread. > For safepoint, since we have suspended all threads, ~'safepointed them' > with a JavaThread, you _could_ just execute the action directly (e.g. > skipping VM_HeapWalkOperation safepoint) since they are suppose to be > safely suspended until the destructor of EB, no? Yes, this should be possible. This would be an advanced change though. I would like EscapeBarriers to be a no-op and fall back to current implementation, if C2-EscapeAnalysis/Graal are disabled. > So I suggest future work to instead just execute the safepoint with the > requesting JT instead of having a this special safepoiting mechanism. > Since you are missing above functionality I see why you went this way. > If you need to push it, it's fine by me. We will work on further improvements. Top of the list would be eliminating the extra suspend mechanism. The implementation has matured for more than 12 months now [1]. It's been tested extensively at SAP over that time and passed also extended testing at Oracle kindly conducted by Vladimir Kozlov. We've got two full Reviews and incorporated extensive feedback from a number of OpenJDK Reviewers (including you, thanks!). Based on that I reckon we're good to push the change as enhancement (JDK-8227745) and bug fix (JDK-8233915). > Thanks for explaining once again :) Pleasure :) Thanks, Richard. [1] http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-July/028729.html -Original Message- From: Robbin Ehn Sent: Mittwoch, 2. September 2020 16:54 To: Reingruber, Richard ; serviceability-dev ; hotspot-compiler-...@openjdk.java.net; Hotspot dev runtime Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, On 2020-09-02 15:48, Reingruber, Richard wrote: > Hi Robbin, > > // taking the discussion back to the mailing lists > >> I still don't understand why you don't deoptimize the objects inside the >> handshake/safepoint instead? So for handshakes using asynch handshake and allowing blocking inside would fix that. (future fix, I'm working on that now) For safepoint, since we have suspended all threads, ~'safepointed them' with a JavaThread, you _could_ just execute the action directly (e.g. skipping VM_HeapWalkOperation safepoint) since they are suppose to be safely suspended until the destructor of EB, no? So I suggest future work to instead just execute the safepoint with the requesting JT instead of having a this special safepoiting mechanism. Since you are missing above functionality I see why you went this way. If you need to push it, it's fine by me. Thanks for explaining once again :) /Robbin > > This is unfortunately not possible. Deoptimizing objects includes reallocating > scalar replaced objects, i.e. calling Deoptimization::realloc_objects(). This > cannot be done at a safepoint or handshake. > > 1. The vm thread is not allowed to allocate on the java heap > See for instance assertions in ParallelScavengeHeap::mem_allocate() > > https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/4c73e045ce815d52abcdc99499266ccf2e6e9b4c/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp*L258__;Iw!!GqivPVa7Brio!K0f5chjtePI6MKBSBOoBKya9YZTJlVhsExQYMDO96v3Af_Klc_E4R26_dSyowotF$ > > This is not easy to change, I suppose, because it will be difficult to gc > if > necessary. > > 2. Using a direct handshake would not work either. The problem there is again > gc. Let J be the JavaThread that is executing the direct handshake. The vm > would deadlock if the vm thread waits for J to execute the closure of a > handshake-all and J waits for the vm thread to execute a gc vm operation. > Patricio Chilano made me aware of this: > https://bugs.openjdk.java.net/browse/JDK-8230594 > > Cheers, Richard. > > -Original Message- > From: Robbin Ehn > Sent: Mittwoch, 2. September 2020 13:56 > To: Reingruber, Richard > Cc: Lindenmaier, Goetz ; Vladimir Kozlov > ; David Holmes > Subject: Re: RFR(L) 8227745: En
RFR(XS) 8252593: [TESTBUG] serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java failed with JVMTI_ERROR_INVALID_SLOT
Hi, please help review this fix for a TESTBUG in serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8252593/webrev.0/ Bug:https://bugs.openjdk.java.net/browse/JDK-8252593 With this change the JVMTI test agent silently accepts JVMTI_ERROR_INVALID_SLOT as result of a JVMTI GetLocalObject() call. The target frame of the call varies because the target thread is running. In rare cases it might not be one of the many frames of GetLocalWithoutSuspendTest.recursiveMethod() as intended but the frame of a static method without parameters which the target thread might call after returning from all the recursive calls. This would result in JVMTI_ERROR_INVALID_SLOT. Anyway JVMTI_ERROR_INVALID_SLOT has to be expected and should be silently ignored. Furthermore I have corrected the type of the parameter waitCycles of Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocal() to be jint. Now it matches the declaration in GetLocalWithoutSuspendTest.java. Thanks, Richard.
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Robbin,
// taking the discussion back to the mailing lists
> I still don't understand why you don't deoptimize the objects inside the
> handshake/safepoint instead?
This is unfortunately not possible. Deoptimizing objects includes reallocating
scalar replaced objects, i.e. calling Deoptimization::realloc_objects(). This
cannot be done at a safepoint or handshake.
1. The vm thread is not allowed to allocate on the java heap
See for instance assertions in ParallelScavengeHeap::mem_allocate()
https://github.com/openjdk/jdk/blob/4c73e045ce815d52abcdc99499266ccf2e6e9b4c/src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp#L258
This is not easy to change, I suppose, because it will be difficult to gc if
necessary.
2. Using a direct handshake would not work either. The problem there is again
gc. Let J be the JavaThread that is executing the direct handshake. The vm
would deadlock if the vm thread waits for J to execute the closure of a
handshake-all and J waits for the vm thread to execute a gc vm operation.
Patricio Chilano made me aware of this:
https://bugs.openjdk.java.net/browse/JDK-8230594
Cheers, Richard.
-Original Message-
From: Robbin Ehn
Sent: Mittwoch, 2. September 2020 13:56
To: Reingruber, Richard
Cc: Lindenmaier, Goetz ; Vladimir Kozlov
; David Holmes
Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi,
I still don't understand why you don't deoptimize the objects inside the
handshake/safepoint instead?
E.g.
JvmtiEnv::GetOwnedMonitorInfo you only should need the execute the code
from:
eb.deoptimize_objects(MaxJavaStackTraceDepth)) before looping over the
stack, so:
void
GetOwnedMonitorInfoClosure::do_thread(Thread *target) {
assert(target->is_Java_thread(), "just checking");
JavaThread *jt = (JavaThread *)target;
if (!jt->is_exiting() && (jt->threadObj() != NULL)) {
+if (EscapeBarrier::deoptimize_objects(jt, MaxJavaStackTraceDepth)) {
_result =
((JvmtiEnvBase*)_env)->get_owned_monitors(_calling_thread, jt,
_owned_monitors_list);
} else {
_result = JVMTI_ERROR_OUT_OF_MEMORY;
}
}
}
Why try 'suspend' the thread first?
When we de-optimize all threads why not just in the following safepoint?
E.g.
VM_HeapWalkOperation::doit() {
+ EscapeBarrier::deoptimize_objects_all_threads();
...
}
Thanks, Robbin
RE: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes
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 Sent: Freitag, 28. August 2020 15:15 To: Reingruber, Richard ; David Holmes ; serviceability-dev 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 > Sent: Freitag, 28. August 2020 10:42 > To: Reingruber, Richard ; David Holmes > ; serviceability-dev > > 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 >> Sent: Freitag, 28. August 2020 03:53 >> To: Yasumasa Suenaga ; Reingruber, Richard >> ; serviceability-dev >> >> 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 thi
RE: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes
Hi Yasumasa, VM_DeoptimizeFrame can be replaced too I'd think. Cheers, Richard. -Original Message- From: Yasumasa Suenaga Sent: Freitag, 28. August 2020 10:42 To: Reingruber, Richard ; David Holmes ; serviceability-dev 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 > Sent: Freitag, 28. August 2020 03:53 > To: Yasumasa Suenaga ; Reingruber, Richard > ; serviceability-dev > > 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 but
RE: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes
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 Sent: Freitag, 28. August 2020 03:53 To: Yasumasa Suenaga ; Reingruber, Richard ; serviceability-dev 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 >> Sent: Donnerstag, 27. August 2020 01:3
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Thanks a lot!
Richard.
-Original Message-
From: Lindenmaier, Goetz
Sent: Freitag, 28. August 2020 08:38
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi Richard,
Thanks for the new webrev.
The small improvements are fine, too.
Reviewed from my side.
Best regards,
Goetz.
> -Original Message-
> From: Reingruber, Richard
> Sent: Thursday, August 27, 2020 10:33 PM
> To: Lindenmaier, Goetz ; serviceability-
> d...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-
> runtime-...@openjdk.java.net
> Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance
> in the Presence of JVMTI Agents
>
> Hi Goetz,
>
> > I read through your change again. It looks good to me now.
> > The new naming and additional comments make it
> > easier to read I think, thank you.
>
> Thanks for all your input!
>
> > One small thing:
> > deoptimization.cpp, l. 1503
> > You don't really need the brackets. Two lines below you don't use them
> either.
> > (No webrev needed)
>
> Thanks for providing the correct line off list. Fixed!
>
> I prepared a new webrev, because I had to rebase after JDK-8249293 [1] and
> because I wanted to make use of JDK-8251384 [2]
>
> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
> Delta: http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8.inc/
>
> The delta looks bigger than it is. Most of it is re-indentation of
> VM_GetOrSetLocal::deoptimize_objects(). You can see this if you look at
>
> http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8.inc/src/hotsp
> ot/share/prims/jvmtiImpl.cpp.udiff.html
>
> which does not include the whitespace change.
>
> Hope you are still ok with webrev.8. The changes are marginal. I've
> commented
> each below.
>
> Thanks, Richard.
>
> --- Details below ---
>
> src/hotspot/share/prims/jvmtiImpl.cpp
>
> @@ -425,11 +425,11 @@
>, _depth(depth)
>, _index(index)
>, _type(type)
>, _jvf(NULL)
>, _set(false)
> - , _eb(NULL, NULL, false) // no references escape
> + , _eb(NULL, NULL, type == T_OBJECT)
>, _result(JVMTI_ERROR_NONE)
>
> Currently 'type' is never equal to T_OBJECT at this location, still I think it
> is better to check. The compiler will replace the compare with false.
>
> @@ -630,11 +630,11 @@
> }
>
> // Revert optimizations based on escape analysis if this is an access to a
> local object
> bool VM_GetOrSetLocal::deoptimize_objects(javaVFrame* jvf) {
> #if COMPILER2_OR_JVMCI
> - if (NOT_JVMCI(DoEscapeAnalysis &&) _type == T_OBJECT) {
> + assert(_type == T_OBJECT, "EscapeBarrier should not be active if _type !=
> T_OBJECT");
>
> I removed the if from VM_GetOrSetLocal::deoptimize_objects(), because
> now it
> only gets called if the VM_GetOrSetLocal instance has an active
> EscapeBarrier
> which will be the case iff the local type is T_OBJECT and if either C2 escape
> analysis is enabled or Graal is used.
>
> src/hotspot/share/runtime/deoptimization.cpp
>
> You suggested to remove the braces. Done.
>
> src/hotspot/share/runtime/deoptimization.hpp
>
> Must provide definition of EscapeBarrier::barrier_active() for new call site
> in
> VM_GetOrSetLocal::doit_prologue() if building with COMPILER2_OR_JVMCI
> not
> defined.
>
> test/hotspot/jtreg/serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysis
> Enabled.java
>
> Make use of [2] and pass test with minimal vm.
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8249293
> [2] https://bugs.openjdk.java.net/browse/JDK-8251384
>
> -Original Message-
> From: Lindenmaier, Goetz
> Sent: Samstag, 22. August 2020 07:46
> To: Reingruber, Richard ; serviceability-
> d...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-
> runtime-...@openjdk.java.net
> Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance
> in the Presence of JVMTI Agents
>
> Hi Richard,
>
> I read through your change again. It looks good to me now.
> The new naming and additional comments make it
> easier to read I think, thank you.
>
> One small thing:
> deoptimization.cpp, l. 1503
> You don't really need the brackets. Two lines below you don't use them
> either.
> (No webrev needed)
>
> Best regards,
> Goetz.
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Goetz,
> I read through your change again. It looks good to me now.
> The new naming and additional comments make it
> easier to read I think, thank you.
Thanks for all your input!
> One small thing:
> deoptimization.cpp, l. 1503
> You don't really need the brackets. Two lines below you don't use them either.
> (No webrev needed)
Thanks for providing the correct line off list. Fixed!
I prepared a new webrev, because I had to rebase after JDK-8249293 [1] and
because I wanted to make use of JDK-8251384 [2]
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8.inc/
The delta looks bigger than it is. Most of it is re-indentation of
VM_GetOrSetLocal::deoptimize_objects(). You can see this if you look at
http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.8.inc/src/hotspot/share/prims/jvmtiImpl.cpp.udiff.html
which does not include the whitespace change.
Hope you are still ok with webrev.8. The changes are marginal. I've commented
each below.
Thanks, Richard.
--- Details below ---
src/hotspot/share/prims/jvmtiImpl.cpp
@@ -425,11 +425,11 @@
, _depth(depth)
, _index(index)
, _type(type)
, _jvf(NULL)
, _set(false)
- , _eb(NULL, NULL, false) // no references escape
+ , _eb(NULL, NULL, type == T_OBJECT)
, _result(JVMTI_ERROR_NONE)
Currently 'type' is never equal to T_OBJECT at this location, still I think it
is better to check. The compiler will replace the compare with false.
@@ -630,11 +630,11 @@
}
// Revert optimizations based on escape analysis if this is an access to a
local object
bool VM_GetOrSetLocal::deoptimize_objects(javaVFrame* jvf) {
#if COMPILER2_OR_JVMCI
- if (NOT_JVMCI(DoEscapeAnalysis &&) _type == T_OBJECT) {
+ assert(_type == T_OBJECT, "EscapeBarrier should not be active if _type !=
T_OBJECT");
I removed the if from VM_GetOrSetLocal::deoptimize_objects(), because now it
only gets called if the VM_GetOrSetLocal instance has an active EscapeBarrier
which will be the case iff the local type is T_OBJECT and if either C2 escape
analysis is enabled or Graal is used.
src/hotspot/share/runtime/deoptimization.cpp
You suggested to remove the braces. Done.
src/hotspot/share/runtime/deoptimization.hpp
Must provide definition of EscapeBarrier::barrier_active() for new call site in
VM_GetOrSetLocal::doit_prologue() if building with COMPILER2_OR_JVMCI not
defined.
test/hotspot/jtreg/serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java
Make use of [2] and pass test with minimal vm.
[1] https://bugs.openjdk.java.net/browse/JDK-8249293
[2] https://bugs.openjdk.java.net/browse/JDK-8251384
-Original Message-
From: Lindenmaier, Goetz
Sent: Samstag, 22. August 2020 07:46
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi Richard,
I read through your change again. It looks good to me now.
The new naming and additional comments make it
easier to read I think, thank you.
One small thing:
deoptimization.cpp, l. 1503
You don't really need the brackets. Two lines below you don't use them either.
(No webrev needed)
Best regards,
Goetz.
RE: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes
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
Sent: Donnerstag, 27. August 2020 01:30
To: Reingruber, Richard ; serviceability-dev
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 On Behalf
> Of Yasumasa Suenaga
> Sent: Montag, 24. August 2020 04:40
> To: serviceability-dev
> 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
>
RE: 8242427: JVMTI frame pop operations should use Thread-Local Handshakes
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 On Behalf
Of Yasumasa Suenaga
Sent: Montag, 24. August 2020 04:40
To: serviceability-dev
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
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi Serguei,
thanks for your review.
> These two lines can be removed:
> 391 jvmtiEnv* jvmti;
> 406 ::jvmti = jvmti;
> No need in another webrev if you fix it.
I've made this change and fixed the copyright year in
jvmtiImpl.hpp. Unfortunately I got no results from the submit repo [1].
I've pushed again to submit. Will push to the jdk master repo when this job
reports success.
Thanks,
Richard.
[1]
https://mail.openjdk.java.net/pipermail/jdk-submit-changes/2020-August/012091.html
From: serguei.spit...@oracle.com
Sent: Freitag, 21. August 2020 18:48
To: Reingruber, Richard ; David Holmes
; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal::doit_prologue()
Hi Richard,
It looks good, thank you for the update!
These two lines can be removed:
391 jvmtiEnv* jvmti;
406 ::jvmti = jvmti;
No need in another webrev if you fix it.
Thanks,
Serguei
On 8/21/20 09:09, Reingruber, Richard wrote:
Hi Serguei,
I have prepared a new webrev based on your suggestions.
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.6/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.6.inc/
Thanks,
Richard.
__
From: serguei.spit...@oracle.com<mailto:serguei.spit...@oracle.com>
<mailto:serguei.spit...@oracle.com>
Sent: Freitag, 21. August 2020 11:22
To: Reingruber, Richard
<mailto:richard.reingru...@sap.com>; David Holmes
<mailto:david.hol...@oracle.com>;
serviceability-dev@openjdk.java.net<mailto:serviceability-dev@openjdk.java.net>
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal::doit_prologue()
Hi Richard,
Thank you for the update, it looks really nice.
Just several more minor comments though (I hope, the last ones).
Should I rename the variable to spinWaitCycles or something similar?
Yes, waitCycles would be better and more consistent.
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java.udiff.html
81 * The wait time is given in cycles.
82 */ 83 public int waitTime;
...
93 waitTime = 1;
This line 82 can be removed if you rename waitTime to waitCycles.
It is better to initialize waitCycles at definition and remove the line 93.
146 public static void msg(String m) {
147 System.out.println("### Java-Test: " + m);
148 }
One of the de-facto standard names for such methods is "log".
80 * Wait time in native, i.e. with walkable stack, after notifying
agent thread to do GetLocalObject() call.
89 msg("Test how many frames fit on the stack by performing recursive
calls until StackOverflowError is thrown");
Could you, please, reballance the two long lines above?
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp.frames.html
There are several spots that can be simplified a little bit:
95 jvmtiError result;
96
97 result = jvmti->GetErrorName(errCode, &errMsg);
==>
jvmtiError result = jvmti->GetErrorName(errCode, &errMsg);
The same is true for for the following cases:
115 err = jvmti->RawMonitorEnter(glws_monitor);
125 err = jvmti->RawMonitorExit(glws_monitor);
135 err = jvmti->RawMonitorWait(glws_monitor, 0);
145 err = jvmti->RawMonitorNotify(glws_monitor);
155 err = jvmti->DestroyRawMonitor(glws_monitor);
173 if (errMsg != NULL) {
An extra space before NULL.
89 static jvmtiEnv* jvmti_global = NULL;
276 jvmtiEnv* jvmti = jvmti_global;
308 jvmtiEnv* jvmti = jvmti_global;
330 jvmtiEnv* jvmti = jvmti_global;
...
409 jvmtiEnv* jvmti;
419 res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_9);
424 jvmti_global = jvmti;
Normal practice is to name the "global_jvmti" as "jvmti".
Then there is no need to set it at the start of each function.
Thanks,
Serguei
On 8/20/20 23:47, Reingruber, Richard wrote:
Hi Serguei,
Sorry for the delay in reply and thank you for the update.
I like it in general. There are some minor comments though.
Excellent, thanks :)
I've prepared webrev.5.
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5.inc/
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java.frames.html
112 waitTime = (waitTime << 1); // double wait time
113 if (waitTime >= M || waitTime < 0) {
114 waitTime = 1; // reset when too long
115 }
The M is too big for time.
"waitTime" is ro
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi Serguei,
I have prepared a new webrev based on your suggestions.
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.6/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.6.inc/
Thanks,
Richard.
__
From: serguei.spit...@oracle.com
Sent: Freitag, 21. August 2020 11:22
To: Reingruber, Richard ; David Holmes
; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal::doit_prologue()
Hi Richard,
Thank you for the update, it looks really nice.
Just several more minor comments though (I hope, the last ones).
> Should I rename the variable to spinWaitCycles or something similar?
Yes, waitCycles would be better and more consistent.
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java.udiff.html
81 * The wait time is given in cycles.
82 */ 83 public int waitTime;
...
93 waitTime = 1;
This line 82 can be removed if you rename waitTime to waitCycles.
It is better to initialize waitCycles at definition and remove the line 93.
146 public static void msg(String m) {
147 System.out.println("### Java-Test: " + m);
148 }
One of the de-facto standard names for such methods is "log".
80 * Wait time in native, i.e. with walkable stack, after notifying
agent thread to do GetLocalObject() call.
89 msg("Test how many frames fit on the stack by performing recursive
calls until StackOverflowError is thrown");
Could you, please, reballance the two long lines above?
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp.frames.html
There are several spots that can be simplified a little bit:
95 jvmtiError result;
96
97 result = jvmti->GetErrorName(errCode, &errMsg);
==>
jvmtiError result = jvmti->GetErrorName(errCode, &errMsg);
The same is true for for the following cases:
115 err = jvmti->RawMonitorEnter(glws_monitor);
125 err = jvmti->RawMonitorExit(glws_monitor);
135 err = jvmti->RawMonitorWait(glws_monitor, 0);
145 err = jvmti->RawMonitorNotify(glws_monitor);
155 err = jvmti->DestroyRawMonitor(glws_monitor);
173 if (errMsg != NULL) {
An extra space before NULL.
89 static jvmtiEnv* jvmti_global = NULL;
276 jvmtiEnv* jvmti = jvmti_global;
308 jvmtiEnv* jvmti = jvmti_global;
330 jvmtiEnv* jvmti = jvmti_global;
...
409 jvmtiEnv* jvmti;
419 res = jvm->GetEnv((void **) &jvmti, JVMTI_VERSION_9);
424 jvmti_global = jvmti;
Normal practice is to name the "global_jvmti" as "jvmti".
Then there is no need to set it at the start of each function.
Thanks,
Serguei
On 8/20/20 23:47, Reingruber, Richard wrote:
Hi Serguei,
Sorry for the delay in reply and thank you for the update.
I like it in general. There are some minor comments though.
Excellent, thanks :)
I've prepared webrev.5.
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5.inc/
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java.frames.html
112 waitTime = (waitTime << 1); // double wait time
113 if (waitTime >= M || waitTime < 0) {
114 waitTime = 1; // reset when too long
115 }
The M is too big for time.
"waitTime" is roughly the number of cycles spent in a spin wait. M ~= 10^6
cycles does not seem too long. Should I rename the variable to spinWaitCycles or
something similar?
What about something like this:
waitTime = (waitTime << 1) % 32;
or
waitTime = (waitTime << 1) & 32;
I went for
// Double wait time, but limit to roughly 10^6 cycles.
waitTime = (waitTime << 1) & (M - 1);
waitTime = waitTime == 0 ? 1 : waitTime;
Masking the waitTime with % 32 is too small. In my experiments with fastdebug
builds I got the crash often with a waitTime of 8K on a Linux server and 256K on
my Windows notebook.
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp.udiff.html
// - Wait for the target thread to either start a new test iteration or to
+// signal shutdown.
A suggestion to replace: "to either start" => "either to start".
Ok, done.
+// Shutdown is signalled by setting test_state to ShutDown. The agent
reacts
+// to it by changing test_state to Terminated and then it exits.
The second "it" is not needed: "then it exits" => "then exits".
Ok, done.
+// .
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi Serguei,
> Sorry for the delay in reply and thank you for the update.
> I like it in general. There are some minor comments though.
Excellent, thanks :)
I've prepared webrev.5.
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.5.inc/
> http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java.frames.html
> 112 waitTime = (waitTime << 1); // double wait time
> 113 if (waitTime >= M || waitTime < 0) {
> 114 waitTime = 1; // reset when too long
> 115 }
> The M is too big for time.
"waitTime" is roughly the number of cycles spent in a spin wait. M ~= 10^6
cycles does not seem too long. Should I rename the variable to spinWaitCycles or
something similar?
> What about something like this:
> waitTime = (waitTime << 1) % 32;
> or
> waitTime = (waitTime << 1) & 32;
I went for
// Double wait time, but limit to roughly 10^6 cycles.
waitTime = (waitTime << 1) & (M - 1);
waitTime = waitTime == 0 ? 1 : waitTime;
Masking the waitTime with % 32 is too small. In my experiments with fastdebug
builds I got the crash often with a waitTime of 8K on a Linux server and 256K on
my Windows notebook.
> http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp.udiff.html
> // - Wait for the target thread to either start a new test iteration or to
> +// signal shutdown.
> A suggestion to replace: "to either start" => "either to start".
Ok, done.
> +// Shutdown is signalled by setting test_state to ShutDown. The agent
> reacts
> +// to it by changing test_state to Terminated and then it exits.
> The second "it" is not needed: "then it exits" => "then exits".
Ok, done.
> +// ... It sets the shared variable test_state
> +// to TargetInNative and then it uses the glws_monitor to send the
> The second "it" is not needed.
Ok, done.
> + monitor_enter(jvmti, env, glws_monitor, AT_LINE);
> + monitor_notify(jvmti, env, glws_monitor, AT_LINE);
> +monitor_wait(jvmti, env, glws_monitor, AT_LINE);
> + monitor_exit(jvmti, env, glws_monitor, AT_LINE);
> + monitor_destroy(jvmti, env, glws_monitor, AT_LINE);
> There is only one lock.
> It'd be more simple to directly use it in the called functions and get rid of
> the parameter.
> Just a suggestion, it is up to you to decide.
Ok, done.
> http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp.frames.html
> I'd suggest to refactor the lines 213 and 239-257 to a separate function
> test_GetLocalObject(jvmti, depth).
> 240 jobject local_val;
> Better to rename it to local_obj or just obj.
Ok, done.
> There are still problems with the indent.
I reformatted the file using 2 space indentation like in other C++ sources. I
didn't include the
indentation change in the delta webrev.
Thanks,
Richard.
__
From: serguei.spit...@oracle.com
Sent: Donnerstag, 20. August 2020 04:42
To: Reingruber, Richard ; David Holmes
; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal::doit_prologue()
Hi Richard,
Sorry for the delay in reply and thank you for the update.
I like it in general. There are some minor comments though.
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java.frames.html
112 waitTime = (waitTime << 1); // double wait time
113 if (waitTime >= M || waitTime < 0) {
114 waitTime = 1; // reset when too long
115 }
The M is too big for time.
What about something like this:
waitTime = (waitTime << 1) % 32;
or
waitTime = (waitTime << 1) & 32;
You can choose a better number instead of 32.
http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp.udiff.html
// - Wait for the target thread to either start a new test iteration or to
+// signal shutdown.
A suggestion to replace: "to either start" => "either to start".
+// Shutdown is signalled by setting test_state to ShutDown. The agent
reacts
+// to it by changing test_state to Terminated and then it exits.
The second "it" is not needed: "then it exits" => "then exits".
+
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Goetz,
I have collected the changes based on your feedback in a new webrev:
Webrev.7: http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.7/
Delta:http://cr.openjdk.java.net/~rrich/webrevs/8227745/webrev.7.inc/
Most of the changes are renamings, commenting, and reformatting.
Besides that ...
- I converted the native agent of the test IterateHeapWithEscapeAnalysisEnabled
from C to C++, because this seems to be preferred by serviceability
developers. I also re-indented the file, but excluded this from the delta
webrev.
- I had to adapt test/jdk/com/sun/jdi/EATests.java to the fact that background
compilation (-Xbatch) cannot be reliably disabled for JVMCI
compilers. E.g. the compile broker will compile in the background if JVMCI is
not yet fully initialized. Therefore it is possible that test cases are
executed before the main test method is compiled on the highest level and then
the test case fails. The higher the system load the higher the probability for
this to happen. In webrev.7 I skip the compilation level check if the vm is
configured to use the JVMCI compiler.
I also answered you inline below.
Thanks,
Richard.
-Original Message-
From: Lindenmaier, Goetz
Sent: Donnerstag, 23. Juli 2020 16:20
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi Richard,
Thanks for your two further explanations in the other thread.
That made the points clear to me.
> > I was not that happy with the names saying not_global_escape
> > and similar. I now agreed you have to use the terms of the escape
> > analysis (NoEscape ArgEscape= throughout the runtime code. I'm still not
> > happy with
> > the 'not' in the term, I always try to expand the name to some
> > sentence with a negated verb, but it makes no sense.
> > For example, "has_not_global_escape_in_scope" expands to
> > "Hasn't a global escape in its scope." in my thinking, which makes
> > no sense. You probably mean
> > "Has not-global escape in its scope." or "Has {ArgEscape|NoEscape}
> > in its scope."
>
> > C2 is using the word "non" in this context, e.g., here
> > alloc->is_non_escaping.
>
> There is also ConnectionGraph::not_global_escape()
That talks about a single node that represents a single
Object. An object has a single state wrt. ea.
You use the term for safepoint which tracks a set of objects.
Here, has_not_global_excape can mean
1. None of the several objects does escape globaly.
2. There is at least one object that escapes globaly.
> > non obviously negates the adjective 'global',
> > non-global or nonglobal even is a English term I find in the
> > net.
> > So what about "has_non_global_escape_in_scope?"
>
> And what about has_ea_local_in_scope?
That's good. Please document somewhere that
Ea_local == ArgEscape | NoEscape.
That's what it is, right?
> > Does jvmti specify that the same limits are used ...?
> > ok on your side.
>
> I don't know and didn't find anything in a quick search.
Ok, not your business.
>
> > jvmtiEnvBase.cpp ok
> > jvmtiImpl.h|cpp ok
> > jvmtiTagMap.cpp ok
> > whitebox.cpp ok
>
> > deoptimization.cpp
>
> > line 177: Please break line
> > line 246, 281: Please break line
> > 1578, 1583, 1589, 1632, 1649, 1651 Break line
>
> > 1651: You use 'non'-terms, too: non-escaping :)
>
> I know :) At least here it is wrong I'd say. "...has to be a not escaping
> obj..."
> sounds better
> (hopefully not only to my german ears).
I thought the term non-escpaing makes it quite clear.
I just wanted to point out that using non above would
be similar to the wording here.
> > IterateHeapWithEscapeAnalysisEnabled.java
>
> > line 415:
> > msg("wait until target thread has set testMethod_result");
> > while (testMethod_result == 0) {
> > Thread.sleep(50);
> > }
> > Might the test run into timeouts at this place?
> > The field is volatile, i.e. it will be reloaded
> > in each iteration. But will dontinline_testMethod
> > write it back to main memory in time?
>
> You mean, the test could hang in that loop for a couple of minutes? I don't
> think so. There are cache coherence protocols in place which will invalidate
> stale data very timely.
Ok, anyways, it would only be a hanging test.
>
> Ok. I've removed quite a lot of the occurrances.
>
> > Also, I like full sentences in comments.
> > Especially for me as
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Thanks David, have a good time!
Richard.
-Original Message-
From: David Holmes
Sent: Dienstag, 18. August 2020 07:20
To: Reingruber, Richard ;
serguei.spit...@oracle.com; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal::doit_prologue()
Hi Richard,
The test seems a lot clearer to me now. I'll leave it to you are Serguei
to iron out any last wrinkles as I am disappearing on vacation for a
week after today. But you have my Review.
Thanks,
David
On 15/08/2020 12:06 am, Reingruber, Richard wrote:
> Hi Serguei,
>
> thanks for the feedback. I have implemented your suggestions and created a new
> webrev:
>
> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4/
> Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/
>
> Please find my replies to your comments below.
>
> Best regards,
> Richard.
>
>> http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.3.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java.frames.html
>
>>33 * the stack walk. The target thread's stack is walkable
>> while in native. After sending the notification it
>>...
>
>>54 * @param depth Depth of target frame for GetLocalObject() call.
>> Should be large value to prolong the unsafe stack walk.
>>55 * @param waitTimeInNativeAfterNotify Time to wait after notify
>> with walkable stack before returning an becoming unsafe again.
>>...
>
>>71 * Wait time in native, i.e. with walkable stack, after notifying
>> agent thread to do GetLocalObject() call.
>>...
>
>>89 msg((now -start) + " ms Iteration : " + iterations + "
>> waitTimeInNativeAfterNotify : " + waitTimeInNativeAfterNotify);
>
>> Could you, please, re-balance the lines above to make them shorter?
>
> Ok, done.
>
>
>>90 int newTargetDepth = recursiveMethod(0, targetDepth);
>>91 if (newTargetDepth < targetDepth) {
>>92 msg("StackOverflowError during test.");
>>93 msg("Old target depth: " + targetDepth);
>>94 msg("Retry with new target depth: " + newTargetDepth);
>>95 targetDepth = newTargetDepth;
>>96 }
>> A comment is needed to explain why a StackOverflowError is not desired.
>> At least, it is not obvious initially.
>>73 public int waitTimeInNativeAfterNotify;
>
>> This name is unreasonably long which makes the code less readable.
>> I'd suggest to reduce it to waitTime.
>
> Ok, done.
>
>> 103 notifyAgentToGetLocalAndWaitShortly(-1, 1);
>> ...
>> 119 notifyAgentToGetLocalAndWaitShortly(depth - 100,
>> waitTimeInNativeAfterNotify);
>
>> It is better to provide a short comment before each call explaining what it
>> is doing.
>> For instance, it is not clear why the call at the line 103 is needed.
>> Why do we need to notify the agent to GetLocal for the second time?
>
> The test is repeated TEST_ITERATIONS times. In each iteration the agent calls
> GetLocal racing the target thread returning from the native call. The last
> call
> in line 103 ist the shutdown signal.
>
>> Can it be refactored into a separate native method?
>
> I've made the shutdown process more explicit with the new native method
> shutDown() which sets thest_state to ShutDown.
>
>> Then the the function name can be reduced to 'notifyAgentToGetLocal'.
>> This long name does not give enough context anyway.
>
> Ok, done.
>
>>85 long iterations = 0;
>>87 do {
>>...
>>97 iterations++;
>>...
>> 102 } while (iterations < TEST_ITERATIONS);
>
>> Why a more explicit 'for' or 'while' loop is not used here? :
>> for (long iter = 0; iter < TEST_ITERATIONS; iter++) {
>
> I have converted the loop into a for loop.
>
>> http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.3.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp.frames.html
>
>> The indent in this file varies. It is better to keep it the same: 4 or 2.
>
> Yes, I noticed this. I have not corrected it yet, because I didn't want to
> pullute the incremental webrev with that change. Would you like me to fix the
> indentation now to 2 spaces or do it as a last step?
>
>>60 AgentCallingGetLocalObject // T
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi Serguei,
thanks for the feedback. I have implemented your suggestions and created a new
webrev:
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.4.inc/
Please find my replies to your comments below.
Best regards,
Richard.
> http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.3.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java.frames.html
> 33 * the stack walk. The target thread's stack is walkable while
> in native. After sending the notification it
> ...
> 54 * @param depth Depth of target frame for GetLocalObject() call.
> Should be large value to prolong the unsafe stack walk.
> 55 * @param waitTimeInNativeAfterNotify Time to wait after notify with
> walkable stack before returning an becoming unsafe again.
> ...
> 71 * Wait time in native, i.e. with walkable stack, after notifying
> agent thread to do GetLocalObject() call.
> ...
> 89 msg((now -start) + " ms Iteration : " + iterations + "
> waitTimeInNativeAfterNotify : " + waitTimeInNativeAfterNotify);
> Could you, please, re-balance the lines above to make them shorter?
Ok, done.
> 90 int newTargetDepth = recursiveMethod(0, targetDepth);
> 91 if (newTargetDepth < targetDepth) {
> 92 msg("StackOverflowError during test.");
> 93 msg("Old target depth: " + targetDepth);
> 94 msg("Retry with new target depth: " + newTargetDepth);
> 95 targetDepth = newTargetDepth;
> 96 }
> A comment is needed to explain why a StackOverflowError is not desired.
> At least, it is not obvious initially.
> 73 public int waitTimeInNativeAfterNotify;
> This name is unreasonably long which makes the code less readable.
> I'd suggest to reduce it to waitTime.
Ok, done.
> 103 notifyAgentToGetLocalAndWaitShortly(-1, 1);
> ...
> 119 notifyAgentToGetLocalAndWaitShortly(depth - 100,
> waitTimeInNativeAfterNotify);
> It is better to provide a short comment before each call explaining what it
> is doing.
> For instance, it is not clear why the call at the line 103 is needed.
> Why do we need to notify the agent to GetLocal for the second time?
The test is repeated TEST_ITERATIONS times. In each iteration the agent calls
GetLocal racing the target thread returning from the native call. The last call
in line 103 ist the shutdown signal.
> Can it be refactored into a separate native method?
I've made the shutdown process more explicit with the new native method
shutDown() which sets thest_state to ShutDown.
> Then the the function name can be reduced to 'notifyAgentToGetLocal'.
> This long name does not give enough context anyway.
Ok, done.
> 85 long iterations = 0;
> 87 do {
> ...
> 97 iterations++;
> ...
> 102 } while (iterations < TEST_ITERATIONS);
> Why a more explicit 'for' or 'while' loop is not used here? :
> for (long iter = 0; iter < TEST_ITERATIONS; iter++) {
I have converted the loop into a for loop.
> http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.3.inc/test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp.frames.html
> The indent in this file varies. It is better to keep it the same: 4 or 2.
Yes, I noticed this. I have not corrected it yet, because I didn't want to
pullute the incremental webrev with that change. Would you like me to fix the
indentation now to 2 spaces or do it as a last step?
> 60 AgentCallingGetLocalObject // The target thread waits for the agent to
> call
> I'd suggest to rename the constant to 'AgentInGetLocal'.
Ok, done.
> 150 GetLocalWithoutSuspendTestThreadLoop(jvmtiEnv * jvmti, JNIEnv* env, void
> * arg) {
> It is better rename the function to TestThreadLoop.
Would AgentThreadLoop be ok too?
> You can add a comment before to explain some basic about what it is doing.
Ok, done.
> 167 printf("*** AGENT: GetLocalWithoutSuspendTestThreadLoop thread
> started. Polling thread '%s' for local variables\n",
> It is better to get rid of leading stars in all messages.
Ok, done.
> 176 // the native method
> Java_GetLocalWithoutSuspendTest_notifyAgentToGetLocalAndWaitShortly
> The part 'Java_GetLocalWithoutSuspendTest_' can be removed from the function
> name.
Ok, done.
---
From: serguei.spit...@oracle.com
Sent: Freitag, 14. August 2020 10:11
To: Reingruber, Richard ; David Holmes
; serviceability-dev@openjdk.java.net
Subject: R
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi David and Serguei,
> On 11/08/2020 3:21 am, serguei.spit...@oracle.com wrote:
> > Hi Richard and David,
> >
> > The implementation looks good to me.
> >
> > But I do not understand what the test is doing with all this counters
> > and recursions.
> >
> > For instance, these fragments:
> >
> >86 recursions = 0;
> >87 try {
> >88 recursiveMethod(1<<20);
> >89 } catch (StackOverflowError e) {
> >90 msg("Caught StackOverflowError as expected");
> >91 }
> >92 int target_depth = recursions-100;// spaces are missed
> > around the '-' sigh
> >
> > It is not obvious that the 'recursion' is updated in the recursiveMethod.
> > I would suggestto make it more explicit:
> > recursiveMethod(M);
> > int target_depth = M - 100;
> >
> > Then the variable 'recursions' can be removed or become local.
> The recursiveMethod takes in the maximum recursions to try and updates
> the recursions variable to record how many recursions were possible - so:
> target_depth = - 100;
> Possibly recursiveMethod could return the actual recursions instead of
> using the global variables?
I've eliminated the static 'recursions' variable. recursiveMethod() now returns
the depth at which the recursion was ended. I hesitated doing this, because I
had to handle the StackOverflowError with all those frames still on stack. But
the handler is empty, so it should not cause problems.
This is the new webrev (as posted previously):
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.3/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.3.inc/
Thanks, Richard.
-Original Message-
From: David Holmes
Sent: Dienstag, 11. August 2020 04:00
To: serguei.spit...@oracle.com; Reingruber, Richard
; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal::doit_prologue()
Hi Serguei,
On 11/08/2020 3:21 am, serguei.spit...@oracle.com wrote:
> Hi Richard and David,
>
> The implementation looks good to me.
>
> But I do not understand what the test is doing with all this counters
> and recursions.
>
> For instance, these fragments:
>
>86 recursions = 0;
>87 try {
>88 recursiveMethod(1<<20);
>89 } catch (StackOverflowError e) {
>90 msg("Caught StackOverflowError as expected");
>91 }
>92 int target_depth = recursions-100;// spaces are missed
> around the '-' sigh
>
> It is not obvious that the 'recursion' is updated in the recursiveMethod.
> I would suggestto make it more explicit:
> recursiveMethod(M);
> int target_depth = M - 100;
>
> Then the variable 'recursions' can be removed or become local.
The recursiveMethod takes in the maximum recursions to try and updates
the recursions variable to record how many recursions were possible - so:
target_depth = - 100;
Possibly recursiveMethod could return the actual recursions instead of
using the global variables?
David
-
> This method will be:
>
>47 private static final int M = 1 << 20;
> ...
> 121 public long recursiveMethod(int depth) {
> 123 if (depth == 0) {
> 124 notifyAgentToGetLocalAndWaitShortly(M - 100,
> waitTimeInNativeAfterNotify);
> 126 } else {
> 127 recursiveMethod(--depth);
> 128 }
> 129 }
>
>
> At least, he test is missing the comments explaining all these.
>
> Thanks,
> Serguei
>
>
>
> On 8/9/20 22:35, David Holmes wrote:
>> Hi Richard,
>>
>> On 31/07/2020 5:28 pm, Reingruber, Richard wrote:
>>> Hi,
>>>
>>> I rebase the fix after JDK-8250042.
>>>
>>> New webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.2/
>>
>> The general fix for this seems good. A minor nit:
>>
>> 588 if (!is_assignable(signature, ob_k, Thread::current())) {
>>
>> You know that the current thread is the VMThread so can use
>> VMThread::vm_thread().
>>
>> Similarly for this existing code:
>>
>> 694 Thread* current_thread = Thread::current();
>>
>> ---
>>
>> Looking at the test code ... I'm less clear on exactly what is
>> happening and the use of spin-waits raises some red-flags for me in
>> terms of test reliability on different platforms. The "while
>> (--waitCycles > 0)" loop in particular o
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi Serguei,
> The implementation looks good to me.
Thanks.
> But I do not understand what the test is doing with all this counters and
> recursions.
The @comment gives an explanation: the target thread builds a stack as large as
possible to prolong the unsafe stackwalk. This is done by means of recursion.
> For instance, these fragments:
> 86 recursions = 0;
> 87 try {
> 88 recursiveMethod(1<<20);
> 89 } catch (StackOverflowError e) {
> 90 msg("Caught StackOverflowError as expected");
> 91 }
> 92 int target_depth = recursions-100;// spaces are missed
> around the '-' sigh
Here we calibrate the test for maximum stack depth. We measure how large the
stack can grow by calling recursiveMethod() until a StackOverflowError is
raised. We use recursions - 100 as target_depth to avoid the StackOverflowError
during the actual test.
> It is not obvious that the 'recursion' is updated in the recursiveMethod.
> I would suggestto make it more explicit:
>recursiveMethod(M);
>int target_depth = M - 100;
> Then the variable 'recursions' can be removed or become local.
> This method will be:
> 47 private static final int M = 1 << 20;
> ...
> 121 public long recursiveMethod(int depth) {
> 123 if (depth == 0) {
> 124 notifyAgentToGetLocalAndWaitShortly(M - 100,
> waitTimeInNativeAfterNotify);
> 126 } else {
> 127 recursiveMethod(--depth);
> 128 }
> 129 }
I don't think this would work. A StackOverflowError would be raised
before notifyAgentToGetLocalAndWaitShortly() is called.
> At least, he test is missing the comments explaining all these.
The arguments to the msg() method serve as documentation too. I would not want
to repeat the msg strings in comments.
Thanks, Richard.
---------
From: serguei.spit...@oracle.com
Sent: Montag, 10. August 2020 19:22
To: David Holmes ; Reingruber, Richard
; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal::doit_prologue()
Hi Richard and David,
The implementation looks good to me.
But I do not understand what the test is doing with all this counters and
recursions.
For instance, these fragments:
86 recursions = 0;
87 try {
88 recursiveMethod(1<<20);
89 } catch (StackOverflowError e) {
90 msg("Caught StackOverflowError as expected");
91 }
92 int target_depth = recursions-100;// spaces are missed around
the '-' sigh
It is not obvious that the 'recursion' is updated in the recursiveMethod.
I would suggestto make it more explicit:
recursiveMethod(M);
int target_depth = M - 100;
Then the variable 'recursions' can be removed or become local.
This method will be:
47 private static final int M = 1 << 20;
...
121 public long recursiveMethod(int depth) {
123 if (depth == 0) {
124 notifyAgentToGetLocalAndWaitShortly(M - 100,
waitTimeInNativeAfterNotify);
126 } else {
127 recursiveMethod(--depth);
128 }
129 }
At least, he test is missing the comments explaining all these.
Thanks,
Serguei
On 8/9/20 22:35, David Holmes wrote:
Hi Richard,
On 31/07/2020 5:28 pm, Reingruber, Richard wrote:
Hi,
I rebase the fix after JDK-8250042.
New webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.2/
The general fix for this seems good. A minor nit:
588 if (!is_assignable(signature, ob_k, Thread::current())) {
You know that the current thread is the VMThread so can use
VMThread::vm_thread().
Similarly for this existing code:
694 Thread* current_thread = Thread::current();
---
Looking at the test code ... I'm less clear on exactly what is happening and
the use of spin-waits raises some red-flags for me in terms of test reliability
on different platforms. The "while (--waitCycles > 0)" loop in particular
offers no certainty that the agent thread is executing anything in particular.
And the use of the spin_count as a guide to future waiting time seems somewhat
arbitrary. In all seriousness I got a headache trying to work out how the test
was expecting to operate. Some parts could be simplified using raw monitors, I
think. But there's no sure way to know the agent thread is in the midst of the
stackwalk when the target thread wants to leave the native code. So I
understand what you are trying to achieve here, I'm just not sure how reliably
it will actually achieve it.
test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp
32 static volatile jlong spinn_cou
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi David,
thanks for looking at this. I've prepared a new webrev based on your feedback.
Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.3/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.3.inc/
I'm answering your points inline below.
Thanks,
Richard.
> On 31/07/2020 5:28 pm, Reingruber, Richard wrote:
> > Hi,
> >
> > I rebase the fix after JDK-8250042.
> >
> > New webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.2/
> The general fix for this seems good. A minor nit:
> 588 if (!is_assignable(signature, ob_k, Thread::current())) {
> You know that the current thread is the VMThread so can use
> VMThread::vm_thread().
> Similarly for this existing code:
> 694 Thread* current_thread = Thread::current();
> ---
Done.
> Looking at the test code ... I'm less clear on exactly what is happening
The @comment in GetLocalWithoutSuspendTest.java describes the intent.
> and the use of spin-waits raises some red-flags for me in terms of test
> reliability on different platforms. The "while (--waitCycles > 0)" loop
> in particular offers no certainty that the agent thread is executing
> anything in particular. And the use of the spin_count as a guide to
> future waiting time seems somewhat arbitrary. In all seriousness I got
> a headache trying to work out how the test was expecting to operate.
> Some parts could be simplified using raw monitors, I think. But there's
> no sure way to know the agent thread is in the midst of the stackwalk
> when the target thread wants to leave the native code. So I understand
> what you are trying to achieve here, I'm just not sure how reliably it
> will actually achieve it.
I've replaced 2 of 3 spin waits with wait calls on a raw monitor. The state of
the test is kept in the global variable test_state. Agent and target thread use
it to synchronize. I hope this helps to make clear what is happening.
As you noticed the remaining spin wait cannot be replaced with a monitor
wait. It should not be eliminated either, though. Without it the target thread
might always return from the native call before the unsafe stack walk was
started. I guess you have noticed that the target thread doubles the spin cycles
in each iteration searching the sweet spot :)
About reliability: on my Windows notebook and on a Linux server the test has
never succeeded without the fix. The probability for failure could be increased
by using a thread with a larger stack, but I don't think this is necessary.
On uniprocessor systems the test might not work very reliably. I experimented
with pinning the jvm to one cpu. Executed like this the test reliably fails
without the fix as well, though.
Without modification of the jvm the test cannot be made 100% reliable. But there
are many tests like this I reckon.
> test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/libGetLocalWithoutSuspendTest.cpp
> 32 static volatile jlong spinn_count = 0;
> Using a 64-bit counter seems like it will be a problem on 32-bit systems.
> Should be spin_count not spinn_count.
This is actually a dummy variable. I have renamed it to dummy_counter. Its
purpose is to prevent the c++ compiler from eliminating the spin wait loop.
I have replaced all longs with ints in the test.
-Original Message-
From: David Holmes
Sent: Montag, 10. August 2020 07:35
To: Reingruber, Richard ;
serguei.spit...@oracle.com; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8249293: Unsafe stackwalk in
VM_GetOrSetLocal::doit_prologue()
Hi Richard,
On 31/07/2020 5:28 pm, Reingruber, Richard wrote:
> Hi,
>
> I rebase the fix after JDK-8250042.
>
> New webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.2/
The general fix for this seems good. A minor nit:
588 if (!is_assignable(signature, ob_k, Thread::current())) {
You know that the current thread is the VMThread so can use
VMThread::vm_thread().
Similarly for this existing code:
694 Thread* current_thread = Thread::current();
---
Looking at the test code ... I'm less clear on exactly what is happening
and the use of spin-waits raises some red-flags for me in terms of test
reliability on different platforms. The "while (--waitCycles > 0)" loop
in particular offers no certainty that the agent thread is executing
anything in particular. And the use of the spin_count as a guide to
future waiting time seems somewhat arbitrary. In all seriousness I got
a headache trying to work out how the test was expecting to operate.
Some parts could be simplified using raw monitors, I think. But there's
no sure way to know the agent thread is in the midst of the stackwalk
when the target thread wants to leave the native code. So I understand
what you are trying to achieve here, I&#x
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi, I rebase the fix after JDK-8250042. New webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.2/ Thanks, Richard. -Original Message- From: serviceability-dev On Behalf Of Reingruber, Richard Sent: Montag, 27. Juli 2020 09:45 To: serguei.spit...@oracle.com; serviceability-dev@openjdk.java.net Subject: [CAUTION] RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue() Hi Serguei, > I tested it on Linux and Windows but not yet on MacOS. The test succeeded now on all platforms. Thanks, Richard. -Original Message- From: Reingruber, Richard Sent: Freitag, 24. Juli 2020 15:04 To: serguei.spit...@oracle.com; serviceability-dev@openjdk.java.net Subject: RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue() Hi Serguei, > The fix itself looks good to me. thanks for looking at the fix. > I still need another look at new test. > Could you, please, convert the agent of new test to C++? > It will make it a little bit simpler. Sure, here is the new webrev.1 with a C++ version of the test agent: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.1/ I tested it on Linux and Windows but not yet on MacOS. Thanks, Richard. -Original Message- From: serguei.spit...@oracle.com Sent: Freitag, 24. Juli 2020 00:00 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net Subject: Re: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue() Hi Richard, Thank you for filing the CR and taking care about it! The fix itself looks good to me. I still need another look at new test. Could you, please, convert the agent of new test to C++? It will make it a little bit simpler. Thanks, Serguei On 7/20/20 01:15, Reingruber, Richard wrote: > Hi, > > please help review this fix for VM_GetOrSetLocal. It moves the unsafe > stackwalk from the vm > operation prologue before the safepoint into the doit() method executed at > the safepoint. > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.0/index.html > Bug:https://bugs.openjdk.java.net/browse/JDK-8249293 > > According to the JVMTI spec on local variable access it is not required to > suspend the target thread > T [1]. The operation will simply fail with JVMTI_ERROR_NO_MORE_FRAMES if T is > executing > bytecodes. It will succeed though if T is blocked because of synchronization > or executing some native > code. > > The issue is that in the latter case the stack walk in > VM_GetOrSetLocal::doit_prologue() to prepare > the access to the local variable is unsafe, because it is done before the > safepoint and it races > with T returning to execute bytecodes making its stack not walkable. The > included test shows that > this can crash the VM if T wins the race. > > Manual testing: > >- new test > test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java >- test/hotspot/jtreg/vmTestbase/nsk/jvmti >- test/hotspot/jtreg/serviceability/jvmti > > Nightly regression tests @SAP: JCK and JTREG, also in Xcomp mode, > SPECjvm2008, SPECjbb2015, > Renaissance Suite, SAP specific tests with fastdebug and release builds on > all platforms > > Thanks, Richard. > > [1] https://docs.oracle.com/en/java/javase/14/docs/specs/jvmti.html#local
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi Serguei, > I tested it on Linux and Windows but not yet on MacOS. The test succeeded now on all platforms. Thanks, Richard. -Original Message- From: Reingruber, Richard Sent: Freitag, 24. Juli 2020 15:04 To: serguei.spit...@oracle.com; serviceability-dev@openjdk.java.net Subject: RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue() Hi Serguei, > The fix itself looks good to me. thanks for looking at the fix. > I still need another look at new test. > Could you, please, convert the agent of new test to C++? > It will make it a little bit simpler. Sure, here is the new webrev.1 with a C++ version of the test agent: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.1/ I tested it on Linux and Windows but not yet on MacOS. Thanks, Richard. -Original Message- From: serguei.spit...@oracle.com Sent: Freitag, 24. Juli 2020 00:00 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net Subject: Re: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue() Hi Richard, Thank you for filing the CR and taking care about it! The fix itself looks good to me. I still need another look at new test. Could you, please, convert the agent of new test to C++? It will make it a little bit simpler. Thanks, Serguei On 7/20/20 01:15, Reingruber, Richard wrote: > Hi, > > please help review this fix for VM_GetOrSetLocal. It moves the unsafe > stackwalk from the vm > operation prologue before the safepoint into the doit() method executed at > the safepoint. > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.0/index.html > Bug:https://bugs.openjdk.java.net/browse/JDK-8249293 > > According to the JVMTI spec on local variable access it is not required to > suspend the target thread > T [1]. The operation will simply fail with JVMTI_ERROR_NO_MORE_FRAMES if T is > executing > bytecodes. It will succeed though if T is blocked because of synchronization > or executing some native > code. > > The issue is that in the latter case the stack walk in > VM_GetOrSetLocal::doit_prologue() to prepare > the access to the local variable is unsafe, because it is done before the > safepoint and it races > with T returning to execute bytecodes making its stack not walkable. The > included test shows that > this can crash the VM if T wins the race. > > Manual testing: > >- new test > test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java >- test/hotspot/jtreg/vmTestbase/nsk/jvmti >- test/hotspot/jtreg/serviceability/jvmti > > Nightly regression tests @SAP: JCK and JTREG, also in Xcomp mode, > SPECjvm2008, SPECjbb2015, > Renaissance Suite, SAP specific tests with fastdebug and release builds on > all platforms > > Thanks, Richard. > > [1] https://docs.oracle.com/en/java/javase/14/docs/specs/jvmti.html#local
RE: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi Serguei, > The fix itself looks good to me. thanks for looking at the fix. > I still need another look at new test. > Could you, please, convert the agent of new test to C++? > It will make it a little bit simpler. Sure, here is the new webrev.1 with a C++ version of the test agent: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.1/ I tested it on Linux and Windows but not yet on MacOS. Thanks, Richard. -Original Message- From: serguei.spit...@oracle.com Sent: Freitag, 24. Juli 2020 00:00 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net Subject: Re: RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue() Hi Richard, Thank you for filing the CR and taking care about it! The fix itself looks good to me. I still need another look at new test. Could you, please, convert the agent of new test to C++? It will make it a little bit simpler. Thanks, Serguei On 7/20/20 01:15, Reingruber, Richard wrote: > Hi, > > please help review this fix for VM_GetOrSetLocal. It moves the unsafe > stackwalk from the vm > operation prologue before the safepoint into the doit() method executed at > the safepoint. > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.0/index.html > Bug:https://bugs.openjdk.java.net/browse/JDK-8249293 > > According to the JVMTI spec on local variable access it is not required to > suspend the target thread > T [1]. The operation will simply fail with JVMTI_ERROR_NO_MORE_FRAMES if T is > executing > bytecodes. It will succeed though if T is blocked because of synchronization > or executing some native > code. > > The issue is that in the latter case the stack walk in > VM_GetOrSetLocal::doit_prologue() to prepare > the access to the local variable is unsafe, because it is done before the > safepoint and it races > with T returning to execute bytecodes making its stack not walkable. The > included test shows that > this can crash the VM if T wins the race. > > Manual testing: > >- new test > test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java >- test/hotspot/jtreg/vmTestbase/nsk/jvmti >- test/hotspot/jtreg/serviceability/jvmti > > Nightly regression tests @SAP: JCK and JTREG, also in Xcomp mode, > SPECjvm2008, SPECjbb2015, > Renaissance Suite, SAP specific tests with fastdebug and release builds on > all platforms > > Thanks, Richard. > > [1] https://docs.oracle.com/en/java/javase/14/docs/specs/jvmti.html#local
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Goetz, > Thanks for the quick reply. Yes, this time it didn't take that long... [... snip ...] > > > > > I understand you annotate at safepoints where the escape analysis > > > > > finds out that an object is "better" than global escape. > > > > > This are the cases where the analysis identifies optimization > > > > > opportunities. These annotations are then used to deoptimize > > > > > frames and the objects referenced by them. > > > > > Doesn't this overestimate the optimized > > > > > objects? E.g., eliminate_alloc_node has many cases where it bails > > > > > out. > > > > > > > > Yes, the implementation is conservative, but it is comparatively simple > > and > > > > the additional debug > > > > info is just 2 flags per safepoint. > > > Thanks. It also helped that you explained to me offline that > > > there are more optimizations than only lock elimination and scalar > > > replacement done based on the ea information. > > > The ea refines the IR graph with allows follow up optimizations > > > which can not easily be tracked back to the escaping objects or > > > the call sites where they do not escape. > > > Thus, if there are non-global escaping objects, you have to > > > deoptimize the frame. > > > Did I repeat that correctly? > > > > Mostly, but there are also cases where deoptimization is required if and > > only > > if ea-local objects > > are passed as arguments. This is the case when values are not read directly > > from a frame, but from a callee frame. > Hmm, don't get this completely, but ok. Let C be a callee frame of B which is a callee of A. If you use JVMTI to read an object reference from a local variable of C then the implementation of JDK-8227745 deoptimizes A if it passes any ea-local as argument, because the reference could be ea-local in A and there might be optimizations that are invalid after the escape state change. > > > > Accesses to instance > > > > members or array elements can be optimized as well. > > > You mean the compiler can/will ignore volatile or memory ordering > > > requirements for non-escaping objects? Sounds reasonable to do. > > > > Yes, for instance. Also without volatile modifiers it will eliminate > > accesses. > > Here is an example: > > Method A has a NoEscape allocation O that is not scalar replaced. A calls > > Method B, which is not > > inlined. When you use your debugger to break in B, then modify a field of O, > > then this modification > > would have no effect without deoptimization, because the jit assumes that B > > cannot modify O without > > a reference to it. > Yes, A can keep O in a register, while the JVMTI thread would write to > the location in the stack where the local is held (if it was written back). Not quite. It is the value of the field of O that is in a register not the reference to O itself. The agent changes the field's value in the /java heap/ (remember: O is _not_ scalar replaced), but the fields value is not reloaded after return from B. > > > > > Syncronization: looks good. I think others had a look at this before. > > > > > > > > > > EscapeBarrier::deoptimize_objects_internal() > > > > > The method name is misleading, it is not used by > > > > > deoptimize_objects(). > > > > > Also, method with the same name is in Deopitmization. > > > > > Proposal: deoptimize_objects_thread() ? > > > > > > > > Sorry, but I don't see, why it would be misleading. > > > > What would be the meaning of 'deoptimize_objects_thread'? I don't > > > > understand that name. > > > 1. I have no idea why it's called "_internal". Because it is private? > > >By the name, I would expect that EscapeBarrier::deoptimize_objects() > > >calls it for some internal tasks. But it does not. > > > > Well, I'd say it is pretty internal, what's happening in that method. So > > IMHO > > the suffix _internal > > is a match. > > > > > 2. My proposal: deoptimize_objects_all_threads() iterates all threads > > > and calls deoptimize_objects(_one)_thread(thread) for each of these. > > > That's how I would have named it. > > > But no bike shedding, if you don't see what I mean it's not obvious. > > Ok. We could have a quick call, too, if you like. > Ok, I think I have understood the remai
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
cough
> syrup, and then embarking on an adventure while wandering around
> neighborhoods or parks all night. This is usually done while listening to
> Punk rock music from a portable jambox.
> ;)
> Don’t do it! 😊
OMG! How come you know?! ;)
> EATestsJVMTI.java
> I think you can just copy this test description into the other
> test. You can have two @test comments, they will be treated
> as separate tests. The @requires will be evaluated accordingly.
> For an example see
> test/hotspot/jtreg/runtime/exceptionMsgs/NullPointerException/NullPointerExceptionTest.java
> which has two different compile setups for the test class (-g).
Done.
> so, that's it for reading code ...
> Some general remarks, maybe a bit picky ...:
> I think you could use less commas ',' in comments.
> As I understand, you need a comma if the relative
> sentence is at the beginning, but not if it is at
> the end:
> If Corona is over, I go to the office.
> but
> I go to the office if Corona is over.
That seem's to be correct except "If Corona is over" isn't a relative sentence
but a conditional sentence, isn't it?
The general rule seems to be: the subordinate clause is separated with a comma
from a following main clause. No comma separation is needed if the subordinate
clause follows the main clause.
Thanks, that's a lesson I learned!
> I think the same holds for 'because', 'while' etc.
> E.g., jvmtiEnvBase.cpp:1313, jvmtiImpl.cpp:646ff,
> vframe_hp.hpp 104ff
Ok. I've removed quite a lot of the occurrances.
> Also, I like full sentences in comments.
> Especially for me as foreign speaker, this makes
> things much more clear. I.e., I try to make it
> a real sentence with articles, capitalized and a
> dot at the end if there is a subject and a verb
> in first place.
> E.g., jvmtiEnvBase.cpp:1327
Are you referring to the following?
(from
http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.6/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html)
1326
1327 // If the frame is a compiled one, need to deoptimize it.
1328 if (vf->is_compiled_frame()) {
This line 1327 is preexisting.
> In many places, your comments read really
> well but some are quite abbreviated I think.
Yeah, but not only because I'm lazy... It is the style that I prefer and I think
it matches the surrounding code quite well.
> E.g. thread.cpp:2601 is an example where a simple
> 'a' helps a lot.
> "Single deoptimization is typically very short."
> I would add 'A': "A single deoptimization is typically very short (fast?)."
> An other meaning of the comment I first considered is this:
> "Single deoptimization is typically very short, all_threads deoptimization
> takes longer"
> having in mind the functions
> EscapeBarries::deoptimize_objects_all_threads()
> and
> EscapeBarries::deoptimize_objects() doing a single thread.
> German with it's compound nouns is helpful here :)
> Einzeldeoptimierung <--> eine einzelne Deoptimierung
I've added the 'A' and I'll try to use complete sentences in the future. The
telegram style has advantages, too, though ;)
Thanks!
Cheers, Richard.
-Original Message-
From: Lindenmaier, Goetz
Sent: Freitag, 17. Juli 2020 14:31
To: Lindenmaier, Goetz ; Reingruber, Richard
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi Richard,
> I'll answer to the obvious things in this mail now.
> I'll go through the code thoroughly again and write
> a review of my findings thereafter.
As promised a detailed walk-throug, but without any major findings:
c1_IR.hpp: ok
ci_Env.h|cpp: ok
compiledMethod.cpp, nmethod.cpp: ok
debugInfoRec.h|cpp: ok
scopeDesc.h|cpp ok
compileBroker.h|cpp:
Maybe a bit of documentation how and why you start
the threads? I had expected there are two test
scenarios run after each other, but now I understand 'Single'
and 'All' run simultaneously. Well, this really is a stress test!
Also good the two variants of depotimization are
stressed against each other.
Besides that really nice it's all in one place.
rootResolver.cpp: ok
jvmciCodeInstaller.cpp: ok
c2compiler.cpp: The essence of this change! Just one line :)
Great!
callnode.hpp ok
escape.h|cpp ok
macro.cpp
I was not that happy with the names saying not_global_escape
and similar. I now agreed you have to use the terms of the escape
analysis (NoEscape ArgEscape= throughout the runtime code. I'm still not happy
with
the 'not' in the term, I always try to expand the name to some
sentence with a negated verb, b
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
th, deoptimize frames with any optimized objects.
> > > // From depth to entry_frame, deoptimize only frames that
> > > // pass optimized objects to their callees.
> > > (First part similar for the comment above
> > EscapeBarrier::deoptimize_objects_internal().)
> >
> > I've reworked the comment. Let me know if you still think it needs to be
> > improved.
> Good now, thanks (maybe break the long line ...)
Ok. Will do in next webrev.7
> > > Syncronization: looks good. I think others had a look at this before.
> > >
> > > EscapeBarrier::deoptimize_objects_internal()
> > > The method name is misleading, it is not used by
> > > deoptimize_objects().
> > > Also, method with the same name is in Deopitmization.
> > > Proposal: deoptimize_objects_thread() ?
> >
> > Sorry, but I don't see, why it would be misleading.
> > What would be the meaning of 'deoptimize_objects_thread'? I don't
> > understand that name.
> 1. I have no idea why it's called "_internal". Because it is private?
>By the name, I would expect that EscapeBarrier::deoptimize_objects()
>calls it for some internal tasks. But it does not.
Well, I'd say it is pretty internal, what's happening in that method. So IMHO
the suffix _internal
is a match.
> 2. My proposal: deoptimize_objects_all_threads() iterates all threads
> and calls deoptimize_objects(_one)_thread(thread) for each of these.
> That's how I would have named it.
> But no bike shedding, if you don't see what I mean it's not obvious.
Ok. We could have a quick call, too, if you like.
> > > Renaming deferred_locals to deferred_updates is good, as well as
> > > adding a datastructure for it.
> > > (Adding this data structure might be a breakout, too.)
> > >
> > > good.
> > >
> > > thread.cpp
> > >
> > > good.
> > >
> > > vframe.cpp
> > >
> > > Is this a bug in existing code?
> > > Makes sense.
> >
> > Depends on your definition of bug. There are no references to
> > vframe::is_entry_frame() in the
> > existing code. I would think it is a bug.
> So it is :)
I'm just afraid it could get fixed by removing the class entryVFrame.
> >
> > >
> > > vframe_hp.hpp
> > > (What stands _hp for? helper? The file should be named
> > compiledVFrame ...)
> > >
> > > not_global_escape_in_scope() ...
> > > Again, you mention escape analysis here. Comments above hold, too.
> >
> > I think it is the right name, because it is meaningful and simple.
> Ok, accepted ... given my understandings from above.
Ok.
> >
> > > You introduce JvmtiDeferredUpdates. Good.
> > >
> > > vframe_hp.cpp
> > >
> > > Changes for JvmtiDeferredUpdates, escape state accessors,
> > >
> > > line 422:
> > > Would an assertion assert(!info->owner_is_scalar_replaced(), ...) hold
> > > here?
> > >
> > >
> > > macros.hpp
> > > Good.
> > >
> > >
> > > Test coding
> > > ====
> > >
> > > compileBroker.h|cpp
> > >
> > > You introduce a third class of threads handled here and
> > > add a new flag to distinguish it. Before, the two kinds
> > > of threads were distinguished implicitly by passing in
> > > a compiler for compiler threads.
> > > The new thread kind is only used for testing in debug.
> > >
> > > make_thread:
> > > You could assert (comp != NULL...) to assure previous
> > > conditions.
> >
> > If replaced the if-statements with a switch-statement, made sure all enum-
> > elements are covered, and
> > added the assertion you suggested.
> >
> > > line 989 indentation broken
> >
> > You are referring to this block I assume:
> > (from
> > http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5/src/hots
> > pot/share/compiler/compileBroker.cpp.frames.html)
> >
> > 976 if (MethodFlushing) {
> > 977 // Initialize the sweeper thread
> > 978 Handle thread_oop = create_thread_oop("Sweeper thread", CHECK);
> > 979 jobject thread_handle = JNIHandles::make_local(THREAD,
> > thread_oop());
> > 980 make_thread(sweeper_t, thread_handle, NULL, NULL, THREAD);
> > 981 }
> > 982
> > 983 #if defined(ASSERT) && COMPILER2_OR_JVMCI
> > 984 if (DeoptimizeObjectsALot == 2) {
> > 985 // Initialize and sta
RFR(S) 8249293: Unsafe stackwalk in VM_GetOrSetLocal::doit_prologue()
Hi, please help review this fix for VM_GetOrSetLocal. It moves the unsafe stackwalk from the vm operation prologue before the safepoint into the doit() method executed at the safepoint. Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8249293/webrev.0/index.html Bug:https://bugs.openjdk.java.net/browse/JDK-8249293 According to the JVMTI spec on local variable access it is not required to suspend the target thread T [1]. The operation will simply fail with JVMTI_ERROR_NO_MORE_FRAMES if T is executing bytecodes. It will succeed though if T is blocked because of synchronization or executing some native code. The issue is that in the latter case the stack walk in VM_GetOrSetLocal::doit_prologue() to prepare the access to the local variable is unsafe, because it is done before the safepoint and it races with T returning to execute bytecodes making its stack not walkable. The included test shows that this can crash the VM if T wins the race. Manual testing: - new test test/hotspot/jtreg/serviceability/jvmti/GetLocalVariable/GetLocalWithoutSuspendTest.java - test/hotspot/jtreg/vmTestbase/nsk/jvmti - test/hotspot/jtreg/serviceability/jvmti Nightly regression tests @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Thanks, Richard. [1] https://docs.oracle.com/en/java/javase/14/docs/specs/jvmti.html#local
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
I see. Thanks for the explanation :) Richard. -Original Message- From: serguei.spit...@oracle.com Sent: Freitag, 5. Juni 2020 09:31 To: Reingruber, Richard ; 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/5/20 00:18, Reingruber, Richard wrote: > Hi, > >> The mach5 test run is good. > Thanks Serguei and thanks to everybody providing feedback! I just pushed the > change. Great, thanks! > Just curious: is mach5 an alias for tier5? The mach5 is a build and test system which also provides CI. Tier5 is one of the testing levels. > And is this mach5 the same as in "Job: > mach5-one-rrich-JDK-8238585-2-20200604-1334-11519059" which is the > (successful) submit repo job? Yes. I guess all mach5 jobs have this prefix. Thanks, Serguei > > Thanks, > Richard. > > -Original Message- > From: serguei.spit...@oracle.com > Sent: Donnerstag, 4. Juni 2020 04:07 > To: Reingruber, Richard ; > 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, > > The mach5 test run is good. > > Thanks, > Serguei > > > 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. >> >> Thanks, Richard. >> >> -Original Message- >> From: serguei.spit...@oracle.com >> Sent: Dienstag, 2. Juni 2020 18:55 >> To: Vladimir Kozlov ; Reingruber, Richard >> ; 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 >>>> Sent: Freitag, 7. Februar 2020 09:19 >>>> To: Reingruber, Richard ; >>>> 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 >>>> >>>> >>>>&g
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi, > The mach5 test run is good. Thanks Serguei and thanks to everybody providing feedback! I just pushed the change. Just curious: is mach5 an alias for tier5? And is this mach5 the same as in "Job: mach5-one-rrich-JDK-8238585-2-20200604-1334-11519059" which is the (successful) submit repo job? Thanks, Richard. -Original Message- From: serguei.spit...@oracle.com Sent: Donnerstag, 4. Juni 2020 04:07 To: Reingruber, Richard ; 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, The mach5 test run is good. Thanks, Serguei 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. > > Thanks, Richard. > > -Original Message- > From: serguei.spit...@oracle.com > Sent: Dienstag, 2. Juni 2020 18:55 > To: Vladimir Kozlov ; Reingruber, Richard > ; 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 >>> Sent: Freitag, 7. Februar 2020 09:19 >>> To: Reingruber, Richard ; >>> 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 >>>> >>>>
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Excellent. Thanks! Richard. -Original Message- From: serguei.spit...@oracle.com Sent: Dienstag, 2. Juni 2020 20:02 To: Reingruber, Richard ; 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 > Sent: Dienstag, 2. Juni 2020 18:55 > To: Vladimir Kozlov ; Reingruber, Richard > ; 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 >>> Sent: Freitag, 7. Februar 2020 09:19 >>> To: Reingruber, Richard ; >>> 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 >>>> >>>>
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
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. Thanks, Richard. -Original Message- From: serguei.spit...@oracle.com Sent: Dienstag, 2. Juni 2020 18:55 To: Vladimir Kozlov ; Reingruber, Richard ; 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 >> Sent: Freitag, 7. Februar 2020 09:19 >> To: Reingruber, Richard ; >> 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 >>> >>> >>>
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Thanks for the info, Vladimir, and for looking at the webrev. Best regards, Richard. -Original Message- From: Vladimir Kozlov Sent: Donnerstag, 28. Mai 2020 18:03 To: Reingruber, Richard ; 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 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 > Sent: Freitag, 7. Februar 2020 09:19 > To: Reingruber, Richard ; > 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 >>
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
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 Sent: Freitag, 7. Februar 2020 09:19 To: Reingruber, Richard ; 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 >
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Serguei,
> Thank you for the bug report update - it is helpful.
> The fix/update looks good in general but I need more time to check some
> points.
Sure. I'd be happy if you could look at it again.
> I'm thinking it would be more safe to run full tier5.
> I can do it after you get all thumbs ups.
The patch goes through extensive testing here at SAP every night since many
weeks. Still it would be
great if you could run full tier5.
I'll wait then for a view more thumbs...
Thanks, Richard.
-Original Message-
From: serguei.spit...@oracle.com
Sent: Donnerstag, 14. Mai 2020 00:32
To: Reingruber, Richard ; Patricio Chilano
; Vladimir Ivanov
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-...@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,
Thank you for the bug report update - it is helpful.
The fix/update looks good in general but I need more time to check some
points.
I'm thinking it would be more safe to run full tier5.
I can do it after you get all thumbs ups.
Thanks,
Serguei
On 4/24/20 01:18, Reingruber, Richard wrote:
> Hi Patricio, Vladimir, and Serguei,
>
> now that direct handshakes are available, I've updated the patch to make use
> of them.
>
> In addition I have done some clean-up changes I missed in the first webrev.
>
> Finally I have implemented the workaround suggested by Patricio to avoid
> nesting the handshake
> into the vm operation VM_SetFramePop [1]
>
> Kindly review again:
>
> Webrev:http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/
> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/
>
> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode
> can be replaced with a
> direct handshake:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585
>
> Testing:
>
> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds
> on all platforms.
>
> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737
>
> Thanks,
> Richard.
>
> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread,
> because it is no JavaThread.
>
> -Original Message-
> From: hotspot-dev On Behalf Of
> Reingruber, Richard
> Sent: Freitag, 14. Februar 2020 19:47
> To: Patricio Chilano ;
> serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
> hotspot-...@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 Patricio,
>
>> > I'm really glad you noticed the problematic nesting. This seems to be
> a general issue: currently a
>> > handshake cannot be nested in a vm operation. Maybe it should be
> asserted in the
>> > Handshake::execute() methods that they are not called by the vm thread
> evaluating a vm operation?
>> >
>> >> Alternatively I think you could do something similar to what we
> do in
>> >> Deoptimization::deoptimize_all_marked():
>> >>
>> >>EnterInterpOnlyModeClosure hs;
>> >>if (SafepointSynchronize::is_at_safepoint()) {
>> >> hs.do_thread(state->get_thread());
>> >>} else {
>> >> Handshake::execute(&hs, state->get_thread());
>> >>}
>> >> (you could pass “EnterInterpOnlyModeClosure” directly to the
>> >> HandshakeClosure() constructor)
>> >
>> > Maybe this could be used also in the Handshake::execute() methods as
> general solution?
>> Right, we could also do that. Avoiding to clear the polling page in
>> HandshakeState::clear_handshake() should be enough to fix this issue and
>> execute a handshake inside a safepoint, but adding that "if" statement
>> in Hanshake::execute() sounds good to avoid all the extra code that we
>> go through when executing a handshake. I filed 8239084 to make that
> change.
>
> Thanks for taking care of this and creating the RFE.
>
>>
>> >> I don’t know JVMTI code so I’m not sure if VM_EnterInterpOnlyMode
> is
>> >> always called in a nested operation or just sometimes.
>> >
&g
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Ok. Thanks for the feedback anyways.
Cheers, Richard.
-Original Message-
From: David Holmes
Sent: Donnerstag, 14. Mai 2020 07:29
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-...@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
> Still not a review, or is it now?
I'd say still not a review as I'm only looking at the general structure.
Cheers,
David
On 14/05/2020 1:37 am, Reingruber, Richard wrote:
> Hi David,
>
>> On 4/05/2020 8:33 pm, Reingruber, Richard wrote:
>>> // Trimmed the list of recipients. If the list gets too long then the
>>> message needs to be approved
>>> // by a moderator.
>
>> Yes I noticed that too :) In general if you send to hotspot-dev you
>> shouldn't need to also send to hotspot-X-dev.
>
> Makes sense. Will do so next time.
>
>>>
>>> This would be the post with the current webrev.1
>>>
>>>
>>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/031245.html
>
>> Sorry I missed that update. Okay so this is working with direct
>> handshakes now.
>
>> One style nit in jvmtiThreadState.cpp:
>
>> assert(SafepointSynchronize::is_at_safepoint() ||
>> ! (JavaThread *)Thread::current() == get_thread() ||
>> ! Thread::current() == get_thread()->active_handshaker(),
>> ! "bad synchronization with owner thread");
>
>> the ! lines should ident as follows
>
>> assert(SafepointSynchronize::is_at_safepoint() ||
>> (JavaThread *)Thread::current() == get_thread() ||
>> Thread::current() == get_thread()->active_handshaker(),
>>! "bad synchronization with owner thread");
>
> Sure.
>
>> Lets see how this plays out.
>
> Hopefully not too bad... :)
>
>>> Not a review but some general commentary ...
>
> Still not a review, or is it now?
>
> Thanks, Richard.
>
> -Original Message-
> From: David Holmes
> Sent: Mittwoch, 13. Mai 2020 07:43
> To: Reingruber, Richard ;
> serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
> hotspot-...@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
>
> On 4/05/2020 8:33 pm, Reingruber, Richard wrote:
>> // Trimmed the list of recipients. If the list gets too long then the
>> message needs to be approved
>> // by a moderator.
>
> Yes I noticed that too :) In general if you send to hotspot-dev you
> shouldn't need to also send to hotspot-X-dev.
>
>> Hi David,
>
> Hi Richard,
>
>>> On 28/04/2020 12:09 am, Reingruber, Richard wrote:
>>>> Hi David,
>>>>
>>>>> Not a review but some general commentary ...
>>>>
>>>> That's welcome.
>>
>>> Having had to take an even closer look now I have a review comment too :)
>>
>>> src/hotspot/share/prims/jvmtiThreadState.cpp
>>
>>> void JvmtiThreadState::invalidate_cur_stack_depth() {
>>> ! assert(SafepointSynchronize::is_at_safepoint() ||
>>> ! (Thread::current()->is_VM_thread() &&
>>> get_thread()->is_vmthread_processing_handshake()) ||
>>> (JavaThread *)Thread::current() == get_thread(),
>>> "must be current thread or at safepoint");
>>
>> You're looking at an outdated webrev, I'm afraid.
>>
>> This would be the post with the current webrev.1
>>
>>
>> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/031245.html
>
> Sorry I missed that update. Okay so this is working with direct
> handshakes now.
>
> One style nit in jvmtiThreadState.cpp:
>
> assert(SafepointSynchronize::is_at_safepoint() ||
> ! (JavaThread *)Thread::current() == get_thread() ||
> ! Thread::current() == get_thread()->active_handshaker(),
> ! "bad synchronization with owner thread");
>
> the ! lines should ident as follows
>
> assert(SafepointSynchronize::is_at_safepoint() ||
> (JavaThread *)Thread::current() == get_thread() ||
> Thread::current() == get_thread()->a
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi David,
> On 4/05/2020 8:33 pm, Reingruber, Richard wrote:
> > // Trimmed the list of recipients. If the list gets too long then the
> > message needs to be approved
> > // by a moderator.
> Yes I noticed that too :) In general if you send to hotspot-dev you
> shouldn't need to also send to hotspot-X-dev.
Makes sense. Will do so next time.
> >
> > This would be the post with the current webrev.1
> >
> >
> > http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/031245.html
> Sorry I missed that update. Okay so this is working with direct
> handshakes now.
> One style nit in jvmtiThreadState.cpp:
> assert(SafepointSynchronize::is_at_safepoint() ||
> ! (JavaThread *)Thread::current() == get_thread() ||
> ! Thread::current() == get_thread()->active_handshaker(),
> ! "bad synchronization with owner thread");
> the ! lines should ident as follows
> assert(SafepointSynchronize::is_at_safepoint() ||
> (JavaThread *)Thread::current() == get_thread() ||
> Thread::current() == get_thread()->active_handshaker(),
> ! "bad synchronization with owner thread");
Sure.
> Lets see how this plays out.
Hopefully not too bad... :)
>> Not a review but some general commentary ...
Still not a review, or is it now?
Thanks, Richard.
-Original Message-
From: David Holmes
Sent: Mittwoch, 13. Mai 2020 07:43
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-...@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
On 4/05/2020 8:33 pm, Reingruber, Richard wrote:
> // Trimmed the list of recipients. If the list gets too long then the message
> needs to be approved
> // by a moderator.
Yes I noticed that too :) In general if you send to hotspot-dev you
shouldn't need to also send to hotspot-X-dev.
> Hi David,
Hi Richard,
>> On 28/04/2020 12:09 am, Reingruber, Richard wrote:
>>> Hi David,
>>>
>>>> Not a review but some general commentary ...
>>>
>>> That's welcome.
>
>> Having had to take an even closer look now I have a review comment too :)
>
>> src/hotspot/share/prims/jvmtiThreadState.cpp
>
>> void JvmtiThreadState::invalidate_cur_stack_depth() {
>> ! assert(SafepointSynchronize::is_at_safepoint() ||
>> ! (Thread::current()->is_VM_thread() &&
>> get_thread()->is_vmthread_processing_handshake()) ||
>> (JavaThread *)Thread::current() == get_thread(),
>> "must be current thread or at safepoint");
>
> You're looking at an outdated webrev, I'm afraid.
>
> This would be the post with the current webrev.1
>
>
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/031245.html
Sorry I missed that update. Okay so this is working with direct
handshakes now.
One style nit in jvmtiThreadState.cpp:
assert(SafepointSynchronize::is_at_safepoint() ||
! (JavaThread *)Thread::current() == get_thread() ||
! Thread::current() == get_thread()->active_handshaker(),
! "bad synchronization with owner thread");
the ! lines should ident as follows
assert(SafepointSynchronize::is_at_safepoint() ||
(JavaThread *)Thread::current() == get_thread() ||
Thread::current() == get_thread()->active_handshaker(),
! "bad synchronization with owner thread");
Lets see how this plays out.
Cheers,
David
> Thanks, Richard.
>
> -Original Message-
> From: David Holmes
> Sent: Montag, 4. Mai 2020 08:51
> To: Reingruber, Richard ; Yasumasa Suenaga
> ; Patricio Chilano
> ; serguei.spit...@oracle.com; Vladimir
> Ivanov ; serviceability-dev@openjdk.java.net;
> hotspot-compiler-...@openjdk.java.net; hotspot-...@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 28/04/2020 12:09 am, Reingruber, Richard wrote:
>> Hi David,
>>
>>> Not a review but some general commentary ...
>>
>> That's welcome.
>
> Having had to take an even closer look now I have a review comment too :)
>
> src/hotspot/share/prims/jvmtiThreadState.cpp
>
> void JvmtiThreadState::invalidate_cur_stack_depth() {
> ! asser
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Thanks Martin.
Cheers, Richard.
-Original Message-
From: Doerr, Martin
Sent: Dienstag, 12. Mai 2020 10:43
To: Reingruber, Richard ; David Holmes
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-...@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,
I had already reviewed webrev.1. Looks good to me.
Thanks for contributing it.
Best regards,
Martin
> -Original Message-
> From: hotspot-runtime-dev boun...@openjdk.java.net> On Behalf Of Reingruber, Richard
> Sent: Montag, 4. Mai 2020 12:33
> To: David Holmes ; serviceability-
> d...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-
> d...@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
>
> // Trimmed the list of recipients. If the list gets too long then the message
> needs to be approved
> // by a moderator.
>
> Hi David,
>
> > On 28/04/2020 12:09 am, Reingruber, Richard wrote:
> > > Hi David,
> > >
> > >> Not a review but some general commentary ...
> > >
> > > That's welcome.
>
> > Having had to take an even closer look now I have a review comment too :)
>
> > src/hotspot/share/prims/jvmtiThreadState.cpp
>
> >void JvmtiThreadState::invalidate_cur_stack_depth() {
> > ! assert(SafepointSynchronize::is_at_safepoint() ||
> > ! (Thread::current()->is_VM_thread() &&
> > get_thread()->is_vmthread_processing_handshake()) ||
> >(JavaThread *)Thread::current() == get_thread(),
> >"must be current thread or at safepoint");
>
> You're looking at an outdated webrev, I'm afraid.
>
> This would be the post with the current webrev.1
>
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-
> April/031245.html
>
> Thanks, Richard.
>
> -Original Message-
> From: David Holmes
> Sent: Montag, 4. Mai 2020 08:51
> To: Reingruber, Richard ; Yasumasa Suenaga
> ; Patricio Chilano
> ; serguei.spit...@oracle.com; Vladimir
> Ivanov ; serviceability-
> d...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-
> d...@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 28/04/2020 12:09 am, Reingruber, Richard wrote:
> > Hi David,
> >
> >> Not a review but some general commentary ...
> >
> > That's welcome.
>
> Having had to take an even closer look now I have a review comment too :)
>
> src/hotspot/share/prims/jvmtiThreadState.cpp
>
>void JvmtiThreadState::invalidate_cur_stack_depth() {
> ! assert(SafepointSynchronize::is_at_safepoint() ||
> ! (Thread::current()->is_VM_thread() &&
> get_thread()->is_vmthread_processing_handshake()) ||
>(JavaThread *)Thread::current() == get_thread(),
>"must be current thread or at safepoint");
>
> The message needs updating to include handshakes.
>
> More below ...
>
> >> On 25/04/2020 2:08 am, Reingruber, Richard wrote:
> >>> Hi Yasumasa, Patricio,
> >>>
> >>>>>> I will send review request to replace VM_SetFramePop to
> handshake in early next week in JDK-8242427.
> >>>>>> Does it help you? I think it gives you to remove workaround.
> >>>>>
> >>>>> I think it would not help that much. Note that when replacing
> VM_SetFramePop with a direct handshake
> >>>>> you could not just execute VM_EnterInterpOnlyMode as a nested vm
> operation [1]. So you would have to
> >>>>> change/replace VM_EnterInterpOnlyMode and I would have to adapt
> to these changes.
> >>>
> >>>> Thanks for your information.
> >>>> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and
> vmTestbase/nsk/jvmti/NotifyFramePop.
> >>>> I will modify and will test it after yours.
> >>>
> >>> Thanks :)
> >>>
> >>>>> Also my first impression was that it won't be that easy from a
> synchronization point o
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
// Trimmed the list of recipients. If the list gets too long then the message
needs to be approved
// by a moderator.
Hi David,
> On 28/04/2020 12:09 am, Reingruber, Richard wrote:
> > Hi David,
> >
> >> Not a review but some general commentary ...
> >
> > That's welcome.
> Having had to take an even closer look now I have a review comment too :)
> src/hotspot/share/prims/jvmtiThreadState.cpp
>void JvmtiThreadState::invalidate_cur_stack_depth() {
> ! assert(SafepointSynchronize::is_at_safepoint() ||
> ! (Thread::current()->is_VM_thread() &&
> get_thread()->is_vmthread_processing_handshake()) ||
>(JavaThread *)Thread::current() == get_thread(),
>"must be current thread or at safepoint");
You're looking at an outdated webrev, I'm afraid.
This would be the post with the current webrev.1
http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-April/031245.html
Thanks, Richard.
-Original Message-
From: David Holmes
Sent: Montag, 4. Mai 2020 08:51
To: Reingruber, Richard ; Yasumasa Suenaga
; Patricio Chilano
; serguei.spit...@oracle.com; Vladimir
Ivanov ; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-...@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 28/04/2020 12:09 am, Reingruber, Richard wrote:
> Hi David,
>
>> Not a review but some general commentary ...
>
> That's welcome.
Having had to take an even closer look now I have a review comment too :)
src/hotspot/share/prims/jvmtiThreadState.cpp
void JvmtiThreadState::invalidate_cur_stack_depth() {
! assert(SafepointSynchronize::is_at_safepoint() ||
! (Thread::current()->is_VM_thread() &&
get_thread()->is_vmthread_processing_handshake()) ||
(JavaThread *)Thread::current() == get_thread(),
"must be current thread or at safepoint");
The message needs updating to include handshakes.
More below ...
>> On 25/04/2020 2:08 am, Reingruber, Richard wrote:
>>> Hi Yasumasa, Patricio,
>>>
>>>>>> I will send review request to replace VM_SetFramePop to handshake in
>>>>>> early next week in JDK-8242427.
>>>>>> Does it help you? I think it gives you to remove workaround.
>>>>>
>>>>> I think it would not help that much. Note that when replacing
>>>>> VM_SetFramePop with a direct handshake
>>>>> you could not just execute VM_EnterInterpOnlyMode as a nested vm
>>>>> operation [1]. So you would have to
>>>>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these
>>>>> changes.
>>>
>>>> Thanks for your information.
>>>> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and
>>>> vmTestbase/nsk/jvmti/NotifyFramePop.
>>>> I will modify and will test it after yours.
>>>
>>> Thanks :)
>>>
>>>>> Also my first impression was that it won't be that easy from a
>>>>> synchronization point of view to
>>>>> replace VM_SetFramePop with a direct handshake. E.g.
>>>>> VM_SetFramePop::doit() indirectly calls
>>>>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets,
>>>>> JvmtiFramePop fpop) where
>>>>> JvmtiThreadState_lock is acquired with safepoint check, if not at
>>>>> safepoint. It's not directly clear
>>>>> to me, how this has to be handled.
>>>
>>>> I think JvmtiEventController::set_frame_pop() should hold
>>>> JvmtiThreadState_lock because it affects other JVMTI operation especially
>>>> FramePop event.
>>>
>>> Yes. To me it is unclear what synchronization is necessary, if it is called
>>> during a handshake. And
>>> also I'm unsure if a thread should do safepoint checks while executing a
>>> handshake.
>
>> I'm growing increasingly concerned that use of direct handshakes to
>> replace VM operations needs a much greater examination for correctness
>> than might initially be thought. I see a number of issues:
>
> I agree. I'll address your concerns in the context of this review thread for
> JDK-8238585 below.
>
> In addition I would suggest to take the general part of the discussion to a
> dedicated thread or to
> the review thread for JDK-8242427. I would like to keep this thread closer
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi David, > Not a review but some general commentary ... That's welcome. > On 25/04/2020 2:08 am, Reingruber, Richard wrote: > > Hi Yasumasa, Patricio, > > > >>>> I will send review request to replace VM_SetFramePop to handshake in > >>>> early next week in JDK-8242427. > >>>> Does it help you? I think it gives you to remove workaround. > >>> > >>> I think it would not help that much. Note that when replacing > >>> VM_SetFramePop with a direct handshake > >>> you could not just execute VM_EnterInterpOnlyMode as a nested vm > >>> operation [1]. So you would have to > >>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these > >>> changes. > > > >> Thanks for your information. > >> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and > >> vmTestbase/nsk/jvmti/NotifyFramePop. > >> I will modify and will test it after yours. > > > > Thanks :) > > > >>> Also my first impression was that it won't be that easy from a > >>> synchronization point of view to > >>> replace VM_SetFramePop with a direct handshake. E.g. > >>> VM_SetFramePop::doit() indirectly calls > >>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, > >>> JvmtiFramePop fpop) where > >>> JvmtiThreadState_lock is acquired with safepoint check, if not at > >>> safepoint. It's not directly clear > >>> to me, how this has to be handled. > > > >> I think JvmtiEventController::set_frame_pop() should hold > >> JvmtiThreadState_lock because it affects other JVMTI operation especially > >> FramePop event. > > > > Yes. To me it is unclear what synchronization is necessary, if it is called > > during a handshake. And > > also I'm unsure if a thread should do safepoint checks while executing a > > handshake. > I'm growing increasingly concerned that use of direct handshakes to > replace VM operations needs a much greater examination for correctness > than might initially be thought. I see a number of issues: I agree. I'll address your concerns in the context of this review thread for JDK-8238585 below. In addition I would suggest to take the general part of the discussion to a dedicated thread or to the review thread for JDK-8242427. I would like to keep this thread closer to its subject. > First, the VMThread executes (most) VM operations with a clean stack in > a clean state, so it has lots of room to work. If we now execute the > same logic in a JavaThread then we risk hitting stackoverflows if > nothing else. But we are also now executing code in a JavaThread and so > we have to be sure that code is not going to act differently (in a bad > way) if executed by a JavaThread rather than the VMThread. For example, > may it be possible that if executing in the VMThread we defer some > activity that might require execution of Java code, or else hand it off > to one of the service threads? If we execute that code directly in the > current JavaThread instead we may not be in a valid state (e.g. consider > re-entrancy to various subsystems that is not allowed). It is not too complex, what EnterInterpOnlyModeClosure::do_thread() is doing. I already added a paragraph to the JBS-Item [1] explaining why the direct handshake is sufficient from a synchronization point of view. Furthermore the stack is walked and the return pc of compiled frames is replaced with the address of the deopt handler. I can't see why this cannot be done with a direct handshake. Something very similar is already done in JavaThread::deoptimize_marked_methods() which is executed as part of an ordinary handshake. The demand on stack-space should be very modest. I would not expect a higher risk for stackoverflow. > Second, we have this question mark over what happens if the operation > hits further safepoint or handshake polls/checks? Are there constraints > on what is allowed here? How can we recognise this problem may exist and > so deal with it? The thread in EnterInterpOnlyModeClosure::do_thread() can't become safepoint/handshake safe. I tested locally test/hotspot/jtreg:vmTestbase_nsk_jvmti with a NoSafepointVerifier. > Third, while we are generally considering what appear to be > single-thread operations, which should be amenable to a direct > handshake, we also have to be careful that some of the code involved > doesn't already expect/assume we are at a safepoint - e.g. a VM op may > not need to take a lock where a direct handshake might! See again my arguments in the JBS item [1].
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Patricio, thanks a lot for all the explanations. At least to me they are really helpful. :) Cheers, Richard. -Original Message- From: Patricio Chilano Sent: Samstag, 25. April 2020 11:23 To: Reingruber, Richard ; Yasumasa Suenaga ; serguei.spit...@oracle.com; Vladimir Ivanov ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-...@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 4/24/20 6:41 PM, Reingruber, Richard wrote: > Hi Patricio, > >>> @Patricio, coming back to my question [1]: >>> >>> In the example you gave in your answer [2]: the java thread would execute a >>> vm operation during a >>> direct handshake operation, while the VMThread is actually in the middle of >>> a VM_HandshakeAllThreads >>> operation, waiting to handshake the same handshakee: why can't the VMThread >>> just proceed? The >>> handshakee would be safepoint safe, wouldn't it? >> Because the VMThread would not be able to decrement _processing_sem to >> claim the operation and execute the closure for that handshakee. If >> another JavaThread is doing a direct handshake with that same handshakee >> and called a new VM operation inside the execution of the >> HandshakeClosure in do_handshake(), nobody would be able to decrement >> the _processing_sem anymore until the original direct operation finished >> and the semaphore is signaled again. > Thanks, understood. On a higher level: a JavaThread can have at most one > handshake operation being > processed at at time. Exactly. As of now we don't handle the case where another handshake operation on the same handshakee is called inside _handshake_cl->do_thread(). If this happens we will deadlock. >> So this can happen despite the >> state of the handshakee is "handshake/safepoint safe". Changing the >> nested VM operation to be a direct handshake would have the same issue. >> Actually as the code is right now we would not even get pass setting the >> handshake operation because in that case we would block in the >> _handshake_turn_sem for the same reason. > Don't really understand the details here, but that's ok. > Interesting that _handshake_turn_sem gets signaled before or after > do_handshake() depending if the > handshake operation is processed by handshakee. Comments say "Disarm > before/after executing > operation" but not why :) Yes, that pattern actually relates with clearing _operation and predates direct handshakes. In theory we should always call do_handshake() first and then clear the handshake. This is what we do when the operation is processed by the handshaker, and it is necessary to be that way, otherwise if we clear the handshake first then the handshakee might transition from the safe state and never see that it actually has to stop for the handshake. Now, when the handshake operation is processed by the handshakee itself we don't have that issue, so it doesn't matter if we clear it before or after. The reason we do it before is to avoid the VMThread to execute unnecessary instructions in try_process(). This is specially true for the VM_HandshakeAllThreads operation case. If the VMThread sees that a JavaThread doesn't have an operation set, it can just continue to try to process the next JavaThread, instead of going through the unnecessary steps of checking the state of the JavaThread and trying to execute a try_wait() operation on the _processing_sem which we know won't succeed. Now for the direct handshake case doing it before or after doesn't really matter and so I just copied the pattern from the non-direct case to make it consistent in that same method. >> So changing VM_SetFramePop to use direct handshakes in the future will >> probably create that last issue I mentioned. Now, since it is executed >> at a safepoint, with your workaround in enter_interp_only_mode() we >> avoid those nested issues in . Maybe 8239084 would have to be revisited >> to address nested operations in all cases. It is not clear to me now >> though if we should handle that in the handshake code or the caller of a >> certain operation should know it might be called in a nested scenario >> and should handle it. > Last question: is it ok for the processor of a direct handshake operation to > do safepoint/handshake > checks? I wouldn't see a reason, why not. But certainly I would avoid it. I tried to think of possible issues with that (independent of the closure logic) but I coul
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Patricio, > > @Patricio, coming back to my question [1]: > > > > In the example you gave in your answer [2]: the java thread would execute a > > vm operation during a > > direct handshake operation, while the VMThread is actually in the middle of > > a VM_HandshakeAllThreads > > operation, waiting to handshake the same handshakee: why can't the VMThread > > just proceed? The > > handshakee would be safepoint safe, wouldn't it? > Because the VMThread would not be able to decrement _processing_sem to > claim the operation and execute the closure for that handshakee. If > another JavaThread is doing a direct handshake with that same handshakee > and called a new VM operation inside the execution of the > HandshakeClosure in do_handshake(), nobody would be able to decrement > the _processing_sem anymore until the original direct operation finished > and the semaphore is signaled again. Thanks, understood. On a higher level: a JavaThread can have at most one handshake operation being processed at at time. > So this can happen despite the > state of the handshakee is "handshake/safepoint safe". Changing the > nested VM operation to be a direct handshake would have the same issue. > Actually as the code is right now we would not even get pass setting the > handshake operation because in that case we would block in the > _handshake_turn_sem for the same reason. Don't really understand the details here, but that's ok. Interesting that _handshake_turn_sem gets signaled before or after do_handshake() depending if the handshake operation is processed by handshakee. Comments say "Disarm before/after executing operation" but not why :) > So changing VM_SetFramePop to use direct handshakes in the future will > probably create that last issue I mentioned. Now, since it is executed > at a safepoint, with your workaround in enter_interp_only_mode() we > avoid those nested issues in . Maybe 8239084 would have to be revisited > to address nested operations in all cases. It is not clear to me now > though if we should handle that in the handshake code or the caller of a > certain operation should know it might be called in a nested scenario > and should handle it. Last question: is it ok for the processor of a direct handshake operation to do safepoint/handshake checks? I wouldn't see a reason, why not. But certainly I would avoid it. > I'll look a bit more at the updated patch but at first glance looks good. Thanks, Richard. -Original Message- From: Patricio Chilano Sent: Freitag, 24. April 2020 19:14 To: Reingruber, Richard ; Yasumasa Suenaga ; serguei.spit...@oracle.com; Vladimir Ivanov ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-...@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, Just jumping into your last question for now. : ) On 4/24/20 1:08 PM, Reingruber, Richard wrote: > Hi Yasumasa, Patricio, > >>>> I will send review request to replace VM_SetFramePop to handshake in early >>>> next week in JDK-8242427. >>>> Does it help you? I think it gives you to remove workaround. >>> I think it would not help that much. Note that when replacing >>> VM_SetFramePop with a direct handshake >>> you could not just execute VM_EnterInterpOnlyMode as a nested vm operation >>> [1]. So you would have to >>> change/replace VM_EnterInterpOnlyMode and I would have to adapt to these >>> changes. >> Thanks for your information. >> I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and >> vmTestbase/nsk/jvmti/NotifyFramePop. >> I will modify and will test it after yours. > Thanks :) > >>> Also my first impression was that it won't be that easy from a >>> synchronization point of view to >>> replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() >>> indirectly calls >>> JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop >>> fpop) where >>> JvmtiThreadState_lock is acquired with safepoint check, if not at >>> safepoint. It's not directly clear >>> to me, how this has to be handled. >> I think JvmtiEventController::set_frame_pop() should hold >> JvmtiThreadState_lock because it affects other JVMTI operation especially >> FramePop event. > Yes. To me it is unclear what synchronization is necessary, if it is called > during a handshake. And > also I'm unsure if
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Yasumasa, Patricio, > >> I will send review request to replace VM_SetFramePop to handshake in early > >> next week in JDK-8242427. > >> Does it help you? I think it gives you to remove workaround. > > > > I think it would not help that much. Note that when replacing > > VM_SetFramePop with a direct handshake > > you could not just execute VM_EnterInterpOnlyMode as a nested vm operation > > [1]. So you would have to > > change/replace VM_EnterInterpOnlyMode and I would have to adapt to these > > changes. > Thanks for your information. > I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and > vmTestbase/nsk/jvmti/NotifyFramePop. > I will modify and will test it after yours. Thanks :) > > Also my first impression was that it won't be that easy from a > > synchronization point of view to > > replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() > > indirectly calls > > JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop > > fpop) where > > JvmtiThreadState_lock is acquired with safepoint check, if not at > > safepoint. It's not directly clear > > to me, how this has to be handled. > I think JvmtiEventController::set_frame_pop() should hold > JvmtiThreadState_lock because it affects other JVMTI operation especially > FramePop event. Yes. To me it is unclear what synchronization is necessary, if it is called during a handshake. And also I'm unsure if a thread should do safepoint checks while executing a handshake. @Patricio, coming back to my question [1]: In the example you gave in your answer [2]: the java thread would execute a vm operation during a direct handshake operation, while the VMThread is actually in the middle of a VM_HandshakeAllThreads operation, waiting to handshake the same handshakee: why can't the VMThread just proceed? The handshakee would be safepoint safe, wouldn't it? Thanks, Richard. [1] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301677&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301677 [2] https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14301763&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14301763 -Original Message- From: Yasumasa Suenaga Sent: Freitag, 24. April 2020 17:23 To: Reingruber, Richard ; Patricio Chilano ; serguei.spit...@oracle.com; Vladimir Ivanov ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-...@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 2020/04/24 23:44, Reingruber, Richard wrote: > Hi Yasumasa, > >> I will send review request to replace VM_SetFramePop to handshake in early >> next week in JDK-8242427. >> Does it help you? I think it gives you to remove workaround. > > I think it would not help that much. Note that when replacing VM_SetFramePop > with a direct handshake > you could not just execute VM_EnterInterpOnlyMode as a nested vm operation > [1]. So you would have to > change/replace VM_EnterInterpOnlyMode and I would have to adapt to these > changes. Thanks for your information. I tested my patch with both vmTestbase/nsk/jvmti/PopFrame and vmTestbase/nsk/jvmti/NotifyFramePop. I will modify and will test it after yours. > Also my first impression was that it won't be that easy from a > synchronization point of view to > replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit() > indirectly calls > JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop > fpop) where > JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint. > It's not directly clear > to me, how this has to be handled. I think JvmtiEventController::set_frame_pop() should hold JvmtiThreadState_lock because it affects other JVMTI operation especially FramePop event. Thanks, Yasumasa > So it appears to me that it would be easier to push JDK-8242427 after this > (JDK-8238585). > >> (The patch is available, but I want to see the result of PIT in this weekend >> whether JDK-8242425 works fine.) > > Would be interesting to see how you handled the issues above :) > > Thanks, Richard. > > [1] See question in comment > https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030 > > -Original Message- > From: Yasumasa Suenaga > Sent
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Yasumasa,
> I will send review request to replace VM_SetFramePop to handshake in early
> next week in JDK-8242427.
> Does it help you? I think it gives you to remove workaround.
I think it would not help that much. Note that when replacing VM_SetFramePop
with a direct handshake
you could not just execute VM_EnterInterpOnlyMode as a nested vm operation [1].
So you would have to
change/replace VM_EnterInterpOnlyMode and I would have to adapt to these
changes.
Also my first impression was that it won't be that easy from a synchronization
point of view to
replace VM_SetFramePop with a direct handshake. E.g. VM_SetFramePop::doit()
indirectly calls
JvmtiEventController::set_frame_pop(JvmtiEnvThreadState *ets, JvmtiFramePop
fpop) where
JvmtiThreadState_lock is acquired with safepoint check, if not at safepoint.
It's not directly clear
to me, how this has to be handled.
So it appears to me that it would be easier to push JDK-8242427 after this
(JDK-8238585).
> (The patch is available, but I want to see the result of PIT in this weekend
> whether JDK-8242425 works fine.)
Would be interesting to see how you handled the issues above :)
Thanks, Richard.
[1] See question in comment
https://bugs.openjdk.java.net/browse/JDK-8230594?focusedCommentId=14302030&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14302030
-Original Message-
From: Yasumasa Suenaga
Sent: Freitag, 24. April 2020 13:34
To: Reingruber, Richard ; Patricio Chilano
; serguei.spit...@oracle.com; Vladimir
Ivanov ; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-...@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,
I will send review request to replace VM_SetFramePop to handshake in early next
week in JDK-8242427.
Does it help you? I think it gives you to remove workaround.
(The patch is available, but I want to see the result of PIT in this weekend
whether JDK-8242425 works fine.)
Thanks,
Yasumasa
On 2020/04/24 17:18, Reingruber, Richard wrote:
> Hi Patricio, Vladimir, and Serguei,
>
> now that direct handshakes are available, I've updated the patch to make use
> of them.
>
> In addition I have done some clean-up changes I missed in the first webrev.
>
> Finally I have implemented the workaround suggested by Patricio to avoid
> nesting the handshake
> into the vm operation VM_SetFramePop [1]
>
> Kindly review again:
>
> Webrev:http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/
> Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/
>
> I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode
> can be replaced with a
> direct handshake:
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8238585
>
> Testing:
>
> * JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds
> on all platforms.
>
> * Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737
>
> Thanks,
> Richard.
>
> [1] An assertion in Handshake::execute_direct() fails, if called be VMThread,
> because it is no JavaThread.
>
> -Original Message-
> From: hotspot-dev On Behalf Of
> Reingruber, Richard
> Sent: Freitag, 14. Februar 2020 19:47
> To: Patricio Chilano ;
> serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
> hotspot-...@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 Patricio,
>
>> > I'm really glad you noticed the problematic nesting. This seems to be
> a general issue: currently a
>> > handshake cannot be nested in a vm operation. Maybe it should be
> asserted in the
>> > Handshake::execute() methods that they are not called by the vm thread
> evaluating a vm operation?
>> >
>> >> Alternatively I think you could do something similar to what we
> do in
>> >> Deoptimization::deoptimize_all_marked():
>> >>
>> >>EnterInterpOnlyModeClosure hs;
>> >>if (SafepointSynchronize::is_at_safepoint()) {
>> >> hs.do_thread(state->get_thread());
>> >>} else {
>> >> Handshake::execute(&hs, state->get_thread());
>> >>}
>> >> (you could pass “Enter
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Patricio, Vladimir, and Serguei,
now that direct handshakes are available, I've updated the patch to make use of
them.
In addition I have done some clean-up changes I missed in the first webrev.
Finally I have implemented the workaround suggested by Patricio to avoid
nesting the handshake
into the vm operation VM_SetFramePop [1]
Kindly review again:
Webrev:http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1/
Webrev(delta): http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.1.inc/
I updated the JBS item explaining why the vm operation VM_EnterInterpOnlyMode
can be replaced with a
direct handshake:
JBS: https://bugs.openjdk.java.net/browse/JDK-8238585
Testing:
* JCK and JTREG tests, also in Xcomp mode with fastdebug and release builds on
all platforms.
* Submit-repo: mach5-one-rrich-JDK-8238585-20200423-1436-10441737
Thanks,
Richard.
[1] An assertion in Handshake::execute_direct() fails, if called be VMThread,
because it is no JavaThread.
-Original Message-
From: hotspot-dev On Behalf Of
Reingruber, Richard
Sent: Freitag, 14. Februar 2020 19:47
To: Patricio Chilano ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-...@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 Patricio,
> > I'm really glad you noticed the problematic nesting. This seems to be a
general issue: currently a
> > handshake cannot be nested in a vm operation. Maybe it should be asserted
in the
> > Handshake::execute() methods that they are not called by the vm thread
evaluating a vm operation?
> >
> >> Alternatively I think you could do something similar to what we do in
> >> Deoptimization::deoptimize_all_marked():
> >>
> >>EnterInterpOnlyModeClosure hs;
> >>if (SafepointSynchronize::is_at_safepoint()) {
> >> hs.do_thread(state->get_thread());
> >>} else {
> >> Handshake::execute(&hs, state->get_thread());
> >>}
> >> (you could pass “EnterInterpOnlyModeClosure” directly to the
> >> HandshakeClosure() constructor)
> >
> > Maybe this could be used also in the Handshake::execute() methods as
general solution?
> Right, we could also do that. Avoiding to clear the polling page in
> HandshakeState::clear_handshake() should be enough to fix this issue and
> execute a handshake inside a safepoint, but adding that "if" statement
> in Hanshake::execute() sounds good to avoid all the extra code that we
> go through when executing a handshake. I filed 8239084 to make that change.
Thanks for taking care of this and creating the RFE.
>
> >> I don’t know JVMTI code so I’m not sure if VM_EnterInterpOnlyMode is
> >> always called in a nested operation or just sometimes.
> >
> > At least one execution path without vm operation exists:
> >
> >JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState
*) : void
> >
JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) :
jlong
> >JvmtiEventControllerPrivate::recompute_enabled() : void
> > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent,
bool) : void (2 matches)
> >JvmtiEventController::change_field_watch(jvmtiEvent, bool) :
void
> > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError
> >jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) :
jvmtiError
> >
> > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main
intent to replace it with a
> > handshake, but to avoid making the compiled methods on stack
not_entrant unless I'm further
> > encouraged to do it with a handshake :)
> Ah! I think you can still do it with a handshake with the
> Deoptimization::deoptimize_all_marked() like solution. I can change the
> if-else statement with just the Handshake::execute() call in 8239084.
> But up to you. : )
Well, I think that's enough encouragement :)
I'll wait for 8239084 and try then again.
(no urgency and all)
Thanks,
Richard.
-Original Message-
From: Patricio Chilano
Sent: Freitag, 14. Februar 2020 15:54
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net;
hotspot-gc-...@openjdk.java.net
Subject: Re: RFR(S) 8238585: Use handshake for
JvmtiEventControll
RE: RFR: 8242425: JVMTI monitor operations should use Thread-Local Handshakes
Hi Yasumasa,
I'm obviously late to this review. Still I wanted to let you know, that there's
another file in the
source tree that lists the VM operations in the VM (just found out about it
myself):
src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMOps.java
Probably you should remove the VM operations from that file too.
It seems to be part of the serviceability agent, which I hardly know. Would be
good if somebody
who is more familiar with it could let us know...
Best regards,
Richard.
-Original Message-
From: serviceability-dev On
Behalf Of Yasumasa Suenaga
Sent: Montag, 20. April 2020 02:33
To: serviceability-dev@openjdk.java.net
Cc: yasue...@gmail.com
Subject: Re: RFR: 8242425: JVMTI monitor operations should use Thread-Local
Handshakes
Hi all,
Could you review it?
JBS: https://bugs.openjdk.java.net/browse/JDK-8242425
webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/
I need one more reviewer to push.
Thanks,
Yasumasa
On 2020/04/17 5:13, serguei.spit...@oracle.com wrote:
> Hi Yasumasa,
>
> Thank you for the update.
> It looks good.
>
> Thanks,
> Serguei
>
>
> On 4/10/20 04:30, Yasumasa Suenaga wrote:
>> Hi Serguei,
>>
>> I use current_jt in this webrev. Could you review again?
>>
>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.02/
>>
>> I tested this change with vmTestbase/nsk/jvmti, they are fine on my Linux
>> x64.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2020/04/10 17:21, serguei.spit...@oracle.com wrote:
>>> Hi Yasumasa,
>>>
>>> Thank you for the update.
>>>
>>> Minor:
>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/src/hotspot/share/prims/jvmtiEnvBase.cpp.udiff.html
>>>
>>> + err = get_locked_objects_in_frame(JavaThread::current(), java_thread,
>>> jvf, owned_monitors_list, depth-1); . . .
>>>
>>> + JvmtiMonitorClosure jmc(java_thread, JavaThread::current(),
>>> owned_monitors_list, this);
>>>
>>> You can use current_jt instead of JavaThread::current() above.
>>>
>>> There is also some test coverage in the vmTestbase/nsk/jvmti/scenarios
>>> tests.
>>> This one as well:
>>> test/hotspot/jtreg/vmTestbase/nsk/jvmti/unit/functions/nosuspendMonitorInfo/JvmtiTest
>>> Probably it is easier to run all vmTestbase/nsk/jvmti tests.
>>>
>>> Thanks,
>>> Serguei
>>>
>>>
>>> On 4/10/20 01:05, Yasumasa Suenaga wrote:
Hi Serguei,
Thanks for your comment!
I uploaded new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.01/
I ran following tests, and all of them were passed on my Linux x64.
- vmTestbase/nsk/jvmti/GetCurrentContendedMonitor
- vmTestbase/nsk/jvmti/GetOwnedMonitorInfo
- vmTestbase/nsk/jdi
- vmTestbase/nsk/jdwp
- serviceability/jvmti/GetOwnedMonitorInfo
- serviceability/jvmti/GetOwnedMonitorStackDepthInfo
- serviceability/jdwp
Thanks,
Yasumasa
On 2020/04/10 14:50, serguei.spit...@oracle.com wrote:
> Hi Yasumasa,
>
> It looks pretty good in general.
> A couple of comments though.
>
> http://cr.openjdk.java.net/~ysuenaga/JDK-8242425/webrev.00/src/hotspot/share/prims/jvmtiEnvBase.cpp.frames.html
>
> 650 JvmtiEnvBase::get_current_contended_monitor(JavaThread *java_thread,
> jobject *monitor_ptr) {
> 651 assert(!Thread::current()->is_VM_thread() &&
> 652 (Thread::current() == java_thread ||
> 653 Thread::current() == java_thread->active_handshaker()),
> 654 "call by myself or at direct handshake");
>
> ...
>
> 685 JvmtiEnvBase::get_owned_monitors(JavaThread* java_thread,
> 686 GrowableArray *owned_monitors_list) {
> 687 jvmtiError err = JVMTI_ERROR_NONE;
> 688 assert(!Thread::current()->is_VM_thread() &&
> 689 (Thread::current() == java_thread ||
> 690 Thread::current() == java_thread->active_handshaker()),
> 691 "call by myself or at direct handshake");
>
> I'd suggest to add this at the beginning:
> JavaThread *current_jt = JavaThread::current();
>
>
> 676 JavaThread *current_jt = reinterpret_cast *>(JavaThread::current());
>
> There is not need in reinterpret_cast. Also, you can use
> the current_jt defined above.
>
> Also, please, removed these two definitions as they became unused with
> your fix:
> src/hotspot/share/runtime/vmOperations.hpp:
> template(GGetCurrentContendedMonitoretOwnedMonitorInfo) \
> src/hotspot/share/runtime/vmOperations.hpp: template() \
>
> The impacted JVMTI monitor functions are used in the JDWP agent to
> support the JDI ThreadReference implementation.
> To be safe the JDI & JDWP tests have to be run as well. It is well
> covered by the tier-5.
>
> Thanks,
> Serguei
>
>
> On 4/9/20 21:46, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> Please review this change:
>>
>> JBS: https://bugs.openjdk
RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump
Hi Ralf,
> > 767: I think _current->in_used doesn't take the final 9 bytes into account
> > that are written in
> > DumperSupport::end_of_dump() after the last dump segment has been finished.
> > You could call get_new_buffer() instead of the if clause.
> Wow, how did you found this? I've fixed it by making sure we flush the
> DumpWriter before calling the deactivate method.
Spending long hours on the review ;)
Ok with the fix.
> > ### src/java.base/share/native/libzip/zip_util.c
> > 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free()
> > performance wise. But have you
> > measured the performance gain? In other words: is it worth it? :)
> This is not done for performance, but to make sure the allocation will not
> fail midway during writing the dump. Maybe it is not worth it, though.
Understood. The heap dump will succeed if you can allocate at least one
WriteWork instance. Without
that you could get out of memory errors in the zlib which would make the dump
fail. Ok!
> http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.2/
Thanks for the clarifications and the changes in the new webrev.
Webrev.2 looks good to me.
Cheers, Richard.
-Original Message-----
From: Schmelter, Ralf
Sent: Montag, 20. April 2020 10:14
To: Reingruber, Richard ; Ioi Lam
; Langer, Christoph ; Yasumasa
Suenaga ; serguei.spit...@oracle.com;
hotspot-runtime-...@openjdk.java.net runtime
Cc: serviceability-dev@openjdk.java.net
Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump
Hi Richard,
thanks for the review. I have incorporated your remarks into a new webrev:
http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.2/
Some remarks to specific points:
> ### src/hotspot/share/services/heapDumper.cpp
> 762: assert(_active, "Must be active");
>
> It appears to me that the assertion would fail, if an error occurred creating
> the CompressionBackend.
You are supposed to check for errors after creating the DumpWriter (which
creates the CompressionBackend). And in case of an error, you directly destruct
the object. I've added a comment to make that clear.
> 767: I think _current->in_used doesn't take the final 9 bytes into account
> that are written in
> DumperSupport::end_of_dump() after the last dump segment has been finished.
> You could call get_new_buffer() instead of the if clause.
Wow, how did you found this? I've fixed it by making sure we flush the
DumpWriter before calling the deactivate method.
> 1064: DumpWriter::DumpWriter()
>
> There doesn't seem to be enough error handling if _buffer cannot be allocated.
> E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop.
As described above, this will not happen if we check for error after
constructing the DumpWriter.
> ### src/java.base/share/native/libzip/zip_util.c
> 1610: Will be hard to beat zlib_block_alloc() and zlib_block_free()
> performance wise. But have you
> measured the performance gain? In other words: is it worth it? :)
This is not done for performance, but to make sure the allocation will not fail
midway during writing the dump. Maybe it is not worth it, though.
> 1655: The result of deflateBound() seems to depend on the header comment,
> which is not given
> here. Could this be an issue, because ZIP_GZip_Fully() can take a comment?
I've added a 1024 byte additional bytes to avoid the problem.
> ### test/lib/jdk/test/lib/hprof/parser/Reader.java
>
> 93: is the created GzipRandomAccess instance closed somewhere?
The object is not closed since it is still used by the Snapshot returned.
Best regard,
Ralf
-Original Message-
From: Reingruber, Richard
Sent: Tuesday, 14 April 2020 10:30
To: Schmelter, Ralf ; Ioi Lam ;
Langer, Christoph ; Yasumasa Suenaga
; serguei.spit...@oracle.com;
hotspot-runtime-...@openjdk.java.net runtime
Cc: serviceability-dev@openjdk.java.net
Subject: RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump
Hi Ralf,
thanks for providing this enhancement to parallel gzip-compress heap dumps!
I reckon it's safe to say that the coding is sophisticated. It would be awesome
if you could sketch
the idea of how HeapDumper, DumpWriter and CompressionBackend work together to
produce the gzipped
dump in a source code comment. Just enough to get started if somebody should
ever have to track down
a bug -- an unlikely event, I know ;)
Please find the details of my review below.
Thanks, Richard.
// Not Reviewer
--
### src/hotspot/share/services/diagnosticCommand.cpp
510 _gzip_level("-gz-level", "The compression level from 0 (store) to 9
(best) when writing in gzipped format.",
511 "INT", "FALSE", "1") {
"FALSE" should be probably false.
RE: RFR(L) 8237354: Add option to jcmd to write a gzipped heap dump
Hi Ralf,
thanks for providing this enhancement to parallel gzip-compress heap dumps!
I reckon it's safe to say that the coding is sophisticated. It would be awesome
if you could sketch
the idea of how HeapDumper, DumpWriter and CompressionBackend work together to
produce the gzipped
dump in a source code comment. Just enough to get started if somebody should
ever have to track down
a bug -- an unlikely event, I know ;)
Please find the details of my review below.
Thanks, Richard.
// Not Reviewer
--
### src/hotspot/share/services/diagnosticCommand.cpp
510 _gzip_level("-gz-level", "The compression level from 0 (store) to 9
(best) when writing in gzipped format.",
511 "INT", "FALSE", "1") {
"FALSE" should be probably false.
### src/hotspot/share/services/diagnosticCommand.hpp
Ok.
### src/hotspot/share/services/heapDumper.cpp
390: Typo: initized
415: Typo: GZipComressor
477: Could you please add a comment, how the "HPROF BLOCKSIZE" comment is
helpful?
539: Member variables of WriteWork are missing the '_' prefix.
546: Just a comment: WriteWork::in_max is actually a compile time constant.
Would be nice if it could be
declared so. One could use templates for this, but then my favourite ide
(eclipse cdt) doesn't
show me references and call hierarchies anymore. So I don't think it is
worth it.
591: Typo: Removes the first element. Returns NULL is empty.
663: _writer, _compressor, _lock could be const.
762: assert(_active, "Must be active");
It appears to me that the assertion would fail, if an error occurred
creating the CompressionBackend.
767: I think _current->in_used doesn't take the final 9 bytes into account that
are written in
DumperSupport::end_of_dump() after the last dump segment has been finished.
You could call get_new_buffer() instead of the if clause.
903: Typo: Check if we don not waste more than _max_waste
1064: DumpWriter::DumpWriter()
There doesn't seem to be enough error handling if _buffer cannot be
allocated.
E.g. DumpWriter::write_raw() at line 1091 will enter an endless loop.
2409: A comment, why Shenandoah is not supported, would be good.
In general I'd say it is good and natural to use the GC work threads.
### src/hotspot/share/services/heapDumper.hpp
Ok.
### src/java.base/share/native/libzip/zip_util.c
I'm not familiar with zlib, but here are my .02€ :)
1610: Will be hard to beat zlib_block_alloc() and zlib_block_free() performance
wise. But have you
measured the performance gain? In other words: is it worth it? :)
1655: The result of deflateBound() seems to depend on the header comment, which
is not given
here. Could this be an issue, because ZIP_GZip_Fully() can take a comment?
1658: deflateEnd() should not be called if deflateInit2Wrapper() failed. I
think this can lead
otherwise to a double free() call.
### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java
66: Maybe additionally check the exit value?
73: It's unclear to me, why this fails. Because the dump already exists?
Because the level is
invalid? Reading the comment I'd expect success, not failure.
### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestEpsilon.java
Ok.
###
test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestShenandoah.java
Ok.
### test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTestZ.java
Ok.
### test/lib/jdk/test/lib/hprof/parser/GzipRandomAccess.java
Ok.
### test/lib/jdk/test/lib/hprof/parser/HprofReader.java
Ok.
### test/lib/jdk/test/lib/hprof/parser/Reader.java
93: is the created GzipRandomAccess instance closed somewhere?
-Original Message-
From: serviceability-dev On
Behalf Of Schmelter, Ralf
Sent: Freitag, 13. März 2020 12:43
To: Ioi Lam ; Langer, Christoph ;
Yasumasa Suenaga ; serguei.spit...@oracle.com;
hotspot-runtime-...@openjdk.java.net runtime
Cc: serviceability-dev@openjdk.java.net
Subject: [CAUTION] RE: RFR(L) 8237354: Add option to jcmd to write a gzipped
heap dump
Hi,
I have updated the webrev:
http://cr.openjdk.java.net/~rschmelter/webrevs/8237354/webrev.1/
It has the following significant changes:
- The jcmd now uses two separate flags. The -gz flag is now a boolean flag
which toggles the compression on/off. And the new -gz-level flag can be used
to change the compression level. If tried to change the jlong flag coding to
allow the old behavior (only one flag, which acts both as a boolean flag and a
jlong flag), but decided against it, since it changes the semantic of a jlong
flag. And I don't expect the -gz-level flag to be used all that much.
- I no longer use my own threads. Instead I use the WorkGang returned from
CollectedHeap:: get_safepoint_workers(). This works fine, apart from Shenandoah
GC, which runs into assertions when calling the CollectedHeap::object_iterate()
method from a worker thread. I'm not sure if the assertion is too strong, but
since the GC is curr
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
> Thanks for cleaning up thread.hpp!
Thanks for providing the feedback!
I justed noticed that the forward declaration of class
jvmtiDeferredLocalVariableSet is not required anymore. Will remove it in the
next webrev. Hope to get some more (partial) reviews.
Thanks, Richard.
-Original Message-
From: Robbin Ehn
Sent: Dienstag, 31. März 2020 16:21
To: Reingruber, Richard ; Doerr, Martin
; Lindenmaier, Goetz ; David
Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com)
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Thanks for cleaning up thread.hpp!
/Robbin
On 2020-03-30 10:31, Reingruber, Richard wrote:
> Hi,
>
> this is webrev.5 based on Robbin's feedback and Martin's review - thanks! :)
>
> The change affects jvmti, hotspot and c2. Partial reviews are very welcome
> too.
>
> Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5/
> Delta: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5.inc/
>
> Robbin, Martin, please let me know, if anything shouldn't be quite as you
> wanted it. Also find my
> comments on your feedback below.
>
> Robbin, can I count you as Reviewer for the runtime part?
>
> Thanks, Richard.
>
> --
>
>> DeoptimizeObjectsALotThread is only used in compileBroker.cpp.
>> You can move both declaration and definition to that file, no need to clobber
>> thread.[c|h]pp. (and the static function deopt_objs_alot_thread_entry)
>
> Done.
>
>> Does JvmtiDeferredUpdates really need to be in thread.hpp, can't be in it's
>> own
>> hpp file? It doesn't seem right to add JVM TI classes into thread.hpp.
>
> I moved JvmtiDeferredUpdates to vframe_hp.hpp where preexisting
> jvmtiDeferredLocalVariableSet is
> declared.
>
>> src/hotspot/share/code/compiledMethod.cpp
>> Nice cleanup!
>
> Thanks :)
>
>> src/hotspot/share/code/debugInfoRec.cpp
>> src/hotspot/share/code/debugInfoRec.hpp
>> Additional parmeters. (Remark: I think "non_global_escape_in_scope" would
>> read better than "not_global_escape_in_scope", but your version is
>> consistent with existing code, so no change request from my side.) Ok.
>
> I've been thinking about this too and finally stayed with
> not_global_escape_in_scope. It's supposed
> to mean an object whose escape state is not GlobalEscape is in scope.
>
>> src/hotspot/share/compiler/compileBroker.cpp
>> src/hotspot/share/compiler/compileBroker.hpp
>> Extra thread for DeoptimizeObjectsALot. (Remark: I would have put it into a
>> follow up change together with the test in order to make this webrev
>> smaller, but since it is included, I'm reviewing everything at once. Not a
>> big deal.) Ok.
>
> Yes the change would be a little smaller. And if it helps I'll split it off.
> In general I prefer
> patches that bring along a suitable amount of tests.
>
>> src/hotspot/share/opto/c2compiler.cpp
>> Make do_escape_analysis independent of JVMCI capabilities. Nice!
>
> It is the main goal of the enhancement. It is done for C2, but could be done
> for JVMCI compilers
> with just a small effort as well.
>
>> src/hotspot/share/opto/escape.cpp
>> Annotation for MachSafePointNodes. Your added functionality looks correct.
>> But I'd prefer to move the bulky code out of the large function.
>> I suggest to factor out something like has_not_global_escape and
>> has_arg_escape. So the code could look like this:
>>SafePointNode* sfn = sfn_worklist.at(next);
>>sfn->set_not_global_escape_in_scope(has_not_global_escape(sfn));
>>if (sfn->is_CallJava()) {
>> CallJavaNode* call = sfn->as_CallJava();
>> call->set_arg_escape(has_arg_escape(call));
>>}
>> This would also allow us to get rid of the found_..._escape_in_args
>> variables making the loops better readable.
>
> Done.
>
>> It's kind of ugly to use strcmp to recognize uncommon trap, but that seems
>> to be the way to do it (there are more such places). So it's ok.
>
> Yeah. I copied the snippet.
>
>> src/hotspot/share/prims/jvmtiImpl.cpp
>> src/hotspot/share/prims/jvmtiImpl.hpp
>> The sequence is pretty complex:
>> VM_GetOrSetLocal element initialization executes EscapeBarrier code which
>> suspends the target thread (extra VM Operation).
>
> Note that the target threads have to be suspended already for
> VM_GetOrSetLocal*. So it's mai
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Martin, > thanks for addressing all my points. I've looked over webrev.5 and I'm > satisfied with your changes. Thanks! > I had also promised to review the tests. Thanks++ I appreciate it very much, the tests are many lines of code. > test/jdk/com/sun/jdi/EATests.java > This is a substantial amount of tests which is appropriate for a such a large > change. Skipping some subtests with UseJVMCICompiler makes sense because it > doesn't provide the necessary JVMTI functionality, yet. > Nice work! > I also like that you test with and without BiasedLocking. Your tests will > still be fine after BiasedLocking deprecation. Hope so :) > Very minor nits: > - 2 typos in comment above EARelockingNestedInflatedTarget: "lockes are > ommitted" (sounds funny) > - You sometimes write "graal" and sometimes "Graal". I guess the capital G is > better. (Also in EATestsJVMCI.java.) > test/jdk/com/sun/jdi/EATestsJVMCI.java > EATests with Graal enabled. Nice that you support Graal to some extent. Maybe > Graal folks want to enhance them in the future. I think this is a good > starting point. Will change this in the next webrev. > Conclusion: Looks good and not trivial :-) > Now, you have one full review. I'd be ok with covering 2nd review by partial > reviews. > Compiler and JVMTI parts are not too complicated IMHO. > Runtime part should get at least one additional careful review. Thanks a lot, Richard. -Original Message- From: Doerr, Martin Sent: Dienstag, 31. März 2020 16:01 To: Reingruber, Richard ; 'Robbin Ehn' ; Lindenmaier, Goetz ; David Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com) ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, thanks for addressing all my points. I've looked over webrev.5 and I'm satisfied with your changes. I had also promised to review the tests. test/hotspot/jtreg/serviceability/jvmti/Heap/IterateHeapWithEscapeAnalysisEnabled.java Thanks for updating the @summary comment. Looks good in webrev.5. test/hotspot/jtreg/serviceability/jvmti/Heap/libIterateHeapWithEscapeAnalysisEnabled.c JVMTI agent for object tagging and heap iteration. Good. test/jdk/com/sun/jdi/EATests.java This is a substantial amount of tests which is appropriate for a such a large change. Skipping some subtests with UseJVMCICompiler makes sense because it doesn't provide the necessary JVMTI functionality, yet. Nice work! I also like that you test with and without BiasedLocking. Your tests will still be fine after BiasedLocking deprecation. Very minor nits: - 2 typos in comment above EARelockingNestedInflatedTarget: "lockes are ommitted" (sounds funny) - You sometimes write "graal" and sometimes "Graal". I guess the capital G is better. (Also in EATestsJVMCI.java.) test/jdk/com/sun/jdi/EATestsJVMCI.java EATests with Graal enabled. Nice that you support Graal to some extent. Maybe Graal folks want to enhance them in the future. I think this is a good starting point. Conclusion: Looks good and not trivial :-) Now, you have one full review. I'd be ok with covering 2nd review by partial reviews. Compiler and JVMTI parts are not too complicated IMHO. Runtime part should get at least one additional careful review. Best regards, Martin > -Original Message- > From: Reingruber, Richard > Sent: Montag, 30. März 2020 10:32 > To: Doerr, Martin ; 'Robbin Ehn' > ; Lindenmaier, Goetz > ; David Holmes ; > Vladimir Kozlov (vladimir.koz...@oracle.com) > ; serviceability-dev@openjdk.java.net; > hotspot-compiler-...@openjdk.java.net; hotspot-runtime- > d...@openjdk.java.net > Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance > in the Presence of JVMTI Agents > > Hi, > > this is webrev.5 based on Robbin's feedback and Martin's review - thanks! :) > > The change affects jvmti, hotspot and c2. Partial reviews are very welcome > too. > > Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5/ > Delta: > http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5.inc/ > > Robbin, Martin, please let me know, if anything shouldn't be quite as you > wanted it. Also find my > comments on your feedback below. > > Robbin, can I count you as Reviewer for the runtime part? > > Thanks, Richard. > > -- > > > DeoptimizeObjectsALotThread is only used in compileBroker.cpp. > > You can move both declaration and definition to that file, no need to > clobber > > thread.[c|h]pp. (and the static function deopt_objs_alot_thre
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
deoptimize_objects functions makes it a little hard to > keep an overview of which one is used for what. > Maybe adding suffixes would help a little bit, but I can also live with what > you have. > Implementation looks correct to me. 2 are internal. I added the suffix _internal to them. This leaves 2 to choose from. > src/hotspot/share/runtime/deoptimization.hpp > Escape barriers and object deoptimization functions. > Typo in comment: "helt" => "held" Done in place already. > src/hotspot/share/runtime/interfaceSupport.cpp > InterfaceSupport::deoptimizeAllObjects() is only used for > DeoptimizeObjectsALot = 1. > I think DeoptimizeObjectsALot = 2 is more important, but I think it's not bad > to have DeoptimizeObjectsALot = 1 in addition. Ok. I never used DeoptimizeObjectsALot = 1 that much. It could be more deterministic in single threaded scenarios. I wouldn't object to get rid of it though. > src/hotspot/share/runtime/stackValue.hpp > Better reinitilization in StackValue. Good. StackValue::obj_is_scalar_replaced() should not return true after calling set_obj(). > src/hotspot/share/runtime/thread.cpp > src/hotspot/share/runtime/thread.hpp > src/hotspot/share/runtime/thread.inline.hpp > wait_for_object_deoptimization, suspend flag, deferred updates and test > feature to deoptimize objects. > In the long term, we want to get rid of suspend flags, so it's not so nice to > introduce a new one. But I agree with Götz that it should be acceptable as > temporary solution until async handshakes are available (which takes more > time). So I'm ok with your change. I'm keen to build the feature on async handshakes when the arive. > You can use MutexLocker with Thread*. Done. > JVMTIDeferredUpdates: I agree with Robin. It'd be nice to move the class out > of thread.hpp. Done. > src/hotspot/share/runtime/vframe.cpp > Added support for entry frame to new_vframe. Ok. > src/hotspot/share/runtime/vframe_hp.cpp > src/hotspot/share/runtime/vframe_hp.hpp > I think code()->as_nmethod() in not_global_escape_in_scope() and arg_escape() > should better be under #ifdef ASSERT or inside the assert statement (no need > for code cache walking in product build). Done. > jvmtiDeferredLocalVariableSet::update_monitors: > Please add a comment explaining that owner referenced by original info may be > scalar replaced, but it is deoptimized in the vframe. Done. -Original Message- From: Doerr, Martin Sent: Donnerstag, 12. März 2020 17:28 To: Reingruber, Richard ; 'Robbin Ehn' ; Lindenmaier, Goetz ; David Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com) ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, I managed to find time for a (almost) complete review of webrev.4. (I'll review the tests separately.) First of all, the change seems to be in pretty good quality for its significant complexity. I couldn't find any real bugs. But I'd like to propose minor improvements. I'm convinced that it's mature because we did substantial testing. I like the new functionality for object deoptimization. It can possibly be reused for future escape analysis based optimizations. So I appreciate having it available in the code base. In addition to that, your change makes the JVMTI implementation better integrated into the VM. Now to the details: src/hotspot/share/c1/c1_IR.hpp describe_scope parameters. Ok. src/hotspot/share/ci/ciEnv.cpp src/hotspot/share/ci/ciEnv.hpp Fix for JvmtiExport::can_walk_any_space() capability. Ok. src/hotspot/share/code/compiledMethod.cpp Nice cleanup! src/hotspot/share/code/debugInfoRec.cpp src/hotspot/share/code/debugInfoRec.hpp Additional parmeters. (Remark: I think "non_global_escape_in_scope" would read better than "not_global_escape_in_scope", but your version is consistent with existing code, so no change request from my side.) Ok. src/hotspot/share/code/nmethod.cpp Nice cleanup! src/hotspot/share/code/pcDesc.hpp Additional parameters. Ok. src/hotspot/share/code/scopeDesc.cpp src/hotspot/share/code/scopeDesc.hpp Improved implementation + additional parameters. Ok. src/hotspot/share/compiler/compileBroker.cpp src/hotspot/share/compiler/compileBroker.hpp Extra thread for DeoptimizeObjectsALot. (Remark: I would have put it into a follow up change together with the test in order to make this webrev smaller, but since it is included, I'm reviewing everything at once. Not a big deal.) Ok. src/hotspot/share/jvmci/jvmciCodeInstaller.cpp Additional parameters. Ok. src/hotspot/share/opto/c2compiler.cpp Make do_escape_analysis independent of JVMCI c
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi,
this is webrev.5 based on Robbin's feedback and Martin's review - thanks! :)
The change affects jvmti, hotspot and c2. Partial reviews are very welcome too.
Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5/
Delta: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.5.inc/
Robbin, Martin, please let me know, if anything shouldn't be quite as you
wanted it. Also find my
comments on your feedback below.
Robbin, can I count you as Reviewer for the runtime part?
Thanks, Richard.
-Original Message-
From: Doerr, Martin
Sent: Donnerstag, 12. März 2020 17:28
To: Reingruber, Richard ; 'Robbin Ehn'
; Lindenmaier, Goetz ; David
Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com)
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi Richard,
I managed to find time for a (almost) complete review of webrev.4. (I'll review
the tests separately.)
First of all, the change seems to be in pretty good quality for its significant
complexity. I couldn't find any real bugs. But I'd like to propose minor
improvements.
I'm convinced that it's mature because we did substantial testing.
I like the new functionality for object deoptimization. It can possibly be
reused for future escape analysis based optimizations. So I appreciate having
it available in the code base.
In addition to that, your change makes the JVMTI implementation better
integrated into the VM.
Now to the details:
src/hotspot/share/c1/c1_IR.hpp
describe_scope parameters. Ok.
src/hotspot/share/ci/ciEnv.cpp
src/hotspot/share/ci/ciEnv.hpp
Fix for JvmtiExport::can_walk_any_space() capability. Ok.
src/hotspot/share/code/compiledMethod.cpp
Nice cleanup!
src/hotspot/share/code/debugInfoRec.cpp
src/hotspot/share/code/debugInfoRec.hpp
Additional parmeters. (Remark: I think "non_global_escape_in_scope" would read
better than "not_global_escape_in_scope", but your version is consistent with
existing code, so no change request from my side.) Ok.
src/hotspot/share/code/nmethod.cpp
Nice cleanup!
src/hotspot/share/code/pcDesc.hpp
Additional parameters. Ok.
src/hotspot/share/code/scopeDesc.cpp
src/hotspot/share/code/scopeDesc.hpp
Improved implementation + additional parameters. Ok.
src/hotspot/share/compiler/compileBroker.cpp
src/hotspot/share/compiler/compileBroker.hpp
Extra thread for DeoptimizeObjectsALot. (Remark: I would have put it into a
follow up change together with the test in order to make this webrev smaller,
but since it is included, I'm reviewing everything at once. Not a big deal.) Ok.
src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
Additional parameters. Ok.
src/hotspot/share/opto/c2compiler.cpp
Make do_escape_analysis independent of JVMCI capabilities. Nice!
src/hotspot/share/opto/callnode.hpp
Additional fields for MachSafePointNodes. Ok.
src/hotspot/share/opto/escape.cpp
Annotation for MachSafePointNodes. Your added functionality looks correct.
But I'd prefer to move the bulky code out of the large function.
I suggest to factor out something like has_not_global_escape and
has_arg_escape. So the code could look like this:
SafePointNode* sfn = sfn_worklist.at(next);
sfn->set_not_global_escape_in_scope(has_not_global_escape(sfn));
if (sfn->is_CallJava()) {
CallJavaNode* call = sfn->as_CallJava();
call->set_arg_escape(has_arg_escape(call));
}
This would also allow us to get rid of the found_..._escape_in_args variables
making the loops better readable.
It's kind of ugly to use strcmp to recognize uncommon trap, but that seems to
be the way to do it (there are more such places). So it's ok.
src/hotspot/share/opto/machnode.hpp
Additional fields for MachSafePointNodes. Ok.
src/hotspot/share/opto/macro.cpp
Allow elimination of non-escaping allocations. Ok.
src/hotspot/share/opto/matcher.cpp
src/hotspot/share/opto/output.cpp
Copy attribute / pass parameters. Ok.
src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp
Nice cleanup!
src/hotspot/share/prims/jvmtiEnv.cpp
src/hotspot/share/prims/jvmtiEnvBase.cpp
Escape barriers + deoptimize objects for target thread. Good.
src/hotspot/share/prims/jvmtiImpl.cpp
src/hotspot/share/prims/jvmtiImpl.hpp
The sequence is pretty complex:
VM_GetOrSetLocal element initialization executes EscapeBarrier code which
suspends the target thread (extra VM Operation).
VM_GetOrSetLocal::doit_prologue performs object deoptimization (by VM Thread to
prepare VM Operation with frame deoptimization).
VM_GetOrSetLocal destructor implicitly calls EscapeBarrier destructor which
resumes the target thread.
But I don't have any improvement proposal. Performance is probably not a
concern, here. So it's ok.
VM_GetOrSetLocal::deoptim
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Martin,
thanks a lot for reviewing and the feedback. I'll dig into the details as soon
as possible. Looking forward to it :)
Thanks, Richard.
-Original Message-
From: Doerr, Martin
Sent: Donnerstag, 12. März 2020 17:28
To: Reingruber, Richard ; 'Robbin Ehn'
; Lindenmaier, Goetz ; David
Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com)
; serviceability-dev@openjdk.java.net;
hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net
Subject: RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi Richard,
I managed to find time for a (almost) complete review of webrev.4. (I'll review
the tests separately.)
First of all, the change seems to be in pretty good quality for its significant
complexity. I couldn't find any real bugs. But I'd like to propose minor
improvements.
I'm convinced that it's mature because we did substantial testing.
I like the new functionality for object deoptimization. It can possibly be
reused for future escape analysis based optimizations. So I appreciate having
it available in the code base.
In addition to that, your change makes the JVMTI implementation better
integrated into the VM.
Now to the details:
src/hotspot/share/c1/c1_IR.hpp
describe_scope parameters. Ok.
src/hotspot/share/ci/ciEnv.cpp
src/hotspot/share/ci/ciEnv.hpp
Fix for JvmtiExport::can_walk_any_space() capability. Ok.
src/hotspot/share/code/compiledMethod.cpp
Nice cleanup!
src/hotspot/share/code/debugInfoRec.cpp
src/hotspot/share/code/debugInfoRec.hpp
Additional parmeters. (Remark: I think "non_global_escape_in_scope" would read
better than "not_global_escape_in_scope", but your version is consistent with
existing code, so no change request from my side.) Ok.
src/hotspot/share/code/nmethod.cpp
Nice cleanup!
src/hotspot/share/code/pcDesc.hpp
Additional parameters. Ok.
src/hotspot/share/code/scopeDesc.cpp
src/hotspot/share/code/scopeDesc.hpp
Improved implementation + additional parameters. Ok.
src/hotspot/share/compiler/compileBroker.cpp
src/hotspot/share/compiler/compileBroker.hpp
Extra thread for DeoptimizeObjectsALot. (Remark: I would have put it into a
follow up change together with the test in order to make this webrev smaller,
but since it is included, I'm reviewing everything at once. Not a big deal.) Ok.
src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
Additional parameters. Ok.
src/hotspot/share/opto/c2compiler.cpp
Make do_escape_analysis independent of JVMCI capabilities. Nice!
src/hotspot/share/opto/callnode.hpp
Additional fields for MachSafePointNodes. Ok.
src/hotspot/share/opto/escape.cpp
Annotation for MachSafePointNodes. Your added functionality looks correct.
But I'd prefer to move the bulky code out of the large function.
I suggest to factor out something like has_not_global_escape and
has_arg_escape. So the code could look like this:
SafePointNode* sfn = sfn_worklist.at(next);
sfn->set_not_global_escape_in_scope(has_not_global_escape(sfn));
if (sfn->is_CallJava()) {
CallJavaNode* call = sfn->as_CallJava();
call->set_arg_escape(has_arg_escape(call));
}
This would also allow us to get rid of the found_..._escape_in_args variables
making the loops better readable.
It's kind of ugly to use strcmp to recognize uncommon trap, but that seems to
be the way to do it (there are more such places). So it's ok.
src/hotspot/share/opto/machnode.hpp
Additional fields for MachSafePointNodes. Ok.
src/hotspot/share/opto/macro.cpp
Allow elimination of non-escaping allocations. Ok.
src/hotspot/share/opto/matcher.cpp
src/hotspot/share/opto/output.cpp
Copy attribute / pass parameters. Ok.
src/hotspot/share/prims/jvmtiCodeBlobEvents.cpp
Nice cleanup!
src/hotspot/share/prims/jvmtiEnv.cpp
src/hotspot/share/prims/jvmtiEnvBase.cpp
Escape barriers + deoptimize objects for target thread. Good.
src/hotspot/share/prims/jvmtiImpl.cpp
src/hotspot/share/prims/jvmtiImpl.hpp
The sequence is pretty complex:
VM_GetOrSetLocal element initialization executes EscapeBarrier code which
suspends the target thread (extra VM Operation).
VM_GetOrSetLocal::doit_prologue performs object deoptimization (by VM Thread to
prepare VM Operation with frame deoptimization).
VM_GetOrSetLocal destructor implicitly calls EscapeBarrier destructor which
resumes the target thread.
But I don't have any improvement proposal. Performance is probably not a
concern, here. So it's ok.
VM_GetOrSetLocal::deoptimize_objects deoptimizes the top frame if it has
non-globally escaping objects and other frames if they have arg escaping ones.
Good.
src/hotspot/share/prims/jvmtiTagMap.cpp
Escape barriers + deoptimize objects for all threads. Ok.
src/hotspot/share/prims/whitebox.cpp
Added WB_IsFrameDeoptimized to API. Ok.
src/hotspot/share/runtime/deoptimization.cpp
Object deoptimiz
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Robbin, > > I understand that Robbin proposed to replace the usage of > > _suspend_flag with handshakes. Apparently, async handshakes > > are needed to do so. We have been waiting a while for removal > > of the _suspend_flag / introduction of async handshakes [2]. > > What is the status here? > I have an old prototype which I would like to continue to work on. > So do not assume asynch handshakes will make 15. > Even if it would, I think there are a lot more investigate work to remove > _suspend_flag. Let us know, if we can be of any help to you and be it only testing. > >> Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4/ > DeoptimizeObjectsALotThread is only used in compileBroker.cpp. > You can move both declaration and definition to that file, no need to clobber > thread.[c|h]pp. (and the static function deopt_objs_alot_thread_entry) Will do. > Does JvmtiDeferredUpdates really need to be in thread.hpp, can't be in it's > own > hpp file? It doesn't seem right to add JVM TI classes into thread.hpp. You are right. It shouldn't be declared in thread.hpp. I will look into that. > Note that we also think we may have a bug in deopt: > https://bugs.openjdk.java.net/browse/JDK-8238237 > I think it would be best, if possible, to push after that is resolved. Sure. > Not even nearly a full review :) I know :) Anyways, thanks a lot, Richard. -Original Message- From: Robbin Ehn Sent: Monday, March 2, 2020 11:17 AM To: Lindenmaier, Goetz ; Reingruber, Richard ; David Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com) ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi, On 2/24/20 5:39 PM, Lindenmaier, Goetz wrote: > Hi, > > I had a look at the progress of this change. Nothing > happened since Richard posted his update using more > handshakes [1]. > But we (SAP) would appreciate a lot if this change could > be successfully reviewed and pushed. > > I think there is basic understanding that this > change is helpful. It fixes a number of issues with JVMTI, > and will deliver the same performance benefits as EA > does in current production mode for debugging scenarios. > > This is important for us as we run our VMs prepared > for debugging in production mode. > > I understand that Robbin proposed to replace the usage of > _suspend_flag with handshakes. Apparently, async handshakes > are needed to do so. We have been waiting a while for removal > of the _suspend_flag / introduction of async handshakes [2]. > What is the status here? I have an old prototype which I would like to continue to work on. So do not assume asynch handshakes will make 15. Even if it would, I think there are a lot more investigate work to remove _suspend_flag. > > I think we should no longer wait, but proceed with > this change. We will look into removing the usage of > suspend_flag introduced here once it is possible to implement > it with handshakes. Yes, sure. >> Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4/ DeoptimizeObjectsALotThread is only used in compileBroker.cpp. You can move both declaration and definition to that file, no need to clobber thread.[c|h]pp. (and the static function deopt_objs_alot_thread_entry) Does JvmtiDeferredUpdates really need to be in thread.hpp, can't be in it's own hpp file? It doesn't seem right to add JVM TI classes into thread.hpp. Note that we also think we may have a bug in deopt: https://bugs.openjdk.java.net/browse/JDK-8238237 I think it would be best, if possible, to push after that is resolved. Not even nearly a full review :) Thanks, Robbin >> Incremental: >> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4.inc/ >> >> I was not able to eliminate the additional suspend flag now. I'll take care >> of this >> as soon as the >> existing suspend-resume-mechanism is reworked. >> >> Testing: >> >> Nightly tests @SAP: >> >>JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance >> Suite, SAP specific tests >>with fastdebug and release builds on all platforms >> >>Stress testing with DeoptimizeObjectsALot running SPECjvm2008 40x parallel >> for 24h >> >> Thanks, Richard. >> >> >> More details on the changes: >> >> * Hide DeoptimizeObjectsALotThread from external view. >> >> * Changed EscapeBarrier_lock to be a _safepoint_check_never lock. >>It used to be _safepoint_check_sometimes, which will be eliminated sooner >> or >
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Ping :) Richard. -Original Message- From: hotspot-compiler-dev On Behalf Of Reingruber, Richard Sent: Dienstag, 4. Februar 2020 09:59 To: David Holmes ; Vladimir Kozlov (vladimir.koz...@oracle.com) ; Robbin Ehn ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: [CAUTION] RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi, I have prepared webrev.4 that incorporates feedback from webrev.3 (thanks!) Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4/ Incremental: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4.inc/ I was not able to eliminate the additional suspend flag now. I'll take care of this as soon as the existing suspend-resume-mechanism is reworked. Testing: Nightly tests @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Stress testing with DeoptimizeObjectsALot running SPECjvm2008 40x parallel for 24h Thanks, Richard. More details on the changes: * Hide DeoptimizeObjectsALotThread from external view. * Changed EscapeBarrier_lock to be a _safepoint_check_never lock. It used to be _safepoint_check_sometimes, which will be eliminated sooner or later. I added explicit thread state changes with ThreadBlockInVM to code paths where we can wait() on EscapeBarrier_lock to become safepoint safe. * Use handshake EscapeBarrierSuspendHandshake to suspend target threads instead of vm operation VM_ThreadSuspendAllForObjDeopt. * Removed uses of Threads_lock. When adding a new thread we suspend it iff EA optimizations are being reverted. In the previous version we were waiting on Threads_lock while EA optimizations were reverted. See EscapeBarrier::thread_added(). * Made tests require Xmixed compilation mode. * Made tests agnostic regarding tiered compilation. I.e. tc isn't disabled anymore, and the tests can be run with tc enabled or disabled. * Exercising EATests.java as well with stress test options DeoptimizeObjectsALot* Due to the non-deterministic deoptimizations some tests need to be skipped. We do this to prevent bit-rot of the stress test code. * Executing EATests.java as well with graal if available. Driver for this is EATestsJVMCI.java. Graal cannot pass all tests, because it does not provide all the new debug info (namely not_global_escape_in_scope and arg_escape in scopeDesc.hpp). And graal does not yet support the JVMTI operations force early return and pop frame. * Removed tracing from new jdi tests in EATests.java. Too much trace output before the debugging connection is established can cause deadlock because output buffers fill up. (See https://bugs.openjdk.java.net/browse/JDK-8173304) * Many copyright year changes and smaller clean-up changes of testing code (trailing white-space and the like). -Original Message- From: David Holmes Sent: Donnerstag, 19. Dezember 2019 03:12 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net; Vladimir Kozlov (vladimir.koz...@oracle.com) Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, I think my issue is with the way EliminateNestedLocks works so I'm going to look into that more deeply. Thanks for the explanations. David On 18/12/2019 12:47 am, Reingruber, Richard wrote: > Hi David, > >> >> Some further queries/concerns: >> >> >> >> src/hotspot/share/runtime/objectMonitor.cpp >> >> >> >> Can you please explain the changes to ObjectMonitor::wait: >> >> >> >> ! _recursions = save // restore the old recursion count >> >> ! + jt->get_and_reset_relock_count_after_wait(); > // >> >> increased by the deferred relock count >> >> >> >> what is the "deferred relock count"? I gather it relates to >> >> >> >> "The code was extended to be able to deoptimize objects of a >> > frame that >> >> is not the top frame and to let another thread than the owning >> > thread do >> >> it." >> > >> > Yes, these relate. Currently EA based optimizations are reverted, when > a compiled frame is >> > replaced with corresponding interpreter frames. Part of this is > relocking objects with eliminated >> > locking. New with the enhancement is that we do this also just before > object references are >> > acqui
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Patricio,
> > I'm really glad you noticed the problematic nesting. This seems to be a
general issue: currently a
> > handshake cannot be nested in a vm operation. Maybe it should be asserted
in the
> > Handshake::execute() methods that they are not called by the vm thread
evaluating a vm operation?
> >
> >> Alternatively I think you could do something similar to what we do in
> >> Deoptimization::deoptimize_all_marked():
> >>
> >>EnterInterpOnlyModeClosure hs;
> >>if (SafepointSynchronize::is_at_safepoint()) {
> >> hs.do_thread(state->get_thread());
> >>} else {
> >> Handshake::execute(&hs, state->get_thread());
> >>}
> >> (you could pass “EnterInterpOnlyModeClosure” directly to the
> >> HandshakeClosure() constructor)
> >
> > Maybe this could be used also in the Handshake::execute() methods as
general solution?
> Right, we could also do that. Avoiding to clear the polling page in
> HandshakeState::clear_handshake() should be enough to fix this issue and
> execute a handshake inside a safepoint, but adding that "if" statement
> in Hanshake::execute() sounds good to avoid all the extra code that we
> go through when executing a handshake. I filed 8239084 to make that change.
Thanks for taking care of this and creating the RFE.
>
> >> I don’t know JVMTI code so I’m not sure if VM_EnterInterpOnlyMode is
> >> always called in a nested operation or just sometimes.
> >
> > At least one execution path without vm operation exists:
> >
> >JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState
*) : void
> >
JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) :
jlong
> >JvmtiEventControllerPrivate::recompute_enabled() : void
> > JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent,
bool) : void (2 matches)
> >JvmtiEventController::change_field_watch(jvmtiEvent, bool) :
void
> > JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError
> >jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) :
jvmtiError
> >
> > I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main
intent to replace it with a
> > handshake, but to avoid making the compiled methods on stack
not_entrant unless I'm further
> > encouraged to do it with a handshake :)
> Ah! I think you can still do it with a handshake with the
> Deoptimization::deoptimize_all_marked() like solution. I can change the
> if-else statement with just the Handshake::execute() call in 8239084.
> But up to you. : )
Well, I think that's enough encouragement :)
I'll wait for 8239084 and try then again.
(no urgency and all)
Thanks,
Richard.
-Original Message-
From: Patricio Chilano
Sent: Freitag, 14. Februar 2020 15:54
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-...@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 2/14/20 9:58 AM, Reingruber, Richard wrote:
> Hi Patricio,
>
> thanks for having a look.
>
>> I’m only commenting on the handshake changes.
>> I see that operation VM_EnterInterpOnlyMode can be called inside
>> operation VM_SetFramePop which also allows nested operations. Here is a
>> comment in VM_SetFramePop definition:
>>
>> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that
> is
>> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled.
>>
>> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we
>> could have a handshake inside a safepoint operation. The issue I see
>> there is that at the end of the handshake the polling page of the target
>> thread could be disarmed. So if the target thread happens to be in a
>> blocked state just transiently and wakes up then it will not stop for
>> the ongoing safepoint. Maybe I can file an RFE to assert that the
>> polling page is armed at the beginning of disarm_safepoint().
>
> I'm really glad you noticed the problematic nesting. This seems to be a
> general issue: currently a
> handshake cannot be nested in a vm operation. Maybe it should be asserted in
> the
> Handsha
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Patricio,
thanks for having a look.
> I’m only commenting on the handshake changes.
> I see that operation VM_EnterInterpOnlyMode can be called inside
> operation VM_SetFramePop which also allows nested operations. Here is a
> comment in VM_SetFramePop definition:
>
> // Nested operation must be allowed for the VM_EnterInterpOnlyMode that is
> // called from the JvmtiEventControllerPrivate::recompute_thread_enabled.
>
> So if we change VM_EnterInterpOnlyMode to be a handshake, then now we
> could have a handshake inside a safepoint operation. The issue I see
> there is that at the end of the handshake the polling page of the target
> thread could be disarmed. So if the target thread happens to be in a
> blocked state just transiently and wakes up then it will not stop for
> the ongoing safepoint. Maybe I can file an RFE to assert that the
> polling page is armed at the beginning of disarm_safepoint().
I'm really glad you noticed the problematic nesting. This seems to be a general
issue: currently a
handshake cannot be nested in a vm operation. Maybe it should be asserted in the
Handshake::execute() methods that they are not called by the vm thread
evaluating a vm operation?
> Alternatively I think you could do something similar to what we do in
> Deoptimization::deoptimize_all_marked():
>
>EnterInterpOnlyModeClosure hs;
>if (SafepointSynchronize::is_at_safepoint()) {
> hs.do_thread(state->get_thread());
>} else {
> Handshake::execute(&hs, state->get_thread());
>}
> (you could pass “EnterInterpOnlyModeClosure” directly to the
> HandshakeClosure() constructor)
Maybe this could be used also in the Handshake::execute() methods as general
solution?
> I don’t know JVMTI code so I’m not sure if VM_EnterInterpOnlyMode is
> always called in a nested operation or just sometimes.
At least one execution path without vm operation exists:
JvmtiEventControllerPrivate::enter_interp_only_mode(JvmtiThreadState *) : void
JvmtiEventControllerPrivate::recompute_thread_enabled(JvmtiThreadState *) :
jlong
JvmtiEventControllerPrivate::recompute_enabled() : void
JvmtiEventControllerPrivate::change_field_watch(jvmtiEvent, bool) :
void (2 matches)
JvmtiEventController::change_field_watch(jvmtiEvent, bool) : void
JvmtiEnv::SetFieldAccessWatch(fieldDescriptor *) : jvmtiError
jvmti_SetFieldAccessWatch(jvmtiEnv *, jclass, jfieldID) :
jvmtiError
I tend to revert back to VM_EnterInterpOnlyMode as it wasn't my main intent to
replace it with a
handshake, but to avoid making the compiled methods on stack not_entrant
unless I'm further
encouraged to do it with a handshake :)
Thanks again,
Richard.
-Original Message-
From: Patricio Chilano
Sent: Donnerstag, 13. Februar 2020 18:47
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-...@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,
I’m only commenting on the handshake changes.
I see that operation VM_EnterInterpOnlyMode can be called inside
operation VM_SetFramePop which also allows nested operations. Here is a
comment in VM_SetFramePop definition:
// Nested operation must be allowed for the VM_EnterInterpOnlyMode that is
// called from the JvmtiEventControllerPrivate::recompute_thread_enabled.
So if we change VM_EnterInterpOnlyMode to be a handshake, then now we
could have a handshake inside a safepoint operation. The issue I see
there is that at the end of the handshake the polling page of the target
thread could be disarmed. So if the target thread happens to be in a
blocked state just transiently and wakes up then it will not stop for
the ongoing safepoint. Maybe I can file an RFE to assert that the
polling page is armed at the beginning of disarm_safepoint().
I think one option could be to remove
SafepointMechanism::disarm_if_needed() in
HandshakeState::clear_handshake() and let each JavaThread disarm itself
for the handshake case.
Alternatively I think you could do something similar to what we do in
Deoptimization::deoptimize_all_marked():
EnterInterpOnlyModeClosure hs;
if (SafepointSynchronize::is_at_safepoint()) {
hs.do_thread(state->get_thread());
} else {
Handshake::execute(&hs, state->get_thread());
}
(you could pass “EnterInterpOnlyModeClosure” directly to the
HandshakeClosure() constructor)
I don’t know JVMTI code so I’m not sure if VM_EnterInterpOnlyMode is
always called in a nested operation or just sometimes.
Thanks,
Patricio
On 2/12/20 7:23 AM, Reingruber, R
RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
// Repost including hotspot runtime and gc lists. // Dean Long suggested to do so, because the enhancement replaces a vm operation // with a handshake. // Original thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2020-February/030359.html Hi, could I please get reviews for this small enhancement in hotspot's jvmti implementation: Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ 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
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Ok. I will repost and include hotspot runtime and gc lists. Thanks, Richard. -Original Message- From: Dean Long Sent: Dienstag, 11. Februar 2020 18:28 To: Reingruber, Richard ; 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 You might want to have some runtime/GC folks look at the handshake changes. dl On 2/6/20 4:39 AM, Reingruber, Richard wrote: > Hi, > > could I please get reviews for this small enhancement: > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ > 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
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Serguei,
> Two reviews has to be good enough unless anyone else did not want to
> review it as well.
> I guess, it is good to push.
Ok. I'll wait a little longer and on Thursday I'll push it.
Thanks, Richard.
-Original Message-
From: serguei.spit...@oracle.com
Sent: Montag, 10. Februar 2020 19:11
To: Reingruber, Richard ; Vladimir Ivanov
; 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
Hi Richard,
Thank you for the details on testing!
Two reviews has to be good enough unless anyone else did not want to
review it as well.
I guess, it is good to push.
Thanks,
Serguei
On 2/10/20 03:26, Reingruber, Richard wrote:
> Hi Vladimir and Serguei,
>
> thanks for looking at the change!
>
>> What exact tests do you run to verify the fix?
>
> The enhancement was tested running the JCK and JTREG tests which include many
> JVMTI, JDI and JDWP tests.
>
> To see if the tests cover this part of the JVMTI implementation I had removed
> the deoptimization of
> compiled frames on stack. I found that e.g. the following test covers this:
>
>vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t012
>
> The test
>
>vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.java
>
> triggers the guarantee
>
> 238 void JvmtiThreadState::invalidate_cur_stack_depth() {
> 239 guarantee(SafepointSynchronize::is_at_safepoint() ||
> 240 (JavaThread *)Thread::current() == get_thread(),
> 241 "must be current thread or at safepoint");
> 242
> 243 _cur_stack_depth = UNKNOWN_STACK_DEPTH;
> 244 }
> 245
>
> because with the enhancement invalidate_cur_stack_depth() gets called by the
> VMThread executing the
> new handshake. So this is covered as well.
>
> Thanks again for reviewing.
>
> Do I need more reviews or are your reviews enough to push the enhancement?
>
> Best regards,
> Richard.
>
> -Original Message-
> From: serguei.spit...@oracle.com
> Sent: Freitag, 7. Februar 2020 19:06
> To: Reingruber, Richard ;
> 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
>
> Hi Richard,
>
> It looks good to me.
> I can't comment on compiled methods non-entrancy.
>
> What exact tests do you run to verify the fix?
>
> Thanks,
> Serguei
>
>
> On 2/6/20 04:39, Reingruber, Richard wrote:
>> Hi,
>>
>> could I please get reviews for this small enhancement:
>>
>> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
>> 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
RE: RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi Vladimir and Serguei,
thanks for looking at the change!
> What exact tests do you run to verify the fix?
The enhancement was tested running the JCK and JTREG tests which include many
JVMTI, JDI and JDWP tests.
To see if the tests cover this part of the JVMTI implementation I had removed
the deoptimization of
compiled frames on stack. I found that e.g. the following test covers this:
vmTestbase/nsk/jvmti/scenarios/events/EM02/em02t012
The test
vmTestbase/nsk/jvmti/scenarios/hotswap/HS202/hs202t002/hs202t002.java
triggers the guarantee
238 void JvmtiThreadState::invalidate_cur_stack_depth() {
239 guarantee(SafepointSynchronize::is_at_safepoint() ||
240 (JavaThread *)Thread::current() == get_thread(),
241 "must be current thread or at safepoint");
242
243 _cur_stack_depth = UNKNOWN_STACK_DEPTH;
244 }
245
because with the enhancement invalidate_cur_stack_depth() gets called by the
VMThread executing the
new handshake. So this is covered as well.
Thanks again for reviewing.
Do I need more reviews or are your reviews enough to push the enhancement?
Best regards,
Richard.
-Original Message-
From: serguei.spit...@oracle.com
Sent: Freitag, 7. Februar 2020 19:06
To: Reingruber, Richard ;
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
Hi Richard,
It looks good to me.
I can't comment on compiled methods non-entrancy.
What exact tests do you run to verify the fix?
Thanks,
Serguei
On 2/6/20 04:39, Reingruber, Richard wrote:
> Hi,
>
> could I please get reviews for this small enhancement:
>
> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/
> 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
RFR(S) 8238585: Use handshake for JvmtiEventControllerPrivate::enter_interp_only_mode() and don't make compiled methods on stack not_entrant
Hi, could I please get reviews for this small enhancement: Webrev: http://cr.openjdk.java.net/~rrich/webrevs/8238585/webrev.0/ 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
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi, I have prepared webrev.4 that incorporates feedback from webrev.3 (thanks!) Full: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4/ Incremental: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.4.inc/ I was not able to eliminate the additional suspend flag now. I'll take care of this as soon as the existing suspend-resume-mechanism is reworked. Testing: Nightly tests @SAP: JCK and JTREG, also in Xcomp mode, SPECjvm2008, SPECjbb2015, Renaissance Suite, SAP specific tests with fastdebug and release builds on all platforms Stress testing with DeoptimizeObjectsALot running SPECjvm2008 40x parallel for 24h Thanks, Richard. More details on the changes: * Hide DeoptimizeObjectsALotThread from external view. * Changed EscapeBarrier_lock to be a _safepoint_check_never lock. It used to be _safepoint_check_sometimes, which will be eliminated sooner or later. I added explicit thread state changes with ThreadBlockInVM to code paths where we can wait() on EscapeBarrier_lock to become safepoint safe. * Use handshake EscapeBarrierSuspendHandshake to suspend target threads instead of vm operation VM_ThreadSuspendAllForObjDeopt. * Removed uses of Threads_lock. When adding a new thread we suspend it iff EA optimizations are being reverted. In the previous version we were waiting on Threads_lock while EA optimizations were reverted. See EscapeBarrier::thread_added(). * Made tests require Xmixed compilation mode. * Made tests agnostic regarding tiered compilation. I.e. tc isn't disabled anymore, and the tests can be run with tc enabled or disabled. * Exercising EATests.java as well with stress test options DeoptimizeObjectsALot* Due to the non-deterministic deoptimizations some tests need to be skipped. We do this to prevent bit-rot of the stress test code. * Executing EATests.java as well with graal if available. Driver for this is EATestsJVMCI.java. Graal cannot pass all tests, because it does not provide all the new debug info (namely not_global_escape_in_scope and arg_escape in scopeDesc.hpp). And graal does not yet support the JVMTI operations force early return and pop frame. * Removed tracing from new jdi tests in EATests.java. Too much trace output before the debugging connection is established can cause deadlock because output buffers fill up. (See https://bugs.openjdk.java.net/browse/JDK-8173304) * Many copyright year changes and smaller clean-up changes of testing code (trailing white-space and the like). -Original Message- From: David Holmes Sent: Donnerstag, 19. Dezember 2019 03:12 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net; Vladimir Kozlov (vladimir.koz...@oracle.com) Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, I think my issue is with the way EliminateNestedLocks works so I'm going to look into that more deeply. Thanks for the explanations. David On 18/12/2019 12:47 am, Reingruber, Richard wrote: > Hi David, > >> >> Some further queries/concerns: >> >> >> >> src/hotspot/share/runtime/objectMonitor.cpp >> >> >> >> Can you please explain the changes to ObjectMonitor::wait: >> >> >> >> ! _recursions = save // restore the old recursion count >> >> ! + jt->get_and_reset_relock_count_after_wait(); > // >> >> increased by the deferred relock count >> >> >> >> what is the "deferred relock count"? I gather it relates to >> >> >> >> "The code was extended to be able to deoptimize objects of a >> > frame that >> >> is not the top frame and to let another thread than the owning >> > thread do >> >> it." >> > >> > Yes, these relate. Currently EA based optimizations are reverted, when > a compiled frame is >> > replaced with corresponding interpreter frames. Part of this is > relocking objects with eliminated >> > locking. New with the enhancement is that we do this also just before > object references are >> > acquired through JVMTI. In this case we deoptimize also the owning > compiled frame C and we >> > register deoptimized objects as deferred updates. When control returns > to C it gets deoptimized, >> > we notice that objects are already deoptimized (reallocated and > relocked), so we don't do it again >> > (relocking twice would be incorrect of course). Deferred updates are > copied into the new &g
RE: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant?
Hi Vladimir, thanks for looking at this and providing feedback. I though as well about using a handshake there. I'll try it. Thanks, Richard. -Original Message- From: Vladimir Ivanov Sent: Donnerstag, 30. Januar 2020 17:55 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net Subject: Re: VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant? Hi Richard, > I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack > not_entrant. To me this > seems unnecessary. I think it would be sufficient to patch the return pc of > compiled frames and > let them return to their deopt handler. Or what would be the reason to make > the compiled methods > not_entrant? > > VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not > native methods get > marked. > > Deoptimization::deoptimize_all_marked(): all marked methods are made > not_entrant. > > Maybe this is for historical reasons? If I remember correctly, many years > ago, deoptimizing a > compiled frame used to require making the corresponding nmethod not_entrant. > And making a nmethod > not_entrant meant overriding its code with a slide of nops that led to the > deopt handler. > > I'd like to change this and just apply Deoptimization::deoptimize() on every > compiled frame on > stack. I've done this locally and tested the change without issues. I'm not a JVMTI expert, but considering VM_EnterInterpOnlyMode is performed on per-thread basis [1], it looks like per-frame deoptimization (instead of per-nmethod) should be enough to do the job. So, from JIT-compiler perspective, your suggestion to use Deoptimization::deoptimize() instead of CompiledMethod::mark_for_deoptimization()/Deoptimization::deoptimize_all_marked() sounds good. PS: also, it looks like handshakes become a perfect fit for VM_EnterInterpOnlyMode: once you don't need to deoptimize on per-nmethod basis, there's no need to trigger global safepoint. Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/prims/jvmtiEventController.cpp#l227 // If running in fullspeed mode, single stepping is implemented // as follows: first, the interpreter does not dispatch to // compiled code for threads that have single stepping enabled; // second, we deoptimize all methods on the thread's stack when // interpreted-only mode is enabled the first time for a given // thread (nothing to do if no Java frames yet).
VM_EnterInterpOnlyMode: why make compiled methods on stack not_entrant?
Hi, I noticed that VM_EnterInterpOnlyMode makes all compiled methods on stack not_entrant. To me this seems unnecessary. I think it would be sufficient to patch the return pc of compiled frames and let them return to their deopt handler. Or what would be the reason to make the compiled methods not_entrant? VM_EnterInterpOnlyMode::doit(): all compiled methods on stack that are not native methods get marked. Deoptimization::deoptimize_all_marked(): all marked methods are made not_entrant. Maybe this is for historical reasons? If I remember correctly, many years ago, deoptimizing a compiled frame used to require making the corresponding nmethod not_entrant. And making a nmethod not_entrant meant overriding its code with a slide of nops that led to the deopt handler. I'd like to change this and just apply Deoptimization::deoptimize() on every compiled frame on stack. I've done this locally and tested the change without issues. Thanks, Richard.
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi, webrev.3 didn't apply anymore after 8236000 [1]. I've rebased and updated in place: http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/ The change was minimal. Cheers, Richard. [1] JDK-8236000: VM build without C2 fails -Original Message----- From: Reingruber, Richard Sent: Dienstag, 10. Dezember 2019 22:45 To: serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi, I would like to get reviews please for http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/ Corresponding RFE: https://bugs.openjdk.java.net/browse/JDK-8227745 Fixes also https://bugs.openjdk.java.net/browse/JDK-8233915 And potentially https://bugs.openjdk.java.net/browse/JDK-8214584 [1] Vladimir Kozlov kindly put webrev.3 through tier1-8 testing without issues (thanks!). In addition the change is being tested at SAP since I posted the first RFR some months ago. The intention of this enhancement is to benefit performance wise from escape analysis even if JVMTI agents request capabilities that allow them to access local variable values. E.g. if you start-up with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, then escape analysis is disabled right from the beginning, well before a debugger attaches -- if ever one should do so. With the enhancement, escape analysis will remain enabled until and after a debugger attaches. EA based optimizations are reverted just before an agent acquires the reference to an object. In the JBS item you'll find more details. Thanks, Richard. [1] Experimental fix for JDK-8214584 based on JDK-8227745 http://cr.openjdk.java.net/~rrich/webrevs/2019/8214584/experiment_v1.patch
RE: RFR (M) 8234510: Remove file seeking requirement for writing a heap dump
Hi Ralf, the enhacement you're proposing is useful I'd say. The enhancements it enables (streaming, compression) even more so. Your change looks good to me. Note that I'm a JDK Committer not a Reviewer. Best regards, Richard. -Original Message- From: serviceability-dev On Behalf Of Schmelter, Ralf Sent: Montag, 16. Dezember 2019 13:28 To: Schmelter, Ralf ; Thomas Stüfe Cc: OpenJDK Serviceability ; hotspot-runtime-...@openjdk.java.net Subject: [CAUTION] RE: RFR (M) 8234510: Remove file seeking requirement for writing a heap dump I forgot to post the updated webrev: http://cr.openjdk.java.net/~rschmelter/webrevs/8234510/webrev.2/ In addition to the changes requested by Thomas, I also renamed the entries in the heap dump segment from entries to sub-records, since that is what they are called in the comment describing the format. Best regards, Ralf
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
is done at most once. It wouldn't be quite so easy to split this in relocking of nested/EA-based eliminated locks. > If so I find this truly awful. Anyone using wait() in a realistic form > requires a notification and so the object cannot be thread confined. In It is not thread confined. > which case I would strongly argue that upon hitting the wait() the deopt > should occur unconditionally and so the lock state is correct before we > wait and so we don't need to mess with the recursion count internally > when we reacquire the monitor. > > > > >> which I don't like the sound of at all when it comes to ObjectMonitor > >> state. So I'd like to understand in detail exactly what is going on here > >> and why. This is a very intrusive change that seems to badly break > >> encapsulation and impacts future changes to ObjectMonitor that are under > >> investigation. > > > > I would not regard this as breaking encapsulation. Certainly not badly. > > > > I've added a property relock_count_after_wait to JavaThread. The property is well > > encapsulated. Future ObjectMonitor implementations have to deal with recursion too. They are free > > in choosing a way to do that as long as that property is taken into account. This is hardly a > > limitation. > > I do think this badly breaks encapsulation as you have to add a callout > from the guts of the ObjectMonitor code to reach into the thread to get > this lock count adjustment. I understand why you have had to do this but > I would much rather see a change to the EA optimisation strategy so that > this is not needed. > > > Note also that the property is a straight forward extension of the existing concept of deferred > > local updates. It is embedded into the structure holding them. So not even the footprint of a > > JavaThread is enlarged if no deferred updates are generated. > > [...] > > > > > I'm actually duplicating the existing external suspend mechanism, because a thread can be > > suspended at most once. And hey, and don't like that either! But it seems not unlikely that the > > duplicate can be removed together with the original and the new type of handshakes that will be > > used for thread suspend can be used for object deoptimization too. See today's discussion in > > JDK-8227745 [2]. > > I hope that discussion bears some fruit, at the moment it seems not to > be possible to use handshakes here. :( > > The external suspend mechanism is a royal pain in the proverbial that we > have to carefully live with. The idea that we're duplicating that for > use in another fringe area of functionality does not thrill me at all. > > To be clear, I understand the problem that exists and that you wish to > solve, but for the runtime parts I balk at the complexity cost of > solving it. I know it's complex, but by far no rocket science. Also I find it hard to imagine another fix for JDK-8233915 besides changing the JVM TI specification. Thanks, Richard. -Original Message- From: David Holmes Sent: Dienstag, 17. Dezember 2019 08:03 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net; Vladimir Kozlov (vladimir.koz...@oracle.com) Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents David On 17/12/2019 4:57 pm, David Holmes wrote: > Hi Richard, > > On 14/12/2019 5:01 am, Reingruber, Richard wrote: >> Hi David, >> >> > Some further queries/concerns: >> > >> > src/hotspot/share/runtime/objectMonitor.cpp >> > >> > Can you please explain the changes to ObjectMonitor::wait: >> > >> > ! _recursions = save // restore the old recursion count >> > ! + jt->get_and_reset_relock_count_after_wait(); // >> > increased by the deferred relock count >> > >> > what is the "deferred relock count"? I gather it relates to >> > >> > "The code was extended to be able to deoptimize objects of a >> frame that >> > is not the top frame and to let another thread than the owning >> thread do >> > it." >> >> Yes, these relate. Currently EA based optimizations are reverted, when >> a compiled frame is replaced >> with corresponding interpreter frames. Part of this is relocking >> objects with eliminated &
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Robbin, > Sorry I don't immediately see what issue there is in doing a handshake > instead of: > VM_GetOwnedMonitorInfo op(this, calling_thread, java_thread, > owned_monitors_list); VM_GetOwnedMonitorInfo /can/ be replaced by a handshake, but the calling_thread T1 needs to walk java_thread T2's stack /before/ to reallocate and relock objects, because the GC interface does not allow the VMThread to allocate from the java heap. T1: 1. reallocate scalar replaced objects of T2 // not possible as part of handshake/vmop, // because GC interface does not allow VMThread // to allocate from heap 2. execute VM_GetOwnedMonitorInfo() or equivalent handshake while T2 is /not/ pushing new frames with EA based optimizations. > > > > 1. L13: is wait_until_eb_stopped to be called by T1 to wait until T2 cannot move anymore? > > > > 2. Handshakes between two threads are synchronous, correct? If so, then T1 will block handshaking > > T2, because either T2 or the VMThread will block in L10. > > Yes, sorry, I forgot/confused myself about asynch handshake. > (I have a test prototype for that, which removes suspend flag) > > > > > I cannot figure out, how you mean this. Only if a helper thread H would handshake T2 then T1 could > > continue and call wait_until_eb_stopped(). But returning from there T1 would block if reallocating > > objects triggers GC or attempting to execute the vm operation in > > JvmtiEnv::GetOwnedMonitorStackDepthInfo(). > > > > It might be impossible to replace my suspend flag with handshakes that are available today, because > > if it was you could replace all the suspend flags right away, couldn't you? > > So adding asynch handshakes and a per thread handshake queue, we can. > (which this test prototype does) Yes, should work for my use case too. > The issue I'm thinking of is if we need selective polling first. > Suspend flags are not checked in every transition, e.g. vm->native. > A JVM TI agent don't expect to suspend it's own thread when suspending > all threads. > (that thread would be suspended when trying to get back to agent code > when it does vm->native transition) Note that JVM TI doesn't offer "suspending all threads" directly. It offers SuspendThreadList [1] which can be used to self-suspend: "If the calling thread is specified in the request_list array, this function will not return until some other thread resumes it" Thanks, Richard. [1] https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#SuspendThreadList -Original Message- From: Robbin Ehn Sent: Montag, 16. Dezember 2019 18:21 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, On 2019-12-16 14:41, Reingruber, Richard wrote: > Hi Robbin, > > first of all: thanks a lot for providing feedback. I do appreciate it. > > I am absolutely willing to move this to handshakes. Only I still can't see > how to achieve it. > > Could you explain the drafted class EscapeBarrierSuspendHandshake a little > bit? [1] > > I'd like to look at it by example of > JvmtiEnv::GetOwnedMonitorStackDepthInfo() where calling_thread > T1 would apply it on another thread T2. Sorry I don't immediately see what issue there is in doing a handshake instead of: VM_GetOwnedMonitorInfo op(this, calling_thread, java_thread, owned_monitors_list); > > 1. L13: is wait_until_eb_stopped to be called by T1 to wait until T2 cannot > move anymore? > > 2. Handshakes between two threads are synchronous, correct? If so, then T1 > will block handshaking > T2, because either T2 or the VMThread will block in L10. Yes, sorry, I forgot/confused myself about asynch handshake. (I have a test prototype for that, which removes suspend flag) > > I cannot figure out, how you mean this. Only if a helper thread H would > handshake T2 then T1 could > continue and call wait_until_eb_stopped(). But returning from there T1 would > block if reallocating > objects triggers GC or attempting to execute the vm operation in > JvmtiEnv::GetOwnedMonitorStackDepthInfo(). > > It might be impossible to replace my suspend flag with handshakes that are > available today, because > if it was you could replace all the suspend flags right away, couldn't you? So adding asynch handshakes and a per thread handshake queue, we can. (which this test prototype does) The iss
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi Robbin,
first of all: thanks a lot for providing feedback. I do appreciate it.
I am absolutely willing to move this to handshakes. Only I still can't see how
to achieve it.
Could you explain the drafted class EscapeBarrierSuspendHandshake a little bit?
[1]
I'd like to look at it by example of JvmtiEnv::GetOwnedMonitorStackDepthInfo()
where calling_thread
T1 would apply it on another thread T2.
1. L13: is wait_until_eb_stopped to be called by T1 to wait until T2 cannot
move anymore?
2. Handshakes between two threads are synchronous, correct? If so, then T1 will
block handshaking
T2, because either T2 or the VMThread will block in L10.
I cannot figure out, how you mean this. Only if a helper thread H would
handshake T2 then T1 could
continue and call wait_until_eb_stopped(). But returning from there T1 would
block if reallocating
objects triggers GC or attempting to execute the vm operation in
JvmtiEnv::GetOwnedMonitorStackDepthInfo().
It might be impossible to replace my suspend flag with handshakes that are
available today, because
if it was you could replace all the suspend flags right away, couldn't you?
Or I'm simply missing something... quite possible... :)
Thanks, Richard.
[1] Drafted by Robbin (thanks!)
1 class EscapeBarrierSuspendHandshake : public HandshakeClosure {
2Semaphore _is_waiting;
3Semaphore _wait;
4bool _started;
5 public:
6EscapeBarrierSuspendHandshake() :
HandshakeClosure("EscapeBarrierSuspend"),
7_wait(0), _started(false) { }
8void do_thread(Thread* th) {
9 _is_waiting.signal();
10 _wait.wait();
11 Atomic::store(&_started, true);
12}
13void wait_until_eb_stopped() { _is_waiting.wait(); }
14void start_thread() {
15 _wait.signal();
16 while(!Atomic::load(&_started)) {
17os::naked_yield();
18 }
19}
20 };
-Original Message-
From: Robbin Ehn
Sent: Montag, 16. Dezember 2019 11:21
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi Richard, as mentioned it would be better if you could do this with
handshakes, instead of using _suspend_flag (since they are going away).
But I can't think of a way doing it without blocking safepoints, so we need to
add some more features in handshakes first.
When possible I hope you are willing to move this code to handshakes instead.
You could stop one thread with, e.g.:
class EscapeBarrierSuspendHandshake : public HandshakeClosure {
Semaphore _is_waiting;
Semaphore _wait;
bool _started;
public:
EscapeBarrierSuspendHandshake() : HandshakeClosure("EscapeBarrierSuspend"),
_wait(0), _started(false) { }
void do_thread(Thread* th) {
_is_waiting.signal();
_wait.wait();
Atomic::store(&_started, true);
}
void wait_until_eb_stopped() { _is_waiting.wait(); }
void start_thread() {
_wait.signal();
while(!Atomic::load(&_started)) {
os::naked_yield();
}
}
};
But it would block safepoints.
Thanks, Robbin
On 12/10/19 10:45 PM, Reingruber, Richard wrote:
> Hi,
>
> I would like to get reviews please for
>
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/
>
> Corresponding RFE:
> https://bugs.openjdk.java.net/browse/JDK-8227745
>
> Fixes also https://bugs.openjdk.java.net/browse/JDK-8233915
> And potentially https://bugs.openjdk.java.net/browse/JDK-8214584 [1]
>
> Vladimir Kozlov kindly put webrev.3 through tier1-8 testing without issues
> (thanks!). In addition the
> change is being tested at SAP since I posted the first RFR some months ago.
>
> The intention of this enhancement is to benefit performance wise from escape
> analysis even if JVMTI
> agents request capabilities that allow them to access local variable values.
> E.g. if you start-up
> with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, then escape
> analysis is disabled right
> from the beginning, well before a debugger attaches -- if ever one should do
> so. With the
> enhancement, escape analysis will remain enabled until and after a debugger
> attaches. EA based
> optimizations are reverted just before an agent acquires the reference to an
> object. In the JBS item
> you'll find more details.
>
> Thanks,
> Richard.
>
> [1] Experimental fix for JDK-8214584 based on JDK-8227745
>
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8214584/experiment_v1.patch
>
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi David, > Some further queries/concerns: > > src/hotspot/share/runtime/objectMonitor.cpp > > Can you please explain the changes to ObjectMonitor::wait: > > ! _recursions = save // restore the old recursion count > ! + jt->get_and_reset_relock_count_after_wait(); // > increased by the deferred relock count > > what is the "deferred relock count"? I gather it relates to > > "The code was extended to be able to deoptimize objects of a frame that > is not the top frame and to let another thread than the owning thread do > it." Yes, these relate. Currently EA based optimizations are reverted, when a compiled frame is replaced with corresponding interpreter frames. Part of this is relocking objects with eliminated locking. New with the enhancement is that we do this also just before object references are acquired through JVMTI. In this case we deoptimize also the owning compiled frame C and we register deoptimized objects as deferred updates. When control returns to C it gets deoptimized, we notice that objects are already deoptimized (reallocated and relocked), so we don't do it again (relocking twice would be incorrect of course). Deferred updates are copied into the new interpreter frames. Problem: relocking is not possible if the target thread T is waiting on the monitor that needs to be relocked. This happens only with non-local objects with EliminateNestedLocks. Instead relocking is deferred until T owns the monitor again. This is what the piece of code above does. > which I don't like the sound of at all when it comes to ObjectMonitor > state. So I'd like to understand in detail exactly what is going on here > and why. This is a very intrusive change that seems to badly break > encapsulation and impacts future changes to ObjectMonitor that are under > investigation. I would not regard this as breaking encapsulation. Certainly not badly. I've added a property relock_count_after_wait to JavaThread. The property is well encapsulated. Future ObjectMonitor implementations have to deal with recursion too. They are free in choosing a way to do that as long as that property is taken into account. This is hardly a limitation. Note also that the property is a straight forward extension of the existing concept of deferred local updates. It is embedded into the structure holding them. So not even the footprint of a JavaThread is enlarged if no deferred updates are generated. > --- > > src/hotspot/share/runtime/thread.cpp > > Can you please explain why JavaThread::wait_for_object_deoptimization > has to be handcrafted in this way rather than using proper transitions. > I wrote wait_for_object_deoptimization taking JavaThread::java_suspend_self_with_safepoint_check as template. So in short: for the same reasons :) Threads reach both methods as part of thread state transitions, therefore special handling is required to change thread state on top of ongoing transitions. > We got rid of "deopt suspend" some time ago and it is disturbing to see > it being added back (effectively). This seems like it may be something > that handshakes could be used for. Deopt suspend used to be something rather different with a similar name[1]. It is not being added back. I'm actually duplicating the existing external suspend mechanism, because a thread can be suspended at most once. And hey, and don't like that either! But it seems not unlikely that the duplicate can be removed together with the original and the new type of handshakes that will be used for thread suspend can be used for object deoptimization too. See today's discussion in JDK-8227745 [2]. Thanks, Richard. [1] Deopt suspend was something like an async. handshake for architectures with register windows, where patching the return pc for deoptimization of a compiled frame was racy if the owner thread was in native code. Instead a "deopt" suspend flag was set on which the thread patched its own frame upon return from native. So no thread was suspended. It got its name only from the name of the flags. [2] Discussion about using handshakes to sync. with the target thread: https://bugs.openjdk.java.net/browse/JDK-8227745?focusedCommentId=14306727&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14306727 -Original Message- From: David Holmes Sent: Freitag, 13. Dezember 2019 00:56 To: Reingruber, Richard ; serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; hotspot-runtime-...@openjdk.java.net Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents Hi Richard, Some further queries/concerns: src/hotspot/share/
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi David, Vladimir, The tests are very targeted and customized towards the issues they solve. IMHO they should be run in the configuration they are tailored for, but as I said, I'm ok with removing the tiered options/conditions. The enhancement should be covered also by existing JVMTI, JDI, JDWP tests, assuming they are also executed with Xcomp. If running the tests with Graal as C2 replacement you'll get failures, because the JVMCI compiler does not provide the debug info required at runtime (see compiledVFrame::not_global_escape_in_scope() and compiledVFrame::arg_escape). Still it would be possible to change the tests to expect these failures when executed with Graal. Perhaps I should do this? Thanks, Richard. -Original Message- From: David Holmes Sent: Freitag, 13. Dezember 2019 02:53 To: Vladimir Kozlov ; Reingruber, Richard ; hotspot-runtime-...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents On 13/12/2019 10:56 am, Vladimir Kozlov wrote: > Yes, David > > You are correct these changes touch all part of VM and may affect Graal > (which also has EA) too. > Changes should be tested in all our modes: tiered, C1 only, Graal, > Interpreter. And I realized that I only ran tier3-graal testing so I > submitted the rest of Graal's tiers now. > > I had assumed that our current testing (I ran all from tier1 to tier8) > should exercise all paths in VM these changes touch. But I may be wrong > and it is correct to ask author to add testing in all VM modes to make > sure new code in VM's runtime and JVMTI is tested. It may be that our existing JVM TI tests will exercise this adequately and that the new tests are more "whitebox" testing than general functional tests. But it is not obvious to me that we do have the coverage we need. Cheers, David > I do like to keep what current test is doing with C2. May be add an > other test for other modes or modify current one to enable to run it in > other modes. > > Thanks, > Vladimir > > On 12/12/19 3:32 PM, David Holmes wrote: >> On 13/12/2019 9:02 am, Reingruber, Richard wrote: >>> Hello Vladimir, >>> >>> thanks for having a look. >>> >>> > Use vm.compMode == "Xmixed" instead of vm.compMode != "Xcomp" to >>> skip >>> > test from running in Interpreter mode too. >>> >>> Done. >>> >>> > You don't need vm.opt.TieredCompilation != true in @requires >>> because you >>> > specified -XX:-TieredCompilation in @run command. >>> >>> Ok. >>> >>> > The test is specifically written for C2 only (not for C1 or >>> Graal) to >>> > verify its Escape Analysis optimization. >>> > I did not look in great details into test's code but its >>> analysis may be >>> > affected if C1 compiler is also used. >>> > >>> > Richard may clarify this. >>> >>> The test cases aim to get their testmethod 'dontinline_testMethod' >>> compiled by C2. If they get C1 >>> compiled before doesn't matter all that much. I've got a slight >>> preference to disabled tiered >>> compilation for simplicity. >> >> My concern - perhaps unfounded - is that this seems to be being tested >> only in a pure C2 environment when the actual changes will have to >> operate correctly in a tiered environment (and JVMCI). >> >> Thanks, >> David >> >>> Thanks, Richard. >>> >>> -Original Message- >>> From: Vladimir Kozlov >>> Sent: Donnerstag, 12. Dezember 2019 19:20 >>> To: David Holmes ; >>> hotspot-runtime-...@openjdk.java.net; >>> hotspot-compiler-...@openjdk.java.net; >>> serviceability-dev@openjdk.java.net; Reingruber, Richard >>> >>> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better >>> Performance in the Presence of JVMTI Agents >>> >>> Hi David, >>> >>> Tiered is disabled because we don't want to see compilations and outputs >>> from C1 compiler which does not have EA. >>> >>> The test is specifically written for C2 only (not for C1 or Graal) to >>> verify its Escape Analysis optimization. >>> I did not look in great details into test's code but its analysis may be >>> affected if C1 compiler is also used. >>> >>> Richard may clarify this. >>> >>> than
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hello Vladimir,
thanks for having a look.
> Use vm.compMode == "Xmixed" instead of vm.compMode != "Xcomp" to skip
> test from running in Interpreter mode too.
Done.
> You don't need vm.opt.TieredCompilation != true in @requires because you
> specified -XX:-TieredCompilation in @run command.
Ok.
> The test is specifically written for C2 only (not for C1 or Graal) to
> verify its Escape Analysis optimization.
> I did not look in great details into test's code but its analysis may be
> affected if C1 compiler is also used.
>
> Richard may clarify this.
The test cases aim to get their testmethod 'dontinline_testMethod' compiled by
C2. If they get C1
compiled before doesn't matter all that much. I've got a slight preference to
disabled tiered
compilation for simplicity.
Thanks, Richard.
-Original Message-
From: Vladimir Kozlov
Sent: Donnerstag, 12. Dezember 2019 19:20
To: David Holmes ;
hotspot-runtime-...@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
serviceability-dev@openjdk.java.net; Reingruber, Richard
Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi David,
Tiered is disabled because we don't want to see compilations and outputs
from C1 compiler which does not have EA.
The test is specifically written for C2 only (not for C1 or Graal) to
verify its Escape Analysis optimization.
I did not look in great details into test's code but its analysis may be
affected if C1 compiler is also used.
Richard may clarify this.
thanks,
Vladimir
On 12/11/19 1:04 PM, David Holmes wrote:
> On 12/12/2019 5:21 am, Vladimir Kozlov wrote:
>> I will do full review later. I want to comment about test command line.
>>
>> You don't need vm.opt.TieredCompilation != true in @requires because
>> you specified -XX:-TieredCompilation in @run command.
>
> And per my comment this should be being tested with tiered as well.
>
> David
>
>> Use vm.compMode == "Xmixed" instead of vm.compMode != "Xcomp" to skip
>> test from running in Interpreter mode too.
>>
>> Thanks,
>> Vladimir
>>
>> On 12/11/19 7:07 AM, Reingruber, Richard wrote:
>>> Hi David,
>>>
>>> > Most of the details here are in areas I can comment on in
>>> detail, but I
>>> > did take an initial general look at things.
>>>
>>> Thanks for taking the time!
>>>
>>> > The only thing that jumped out at me is that I think the
>>> > DeoptimizeObjectsALotThread should be a hidden thread.
>>> >
>>> > + bool is_hidden_from_external_view() const { return true; }
>>>
>>> Yes, it should. Will add the method like above.
>>>
>>> > Also I don't see any testing of the DeoptimizeObjectsALotThread.
>>> Without
>>> > active testing this will just bit-rot.
>>>
>>> DeoptimizeObjectsALot is meant for stress testing with a larger
>>> workload. I will add a minimal test
>>> to keep it fresh.
>>>
>>> > Also on the tests I don't understand your @requires clause:
>>> >
>>> > @requires ((vm.compMode != "Xcomp") & vm.compiler2.enabled &
>>> > (vm.opt.TieredCompilation != true))
>>> >
>>> > This seems to require that TieredCompilation is disabled, but
>>> tiered is
>>> > our normal mode of operation. ??
>>> >
>>>
>>> I removed the clause. I guess I wanted to target the tests towards
>>> the code they are supposed to
>>> test, and it's easier to analyze failures w/o tiered compilation and
>>> with just one compiler thread.
>>>
>>> Additionally I will make use of
>>> compiler.whitebox.CompilerWhiteBoxTest.THRESHOLD in the tests.
>>>
>>> Thanks,
>>> Richard.
>>>
>>> -Original Message-
>>> From: David Holmes
>>> Sent: Mittwoch, 11. Dezember 2019 08:03
>>> To: Reingruber, Richard ;
>>> serviceability-dev@openjdk.java.net;
>>> hotspot-compiler-...@openjdk.java.net;
>>> hotspot-runtime-...@openjdk.java.net
>>> Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better
>>> Performance in the Presence of JVMTI Agents
>>>
>>> Hi Richard,
>>>
>>> On 11/12/2019 7:45 am, Reingruber, Richard wrote:
>>>> Hi,
>>>>
>>>> I would like to get reviews please for
>>>>
>>>> http://cr.openjdk
RE: RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi David,
> Most of the details here are in areas I can comment on in detail, but I
> did take an initial general look at things.
Thanks for taking the time!
> The only thing that jumped out at me is that I think the
> DeoptimizeObjectsALotThread should be a hidden thread.
>
> + bool is_hidden_from_external_view() const { return true; }
Yes, it should. Will add the method like above.
> Also I don't see any testing of the DeoptimizeObjectsALotThread. Without
> active testing this will just bit-rot.
DeoptimizeObjectsALot is meant for stress testing with a larger workload. I
will add a minimal test
to keep it fresh.
> Also on the tests I don't understand your @requires clause:
>
> @requires ((vm.compMode != "Xcomp") & vm.compiler2.enabled &
> (vm.opt.TieredCompilation != true))
>
> This seems to require that TieredCompilation is disabled, but tiered is
> our normal mode of operation. ??
>
I removed the clause. I guess I wanted to target the tests towards the code
they are supposed to
test, and it's easier to analyze failures w/o tiered compilation and with just
one compiler thread.
Additionally I will make use of
compiler.whitebox.CompilerWhiteBoxTest.THRESHOLD in the tests.
Thanks,
Richard.
-Original Message-----
From: David Holmes
Sent: Mittwoch, 11. Dezember 2019 08:03
To: Reingruber, Richard ;
serviceability-dev@openjdk.java.net; hotspot-compiler-...@openjdk.java.net;
hotspot-runtime-...@openjdk.java.net
Subject: Re: RFR(L) 8227745: Enable Escape Analysis for Better Performance in
the Presence of JVMTI Agents
Hi Richard,
On 11/12/2019 7:45 am, Reingruber, Richard wrote:
> Hi,
>
> I would like to get reviews please for
>
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/
>
> Corresponding RFE:
> https://bugs.openjdk.java.net/browse/JDK-8227745
>
> Fixes also https://bugs.openjdk.java.net/browse/JDK-8233915
> And potentially https://bugs.openjdk.java.net/browse/JDK-8214584 [1]
>
> Vladimir Kozlov kindly put webrev.3 through tier1-8 testing without issues
> (thanks!). In addition the
> change is being tested at SAP since I posted the first RFR some months ago.
>
> The intention of this enhancement is to benefit performance wise from escape
> analysis even if JVMTI
> agents request capabilities that allow them to access local variable values.
> E.g. if you start-up
> with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, then escape
> analysis is disabled right
> from the beginning, well before a debugger attaches -- if ever one should do
> so. With the
> enhancement, escape analysis will remain enabled until and after a debugger
> attaches. EA based
> optimizations are reverted just before an agent acquires the reference to an
> object. In the JBS item
> you'll find more details.
Most of the details here are in areas I can comment on in detail, but I
did take an initial general look at things.
The only thing that jumped out at me is that I think the
DeoptimizeObjectsALotThread should be a hidden thread.
+ bool is_hidden_from_external_view() const { return true; }
Also I don't see any testing of the DeoptimizeObjectsALotThread. Without
active testing this will just bit-rot.
Also on the tests I don't understand your @requires clause:
@requires ((vm.compMode != "Xcomp") & vm.compiler2.enabled &
(vm.opt.TieredCompilation != true))
This seems to require that TieredCompilation is disabled, but tiered is
our normal mode of operation. ??
Thanks,
David
> Thanks,
> Richard.
>
> [1] Experimental fix for JDK-8214584 based on JDK-8227745
>
> http://cr.openjdk.java.net/~rrich/webrevs/2019/8214584/experiment_v1.patch
>
RFR(L) 8227745: Enable Escape Analysis for Better Performance in the Presence of JVMTI Agents
Hi, I would like to get reviews please for http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.3/ Corresponding RFE: https://bugs.openjdk.java.net/browse/JDK-8227745 Fixes also https://bugs.openjdk.java.net/browse/JDK-8233915 And potentially https://bugs.openjdk.java.net/browse/JDK-8214584 [1] Vladimir Kozlov kindly put webrev.3 through tier1-8 testing without issues (thanks!). In addition the change is being tested at SAP since I posted the first RFR some months ago. The intention of this enhancement is to benefit performance wise from escape analysis even if JVMTI agents request capabilities that allow them to access local variable values. E.g. if you start-up with -agentlib:jdwp=transport=dt_socket,server=y,suspend=n, then escape analysis is disabled right from the beginning, well before a debugger attaches -- if ever one should do so. With the enhancement, escape analysis will remain enabled until and after a debugger attaches. EA based optimizations are reverted just before an agent acquires the reference to an object. In the JBS item you'll find more details. Thanks, Richard. [1] Experimental fix for JDK-8214584 based on JDK-8227745 http://cr.openjdk.java.net/~rrich/webrevs/2019/8214584/experiment_v1.patch
RE: RFC 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement
Hi Leonid, these are valid points. Thanks for making me aware of them. I've increased the maximum heap size in my tests as suggested, and I've also run them with ZGC enabled. I've also added the vm.opt.TieredCompilation != true requirement. I've done the changes in place. Thanks, Richard. -Original Message- From: hotspot-compiler-dev On Behalf Of Leonid Mesnik Sent: Dienstag, 12. November 2019 20:34 To: hotspot-compiler-...@openjdk.java.net Subject: Re: RFC 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement Hi I don't make complete review just sanity verified your test headers. I see a couple of potential issues with them. 1) The using Xmx32M could cause OOME failures if test is executed with ZGC. I think that at least 256M should be set. Could you please verify that your tests pass with ZGC enabled. 2) I think it makes sense to add requires vm.opt.TieredCompilation != true to just skip tests if anyone runs them with tiered compilation disabled explicitly. Leonid On 11/11/19 7:29 AM, Reingruber, Richard wrote: > Hi, > > I have created https://bugs.openjdk.java.net/browse/JDK-8233915 > > In short, a set of live objects L is not found using JVMTI FollowReferences() > if L is only reachable > from a scalar replaced object in a frame of a C2 compiled method. If L > happens to be a growing leak, > then a dynamically loaded JVMTI agent (note: can_tag_objects is an always > capability) for heap > diagnostics won't discover L as live and it won't be able to find root > references that lead to L. > > I'd like to suggest the implementation for the proposed enhancement > JDK-8227745 as bug-fix. > > RFE: https://bugs.openjdk.java.net/browse/JDK-8227745 > Webrev(*): http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.1/ > > Please comment on the suggestion. Dou you see other solutions that allow an > agent to discover the > chain of references to L? > > I'd like to work on the complexity as well. One significant simplification > could be, if it was > possible to reallocate scalar replaced objects at safepoints (i.e. allow the > VM thread to call > Deoptimization::realloc_objects()). The GC interface does not seem to allow > this. > > Thanks, Richard. > > (*) Not yet accepted, because deemed too complex for the performance gain. > Note that I was able to > reduce webrev.1 in size compared to webrev.0
RFC 8233915: JVMTI FollowReferences: Java Heap Leak not found because of C2 Scalar Replacement
Hi, I have created https://bugs.openjdk.java.net/browse/JDK-8233915 In short, a set of live objects L is not found using JVMTI FollowReferences() if L is only reachable from a scalar replaced object in a frame of a C2 compiled method. If L happens to be a growing leak, then a dynamically loaded JVMTI agent (note: can_tag_objects is an always capability) for heap diagnostics won't discover L as live and it won't be able to find root references that lead to L. I'd like to suggest the implementation for the proposed enhancement JDK-8227745 as bug-fix. RFE: https://bugs.openjdk.java.net/browse/JDK-8227745 Webrev(*): http://cr.openjdk.java.net/~rrich/webrevs/2019/8227745/webrev.1/ Please comment on the suggestion. Dou you see other solutions that allow an agent to discover the chain of references to L? I'd like to work on the complexity as well. One significant simplification could be, if it was possible to reallocate scalar replaced objects at safepoints (i.e. allow the VM thread to call Deoptimization::realloc_objects()). The GC interface does not seem to allow this. Thanks, Richard. (*) Not yet accepted, because deemed too complex for the performance gain. Note that I was able to reduce webrev.1 in size compared to webrev.0
RE: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small
> I kept the 128M That's good. Cheers, Richard. -Original Message- From: Per Liden Sent: Wednesday, October 9, 2019 8:24 PM To: Reingruber, Richard ; hotspot-compiler-dev Cc: serviceability-dev@openjdk.java.net Subject: Re: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small Thanks for reviewing, Richard. I kept the 128M, since that was what I ran through testing, and I'd like to push this as soon as possible since it's causing noise in our CI. If someone wants to remove the -Xmx128M, feel free to file a follow up. However, note that the test might then consume more memory, since the default -Xmx might be larger than 128M in some environments/configurations. cheers, Per On 10/9/19 4:04 PM, Reingruber, Richard wrote: > Hi Per, > > Sorry about the problem. Your change looks good to me, I'm not a reviewer > though. > > Alternatively you can just remove the lines that set -Xmx (and -Xms). The > lines are not needed in these tests (copied from other tests). I've tried > that successfully just now. > > Thanks, Richard. > > -Original Message- > From: Per Liden > Sent: Mittwoch, 9. Oktober 2019 15:20 > To: hotspot-compiler-dev > Cc: Reingruber, Richard ; > serviceability-dev@openjdk.java.net > Subject: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: > Heap too small > > The newly added: > > GetOwnedMonitorInfoWithEATest.java > GetOwnedMonitorStackDepthInfoWithEATest.java > > fail when run with ZGC as they set -Xmx to 32M which is too. Bumping to > 128m. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232056 > Webrev: http://cr.openjdk.java.net/~pliden/8232056/webrev.0 > > /Per >
RE: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small
Hi Per, Sorry about the problem. Your change looks good to me, I'm not a reviewer though. Alternatively you can just remove the lines that set -Xmx (and -Xms). The lines are not needed in these tests (copied from other tests). I've tried that successfully just now. Thanks, Richard. -Original Message- From: Per Liden Sent: Mittwoch, 9. Oktober 2019 15:20 To: hotspot-compiler-dev Cc: Reingruber, Richard ; serviceability-dev@openjdk.java.net Subject: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small The newly added: GetOwnedMonitorInfoWithEATest.java GetOwnedMonitorStackDepthInfoWithEATest.java fail when run with ZGC as they set -Xmx to 32M which is too. Bumping to 128m. Bug: https://bugs.openjdk.java.net/browse/JDK-8232056 Webrev: http://cr.openjdk.java.net/~pliden/8232056/webrev.0 /Per
RE: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
Thank you, Dan and Serguei. Richard. From: serguei.spit...@oracle.com Sent: Donnerstag, 26. September 2019 16:33 To: daniel.daughe...@oracle.com; Reingruber, Richard ; Vladimir Kozlov ; David Holmes ; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken I'm okay with that too. Thanks, Serguei On 9/26/19 07:30, Daniel D. Daugherty wrote: I'm good with the testing that you've done. Thanks for closing the loop. Serguei? Dan On 9/26/19 3:36 AM, Reingruber, Richard wrote: Hi Dan and Serguei, The change went through our nightly testing a few times, which includes these tests and many more on all platforms. Thanks, Richard. From: serguei.spit...@oracle.com<mailto:serguei.spit...@oracle.com> <mailto:serguei.spit...@oracle.com> Sent: Mittwoch, 25. September 2019 19:10 To: daniel.daughe...@oracle.com<mailto:daniel.daughe...@oracle.com>; Reingruber, Richard <mailto:richard.reingru...@sap.com>; Vladimir Kozlov <mailto:vladimir.koz...@oracle.com>; David Holmes <mailto:david.hol...@oracle.com>; hotspot-compiler-...@openjdk.java.net<mailto:hotspot-compiler-...@openjdk.java.net>; serviceability-dev@openjdk.java.net<mailto:serviceability-dev@openjdk.java.net> Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken Hi Dan and Richard, The JVMTI and JDI tests are: vmTestbase_nsk_jvmti, vmTestbase_nsk_jdi and jdk_jdi The tests locations are: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti open/test/hotspot/jtreg/vmTestbase/nsk/jdi open/test/jdk/com/sun/jdi I think, they all have to be in the hs-tier5-rt. Thanks, Serguei On 9/25/19 07:32, Daniel D. Daugherty wrote: Based on the review thread, it looks like Richard has run Tier1 tests on this change. I don't think there are any JVM/TI tests in Tier1. I'm not sure how much compiler testing is done in Tier1, but I do know that the compiler stress testing doesn't kick in until the later tiers (Tier5 or Tier6)... Serguei, with your JVM/TI hat on, what kind of additional testing (if any) do you think we need here? Dan On 9/25/19 6:20 AM, Reingruber, Richard wrote: Thank you Vladimir and also David and Serguei for your Reviews. > May be add comment that it is onload capability and can't be changed during execution. Done. I'll be out-of-office next week. Will push when coming back. Thanks, Richard. -Original Message- From: Vladimir Kozlov <mailto:vladimir.koz...@oracle.com> Sent: Dienstag, 24. September 2019 21:04 To: Reingruber, Richard <mailto:richard.reingru...@sap.com>; hotspot-compiler-...@openjdk.java.net<mailto:hotspot-compiler-...@openjdk.java.net>; serviceability-dev@openjdk.java.net<mailto:serviceability-dev@openjdk.java.net> Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken I read discussion and this change looks good to me. May be add comment that it is onload capability and can't be changed during execution. Thanks, Vladimir On 9/6/19 7:24 AM, Reingruber, Richard wrote: Hi, could I please get reviews for Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8230677/webrev.0/ Bug:https://bugs.openjdk.java.net/browse/JDK-8230677 The JVMTI functions GetOwnedMonitorInfo() and GetOwnedMonitorStackDepthInfo() can be used to retrieve objects locked by a thread. In terms of escape analysis those references escape and optimizations like scalar replacement become invalid. The runtime currently cannot cope with objects escaping through JVMTI (try included tests). Therefore escape analysis should be disabled if an agent requests the capabilities can_get_owned_monitor_info or can_get_owned_monitor_stack_depth_info. This was taken out of JDK-8227745 [1] to make it smaller. With JDK-8227745 there's no need to disable escape analysis, instead optimizations based on escape analysis will be reverted just before objects escape through JVMTI. I've run tier1 tests. Thanks, Richard. [1] https://bugs.openjdk.java.net/browse/JDK-8227745
RE: Should optimizations be observable for JVMTI agents?
Vladimir and Andrew, thanks for the feedback. Even if it is -1 so far ;) I think I should clarify what my intend and motivation are. Clearly it is not my intend to hinder optimization in the (potential) presence of JVMTI agents. It probably looks like it, though, as I'm opening all those bugs requesting to disable EA. All the bugs are split off the RFE JDK-8227745. Vladimir has asked me to do so. This way we can discuss the issues I see one-by-one and we're also able to selectively downport conservative fixes, i.e. disabling EA in some scenarios. **My actual intend** is to enable EA independently of JVMTI agents, reconstructing the high level state just before it is inspected. **Main motivation** behind RFE JDK-8227745 is to be able to start a production system in a mode that allows to initiate a debugging session anytime later if necessary or desired. In most cases debugging will never be activated and the production systems should run at the best possible performance while still being ready for debugging. Besides this the enhancement will improve performance when a debugger has attached to the vm. Note that the cost for this is virtually zero when you don't make JVMTI calls. You'll get the full speed-up of EA. Note also that most of the required debuginfo is there already. It is needed to switch from compiled to interpreted execution. If your agent actually performs JVMTI calls, then I would estimate the costs of reconstructing the state, i.e. reallocating/relocking and saving the objects for later deoptimization as relatively small. Also you have to do that just once. The next time the agent inspects the same part of the app state it will be there already. Thanks, Richard. PS: I'll be out-of-office for a week and therefore unresponsive. -Original Message- From: Vladimir Kozlov Sent: Mittwoch, 25. September 2019 18:53 To: Andrew Dinn ; Reingruber, Richard ; David Holmes ; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: Should optimizations be observable for JVMTI agents? I had very good discussion yesterday with Serguei Spitsyn from serviceability. He said that we may not need one solution. Both cases, monitoring and debugging, are important and we can use different solutions for them. As Andrew said, for monitoring you want to observe the same behavior as in production. I think we should not restrict JIT and others optimizations in this case. I also agree with Richard that JVMTI may report scalar replaced objects and elided monitors in this mode if requested - it is also interesting information. For debugging we may want to see locals and monitors present in compiled code and it is reasonable to avoid optimizations which remove them. But even for debugging we may want to use optimized code as we do when debugging optimized C code (we don't expect to see all locals in such case). May be we should check not which JVMTI capabilities are switched on but for what JVMTI is used for. Or add API for user to ask what he wants. As Richard mentioned in some email compiled frame can't be deoptimized (to get objects and monitors back) if it is not top frame on stack. So we can't rely on deoptimization here. JIT and Runtime need to know what to do with optimizations when agent is attached to JVM. I don't like suggestion for 8230956 to switch off EA when can_tag_objects is on. Based on declaration, can_tag_objects is always on. Which means we will have EA off in all cases including monitoring tools (JFR, managment, profiling) which is not acceptable for me. I share David's concern about missing cases for some JVMTI capabilities which are not checked when JIT decides to use optimizations. And I think it will be troublesome to go through all capabilities old and new to see if we need to add checks. For me as JIT compiler engineer it would be much simpler to ask JVMTI should optimizations be switched off or not and let JVMTI find in which case it is used and make decision instead of current case when JIT checks some JVMTI capabilities. I agree to provide information in compiled code for JVMTI - we do provide information about scalar replaced object already. And I think it would be much easier to document such relation between JIT and JVMTI. Thanks, Vladimir On 9/25/19 7:32 AM, Andrew Dinn wrote: > On 25/09/2019 13:31, Reingruber, Richard wrote: >>> The terminology clarification is simply that - a clarification so that >>> when the spec says "heap" it means "Java heap", when it says "Thread" it >>> means "Java thread" etc without having to spell it out each time. I do >>> not read this as meaning anything about an "abstract virtual machine" >>> state, it is about the Java Virtual Machine state - which to mean can be >>> t
RE: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
Hi Dan and Serguei, The change went through our nightly testing a few times, which includes these tests and many more on all platforms. Thanks, Richard. From: serguei.spit...@oracle.com Sent: Mittwoch, 25. September 2019 19:10 To: daniel.daughe...@oracle.com; Reingruber, Richard ; Vladimir Kozlov ; David Holmes ; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken Hi Dan and Richard, The JVMTI and JDI tests are: vmTestbase_nsk_jvmti, vmTestbase_nsk_jdi and jdk_jdi The tests locations are: open/test/hotspot/jtreg/vmTestbase/nsk/jvmti open/test/hotspot/jtreg/vmTestbase/nsk/jdi open/test/jdk/com/sun/jdi I think, they all have to be in the hs-tier5-rt. Thanks, Serguei On 9/25/19 07:32, Daniel D. Daugherty wrote: Based on the review thread, it looks like Richard has run Tier1 tests on this change. I don't think there are any JVM/TI tests in Tier1. I'm not sure how much compiler testing is done in Tier1, but I do know that the compiler stress testing doesn't kick in until the later tiers (Tier5 or Tier6)... Serguei, with your JVM/TI hat on, what kind of additional testing (if any) do you think we need here? Dan On 9/25/19 6:20 AM, Reingruber, Richard wrote: Thank you Vladimir and also David and Serguei for your Reviews. > May be add comment that it is onload capability and can't be changed during execution. Done. I'll be out-of-office next week. Will push when coming back. Thanks, Richard. -Original Message- From: Vladimir Kozlov <mailto:vladimir.koz...@oracle.com> Sent: Dienstag, 24. September 2019 21:04 To: Reingruber, Richard <mailto:richard.reingru...@sap.com>; hotspot-compiler-...@openjdk.java.net<mailto:hotspot-compiler-...@openjdk.java.net>; serviceability-dev@openjdk.java.net<mailto:serviceability-dev@openjdk.java.net> Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken I read discussion and this change looks good to me. May be add comment that it is onload capability and can't be changed during execution. Thanks, Vladimir On 9/6/19 7:24 AM, Reingruber, Richard wrote: Hi, could I please get reviews for Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8230677/webrev.0/ Bug:https://bugs.openjdk.java.net/browse/JDK-8230677 The JVMTI functions GetOwnedMonitorInfo() and GetOwnedMonitorStackDepthInfo() can be used to retrieve objects locked by a thread. In terms of escape analysis those references escape and optimizations like scalar replacement become invalid. The runtime currently cannot cope with objects escaping through JVMTI (try included tests). Therefore escape analysis should be disabled if an agent requests the capabilities can_get_owned_monitor_info or can_get_owned_monitor_stack_depth_info. This was taken out of JDK-8227745 [1] to make it smaller. With JDK-8227745 there's no need to disable escape analysis, instead optimizations based on escape analysis will be reverted just before objects escape through JVMTI. I've run tier1 tests. Thanks, Richard. [1] https://bugs.openjdk.java.net/browse/JDK-8227745
RE: RFR(S) 8230956: Should disable Escape Analysis when JVMTI capability can_tag_objects is taken
Hello Vladimir, thanks for looking at this. > can_tag_objects is "always" capability. That's correct. > If it is true then EA will be disabled in all cases when JVMTI agent is used. It is too broad. > > Am I missing something? No that's correct too. If you include jvmti as hotspot feature in your build then you should disable escape analysis by default. That's really too hard. My proposed improvement has the effect that escape analysis is disabled if any agent calls AddCapabilities() during the OnLoad phase. Because calling AddCapabilities(), even with an empty set of capabilities, has the effect that JvmtiExport::can_walk_any_space() will return always true after that. Not sure if this is a bug or feature though. But only disabling EA by default or JDK-8227745 would be a real fix. > It is also not clear to me that it is bug. Based on all description this functionality is used to > catch leaks in Java heap. But scalar replaced objects do not exists. JVMTI should not even see them. I do think, JVMTI heap functions must report scalar replaced objects for formal and for practical reasons. JVM spec defines for the new bytecode [1] Operation Create new object Description [...] Memory for a new instance of that class is allocated from the garbage-collected heap, [...] So I think JVMTI heap functions have to report that new instance on the virtual heap. If they don't do it you can get contradicting data, too, from agents that employ bytecode instrumentation to count instances. Also there can be a leak rooted at a chain of scalar replaced objects. This is currently not reported either. If an agent traverses references it won't arrive at the leaked objects. If it itereates objects on the heap then the leaking objects are found, but it will remain unknown what's keeping them alive. Thanks, Richard. [1] https://docs.oracle.com/javase/specs/jvms/se13/html/jvms-6.html#jvms-6.5.new -Original Message- From: Vladimir Kozlov Sent: Mittwoch, 25. September 2019 03:04 To: Reingruber, Richard ; hotspot-compiler-...@openjdk.java.net; OpenJDK Serviceability Subject: Re: RFR(S) 8230956: Should disable Escape Analysis when JVMTI capability can_tag_objects is taken It is also not clear to me that it is bug. Based on all description this functionality is used to catch leaks in Java heap. But scalar replaced objects do not exists. JVMTI should not even see them. Thanks, Vladimir On 9/24/19 3:37 PM, Vladimir Kozlov wrote: > can_tag_objects is "always" capability. > > If it is true then EA will be disabled in all cases when JVMTI agent is used. > It is too broad. > > Am I missing something? > > Thanks, > Vladimir > > On 9/13/19 7:12 AM, Reingruber, Richard wrote: >> Hi, >> >> could I please get reviews for >> >> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8230956/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8230956 >> >> JVMTI provides functions to follow references beginning at the roots of the >> object graph and it >> provides functions to iterate all objects on the heap[1][2]. These functions >> are means to access >> objects which are otherwise local to a Java thread. In terms of escape >> analysis these local objects >> escape through these JVMTI functions invalidating optimizations based on >> escape analysis. >> >> Example: >> >> - Let J be a JavaThread that calls a compiled method M with a NoEscape >> instance I of class C that is >> scalar replaced. >> >> - JVMTI agent A uses JVMTI FollowReferences() to iterate the objects in the >> object graph tagging all >> instances of C. >> >> - A uses GetObjectsWithTags() to retrieve the tagged instances of C. >> >> - Error: I is missing because its allocation was eliminated / scalar >> replaced. >> >> Agents are required to possess the capability can_tag_objects in order to >> call the JVMTI heap >> functions that let objects escape. Currently it is not possible to revert >> EA based optimizations >> just before objects escape through JVMTI therefore escape analysis should be >> disabled as soon as the >> JVMTI capability can_tag_objects is taken. >> >> But this is not sufficient, because there may be compiled frames on stack >> with EA based >> optimizations when a JVMTI agent takes can_tag_objects (see included >> exclusive test cases), and then >> it does not help to disable escape analysis or invalidate compiled methods >> with ea based >> optimizations. In general it is still an improvement to do so. JDK-8227745 >> would be a complete >> solution to the issue. >
RE: Should optimizations be observable for JVMTI agents?
> >> Not a yes/no question IMO. I certainly don't subscribe to your view that > >> JVM TI must always expose the "abstract virtual machine" regardless of > >> what may have been done in the real VM. > > > > That's what what the documentation says. Everything refers to the Java VM not to the native > > platform. An object is allocated on the JVM heap which is distinct from native memory. JVM TI must > > report an object on the JVM heap regardless wether that virtual allocation was mapped to x86 > > registers, linux thread stack, linux process heap, or to nv ram. This is just an example for > > the fact that it is the state of the virtual machine which is inspected. > > > > Please read again https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#context > > > > 'Since this interface provides access to the state of applications running in the Java virtual > > machine; terminology refers to the Java platform and not the native platform (unless stated > > otherwise). For example:' > > > > "thread" means Java programming language thread. > > "stack frame" means Java virtual machine stack frame. > > "class" means Java programming language class. > > "heap" means Java virtual machine heap. <- note this > > "monitor" means Java programming language object monitor. > > > > These sum up to *the state* to be shown. > > The terminology clarification is simply that - a clarification so that > when the spec says "heap" it means "Java heap", when it says "Thread" it > means "Java thread" etc without having to spell it out each time. I do > not read this as meaning anything about an "abstract virtual machine" > state, it is about the Java Virtual Machine state - which to mean can be > the concrete state as implemented by Hotspot, not some abstract > conceptual model state. It is more than that. It is the glue to the JVM and Java Language specifications. This is important to accept. Otherwise I would suggest to do your java debugging with gdb and Intel (or AMD??) x86 manuals at your hand. > We'll just have to agree to disagree here. Agreed. All I do is offer my points to our audience hoping for a few '+1' ;) Richard. -Original Message- From: David Holmes Sent: Mittwoch, 25. September 2019 12:34 To: Reingruber, Richard ; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: Should optimizations be observable for JVMTI agents? On 25/09/2019 7:46 pm, Reingruber, Richard wrote: > Hi David, > > thanks for taking part in the discussion. > >> Hi Richard, >> >> Thanks for continuing the discussion. Some responses below. >> >> On 25/09/2019 7:28 am, Reingruber, Richard wrote: >> > Hi, >> > >> > I would like to get comments on the following questions: >> > >> >1. Should optimizations be observable for JVMTI agents in general? >> >> Not a yes/no question IMO. I certainly don't subscribe to your view that >> JVM TI must always expose the "abstract virtual machine" regardless of >> what may have been done in the real VM. > > That's what what the documentation says. Everything refers to the Java VM not > to the native > platform. An object is allocated on the JVM heap which is distinct from > native memory. JVM TI must > report an object on the JVM heap regardless wether that virtual allocation > was mapped to x86 > registers, linux thread stack, linux process heap, or to nv ram. This is just > an example for > the fact that it is the state of the virtual machine which is inspected. > > Please read again > https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#context > > 'Since this interface provides access to the state of applications > running in the Java virtual > machine; terminology refers to the Java platform and not the native > platform (unless stated > otherwise). For example:' > > "thread" means Java programming language thread. > "stack frame" means Java virtual machine stack frame. > "class" means Java programming language class. > "heap" means Java virtual machine heap. <- note this > "monitor" means Java programming language object monitor. > > These sum up to *the state* to be shown. The terminolog
RE: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
Thank you Vladimir and also David and Serguei for your Reviews. > May be add comment that it is onload capability and can't be changed during execution. Done. I'll be out-of-office next week. Will push when coming back. Thanks, Richard. -Original Message- From: Vladimir Kozlov Sent: Dienstag, 24. September 2019 21:04 To: Reingruber, Richard ; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken I read discussion and this change looks good to me. May be add comment that it is onload capability and can't be changed during execution. Thanks, Vladimir On 9/6/19 7:24 AM, Reingruber, Richard wrote: > Hi, > > could I please get reviews for > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8230677/webrev.0/ > Bug:https://bugs.openjdk.java.net/browse/JDK-8230677 > > The JVMTI functions GetOwnedMonitorInfo() and GetOwnedMonitorStackDepthInfo() > can be used to > retrieve objects locked by a thread. In terms of escape analysis those > references escape and > optimizations like scalar replacement become invalid. > > The runtime currently cannot cope with objects escaping through JVMTI (try > included > tests). Therefore escape analysis should be disabled if an agent requests the > capabilities > can_get_owned_monitor_info or can_get_owned_monitor_stack_depth_info. > > This was taken out of JDK-8227745 [1] to make it smaller. With JDK-8227745 > there's no need to > disable escape analysis, instead optimizations based on escape analysis will > be reverted just before > objects escape through JVMTI. > > I've run tier1 tests. > > Thanks, Richard. > > [1] https://bugs.openjdk.java.net/browse/JDK-8227745 >
RE: Should optimizations be observable for JVMTI agents?
Hi David, thanks for taking part in the discussion. > Hi Richard, > > Thanks for continuing the discussion. Some responses below. > > On 25/09/2019 7:28 am, Reingruber, Richard wrote: > > Hi, > > > > I would like to get comments on the following questions: > > > >1. Should optimizations be observable for JVMTI agents in general? > > Not a yes/no question IMO. I certainly don't subscribe to your view that > JVM TI must always expose the "abstract virtual machine" regardless of > what may have been done in the real VM. That's what what the documentation says. Everything refers to the Java VM not to the native platform. An object is allocated on the JVM heap which is distinct from native memory. JVM TI must report an object on the JVM heap regardless wether that virtual allocation was mapped to x86 registers, linux thread stack, linux process heap, or to nv ram. This is just an example for the fact that it is the state of the virtual machine which is inspected. Please read again https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#context 'Since this interface provides access to the state of applications running in the Java virtual machine; terminology refers to the Java platform and not the native platform (unless stated otherwise). For example:' "thread" means Java programming language thread. "stack frame" means Java virtual machine stack frame. "class" means Java programming language class. "heap" means Java virtual machine heap. <- note this "monitor" means Java programming language object monitor. These sum up to *the state* to be shown. You'll see that it is all about the _virtual_ machine. Maybe there is room for additional information about the native machine... but first JVMTI must show the virtual state to agents. > This seems potentially too > limiting and proscriptive to me. The JLS, as you note, already allows > for optimisations that may surprise the "naive". That is currently only > stated in terms of reachability and finalization, but it establishes the > precedent of being pragmatic about these things. Unfortunately the JLS > doesn't define its own interactions with specifications like JVM TI, so > we can't expect to find all the answers in the JLS, again IMO. The JVMS > also doesn't cover interactions between various specifications. If we > look at the JVM TI specification it is defined as: > > "It provides both a way to inspect the state and to control the > execution of applications running in the JavaTM virtual machine (VM). " > > That's nice and broad to me - its about what is running in the JVM. It > explicitly does not say anything about observability or control of > things that are visible in the Java source code (which seems to be what > your 'abstract virtual machine' maps to). Obviously there's is a lot of > correlation between the runtime entities and source code entities, but > no requirement to exactly replicate what may be present in the source > code. Indeed given there is no specification for how to transform source > code to bytecode, it would be very difficult for it to state that. > > So I think we have to consider each optimisation (or group thereof) on > its own merits, considering: > - how important it would be to accurately interact with things as > expressed at the source level > - the cost of disabling or reversing the optimisation when needed; and > - the overall cost and complexity it adds to the development and > maintenance of the JVM > > >2. Should in particular optimzations based on escape analysis be observable? > > > > (a) Should GetOwnedMonitorInfo() exclude objects with eliminated locking? > > Currently it does [1] > > I certainly don't have a problem with lock-elision really meaning > lock-elision. But nor do I insist that is the way it should be. > > My concern with the current behaviour(?) and proposals in this area is > that the approaches are far too coarse-grained**. If we have the > can_get_monitor_info capability then we disable all of Escape Analysis > for everything! That's harsh. With your proposal for JDK-8227745 IIUC if > we are looking for monitors and hit an optimized frame then we deopt > incase it may contained an elided monitor. Less harsh but still more > coarse-grained than I would like. I would expect EA to be a bit smarter > here: > > - if an object is thread-confined but subject to synchronization, and we
RE: Should optimizations be observable for JVMTI agents?
To get started: my own answers to the questions: Optimizations should _not_ be observable for JVMTI agents. They should be as transparent as they are for Java programs. Therefore EA should be disabled appropriately or JDK-8227745 should be realized [3] This is why: Documentation states "[...] JVMTI [...] provides a way to inspect the state and to control the execution of applications running in the JavaTM virtual machine (VM). " [1] It clarifies again that it refers to the Java platform and not to the native platform. Eg '"monitor" means Java programming language object monitor.' [2] 1. + 2.: No In essence the JVMTI Doc says a JVMTI agent observes what the app itself observes. Namely the state of the app. Optimizations that are transparent to the application must be transparent to JVMTI agents also. In other and more words: I see the JVM as an abstract model created by JLS/JVM specs. Concrete implementations use the degrees of freedom the model has for optimizations to reduce resource consumption for better performance. Optimizations are implementation details. They are transparent to Java programs, as they don't have any additional effect on the application state in the JVM(*). According to the documentation above JVMTI agents have to observe the very same state and optimizations therefore are transparent for them too. (*) should be true at least for compiler optimizations. 2a: No So let's look at some thread T which has successfully completed a monitorenter bytecode on an object O. The state of the program on the JVM is then T owns O's monitor. It may be, though, that the monitorenter has no ordering effect, as specified by the Java memory model, because no other thread S will ever execute a monitorenter on O. This allows to eliminate the locking instructions, but even then O should be reported by GetOwnedMonitorInfo(), because that's the state of the program on the JVM. 2b: No This one is a little bit more complicated, because JLS 12.6.1 [4] states "Optimizing transformations of a program can be designed that reduce the number of objects that are reachable to be less than those which would naively be considered reachable. For example, a Java compiler or code generator may choose to set a variable or parameter that will no longer be used to null to cause the storage for such an object to be potentially reclaimable sooner. Another example of this occurs if the values in an object's fields are stored in registers. The program may then access the registers instead of the object, and never access the object again. This would imply that the object is garbage. Note that this sort of optimization is only allowed if references are on the stack, not stored in the heap." This is tailored exactly to an optimization that aims to remove heap references as soon as possible from the stack roots of the object graph in order to make them unreachable and reclaim their memory. This change in reachability can be detected, though, by means of finalization and java.lang.ref. Therefore it was "legalized" in the JLS. The cited sections match scalar replacement very well also. Would have been nice and sufficient if the statements were restricted to instances with finalization or subclasses of java.lang.ref.Reference. They are considered to escape globally and are never scalar replaced. Finalization and notification/nullification for java.lang.ref.Reference, though, are the only means by which a Java program can observe the optimization. For other objects it is impossible. Therefore scalar replacement is transparent to the Java app and consequently to JVMTI agents also. Note also that C2 can scalar replace objects even if they do escape globally (but only after uncommon traps). Then 12.6.1 does not apply anyway. 2c: No. For the same reasons as for 2b. 2d: No, but not sure :) JVMTI doc above says "... provides a way ... to control the execution of applications...". According to this I would think a modification by a JVMTI agent should have an effect. There might be cases (loop without call but with safepoint), where reads get cached, even without EA and modifications have no effect. Thanks, Richard. [1] https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#whatIs [2] https://docs.oracle.com/en/java/javase/13/docs/specs/jvmti.html#context [3] JDK-8227745 in a nutshell will do what's already done when a thread traps from compiled execution to the interpreter: it reallocates and relocks objects upon access through JVMTI. This allows to enable EA and keep it transparent for agents. [4] https://docs.oracle.com/javase/specs/jls/se13/html/jls-12.html#jls-12.6.1 -Original Message- From: serviceability-dev On Behalf Of Reingruber, Richard Sent: Dienstag, 24. September 2019 23:29 To: hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Sub
Should optimizations be observable for JVMTI agents?
Hi, I would like to get comments on the following questions: 1. Should optimizations be observable for JVMTI agents in general? 2. Should in particular optimzations based on escape analysis be observable? (a) Should GetOwnedMonitorInfo() exclude objects with eliminated locking? Currently it does [1] (b) Should GetLocalObject() return null for scalar replaced objects? Currently it does not. EA is disabled if agents can access locals. (c) Should scalar replaced objects be omitted when agents iterate the heap / traverse the object graph. Currently they are omitted [2] (d) Should memory optimizations (caching of reads) be observable? Eg. should field modifications of a NoEscape object O by a JVMTI agent have an effect in a compiled method that optimized field accesses based on EA? Currently memory optimizations can be observed, if the agent uses heap functions only to acquire a reference to the local object, which was not scalar replaced. ...and in the end hopefully an agreement :) 2a was discussed in the code review of JDK-8230677 [3]. David Holmes wished to generalize the discussion and to draw more attention to it to get answers we can rely on. Thanks, Richard. [1] https://bugs.openjdk.java.net/browse/JDK-8230677 [2] https://bugs.openjdk.java.net/browse/JDK-8230956 [3] Prev. discussion https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-September/029224.html
RE: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
Hi David, thanks for the discussion so far. I certainly learned from it. I'll start a new thread were I'll ask for comments on the relationship of JVMTI and optimizations, especially those based on EA. And thanks for your Review too. I'll wait until there's some feedback on the new thread. Richard. -Original Message- From: David Holmes Sent: Dienstag, 24. September 2019 02:17 To: Reingruber, Richard ; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken Hi Richard, On 24/09/2019 1:12 am, Reingruber, Richard wrote: > Hi David, > > The JVMTI documentation answers the question "What is the JVM Tool > Interface?" as follows > >"It provides both a way to inspect the state and to control the execution > of applications running >in the JavaTM virtual machine (VM)" > > So it's the state on the _virtual_ machine. You're placing a double-meaning on "virtual" there. The JVM is a "Java virtual machine". That doesn't equate to your 'abstract virtual machine' concept. > And then there's another section "Specification Context". I should have found > it before, but it is > the 16th section of the introduction. It should be the first, really. > >Specification Context > >Since this interface provides access to the state of applications running > in the Java virtual >machine; terminology refers to the Java platform and not the native > platform (unless stated >otherwise). For example: > >"thread" means Java programming language thread. >"stack frame" means Java virtual machine stack frame. >"class" means Java programming language class. >"heap" means Java virtual machine heap. >"monitor" means Java programming language object monitor. > > Based on this, in particular "...not the native platform...", I'd think we > can finally agree that it > is the state of the abstract virtual machine that's presented to JVMTI > clients. I think you're reading far too much into these words that are simply allowing for usage of simple terms, like thread, without having to constantly re-state whether it means "Java programming language thread" or "JVM native thread" or some other kind of thread. I'm not saying this isn't how it should work, I'm saying it needs to be established/confirmed how it should work. > I've answered more of your questions below. Responses below too. > Please let me know, if you think this needs more attention and discussion. If > so, I would like > to start a new thread, because this one won't have to many followers anymore > ;) I certainly think this needs more attention and discussion - even if it is just the compiler folk confirming "hey this is all fine, we missed a couple of cases ". That would set my mind at ease. I can see now that not all of the discussion has been cross-posted to the serviceability-dev list. > Is mailing list discussion the right format at all? It's the only medium we have available at present. > Richard. > >> > Hi David, >> > >> > I still think that JVMTI has to reflect the state of the abstract > virtual machine and it must hide >> > optimizations from its client (Joe the Java developer). >> >> I'm not sure I agree as a blanket statement. It may not be feasible to >> perform certain optimisations and at the same time keep around enough >> information to reconstruct the state as it would have been had the >> optimization not occurred. > > It is feasible. And it is done already at every safepoint in a nmethod to be > able to switch from > compiled to interpreted execution. Okay, so perhaps I am imagining scenarios that are actually impossible and things are much simpler in reality.. >> That's why I want to see a discussion of the >> broader issue of how something like escape analysis is supposed to >> interact with facilities like JVM TI. You've flagged a couple of >> conditions under which EA should be disabled, but are they sufficient? > > Well, I've created JDK-8227745. I claim it handles all EA issues. Vladimir > Kozlov suggested to > create separate bugs for cases when EA optimizations can be observed. That > makes sense to be. And > allows to downport the conservative (i.e. disabling EA) fixes. Okay. > >> Give they are both dynamic facilities what is suppose
RE: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
Hi David, The JVMTI documentation answers the question "What is the JVM Tool Interface?" as follows "It provides both a way to inspect the state and to control the execution of applications running in the JavaTM virtual machine (VM)" So it's the state on the _virtual_ machine. And then there's another section "Specification Context". I should have found it before, but it is the 16th section of the introduction. It should be the first, really. Specification Context Since this interface provides access to the state of applications running in the Java virtual machine; terminology refers to the Java platform and not the native platform (unless stated otherwise). For example: "thread" means Java programming language thread. "stack frame" means Java virtual machine stack frame. "class" means Java programming language class. "heap" means Java virtual machine heap. "monitor" means Java programming language object monitor. Based on this, in particular "...not the native platform...", I'd think we can finally agree that it is the state of the abstract virtual machine that's presented to JVMTI clients. I've answered more of your questions below. Please let me know, if you think this needs more attention and discussion. If so, I would like to start a new thread, because this one won't have to many followers anymore ;) Is mailing list discussion the right format at all? Richard. > > Hi David, > > > > I still think that JVMTI has to reflect the state of the abstract virtual machine and it must hide > > optimizations from its client (Joe the Java developer). > > I'm not sure I agree as a blanket statement. It may not be feasible to > perform certain optimisations and at the same time keep around enough > information to reconstruct the state as it would have been had the > optimization not occurred. It is feasible. And it is done already at every safepoint in a nmethod to be able to switch from compiled to interpreted execution. > That's why I want to see a discussion of the > broader issue of how something like escape analysis is supposed to > interact with facilities like JVM TI. You've flagged a couple of > conditions under which EA should be disabled, but are they sufficient? Well, I've created JDK-8227745. I claim it handles all EA issues. Vladimir Kozlov suggested to create separate bugs for cases when EA optimizations can be observed. That makes sense to be. And allows to downport the conservative (i.e. disabling EA) fixes. > Give they are both dynamic facilities what is supposed to happen if you > keep switching things on and off? Does enabling > can_get_owned_monitor_info require previous EA actions to be undone? can_get_owned_monitor_info is a capability that can be added only in the OnLoad phase, so nothing needs to be undone. can_tag_objects is dynamic (JDK-8230956), so disabling EA does not help in all cases. I have elaborated on this in the bug. With JDK-8227745, though, it does not matter how often the capability is added/removed. The EA base optimizations can be reverted as needed just-in-time. > I don't know the answers here. I certainly hope these questions have > been considered when EA was being developed - in which case I'd like to > see the discussion. Otherwise this is a conversation that needs to be > had, and the development of an overall approach for dealing with this, > not trying to address things piece-meal as someone recognises a new problem. > Specs are imperfect and always evolving. Sometimes the consequences of > specific optimizations may not be realised at the spec level yet need to > be accounted for. That may or may not be the case with EA. > > I find it hard to see how to do lock elision yet at the same time track > when the lock would have been taken, without negating the whole purpose > of eliding the lock. As stated above: this is done for deoptimization already. All tracking information is collected at compile time. There are no runtime costs, except size of debuginfo. JDK-8227745 does what deoptimization does: reallocating and relocking objects. Difference is that JDK-8227745 does it right before JVMTI access. Deoptimization does it when replacing a compiled frame by corresponding interpreted frames. -Original Message- From: David Holmes Sent: Montag, 23. September 2019 08:59 To: Reingruber, Richard ; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken Hi Richard, On 22/09/2019 7:06 am, Reingruber, Richard wrote: > Hi David, > > I still
RE: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
Hi David, I still think that JVMTI has to reflect the state of the abstract virtual machine and it must hide optimizations from its client (Joe the Java developer). There has to be a way to debug an app without optimizations getting into your way. I like to debug my C/C++ program after I compiled it -O0 -g. There has to be something equivalent for Java debugging. And I don't mean -Xint. Since 1.4.1 we've got "Full Speed Debugging" [1]. So far JVMTI does an excellent job of making optimizations transparent to the user. If it didn't, I would like to file a JEP for an interface that shows the pure JVM state (at full speed of course). > >> You seem to have completely missed my point. If the object is local and > >> is synchronized upon then the synchronization can be elided (and should > >> be) in which case it won't appear in GetOwnedMonitorInfo and so does not > >> escape. If the synchronization cannot be elided then the object cannot > >> be considered local. That is how Escape Analysis should be operating > >> here IMHO. > > > > I presume we agree that it is the state of the abstract virtual machine that must be observed > > through JVMTI, right? > > > > The locking state of an object O after a monitorenter on O is locked on the abstract vm. > > > > The JIT can still elide synchronization based on a prove that it is actually redundant for the > > computation. But at a safepoint JVMTI must report O as locked, because that's its state on the > > abstract virtual machine. > > I don't agree. If the locking can be elided then it is completely > elided. If the state of the "abstract VM" had to be perfectly preserved > then we wouldn't be able to do the optimisations referred to in JLS 12.6: > > "Optimizing transformations of a program can be designed that reduce the > number of objects that are reachable to be less than those which would > naively be considered reachable." I'd like to write a few words about the relationship of specification and optimizations: It's the purpose of a specification to define an abstract model. Optimizations are techniques employed by an implementation to reduce resource consumption for better performance within the bounds set by the spec, meaning optimizations have to be transparent to the program. You can't write a program that detects an optimization. If you could then the implementation would violate rules given by the specification. (And I don't consider a benchmark a prove.) Very rarely you'll find specs mention optimizations. You just don't want to mix specification and implementation! If they do, they trade beauty and simplicity of an abstract model, ideally based on formal definitions, for performance. They do mention an optimization, if it is impossible to hide it. In the case of JLS 12.6 it is possible to detect that an object reference is removed from a local variable by means of finalizations and java.lang.ref. Implementors wanted it so badly, though, that they changed the spec. Another example in the future could be tail-call-optimization ... > I place lock elision in the same category of "optimising > transformations" that changes what would "naively" be expected. Now this > should be explicitly covered in the JLS/JVMS somewhere but I'm having > trouble finding exactly where. This article discusses lock elision: > > https://www.ibm.com/developerworks/library/j-jtp10185/index.html > > and states: > > "It stands to reason, then, that if a thread enters a synchronized block > protected by a lock that no other thread will ever synchronize on, then > that synchronization has no effect and can therefore be removed by the > optimizer. (The Java Language Specification explicitly allows this > optimization.)" I doubt you'll find it in the JLS/JVMS. It's an implementation detail permitted by the memory model. That's what the article is saying. If a Java app has data races, then you would not reason about removed synchronization. You would argue with the means of the memory model: eg the synchronization action A1 (JLS 17.4.2 [2]) does not 'synchronized-with' (17.4.4 [3]) sync. action A2, so they are not ordered. > I'll have to ping Brian to see if he recalls exactly where this is > covered. :) Ok :) Please let me know! Richard. [1] https://docs.oracle.com/javase/8/docs/technotes/guides/jpda/enhancements1.4.html#fsd [2] https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.2 [3] https://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.4.4 ---
RE: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
Hi David, > >> You seem to have completely missed my point. If the object is local and > >> is synchronized upon then the synchronization can be elided (and should > >> be) in which case it won't appear in GetOwnedMonitorInfo and so does not > >> escape. If the synchronization cannot be elided then the object cannot > >> be considered local. That is how Escape Analysis should be operating > >> here IMHO. > > > > I presume we agree that it is the state of the abstract virtual machine that must be observed > > through JVMTI, right? > > > > The locking state of an object O after a monitorenter on O is locked on the abstract vm. > > > > The JIT can still elide synchronization based on a prove that it is actually redundant for the > > computation. But at a safepoint JVMTI must report O as locked, because that's its state on the > > abstract virtual machine. > > I don't agree. If the locking can be elided then it is completely > elided. If the state of the "abstract VM" had to be perfectly preserved > then we wouldn't be able to do the optimisations referred to in JLS 12.6: > > "Optimizing transformations of a program can be designed that reduce the > number of objects that are reachable to be less than those which would > naively be considered reachable." Interestingly this optimization is disabled, if a JVMTI agent can_access_local_variables. (see ciMethod::liveness_at_bci()) > I place lock elision in the same category of "optimising > transformations" that changes what would "naively" be expected. Now this > should be explicitly covered in the JLS/JVMS somewhere but I'm having > trouble finding exactly where. This article discusses lock elision: > > https://www.ibm.com/developerworks/library/j-jtp10185/index.html > > and states: > > "It stands to reason, then, that if a thread enters a synchronized block > protected by a lock that no other thread will ever synchronize on, then > that synchronization has no effect and can therefore be removed by the > optimizer. (The Java Language Specification explicitly allows this > optimization.)" > > I'll have to ping Brian to see if he recalls exactly where this is > covered. :) In the formal specification of the memory model, I'd guess. Can be confusing, though, if you see in your debugger, that your object gets locked (interpreted), then its not locked (compiled) and then in the same activation suddenly locked, because an uncommon trap was hit. Thanks and a good weekend to you! - Actually to every reader :) Richard. -Original Message- From: David Holmes Sent: Freitag, 20. September 2019 11:07 To: Reingruber, Richard ; hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken Hi Richard, On 20/09/2019 6:31 pm, Reingruber, Richard wrote: > Hi David, > >> On 20/09/2019 2:42 am, Reingruber, Richard wrote: >> > Hi David, >> > >> > thanks for looking at this issue. And my appologies for the lengthy > mail... >> > >> >> > The JVMTI functions GetOwnedMonitorInfo() and > GetOwnedMonitorStackDepthInfo() can be used to >> >> > retrieve objects locked by a thread. In terms of escape > analysis those references escape and >> >> > optimizations like scalar replacement become invalid. >> >> >> >> What bothers me about this is that it seems like escape analysis > is >> >> doing something wrong in this case. >> > >> > Yes it is. >> > >> >> If the object is thread-local but is >> >> being synchronized upon then either: >> > >> > The object is not local, because it can escape through JVMTI > GetOwnedMonitorInfo(). Escape analysis >> > does not recognize this. That's what it is doing wrong. Consequently > the state of the virtual >> > machine, as observed through JVMTI, is wrong. See below... >> >> You seem to have completely missed my point. If the object is local and >> is synchronized upon then the synchronization can be elided (and should >> be) in which case it won't appear in GetOwnedMonitorInfo and so does not >> escape. If the synchronization cannot be elided then the object cannot >> be considered local. That is h
RE: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
Hi David,
> On 20/09/2019 2:42 am, Reingruber, Richard wrote:
> > Hi David,
> >
> > thanks for looking at this issue. And my appologies for the lengthy
mail...
> >
> >> > The JVMTI functions GetOwnedMonitorInfo() and
GetOwnedMonitorStackDepthInfo() can be used to
> >> > retrieve objects locked by a thread. In terms of escape analysis
those references escape and
> >> > optimizations like scalar replacement become invalid.
> >>
> >> What bothers me about this is that it seems like escape analysis is
> >> doing something wrong in this case.
> >
> > Yes it is.
> >
> >> If the object is thread-local but is
> >> being synchronized upon then either:
> >
> > The object is not local, because it can escape through JVMTI
GetOwnedMonitorInfo(). Escape analysis
> > does not recognize this. That's what it is doing wrong. Consequently the
state of the virtual
> > machine, as observed through JVMTI, is wrong. See below...
>
> You seem to have completely missed my point. If the object is local and
> is synchronized upon then the synchronization can be elided (and should
> be) in which case it won't appear in GetOwnedMonitorInfo and so does not
> escape. If the synchronization cannot be elided then the object cannot
> be considered local. That is how Escape Analysis should be operating
> here IMHO.
I presume we agree that it is the state of the abstract virtual machine that
must be observed
through JVMTI, right?
The locking state of an object O after a monitorenter on O is locked on the
abstract vm.
The JIT can still elide synchronization based on a prove that it is actually
redundant for the
computation. But at a safepoint JVMTI must report O as locked, because that's
its state on the
abstract virtual machine.
Cheers, Richard.
-Original Message-
From: David Holmes
Sent: Freitag, 20. September 2019 00:59
To: Reingruber, Richard ;
hotspot-compiler-...@openjdk.java.net; serviceability-dev@openjdk.java.net
Subject: Re: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability
can_get_owned_monitor_info was taken
On 20/09/2019 2:42 am, Reingruber, Richard wrote:
> Hi David,
>
> thanks for looking at this issue. And my appologies for the lengthy mail...
>
>> > The JVMTI functions GetOwnedMonitorInfo() and
> GetOwnedMonitorStackDepthInfo() can be used to
>> > retrieve objects locked by a thread. In terms of escape analysis those
> references escape and
>> > optimizations like scalar replacement become invalid.
>>
>> What bothers me about this is that it seems like escape analysis is
>> doing something wrong in this case.
>
> Yes it is.
>
>> If the object is thread-local but is
>> being synchronized upon then either:
>
> The object is not local, because it can escape through JVMTI
> GetOwnedMonitorInfo(). Escape analysis
> does not recognize this. That's what it is doing wrong. Consequently the
> state of the virtual
> machine, as observed through JVMTI, is wrong. See below...
You seem to have completely missed my point. If the object is local and
is synchronized upon then the synchronization can be elided (and should
be) in which case it won't appear in GetOwnedMonitorInfo and so does not
escape. If the synchronization cannot be elided then the object cannot
be considered local. That is how Escape Analysis should be operating
here IMHO.
Cheers,
David
-
>> a) the synchronization is elided and so the object will not appear in
>> the set of owned monitors; or
>> b) the fact synchronization occurs renders the object ineligible to be
>> considered thread-local, and so there is no problem with it appearing in
>> the set of owned monitors
>>
>> I think there is a bigger design philosophy issue here about the
>> interaction of escape analysis and debugging/management frameworks in
>> general. I'd like to see a very clear description on exactly how they
>> should interact.
>>
>
> I don't see too many design alternatives here. The JVMTI implementation has
> to present the correct
> state of the virtual machine according to the spec. I think it fails to do so
> in this case.
>
> Please look again at the test:
>
> 172 public long dontinline_endlessLoop() {
> 173 long cs = checkSum;
> 174 while (doLoop && loopCount-- > 0) {
> 175 targetIsInLoop = true;
> 176 checkSum += checkSum % ++cs;
> 177 }
>
RE: RFR(S) 8230677: Should disable Escape Analysis if JVMTI capability can_get_owned_monitor_info was taken
Hi David,
thanks for looking at this issue. And my appologies for the lengthy mail...
> > The JVMTI functions GetOwnedMonitorInfo() and
GetOwnedMonitorStackDepthInfo() can be used to
> > retrieve objects locked by a thread. In terms of escape analysis those
references escape and
> > optimizations like scalar replacement become invalid.
>
> What bothers me about this is that it seems like escape analysis is
> doing something wrong in this case.
Yes it is.
> If the object is thread-local but is
> being synchronized upon then either:
The object is not local, because it can escape through JVMTI
GetOwnedMonitorInfo(). Escape analysis
does not recognize this. That's what it is doing wrong. Consequently the state
of the virtual
machine, as observed through JVMTI, is wrong. See below...
> a) the synchronization is elided and so the object will not appear in
> the set of owned monitors; or
> b) the fact synchronization occurs renders the object ineligible to be
> considered thread-local, and so there is no problem with it appearing in
> the set of owned monitors
>
> I think there is a bigger design philosophy issue here about the
> interaction of escape analysis and debugging/management frameworks in
> general. I'd like to see a very clear description on exactly how they
> should interact.
>
I don't see too many design alternatives here. The JVMTI implementation has to
present the correct
state of the virtual machine according to the spec. I think it fails to do so
in this case.
Please look again at the test:
172 public long dontinline_endlessLoop() {
173 long cs = checkSum;
174 while (doLoop && loopCount-- > 0) {
175 targetIsInLoop = true;
176 checkSum += checkSum % ++cs;
177 }
178 loopCount = 3;
179 targetIsInLoop = false;
180 return checkSum;
181 }
249 public void dontinline_testMethod() {
250 LockCls l1 = new LockCls();// to be scalar replaced
251 synchronized (l1) {
252 inlinedTestMethodWithNestedLocking(l1);
253 }
254 }
255
256 public void inlinedTestMethodWithNestedLocking(LockCls l1) {
257 synchronized (l1) { // nested
258 dontinline_endlessLoop();
259 }
260 }
This is the stack when the agent calls GetOwnedMonitorInfo()
dontinline_endlessLoop()at line 176
inlinedTestMethodWithNestedLocking()at line 258 // inlined into caller
frame
dontinline_testMethod() at line 252 // compiled frame
The state of the _virtual_ machine at that point is obvious:
- An instance of LockCls must exist. It was allocated by a new bytecode at line
250.
- That instance was locked by a monitorenter bytecode at line 251
This could be proven by interpreting the execution trace bytecode by bytecode
using paper and
pencil (hope you won't make me do this, though ;))
JVMTI is used to examine the state of the virtual machine. The result of the
JVMTI call
GetOwnedMonitorInfo() must include that locked instance of LockCls. It is
obviously a bug if it does
not.
From a more philosophical point of view compiled code is free to change the
state of the physical
machine in a way such that it cannot be mapped to a valid state of the virtual
machine after each
and every machine instruction. But it must reach points in its execution trace,
where it is actually
possible to present a valid state of the virtual machine to observers, e.g.
JVMTI agents. These
points are called safepoints.
The test is a prove that compiled code fails to do so, as it reaches a
safepoint where an invalid vm
state is presented. EA does not take into account that the lock state can be
observed using
GetOwnedMonitorInfo(). As a fix EA is disabled if the corresponding capability
can_get_owned_monitor_info is taken. With the fix the test passes.
Note that for the very same reason EA is disabled if can_access_local_variables
is taken, because
the JVMTI implementation cannot handout references to objects stored in local
variables if they were
scalar replaced.
With the proposed enhancement JDK-8227745 it is not necessary to disable EA. It
allows to revert EA
based optimizations just-in-time before local objects escape. Note that EA opts
are already reverted
today if a compiled frame gets replaced by corresponding interpreted frames
(see realloc_objects()
and relock_objects() in class Deoptimization)
Thanks and cheers, Richard.
[1] https://bugs.openjdk.java.net/browse/JDK-8227745
-Original Message-
From: David Holmes
Sent: Donnerstag, 19. September 2019 02:43
To: Reingruber, Richard ;
hotspot-compiler-...@openjdk.java.net; serviceability-dev
RFR(S) 8230956: Should disable Escape Analysis when JVMTI capability can_tag_objects is taken
Hi, could I please get reviews for Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8230956/webrev.0/ Bug:https://bugs.openjdk.java.net/browse/JDK-8230956 JVMTI provides functions to follow references beginning at the roots of the object graph and it provides functions to iterate all objects on the heap[1][2]. These functions are means to access objects which are otherwise local to a Java thread. In terms of escape analysis these local objects escape through these JVMTI functions invalidating optimizations based on escape analysis. Example: - Let J be a JavaThread that calls a compiled method M with a NoEscape instance I of class C that is scalar replaced. - JVMTI agent A uses JVMTI FollowReferences() to iterate the objects in the object graph tagging all instances of C. - A uses GetObjectsWithTags() to retrieve the tagged instances of C. - Error: I is missing because its allocation was eliminated / scalar replaced. Agents are required to possess the capability can_tag_objects in order to call the JVMTI heap functions that let objects escape. Currently it is not possible to revert EA based optimizations just before objects escape through JVMTI therefore escape analysis should be disabled as soon as the JVMTI capability can_tag_objects is taken. But this is not sufficient, because there may be compiled frames on stack with EA based optimizations when a JVMTI agent takes can_tag_objects (see included exclusive test cases), and then it does not help to disable escape analysis or invalidate compiled methods with ea based optimizations. In general it is still an improvement to do so. JDK-8227745 would be a complete solution to the issue. An further improvement could be to invalidate methods compiled by c2 when can_tag_objects gets added, but I'd rather suggest to integrated the implementation for JDK-8227745. Note also that after calling JVMTI AddCapabilities(), even with an empty set of capabilities, JvmtiExport::can_walk_any_space() will return true. I've run tier1 tests. Thanks, Richard. [1] https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#Heap [2] https://docs.oracle.com/en/java/javase/11/docs/specs/jvmti.html#Heap_1_0
RE: RFR: JDK-8192057: com/sun/jdi/BadHandshakeTest.java fails with java.net.ConnectException
Hi Alex,
thanks, the change looks good.
Best regards, Richard.
-Original Message-
From: Alex Menkov
Sent: Dienstag, 10. September 2019 22:33
To: Reingruber, Richard ;
serguei.spit...@oracle.com; OpenJDK Serviceability
Subject: Re: RFR: JDK-8192057: com/sun/jdi/BadHandshakeTest.java fails with
java.net.ConnectException
Hi Richard,
Updated webrev:
http://cr.openjdk.java.net/~amenkov/jdk14/BadHandshakeTest/webrev.2/
added delay between retries & moved error clearing to the beginning of
the cycle.
--alex
On 09/09/2019 02:07, Reingruber, Richard wrote:
> Hi Alex,
>
>> Of course error can be cleared before each try - there is not functional
>> difference.
>
> It is just a little confusing, as you can get an exception in L. 95, too. But
> I'm ok with it, if you
> prefer it like this.
>
> I would suggest, though, to sleep some ms before a retry and double the sleep
> time in each
> following retry.
>
> Best regards,
> Richard.
>
> -Original Message-
> From: Alex Menkov
> Sent: Freitag, 6. September 2019 22:52
> To: Reingruber, Richard ;
> serguei.spit...@oracle.com; OpenJDK Serviceability
>
> Subject: Re: RFR: JDK-8192057: com/sun/jdi/BadHandshakeTest.java fails with
> java.net.ConnectException
>
> Hi Richard,
>
> On 09/06/2019 09:28, Reingruber, Richard wrote:
>> Hi Alex,
>>
>> that's a good fix for the issue.
>>
>> One minor thing:
>>
>> 89 Exception error = null;
>> 90 for (int retry = 0; retry < 5; retry++) {
>> 91 try {
>> 92 log("retry: " + retry);
>> 93 s = new Socket("localhost", port);
>> 94 error = null;
>> 95
>> s.getOutputStream().write("JDWP-".getBytes("UTF-8"));
>> 96 break;
>> 97 } catch (ConnectException ex) {
>> 98 log("got exception: " + ex.toString());
>> 99 error = ex;
>>100 }
>>101 }
>>102 if (error != null) {
>>103 throw error;
>>104 }
>>
>> Is there a reason to clear the local variable error in line 94 instead of
>> clearing it
>> in line 91 where each new attempt begins?
>
> The logic here is:
> The cycle has 2 exits:
> - error (max retry attempts reached, error is set by last "catch")
> - success ("break" statement at line 96, error should be null)
> So error is cleared only after the socket is connected (this is the
> problematic operation which can cause ConnectException).
>
> Of course error can be cleared before each try - there is not functional
> difference.
>
> --alex
>
>>
>> Cheers, Richard.
>>
>> -Original Message-
>> From: serviceability-dev On
>> Behalf Of serguei.spit...@oracle.com
>> Sent: Mittwoch, 4. September 2019 22:11
>> To: Alex Menkov ; OpenJDK Serviceability
>>
>> Subject: Re: RFR: JDK-8192057: com/sun/jdi/BadHandshakeTest.java fails with
>> java.net.ConnectException
>>
>> Hi Alex,
>>
>> The fix looks good.
>> Good simplification!
>>
>> Thanks,
>> Serguei
>>
>>
>> On 9/4/19 12:19, Alex Menkov wrote:
>>> Hi all,
>>>
>>> Please review the fix for BadHandshakeTest test.
>>> The problem is the test connects to the server twice and if debuggee
>>> hasn't yet handled disconnection, the next connect gets "connection
>>> refused" error.
>>> Instead of adding delay before 2nd connect (we never know "good" value
>>> for the delay and big delay can cause "accept timeout"), the test
>>> re-tries connect in case of ConnectException.
>>> Also improved/simplified the test slightly - debuggee is now run with
>>> auto port assignment (used lib.jdb.Debuggee test class which
>>> implements required functionality).
>>>
>>> jira:
>>> https://bugs.openjdk.java.net/browse/JDK-8192057
>>> webrev:
>>> http://cr.openjdk.java.net/~amenkov/jdk14/BadHandshakeTest/webrev/
>>>
>>> --alex
>>
