From dean.long at oracle.com Tue Oct 1 06:11:58 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 30 Sep 2019 23:11:58 -0700 Subject: RFR/RFC 8231503: [TESTBUG] compiler/{jvmci, aot} tests should not run with GCs that do not support JVMCI/AOT In-Reply-To: References: <1873f335-86ba-2d37-1644-1ecc94346507@redhat.com> <96f76c08-cc56-027b-6f4b-4a6b827b3238@redhat.com> Message-ID: <7210b2ef-9d64-885f-9ac4-45f2dfc52db3@oracle.com> OK, thanks for explaining that.? The JVM doesn't provide a way to query which flags are available, so the methods in VMProps.java are doing it instead, and you just made them a little smarter.? Your fix looks good to me. dl On 9/30/19 12:50 AM, Aleksey Shipilev wrote: > On 9/27/19 8:52 PM, dean.long at oracle.com wrote: >> If some GCs don't support JVMCI/AOT, maybe we should turn off the EnableJVMCI and UseAOT flags. >> Wouldn't that prevent the tests from running? > I believe there is a circularity in reasoning there. Tests would enable +UseAOT or +UseJVMCI after > they get clear through @requires, and then everything goes boom. VMProps set "vm.aot" and "vm.jvmci" > sensing the presence of jaotc and the _availability_ of UseJVMCI flag. And it is too early to sense > if @run would set +UseAOT or +UseJVMCI. > > This explains why tests still fail with Shenandoah that *does* turn off UseAOT. It does not help, > because it happens too late, and tests fail. > > I believe the only way to disallow tests to run is proper @requires. The question is how exactly to > spell it: dropping "vm.aot"/"vm.jvmci" to "false" when unsupported GC is selected (like this patch > is doing), or do explicit @requires for every test listing every compatible GC. > From shade at redhat.com Tue Oct 1 07:12:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Oct 2019 09:12:34 +0200 Subject: RFR/RFC 8231503: [TESTBUG] compiler/{jvmci, aot} tests should not run with GCs that do not support JVMCI/AOT In-Reply-To: References: <1873f335-86ba-2d37-1644-1ecc94346507@redhat.com> <96f76c08-cc56-027b-6f4b-4a6b827b3238@redhat.com> <2ead05f5-b8ca-44ee-02a5-22d4963c1fa5@oracle.com> <6bad3715-78e0-1357-a03f-15c35979fafb@oracle.com> Message-ID: <089cb936-4d3b-e39d-e780-506eea4fceb7@redhat.com> On 9/30/19 9:46 PM, Vladimir Kozlov wrote: > Looks good for me. jdk-submit came clean, so I will be pushing it shortly. -- Thanks, -Aleksey From christian.hagedorn at oracle.com Tue Oct 1 08:30:16 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Tue, 1 Oct 2019 10:30:16 +0200 Subject: [14] RFR(XS): 8231626: DeoptimizeRandom should not be a product flag Message-ID: Hi Please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8231626 http://cr.openjdk.java.net/~chagedorn/8231626/webrev.00/ The corresponding CSR [1] is still in process. Once reviewed, I'll wait with pushing the fix until the CSR is approved. Thank you! Best regards, Christian [1] https://bugs.openjdk.java.net/browse/JDK-8231664 From stefan.karlsson at oracle.com Tue Oct 1 08:43:57 2019 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Tue, 1 Oct 2019 10:43:57 +0200 Subject: RFR/RFC 8231503: [TESTBUG] compiler/{jvmci, aot} tests should not run with GCs that do not support JVMCI/AOT In-Reply-To: <6bad3715-78e0-1357-a03f-15c35979fafb@oracle.com> References: <1873f335-86ba-2d37-1644-1ecc94346507@redhat.com> <96f76c08-cc56-027b-6f4b-4a6b827b3238@redhat.com> <2ead05f5-b8ca-44ee-02a5-22d4963c1fa5@oracle.com> <6bad3715-78e0-1357-a03f-15c35979fafb@oracle.com> Message-ID: Hi Vladimir, Thanks for the clarification! I do find this odd and sense a kind of false abstraction here, but I'm not going to push for a change in this area. I'm happy that it's going to be easier to run ZGC tests locally with this change. Thanks, StefanK On 2019-09-30 19:51, Vladimir Kozlov wrote: > -XX:-UseJVMCICompiler is used explicitly to run Graal's unit tests to > compare results with C2. Without it Graal will be loaded and used > instead of C2 by default if +UseJVMCI is specified. These unit tests > should not run with not support GCs. > > I don't think we should modify check in > JVMCIGlobals::check_jvmci_supported_gc(). > > I am fine with proposed changes in VMProps.java and I agree that JVMCI > and AOT may have different GCs support even so currently they match. > > Thanks, > Vladimir > > On 9/30/19 6:27 AM, Stefan Karlsson wrote: >> [I wrote this before realizing that the mail thread had forked. Some >> of the comments might have already been covered] >> >> Hi Aleksey, >> >> Thanks for fixing this! >> >> Inlined: >> >> On 2019-09-27 17:26, Aleksey Shipilev wrote: >>> Replying with proper "To:". Friday, eh. >>> >>> On 9/27/19 5:23 PM, Aleksey Shipilev wrote: >>>> Testbug: >>>> ?? https://bugs.openjdk.java.net/browse/JDK-8231503 >>>> >>>> Candidate fix: >>>> ?? https://cr.openjdk.java.net/~shade/8231503/webrev.01/ >> >> One suggestion would be to rewrite the GC checking to use the enum >> values instead of string compares: >> >> ???????? switch (GC.selected()) { >> ???????????? case Serial: >> ???????????? case Parallel: >> ???????????? case G1: >> ???????????????? // These GCs are supported with AOT >> ???????????????? return "true"; >> ???????????? default: >> ???????????????? // Every other GC is not supported >> ???????????????? return "false"; >> ???????? } >> >> >> Maybe even create a function that returns a boolean. >> >>>> >>>> I am actually not sure it should be fixed this way. The alternative >>>> is to add the @requires lines to >>>> every affected test (there are about a hundred of them), like this: >>>> ?? @requires (vm.gc == "null" || vm.gc == "G1" || vm.gc = "Serial" >>>> || vm.gc = "Parallel") >>>> >>>> ...but that seems too intrusive. Or maybe not? Open for opinions >>>> from those who maintain JVMCI/AOT. >> >> I would also be interested in hearing what the JVMCI/AOT maintainers >> think. >> >> Isn't it odd that we prevent these tests from being run when JVMCI is >> enabled? Shouldn't we only skip the tests when an unsupported compiler >> is used? For all practical purposes that would be when Graal is used. >> >> A lot of the tests are run with -XX:-UseJVMCICompiler and it's not >> obvious to me that those have to be excluded when running with ZGC or >> Shenandoah. >> >> I think there might be a bug in check_jvmci_supported_gc and that we >> probably should change this to: >> --- >> diff --git a/src/hotspot/share/jvmci/jvmci_globals.cpp >> b/src/hotspot/share/jvmci/jvmci_globals.cpp >> --- a/src/hotspot/share/jvmci/jvmci_globals.cpp >> +++ b/src/hotspot/share/jvmci/jvmci_globals.cpp >> @@ -123,7 +123,7 @@ >> ??} >> >> ??void JVMCIGlobals::check_jvmci_supported_gc() { >> -? if (EnableJVMCI) { >> +? if (EnableJVMCI && UseJVMCICompiler) { >> ????? // Check if selected GC is supported by JVMCI and Java compiler >> ????? if (!(UseSerialGC || UseParallelGC || UseParallelOldGC || >> UseG1GC)) { >> ??????? vm_exit_during_initialization("JVMCI Compiler does not support >> selected GC", GCConfig::hs_err_name()); >> --- >> >> I tested this with ZGC (without your patch) and ran the tests in >> test/hotspot/jtreg/compiler/jvmci. 90% of the tests passed, some of >> the tests failed (as expected) because they actually ran with >> -XX:+UseJVMCICompiler, and some (unexpectedly) crashed with >> -XX:-UseJVMCICompiler. The latter might be a real bug in the JVMCI API. >> >> With all this said, maybe we should: >> >> 0) Add your "gc supports graal" checks to a new helper function >> (selectedGCSupportsGraal() ?). >> 1) Use the UseJVCMICompiler patch above >> 2) Leave the vmJvmci function as is >> 3) Tag tests actually requiring graal with vm.graal.enabled >> 4) Maybe change @requires vm.aot to to use vm.aot.enabled >> 5) Use this function to implement vm.graal.enabled and vm.aot.enabled >> >> Of course, I could have misunderstood the meaning of >> -XX:-UseJVMCICompiler, but then it would be good to get some >> clarification about that. >> >> Also, if you are in a hurry to get this resolved, then we could >> consider making these changes after your patch has been pushed. >> >> Thanks, >> StefanK >> >>>> >>>> Testing: compiler/aot, compiler/jvmci {serial, parallel, g1, >>>> shenandoah, zgc}; tier1 >>> From rwestrel at redhat.com Tue Oct 1 08:44:48 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 01 Oct 2019 10:44:48 +0200 Subject: RFR(T) 8231665: 8231055 broke escapeAnalysis/TestSelfArrayCopy.java Message-ID: <87o8z04zy7.fsf@redhat.com> http://cr.openjdk.java.net/~roland/8231665/webrev.00/ With 8231055, I pushed a change to an existing test case (and a new test case) that causes no compilation to occur because of a wrong compile command. Roland. From tobias.hartmann at oracle.com Tue Oct 1 08:48:19 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 1 Oct 2019 10:48:19 +0200 Subject: RFR(T) 8231665: 8231055 broke escapeAnalysis/TestSelfArrayCopy.java In-Reply-To: <87o8z04zy7.fsf@redhat.com> References: <87o8z04zy7.fsf@redhat.com> Message-ID: <308bae1c-6ce0-4aa1-13a4-335cdb8614ea@oracle.com> Hi Roland, looks good and trivial. Best regards, Tobias On 01.10.19 10:44, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8231665/webrev.00/ > > With 8231055, I pushed a change to an existing test case (and a new test > case) that causes no compilation to occur because of a wrong compile > command. > > Roland. > From yasuenag at gmail.com Tue Oct 1 08:57:36 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Tue, 1 Oct 2019 17:57:36 +0900 Subject: RFR: 8231659: [JVMCI] Could not work PrintAssembly for JVMCI installed code Message-ID: <8ee7143a-15cb-5761-528c-c5fa687d89f3@gmail.com> Hi all, Please review this change. JBS: https://bugs.openjdk.java.net/browse/JDK-8231659 webrev: https://cr.openjdk.java.net/~ysuenaga/JDK-8231659/webrev.00/ PrintAssembly would work in twice for JVMCI installed code before, so I fixed it in JDK-8180601. However PrintAseembly would not work for them in JDK 13 or later. It seems due to JDK-8220623. JDK-8220623 lacks print_nmethod() call. Thus I revert JDK-8180601 to work PrintAssembly. From tobias.hartmann at oracle.com Tue Oct 1 09:04:49 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 1 Oct 2019 11:04:49 +0200 Subject: [14] RFR(XS): 8231626: DeoptimizeRandom should not be a product flag In-Reply-To: References: Message-ID: Hi Christian, looks good. Best regards, Tobias On 01.10.19 10:30, Christian Hagedorn wrote: > Hi > > Please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8231626 > http://cr.openjdk.java.net/~chagedorn/8231626/webrev.00/ > > The corresponding CSR [1] is still in process. Once reviewed, I'll wait with pushing the fix until > the CSR is approved. > > Thank you! > > Best regards, > Christian > > > [1] https://bugs.openjdk.java.net/browse/JDK-8231664 From nils.eliasson at oracle.com Tue Oct 1 09:57:52 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 1 Oct 2019 11:57:52 +0200 Subject: [14] RFR(XS): 8231626: DeoptimizeRandom should not be a product flag In-Reply-To: References: Message-ID: <2cfe9c46-fcb0-8554-391d-8bf2d44eb7fc@oracle.com> Hi Christian, Looks good, Regards, Nils On 2019-10-01 10:30, Christian Hagedorn wrote: > Hi > > Please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8231626 > http://cr.openjdk.java.net/~chagedorn/8231626/webrev.00/ > > The corresponding CSR [1] is still in process. Once reviewed, I'll > wait with pushing the fix until the CSR is approved. > > Thank you! > > Best regards, > Christian > > > [1] https://bugs.openjdk.java.net/browse/JDK-8231664 From dms at samersoff.net Tue Oct 1 11:01:16 2019 From: dms at samersoff.net (Dmitry Samersoff) Date: Tue, 1 Oct 2019 14:01:16 +0300 Subject: RFR/RFC 8231503: [TESTBUG] compiler/{jvmci, aot} tests should not run with GCs that do not support JVMCI/AOT In-Reply-To: References: <1873f335-86ba-2d37-1644-1ecc94346507@redhat.com> <96f76c08-cc56-027b-6f4b-4a6b827b3238@redhat.com> <838116ae-fcd7-da5c-3035-e37dd59066c4@samersoff.net> Message-ID: <942e0812-4267-f581-b7e7-41c36502b972@samersoff.net> Aleksey, > I don't think new flag wins us anything? I believe most of the tests > would then be: > @requires vm.aot & vm.aot_compatible_gc This combination gives to a Maintainer a clear point of what should be checked if the test doesn't run. -Dmitry On 30.09.19 11:27, Aleksey Shipilev wrote: > On 9/30/19 10:22 AM, Dmitry Samersoff wrote: >> Updating all tests with long @require (and maintain it in the future) >> can be a painful task. >> >> One of possible option is to introduce vm.aot_compatible_gc and update >> @require to use this new flag. > > I don't think new flag wins us anything? I believe most of the tests would then be: > @requires vm.aot & vm.aot_compatible_gc > > ...which suggests we should be "just" setting the vm.aot properly? > >> But, if you finally go to the simple way that is shown in candidate >> webrev, please factor out GC selection logic into a separate function, >> to have it in one place. > > I thought about it when doing the candidate patch. Are we sure that GC support of AOT and JVMCI is > symmetrical? I.e. if GC supports JVMCI, is it guaranteed to support AOT, and vice versa? If not, the > selection logic should remain separate. > From rwestrel at redhat.com Tue Oct 1 12:45:31 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 01 Oct 2019 14:45:31 +0200 Subject: RFR(T) 8231665: 8231055 broke escapeAnalysis/TestSelfArrayCopy.java In-Reply-To: <308bae1c-6ce0-4aa1-13a4-335cdb8614ea@oracle.com> References: <87o8z04zy7.fsf@redhat.com> <308bae1c-6ce0-4aa1-13a4-335cdb8614ea@oracle.com> Message-ID: <87imp84ot0.fsf@redhat.com> Thanks for the review, Tobias. Roland. From shade at redhat.com Tue Oct 1 15:16:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 1 Oct 2019 17:16:25 +0200 Subject: RFR/RFC 8231503: [TESTBUG] compiler/{jvmci, aot} tests should not run with GCs that do not support JVMCI/AOT In-Reply-To: <942e0812-4267-f581-b7e7-41c36502b972@samersoff.net> References: <1873f335-86ba-2d37-1644-1ecc94346507@redhat.com> <96f76c08-cc56-027b-6f4b-4a6b827b3238@redhat.com> <838116ae-fcd7-da5c-3035-e37dd59066c4@samersoff.net> <942e0812-4267-f581-b7e7-41c36502b972@samersoff.net> Message-ID: <9bd7867f-fbc2-e4d9-2c26-8a40c548e71c@redhat.com> On 10/1/19 1:01 PM, Dmitry Samersoff wrote: >> I don't think new flag wins us anything? I believe most of the tests >> would then be: >> @requires vm.aot & vm.aot_compatible_gc > > This combination gives to a Maintainer a clear point of what should be > checked if the test doesn't run. Already pushed, sorry. But, in the same way, Maintainer would check the definition for vm.aot flag. It does not make sense to me to always carry two flags for every test. I would think it is even greater headache for maintenance to always remember @require-ing two flags. -- Thanks, -Aleksey From nils.eliasson at oracle.com Tue Oct 1 19:13:05 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 1 Oct 2019 21:13:05 +0200 Subject: 8226721: Missing intrinsics for Math.ceil, floor, rint In-Reply-To: References: Message-ID: <674e3acb-5bba-0d33-f45e-e8245f6847f2@oracle.com> Hi Jatin, Your patch is pushed. Thanks for contributing! Best regards, Nils On 2019-09-03 11:41, Bhateja, Jatin wrote: > Hi All, > > Please find a patch with the following changes:- > 1) Intrincifiation for Math.ceil/floor/rint. > 2) Auto-vectorizer handling. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8226721 > Webrev: http://cr.openjdk.java.net/~jbhateja/8226721/webrev.05 > > Kindly review it. > > Best Regards, > Jatin From vivek.r.deshpande at intel.com Tue Oct 1 23:36:56 2019 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Tue, 1 Oct 2019 23:36:56 +0000 Subject: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB731EE6@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> Hi Vladimir I have updated the patch with appropriate comments in globals_x86.hpp and also updated the bug entry. The updated webrev is here: http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.01/ Could you please review. Regards, Vivek -----Original Message----- From: Deshpande, Vivek R Sent: Thursday, September 26, 2019 10:52 AM To: Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net Cc: Scott Oaks ; eric.caspole ; Robert Strout Subject: RE: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors Thanks you Vladimir for the review. I will work on the adding the comments and changes to the bug report. Yes the threshold is for architectures after skylake which support AVX512. With this threshold( value = 4096 bytes found experimentally), AVX512 will be used if the array size is bigger than that. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, September 25, 2019 12:41 PM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net Cc: Scott Oaks ; eric.caspole ; Robert Strout Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors Thank you, Vivek I see you did several changes including intrinsics code. Would be nice if you list changes you did in bug report. I see you removed _evex instructions variants in .ad file, replaced evex instructions in stubs and set UseAVX to 2 for Skylake. It is easy to understand. But what about array limit AVX3Threshold? I assume it is for non-Skylake CPUs with AVX512. Right? What number 4096 is based on. It seems AVX3Threshold == 0 has special meaning - add line in globals_x86.hpp explaining it. I would need more time to look on related changes. Thanks, Vladimir On 9/3/19 5:02 PM, Deshpande, Vivek R wrote: > Hi All > > I have created a patch which sets AVX2 for Skylake and selectively > uses EVEX instructions based on threshold for platforms after Skylake. > I don't observe the regressions for SPECjvm2008 on Skylake with this patch. > JBS id: > https://bugs.openjdk.java.net/browse/JDK-8221092 > Webrev: > http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.00/ > Could you all please review the patch. > > Regards, > Vivek > From HORIE at jp.ibm.com Wed Oct 2 04:27:03 2019 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 2 Oct 2019 13:27:03 +0900 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Message-ID: Dear all, Would you please review the following change? Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on top of 8226721: Missing intrinsics for Math.ceil, floor, rint. Best regards, Michihiro From rwestrel at redhat.com Wed Oct 2 07:34:29 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 02 Oct 2019 09:34:29 +0200 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode Message-ID: <87ftkb4n3u.fsf@redhat.com> http://cr.openjdk.java.net/~roland/8231620/webrev.00/ In test1() of the regression test, the loop is unswitched. Once it is there are 2 Lock nodes but a single shared FastLock node. Split if then happens with the shared FastLock between the If to be split and the dominating Region. C2 then crashes in PhaseIdealLoop::split_up() because the pattern with the FastLock is unhandled there. merge_point_safe() checks for a FastLock node and it is expected to prevent split if when that pattern is encountered. But in the case test1(), There's a CastPP between the Phi and the FastLock. test2() of the regression test is similar except that, instead of a CastPP, a load node is between the Phi and the FastLock. That one crashes the same way but only on 32 bits because a ConvI2L prevents split if on 64 bits. Rather than try to fix merge_point_safe() to handle every node that can be in between the FastLock and the Phi, I propose handling FastLock nodes in PhaseIdealLoop::split_up() which is AFAICT straightforward. Roland. From shade at redhat.com Wed Oct 2 08:50:32 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 2 Oct 2019 10:50:32 +0200 Subject: RFR (XS) 8231713: x86_32 build failures after JDK-8226721 (Missing intrinsics for Math.ceil, floor, rint) Message-ID: <6e34ae48-4c16-6223-73ef-9ec24c4a9a80@redhat.com> Bug: https://bugs.openjdk.java.net/browse/JDK-8231713 Fix: https://cr.openjdk.java.net/~shade/8231713/webrev.01/ I actually tried to define the missing operand declarations in x86_32.ad, but that quickly leads to conflicts. So, I opted to disable the parts of 8226721 for x86_32. Testing: test from 8226721, {x86_32, x86_64} hotspot_compiler, jdk-submit (running) -- Thanks, -Aleksey From sgehwolf at redhat.com Wed Oct 2 10:17:44 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 02 Oct 2019 12:17:44 +0200 Subject: [8u] RFR: 8134579: [TESTBUG] Some bmi tests fail if can_access_local_variables is on. Message-ID: Hi, Could I get a review of this OpenJDK 8u test-fix, please? We are seeing occasional test failures for LZcntTestI.java and/or LZcntTestL.java when running OpenJDK 8u tier1 tests. Backporting this change from JDK 9 fixes the issue. The JDK 9 patch didn't apply cleanly. Modifications I've done are: * Record AddnTest{I,L}.java => AndnTest{L,I}.java as a rename. * Manually removed AddnTest{I,L}.java tests as the removal rejected. This was done part of the rename (hg mv -A source dest) * Kept @library and @run definitions of AndnTest{I,L}.java as they were, modulo test name (last argument). Bug: https://bugs.openjdk.java.net/browse/JDK-8134579 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134579/jdk8/01/webrev/ Testing: OpenJDK 8u tier1 tests on Linux x86_64 (release/fastdebug). Relevant test(s) fails prior, passes after. Thoughts? Thanks, Severin From vladimir.kozlov at oracle.com Wed Oct 2 17:11:59 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 Oct 2019 10:11:59 -0700 Subject: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB731EE6@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> Message-ID: Good. thanks, Vladimir On 10/1/19 4:36 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have updated the patch with appropriate comments in globals_x86.hpp and also updated the bug entry. > The updated webrev is here: > http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.01/ > Could you please review. > > Regards, > Vivek > > -----Original Message----- > From: Deshpande, Vivek R > Sent: Thursday, September 26, 2019 10:52 AM > To: Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net > Cc: Scott Oaks ; eric.caspole ; Robert Strout > Subject: RE: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors > > Thanks you Vladimir for the review. > I will work on the adding the comments and changes to the bug report. > > Yes the threshold is for architectures after skylake which support AVX512. > With this threshold( value = 4096 bytes found experimentally), AVX512 will be used if the array size is bigger than that. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, September 25, 2019 12:41 PM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net > Cc: Scott Oaks ; eric.caspole ; Robert Strout > Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors > > Thank you, Vivek > > I see you did several changes including intrinsics code. Would be nice if you list changes you did in bug report. I see you removed _evex instructions variants in .ad file, replaced evex instructions in stubs and set UseAVX to 2 for Skylake. It is easy to understand. > > But what about array limit AVX3Threshold? I assume it is for non-Skylake CPUs with AVX512. Right? > What number 4096 is based on. It seems AVX3Threshold == 0 has special meaning - add line in globals_x86.hpp explaining it. I would need more time to look on related changes. > > Thanks, > Vladimir > > On 9/3/19 5:02 PM, Deshpande, Vivek R wrote: >> Hi All >> >> I have created a patch which sets AVX2 for Skylake and selectively >> uses EVEX instructions based on threshold for platforms after Skylake. >> I don't observe the regressions for SPECjvm2008 on Skylake with this patch. >> JBS id: >> https://bugs.openjdk.java.net/browse/JDK-8221092 >> Webrev: >> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.00/ >> Could you all please review the patch. >> >> Regards, >> Vivek >> From vladimir.kozlov at oracle.com Wed Oct 2 17:15:04 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 2 Oct 2019 10:15:04 -0700 Subject: RFR (XS) 8231713: x86_32 build failures after JDK-8226721 (Missing intrinsics for Math.ceil, floor, rint) In-Reply-To: <6e34ae48-4c16-6223-73ef-9ec24c4a9a80@redhat.com> References: <6e34ae48-4c16-6223-73ef-9ec24c4a9a80@redhat.com> Message-ID: Okay. Thanks, Vladimir On 10/2/19 1:50 AM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8231713 > > Fix: > https://cr.openjdk.java.net/~shade/8231713/webrev.01/ > > I actually tried to define the missing operand declarations in x86_32.ad, but that quickly leads to > conflicts. So, I opted to disable the parts of 8226721 for x86_32. > > Testing: test from 8226721, {x86_32, x86_64} hotspot_compiler, jdk-submit (running) > From rwestrel at redhat.com Thu Oct 3 08:48:04 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 03 Oct 2019 10:48:04 +0200 Subject: RFR(S): 8231550: C2: ShouldNotReachHere() in verify_strip_mined_scheduling Message-ID: <87wodm2p17.fsf@redhat.com> http://cr.openjdk.java.net/~roland/8231550/webrev.00/ This is another case where too conservative alias analysis pushes a load in the outer strip mined loop and causes loop strip mining verification to fail. The regression test contains two subtests. In both cases, a load (either of the array length or of a field) depends on a CastPP that's control dependent on the counted loop. A store that's unrelated is sunk in the outer strip mined loop. Because the load can't float above the counted loop and because anti dependence analysis is too conservative, the load ends up in the outer strip mined loop. I see no way around this one other than to relax anti dependence analysis. This also causes my recent fix for Shenandoah bug 8231761 to fail (because it relied on anti-dependence analysis to be conservative) so I also had to rework it. Roland. From rwestrel at redhat.com Thu Oct 3 08:52:29 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 03 Oct 2019 10:52:29 +0200 Subject: [8u] RFR: 8134579: [TESTBUG] Some bmi tests fail if can_access_local_variables is on. In-Reply-To: References: Message-ID: <87tv8q2otu.fsf@redhat.com> > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134579/jdk8/01/webrev/ Looks good to me. Roland. From sgehwolf at redhat.com Thu Oct 3 08:59:52 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 03 Oct 2019 10:59:52 +0200 Subject: [8u] RFR: 8134579: [TESTBUG] Some bmi tests fail if can_access_local_variables is on. In-Reply-To: <87tv8q2otu.fsf@redhat.com> References: <87tv8q2otu.fsf@redhat.com> Message-ID: On Thu, 2019-10-03 at 10:52 +0200, Roland Westrelin wrote: > > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8134579/jdk8/01/webrev/ > > Looks good to me. Thanks for the review, Roland! Cheers, Severin From vivek.r.deshpande at intel.com Thu Oct 3 16:31:41 2019 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 3 Oct 2019 16:31:41 +0000 Subject: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB731EE6@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7CA2D1@fmsmsx121.amr.corp.intel.com> Hi Vladimir Can I push the patch? Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Wednesday, October 2, 2019 10:12 AM To: Deshpande, Vivek R ; 'hotspot-compiler-dev at openjdk.java.net' Cc: 'Scott Oaks' ; 'eric.caspole' ; 'Robert Strout' Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors Good. thanks, Vladimir On 10/1/19 4:36 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have updated the patch with appropriate comments in globals_x86.hpp and also updated the bug entry. > The updated webrev is here: > http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.01/ > Could you please review. > > Regards, > Vivek > > -----Original Message----- > From: Deshpande, Vivek R > Sent: Thursday, September 26, 2019 10:52 AM > To: Vladimir Kozlov ; > hotspot-compiler-dev at openjdk.java.net > Cc: Scott Oaks ; eric.caspole > ; Robert Strout > Subject: RE: RFR: 8221092: UseAVX=3 has performance degredation on > Skylake (X7) processors > > Thanks you Vladimir for the review. > I will work on the adding the comments and changes to the bug report. > > Yes the threshold is for architectures after skylake which support AVX512. > With this threshold( value = 4096 bytes found experimentally), AVX512 will be used if the array size is bigger than that. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, September 25, 2019 12:41 PM > To: Deshpande, Vivek R ; > hotspot-compiler-dev at openjdk.java.net > Cc: Scott Oaks ; eric.caspole > ; Robert Strout > Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on > Skylake (X7) processors > > Thank you, Vivek > > I see you did several changes including intrinsics code. Would be nice if you list changes you did in bug report. I see you removed _evex instructions variants in .ad file, replaced evex instructions in stubs and set UseAVX to 2 for Skylake. It is easy to understand. > > But what about array limit AVX3Threshold? I assume it is for non-Skylake CPUs with AVX512. Right? > What number 4096 is based on. It seems AVX3Threshold == 0 has special meaning - add line in globals_x86.hpp explaining it. I would need more time to look on related changes. > > Thanks, > Vladimir > > On 9/3/19 5:02 PM, Deshpande, Vivek R wrote: >> Hi All >> >> I have created a patch which sets AVX2 for Skylake and selectively >> uses EVEX instructions based on threshold for platforms after Skylake. >> I don't observe the regressions for SPECjvm2008 on Skylake with this patch. >> JBS id: >> https://bugs.openjdk.java.net/browse/JDK-8221092 >> Webrev: >> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.00/ >> Could you all please review the patch. >> >> Regards, >> Vivek >> From igor.veresov at oracle.com Fri Oct 4 06:30:08 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 3 Oct 2019 23:30:08 -0700 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out Message-ID: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> The problem with this is that the test wants to run with -XX:-TieredCompilation in order to deterministically test the top level compiler. When we run this test with Graal we add -XX:+UseJVMCICompiler on top of that. The combination of these flags is extremely slow since Graal will have to compile itself while running in the interpreter, which causes timeouts. There are a lot of tests that behave this way. The proposed solution is as follows. We introduce a special mode of tiered compilation that basically emulates the non-tiered mode - application code is profiled in the interpreter and then goes straight to the top level compiler. However, for the code of the JVMCI compiler we make an exception - it still gets to be compiled with C1 (level 1) as it normally does in tiered mode. The new mode integrates with AOT as well. As result the tests in question can execute an order of magnitude faster while still testing the top level compiler as these tests were designed to. I?d like to introduce a -XX:TieredMode= flag to control this. See the webrev for its description. To make the tests work out-of-the-box I check if the flags -XX:-TieredCompilation and -XX:+UseJVMCICompiler are on the command line and turn the tiered compilation back on in non-tiered emulation mode. A warning is issued to alert the user to the change. This mode is also a step towards being able to remove the non-tiered policy. Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8227003 igor From doug.simon at oracle.com Fri Oct 4 08:07:03 2019 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 4 Oct 2019 10:07:03 +0200 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> Message-ID: <57247A79-4385-412F-B710-9F030658CDF4@oracle.com> Glancing through the web rev, I see new flags such as Tier40MinInvocationThreshold and Tier40CompileThreshold. Why ?Tier40? instead of ?Tier4"? -Doug > On 4 Oct 2019, at 08:30, Igor Veresov wrote: > > The problem with this is that the test wants to run with -XX:-TieredCompilation in order to deterministically test the top level compiler. When we run this test with Graal we add -XX:+UseJVMCICompiler on top of that. The combination of these flags is extremely slow since Graal will have to compile itself while running in the interpreter, which causes timeouts. There are a lot of tests that behave this way. > > The proposed solution is as follows. We introduce a special mode of tiered compilation that basically emulates the non-tiered mode - application code is profiled in the interpreter and then goes straight to the top level compiler. However, for the code of the JVMCI compiler we make an exception - it still gets to be compiled with C1 (level 1) as it normally does in tiered mode. The new mode integrates with AOT as well. As result the tests in question can execute an order of magnitude faster while still testing the top level compiler as these tests were designed to. > > I?d like to introduce a -XX:TieredMode= flag to control this. See the webrev for its description. > > To make the tests work out-of-the-box I check if the flags -XX:-TieredCompilation and -XX:+UseJVMCICompiler are on the command line and turn the tiered compilation back on in non-tiered emulation mode. A warning is issued to alert the user to the change. This mode is also a step towards being able to remove the non-tiered policy. > > Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8227003 > > igor > > > From martin.doerr at sap.com Fri Oct 4 08:52:39 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 4 Oct 2019 08:52:39 +0000 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: Hi Michihiro, thanks for implementing it for PPC64. The new match rules should have "format" and "size", too. Otherwise, looks good. Best regards, Martin From: ppc-aix-port-dev On Behalf Of Michihiro Horie Sent: Mittwoch, 2. Oktober 2019 06:27 To: ppc-aix-port-dev at openjdk.java.net; hotspot compiler Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Dear all, Would you please review the following change? Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on top of 8226721: Missing intrinsics for Math.ceil, floor, rint. Best regards, Michihiro From HORIE at jp.ibm.com Fri Oct 4 10:46:21 2019 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Fri, 4 Oct 2019 19:46:21 +0900 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: Hi Martin, Thank you so much for your review. I added the format and size. New webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.01/ I need one more review for this webrev. Best regards, Michihiro From: "Doerr, Martin" To: Michihiro Horie , "ppc-aix-port-dev at openjdk.java.net" , hotspot compiler Date: 2019/10/04 17:52 Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Hi Michihiro, thanks for implementing it for PPC64. The new match rules should have ?format? and ?size?, too. Otherwise, looks good. Best regards, Martin From: ppc-aix-port-dev On Behalf Of Michihiro Horie Sent: Mittwoch, 2. Oktober 2019 06:27 To: ppc-aix-port-dev at openjdk.java.net; hotspot compiler Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Dear all, Would you please review the following change? Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on top of 8226721: Missing intrinsics for Math.ceil, floor, rint. Best regards, Michihiro From claes.redestad at oracle.com Fri Oct 4 11:06:00 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 4 Oct 2019 13:06:00 +0200 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> Message-ID: <1cf8bfdc-d7cc-e9a1-319a-2edad2a74454@oracle.com> Hi! I think the subject of this RFE should be updated to better reflect the feature being added, and not the test issue that motivated it. Is the plan to keep this feature around once AOT-compiled Graal is supported/integrated? If not then TieredMode should probably be diagnostic or even experimental to simplify eventually removing it. For tiered mode 4, you're adding 9 new diagnostic flags. Could some Tier2 or Tier3 flags be ergonomically repurposed rather? E.g., I guess Tier0Delay could reuse Tier3DelayOn/-Off instead, but just go to level 0 rather than the disabled level 3. Thanks! /Claes On 2019-10-04 08:30, Igor Veresov wrote: > The problem with this is that the test wants to run with -XX:-TieredCompilation in order to deterministically test the top level compiler. When we run this test with Graal we add -XX:+UseJVMCICompiler on top of that. The combination of these flags is extremely slow since Graal will have to compile itself while running in the interpreter, which causes timeouts. There are a lot of tests that behave this way. > > The proposed solution is as follows. We introduce a special mode of tiered compilation that basically emulates the non-tiered mode - application code is profiled in the interpreter and then goes straight to the top level compiler. However, for the code of the JVMCI compiler we make an exception - it still gets to be compiled with C1 (level 1) as it normally does in tiered mode. The new mode integrates with AOT as well. As result the tests in question can execute an order of magnitude faster while still testing the top level compiler as these tests were designed to. > > I?d like to introduce a -XX:TieredMode= flag to control this. See the webrev for its description. > > To make the tests work out-of-the-box I check if the flags -XX:-TieredCompilation and -XX:+UseJVMCICompiler are on the command line and turn the tiered compilation back on in non-tiered emulation mode. A warning is issued to alert the user to the change. This mode is also a step towards being able to remove the non-tiered policy. > > Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.00/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8227003 > > igor > > > From igor.veresov at oracle.com Fri Oct 4 13:30:43 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 4 Oct 2019 06:30:43 -0700 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <57247A79-4385-412F-B710-9F030658CDF4@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <57247A79-4385-412F-B710-9F030658CDF4@oracle.com> Message-ID: <5C7C55AF-8F78-4434-949A-28EC9A5DAA91@oracle.com> > On Oct 4, 2019, at 1:07 AM, Doug Simon wrote: > > Glancing through the web rev, I see new flags such as Tier40MinInvocationThreshold and Tier40CompileThreshold. Why ?Tier40? instead of ?Tier4"? > It?s controls the level 0 -> 4 transition. Sort of an existing naming scheme. Igor > -Doug > >> On 4 Oct 2019, at 08:30, Igor Veresov > wrote: >> >> The problem with this is that the test wants to run with -XX:-TieredCompilation in order to deterministically test the top level compiler. When we run this test with Graal we add -XX:+UseJVMCICompiler on top of that. The combination of these flags is extremely slow since Graal will have to compile itself while running in the interpreter, which causes timeouts. There are a lot of tests that behave this way. >> >> The proposed solution is as follows. We introduce a special mode of tiered compilation that basically emulates the non-tiered mode - application code is profiled in the interpreter and then goes straight to the top level compiler. However, for the code of the JVMCI compiler we make an exception - it still gets to be compiled with C1 (level 1) as it normally does in tiered mode. The new mode integrates with AOT as well. As result the tests in question can execute an order of magnitude faster while still testing the top level compiler as these tests were designed to. >> >> I?d like to introduce a -XX:TieredMode= flag to control this. See the webrev for its description. >> >> To make the tests work out-of-the-box I check if the flags -XX:-TieredCompilation and -XX:+UseJVMCICompiler are on the command line and turn the tiered compilation back on in non-tiered emulation mode. A warning is issued to alert the user to the change. This mode is also a step towards being able to remove the non-tiered policy. >> >> Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8227003 >> >> igor >> >> >> > From igor.veresov at oracle.com Fri Oct 4 13:36:19 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 4 Oct 2019 06:36:19 -0700 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <1cf8bfdc-d7cc-e9a1-319a-2edad2a74454@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <1cf8bfdc-d7cc-e9a1-319a-2edad2a74454@oracle.com> Message-ID: <619A59B0-29AF-49C4-AC0D-DA21C02014E3@oracle.com> > On Oct 4, 2019, at 4:06 AM, Claes Redestad wrote: > > Hi! > > I think the subject of this RFE should be updated to better reflect the > feature being added, and not the test issue that motivated it. > Yes, probably. > Is the plan to keep this feature around once AOT-compiled Graal is supported/integrated? If not then TieredMode should probably be > diagnostic or even experimental to simplify eventually removing it. > Yes, the plan is to keep it. We will still be testing Graal in Java mode. Also as I noted I?d like to remove the non-tiered policy in the future. So then -XX:-TieredCompilation will just mean -XX:TieredMode=2 > For tiered mode 4, you're adding 9 new diagnostic flags. Could some > Tier2 or Tier3 flags be ergonomically repurposed rather? E.g., I guess > Tier0Delay could reuse Tier3DelayOn/-Off instead, but just go to level 0 > rather than the disabled level 3. I could, yes, but I decided that it would be confusing to repurpose these flags. There is no level 3, for example. I could make them a single flag to look like -XX:Tiered40Thresholds=I,j,k,l but I?ll obviously will have to write a parser for that. Igor > > Thanks! > > /Claes > > On 2019-10-04 08:30, Igor Veresov wrote: >> The problem with this is that the test wants to run with -XX:-TieredCompilation in order to deterministically test the top level compiler. When we run this test with Graal we add -XX:+UseJVMCICompiler on top of that. The combination of these flags is extremely slow since Graal will have to compile itself while running in the interpreter, which causes timeouts. There are a lot of tests that behave this way. >> The proposed solution is as follows. We introduce a special mode of tiered compilation that basically emulates the non-tiered mode - application code is profiled in the interpreter and then goes straight to the top level compiler. However, for the code of the JVMCI compiler we make an exception - it still gets to be compiled with C1 (level 1) as it normally does in tiered mode. The new mode integrates with AOT as well. As result the tests in question can execute an order of magnitude faster while still testing the top level compiler as these tests were designed to. >> I?d like to introduce a -XX:TieredMode= flag to control this. See the webrev for its description. >> To make the tests work out-of-the-box I check if the flags -XX:-TieredCompilation and -XX:+UseJVMCICompiler are on the command line and turn the tiered compilation back on in non-tiered emulation mode. A warning is issued to alert the user to the change. This mode is also a step towards being able to remove the non-tiered policy. >> Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8227003 >> igor From vladimir.x.ivanov at oracle.com Fri Oct 4 14:05:40 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 4 Oct 2019 17:05:40 +0300 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: Hi Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: + switch (rmode) { + case 0: // rint + frin(t, b); + break; + case 1: // floor + frim(t, b); + break; + case 2: // ceil + frip(t, b); + break; + default: + ShouldNotReachHere(); + } What do you think about introducing enum constants instead of using hard-coded 0/1/2? src/hotspot/share/opto/library_call.cpp: case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(2))); break; case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(1))); break; case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(0))); break; The downside is you have to move the switch from macroAssembler because enum should be visible from both places. (Is there a better place for that than roundD_regNode::emit() in AD file?) Best regards, Vladimir Ivanov On 02/10/2019 07:27, Michihiro Horie wrote: > > Dear all, > > Would you please review the following change? > Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > > This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on > top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > > Best regards, > Michihiro > From vladimir.x.ivanov at oracle.com Fri Oct 4 14:06:46 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 4 Oct 2019 17:06:46 +0300 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode In-Reply-To: <87ftkb4n3u.fsf@redhat.com> References: <87ftkb4n3u.fsf@redhat.com> Message-ID: <2f284b47-cd7f-a7ce-22f4-165917182702@oracle.com> Looks good. (Submitted for testing.) Best regards, Vladimir Ivanov On 02/10/2019 10:34, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8231620/webrev.00/ > > In test1() of the regression test, the loop is unswitched. Once it is > there are 2 Lock nodes but a single shared FastLock node. Split if then > happens with the shared FastLock between the If to be split and the > dominating Region. C2 then crashes in PhaseIdealLoop::split_up() because > the pattern with the FastLock is unhandled there. merge_point_safe() > checks for a FastLock node and it is expected to prevent split if when > that pattern is encountered. But in the case test1(), There's a CastPP > between the Phi and the FastLock. > > test2() of the regression test is similar except that, instead of a > CastPP, a load node is between the Phi and the FastLock. That one > crashes the same way but only on 32 bits because a ConvI2L prevents > split if on 64 bits. > > Rather than try to fix merge_point_safe() to handle every node that can > be in between the FastLock and the Phi, I propose handling FastLock > nodes in PhaseIdealLoop::split_up() which is AFAICT straightforward. > > Roland. > From vladimir.x.ivanov at oracle.com Fri Oct 4 15:15:35 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 4 Oct 2019 18:15:35 +0300 Subject: RFR(S): 8231550: C2: ShouldNotReachHere() in verify_strip_mined_scheduling In-Reply-To: <87wodm2p17.fsf@redhat.com> References: <87wodm2p17.fsf@redhat.com> Message-ID: Looks good. (Submitted for testing.) Best regards, Vladimir Ivanov On 03/10/2019 11:48, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8231550/webrev.00/ > > This is another case where too conservative alias analysis pushes a load > in the outer strip mined loop and causes loop strip mining verification > to fail. The regression test contains two subtests. In both cases, a > load (either of the array length or of a field) depends on a CastPP > that's control dependent on the counted loop. A store that's unrelated > is sunk in the outer strip mined loop. Because the load can't float > above the counted loop and because anti dependence analysis is too > conservative, the load ends up in the outer strip mined loop. I see no > way around this one other than to relax anti dependence analysis. > > This also causes my recent fix for Shenandoah bug 8231761 to fail > (because it relied on anti-dependence analysis to be conservative) so I > also had to rework it. > > Roland. > From tom.rodriguez at oracle.com Fri Oct 4 17:26:25 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Oct 2019 10:26:25 -0700 Subject: RFR(S) 8231586: enlarge encoding space for OopMapValue offsets Message-ID: http://cr.openjdk.java.net/~never/8231586/webrev https://bugs.openjdk.java.net/browse/JDK-8231586 The current OopMapValue encoding uses a bit mask for each value even though only one bit is ever set. Since only 16 bits are available for encoding this limits the offsets it can express. Compilation with a large number of stack slots can bailout because of this limit. This changes the encoding to use 2 bits which gives 2 bits back to the offset. I also deleted some StressDerivedPointers machinery that's been completely unimplemented for years (decades?). The flag itself is now dead but I wasn't sure if there are test references to it somewhere. Should I delete the flag as well? mach5 testing is in progress. tom From tom.rodriguez at oracle.com Fri Oct 4 17:55:05 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Oct 2019 10:55:05 -0700 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> Message-ID: <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> > I?d like to introduce a -XX:TieredMode= flag to control this. > See the webrev for its description. I think the policy you are suggesting sounds reasonable to me, but I find the use of a bit mask to select it to be confusing. Several of the bit mask states seem invalid like TieredMode=7 seems to just be TieredMode=1 apart from inconsistent flags settings. How is TieredMode=1 different from TieredStopAtLevel=1? Isn't TieredMode=6 equivalent to the old -TieredCompilation? We've disabled level 1-3 for everyone but JVMCI and then we've disable the special level 1 for JVMCI, so isn't level 4 the only thing left? Why not have some symbolic names with a clearer description of what those modes are? Do we even need/want this much flexibility exposed? Maybe -TieredCompilation defaults to the new behaviour in the presence of +UseJVMCICompiler and a new StrictTieredCompilation gives you the old behaviour. tom > > To make the tests work out-of-the-box I check if the flags > -XX:-TieredCompilation and -XX:+UseJVMCICompiler are on the command line > and turn the tiered compilation back on in non-tiered emulation mode. A > warning is issued to alert the user to the change. This mode is also a > step towards being able to remove the non-tiered policy. > > Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.00/ > > JBS: https://bugs.openjdk.java.net/browse/JDK-8227003 > > igor > > > From tom.rodriguez at oracle.com Fri Oct 4 19:23:57 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 4 Oct 2019 12:23:57 -0700 Subject: RFR: 8231659: [JVMCI] Could not work PrintAssembly for JVMCI installed code In-Reply-To: <8ee7143a-15cb-5761-528c-c5fa687d89f3@gmail.com> References: <8ee7143a-15cb-5761-528c-c5fa687d89f3@gmail.com> Message-ID: <501e7e05-3334-62f9-c765-ea2c35326d32@oracle.com> Yasumasa Suenaga wrote on 10/1/19 1:57 AM: > Hi all, > > Please review this change. > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8231659 > ? webrev: https://cr.openjdk.java.net/~ysuenaga/JDK-8231659/webrev.00/ > > PrintAssembly would work in twice for JVMCI installed code before, so I > fixed it in JDK-8180601. > However PrintAseembly would not work for them in JDK 13 or later. It > seems due to JDK-8220623. > > JDK-8220623 lacks print_nmethod() call. Thus I revert JDK-8180601 to > work PrintAssembly. I'd noticed this but forgot to go back and investigate. I think it would be nicer to make that code look like the code that was accidentally removed from JVMCIEnv.cpp: diff -r 647e896479ff src/hotspot/share/jvmci/jvmciCodeInstaller.cpp --- a/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp +++ b/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp @@ -642,11 +642,9 @@ failed_speculations, speculations, speculations_len); cb = nm->as_codeblob_or_null(); if (nm != NULL && compile_state == NULL) { + // This compile didn't come through the CompileBroker so perform the printing here DirectiveSet* directive = DirectivesStack::getMatchingDirective(method, compiler); - bool printnmethods = directive->PrintAssemblyOption || directive->PrintNMethodsOption; - if (!printnmethods && (PrintDebugInfo || PrintRelocations || PrintDependencies || PrintExceptionHandlers)) { - nm->print_nmethod(printnmethods); - } + nm->maybe_print_nmethod(directive); DirectivesStack::release(directive); } } No point in duplicating that logic. tom From dean.long at oracle.com Fri Oct 4 19:29:21 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Oct 2019 12:29:21 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed Message-ID: https://bugs.openjdk.java.net/browse/JDK-8231902 http://cr.openjdk.java.net/~dlong/8231902/webrev/ A recent upstream Graal change causes the META-INF/providers directory to contain only a single file, causing the $(GREP) command to not prepend the filename to the output.? The simple fix is to create an empty file in the directory. dl From vladimir.kozlov at oracle.com Fri Oct 4 20:03:31 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 4 Oct 2019 13:03:31 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: References: Message-ID: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> Good. Thanks Vladimir > On Oct 4, 2019, at 12:29 PM, dean.long at oracle.com wrote: > > https://bugs.openjdk.java.net/browse/JDK-8231902 > http://cr.openjdk.java.net/~dlong/8231902/webrev/ > > A recent upstream Graal change causes the META-INF/providers directory to contain only a single file, causing the $(GREP) command to not prepend the filename to the output. The simple fix is to create an empty file in the directory. > > dl From erik.joelsson at oracle.com Fri Oct 4 20:08:49 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 4 Oct 2019 13:08:49 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> References: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> Message-ID: <0cda922a-806a-bc0a-853a-290d445212c4@oracle.com> See comment I put in the bug. /Erik On 2019-10-04 13:03, Vladimir Kozlov wrote: > Good. > > Thanks > Vladimir > >> On Oct 4, 2019, at 12:29 PM, dean.long at oracle.com wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8231902 >> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >> >> A recent upstream Graal change causes the META-INF/providers directory to contain only a single file, causing the $(GREP) command to not prepend the filename to the output. The simple fix is to create an empty file in the directory. >> >> dl From ekaterina.pavlova at oracle.com Fri Oct 4 20:58:57 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Fri, 4 Oct 2019 13:58:57 -0700 Subject: RFR(T/S) 8231903: [Graal] Update com.oracle.mxtool.junit classes Message-ID: <7770495a-c1bd-c248-217f-fc307ff2c3f9@oracle.com> Hi, please review the following change which syncs com.oracle.mxtool.junit classes with ones from graal ws. Also - removed org.graalvm.compiler.core.test.CheckGraalInvariants from test/hotspot/jtreg/ProblemList-graal.txt as the test doesn't fail anymore - updated test/hotspot/jtreg/compiler/graalunit/TestPackages.txt to match latest list of test packages JBS: https://bugs.openjdk.java.net/browse/JDK-8231903 webrev: http://cr.openjdk.java.net/~epavlova//8231903/webrev.00/index.html testing: graal unit tests thanks, -katya From dean.long at oracle.com Fri Oct 4 22:09:53 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Oct 2019 15:09:53 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: References: Message-ID: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> Here's an alternative version with $(NAWK) usage suggested by Erik Joelsson: http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ dl On 10/4/19 12:29 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8231902 > http://cr.openjdk.java.net/~dlong/8231902/webrev/ > > A recent upstream Graal change causes the META-INF/providers directory > to contain only a single file, causing the $(GREP) command to not > prepend the filename to the output.? The simple fix is to create an > empty file in the directory. > > dl From igor.veresov at oracle.com Fri Oct 4 22:44:47 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 4 Oct 2019 15:44:47 -0700 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> Message-ID: <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> > On Oct 4, 2019, at 10:55 AM, Tom Rodriguez wrote: > >> I?d like to introduce a -XX:TieredMode= flag to control this. See the webrev for its description. > Command line parameter naming is the hardest problem in computer science indeed. > I think the policy you are suggesting sounds reasonable to me, but I find the use of a bit mask to select it to be confusing. Several of the bit mask states seem invalid like TieredMode=7 seems to just be TieredMode=1 apart from inconsistent flags settings. How is TieredMode=1 different from TieredStopAtLevel=1? Isn't TieredMode=6 equivalent to the old -TieredCompilation? We've disabled level 1-3 for everyone but JVMCI and then we've disable the special level 1 for JVMCI, so isn't level 4 the only thing left? > So, first thing is that I?d like to get rid of the non-tiered policy in the future, so the goal of TieredMode was to be able to select all the possible execution modes. The ability to combine 2 | 4 is intentional. Some tests want to switch C1 off entirely. The two tests in this webrev are one of those. It is also useful if you suspect that C1 is a problem and want to turn it off. TieredMode=1 for now is the same as TieredStopAtLevel=1, yes, but my intention is to make the adjustments to the policy to do it more refined. TieredStopAtLevel=1 is really a debug flag that people started using to get a C1-only mode, but it has not been tuned for that really, it just limits the compile level at the last moment before a compile request is submitted. Anyways, my intent was to make TieredMode to be a *set* of flags that adjust the policy behavior. You?re right that some bit combinations are making the policy to ignore some other bits (although all the bit combinations are valid, there is even a test that checks that). > Why not have some symbolic names with a clearer description of what those modes are? That?s a good idea, except I wan?t able to come up with the good names. I don?t want to mention C1 or C2 in the names of these flags, because it may all be different modes of Graal in the future. If we name the options now we are struck with them forever. Bits are on the other hand anonymous. May be 0 - default, 1 - simple, 2 - no_intermediate, 4 - no_force_simple ? > Do we even need/want this much flexibility exposed? Maybe -TieredCompilation defaults to the new behaviour in the presence of +UseJVMCICompiler and a new StrictTieredCompilation gives you the old behaviour. > I had this in one of the revisions. I think it?s more confusing. -XX:-TieredCompilation - C1 only for Graal -XX:-StrictTieredCompilation - no C1 at all. -XX:+TieredCompilation - normal behavior And then there are combinations of these flags with ambiguous meanings. It becomes this ?I seriously mean no tiered this time? flag. I?m not a big fan of how it reads. Igor > tom > > >> To make the tests work out-of-the-box I check if the flags -XX:-TieredCompilation and -XX:+UseJVMCICompiler are on the command line and turn the tiered compilation back on in non-tiered emulation mode. A warning is issued to alert the user to the change. This mode is also a step towards being able to remove the non-tiered policy. >> Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.00/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8227003 >> igor From dean.long at oracle.com Fri Oct 4 22:47:52 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Oct 2019 15:47:52 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> References: <44D71F8E-DCB0-4D32-B28F-F4755BC46D10@oracle.com> Message-ID: <3ae4de07-95ec-b8f1-b27f-e0e8bfb80c12@oracle.com> Thanks Vladimir. dl On 10/4/19 1:03 PM, Vladimir Kozlov wrote: > Good. > > Thanks > Vladimir > >> On Oct 4, 2019, at 12:29 PM, dean.long at oracle.com wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8231902 >> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >> >> A recent upstream Graal change causes the META-INF/providers directory to contain only a single file, causing the $(GREP) command to not prepend the filename to the output. The simple fix is to create an empty file in the directory. >> >> dl From dean.long at oracle.com Fri Oct 4 23:27:14 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 4 Oct 2019 16:27:14 -0700 Subject: RFR(S) 8231586: enlarge encoding space for OopMapValue offsets In-Reply-To: References: Message-ID: <92e6a5a2-c806-843d-a8e0-84f0aa3718b7@oracle.com> It's not obvious that we only set 1 bit.? The set methods don't enforce that.? And this code looks like it is setting both "derived" and "oop": http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/opto/buildOopMap.cpp#l315 dl On 10/4/19 10:26 AM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8231586/webrev > https://bugs.openjdk.java.net/browse/JDK-8231586 > > The current OopMapValue encoding uses a bit mask for each value even > though only one bit is ever set.? Since only 16 bits are available for > encoding this limits the offsets it can express. Compilation with a > large number of stack slots can bailout because of this limit.? This > changes the encoding to use 2 bits which gives 2 bits back to the offset. > > I also deleted some StressDerivedPointers machinery that's been > completely unimplemented for years (decades?).? The flag itself is now > dead but I wasn't sure if there are test references to it somewhere. > Should I delete the flag as well? > > mach5 testing is in progress. > > tom From yasuenag at gmail.com Sat Oct 5 00:40:28 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Sat, 5 Oct 2019 09:40:28 +0900 Subject: RFR: 8231659: [JVMCI] Could not work PrintAssembly for JVMCI installed code In-Reply-To: <501e7e05-3334-62f9-c765-ea2c35326d32@oracle.com> References: <8ee7143a-15cb-5761-528c-c5fa687d89f3@gmail.com> <501e7e05-3334-62f9-c765-ea2c35326d32@oracle.com> Message-ID: Hi Tom, I agree with you. Your change looks good. Can you push it? or may I create changeset for this? Thanks, Yasumasa On 2019/10/05 4:23, Tom Rodriguez wrote: > > > Yasumasa Suenaga wrote on 10/1/19 1:57 AM: >> Hi all, >> >> Please review this change. >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8231659 >> ?? webrev: https://cr.openjdk.java.net/~ysuenaga/JDK-8231659/webrev.00/ >> >> PrintAssembly would work in twice for JVMCI installed code before, so I fixed it in JDK-8180601. >> However PrintAseembly would not work for them in JDK 13 or later. It seems due to JDK-8220623. >> >> JDK-8220623 lacks print_nmethod() call. Thus I revert JDK-8180601 to work PrintAssembly. > > I'd noticed this but forgot to go back and investigate.? I think it would be nicer to make that code look like the code that was accidentally removed from JVMCIEnv.cpp: > > diff -r 647e896479ff src/hotspot/share/jvmci/jvmciCodeInstaller.cpp > --- a/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp > +++ b/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp > @@ -642,11 +642,9 @@ > ???????????????????????????????????????? failed_speculations, speculations, speculations_len); > ???? cb = nm->as_codeblob_or_null(); > ???? if (nm != NULL && compile_state == NULL) { > +????? // This compile didn't come through the CompileBroker so perform the printing here > ?????? DirectiveSet* directive = DirectivesStack::getMatchingDirective(method, compiler); > -????? bool printnmethods = directive->PrintAssemblyOption || directive->PrintNMethodsOption; > -????? if (!printnmethods && (PrintDebugInfo || PrintRelocations || PrintDependencies || PrintExceptionHandlers)) { > -??????? nm->print_nmethod(printnmethods); > -????? } > +????? nm->maybe_print_nmethod(directive); > ?????? DirectivesStack::release(directive); > ???? } > ?? } > > No point in duplicating that logic. > > tom From tom.rodriguez at oracle.com Sat Oct 5 17:41:21 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Sat, 5 Oct 2019 10:41:21 -0700 Subject: RFR(S) 8231586: enlarge encoding space for OopMapValue offsets In-Reply-To: <92e6a5a2-c806-843d-a8e0-84f0aa3718b7@oracle.com> References: <92e6a5a2-c806-843d-a8e0-84f0aa3718b7@oracle.com> Message-ID: <6fa4389f-81f2-7591-de61-9edc60a18187@oracle.com> dean.long at oracle.com wrote on 10/4/19 4:27 PM: > It's not obvious that we only set 1 bit.? The set methods don't enforce > that.? And this code looks like it is setting both "derived" and "oop": Each of those calls produce independent OopMapValues. http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/compiler/oopMap.cpp#l137 Also all tests against the type are equality tests, not bitmasks, so if more than one bit was set it would fail to match anything. The bitmask-ness of the values is only used for filtering the iteration. tom > > http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/opto/buildOopMap.cpp#l315 > > > dl > > On 10/4/19 10:26 AM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/8231586/webrev >> https://bugs.openjdk.java.net/browse/JDK-8231586 >> >> The current OopMapValue encoding uses a bit mask for each value even >> though only one bit is ever set.? Since only 16 bits are available for >> encoding this limits the offsets it can express. Compilation with a >> large number of stack slots can bailout because of this limit.? This >> changes the encoding to use 2 bits which gives 2 bits back to the offset. >> >> I also deleted some StressDerivedPointers machinery that's been >> completely unimplemented for years (decades?).? The flag itself is now >> dead but I wasn't sure if there are test references to it somewhere. >> Should I delete the flag as well? >> >> mach5 testing is in progress. >> >> tom > From dean.long at oracle.com Sun Oct 6 04:25:10 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Sat, 5 Oct 2019 21:25:10 -0700 Subject: RFR(S) 8231586: enlarge encoding space for OopMapValue offsets In-Reply-To: <6fa4389f-81f2-7591-de61-9edc60a18187@oracle.com> References: <92e6a5a2-c806-843d-a8e0-84f0aa3718b7@oracle.com> <6fa4389f-81f2-7591-de61-9edc60a18187@oracle.com> Message-ID: <5ff481d6-f440-90d6-6f04-3576879afbf5@oracle.com> You're right, my mistake.? Your change looks good.? I was actually looking at the set_* methods in OopMapValue, not OopMap, and incorrectly thought the | would preserve the previous value.? On closer inspection, it doesn't, and those methods don't even get called, because the ctor uses a different set method.? Can we remove these unused methods? ??? void set_oop()????????????? { set_value((value() & register_mask_in_place) | oop_value); } ??? void set_narrowoop()????????? { set_value((value() & register_mask_in_place) | narrowoop_value); } ??? void set_callee_saved()???? { set_value((value() & register_mask_in_place) | callee_saved_value); } ??? void set_derived_oop()????? { set_value((value() & register_mask_in_place) | derived_oop_value); } dl On 10/5/19 10:41 AM, Tom Rodriguez wrote: > > > dean.long at oracle.com wrote on 10/4/19 4:27 PM: >> It's not obvious that we only set 1 bit. The set methods don't >> enforce that.? And this code looks like it is setting both "derived" >> and "oop": > > Each of those calls produce independent OopMapValues. > http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/compiler/oopMap.cpp#l137 > ?Also all tests against the type are equality tests, not bitmasks, so > if more than one bit was set it would fail to match anything. The > bitmask-ness of the values is only used for filtering the iteration. > > tom > >> >> http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/opto/buildOopMap.cpp#l315 >> >> >> dl >> >> On 10/4/19 10:26 AM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/8231586/webrev >>> https://bugs.openjdk.java.net/browse/JDK-8231586 >>> >>> The current OopMapValue encoding uses a bit mask for each value even >>> though only one bit is ever set.? Since only 16 bits are available >>> for encoding this limits the offsets it can express. Compilation >>> with a large number of stack slots can bailout because of this >>> limit.? This changes the encoding to use 2 bits which gives 2 bits >>> back to the offset. >>> >>> I also deleted some StressDerivedPointers machinery that's been >>> completely unimplemented for years (decades?).? The flag itself is >>> now dead but I wasn't sure if there are test references to it >>> somewhere. Should I delete the flag as well? >>> >>> mach5 testing is in progress. >>> >>> tom >> From tobias.hartmann at oracle.com Mon Oct 7 07:10:12 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 7 Oct 2019 09:10:12 +0200 Subject: RFR(S): 8231550: C2: ShouldNotReachHere() in verify_strip_mined_scheduling In-Reply-To: References: <87wodm2p17.fsf@redhat.com> Message-ID: <46390620-e9e3-ab00-d543-1cc99ca531e3@oracle.com> +1 All testing that Vladimir submitted passed. Best regards, Tobias On 04.10.19 17:15, Vladimir Ivanov wrote: > Looks good. > > (Submitted for testing.) > > Best regards, > Vladimir Ivanov > > On 03/10/2019 11:48, Roland Westrelin wrote: >> >> http://cr.openjdk.java.net/~roland/8231550/webrev.00/ >> >> This is another case where too conservative alias analysis pushes a load >> in the outer strip mined loop and causes loop strip mining verification >> to fail. The regression test contains two subtests. In both cases, a >> load (either of the array length or of a field) depends on a CastPP >> that's control dependent on the counted loop. A store that's unrelated >> is sunk in the outer strip mined loop. Because the load can't float >> above the counted loop and because anti dependence analysis is too >> conservative, the load ends up in the outer strip mined loop. I see no >> way around this one other than to relax anti dependence analysis. >> >> This also causes my recent fix for Shenandoah bug 8231761 to fail >> (because it relied on anti-dependence analysis to be conservative) so I >> also had to rework it. >> >> Roland. >> From HORIE at jp.ibm.com Mon Oct 7 07:13:51 2019 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Mon, 7 Oct 2019 16:13:51 +0900 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: Hi Vladimir, Thanks a lot for your nice suggestion. Yes, I prefer enum use. I'm wondering if the enum constants can be declared in sharedRuntime.hpp. Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ Best regards, Michihiro From: Vladimir Ivanov To: Michihiro Horie , ppc-aix-port-dev at openjdk.java.net, hotspot compiler Date: 2019/10/04 23:05 Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Hi Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: + switch (rmode) { + case 0: // rint + frin(t, b); + break; + case 1: // floor + frim(t, b); + break; + case 2: // ceil + frip(t, b); + break; + default: + ShouldNotReachHere(); + } What do you think about introducing enum constants instead of using hard-coded 0/1/2? src/hotspot/share/opto/library_call.cpp: case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(2))); break; case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(1))); break; case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(0))); break; The downside is you have to move the switch from macroAssembler because enum should be visible from both places. (Is there a better place for that than roundD_regNode::emit() in AD file?) Best regards, Vladimir Ivanov On 02/10/2019 07:27, Michihiro Horie wrote: > > Dear all, > > Would you please review the following change? > Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8231649&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=R6acJsgDk7_ranieVc4S0sbz0QkjQsntUQEjH0ccyNY&s=llmr9Zh9oQcigrJ0dsVA_LudU15VZuJSEc01KPG28RA&e= > Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.00&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=R6acJsgDk7_ranieVc4S0sbz0QkjQsntUQEjH0ccyNY&s=ByqZ3EjmpHbcgI1a94W8uyXm9FwOgo3DNSLl63wBJow&e= > > This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on > top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > > Best regards, > Michihiro > From tobias.hartmann at oracle.com Mon Oct 7 07:18:52 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 7 Oct 2019 09:18:52 +0200 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode In-Reply-To: <87ftkb4n3u.fsf@redhat.com> References: <87ftkb4n3u.fsf@redhat.com> Message-ID: Hi Roland, looks good to me but the merge_point_safe method is now useless on 32 bit. Best regards, Tobias On 02.10.19 09:34, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8231620/webrev.00/ > > In test1() of the regression test, the loop is unswitched. Once it is > there are 2 Lock nodes but a single shared FastLock node. Split if then > happens with the shared FastLock between the If to be split and the > dominating Region. C2 then crashes in PhaseIdealLoop::split_up() because > the pattern with the FastLock is unhandled there. merge_point_safe() > checks for a FastLock node and it is expected to prevent split if when > that pattern is encountered. But in the case test1(), There's a CastPP > between the Phi and the FastLock. > > test2() of the regression test is similar except that, instead of a > CastPP, a load node is between the Phi and the FastLock. That one > crashes the same way but only on 32 bits because a ConvI2L prevents > split if on 64 bits. > > Rather than try to fix merge_point_safe() to handle every node that can > be in between the FastLock and the Phi, I propose handling FastLock > nodes in PhaseIdealLoop::split_up() which is AFAICT straightforward. > > Roland. > From rwestrel at redhat.com Mon Oct 7 07:58:18 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 07 Oct 2019 09:58:18 +0200 Subject: RFR(S): 8231550: C2: ShouldNotReachHere() in verify_strip_mined_scheduling In-Reply-To: <46390620-e9e3-ab00-d543-1cc99ca531e3@oracle.com> References: <87wodm2p17.fsf@redhat.com> <46390620-e9e3-ab00-d543-1cc99ca531e3@oracle.com> Message-ID: <877e5h2did.fsf@redhat.com> Thanks for the reviews Vladimir & Tobias. Roland. From rwestrel at redhat.com Mon Oct 7 07:58:48 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 07 Oct 2019 09:58:48 +0200 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode In-Reply-To: References: <87ftkb4n3u.fsf@redhat.com> Message-ID: <874l0l2dhj.fsf@redhat.com> > looks good to me but the merge_point_safe method is now useless on 32 bit. Right. What about this: http://cr.openjdk.java.net/~roland/8231620/webrev.01/ Roland. From martin.doerr at sap.com Mon Oct 7 08:30:04 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 7 Oct 2019 08:30:04 +0000 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: Hi Michihiro, I think sharedRuntime is not a good place for the C2 enum. Maybe intrinsicnode.hpp would be a better pace for it. But then, the code in macroAssembler should be guarded by #ifdef COMPILER2. Best regards, Martin From: Michihiro Horie Sent: Montag, 7. Oktober 2019 09:14 To: Vladimir Ivanov Cc: hotspot compiler ; ppc-aix-port-dev at openjdk.java.net; Doerr, Martin Subject: RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Hi Vladimir, Thanks a lot for your nice suggestion. Yes, I prefer enum use. I'm wondering if the enum constants can be declared in sharedRuntime.hpp. Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ Best regards, Michihiro [Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:]Vladimir Ivanov ---2019/10/04 23:05:48---Hi Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: From: Vladimir Ivanov > To: Michihiro Horie >, ppc-aix-port-dev at openjdk.java.net, hotspot compiler > Date: 2019/10/04 23:05 Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power ________________________________ Hi Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: + switch (rmode) { + case 0: // rint + frin(t, b); + break; + case 1: // floor + frim(t, b); + break; + case 2: // ceil + frip(t, b); + break; + default: + ShouldNotReachHere(); + } What do you think about introducing enum constants instead of using hard-coded 0/1/2? src/hotspot/share/opto/library_call.cpp: case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(2))); break; case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(1))); break; case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(0))); break; The downside is you have to move the switch from macroAssembler because enum should be visible from both places. (Is there a better place for that than roundD_regNode::emit() in AD file?) Best regards, Vladimir Ivanov On 02/10/2019 07:27, Michihiro Horie wrote: > > Dear all, > > Would you please review the following change? > Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > > This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on > top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > > Best regards, > Michihiro > From magnus.ihse.bursie at oracle.com Mon Oct 7 08:49:48 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 7 Oct 2019 10:49:48 +0200 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> References: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> Message-ID: <6faea9f8-df75-45bd-6f4b-50006a475dd8@oracle.com> On 2019-10-05 00:09, dean.long at oracle.com wrote: > Here's an alternative version with $(NAWK) usage suggested by Erik > Joelsson: > > http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ This one looks good to me. /Magnus > > dl > > On 10/4/19 12:29 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231902 >> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >> >> A recent upstream Graal change causes the META-INF/providers >> directory to contain only a single file, causing the $(GREP) command >> to not prepend the filename to the output.? The simple fix is to >> create an empty file in the directory. >> >> dl > From rwestrel at redhat.com Mon Oct 7 09:12:11 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 07 Oct 2019 11:12:11 +0200 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode In-Reply-To: <874l0l2dhj.fsf@redhat.com> References: <87ftkb4n3u.fsf@redhat.com> <874l0l2dhj.fsf@redhat.com> Message-ID: <87y2xw2a38.fsf@redhat.com> BTW, now that we have range checks CastII, why do we need to test for ConvI2L in merge_point_safe()? Roland. From tobias.hartmann at oracle.com Mon Oct 7 09:12:25 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 7 Oct 2019 11:12:25 +0200 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode In-Reply-To: <874l0l2dhj.fsf@redhat.com> References: <87ftkb4n3u.fsf@redhat.com> <874l0l2dhj.fsf@redhat.com> Message-ID: <69dd1fd7-7363-1d2b-a30f-ff5a70ab87eb@oracle.com> Looks good. Best regards, Tobias On 07.10.19 09:58, Roland Westrelin wrote: > >> looks good to me but the merge_point_safe method is now useless on 32 bit. > > Right. What about this: > > http://cr.openjdk.java.net/~roland/8231620/webrev.01/ > > Roland. > From tobias.hartmann at oracle.com Mon Oct 7 09:21:58 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 7 Oct 2019 11:21:58 +0200 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode In-Reply-To: <87y2xw2a38.fsf@redhat.com> References: <87ftkb4n3u.fsf@redhat.com> <874l0l2dhj.fsf@redhat.com> <87y2xw2a38.fsf@redhat.com> Message-ID: <6c07a822-0d47-4f4a-a6ec-7c9941ca07c1@oracle.com> On 07.10.19 11:12, Roland Westrelin wrote: > BTW, now that we have range checks CastII, why do we need to test for > ConvI2L in merge_point_safe()? I've attempted to remove that code with JDK-8145313 [1] but it seemed that aggressive splitting of ConvI2L nodes through phis lead to less optimal code due to more register spilling. Best regards, Tobias [1] https://bugs.openjdk.java.net/browse/JDK-8145313 From vladimir.x.ivanov at oracle.com Mon Oct 7 10:55:24 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 Oct 2019 13:55:24 +0300 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: > I think sharedRuntime is not a good place for the C2 enum. Agree. I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) and lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. Best regards, Vladimir Ivanov > > Maybe intrinsicnode.hpp would be a better pace for it. But then, the > code in macroAssembler should be guarded by #ifdef COMPILER2. > > Best regards, > > Martin > > *From:*Michihiro Horie > *Sent:* Montag, 7. Oktober 2019 09:14 > *To:* Vladimir Ivanov > *Cc:* hotspot compiler ; > ppc-aix-port-dev at openjdk.java.net; Doerr, Martin > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on Power > > Hi Vladimir, > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > I'm wondering if the enum constants can be declared in sharedRuntime.hpp. > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > > Best regards, > Michihiro > > Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir Ivanov > ---2019/10/04 23:05:48---Hi Michihiro, > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > From: Vladimir Ivanov > > To: Michihiro Horie >, > ppc-aix-port-dev at openjdk.java.net > , hotspot compiler > > > Date: 2019/10/04 23:05 > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on Power > > ------------------------------------------------------------------------ > > > > > Hi Michihiro, > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > + ?switch (rmode) { > + ? ?case 0: // rint > + ? ? ?frin(t, b); > + ? ? ?break; > + ? ?case 1: // floor > + ? ? ?frim(t, b); > + ? ? ?break; > + ? ?case 2: // ceil > + ? ? ?frip(t, b); > + ? ? ?break; > + ? ?default: > + ? ? ?ShouldNotReachHere(); > + ?} > > What do you think about introducing enum constants instead of using > hard-coded 0/1/2? > > src/hotspot/share/opto/library_call.cpp: > > ? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(2))); break; > ? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(1))); break; > ? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(0))); break; > > The downside is you have to move the switch from macroAssembler because > enum should be visible from both places. (Is there a better place for > that than roundD_regNode::emit() in AD file?) > > Best regards, > Vladimir Ivanov > > On 02/10/2019 07:27, Michihiro Horie wrote: >> >> Dear all, >> >> Would you please review the following change? >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 >> >> This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. >> >> Best regards, >> Michihiro >> > > > From vladimir.x.ivanov at oracle.com Mon Oct 7 10:57:48 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 Oct 2019 13:57:48 +0300 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode In-Reply-To: <2f284b47-cd7f-a7ce-22f4-165917182702@oracle.com> References: <87ftkb4n3u.fsf@redhat.com> <2f284b47-cd7f-a7ce-22f4-165917182702@oracle.com> Message-ID: <9ea3db53-1609-83d1-9550-c52761df2fd2@oracle.com> Testing results are clean. Best regards, Vladimir Ivanov On 04/10/2019 17:06, Vladimir Ivanov wrote: > Looks good. > > (Submitted for testing.) > > Best regards, > Vladimir Ivanov > > On 02/10/2019 10:34, Roland Westrelin wrote: >> >> http://cr.openjdk.java.net/~roland/8231620/webrev.00/ >> >> In test1() of the regression test, the loop is unswitched. Once it is >> there are 2 Lock nodes but a single shared FastLock node. Split if then >> happens with the shared FastLock between the If to be split and the >> dominating Region. C2 then crashes in PhaseIdealLoop::split_up() because >> the pattern with the FastLock is unhandled there. merge_point_safe() >> checks for a FastLock node and it is expected to prevent split if when >> that pattern is encountered. But in the case test1(), There's a CastPP >> between the Phi and the FastLock. >> >> test2() of the regression test is similar except that, instead of a >> CastPP, a load node is between the Phi and the FastLock. That one >> crashes the same way but only on 32 bits because a ConvI2L prevents >> split if on 64 bits. >> >> Rather than try to fix merge_point_safe() to handle every node that can >> be in between the FastLock and the Phi, I propose handling FastLock >> nodes in PhaseIdealLoop::split_up() which is AFAICT straightforward. >> >> Roland. >> From vladimir.x.ivanov at oracle.com Mon Oct 7 11:03:11 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 Oct 2019 14:03:11 +0300 Subject: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB731EE6@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> Message-ID: <7f41aab7-4c53-6254-3518-49691d527a6a@oracle.com> > http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.01/ Looks good. Best regards, Vladimir Ivanov > -----Original Message----- > From: Deshpande, Vivek R > Sent: Thursday, September 26, 2019 10:52 AM > To: Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net > Cc: Scott Oaks ; eric.caspole ; Robert Strout > Subject: RE: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors > > Thanks you Vladimir for the review. > I will work on the adding the comments and changes to the bug report. > > Yes the threshold is for architectures after skylake which support AVX512. > With this threshold( value = 4096 bytes found experimentally), AVX512 will be used if the array size is bigger than that. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Wednesday, September 25, 2019 12:41 PM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net > Cc: Scott Oaks ; eric.caspole ; Robert Strout > Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors > > Thank you, Vivek > > I see you did several changes including intrinsics code. Would be nice if you list changes you did in bug report. I see you removed _evex instructions variants in .ad file, replaced evex instructions in stubs and set UseAVX to 2 for Skylake. It is easy to understand. > > But what about array limit AVX3Threshold? I assume it is for non-Skylake CPUs with AVX512. Right? > What number 4096 is based on. It seems AVX3Threshold == 0 has special meaning - add line in globals_x86.hpp explaining it. I would need more time to look on related changes. > > Thanks, > Vladimir > > On 9/3/19 5:02 PM, Deshpande, Vivek R wrote: >> Hi All >> >> I have created a patch which sets AVX2 for Skylake and selectively >> uses EVEX instructions based on threshold for platforms after Skylake. >> I don't observe the regressions for SPECjvm2008 on Skylake with this patch. >> JBS id: >> https://bugs.openjdk.java.net/browse/JDK-8221092 >> Webrev: >> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.00/ >> Could you all please review the patch. >> >> Regards, >> Vivek >> From rwestrel at redhat.com Mon Oct 7 12:03:40 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 07 Oct 2019 14:03:40 +0200 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode In-Reply-To: <9ea3db53-1609-83d1-9550-c52761df2fd2@oracle.com> References: <87ftkb4n3u.fsf@redhat.com> <2f284b47-cd7f-a7ce-22f4-165917182702@oracle.com> <9ea3db53-1609-83d1-9550-c52761df2fd2@oracle.com> Message-ID: <87tv8k225f.fsf@redhat.com> Thanks for the review and testing! Roland. From rwestrel at redhat.com Mon Oct 7 12:03:51 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 07 Oct 2019 14:03:51 +0200 Subject: RFR(S): 8231620: assert(bol->is_Bool()) crash during split if due to FastLockNode In-Reply-To: <69dd1fd7-7363-1d2b-a30f-ff5a70ab87eb@oracle.com> References: <87ftkb4n3u.fsf@redhat.com> <874l0l2dhj.fsf@redhat.com> <69dd1fd7-7363-1d2b-a30f-ff5a70ab87eb@oracle.com> Message-ID: <87r23o2254.fsf@redhat.com> Thanks for the review. Roland. From nils.eliasson at oracle.com Mon Oct 7 12:05:18 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 7 Oct 2019 14:05:18 +0200 Subject: RFR: 8231659: [JVMCI] Could not work PrintAssembly for JVMCI installed code In-Reply-To: <8ee7143a-15cb-5761-528c-c5fa687d89f3@gmail.com> References: <8ee7143a-15cb-5761-528c-c5fa687d89f3@gmail.com> Message-ID: Hi, Related to the code you are changing: The CompilerDirectives is not supposed to be used in that way. The compiler should use the lookup to find a directive at the beginning of a compilation, and then keep using that directive for the entire duration of the compilation. Otherwise you may get different option values. PrintAssembly and PrintNMethod may not cause any failures or inconsistencies at the moment, but is still incorrect. Regards, Nils On 2019-10-01 10:57, Yasumasa Suenaga wrote: > Hi all, > > Please review this change. > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8231659 > ? webrev: https://cr.openjdk.java.net/~ysuenaga/JDK-8231659/webrev.00/ > > PrintAssembly would work in twice for JVMCI installed code before, so > I fixed it in JDK-8180601. > However PrintAseembly would not work for them in JDK 13 or later. It > seems due to JDK-8220623. > > JDK-8220623 lacks print_nmethod() call. Thus I revert JDK-8180601 to > work PrintAssembly. From martin.doerr at sap.com Mon Oct 7 13:08:17 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 7 Oct 2019 13:08:17 +0000 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > and lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. That sounds good. Thanks, Martin > -----Original Message----- > From: Vladimir Ivanov > Sent: Montag, 7. Oktober 2019 12:55 > To: Doerr, Martin ; Michihiro Horie > > Cc: hotspot compiler ; ppc-aix- > port-dev at openjdk.java.net > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > > > I think sharedRuntime is not a good place for the C2 enum. > Agree. > > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > and > lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. > > Best regards, > Vladimir Ivanov > > > > > Maybe intrinsicnode.hpp would be a better pace for it. But then, the > > code in macroAssembler should be guarded by #ifdef COMPILER2. > > > > Best regards, > > > > Martin > > > > *From:*Michihiro Horie > > *Sent:* Montag, 7. Oktober 2019 09:14 > > *To:* Vladimir Ivanov > > *Cc:* hotspot compiler ; > > ppc-aix-port-dev at openjdk.java.net; Doerr, Martin > > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > rint on Power > > > > Hi Vladimir, > > > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > > I'm wondering if the enum constants can be declared in > sharedRuntime.hpp. > > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > > > > Best regards, > > Michihiro > > > > Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi > > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir Ivanov > > ---2019/10/04 23:05:48---Hi Michihiro, > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > > > From: Vladimir Ivanov > > > > To: Michihiro Horie >, > > ppc-aix-port-dev at openjdk.java.net > > , hotspot compiler > > > > > > Date: 2019/10/04 23:05 > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > floor, rint on Power > > > > ------------------------------------------------------------------------ > > > > > > > > > > Hi Michihiro, > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > + ?switch (rmode) { > > + ? ?case 0: // rint > > + ? ? ?frin(t, b); > > + ? ? ?break; > > + ? ?case 1: // floor > > + ? ? ?frim(t, b); > > + ? ? ?break; > > + ? ?case 2: // ceil > > + ? ? ?frip(t, b); > > + ? ? ?break; > > + ? ?default: > > + ? ? ?ShouldNotReachHere(); > > + ?} > > > > What do you think about introducing enum constants instead of using > > hard-coded 0/1/2? > > > > src/hotspot/share/opto/library_call.cpp: > > > > ? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(2))); break; > > ? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(1))); break; > > ? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(0))); break; > > > > The downside is you have to move the switch from macroAssembler > because > > enum should be visible from both places. (Is there a better place for > > that than roundD_regNode::emit() in AD file?) > > > > Best regards, > > Vladimir Ivanov > > > > On 02/10/2019 07:27, Michihiro Horie wrote: > >> > >> Dear all, > >> > >> Would you please review the following change? > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > >> > >> This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on > >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > >> > >> Best regards, > >> Michihiro > >> > > > > > > From HORIE at jp.ibm.com Mon Oct 7 13:31:37 2019 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Mon, 7 Oct 2019 22:31:37 +0900 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: Hi Martin, Vladimir, Thank you for your feedback. Fixed webrev is as follows. http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ Best regards, Michihiro From: "Doerr, Martin" To: Vladimir Ivanov , Michihiro Horie Cc: hotspot compiler , "ppc-aix-port-dev at openjdk.java.net" Date: 2019/10/07 22:09 Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > and lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. That sounds good. Thanks, Martin > -----Original Message----- > From: Vladimir Ivanov > Sent: Montag, 7. Oktober 2019 12:55 > To: Doerr, Martin ; Michihiro Horie > > Cc: hotspot compiler ; ppc-aix- > port-dev at openjdk.java.net > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > > > I think sharedRuntime is not a good place for the C2 enum. > Agree. > > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > and > lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. > > Best regards, > Vladimir Ivanov > > > > > Maybe intrinsicnode.hpp would be a better pace for it. But then, the > > code in macroAssembler should be guarded by #ifdef COMPILER2. > > > > Best regards, > > > > Martin > > > > *From:*Michihiro Horie > > *Sent:* Montag, 7. Oktober 2019 09:14 > > *To:* Vladimir Ivanov > > *Cc:* hotspot compiler ; > > ppc-aix-port-dev at openjdk.java.net; Doerr, Martin > > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > rint on Power > > > > Hi Vladimir, > > > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > > I'm wondering if the enum constants can be declared in > sharedRuntime.hpp. > > Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.02_&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=2mWk2yYwINswKYMG4aJrP-RiIfRSUcPRIcb9foWMZu4&s=wONyvkgYSlTIU5HnJQRZzBDj_ehNS8LTZZQGhePAPB0&e= > > > > Best regards, > > Michihiro > > > > Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi > > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir Ivanov > > ---2019/10/04 23:05:48---Hi Michihiro, > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > > > From: Vladimir Ivanov > > > > To: Michihiro Horie >, > > ppc-aix-port-dev at openjdk.java.net > > , hotspot compiler > > > > > > Date: 2019/10/04 23:05 > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > floor, rint on Power > > > > ------------------------------------------------------------------------ > > > > > > > > > > Hi Michihiro, > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > + ?switch (rmode) { > > + ? ?case 0: // rint > > + ? ? ?frin(t, b); > > + ? ? ?break; > > + ? ?case 1: // floor > > + ? ? ?frim(t, b); > > + ? ? ?break; > > + ? ?case 2: // ceil > > + ? ? ?frip(t, b); > > + ? ? ?break; > > + ? ?default: > > + ? ? ?ShouldNotReachHere(); > > + ?} > > > > What do you think about introducing enum constants instead of using > > hard-coded 0/1/2? > > > > src/hotspot/share/opto/library_call.cpp: > > > > ? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(2))); break; > > ? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(1))); break; > > ? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(0))); break; > > > > The downside is you have to move the switch from macroAssembler > because > > enum should be visible from both places. (Is there a better place for > > that than roundD_regNode::emit() in AD file?) > > > > Best regards, > > Vladimir Ivanov > > > > On 02/10/2019 07:27, Michihiro Horie wrote: > >> > >> Dear all, > >> > >> Would you please review the following change? > >> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8231649&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=2mWk2yYwINswKYMG4aJrP-RiIfRSUcPRIcb9foWMZu4&s=sSCJ80bau3whf3leqnEm1HnTrreRsJWRKhSok40ClWw&e= > >> Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.00&d=DwIFAw&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=2mWk2yYwINswKYMG4aJrP-RiIfRSUcPRIcb9foWMZu4&s=19qkZlAmIAta2qh_zkPfr5M4mXGOj6bZxqweKwwTnlQ&e= > >> > >> This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on > >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > >> > >> Best regards, > >> Michihiro > >> > > > > > > From martin.doerr at sap.com Mon Oct 7 13:43:59 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 7 Oct 2019 13:43:59 +0000 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: Hi Michihiro, please move the implementation into the "instruct" and remove the declarations from macroAssembler_ppc.hpp. If you prefer having the implementation outside of the "instruct", please put it into new "enc_class". Thanks, Martin From: Michihiro Horie Sent: Montag, 7. Oktober 2019 15:32 To: Doerr, Martin Cc: hotspot compiler ; ppc-aix-port-dev at openjdk.java.net; Vladimir Ivanov Subject: RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Hi Martin, Vladimir, Thank you for your feedback. Fixed webrev is as follows. http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ Best regards, Michihiro [Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I suggest to put the enum in RoundDoubleModeNode (convertn]"Doerr, Martin" ---2019/10/07 22:09:15---> I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > and lift instruction selectio From: "Doerr, Martin" > To: Vladimir Ivanov >, Michihiro Horie > Cc: hotspot compiler >, "ppc-aix-port-dev at openjdk.java.net" > Date: 2019/10/07 22:09 Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power ________________________________ > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > and lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. That sounds good. Thanks, Martin > -----Original Message----- > From: Vladimir Ivanov > > Sent: Montag, 7. Oktober 2019 12:55 > To: Doerr, Martin >; Michihiro Horie > > > Cc: hotspot compiler >; ppc-aix- > port-dev at openjdk.java.net > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > > > I think sharedRuntime is not a good place for the C2 enum. > Agree. > > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > and > lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. > > Best regards, > Vladimir Ivanov > > > > > Maybe intrinsicnode.hpp would be a better pace for it. But then, the > > code in macroAssembler should be guarded by #ifdef COMPILER2. > > > > Best regards, > > > > Martin > > > > *From:*Michihiro Horie > > > *Sent:* Montag, 7. Oktober 2019 09:14 > > *To:* Vladimir Ivanov > > > *Cc:* hotspot compiler >; > > ppc-aix-port-dev at openjdk.java.net; Doerr, Martin > > > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > rint on Power > > > > Hi Vladimir, > > > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > > I'm wondering if the enum constants can be declared in > sharedRuntime.hpp. > > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > > > > Best regards, > > Michihiro > > > > Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi > > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir Ivanov > > ---2019/10/04 23:05:48---Hi Michihiro, > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > > > From: Vladimir Ivanov > > > > > To: Michihiro Horie >, > > ppc-aix-port-dev at openjdk.java.net > > , hotspot compiler > > > > > > > Date: 2019/10/04 23:05 > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > floor, rint on Power > > > > ------------------------------------------------------------------------ > > > > > > > > > > Hi Michihiro, > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > + switch (rmode) { > > + case 0: // rint > > + frin(t, b); > > + break; > > + case 1: // floor > > + frim(t, b); > > + break; > > + case 2: // ceil > > + frip(t, b); > > + break; > > + default: > > + ShouldNotReachHere(); > > + } > > > > What do you think about introducing enum constants instead of using > > hard-coded 0/1/2? > > > > src/hotspot/share/opto/library_call.cpp: > > > > case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(2))); break; > > case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(1))); break; > > case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(0))); break; > > > > The downside is you have to move the switch from macroAssembler > because > > enum should be visible from both places. (Is there a better place for > > that than roundD_regNode::emit() in AD file?) > > > > Best regards, > > Vladimir Ivanov > > > > On 02/10/2019 07:27, Michihiro Horie wrote: > >> > >> Dear all, > >> > >> Would you please review the following change? > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > >> > >> This change adds intrinsics for Math's ceil, floor, and rint for PPC64, on > >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > >> > >> Best regards, > >> Michihiro > >> > > > > > > From vladimir.x.ivanov at oracle.com Mon Oct 7 13:51:10 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 Oct 2019 16:51:10 +0300 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: Message-ID: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> > Fixed webrev is as follows. Thanks, Michihiro. > http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ src/hotspot/share/opto/convertnode.hpp: + enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; Please, explicitly initialize the elements. Numbering is important since it is aligned with instruction encoding on x86. src/hotspot/share/opto/library_call.cpp: + case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; Please, change RoundDoubleModeNode to accept the enum instead and instantiate the ConI node inside it or introduce a static factory (::make(GraphKit*,RoundingMode)) for that purpose. src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: + void math_round(const FloatRegister t, const FloatRegister b, int rmode); + void math_round_vec(const VectorSRegister t, const VectorSRegister b, int rmode); I suggest to get rid of helpers in MacroAssembler and simply move the code into corresponding AD instructions. Best regards, Vladimir Ivanov > Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I > suggest to put the enum in RoundDoubleModeNode (convertn"Doerr, Martin" > ---2019/10/07 22:09:15---> I suggest to put the enum in > RoundDoubleModeNode (convertnode.hpp) > and lift instruction selectio > > From: "Doerr, Martin" > To: Vladimir Ivanov , Michihiro Horie > > Cc: hotspot compiler , > "ppc-aix-port-dev at openjdk.java.net" > Date: 2019/10/07 22:09 > Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on Power > > ------------------------------------------------------------------------ > > > > > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > > and lift instruction selection logic from macroAssembler_ppc.cpp into > ppc.ad. > That sounds good. > > Thanks, > Martin > > > > -----Original Message----- > > From: Vladimir Ivanov > > Sent: Montag, 7. Oktober 2019 12:55 > > To: Doerr, Martin ; Michihiro Horie > > > > Cc: hotspot compiler ; ppc-aix- > > port-dev at openjdk.java.net > > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on Power > > > > > I think sharedRuntime is not a good place for the C2 enum. > > Agree. > > > > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > > and > > lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. > > > > Best regards, > > Vladimir Ivanov > > > > > > > > Maybe intrinsicnode.hpp would be a better pace for it. But then, the > > > code in macroAssembler should be guarded by #ifdef COMPILER2. > > > > > > Best regards, > > > > > > Martin > > > > > > *From:*Michihiro Horie > > > *Sent:* Montag, 7. Oktober 2019 09:14 > > > *To:* Vladimir Ivanov > > > *Cc:* hotspot compiler ; > > > ppc-aix-port-dev at openjdk.java.net; Doerr, Martin > > > > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > > rint on Power > > > > > > Hi Vladimir, > > > > > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > > > I'm wondering if the enum constants can be declared in > > sharedRuntime.hpp. > > > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > > > > > > Best regards, > > > Michihiro > > > > > > Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi > > > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir Ivanov > > > ---2019/10/04 23:05:48---Hi Michihiro, > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > > > > > From: Vladimir Ivanov > > > > > > To: Michihiro Horie >, > > > ppc-aix-port-dev at openjdk.java.net > > > , hotspot compiler > > > > > > > > > Date: 2019/10/04 23:05 > > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > > floor, rint on Power > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > Hi Michihiro, > > > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > > + ?switch (rmode) { > > > + ? ?case 0: // rint > > > + ? ? ?frin(t, b); > > > + ? ? ?break; > > > + ? ?case 1: // floor > > > + ? ? ?frim(t, b); > > > + ? ? ?break; > > > + ? ?case 2: // ceil > > > + ? ? ?frip(t, b); > > > + ? ? ?break; > > > + ? ?default: > > > + ? ? ?ShouldNotReachHere(); > > > + ?} > > > > > > What do you think about introducing enum constants instead of using > > > hard-coded 0/1/2? > > > > > > src/hotspot/share/opto/library_call.cpp: > > > > > > ?? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(2))); break; > > > ?? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(1))); break; > > > ?? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(0))); break; > > > > > > The downside is you have to move the switch from macroAssembler > > because > > > enum should be visible from both places. (Is there a better place for > > > that than roundD_regNode::emit() in AD file?) > > > > > > Best regards, > > > Vladimir Ivanov > > > > > > On 02/10/2019 07:27, Michihiro Horie wrote: > > >> > > >> Dear all, > > >> > > >> Would you please review the following change? > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > > >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > > >> > > >> This change adds intrinsics for Math's ceil, floor, and rint for > PPC64, on > > >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > > >> > > >> Best regards, > > >> Michihiro > > >> > > > > > > > > > > > > > From erik.joelsson at oracle.com Mon Oct 7 15:20:57 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 7 Oct 2019 08:20:57 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> References: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> Message-ID: <994c7bcf-1632-fe1a-fad3-a58d17371730@oracle.com> Looks good! Thanks! /Erik On 2019-10-04 15:09, dean.long at oracle.com wrote: > Here's an alternative version with $(NAWK) usage suggested by Erik > Joelsson: > > http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ > > dl > > On 10/4/19 12:29 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231902 >> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >> >> A recent upstream Graal change causes the META-INF/providers >> directory to contain only a single file, causing the $(GREP) command >> to not prepend the filename to the output.? The simple fix is to >> create an empty file in the directory. >> >> dl > From HORIE at jp.ibm.com Mon Oct 7 15:54:23 2019 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Tue, 8 Oct 2019 00:54:23 +0900 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> Message-ID: Hi Martin, Vladimir, Thanks a lot for your further feedback, which makes sense. New webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ Best regards, Michihiro From: Vladimir Ivanov To: Michihiro Horie , "Doerr, Martin" Cc: hotspot compiler , "ppc-aix-port-dev at openjdk.java.net" Date: 2019/10/07 22:51 Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > Fixed webrev is as follows. Thanks, Michihiro. > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.03_&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=v7cz3cWllApJ_IFf4LHkc5TbcqZTtP_3jrA5HUG0YvQ&s=uOsX2e2oMxbLhGTFmTLD3P8VaAPDCrNJ8jgkUCjPCr0&e= src/hotspot/share/opto/convertnode.hpp: + enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; Please, explicitly initialize the elements. Numbering is important since it is aligned with instruction encoding on x86. src/hotspot/share/opto/library_call.cpp: + case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; Please, change RoundDoubleModeNode to accept the enum instead and instantiate the ConI node inside it or introduce a static factory (::make(GraphKit*,RoundingMode)) for that purpose. src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: + void math_round(const FloatRegister t, const FloatRegister b, int rmode); + void math_round_vec(const VectorSRegister t, const VectorSRegister b, int rmode); I suggest to get rid of helpers in MacroAssembler and simply move the code into corresponding AD instructions. Best regards, Vladimir Ivanov > Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I > suggest to put the enum in RoundDoubleModeNode (convertn"Doerr, Martin" > ---2019/10/07 22:09:15---> I suggest to put the enum in > RoundDoubleModeNode (convertnode.hpp) > and lift instruction selectio > > From: "Doerr, Martin" > To: Vladimir Ivanov , Michihiro Horie > > Cc: hotspot compiler , > "ppc-aix-port-dev at openjdk.java.net" > Date: 2019/10/07 22:09 > Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on Power > > ------------------------------------------------------------------------ > > > > > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > > and lift instruction selection logic from macroAssembler_ppc.cpp into > ppc.ad. > That sounds good. > > Thanks, > Martin > > > > -----Original Message----- > > From: Vladimir Ivanov > > Sent: Montag, 7. Oktober 2019 12:55 > > To: Doerr, Martin ; Michihiro Horie > > > > Cc: hotspot compiler ; ppc-aix- > > port-dev at openjdk.java.net > > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on Power > > > > > I think sharedRuntime is not a good place for the C2 enum. > > Agree. > > > > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > > and > > lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. > > > > Best regards, > > Vladimir Ivanov > > > > > > > > Maybe intrinsicnode.hpp would be a better pace for it. But then, the > > > code in macroAssembler should be guarded by #ifdef COMPILER2. > > > > > > Best regards, > > > > > > Martin > > > > > > *From:*Michihiro Horie > > > *Sent:* Montag, 7. Oktober 2019 09:14 > > > *To:* Vladimir Ivanov > > > *Cc:* hotspot compiler ; > > > ppc-aix-port-dev at openjdk.java.net; Doerr, Martin > > > > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > > rint on Power > > > > > > Hi Vladimir, > > > > > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > > > I'm wondering if the enum constants can be declared in > > sharedRuntime.hpp. > > > Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.02_&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=v7cz3cWllApJ_IFf4LHkc5TbcqZTtP_3jrA5HUG0YvQ&s=QqRnoTYJ2LA36FkYoBNfzTWQpgOfUwW6fpNwqVkKLcc&e= > > > > > > Best regards, > > > Michihiro > > > > > > Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi > > > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir Ivanov > > > ---2019/10/04 23:05:48---Hi Michihiro, > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > > > > > From: Vladimir Ivanov > > > > > > To: Michihiro Horie >, > > > ppc-aix-port-dev at openjdk.java.net > > > , hotspot compiler > > > > > > > > > Date: 2019/10/04 23:05 > > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > > floor, rint on Power > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > Hi Michihiro, > > > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > > + ?switch (rmode) { > > > + ? ?case 0: // rint > > > + ? ? ?frin(t, b); > > > + ? ? ?break; > > > + ? ?case 1: // floor > > > + ? ? ?frim(t, b); > > > + ? ? ?break; > > > + ? ?case 2: // ceil > > > + ? ? ?frip(t, b); > > > + ? ? ?break; > > > + ? ?default: > > > + ? ? ?ShouldNotReachHere(); > > > + ?} > > > > > > What do you think about introducing enum constants instead of using > > > hard-coded 0/1/2? > > > > > > src/hotspot/share/opto/library_call.cpp: > > > > > > ?? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(2))); break; > > > ?? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(1))); break; > > > ?? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(0))); break; > > > > > > The downside is you have to move the switch from macroAssembler > > because > > > enum should be visible from both places. (Is there a better place for > > > that than roundD_regNode::emit() in AD file?) > > > > > > Best regards, > > > Vladimir Ivanov > > > > > > On 02/10/2019 07:27, Michihiro Horie wrote: > > >> > > >> Dear all, > > >> > > >> Would you please review the following change? > > >> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8231649&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=v7cz3cWllApJ_IFf4LHkc5TbcqZTtP_3jrA5HUG0YvQ&s=IQxoK14NCUxCVzAfHNqAImAnQDayn6Yll9vYTtFXR0I&e= > > >> Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.00&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=v7cz3cWllApJ_IFf4LHkc5TbcqZTtP_3jrA5HUG0YvQ&s=Fl6YXvxk9_YvXDPTaTFX9IYMfRtdpWgOF2rJak2SyYg&e= > > >> > > >> This change adds intrinsics for Math's ceil, floor, and rint for > PPC64, on > > >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > > >> > > >> Best regards, > > >> Michihiro > > >> > > > > > > > > > > > > > From vladimir.x.ivanov at oracle.com Mon Oct 7 16:20:48 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 Oct 2019 19:20:48 +0300 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> Message-ID: <4da2ec93-e1da-9fc5-4bca-40dfc461f286@oracle.com> > New webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ src/hotspot/share/opto/convertnode.hpp: + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, ConINode::make(rmode)) {} ConINode::make() allocates a new node which has to be seen by GVN, so there's a type recorded for it. That's why I mentioned GraphKit*. But you can use PhaseGVN & intcon as well. Otherwise, looks good. Best regards, Vladimir Ivanov > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, Michihiro. > > From: Vladimir Ivanov > To: Michihiro Horie , "Doerr, Martin" > > Cc: hotspot compiler , > "ppc-aix-port-dev at openjdk.java.net" > Date: 2019/10/07 22:51 > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on Power > > ------------------------------------------------------------------------ > > > > > > Fixed webrev is as follows. > > Thanks, Michihiro. > > > http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ > > src/hotspot/share/opto/convertnode.hpp: > > + ?enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > > Please, explicitly initialize the elements. Numbering is important since > it is aligned with instruction encoding on x86. > > > src/hotspot/share/opto/library_call.cpp: > > + ?case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > Please, change RoundDoubleModeNode to accept the enum instead and > instantiate the ConI node inside it or introduce a static factory > (::make(GraphKit*,RoundingMode)) for that purpose. > > > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > > + ?void math_round(const FloatRegister t, const FloatRegister b, int rmode); > + ?void math_round_vec(const VectorSRegister t, const VectorSRegister b, > int rmode); > > I suggest to get rid of helpers in MacroAssembler and simply move the > code into corresponding AD instructions. > > Best regards, > Vladimir Ivanov > > > Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I > > suggest to put the enum in RoundDoubleModeNode (convertn"Doerr, Martin" > > ---2019/10/07 22:09:15---> I suggest to put the enum in > > RoundDoubleModeNode (convertnode.hpp) > and lift instruction selectio > > > > From: "Doerr, Martin" > > To: Vladimir Ivanov , Michihiro Horie > > > > Cc: hotspot compiler , > > "ppc-aix-port-dev at openjdk.java.net" > > Date: 2019/10/07 22:09 > > Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > floor, rint on Power > > > > ------------------------------------------------------------------------ > > > > > > > > ?> I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > > ?> and lift instruction selection logic from macroAssembler_ppc.cpp into > > ppc.ad. > > That sounds good. > > > > Thanks, > > Martin > > > > > > ?> -----Original Message----- > > ?> From: Vladimir Ivanov > > ?> Sent: Montag, 7. Oktober 2019 12:55 > > ?> To: Doerr, Martin ; Michihiro Horie > > ?> > > ?> Cc: hotspot compiler ; ppc-aix- > > ?> port-dev at openjdk.java.net > > ?> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > rint on Power > > ?> > > ?> > I think sharedRuntime is not a good place for the C2 enum. > > ?> Agree. > > ?> > > ?> I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > > ?> and > > ?> lift instruction selection logic from macroAssembler_ppc.cpp into > ppc.ad. > > ?> > > ?> Best regards, > > ?> Vladimir Ivanov > > ?> > > ?> > > > ?> > Maybe intrinsicnode.hpp would be a better pace for it. But then, the > > ?> > code in macroAssembler should be guarded by #ifdef COMPILER2. > > ?> > > > ?> > Best regards, > > ?> > > > ?> > Martin > > ?> > > > ?> > *From:*Michihiro Horie > > ?> > *Sent:* Montag, 7. Oktober 2019 09:14 > > ?> > *To:* Vladimir Ivanov > > ?> > *Cc:* hotspot compiler ; > > ?> > ppc-aix-port-dev at openjdk.java.net; Doerr, Martin > > ?> > > ?> > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > ?> > rint on Power > > ?> > > > ?> > Hi Vladimir, > > ?> > > > ?> > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > > ?> > I'm wondering if the enum constants can be declared in > > ?> sharedRuntime.hpp. > > ?> > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > > ?> > > > ?> > Best regards, > > ?> > Michihiro > > ?> > > > ?> > Inactive hide details for Vladimir Ivanov ---2019/10/04 > 23:05:48---Hi > > ?> > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > Ivanov > > ?> > ---2019/10/04 23:05:48---Hi Michihiro, > > ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > ?> > > > ?> > From: Vladimir Ivanov > ?> > > > > ?> > To: Michihiro Horie >, > > ?> > ppc-aix-port-dev at openjdk.java.net > > ?> > , hotspot compiler > > ?> > > ?> > > > > ?> > Date: 2019/10/04 23:05 > > ?> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, > > ?> > floor, rint on Power > > ?> > > > ?> > > > ------------------------------------------------------------------------ > > ?> > > > ?> > > > ?> > > > ?> > > > ?> > Hi Michihiro, > > ?> > > > ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > ?> > + ?switch (rmode) { > > ?> > + ? ?case 0: // rint > > ?> > + ? ? ?frin(t, b); > > ?> > + ? ? ?break; > > ?> > + ? ?case 1: // floor > > ?> > + ? ? ?frim(t, b); > > ?> > + ? ? ?break; > > ?> > + ? ?case 2: // ceil > > ?> > + ? ? ?frip(t, b); > > ?> > + ? ? ?break; > > ?> > + ? ?default: > > ?> > + ? ? ?ShouldNotReachHere(); > > ?> > + ?} > > ?> > > > ?> > What do you think about introducing enum constants instead of using > > ?> > hard-coded 0/1/2? > > ?> > > > ?> > src/hotspot/share/opto/library_call.cpp: > > ?> > > > ?> > ?? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > > ?> > makecon(TypeInt::make(2))); break; > > ?> > ?? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, > > ?> > makecon(TypeInt::make(1))); break; > > ?> > ?? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, > > ?> > makecon(TypeInt::make(0))); break; > > ?> > > > ?> > The downside is you have to move the switch from macroAssembler > > ?> because > > ?> > enum should be visible from both places. (Is there a better > place for > > ?> > that than roundD_regNode::emit() in AD file?) > > ?> > > > ?> > Best regards, > > ?> > Vladimir Ivanov > > ?> > > > ?> > On 02/10/2019 07:27, Michihiro Horie wrote: > > ?> >> > > ?> >> Dear all, > > ?> >> > > ?> >> Would you please review the following change? > > ?> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > > ?> >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > > ?> >> > > ?> >> This change adds intrinsics for Math's ceil, floor, and rint for > > PPC64, on > > ?> >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > > ?> >> > > ?> >> Best regards, > > ?> >> Michihiro > > ?> >> > > ?> > > > ?> > > > ?> > > > > > > > > > > > > > From tom.rodriguez at oracle.com Mon Oct 7 17:11:05 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 7 Oct 2019 10:11:05 -0700 Subject: RFR(S) 8231586: enlarge encoding space for OopMapValue offsets In-Reply-To: <5ff481d6-f440-90d6-6f04-3576879afbf5@oracle.com> References: <92e6a5a2-c806-843d-a8e0-84f0aa3718b7@oracle.com> <6fa4389f-81f2-7591-de61-9edc60a18187@oracle.com> <5ff481d6-f440-90d6-6f04-3576879afbf5@oracle.com> Message-ID: dean.long at oracle.com wrote on 10/5/19 9:25 PM: > You're right, my mistake.? Your change looks good.? I was actually > looking at the set_* methods in OopMapValue, not OopMap, and incorrectly > thought the | would preserve the previous value.? On closer inspection, > it doesn't, and those methods don't even get called, because the ctor > uses a different set method.? Can we remove these unused methods? Good idea. I've deleted those along with some other dead methods and rearranged the code a little bit to hide more of the API so it's clearer what might be done to an OopMapValue. The delta webrev is just my changes and the .1 webrev is the full new webrev. I'm submitting a mach5 run now. http://cr.openjdk.java.net/~never/8231586-delta/webrev/ http://cr.openjdk.java.net/~never/8231586.1/webrev/ tom > > ??? void set_oop()????????????? { set_value((value() & > register_mask_in_place) | oop_value); } > ??? void set_narrowoop()????????? { set_value((value() & > register_mask_in_place) | narrowoop_value); } > ??? void set_callee_saved()???? { set_value((value() & > register_mask_in_place) | callee_saved_value); } > ??? void set_derived_oop()????? { set_value((value() & > register_mask_in_place) | derived_oop_value); } > > dl > > On 10/5/19 10:41 AM, Tom Rodriguez wrote: >> >> >> dean.long at oracle.com wrote on 10/4/19 4:27 PM: >>> It's not obvious that we only set 1 bit. The set methods don't >>> enforce that.? And this code looks like it is setting both "derived" >>> and "oop": >> >> Each of those calls produce independent OopMapValues. >> http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/compiler/oopMap.cpp#l137 >> ?Also all tests against the type are equality tests, not bitmasks, so >> if more than one bit was set it would fail to match anything. The >> bitmask-ness of the values is only used for filtering the iteration. >> >> tom >> >>> >>> http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/opto/buildOopMap.cpp#l315 >>> >>> >>> dl >>> >>> On 10/4/19 10:26 AM, Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/8231586/webrev >>>> https://bugs.openjdk.java.net/browse/JDK-8231586 >>>> >>>> The current OopMapValue encoding uses a bit mask for each value even >>>> though only one bit is ever set.? Since only 16 bits are available >>>> for encoding this limits the offsets it can express. Compilation >>>> with a large number of stack slots can bailout because of this >>>> limit.? This changes the encoding to use 2 bits which gives 2 bits >>>> back to the offset. >>>> >>>> I also deleted some StressDerivedPointers machinery that's been >>>> completely unimplemented for years (decades?).? The flag itself is >>>> now dead but I wasn't sure if there are test references to it >>>> somewhere. Should I delete the flag as well? >>>> >>>> mach5 testing is in progress. >>>> >>>> tom >>> > From martin.doerr at sap.com Mon Oct 7 17:16:09 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 7 Oct 2019 17:16:09 +0000 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> Message-ID: Hi Michihiro, thanks for improving it. I think it would be better to use adlc's include generator instead of including "opto/convertnode.hpp" explicitly in the ad file. src/hotspot/share/adlc/main.cpp AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); + AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); @Vladimir: Do you agree? Would you do it this way, too? Otherwise, the change looks good to me. Best regards, Martin From: Michihiro Horie Sent: Montag, 7. Oktober 2019 17:54 To: Vladimir Ivanov Cc: hotspot compiler ; Doerr, Martin ; ppc-aix-port-dev at openjdk.java.net Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Hi Martin, Vladimir, Thanks a lot for your further feedback, which makes sense. New webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ Best regards, Michihiro [Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, Michihiro.]Vladimir Ivanov ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, Michihiro. From: Vladimir Ivanov > To: Michihiro Horie >, "Doerr, Martin" > Cc: hotspot compiler >, "ppc-aix-port-dev at openjdk.java.net" > Date: 2019/10/07 22:51 Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power ________________________________ > Fixed webrev is as follows. Thanks, Michihiro. > http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ src/hotspot/share/opto/convertnode.hpp: + enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; Please, explicitly initialize the elements. Numbering is important since it is aligned with instruction encoding on x86. src/hotspot/share/opto/library_call.cpp: + case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; Please, change RoundDoubleModeNode to accept the enum instead and instantiate the ConI node inside it or introduce a static factory (::make(GraphKit*,RoundingMode)) for that purpose. src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: + void math_round(const FloatRegister t, const FloatRegister b, int rmode); + void math_round_vec(const VectorSRegister t, const VectorSRegister b, int rmode); I suggest to get rid of helpers in MacroAssembler and simply move the code into corresponding AD instructions. Best regards, Vladimir Ivanov > Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I > suggest to put the enum in RoundDoubleModeNode (convertn"Doerr, Martin" > ---2019/10/07 22:09:15---> I suggest to put the enum in > RoundDoubleModeNode (convertnode.hpp) > and lift instruction selectio > > From: "Doerr, Martin" > > To: Vladimir Ivanov >, Michihiro Horie > > > Cc: hotspot compiler >, > "ppc-aix-port-dev at openjdk.java.net" > > Date: 2019/10/07 22:09 > Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on Power > > ------------------------------------------------------------------------ > > > > > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > > and lift instruction selection logic from macroAssembler_ppc.cpp into > ppc.ad. > That sounds good. > > Thanks, > Martin > > > > -----Original Message----- > > From: Vladimir Ivanov > > > Sent: Montag, 7. Oktober 2019 12:55 > > To: Doerr, Martin >; Michihiro Horie > > > > > Cc: hotspot compiler >; ppc-aix- > > port-dev at openjdk.java.net > > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on Power > > > > > I think sharedRuntime is not a good place for the C2 enum. > > Agree. > > > > I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > > and > > lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. > > > > Best regards, > > Vladimir Ivanov > > > > > > > > Maybe intrinsicnode.hpp would be a better pace for it. But then, the > > > code in macroAssembler should be guarded by #ifdef COMPILER2. > > > > > > Best regards, > > > > > > Martin > > > > > > *From:*Michihiro Horie > > > > *Sent:* Montag, 7. Oktober 2019 09:14 > > > *To:* Vladimir Ivanov > > > > *Cc:* hotspot compiler >; > > > ppc-aix-port-dev at openjdk.java.net; Doerr, Martin > > > > > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > > rint on Power > > > > > > Hi Vladimir, > > > > > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > > > I'm wondering if the enum constants can be declared in > > sharedRuntime.hpp. > > > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > > > > > > Best regards, > > > Michihiro > > > > > > Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi > > > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir Ivanov > > > ---2019/10/04 23:05:48---Hi Michihiro, > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > > > > > From: Vladimir Ivanov > > > > > > > To: Michihiro Horie >, > > > ppc-aix-port-dev at openjdk.java.net > > > , hotspot compiler > > > > > > > > > > Date: 2019/10/04 23:05 > > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > > floor, rint on Power > > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > Hi Michihiro, > > > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > > + switch (rmode) { > > > + case 0: // rint > > > + frin(t, b); > > > + break; > > > + case 1: // floor > > > + frim(t, b); > > > + break; > > > + case 2: // ceil > > > + frip(t, b); > > > + break; > > > + default: > > > + ShouldNotReachHere(); > > > + } > > > > > > What do you think about introducing enum constants instead of using > > > hard-coded 0/1/2? > > > > > > src/hotspot/share/opto/library_call.cpp: > > > > > > case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(2))); break; > > > case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(1))); break; > > > case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(0))); break; > > > > > > The downside is you have to move the switch from macroAssembler > > because > > > enum should be visible from both places. (Is there a better place for > > > that than roundD_regNode::emit() in AD file?) > > > > > > Best regards, > > > Vladimir Ivanov > > > > > > On 02/10/2019 07:27, Michihiro Horie wrote: > > >> > > >> Dear all, > > >> > > >> Would you please review the following change? > > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > > >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > > >> > > >> This change adds intrinsics for Math's ceil, floor, and rint for > PPC64, on > > >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > > >> > > >> Best regards, > > >> Michihiro > > >> > > > > > > > > > > > > > From vladimir.x.ivanov at oracle.com Mon Oct 7 17:18:09 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 Oct 2019 20:18:09 +0300 Subject: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors In-Reply-To: <7f41aab7-4c53-6254-3518-49691d527a6a@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB731EE6@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> <7f41aab7-4c53-6254-3518-49691d527a6a@oracle.com> Message-ID: <6dd7c943-c79e-c384-c94e-c3ad16f8c7a5@oracle.com> Vivek, Thinking more about it, I got a question: src/hotspot/cpu/x86/x86.ad: instruct Repl4F_zero(vecX dst, immF0 zero) %{ - predicate(n->as_Vector()->length() == 4 && UseAVX < 3); + predicate(n->as_Vector()->length() == 4); match(Set dst (ReplicateF zero)); format %{ "xorps $dst,$dst\t! replicate4F zero" %} ins_encode %{ __ xorps($dst$$XMMRegister, $dst$$XMMRegister); %} ins_pipe( fpu_reg_reg ); %} -instruct Repl4F_zero_evex(vecX dst, immF0 zero) %{ - predicate(n->as_Vector()->length() == 4 && UseAVX > 2); - match(Set dst (ReplicateF zero)); - format %{ "vpxor $dst k0,$dst,$dst\t! replicate4F zero" %} - ins_encode %{ - // Use vpxor in place of vxorps since EVEX has a constriant on dq for vxorps: this is a 512-bit operation - int vector_len = 2; - __ vpxor($dst$$XMMRegister,$dst$$XMMRegister, $dst$$XMMRegister, vector_len); - %} - ins_pipe( fpu_reg_reg ); -%} Any issues with vecX when encoding xorps with dst in higher half (xmm16-31) without avx512vl support? Should it be turned to legVecX? Also: // Load vectors (16 bytes long) instruct MoveVecX2Leg(legVecX dst, vecX src) %{ match(Set dst src); format %{ "movdqu $dst,$src\t! load vector (16 bytes)" %} ins_encode %{ if (UseAVX > 2 && !VM_Version::supports_avx512vl()) { int vector_len = 2; __ evmovdquq($dst$$XMMRegister, $src$$XMMRegister, vector_len); } else { __ movdqu($dst$$XMMRegister, $src$$XMMRegister); } %} ins_pipe( fpu_reg_reg ); %} From performance perspective, does it make any sense to further limit EVEX-encoded case when src is in lower half of the range (0-15)? Best regards, Vladimir Ivanov On 07/10/2019 14:03, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.01/ > > Looks good. > > Best regards, > Vladimir Ivanov > >> -----Original Message----- >> From: Deshpande, Vivek R >> Sent: Thursday, September 26, 2019 10:52 AM >> To: Vladimir Kozlov ; >> hotspot-compiler-dev at openjdk.java.net >> Cc: Scott Oaks ; eric.caspole >> ; Robert Strout >> Subject: RE: RFR: 8221092: UseAVX=3 has performance degredation on >> Skylake (X7) processors >> >> Thanks you Vladimir for the review. >> I will work on the adding the comments and changes to the bug report. >> >> Yes the threshold is for architectures after skylake which support >> AVX512. >> With this threshold( value = 4096 bytes found experimentally), AVX512 >> will be used if the array size is bigger than that. >> >> Regards, >> Vivek >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, September 25, 2019 12:41 PM >> To: Deshpande, Vivek R ; >> hotspot-compiler-dev at openjdk.java.net >> Cc: Scott Oaks ; eric.caspole >> ; Robert Strout >> Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on >> Skylake (X7) processors >> >> Thank you, Vivek >> >> I see you did several changes including intrinsics code. Would be nice >> if you list changes you did in bug report. I see you removed _evex >> instructions variants in .ad file, replaced evex instructions in stubs >> and set UseAVX to 2 for Skylake. It is easy to understand. >> >> But what about array limit AVX3Threshold? I assume it is for >> non-Skylake CPUs with AVX512. Right? >> What number 4096 is based on. It seems AVX3Threshold == 0 has special >> meaning - add line in globals_x86.hpp explaining it. I would need more >> time to look on related changes. >> >> Thanks, >> Vladimir >> >> On 9/3/19 5:02 PM, Deshpande, Vivek R wrote: >>> Hi All >>> >>> I have created a patch which sets AVX2 for Skylake and selectively >>> uses EVEX instructions based on threshold for platforms after Skylake. >>> I don't observe the regressions for SPECjvm2008 on Skylake with this >>> patch. >>> JBS id: >>> https://bugs.openjdk.java.net/browse/JDK-8221092 >>> Webrev: >>> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.00/ >>> Could you all please review the patch. >>> >>> Regards, >>> Vivek >>> From vladimir.x.ivanov at oracle.com Mon Oct 7 17:31:15 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 7 Oct 2019 20:31:15 +0300 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> Message-ID: <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> > I think it would be better to use adlc?s include generator instead of > including "opto/convertnode.hpp" explicitly in the ad file. > > src/hotspot/share/adlc/main.cpp > > ?? AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > > +? AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > > ?? AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > > @Vladimir: Do you agree? Would you do it this way, too? I prefer current version. When proposing the refactoring I thought about the change in adlc as well, but when I saw the patch I noticed that putting it in AD file stresses it's a platform-specific dependency. I think that's the right way to look at it until we get a way to funnel attributes from ideal nodes to mach nodes and use them during code emission. Best regards, Vladimir Ivanov > *From:*Michihiro Horie > *Sent:* Montag, 7. Oktober 2019 17:54 > *To:* Vladimir Ivanov > *Cc:* hotspot compiler ; Doerr, > Martin ; ppc-aix-port-dev at openjdk.java.net > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on Power > > Hi Martin, Vladimir, > Thanks a lot for your further feedback, which makes sense. > > New webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ > > Best regards, > Michihiro > > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, Michihiro. > > From: Vladimir Ivanov > > To: Michihiro Horie >, > "Doerr, Martin" > > Cc: hotspot compiler >, > "ppc-aix-port-dev at openjdk.java.net > " > > > Date: 2019/10/07 22:51 > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on Power > > ------------------------------------------------------------------------ > > > > > >> Fixed webrev is as follows. > > Thanks, Michihiro. > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ > > src/hotspot/share/opto/convertnode.hpp: > > + ?enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > > Please, explicitly initialize the elements. Numbering is important since > it is aligned with instruction encoding on x86. > > > src/hotspot/share/opto/library_call.cpp: > > + ?case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > Please, change RoundDoubleModeNode to accept the enum instead and > instantiate the ConI node inside it or introduce a static factory > (::make(GraphKit*,RoundingMode)) for that purpose. > > > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > > + ?void math_round(const FloatRegister t, const FloatRegister b, int rmode); > + ?void math_round_vec(const VectorSRegister t, const VectorSRegister b, > int rmode); > > I suggest to get rid of helpers in MacroAssembler and simply move the > code into corresponding AD instructions. > > Best regards, > Vladimir Ivanov > >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I >> suggest to put the enum in RoundDoubleModeNode (convertn"Doerr, Martin" >> ---2019/10/07 22:09:15---> I suggest to put the enum in >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction selectio >> >> From: "Doerr, Martin" > >> To: Vladimir Ivanov >, > Michihiro Horie >> > >> Cc: hotspot compiler >, >> "ppc-aix-port-dev at openjdk.java.net > " > > >> Date: 2019/10/07 22:09 >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, >> floor, rint on Power >> >> ------------------------------------------------------------------------ >> >> >> >> ?> I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) >> ?> and lift instruction selection logic from macroAssembler_ppc.cpp into >> ppc.ad. >> That sounds good. >> >> Thanks, >> Martin >> >> >> ?> -----Original Message----- >> ?> From: Vladimir Ivanov > >> ?> Sent: Montag, 7. Oktober 2019 12:55 >> ?> To: Doerr, Martin >; Michihiro Horie >> ?> > >> ?> Cc: hotspot compiler >; ppc-aix- >> ?> port-dev at openjdk.java.net >> ?> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, >> rint on Power >> ?> >> ?> > I think sharedRuntime is not a good place for the C2 enum. >> ?> Agree. >> ?> >> ?> I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) >> ?> and >> ?> lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. >> ?> >> ?> Best regards, >> ?> Vladimir Ivanov >> ?> >> ?> > >> ?> > Maybe intrinsicnode.hpp would be a better pace for it. But then, the >> ?> > code in macroAssembler should be guarded by #ifdef COMPILER2. >> ?> > >> ?> > Best regards, >> ?> > >> ?> > Martin >> ?> > >> ?> > *From:*Michihiro Horie > >> ?> > *Sent:* Montag, 7. Oktober 2019 09:14 >> ?> > *To:* Vladimir Ivanov > >> ?> > *Cc:* hotspot compiler >; >> ?> > ppc-aix-port-dev at openjdk.java.net > ; Doerr, Martin >> ?> > >> ?> > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, >> ?> > rint on Power >> ?> > >> ?> > Hi Vladimir, >> ?> > >> ?> > Thanks a lot for your nice suggestion. Yes, I prefer enum use. >> ?> > I'm wondering if the enum constants can be declared in >> ?> sharedRuntime.hpp. >> ?> > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ >> ?> > >> ?> > Best regards, >> ?> > Michihiro >> ?> > >> ?> > Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi >> ?> > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir Ivanov >> ?> > ---2019/10/04 23:05:48---Hi Michihiro, >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: >> ?> > >> ?> > From: Vladimir Ivanov > ?> > > > >> ?> > To: Michihiro Horie >, >> ?> > ppc-aix-port-dev at openjdk.java.net >> ?> > , hotspot compiler >> ?> > > ?> > > > >> ?> > Date: 2019/10/04 23:05 >> ?> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, >> ?> > floor, rint on Power >> ?> > >> ?> > >> ------------------------------------------------------------------------ >> ?> > >> ?> > >> ?> > >> ?> > >> ?> > Hi Michihiro, >> ?> > >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: >> ?> > + ?switch (rmode) { >> ?> > + ? ?case 0: // rint >> ?> > + ? ? ?frin(t, b); >> ?> > + ? ? ?break; >> ?> > + ? ?case 1: // floor >> ?> > + ? ? ?frim(t, b); >> ?> > + ? ? ?break; >> ?> > + ? ?case 2: // ceil >> ?> > + ? ? ?frip(t, b); >> ?> > + ? ? ?break; >> ?> > + ? ?default: >> ?> > + ? ? ?ShouldNotReachHere(); >> ?> > + ?} >> ?> > >> ?> > What do you think about introducing enum constants instead of using >> ?> > hard-coded 0/1/2? >> ?> > >> ?> > src/hotspot/share/opto/library_call.cpp: >> ?> > >> ?> > ?? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, >> ?> > makecon(TypeInt::make(2))); break; >> ?> > ?? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, >> ?> > makecon(TypeInt::make(1))); break; >> ?> > ?? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, >> ?> > makecon(TypeInt::make(0))); break; >> ?> > >> ?> > The downside is you have to move the switch from macroAssembler >> ?> because >> ?> > enum should be visible from both places. (Is there a better place for >> ?> > that than roundD_regNode::emit() in AD file?) >> ?> > >> ?> > Best regards, >> ?> > Vladimir Ivanov >> ?> > >> ?> > On 02/10/2019 07:27, Michihiro Horie wrote: >> ?> >> >> ?> >> Dear all, >> ?> >> >> ?> >> Would you please review the following change? >> ?> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 >> ?> >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 >> ?> >> >> ?> >> This change adds intrinsics for Math's ceil, floor, and rint for >> PPC64, on >> ?> >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. >> ?> >> >> ?> >> Best regards, >> ?> >> Michihiro >> ?> >> >> ?> > >> ?> > >> ?> > >> >> >> >> > > > From dean.long at oracle.com Mon Oct 7 20:20:38 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 7 Oct 2019 13:20:38 -0700 Subject: RFR(XXS) 8231902: Build of jdk.internal.vm.compiler.management/module-info.java.extra failed In-Reply-To: <994c7bcf-1632-fe1a-fad3-a58d17371730@oracle.com> References: <8c5b2cdc-6bcf-e593-b872-0c7a7df4c119@oracle.com> <994c7bcf-1632-fe1a-fad3-a58d17371730@oracle.com> Message-ID: <3691e3fc-5167-dff5-334b-6f4a0604aa20@oracle.com> Thanks Magnus and Erik! dl On 10/7/19 8:20 AM, Erik Joelsson wrote: > Looks good! Thanks! > > /Erik > > On 2019-10-04 15:09, dean.long at oracle.com wrote: >> Here's an alternative version with $(NAWK) usage suggested by Erik >> Joelsson: >> >> http://cr.openjdk.java.net/~dlong/8231902/webrev.2/ >> >> dl >> >> On 10/4/19 12:29 PM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8231902 >>> http://cr.openjdk.java.net/~dlong/8231902/webrev/ >>> >>> A recent upstream Graal change causes the META-INF/providers >>> directory to contain only a single file, causing the $(GREP) command >>> to not prepend the filename to the output.? The simple fix is to >>> create an empty file in the directory. >>> >>> dl >> From tom.rodriguez at oracle.com Mon Oct 7 22:13:11 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 7 Oct 2019 15:13:11 -0700 Subject: RFR: 8231659: [JVMCI] Could not work PrintAssembly for JVMCI installed code In-Reply-To: References: <8ee7143a-15cb-5761-528c-c5fa687d89f3@gmail.com> Message-ID: Nils Eliasson wrote on 10/7/19 5:05 AM: > Hi, > > Related to the code you are changing: > > The CompilerDirectives is not supposed to be used in that way. The > compiler should use the lookup to find a directive at the beginning of a > compilation, and then keep using that directive for the entire duration > of the compilation. Otherwise you may get different option values. > PrintAssembly and PrintNMethod may not cause any failures or > inconsistencies at the moment, but is still incorrect. This path is not a normal CompileBroker compilation path so there are no other uses of the CompilerDirectives to be inconsistent with. Is there some other way this should be done? tom > > Regards, > > Nils > > > On 2019-10-01 10:57, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change. >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8231659 >> ? webrev: https://cr.openjdk.java.net/~ysuenaga/JDK-8231659/webrev.00/ >> >> PrintAssembly would work in twice for JVMCI installed code before, so >> I fixed it in JDK-8180601. >> However PrintAseembly would not work for them in JDK 13 or later. It >> seems due to JDK-8220623. >> >> JDK-8220623 lacks print_nmethod() call. Thus I revert JDK-8180601 to >> work PrintAssembly. From dean.long at oracle.com Tue Oct 8 05:43:06 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 7 Oct 2019 22:43:06 -0700 Subject: RFR(S) 8231586: enlarge encoding space for OopMapValue offsets In-Reply-To: References: <92e6a5a2-c806-843d-a8e0-84f0aa3718b7@oracle.com> <6fa4389f-81f2-7591-de61-9edc60a18187@oracle.com> <5ff481d6-f440-90d6-6f04-3576879afbf5@oracle.com> Message-ID: <43425f68-cb1d-9569-5ea8-e337b28b879b@oracle.com> Looks good.? The only thing I noticed is that while you moved the asserts into the OopMapValue ctor, the read_from method still bypasses those asserts.? Would it make sense to move those asserts into set_content_reg()? dl On 10/7/19 10:11 AM, Tom Rodriguez wrote: > > > dean.long at oracle.com wrote on 10/5/19 9:25 PM: >> You're right, my mistake.? Your change looks good.? I was actually >> looking at the set_* methods in OopMapValue, not OopMap, and >> incorrectly thought the | would preserve the previous value.? On >> closer inspection, it doesn't, and those methods don't even get >> called, because the ctor uses a different set method.? Can we remove >> these unused methods? > > Good idea.? I've deleted those along with some other dead methods and > rearranged the code a little bit to hide more of the API so it's > clearer what might be done to an OopMapValue.? The delta webrev is > just my changes and the .1 webrev is the full new webrev.? I'm > submitting a mach5 run now. > > http://cr.openjdk.java.net/~never/8231586-delta/webrev/ > http://cr.openjdk.java.net/~never/8231586.1/webrev/ > > tom > >> >> ???? void set_oop()????????????? { set_value((value() & >> register_mask_in_place) | oop_value); } >> ???? void set_narrowoop()????????? { set_value((value() & >> register_mask_in_place) | narrowoop_value); } >> ???? void set_callee_saved()???? { set_value((value() & >> register_mask_in_place) | callee_saved_value); } >> ???? void set_derived_oop()????? { set_value((value() & >> register_mask_in_place) | derived_oop_value); } >> >> dl >> >> On 10/5/19 10:41 AM, Tom Rodriguez wrote: >>> >>> >>> dean.long at oracle.com wrote on 10/4/19 4:27 PM: >>>> It's not obvious that we only set 1 bit. The set methods don't >>>> enforce that.? And this code looks like it is setting both >>>> "derived" and "oop": >>> >>> Each of those calls produce independent OopMapValues. >>> http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/compiler/oopMap.cpp#l137 >>> ?Also all tests against the type are equality tests, not bitmasks, >>> so if more than one bit was set it would fail to match anything. The >>> bitmask-ness of the values is only used for filtering the iteration. >>> >>> tom >>> >>>> >>>> http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/opto/buildOopMap.cpp#l315 >>>> >>>> >>>> dl >>>> >>>> On 10/4/19 10:26 AM, Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/8231586/webrev >>>>> https://bugs.openjdk.java.net/browse/JDK-8231586 >>>>> >>>>> The current OopMapValue encoding uses a bit mask for each value >>>>> even though only one bit is ever set.? Since only 16 bits are >>>>> available for encoding this limits the offsets it can express. >>>>> Compilation with a large number of stack slots can bailout because >>>>> of this limit.? This changes the encoding to use 2 bits which >>>>> gives 2 bits back to the offset. >>>>> >>>>> I also deleted some StressDerivedPointers machinery that's been >>>>> completely unimplemented for years (decades?).? The flag itself is >>>>> now dead but I wasn't sure if there are test references to it >>>>> somewhere. Should I delete the flag as well? >>>>> >>>>> mach5 testing is in progress. >>>>> >>>>> tom >>>> >> From HORIE at jp.ibm.com Tue Oct 8 06:33:55 2019 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Tue, 8 Oct 2019 15:33:55 +0900 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> Message-ID: Hi Martin, Vladimir, > I think it would be better to use adlc?s include generator instead of > including "opto/convertnode.hpp" explicitly in the ad file. > > src/hotspot/share/adlc/main.cpp > > ?? AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > > +? AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > > ?? AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > > @Vladimir: Do you agree? Would you do it this way, too? Thanks for your recommendation, I didn't know adlc's include generator. (Now I understand why intrinsicnode.hpp was included.) > I prefer current version. > > When proposing the refactoring I thought about the change in adlc as > well, but when I saw the patch I noticed that putting it in AD file > stresses it's a platform-specific dependency. > > I think that's the right way to look at it until we get a way to funnel > attributes from ideal nodes to mach nodes and use them during code > emission. I will kept the change as-is if Martin is ok on this point. > ConINode::make() allocates a new node which has to be seen by GVN, so > there's a type recorded for it. That's why I mentioned GraphKit*. But > you can use PhaseGVN & intcon as well. Thank you for telling the details, I understand the code better. Latest webrev is as follows: http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/ Best regards, Michihiro From: Vladimir Ivanov To: "Doerr, Martin" , Michihiro Horie Cc: hotspot compiler , "ppc-aix-port-dev at openjdk.java.net" Date: 2019/10/08 02:31 Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > I think it would be better to use adlc?s include generator instead of > including "opto/convertnode.hpp" explicitly in the ad file. > > src/hotspot/share/adlc/main.cpp > > ?? AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > > +? AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > > ?? AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > > @Vladimir: Do you agree? Would you do it this way, too? I prefer current version. When proposing the refactoring I thought about the change in adlc as well, but when I saw the patch I noticed that putting it in AD file stresses it's a platform-specific dependency. I think that's the right way to look at it until we get a way to funnel attributes from ideal nodes to mach nodes and use them during code emission. Best regards, Vladimir Ivanov > *From:*Michihiro Horie > *Sent:* Montag, 7. Oktober 2019 17:54 > *To:* Vladimir Ivanov > *Cc:* hotspot compiler ; Doerr, > Martin ; ppc-aix-port-dev at openjdk.java.net > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on Power > > Hi Martin, Vladimir, > Thanks a lot for your further feedback, which makes sense. > > New webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.04_&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=fSzwlsfGWRzgRyzRwoRijgP0dNfRTTp9AtcEU_pRSh4&s=IlXiSrIMK6_IZWaQkNhJKAF-apNgFw0My38tD3o6324&e= > > Best regards, > Michihiro > > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, Michihiro. > > From: Vladimir Ivanov > > To: Michihiro Horie >, > "Doerr, Martin" > > Cc: hotspot compiler >, > "ppc-aix-port-dev at openjdk.java.net > " > > > Date: 2019/10/07 22:51 > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on Power > > ------------------------------------------------------------------------ > > > > > >> Fixed webrev is as follows. > > Thanks, Michihiro. > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.03_&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=fSzwlsfGWRzgRyzRwoRijgP0dNfRTTp9AtcEU_pRSh4&s=LdjN1SKMJL0PdT8OIqU60Xg3ULNBAM24D5I4CNOW0hw&e= > > src/hotspot/share/opto/convertnode.hpp: > > + ?enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > > Please, explicitly initialize the elements. Numbering is important since > it is aligned with instruction encoding on x86. > > > src/hotspot/share/opto/library_call.cpp: > > + ?case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > Please, change RoundDoubleModeNode to accept the enum instead and > instantiate the ConI node inside it or introduce a static factory > (::make(GraphKit*,RoundingMode)) for that purpose. > > > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > > + ?void math_round(const FloatRegister t, const FloatRegister b, int rmode); > + ?void math_round_vec(const VectorSRegister t, const VectorSRegister b, > int rmode); > > I suggest to get rid of helpers in MacroAssembler and simply move the > code into corresponding AD instructions. > > Best regards, > Vladimir Ivanov > >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I >> suggest to put the enum in RoundDoubleModeNode (convertn"Doerr, Martin" >> ---2019/10/07 22:09:15---> I suggest to put the enum in >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction selectio >> >> From: "Doerr, Martin" > >> To: Vladimir Ivanov >, > Michihiro Horie >> > >> Cc: hotspot compiler >, >> "ppc-aix-port-dev at openjdk.java.net > " > > >> Date: 2019/10/07 22:09 >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, >> floor, rint on Power >> >> ------------------------------------------------------------------------ >> >> >> >> ?> I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) >> ?> and lift instruction selection logic from macroAssembler_ppc.cpp into >> ppc.ad. >> That sounds good. >> >> Thanks, >> Martin >> >> >> ?> -----Original Message----- >> ?> From: Vladimir Ivanov > >> ?> Sent: Montag, 7. Oktober 2019 12:55 >> ?> To: Doerr, Martin >; Michihiro Horie >> ?> > >> ?> Cc: hotspot compiler >; ppc-aix- >> ?> port-dev at openjdk.java.net >> ?> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, >> rint on Power >> ?> >> ?> > I think sharedRuntime is not a good place for the C2 enum. >> ?> Agree. >> ?> >> ?> I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) >> ?> and >> ?> lift instruction selection logic from macroAssembler_ppc.cpp into ppc.ad. >> ?> >> ?> Best regards, >> ?> Vladimir Ivanov >> ?> >> ?> > >> ?> > Maybe intrinsicnode.hpp would be a better pace for it. But then, the >> ?> > code in macroAssembler should be guarded by #ifdef COMPILER2. >> ?> > >> ?> > Best regards, >> ?> > >> ?> > Martin >> ?> > >> ?> > *From:*Michihiro Horie > >> ?> > *Sent:* Montag, 7. Oktober 2019 09:14 >> ?> > *To:* Vladimir Ivanov > >> ?> > *Cc:* hotspot compiler >; >> ?> > ppc-aix-port-dev at openjdk.java.net > ; Doerr, Martin >> ?> > >> ?> > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, >> ?> > rint on Power >> ?> > >> ?> > Hi Vladimir, >> ?> > >> ?> > Thanks a lot for your nice suggestion. Yes, I prefer enum use. >> ?> > I'm wondering if the enum constants can be declared in >> ?> sharedRuntime.hpp. >> ?> > Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.02_&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=fSzwlsfGWRzgRyzRwoRijgP0dNfRTTp9AtcEU_pRSh4&s=m5k26bqmrP_HZ8c6w0ffEa4cS8nKw12n-wMOrn7gQIQ&e= >> ?> > >> ?> > Best regards, >> ?> > Michihiro >> ?> > >> ?> > Inactive hide details for Vladimir Ivanov ---2019/10/04 23:05:48---Hi >> ?> > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir Ivanov >> ?> > ---2019/10/04 23:05:48---Hi Michihiro, >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: >> ?> > >> ?> > From: Vladimir Ivanov > ?> > > > >> ?> > To: Michihiro Horie >, >> ?> > ppc-aix-port-dev at openjdk.java.net < mailto:ppc-aix-port-dev at openjdk.java.net> >> ?> > , hotspot compiler >> ?> > > ?> > > > >> ?> > Date: 2019/10/04 23:05 >> ?> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, >> ?> > floor, rint on Power >> ?> > >> ?> > >> ------------------------------------------------------------------------ >> ?> > >> ?> > >> ?> > >> ?> > >> ?> > Hi Michihiro, >> ?> > >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: >> ?> > + ?switch (rmode) { >> ?> > + ? ?case 0: // rint >> ?> > + ? ? ?frin(t, b); >> ?> > + ? ? ?break; >> ?> > + ? ?case 1: // floor >> ?> > + ? ? ?frim(t, b); >> ?> > + ? ? ?break; >> ?> > + ? ?case 2: // ceil >> ?> > + ? ? ?frip(t, b); >> ?> > + ? ? ?break; >> ?> > + ? ?default: >> ?> > + ? ? ?ShouldNotReachHere(); >> ?> > + ?} >> ?> > >> ?> > What do you think about introducing enum constants instead of using >> ?> > hard-coded 0/1/2? >> ?> > >> ?> > src/hotspot/share/opto/library_call.cpp: >> ?> > >> ?> > ?? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, >> ?> > makecon(TypeInt::make(2))); break; >> ?> > ?? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, >> ?> > makecon(TypeInt::make(1))); break; >> ?> > ?? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, >> ?> > makecon(TypeInt::make(0))); break; >> ?> > >> ?> > The downside is you have to move the switch from macroAssembler >> ?> because >> ?> > enum should be visible from both places. (Is there a better place for >> ?> > that than roundD_regNode::emit() in AD file?) >> ?> > >> ?> > Best regards, >> ?> > Vladimir Ivanov >> ?> > >> ?> > On 02/10/2019 07:27, Michihiro Horie wrote: >> ?> >> >> ?> >> Dear all, >> ?> >> >> ?> >> Would you please review the following change? >> ?> >> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8231649&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=fSzwlsfGWRzgRyzRwoRijgP0dNfRTTp9AtcEU_pRSh4&s=SlyNAQFdnb87Dn0EZNWzIxgm1-5luZZxasXkBUoZeP0&e= >> ?> >> Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.00&d=DwID-g&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=fSzwlsfGWRzgRyzRwoRijgP0dNfRTTp9AtcEU_pRSh4&s=-zp4Mak75FNz1Gel2QUNoWyK4E0EGS6YrZSVDDZhbKg&e= >> ?> >> >> ?> >> This change adds intrinsics for Math's ceil, floor, and rint for >> PPC64, on >> ?> >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. >> ?> >> >> ?> >> Best regards, >> ?> >> Michihiro >> ?> >> >> ?> > >> ?> > >> ?> > >> >> >> >> > > > From nils.eliasson at oracle.com Tue Oct 8 07:20:44 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 8 Oct 2019 09:20:44 +0200 Subject: RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: References: Message-ID: Hi all, Here is the latest patch http://cr.openjdk.java.net/~neliasso/superlate/webrev.04/ This is the full implementation, stable on x64 and aarch64. // Nils On 2019-09-26 16:56, Nils Eliasson wrote: > Hi, > > Now I have update the patch in place: > http://cr.openjdk.java.net/~neliasso/aarch_barriers/aarch_super_late > > Status: > > Quite stable - hits a problem with monitor_enter_complete - probably a > bug in cas/cmpx. I'm looking into it > > Use optimized spilling with -XX:+UseNewCode2 - a little less stable. > > Regards, > > Nils > > > On 2019-09-26 16:26, Stuart Monteith wrote: >> Hello, >> ??? Yes, I'll try this out - I was in the middle of my own >> implementation, but I haven't advanced it as far as Nils. >> >> BR, >> ? Stuart >> >> On Sat, 21 Sep 2019 at 09:11, Per Liden wrote: >>> Thanks Nils! >>> >>> Stuart, could you take this for a spin and help Nils track down the >>> last >>> few issues? >>> >>> We're eager to push this as soon as we feel comfortable that the >>> aarch64 >>> bits are good enough. >>> >>> cheers, >>> Per >>> >>> On 9/20/19 4:50 PM, Nils Eliasson wrote: >>>> Hi, >>>> >>>> This is an attempt of porting the redesigned C2 barriers to aarch64. >>>> >>>> Status >>>> >>>> * Mostly complete - ad-files should be complete although not fully >>>> tested yet >>>> >>>> * Spilling is implemented but not optimized >>>> >>>> * Runs a bit, but far from stable. >>>> >>>> >>>> Patch: http://cr.openjdk.java.net/~neliasso/aarch_barriers/ >>>> >>>> Regards, >>>> >>>> Nils >>>> >>>> >>>> >>>> On 2019-09-04 14:58, Erik ?sterlund wrote: >>>> >>>>> Hi, >>>>> >>>>> For many years we have expanded load barriers in the C2 sea of nodes. >>>>> It has been a constant struggle to keep up with bugs due to >>>>> optimizations breaking our barriers. It has never truly worked. One >>>>> particular pain point that has never been handled quite right up >>>>> until >>>>> now, is dealing with safepoints ending up between a load and its load >>>>> barrier. We have had workarounds for that before, but they have never >>>>> really been enough. >>>>> >>>>> In the end, our barrier is only a conditional branch to a slow path, >>>>> so there is really not much that the optimizer can do to help us make >>>>> that better. But it has many creative ways of breaking our GC >>>>> invariants. >>>>> >>>>> I think we have finally had enough of this, and want to move the >>>>> barrier expansion to the MachNode level instead. This way, we can >>>>> finally put an end to the load and its load barrier being separated >>>>> (and related even more complicated issues for atomics). >>>>> >>>>> Our new solution is to tag accesses that want load barriers during >>>>> parsing, and then let C2 optimize whatever it wants to, >>>>> invariantly of >>>>> GC barriers. Then it will match mach nodes, and perform global code >>>>> motion and scheduling. Only right before dumping the machine code of >>>>> the resulting graph do we call into the barrier set to perform last >>>>> second analysis of barriers, and then during machine code dumping, we >>>>> inject our load barriers. After the normal insts() are dumped, we >>>>> inject slow path stubs for our barriers. >>>>> >>>>> There are two optimizations that we would like to retain in this >>>>> scheme. >>>>> >>>>> Optimization 1: Dominating barrier analysis >>>>> Previously, we instantiated a PhaseIdealLoop instance to analyze >>>>> dominating barriers. That was convenient because a dominator tree is >>>>> available for finding load barriers that dominate other load barriers >>>>> in the CFG. I built a new more precise analysis on the PhaseCFG level >>>>> instead, happening after the matching to mach nodes. The analysis is >>>>> now looking for dominating accesses, instead of dominating load >>>>> barriers. Because any dominating access, including stores, will make >>>>> sure that what is left behind in memory is "good". Another thing that >>>>> makes the analysis more precise, is that it doesn't require strict >>>>> dominance in the CFG. If the earlier access is in the same Block >>>>> as an >>>>> access with barriers, we now also utilize knowledge about the >>>>> scheduling of the instructions, which has completed at this point. So >>>>> we can safely remove such pointless load barriers in the same block >>>>> now. The analysis is performed right before machine code is emitted, >>>>> so we can trust that it won't change after the analysis due to >>>>> optimizations. >>>>> >>>>> Optimization 2: Tight register spilling >>>>> When we call the slow path of our barriers, we want to spill only the >>>>> registers that are live. Previously, we had a special >>>>> LoadBarrierSlowReg node corresponding to the slow path, that killed >>>>> all XMM registers, and then all general purpose registers were called >>>>> in the slow path. Now we instead perform explicit live analysis of >>>>> our >>>>> registers on MachNodes, including how large chunks of vector >>>>> registers >>>>> are being used, and spill only exactly the registers that are live >>>>> (and only the part of the register that is live for XMM/YMM/ZMM >>>>> registers). >>>>> >>>>> Zooming out a bit, all complexity of pulling the barriers in the sea >>>>> of nodes through various interesting phases while retaining GC >>>>> invariants such as "don't put safepoints in my barrier", become >>>>> trivial and no longer an issue. We simply tag our loads to need >>>>> barriers, and let C2 do whatever it wants to in the sea of nodes. >>>>> Once >>>>> all scheduling is done, we do our thing. Hopefully this will make the >>>>> barriers as stable and resilient as our C1 barriers, which cause >>>>> trouble extremely rarely. >>>>> >>>>> We have run a number of benchmarks. We have observed a number of >>>>> improvements, but never any regressions. There has been countless >>>>> runs >>>>> through gc-test-suite, and a few hs-tier1-6 and his tier1-7 runs. >>>>> >>>>> Finally, I would like to thank Per and StefanK for the many hours >>>>> spent on helping me with this patch, both in terms of spotting flaws >>>>> in my prototypes, benchmarking, testing, and refactoring so the code >>>>> looks nice and much more understandable. I will add both to the >>>>> Contributed-by line. >>>>> >>>>> @Stuart: It would be awesome if you could provide some AArch64 bits >>>>> for this patch so we do things the same way (ish). >>>>> >>>>> Bug: >>>>> https://bugs.openjdk.java.net/browse/JDK-8230565 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~eosterlund/8230565/webrev.00/ >>>>> >>>>> Thanks, >>>>> /Erik From felix.yang at huawei.com Tue Oct 8 08:14:24 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 8 Oct 2019 08:14:24 +0000 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop Message-ID: Hi, Could I have a review for this trivial C2 bugfix please? Bug: https://bugs.openjdk.java.net/browse/JDK-8231988 This bug is always reproducible with 8u, 11u, 13 and latest 14. After some investigation, we found that the cmp node in one empty loop was deleted by IdealLoopTree::do_remove_empty_loop, but it still has another user outside the empty loop. C2 call stack: #0 IdealLoopTree::do_remove_empty_loop (this=0x96b060, phase=0xffff5c3815c0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3131 #1 0x0000ffffb7077f70 in IdealLoopTree::iteration_split_impl (this=0x96b060, phase=0xffff5c3815c0, old_new=...) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3186 #2 0x0000ffffb7078590 in IdealLoopTree::iteration_split (this=0x96b060, phase=0xffff5c3815c0, old_new=...) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3336 #3 0x0000ffffb70784a8 in IdealLoopTree::iteration_split (this=0x96b130, phase=0xffff5c3815c0, old_new=...) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3320 #4 0x0000ffffb708a2c8 in PhaseIdealLoop::build_and_optimize (this=0xffff5c3815c0, mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.cpp:3088 #5 0x0000ffffb6a46e58 in PhaseIdealLoop::PhaseIdealLoop (this=0xffff5c3815c0, igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:945 #6 0x0000ffffb6a46f18 in PhaseIdealLoop::optimize (igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:1020 #7 0x0000ffffb6a3abc8 in Compile::Optimize (this=0xffff5c3847a8) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:2328 #8 0x0000ffffb6a3458c in Compile::Compile (this=0xffff5c3847a8, ci_env=0xffff5c385558, compiler=0xffff581e2110, target=0x928e20, osr_bci=-1, subsume_loads=true, do_escape_analysis=true, eliminate_boxing=true, directive=0xffff581b1e70) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:874 #9 0x0000ffffb690a508 in C2Compiler::compile_method (this=0xffff581e2110, env=0xffff5c385558, target=0x928e20, entry_bci=-1, directive=0xffff581b1e70) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/c2compiler.cpp:110 #10 0x0000ffffb6a506c8 in CompileBroker::invoke_compiler_on_method (task=0xffff5824df80) at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2115 #11 0x0000ffffb6a4f554 in CompileBroker::compiler_thread_loop () at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:1800 #12 0x0000ffffb747be0c in compiler_thread_entry (thread=0xffff581e2800, __the_thread__=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:3401 #13 0x0000ffffb7477208 in JavaThread::thread_main_inner (this=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1917 #14 0x0000ffffb747708c in JavaThread::run (this=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1900 #15 0x0000ffffb7473270 in Thread::call_run (this=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:398 #16 0x0000ffffb71e1574 in thread_native_entry (thread=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/os/linux/os_linux.cpp:792 #17 0x0000ffffb7f3edc4 in start_thread () from /lib64/libpthread.so.0 #18 0x0000ffffb7e73fd0 in thread_start () from /lib64/libc.so.6 The other use of the cmp node was created by: #0 PhaseStringOpts::getChars (this=0xffff5c383630, kit=..., arg=0xafaf88, dst_array=0xffff58021cd8, bt=T_BYTE, end=0xaef210, final_merge=0xffff58022b18, final_mem=0xffff58022bb0, merge_index=0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:1251 #1 0x0000ffffb73d72b4 in PhaseStringOpts::int_getChars (this=0xffff5c383630, kit=..., arg=0xafaf88, dst_array=0xffff58021cd8, dst_coder=0xb2d080, start=0xffff580226f8, size=0xaebdf0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:1396 #2 0x0000ffffb73d93bc in PhaseStringOpts::replace_string_concat (this=0xffff5c383630, sc=0xb1bf10) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:1932 #3 0x0000ffffb73d3cfc in PhaseStringOpts::PhaseStringOpts (this=0xffff5c383630, gvn=0xffff5c383aa8) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:667 #4 0x0000ffffb6a39798 in Compile::inline_string_calls (this=0xffff5c384528, parse_time=true) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:2026 #5 0x0000ffffb6a343d4 in Compile::Compile (this=0xffff5c384528, ci_env=0xffff5c3852d8, compiler=0xffff58002f70, target=0xb03050, osr_bci=-1, subsume_loads=true, do_escape_analysis=true, eliminate_boxing=true, directive=0xa85fb0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:834 #6 0x0000ffffb690a508 in C2Compiler::compile_method (this=0xffff58002f70, env=0xffff5c3852d8, target=0xb03050, entry_bci=-1, directive=0xa85fb0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/c2compiler.cpp:110 #7 0x0000ffffb6a506c8 in CompileBroker::invoke_compiler_on_method (task=0xffff58085340) at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2115 #8 0x0000ffffb6a4f554 in CompileBroker::compiler_thread_loop () at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:1800 #9 0x0000ffffb747be0c in compiler_thread_entry (thread=0xffff58010800, __the_thread__=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:3401 #10 0x0000ffffb7477208 in JavaThread::thread_main_inner (this=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1917 #11 0x0000ffffb747708c in JavaThread::run (this=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1900 #12 0x0000ffffb7473270 in Thread::call_run (this=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:398 #13 0x0000ffffb71e1574 in thread_native_entry (thread=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/os/linux/os_linux.cpp:792 #14 0x0000ffffb7f3edc4 in start_thread () from /lib64/libpthread.so.0 #15 0x0000ffffb7e73fd0 in thread_start () from /lib64/libc.so.6 Cmp node was deleted by: #0 PhaseIterGVN::optimize (this=0xffff5c381f28) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/phaseX.cpp:1162 #1 0x0000ffffb708a630 in PhaseIdealLoop::build_and_optimize (this=0xffff5c3812c0, mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.cpp:3163 #2 0x0000ffffb6a46e58 in PhaseIdealLoop::PhaseIdealLoop (this=0xffff5c3812c0, igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:945 #3 0x0000ffffb6a46f18 in PhaseIdealLoop::optimize (igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:1020 #4 0x0000ffffb6a3abc8 in Compile::Optimize (this=0xffff5c3844a8) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:2328 #5 0x0000ffffb6a3458c in Compile::Compile (this=0xffff5c3844a8, ci_env=0xffff5c385258, compiler=0xaaf7a0, target=0xb19630, osr_bci=-1, subsume_loads=true, do_escape_analysis=true, eliminate_boxing=true, directive=0xa85fb0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:874 #6 0x0000ffffb690a508 in C2Compiler::compile_method (this=0xaaf7a0, env=0xffff5c385258, target=0xb19630, entry_bci=-1, directive=0xa85fb0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/c2compiler.cpp:110 #7 0x0000ffffb6a506c8 in CompileBroker::invoke_compiler_on_method (task=0xffff58067330) at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2115 #8 0x0000ffffb6a4f554 in CompileBroker::compiler_thread_loop () at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:1800 #9 0x0000ffffb747be0c in compiler_thread_entry (thread=0xabd000, __the_thread__=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:3401 #10 0x0000ffffb7477208 in JavaThread::thread_main_inner (this=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1917 #11 0x0000ffffb747708c in JavaThread::run (this=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1900 #12 0x0000ffffb7473270 in Thread::call_run (this=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:398 #13 0x0000ffffb71e1574 in thread_native_entry (thread=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/os/linux/os_linux.cpp:792 #14 0x0000ffffb7f3edc4 in start_thread () from /lib64/libpthread.so.0 #15 0x0000ffffb7e73fd0 in thread_start () from /lib64/libc.so.6 Proposed patch duplicate the cmp node if it has other users: diff -r 5b5de2618756 src/hotspot/share/opto/loopTransform.cpp --- a/src/hotspot/share/opto/loopTransform.cpp Mon Oct 07 17:13:59 2019 -0700 +++ b/src/hotspot/share/opto/loopTransform.cpp Wed Oct 09 15:39:42 2019 +0800 @@ -3129,6 +3129,13 @@ // We also need to replace the original limit to collapse loop exit. Node* cmp = cl->loopexit()->cmp_node(); assert(cl->limit() == cmp->in(2), "sanity"); + // Duplicate cmp node if it has other users + if (cmp->outcnt() > 1) { + cmp = cmp->clone(); + cmp = phase->_igvn.register_new_node_with_optimizer(cmp); + BoolNode *bol = cl->loopexit()->in(CountedLoopEndNode::TestValue)->as_Bool(); + phase->_igvn.replace_input_of(bol, 1, cmp); // put bol on worklist + } phase->_igvn._worklist.push(cmp->in(2)); // put limit on worklist phase->_igvn.replace_input_of(cmp, 2, exact_limit); // put cmp on worklist } Patch is currently under testing. Thanks, Felix From vladimir.x.ivanov at oracle.com Tue Oct 8 09:46:54 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 8 Oct 2019 12:46:54 +0300 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> Message-ID: > http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/ Looks good. (Test results are clean.) Best regards, Vladimir Ivanov > > I think it would be better to use adlc?s include generator instead of > > including "opto/convertnode.hpp" explicitly in the ad file. > > > > src/hotspot/share/adlc/main.cpp > > > > ??? AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > > > > +? AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > > > > ??? AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > > > > @Vladimir: Do you agree? Would you do it this way, too? > > I prefer current version. > > When proposing the refactoring I thought about the change in adlc as > well, but when I saw the patch I noticed that putting it in AD file > stresses it's a platform-specific dependency. > > I think that's the right way to look at it until we get a way to funnel > attributes from ideal nodes to mach nodes and use them during code > emission. > > Best regards, > Vladimir Ivanov > > > *From:*Michihiro Horie > > *Sent:* Montag, 7. Oktober 2019 17:54 > > *To:* Vladimir Ivanov > > *Cc:* hotspot compiler ; Doerr, > > Martin ; ppc-aix-port-dev at openjdk.java.net > > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > rint on Power > > > > Hi Martin, Vladimir, > > Thanks a lot for your further feedback, which makes sense. > > > > New webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ > > > > Best regards, > > Michihiro > > > > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, Michihiro. > > > > From: Vladimir Ivanov > > > > To: Michihiro Horie >, > > "Doerr, Martin" > > > Cc: hotspot compiler > >, > > "ppc-aix-port-dev at openjdk.java.net > > " > > > > > > Date: 2019/10/07 22:51 > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > floor, rint on Power > > > > ------------------------------------------------------------------------ > > > > > > > > > > > >> Fixed webrev is as follows. > > > > Thanks, Michihiro. > > > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ > > > > src/hotspot/share/opto/convertnode.hpp: > > > > + ?enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > > > > Please, explicitly initialize the elements. Numbering is important since > > it is aligned with instruction encoding on x86. > > > > > > src/hotspot/share/opto/library_call.cpp: > > > > + ?case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > > > Please, change RoundDoubleModeNode to accept the enum instead and > > instantiate the ConI node inside it or introduce a static factory > > (::make(GraphKit*,RoundingMode)) for that purpose. > > > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > > > > + ?void math_round(const FloatRegister t, const FloatRegister b, int > rmode); > > + ?void math_round_vec(const VectorSRegister t, const VectorSRegister b, > > int rmode); > > > > I suggest to get rid of helpers in MacroAssembler and simply move the > > code into corresponding AD instructions. > > > > Best regards, > > Vladimir Ivanov > > > >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I > >> suggest to put the enum in RoundDoubleModeNode (convertn"Doerr, Martin" > >> ---2019/10/07 22:09:15---> I suggest to put the enum in > >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction selectio > >> > >> From: "Doerr, Martin" > > >> To: Vladimir Ivanov >, > > Michihiro Horie > >> > > >> Cc: hotspot compiler > >, > >> "ppc-aix-port-dev at openjdk.java.net > > " > > > > > >> Date: 2019/10/07 22:09 > >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > >> floor, rint on Power > >> > >> ------------------------------------------------------------------------ > >> > >> > >> > >> ?> I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > >> ?> and lift instruction selection logic from macroAssembler_ppc.cpp > into > >> ppc.ad. > >> That sounds good. > >> > >> Thanks, > >> Martin > >> > >> > >> ?> -----Original Message----- > >> ?> From: Vladimir Ivanov > > >> ?> Sent: Montag, 7. Oktober 2019 12:55 > >> ?> To: Doerr, Martin >; Michihiro Horie > >> ?> > > >> ?> Cc: hotspot compiler > >; ppc-aix- > >> ?> port-dev at openjdk.java.net > >> ?> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >> rint on Power > >> ?> > >> ?> > I think sharedRuntime is not a good place for the C2 enum. > >> ?> Agree. > >> ?> > >> ?> I suggest to put the enum in RoundDoubleModeNode (convertnode.hpp) > >> ?> and > >> ?> lift instruction selection logic from macroAssembler_ppc.cpp into > ppc.ad. > >> ?> > >> ?> Best regards, > >> ?> Vladimir Ivanov > >> ?> > >> ?> > > >> ?> > Maybe intrinsicnode.hpp would be a better pace for it. But > then, the > >> ?> > code in macroAssembler should be guarded by #ifdef COMPILER2. > >> ?> > > >> ?> > Best regards, > >> ?> > > >> ?> > Martin > >> ?> > > >> ?> > *From:*Michihiro Horie > > >> ?> > *Sent:* Montag, 7. Oktober 2019 09:14 > >> ?> > *To:* Vladimir Ivanov > > >> ?> > *Cc:* hotspot compiler > >; > >> ?> > ppc-aix-port-dev at openjdk.java.net > > ; Doerr, Martin > >> ?> > > >> ?> > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, > >> ?> > rint on Power > >> ?> > > >> ?> > Hi Vladimir, > >> ?> > > >> ?> > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > >> ?> > I'm wondering if the enum constants can be declared in > >> ?> sharedRuntime.hpp. > >> ?> > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > >> ?> > > >> ?> > Best regards, > >> ?> > Michihiro > >> ?> > > >> ?> > Inactive hide details for Vladimir Ivanov ---2019/10/04 > 23:05:48---Hi > >> ?> > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > Ivanov > >> ?> > ---2019/10/04 23:05:48---Hi Michihiro, > >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >> ?> > > >> ?> > From: Vladimir Ivanov > > ?> > > > > > >> ?> > To: Michihiro Horie >, > >> ?> > ppc-aix-port-dev at openjdk.java.net > > >> ?> > , hotspot compiler > >> ?> > > > ?> > > > > > >> ?> > Date: 2019/10/04 23:05 > >> ?> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, > >> ?> > floor, rint on Power > >> ?> > > >> ?> > > >> ------------------------------------------------------------------------ > >> ?> > > >> ?> > > >> ?> > > >> ?> > > >> ?> > Hi Michihiro, > >> ?> > > >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >> ?> > + ?switch (rmode) { > >> ?> > + ? ?case 0: // rint > >> ?> > + ? ? ?frin(t, b); > >> ?> > + ? ? ?break; > >> ?> > + ? ?case 1: // floor > >> ?> > + ? ? ?frim(t, b); > >> ?> > + ? ? ?break; > >> ?> > + ? ?case 2: // ceil > >> ?> > + ? ? ?frip(t, b); > >> ?> > + ? ? ?break; > >> ?> > + ? ?default: > >> ?> > + ? ? ?ShouldNotReachHere(); > >> ?> > + ?} > >> ?> > > >> ?> > What do you think about introducing enum constants instead of using > >> ?> > hard-coded 0/1/2? > >> ?> > > >> ?> > src/hotspot/share/opto/library_call.cpp: > >> ?> > > >> ?> > ?? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > >> ?> > makecon(TypeInt::make(2))); break; > >> ?> > ?? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, > >> ?> > makecon(TypeInt::make(1))); break; > >> ?> > ?? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, > >> ?> > makecon(TypeInt::make(0))); break; > >> ?> > > >> ?> > The downside is you have to move the switch from macroAssembler > >> ?> because > >> ?> > enum should be visible from both places. (Is there a better > place for > >> ?> > that than roundD_regNode::emit() in AD file?) > >> ?> > > >> ?> > Best regards, > >> ?> > Vladimir Ivanov > >> ?> > > >> ?> > On 02/10/2019 07:27, Michihiro Horie wrote: > >> ?> >> > >> ?> >> Dear all, > >> ?> >> > >> ?> >> Would you please review the following change? > >> ?> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > >> ?> >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > >> ?> >> > >> ?> >> This change adds intrinsics for Math's ceil, floor, and rint for > >> PPC64, on > >> ?> >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > >> ?> >> > >> ?> >> Best regards, > >> ?> >> Michihiro > >> ?> >> > >> ?> > > >> ?> > > >> ?> > > >> > >> > >> > >> > > > > > > > > > > From martin.doerr at sap.com Tue Oct 8 10:14:15 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 8 Oct 2019 10:14:15 +0000 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> Message-ID: Hi Vladimir and Michihiro, I like webrev.04 more than webrev.05. I think it's not good to include graphKit.hpp in convertnode.hpp. This creates a weird dependency. What was the reason for this change? Best regards, Martin > -----Original Message----- > From: Vladimir Ivanov > Sent: Dienstag, 8. Oktober 2019 11:47 > To: Michihiro Horie > Cc: hotspot compiler ; Doerr, > Martin ; ppc-aix-port-dev at openjdk.java.net > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > > > > http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/ > > Looks good. > > (Test results are clean.) > > Best regards, > Vladimir Ivanov > > > > I think it would be better to use adlc?s include generator instead of > > > including "opto/convertnode.hpp" explicitly in the ad file. > > > > > > src/hotspot/share/adlc/main.cpp > > > > > > ??? AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > > > > > > +? AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > > > > > > ??? AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > > > > > > @Vladimir: Do you agree? Would you do it this way, too? > > > > I prefer current version. > > > > When proposing the refactoring I thought about the change in adlc as > > well, but when I saw the patch I noticed that putting it in AD file > > stresses it's a platform-specific dependency. > > > > I think that's the right way to look at it until we get a way to funnel > > attributes from ideal nodes to mach nodes and use them during code > > emission. > > > > Best regards, > > Vladimir Ivanov > > > > > *From:*Michihiro Horie > > > *Sent:* Montag, 7. Oktober 2019 17:54 > > > *To:* Vladimir Ivanov > > > *Cc:* hotspot compiler ; > Doerr, > > > Martin ; ppc-aix-port-dev at openjdk.java.net > > > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > > rint on Power > > > > > > Hi Martin, Vladimir, > > > Thanks a lot for your further feedback, which makes sense. > > > > > > New webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ > > > > > > Best regards, > > > Michihiro > > > > > > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > > > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > > > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, Michihiro. > > > > > > From: Vladimir Ivanov > > > > > > To: Michihiro Horie >, > > > "Doerr, Martin" > > > > Cc: hotspot compiler > > >, > > > "ppc-aix-port-dev at openjdk.java.net > > > " > > > > > > > > > Date: 2019/10/07 22:51 > > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > > floor, rint on Power > > > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > > > > > >> Fixed webrev is as follows. > > > > > > Thanks, Michihiro. > > > > > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ > > > > > > src/hotspot/share/opto/convertnode.hpp: > > > > > > + ?enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > > > > > > Please, explicitly initialize the elements. Numbering is important since > > > it is aligned with instruction encoding on x86. > > > > > > > > > src/hotspot/share/opto/library_call.cpp: > > > > > > + ?case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > > > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); > break; > > > > > > Please, change RoundDoubleModeNode to accept the enum instead and > > > instantiate the ConI node inside it or introduce a static factory > > > (::make(GraphKit*,RoundingMode)) for that purpose. > > > > > > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > > > > > > + ?void math_round(const FloatRegister t, const FloatRegister b, int > > rmode); > > > + ?void math_round_vec(const VectorSRegister t, const VectorSRegister > b, > > > int rmode); > > > > > > I suggest to get rid of helpers in MacroAssembler and simply move the > > > code into corresponding AD instructions. > > > > > > Best regards, > > > Vladimir Ivanov > > > > > >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I > > >> suggest to put the enum in RoundDoubleModeNode (convertn"Doerr, > Martin" > > >> ---2019/10/07 22:09:15---> I suggest to put the enum in > > >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction > selectio > > >> > > >> From: "Doerr, Martin" > > > > >> To: Vladimir Ivanov > >, > > > Michihiro Horie > > >> > > > >> Cc: hotspot compiler > > >, > > >> "ppc-aix-port-dev at openjdk.java.net > > > " > > > > > > > > >> Date: 2019/10/07 22:09 > > >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > >> floor, rint on Power > > >> > > >> ------------------------------------------------------------------------ > > >> > > >> > > >> > > >> ?> I suggest to put the enum in RoundDoubleModeNode > (convertnode.hpp) > > >> ?> and lift instruction selection logic from macroAssembler_ppc.cpp > > into > > >> ppc.ad. > > >> That sounds good. > > >> > > >> Thanks, > > >> Martin > > >> > > >> > > >> ?> -----Original Message----- > > >> ?> From: Vladimir Ivanov > > > > >> ?> Sent: Montag, 7. Oktober 2019 12:55 > > >> ?> To: Doerr, Martin > >; Michihiro Horie > > >> ?> > > > >> ?> Cc: hotspot compiler > > >; ppc-aix- > > >> ?> port-dev at openjdk.java.net > > >> ?> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > > >> rint on Power > > >> ?> > > >> ?> > I think sharedRuntime is not a good place for the C2 enum. > > >> ?> Agree. > > >> ?> > > >> ?> I suggest to put the enum in RoundDoubleModeNode > (convertnode.hpp) > > >> ?> and > > >> ?> lift instruction selection logic from macroAssembler_ppc.cpp into > > ppc.ad. > > >> ?> > > >> ?> Best regards, > > >> ?> Vladimir Ivanov > > >> ?> > > >> ?> > > > >> ?> > Maybe intrinsicnode.hpp would be a better pace for it. But > > then, the > > >> ?> > code in macroAssembler should be guarded by #ifdef COMPILER2. > > >> ?> > > > >> ?> > Best regards, > > >> ?> > > > >> ?> > Martin > > >> ?> > > > >> ?> > *From:*Michihiro Horie > > > >> ?> > *Sent:* Montag, 7. Oktober 2019 09:14 > > >> ?> > *To:* Vladimir Ivanov > > > > >> ?> > *Cc:* hotspot compiler > > >; > > >> ?> > ppc-aix-port-dev at openjdk.java.net > > > ; Doerr, Martin > > >> ?> > > > >> ?> > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > > floor, > > >> ?> > rint on Power > > >> ?> > > > >> ?> > Hi Vladimir, > > >> ?> > > > >> ?> > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > > >> ?> > I'm wondering if the enum constants can be declared in > > >> ?> sharedRuntime.hpp. > > >> ?> > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > > >> ?> > > > >> ?> > Best regards, > > >> ?> > Michihiro > > >> ?> > > > >> ?> > Inactive hide details for Vladimir Ivanov ---2019/10/04 > > 23:05:48---Hi > > >> ?> > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > > Ivanov > > >> ?> > ---2019/10/04 23:05:48---Hi Michihiro, > > >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > >> ?> > > > >> ?> > From: Vladimir Ivanov > > > ?> > > > > > > > >> ?> > To: Michihiro Horie >, > > >> ?> > ppc-aix-port-dev at openjdk.java.net > > > > >> ?> > , hotspot compiler > > >> ?> > > > > ?> > > > > > > > >> ?> > Date: 2019/10/04 23:05 > > >> ?> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > > Math.ceil, > > >> ?> > floor, rint on Power > > >> ?> > > > >> ?> > > > >> ------------------------------------------------------------------------ > > >> ?> > > > >> ?> > > > >> ?> > > > >> ?> > > > >> ?> > Hi Michihiro, > > >> ?> > > > >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > >> ?> > + ?switch (rmode) { > > >> ?> > + ? ?case 0: // rint > > >> ?> > + ? ? ?frin(t, b); > > >> ?> > + ? ? ?break; > > >> ?> > + ? ?case 1: // floor > > >> ?> > + ? ? ?frim(t, b); > > >> ?> > + ? ? ?break; > > >> ?> > + ? ?case 2: // ceil > > >> ?> > + ? ? ?frip(t, b); > > >> ?> > + ? ? ?break; > > >> ?> > + ? ?default: > > >> ?> > + ? ? ?ShouldNotReachHere(); > > >> ?> > + ?} > > >> ?> > > > >> ?> > What do you think about introducing enum constants instead of > using > > >> ?> > hard-coded 0/1/2? > > >> ?> > > > >> ?> > src/hotspot/share/opto/library_call.cpp: > > >> ?> > > > >> ?> > ?? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > > >> ?> > makecon(TypeInt::make(2))); break; > > >> ?> > ?? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, > > >> ?> > makecon(TypeInt::make(1))); break; > > >> ?> > ?? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, > > >> ?> > makecon(TypeInt::make(0))); break; > > >> ?> > > > >> ?> > The downside is you have to move the switch from > macroAssembler > > >> ?> because > > >> ?> > enum should be visible from both places. (Is there a better > > place for > > >> ?> > that than roundD_regNode::emit() in AD file?) > > >> ?> > > > >> ?> > Best regards, > > >> ?> > Vladimir Ivanov > > >> ?> > > > >> ?> > On 02/10/2019 07:27, Michihiro Horie wrote: > > >> ?> >> > > >> ?> >> Dear all, > > >> ?> >> > > >> ?> >> Would you please review the following change? > > >> ?> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > > >> ?> >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > > >> ?> >> > > >> ?> >> This change adds intrinsics for Math's ceil, floor, and rint for > > >> PPC64, on > > >> ?> >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > > >> ?> >> > > >> ?> >> Best regards, > > >> ?> >> Michihiro > > >> ?> >> > > >> ?> > > > >> ?> > > > >> ?> > > > >> > > >> > > >> > > >> > > > > > > > > > > > > > > > > > From vladimir.x.ivanov at oracle.com Tue Oct 8 10:30:48 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 8 Oct 2019 13:30:48 +0300 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> Message-ID: On 08/10/2019 13:14, Doerr, Martin wrote: > Hi Vladimir and Michihiro, > > I like webrev.04 more than webrev.05. > I think it's not good to include graphKit.hpp in convertnode.hpp. This creates a weird dependency. > What was the reason for this change? webrev.04 has a bug. Quote from earlier email: "src/hotspot/share/opto/convertnode.hpp: + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, ConINode::make(rmode)) {} ConINode::make() allocates a new node which has to be seen by GVN, so there's a type recorded for it. That's why I mentioned GraphKit*. But you can use PhaseGVN & intcon as well." Alternatively, Compile* can be used as well. Best regards, Vladimir Ivanov >> -----Original Message----- >> From: Vladimir Ivanov >> Sent: Dienstag, 8. Oktober 2019 11:47 >> To: Michihiro Horie >> Cc: hotspot compiler ; Doerr, >> Martin ; ppc-aix-port-dev at openjdk.java.net >> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power >> >> >>> http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/ >> >> Looks good. >> >> (Test results are clean.) >> >> Best regards, >> Vladimir Ivanov >> >>> > I think it would be better to use adlc?s include generator instead of >>> > including "opto/convertnode.hpp" explicitly in the ad file. >>> > >>> > src/hotspot/share/adlc/main.cpp >>> > >>> > ??? AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); >>> > >>> > +? AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); >>> > >>> > ??? AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); >>> > >>> > @Vladimir: Do you agree? Would you do it this way, too? >>> >>> I prefer current version. >>> >>> When proposing the refactoring I thought about the change in adlc as >>> well, but when I saw the patch I noticed that putting it in AD file >>> stresses it's a platform-specific dependency. >>> >>> I think that's the right way to look at it until we get a way to funnel >>> attributes from ideal nodes to mach nodes and use them during code >>> emission. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> > *From:*Michihiro Horie >>> > *Sent:* Montag, 7. Oktober 2019 17:54 >>> > *To:* Vladimir Ivanov >>> > *Cc:* hotspot compiler ; >> Doerr, >>> > Martin ; ppc-aix-port-dev at openjdk.java.net >>> > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, >>> > rint on Power >>> > >>> > Hi Martin, Vladimir, >>> > Thanks a lot for your further feedback, which makes sense. >>> > >>> > New webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ >>> > >>> > Best regards, >>> > Michihiro >>> > >>> > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> >>> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov >>> > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, Michihiro. >>> > >>> > From: Vladimir Ivanov >> > > >>> > To: Michihiro Horie >, >>> > "Doerr, Martin" > > >>> > Cc: hotspot compiler >> > >, >>> > "ppc-aix-port-dev at openjdk.java.net >>> > " >>> > >> > > >>> > Date: 2019/10/07 22:51 >>> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, >>> > floor, rint on Power >>> > >>> > ------------------------------------------------------------------------ >>> > >>> > >>> > >>> > >>> > >>> >> Fixed webrev is as follows. >>> > >>> > Thanks, Michihiro. >>> > >>> >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ >>> > >>> > src/hotspot/share/opto/convertnode.hpp: >>> > >>> > + ?enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; >>> > >>> > Please, explicitly initialize the elements. Numbering is important since >>> > it is aligned with instruction encoding on x86. >>> > >>> > >>> > src/hotspot/share/opto/library_call.cpp: >>> > >>> > + ?case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, >>> > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); >> break; >>> > >>> > Please, change RoundDoubleModeNode to accept the enum instead and >>> > instantiate the ConI node inside it or introduce a static factory >>> > (::make(GraphKit*,RoundingMode)) for that purpose. >>> > >>> > >>> > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: >>> > >>> > + ?void math_round(const FloatRegister t, const FloatRegister b, int >>> rmode); >>> > + ?void math_round_vec(const VectorSRegister t, const VectorSRegister >> b, >>> > int rmode); >>> > >>> > I suggest to get rid of helpers in MacroAssembler and simply move the >>> > code into corresponding AD instructions. >>> > >>> > Best regards, >>> > Vladimir Ivanov >>> > >>> >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I >>> >> suggest to put the enum in RoundDoubleModeNode (convertn"Doerr, >> Martin" >>> >> ---2019/10/07 22:09:15---> I suggest to put the enum in >>> >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction >> selectio >>> >> >>> >> From: "Doerr, Martin" >> > >>> >> To: Vladimir Ivanov >> >, >>> > Michihiro Horie >>> >> > >>> >> Cc: hotspot compiler >> > >, >>> >> "ppc-aix-port-dev at openjdk.java.net >>> > " >>> > >> > > >>> >> Date: 2019/10/07 22:09 >>> >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, >>> >> floor, rint on Power >>> >> >>> >> ------------------------------------------------------------------------ >>> >> >>> >> >>> >> >>> >> ?> I suggest to put the enum in RoundDoubleModeNode >> (convertnode.hpp) >>> >> ?> and lift instruction selection logic from macroAssembler_ppc.cpp >>> into >>> >> ppc.ad. >>> >> That sounds good. >>> >> >>> >> Thanks, >>> >> Martin >>> >> >>> >> >>> >> ?> -----Original Message----- >>> >> ?> From: Vladimir Ivanov >> > >>> >> ?> Sent: Montag, 7. Oktober 2019 12:55 >>> >> ?> To: Doerr, Martin >> >; Michihiro Horie >>> >> ?> > >>> >> ?> Cc: hotspot compiler >> > >; ppc-aix- >>> >> ?> port-dev at openjdk.java.net >>> >> ?> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, >>> >> rint on Power >>> >> ?> >>> >> ?> > I think sharedRuntime is not a good place for the C2 enum. >>> >> ?> Agree. >>> >> ?> >>> >> ?> I suggest to put the enum in RoundDoubleModeNode >> (convertnode.hpp) >>> >> ?> and >>> >> ?> lift instruction selection logic from macroAssembler_ppc.cpp into >>> ppc.ad. >>> >> ?> >>> >> ?> Best regards, >>> >> ?> Vladimir Ivanov >>> >> ?> >>> >> ?> > >>> >> ?> > Maybe intrinsicnode.hpp would be a better pace for it. But >>> then, the >>> >> ?> > code in macroAssembler should be guarded by #ifdef COMPILER2. >>> >> ?> > >>> >> ?> > Best regards, >>> >> ?> > >>> >> ?> > Martin >>> >> ?> > >>> >> ?> > *From:*Michihiro Horie > > >>> >> ?> > *Sent:* Montag, 7. Oktober 2019 09:14 >>> >> ?> > *To:* Vladimir Ivanov >> > >>> >> ?> > *Cc:* hotspot compiler >> > >; >>> >> ?> > ppc-aix-port-dev at openjdk.java.net >>> > ; Doerr, Martin >>> >> ?> > >>> >> ?> > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, >>> floor, >>> >> ?> > rint on Power >>> >> ?> > >>> >> ?> > Hi Vladimir, >>> >> ?> > >>> >> ?> > Thanks a lot for your nice suggestion. Yes, I prefer enum use. >>> >> ?> > I'm wondering if the enum constants can be declared in >>> >> ?> sharedRuntime.hpp. >>> >> ?> > Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ >>> >> ?> > >>> >> ?> > Best regards, >>> >> ?> > Michihiro >>> >> ?> > >>> >> ?> > Inactive hide details for Vladimir Ivanov ---2019/10/04 >>> 23:05:48---Hi >>> >> ?> > Michihiro, src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir >>> Ivanov >>> >> ?> > ---2019/10/04 23:05:48---Hi Michihiro, >>> >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: >>> >> ?> > >>> >> ?> > From: Vladimir Ivanov >> > > ?> > >>> > > >>> >> ?> > To: Michihiro Horie > >, >>> >> ?> > ppc-aix-port-dev at openjdk.java.net >>> >>> >> ?> > , hotspot compiler >>> >> ?> > >> > > ?> > >>> > > >>> >> ?> > Date: 2019/10/04 23:05 >>> >> ?> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for >>> Math.ceil, >>> >> ?> > floor, rint on Power >>> >> ?> > >>> >> ?> > >>> >> ------------------------------------------------------------------------ >>> >> ?> > >>> >> ?> > >>> >> ?> > >>> >> ?> > >>> >> ?> > Hi Michihiro, >>> >> ?> > >>> >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: >>> >> ?> > + ?switch (rmode) { >>> >> ?> > + ? ?case 0: // rint >>> >> ?> > + ? ? ?frin(t, b); >>> >> ?> > + ? ? ?break; >>> >> ?> > + ? ?case 1: // floor >>> >> ?> > + ? ? ?frim(t, b); >>> >> ?> > + ? ? ?break; >>> >> ?> > + ? ?case 2: // ceil >>> >> ?> > + ? ? ?frip(t, b); >>> >> ?> > + ? ? ?break; >>> >> ?> > + ? ?default: >>> >> ?> > + ? ? ?ShouldNotReachHere(); >>> >> ?> > + ?} >>> >> ?> > >>> >> ?> > What do you think about introducing enum constants instead of >> using >>> >> ?> > hard-coded 0/1/2? >>> >> ?> > >>> >> ?> > src/hotspot/share/opto/library_call.cpp: >>> >> ?> > >>> >> ?> > ?? case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, >>> >> ?> > makecon(TypeInt::make(2))); break; >>> >> ?> > ?? case vmIntrinsics::_floor: ?n = new RoundDoubleModeNode(arg, >>> >> ?> > makecon(TypeInt::make(1))); break; >>> >> ?> > ?? case vmIntrinsics::_rint: ? n = new RoundDoubleModeNode(arg, >>> >> ?> > makecon(TypeInt::make(0))); break; >>> >> ?> > >>> >> ?> > The downside is you have to move the switch from >> macroAssembler >>> >> ?> because >>> >> ?> > enum should be visible from both places. (Is there a better >>> place for >>> >> ?> > that than roundD_regNode::emit() in AD file?) >>> >> ?> > >>> >> ?> > Best regards, >>> >> ?> > Vladimir Ivanov >>> >> ?> > >>> >> ?> > On 02/10/2019 07:27, Michihiro Horie wrote: >>> >> ?> >> >>> >> ?> >> Dear all, >>> >> ?> >> >>> >> ?> >> Would you please review the following change? >>> >> ?> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 >>> >> ?> >> Webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 >>> >> ?> >> >>> >> ?> >> This change adds intrinsics for Math's ceil, floor, and rint for >>> >> PPC64, on >>> >> ?> >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. >>> >> ?> >> >>> >> ?> >> Best regards, >>> >> ?> >> Michihiro >>> >> ?> >> >>> >> ?> > >>> >> ?> > >>> >> ?> > >>> >> >>> >> >>> >> >>> >> >>> > >>> > >>> > >>> >>> >>> >>> From nils.eliasson at oracle.com Tue Oct 8 12:10:50 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 8 Oct 2019 14:10:50 +0200 Subject: RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: References: Message-ID: Updated webrev: http://cr.openjdk.java.net/~neliasso/superlate/webrev.05/ Includes some very minor fixes to make builds pass on all platforms. // Nils On 2019-10-08 09:20, Nils Eliasson wrote: > Hi all, > > Here is the latest patch > http://cr.openjdk.java.net/~neliasso/superlate/webrev.04/ > > This is the full implementation, stable on x64 and aarch64. > > // Nils > > > On 2019-09-26 16:56, Nils Eliasson wrote: >> Hi, >> >> Now I have update the patch in place: >> http://cr.openjdk.java.net/~neliasso/aarch_barriers/aarch_super_late >> >> Status: >> >> Quite stable - hits a problem with monitor_enter_complete - probably >> a bug in cas/cmpx. I'm looking into it >> >> Use optimized spilling with -XX:+UseNewCode2 - a little less stable. >> >> Regards, >> >> Nils >> >> >> On 2019-09-26 16:26, Stuart Monteith wrote: >>> Hello, >>> ??? Yes, I'll try this out - I was in the middle of my own >>> implementation, but I haven't advanced it as far as Nils. >>> >>> BR, >>> ? Stuart >>> >>> On Sat, 21 Sep 2019 at 09:11, Per Liden wrote: >>>> Thanks Nils! >>>> >>>> Stuart, could you take this for a spin and help Nils track down the >>>> last >>>> few issues? >>>> >>>> We're eager to push this as soon as we feel comfortable that the >>>> aarch64 >>>> bits are good enough. >>>> >>>> cheers, >>>> Per >>>> >>>> On 9/20/19 4:50 PM, Nils Eliasson wrote: >>>>> Hi, >>>>> >>>>> This is an attempt of porting the redesigned C2 barriers to aarch64. >>>>> >>>>> Status >>>>> >>>>> * Mostly complete - ad-files should be complete although not fully >>>>> tested yet >>>>> >>>>> * Spilling is implemented but not optimized >>>>> >>>>> * Runs a bit, but far from stable. >>>>> >>>>> >>>>> Patch: http://cr.openjdk.java.net/~neliasso/aarch_barriers/ >>>>> >>>>> Regards, >>>>> >>>>> Nils >>>>> >>>>> >>>>> >>>>> On 2019-09-04 14:58, Erik ?sterlund wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> For many years we have expanded load barriers in the C2 sea of >>>>>> nodes. >>>>>> It has been a constant struggle to keep up with bugs due to >>>>>> optimizations breaking our barriers. It has never truly worked. One >>>>>> particular pain point that has never been handled quite right up >>>>>> until >>>>>> now, is dealing with safepoints ending up between a load and its >>>>>> load >>>>>> barrier. We have had workarounds for that before, but they have >>>>>> never >>>>>> really been enough. >>>>>> >>>>>> In the end, our barrier is only a conditional branch to a slow path, >>>>>> so there is really not much that the optimizer can do to help us >>>>>> make >>>>>> that better. But it has many creative ways of breaking our GC >>>>>> invariants. >>>>>> >>>>>> I think we have finally had enough of this, and want to move the >>>>>> barrier expansion to the MachNode level instead. This way, we can >>>>>> finally put an end to the load and its load barrier being separated >>>>>> (and related even more complicated issues for atomics). >>>>>> >>>>>> Our new solution is to tag accesses that want load barriers during >>>>>> parsing, and then let C2 optimize whatever it wants to, >>>>>> invariantly of >>>>>> GC barriers. Then it will match mach nodes, and perform global code >>>>>> motion and scheduling. Only right before dumping the machine code of >>>>>> the resulting graph do we call into the barrier set to perform last >>>>>> second analysis of barriers, and then during machine code >>>>>> dumping, we >>>>>> inject our load barriers. After the normal insts() are dumped, we >>>>>> inject slow path stubs for our barriers. >>>>>> >>>>>> There are two optimizations that we would like to retain in this >>>>>> scheme. >>>>>> >>>>>> Optimization 1: Dominating barrier analysis >>>>>> Previously, we instantiated a PhaseIdealLoop instance to analyze >>>>>> dominating barriers. That was convenient because a dominator tree is >>>>>> available for finding load barriers that dominate other load >>>>>> barriers >>>>>> in the CFG. I built a new more precise analysis on the PhaseCFG >>>>>> level >>>>>> instead, happening after the matching to mach nodes. The analysis is >>>>>> now looking for dominating accesses, instead of dominating load >>>>>> barriers. Because any dominating access, including stores, will make >>>>>> sure that what is left behind in memory is "good". Another thing >>>>>> that >>>>>> makes the analysis more precise, is that it doesn't require strict >>>>>> dominance in the CFG. If the earlier access is in the same Block >>>>>> as an >>>>>> access with barriers, we now also utilize knowledge about the >>>>>> scheduling of the instructions, which has completed at this >>>>>> point. So >>>>>> we can safely remove such pointless load barriers in the same block >>>>>> now. The analysis is performed right before machine code is emitted, >>>>>> so we can trust that it won't change after the analysis due to >>>>>> optimizations. >>>>>> >>>>>> Optimization 2: Tight register spilling >>>>>> When we call the slow path of our barriers, we want to spill only >>>>>> the >>>>>> registers that are live. Previously, we had a special >>>>>> LoadBarrierSlowReg node corresponding to the slow path, that killed >>>>>> all XMM registers, and then all general purpose registers were >>>>>> called >>>>>> in the slow path. Now we instead perform explicit live analysis >>>>>> of our >>>>>> registers on MachNodes, including how large chunks of vector >>>>>> registers >>>>>> are being used, and spill only exactly the registers that are live >>>>>> (and only the part of the register that is live for XMM/YMM/ZMM >>>>>> registers). >>>>>> >>>>>> Zooming out a bit, all complexity of pulling the barriers in the sea >>>>>> of nodes through various interesting phases while retaining GC >>>>>> invariants such as "don't put safepoints in my barrier", become >>>>>> trivial and no longer an issue. We simply tag our loads to need >>>>>> barriers, and let C2 do whatever it wants to in the sea of nodes. >>>>>> Once >>>>>> all scheduling is done, we do our thing. Hopefully this will make >>>>>> the >>>>>> barriers as stable and resilient as our C1 barriers, which cause >>>>>> trouble extremely rarely. >>>>>> >>>>>> We have run a number of benchmarks. We have observed a number of >>>>>> improvements, but never any regressions. There has been countless >>>>>> runs >>>>>> through gc-test-suite, and a few hs-tier1-6 and his tier1-7 runs. >>>>>> >>>>>> Finally, I would like to thank Per and StefanK for the many hours >>>>>> spent on helping me with this patch, both in terms of spotting flaws >>>>>> in my prototypes, benchmarking, testing, and refactoring so the code >>>>>> looks nice and much more understandable. I will add both to the >>>>>> Contributed-by line. >>>>>> >>>>>> @Stuart: It would be awesome if you could provide some AArch64 bits >>>>>> for this patch so we do things the same way (ish). >>>>>> >>>>>> Bug: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8230565 >>>>>> >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~eosterlund/8230565/webrev.00/ >>>>>> >>>>>> Thanks, >>>>>> /Erik From per.liden at oracle.com Tue Oct 8 13:30:49 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 8 Oct 2019 15:30:49 +0200 Subject: RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: References: Message-ID: <41d1807c-f4b7-2b74-11c2-e0d9fc5784ca@oracle.com> Looks good! /Per On 10/8/19 2:10 PM, Nils Eliasson wrote: > Updated webrev: > > http://cr.openjdk.java.net/~neliasso/superlate/webrev.05/ > > Includes some very minor fixes to make builds pass on all platforms. > > // Nils > > > On 2019-10-08 09:20, Nils Eliasson wrote: >> Hi all, >> >> Here is the latest patch >> http://cr.openjdk.java.net/~neliasso/superlate/webrev.04/ >> >> This is the full implementation, stable on x64 and aarch64. >> >> // Nils >> >> >> On 2019-09-26 16:56, Nils Eliasson wrote: >>> Hi, >>> >>> Now I have update the patch in place: >>> http://cr.openjdk.java.net/~neliasso/aarch_barriers/aarch_super_late >>> >>> Status: >>> >>> Quite stable - hits a problem with monitor_enter_complete - probably >>> a bug in cas/cmpx. I'm looking into it >>> >>> Use optimized spilling with -XX:+UseNewCode2 - a little less stable. >>> >>> Regards, >>> >>> Nils >>> >>> >>> On 2019-09-26 16:26, Stuart Monteith wrote: >>>> Hello, >>>> ??? Yes, I'll try this out - I was in the middle of my own >>>> implementation, but I haven't advanced it as far as Nils. >>>> >>>> BR, >>>> ? Stuart >>>> >>>> On Sat, 21 Sep 2019 at 09:11, Per Liden wrote: >>>>> Thanks Nils! >>>>> >>>>> Stuart, could you take this for a spin and help Nils track down the >>>>> last >>>>> few issues? >>>>> >>>>> We're eager to push this as soon as we feel comfortable that the >>>>> aarch64 >>>>> bits are good enough. >>>>> >>>>> cheers, >>>>> Per >>>>> >>>>> On 9/20/19 4:50 PM, Nils Eliasson wrote: >>>>>> Hi, >>>>>> >>>>>> This is an attempt of porting the redesigned C2 barriers to aarch64. >>>>>> >>>>>> Status >>>>>> >>>>>> * Mostly complete - ad-files should be complete although not fully >>>>>> tested yet >>>>>> >>>>>> * Spilling is implemented but not optimized >>>>>> >>>>>> * Runs a bit, but far from stable. >>>>>> >>>>>> >>>>>> Patch: http://cr.openjdk.java.net/~neliasso/aarch_barriers/ >>>>>> >>>>>> Regards, >>>>>> >>>>>> Nils >>>>>> >>>>>> >>>>>> >>>>>> On 2019-09-04 14:58, Erik ?sterlund wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> For many years we have expanded load barriers in the C2 sea of >>>>>>> nodes. >>>>>>> It has been a constant struggle to keep up with bugs due to >>>>>>> optimizations breaking our barriers. It has never truly worked. One >>>>>>> particular pain point that has never been handled quite right up >>>>>>> until >>>>>>> now, is dealing with safepoints ending up between a load and its >>>>>>> load >>>>>>> barrier. We have had workarounds for that before, but they have >>>>>>> never >>>>>>> really been enough. >>>>>>> >>>>>>> In the end, our barrier is only a conditional branch to a slow path, >>>>>>> so there is really not much that the optimizer can do to help us >>>>>>> make >>>>>>> that better. But it has many creative ways of breaking our GC >>>>>>> invariants. >>>>>>> >>>>>>> I think we have finally had enough of this, and want to move the >>>>>>> barrier expansion to the MachNode level instead. This way, we can >>>>>>> finally put an end to the load and its load barrier being separated >>>>>>> (and related even more complicated issues for atomics). >>>>>>> >>>>>>> Our new solution is to tag accesses that want load barriers during >>>>>>> parsing, and then let C2 optimize whatever it wants to, >>>>>>> invariantly of >>>>>>> GC barriers. Then it will match mach nodes, and perform global code >>>>>>> motion and scheduling. Only right before dumping the machine code of >>>>>>> the resulting graph do we call into the barrier set to perform last >>>>>>> second analysis of barriers, and then during machine code >>>>>>> dumping, we >>>>>>> inject our load barriers. After the normal insts() are dumped, we >>>>>>> inject slow path stubs for our barriers. >>>>>>> >>>>>>> There are two optimizations that we would like to retain in this >>>>>>> scheme. >>>>>>> >>>>>>> Optimization 1: Dominating barrier analysis >>>>>>> Previously, we instantiated a PhaseIdealLoop instance to analyze >>>>>>> dominating barriers. That was convenient because a dominator tree is >>>>>>> available for finding load barriers that dominate other load >>>>>>> barriers >>>>>>> in the CFG. I built a new more precise analysis on the PhaseCFG >>>>>>> level >>>>>>> instead, happening after the matching to mach nodes. The analysis is >>>>>>> now looking for dominating accesses, instead of dominating load >>>>>>> barriers. Because any dominating access, including stores, will make >>>>>>> sure that what is left behind in memory is "good". Another thing >>>>>>> that >>>>>>> makes the analysis more precise, is that it doesn't require strict >>>>>>> dominance in the CFG. If the earlier access is in the same Block >>>>>>> as an >>>>>>> access with barriers, we now also utilize knowledge about the >>>>>>> scheduling of the instructions, which has completed at this >>>>>>> point. So >>>>>>> we can safely remove such pointless load barriers in the same block >>>>>>> now. The analysis is performed right before machine code is emitted, >>>>>>> so we can trust that it won't change after the analysis due to >>>>>>> optimizations. >>>>>>> >>>>>>> Optimization 2: Tight register spilling >>>>>>> When we call the slow path of our barriers, we want to spill only >>>>>>> the >>>>>>> registers that are live. Previously, we had a special >>>>>>> LoadBarrierSlowReg node corresponding to the slow path, that killed >>>>>>> all XMM registers, and then all general purpose registers were >>>>>>> called >>>>>>> in the slow path. Now we instead perform explicit live analysis >>>>>>> of our >>>>>>> registers on MachNodes, including how large chunks of vector >>>>>>> registers >>>>>>> are being used, and spill only exactly the registers that are live >>>>>>> (and only the part of the register that is live for XMM/YMM/ZMM >>>>>>> registers). >>>>>>> >>>>>>> Zooming out a bit, all complexity of pulling the barriers in the sea >>>>>>> of nodes through various interesting phases while retaining GC >>>>>>> invariants such as "don't put safepoints in my barrier", become >>>>>>> trivial and no longer an issue. We simply tag our loads to need >>>>>>> barriers, and let C2 do whatever it wants to in the sea of nodes. >>>>>>> Once >>>>>>> all scheduling is done, we do our thing. Hopefully this will make >>>>>>> the >>>>>>> barriers as stable and resilient as our C1 barriers, which cause >>>>>>> trouble extremely rarely. >>>>>>> >>>>>>> We have run a number of benchmarks. We have observed a number of >>>>>>> improvements, but never any regressions. There has been countless >>>>>>> runs >>>>>>> through gc-test-suite, and a few hs-tier1-6 and his tier1-7 runs. >>>>>>> >>>>>>> Finally, I would like to thank Per and StefanK for the many hours >>>>>>> spent on helping me with this patch, both in terms of spotting flaws >>>>>>> in my prototypes, benchmarking, testing, and refactoring so the code >>>>>>> looks nice and much more understandable. I will add both to the >>>>>>> Contributed-by line. >>>>>>> >>>>>>> @Stuart: It would be awesome if you could provide some AArch64 bits >>>>>>> for this patch so we do things the same way (ish). >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8230565 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~eosterlund/8230565/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Erik From nils.eliasson at oracle.com Tue Oct 8 13:37:06 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 8 Oct 2019 15:37:06 +0200 Subject: RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: <41d1807c-f4b7-2b74-11c2-e0d9fc5784ca@oracle.com> References: <41d1807c-f4b7-2b74-11c2-e0d9fc5784ca@oracle.com> Message-ID: <655c746e-2456-4422-5c14-d49e08864acf@oracle.com> For the non-Aarch64 parts: Looks good! Reviewed. // Nils On 2019-10-08 15:30, Per Liden wrote: > Looks good! > > /Per > > On 10/8/19 2:10 PM, Nils Eliasson wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~neliasso/superlate/webrev.05/ >> >> Includes some very minor fixes to make builds pass on all platforms. >> >> // Nils >> >> >> On 2019-10-08 09:20, Nils Eliasson wrote: >>> Hi all, >>> >>> Here is the latest patch >>> http://cr.openjdk.java.net/~neliasso/superlate/webrev.04/ >>> >>> This is the full implementation, stable on x64 and aarch64. >>> >>> // Nils >>> >>> >>> On 2019-09-26 16:56, Nils Eliasson wrote: >>>> Hi, >>>> >>>> Now I have update the patch in place: >>>> http://cr.openjdk.java.net/~neliasso/aarch_barriers/aarch_super_late >>>> >>>> Status: >>>> >>>> Quite stable - hits a problem with monitor_enter_complete - >>>> probably a bug in cas/cmpx. I'm looking into it >>>> >>>> Use optimized spilling with -XX:+UseNewCode2 - a little less stable. >>>> >>>> Regards, >>>> >>>> Nils >>>> >>>> >>>> On 2019-09-26 16:26, Stuart Monteith wrote: >>>>> Hello, >>>>> ??? Yes, I'll try this out - I was in the middle of my own >>>>> implementation, but I haven't advanced it as far as Nils. >>>>> >>>>> BR, >>>>> ? Stuart >>>>> >>>>> On Sat, 21 Sep 2019 at 09:11, Per Liden wrote: >>>>>> Thanks Nils! >>>>>> >>>>>> Stuart, could you take this for a spin and help Nils track down >>>>>> the last >>>>>> few issues? >>>>>> >>>>>> We're eager to push this as soon as we feel comfortable that the >>>>>> aarch64 >>>>>> bits are good enough. >>>>>> >>>>>> cheers, >>>>>> Per >>>>>> >>>>>> On 9/20/19 4:50 PM, Nils Eliasson wrote: >>>>>>> Hi, >>>>>>> >>>>>>> This is an attempt of porting the redesigned C2 barriers to >>>>>>> aarch64. >>>>>>> >>>>>>> Status >>>>>>> >>>>>>> * Mostly complete - ad-files should be complete although not fully >>>>>>> tested yet >>>>>>> >>>>>>> * Spilling is implemented but not optimized >>>>>>> >>>>>>> * Runs a bit, but far from stable. >>>>>>> >>>>>>> >>>>>>> Patch: http://cr.openjdk.java.net/~neliasso/aarch_barriers/ >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Nils >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 2019-09-04 14:58, Erik ?sterlund wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> For many years we have expanded load barriers in the C2 sea of >>>>>>>> nodes. >>>>>>>> It has been a constant struggle to keep up with bugs due to >>>>>>>> optimizations breaking our barriers. It has never truly worked. >>>>>>>> One >>>>>>>> particular pain point that has never been handled quite right >>>>>>>> up until >>>>>>>> now, is dealing with safepoints ending up between a load and >>>>>>>> its load >>>>>>>> barrier. We have had workarounds for that before, but they have >>>>>>>> never >>>>>>>> really been enough. >>>>>>>> >>>>>>>> In the end, our barrier is only a conditional branch to a slow >>>>>>>> path, >>>>>>>> so there is really not much that the optimizer can do to help >>>>>>>> us make >>>>>>>> that better. But it has many creative ways of breaking our GC >>>>>>>> invariants. >>>>>>>> >>>>>>>> I think we have finally had enough of this, and want to move the >>>>>>>> barrier expansion to the MachNode level instead. This way, we can >>>>>>>> finally put an end to the load and its load barrier being >>>>>>>> separated >>>>>>>> (and related even more complicated issues for atomics). >>>>>>>> >>>>>>>> Our new solution is to tag accesses that want load barriers during >>>>>>>> parsing, and then let C2 optimize whatever it wants to, >>>>>>>> invariantly of >>>>>>>> GC barriers. Then it will match mach nodes, and perform global >>>>>>>> code >>>>>>>> motion and scheduling. Only right before dumping the machine >>>>>>>> code of >>>>>>>> the resulting graph do we call into the barrier set to perform >>>>>>>> last >>>>>>>> second analysis of barriers, and then during machine code >>>>>>>> dumping, we >>>>>>>> inject our load barriers. After the normal insts() are dumped, we >>>>>>>> inject slow path stubs for our barriers. >>>>>>>> >>>>>>>> There are two optimizations that we would like to retain in >>>>>>>> this scheme. >>>>>>>> >>>>>>>> Optimization 1: Dominating barrier analysis >>>>>>>> Previously, we instantiated a PhaseIdealLoop instance to analyze >>>>>>>> dominating barriers. That was convenient because a dominator >>>>>>>> tree is >>>>>>>> available for finding load barriers that dominate other load >>>>>>>> barriers >>>>>>>> in the CFG. I built a new more precise analysis on the PhaseCFG >>>>>>>> level >>>>>>>> instead, happening after the matching to mach nodes. The >>>>>>>> analysis is >>>>>>>> now looking for dominating accesses, instead of dominating load >>>>>>>> barriers. Because any dominating access, including stores, will >>>>>>>> make >>>>>>>> sure that what is left behind in memory is "good". Another >>>>>>>> thing that >>>>>>>> makes the analysis more precise, is that it doesn't require strict >>>>>>>> dominance in the CFG. If the earlier access is in the same >>>>>>>> Block as an >>>>>>>> access with barriers, we now also utilize knowledge about the >>>>>>>> scheduling of the instructions, which has completed at this >>>>>>>> point. So >>>>>>>> we can safely remove such pointless load barriers in the same >>>>>>>> block >>>>>>>> now. The analysis is performed right before machine code is >>>>>>>> emitted, >>>>>>>> so we can trust that it won't change after the analysis due to >>>>>>>> optimizations. >>>>>>>> >>>>>>>> Optimization 2: Tight register spilling >>>>>>>> When we call the slow path of our barriers, we want to spill >>>>>>>> only the >>>>>>>> registers that are live. Previously, we had a special >>>>>>>> LoadBarrierSlowReg node corresponding to the slow path, that >>>>>>>> killed >>>>>>>> all XMM registers, and then all general purpose registers were >>>>>>>> called >>>>>>>> in the slow path. Now we instead perform explicit live analysis >>>>>>>> of our >>>>>>>> registers on MachNodes, including how large chunks of vector >>>>>>>> registers >>>>>>>> are being used, and spill only exactly the registers that are live >>>>>>>> (and only the part of the register that is live for XMM/YMM/ZMM >>>>>>>> registers). >>>>>>>> >>>>>>>> Zooming out a bit, all complexity of pulling the barriers in >>>>>>>> the sea >>>>>>>> of nodes through various interesting phases while retaining GC >>>>>>>> invariants such as "don't put safepoints in my barrier", become >>>>>>>> trivial and no longer an issue. We simply tag our loads to need >>>>>>>> barriers, and let C2 do whatever it wants to in the sea of >>>>>>>> nodes. Once >>>>>>>> all scheduling is done, we do our thing. Hopefully this will >>>>>>>> make the >>>>>>>> barriers as stable and resilient as our C1 barriers, which cause >>>>>>>> trouble extremely rarely. >>>>>>>> >>>>>>>> We have run a number of benchmarks. We have observed a number of >>>>>>>> improvements, but never any regressions. There has been >>>>>>>> countless runs >>>>>>>> through gc-test-suite, and a few hs-tier1-6 and his tier1-7 runs. >>>>>>>> >>>>>>>> Finally, I would like to thank Per and StefanK for the many hours >>>>>>>> spent on helping me with this patch, both in terms of spotting >>>>>>>> flaws >>>>>>>> in my prototypes, benchmarking, testing, and refactoring so the >>>>>>>> code >>>>>>>> looks nice and much more understandable. I will add both to the >>>>>>>> Contributed-by line. >>>>>>>> >>>>>>>> @Stuart: It would be awesome if you could provide some AArch64 >>>>>>>> bits >>>>>>>> for this patch so we do things the same way (ish). >>>>>>>> >>>>>>>> Bug: >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8230565 >>>>>>>> >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~eosterlund/8230565/webrev.00/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> /Erik From erik.osterlund at oracle.com Tue Oct 8 15:34:25 2019 From: erik.osterlund at oracle.com (erik.osterlund at oracle.com) Date: Tue, 8 Oct 2019 17:34:25 +0200 Subject: RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: References: Message-ID: <1fb91ab5-692d-a868-e99f-55966e7359ac@oracle.com> Hi Nils, That AArch64 code looks good to me. Thanks for sorting it out. Thanks, /Erik On 10/8/19 2:10 PM, Nils Eliasson wrote: > Updated webrev: > > http://cr.openjdk.java.net/~neliasso/superlate/webrev.05/ > > Includes some very minor fixes to make builds pass on all platforms. > > // Nils > > > On 2019-10-08 09:20, Nils Eliasson wrote: >> Hi all, >> >> Here is the latest patch >> http://cr.openjdk.java.net/~neliasso/superlate/webrev.04/ >> >> This is the full implementation, stable on x64 and aarch64. >> >> // Nils >> >> >> On 2019-09-26 16:56, Nils Eliasson wrote: >>> Hi, >>> >>> Now I have update the patch in place: >>> http://cr.openjdk.java.net/~neliasso/aarch_barriers/aarch_super_late >>> >>> Status: >>> >>> Quite stable - hits a problem with monitor_enter_complete - probably >>> a bug in cas/cmpx. I'm looking into it >>> >>> Use optimized spilling with -XX:+UseNewCode2 - a little less stable. >>> >>> Regards, >>> >>> Nils >>> >>> >>> On 2019-09-26 16:26, Stuart Monteith wrote: >>>> Hello, >>>> ??? Yes, I'll try this out - I was in the middle of my own >>>> implementation, but I haven't advanced it as far as Nils. >>>> >>>> BR, >>>> ? Stuart >>>> >>>> On Sat, 21 Sep 2019 at 09:11, Per Liden wrote: >>>>> Thanks Nils! >>>>> >>>>> Stuart, could you take this for a spin and help Nils track down >>>>> the last >>>>> few issues? >>>>> >>>>> We're eager to push this as soon as we feel comfortable that the >>>>> aarch64 >>>>> bits are good enough. >>>>> >>>>> cheers, >>>>> Per >>>>> >>>>> On 9/20/19 4:50 PM, Nils Eliasson wrote: >>>>>> Hi, >>>>>> >>>>>> This is an attempt of porting the redesigned C2 barriers to aarch64. >>>>>> >>>>>> Status >>>>>> >>>>>> * Mostly complete - ad-files should be complete although not fully >>>>>> tested yet >>>>>> >>>>>> * Spilling is implemented but not optimized >>>>>> >>>>>> * Runs a bit, but far from stable. >>>>>> >>>>>> >>>>>> Patch: http://cr.openjdk.java.net/~neliasso/aarch_barriers/ >>>>>> >>>>>> Regards, >>>>>> >>>>>> Nils >>>>>> >>>>>> >>>>>> >>>>>> On 2019-09-04 14:58, Erik ?sterlund wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> For many years we have expanded load barriers in the C2 sea of >>>>>>> nodes. >>>>>>> It has been a constant struggle to keep up with bugs due to >>>>>>> optimizations breaking our barriers. It has never truly worked. One >>>>>>> particular pain point that has never been handled quite right up >>>>>>> until >>>>>>> now, is dealing with safepoints ending up between a load and its >>>>>>> load >>>>>>> barrier. We have had workarounds for that before, but they have >>>>>>> never >>>>>>> really been enough. >>>>>>> >>>>>>> In the end, our barrier is only a conditional branch to a slow >>>>>>> path, >>>>>>> so there is really not much that the optimizer can do to help us >>>>>>> make >>>>>>> that better. But it has many creative ways of breaking our GC >>>>>>> invariants. >>>>>>> >>>>>>> I think we have finally had enough of this, and want to move the >>>>>>> barrier expansion to the MachNode level instead. This way, we can >>>>>>> finally put an end to the load and its load barrier being separated >>>>>>> (and related even more complicated issues for atomics). >>>>>>> >>>>>>> Our new solution is to tag accesses that want load barriers during >>>>>>> parsing, and then let C2 optimize whatever it wants to, >>>>>>> invariantly of >>>>>>> GC barriers. Then it will match mach nodes, and perform global code >>>>>>> motion and scheduling. Only right before dumping the machine >>>>>>> code of >>>>>>> the resulting graph do we call into the barrier set to perform last >>>>>>> second analysis of barriers, and then during machine code >>>>>>> dumping, we >>>>>>> inject our load barriers. After the normal insts() are dumped, we >>>>>>> inject slow path stubs for our barriers. >>>>>>> >>>>>>> There are two optimizations that we would like to retain in this >>>>>>> scheme. >>>>>>> >>>>>>> Optimization 1: Dominating barrier analysis >>>>>>> Previously, we instantiated a PhaseIdealLoop instance to analyze >>>>>>> dominating barriers. That was convenient because a dominator >>>>>>> tree is >>>>>>> available for finding load barriers that dominate other load >>>>>>> barriers >>>>>>> in the CFG. I built a new more precise analysis on the PhaseCFG >>>>>>> level >>>>>>> instead, happening after the matching to mach nodes. The >>>>>>> analysis is >>>>>>> now looking for dominating accesses, instead of dominating load >>>>>>> barriers. Because any dominating access, including stores, will >>>>>>> make >>>>>>> sure that what is left behind in memory is "good". Another thing >>>>>>> that >>>>>>> makes the analysis more precise, is that it doesn't require strict >>>>>>> dominance in the CFG. If the earlier access is in the same Block >>>>>>> as an >>>>>>> access with barriers, we now also utilize knowledge about the >>>>>>> scheduling of the instructions, which has completed at this >>>>>>> point. So >>>>>>> we can safely remove such pointless load barriers in the same block >>>>>>> now. The analysis is performed right before machine code is >>>>>>> emitted, >>>>>>> so we can trust that it won't change after the analysis due to >>>>>>> optimizations. >>>>>>> >>>>>>> Optimization 2: Tight register spilling >>>>>>> When we call the slow path of our barriers, we want to spill >>>>>>> only the >>>>>>> registers that are live. Previously, we had a special >>>>>>> LoadBarrierSlowReg node corresponding to the slow path, that killed >>>>>>> all XMM registers, and then all general purpose registers were >>>>>>> called >>>>>>> in the slow path. Now we instead perform explicit live analysis >>>>>>> of our >>>>>>> registers on MachNodes, including how large chunks of vector >>>>>>> registers >>>>>>> are being used, and spill only exactly the registers that are live >>>>>>> (and only the part of the register that is live for XMM/YMM/ZMM >>>>>>> registers). >>>>>>> >>>>>>> Zooming out a bit, all complexity of pulling the barriers in the >>>>>>> sea >>>>>>> of nodes through various interesting phases while retaining GC >>>>>>> invariants such as "don't put safepoints in my barrier", become >>>>>>> trivial and no longer an issue. We simply tag our loads to need >>>>>>> barriers, and let C2 do whatever it wants to in the sea of >>>>>>> nodes. Once >>>>>>> all scheduling is done, we do our thing. Hopefully this will >>>>>>> make the >>>>>>> barriers as stable and resilient as our C1 barriers, which cause >>>>>>> trouble extremely rarely. >>>>>>> >>>>>>> We have run a number of benchmarks. We have observed a number of >>>>>>> improvements, but never any regressions. There has been >>>>>>> countless runs >>>>>>> through gc-test-suite, and a few hs-tier1-6 and his tier1-7 runs. >>>>>>> >>>>>>> Finally, I would like to thank Per and StefanK for the many hours >>>>>>> spent on helping me with this patch, both in terms of spotting >>>>>>> flaws >>>>>>> in my prototypes, benchmarking, testing, and refactoring so the >>>>>>> code >>>>>>> looks nice and much more understandable. I will add both to the >>>>>>> Contributed-by line. >>>>>>> >>>>>>> @Stuart: It would be awesome if you could provide some AArch64 bits >>>>>>> for this patch so we do things the same way (ish). >>>>>>> >>>>>>> Bug: >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8230565 >>>>>>> >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~eosterlund/8230565/webrev.00/ >>>>>>> >>>>>>> Thanks, >>>>>>> /Erik From vivek.r.deshpande at intel.com Tue Oct 8 17:50:10 2019 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Tue, 8 Oct 2019 17:50:10 +0000 Subject: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors In-Reply-To: <6dd7c943-c79e-c384-c94e-c3ad16f8c7a5@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB731EE6@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> <7f41aab7-4c53-6254-3518-49691d527a6a@oracle.com> <6dd7c943-c79e-c384-c94e-c3ad16f8c7a5@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7CDA58@fmsmsx121.amr.corp.intel.com> Hi Vladimir VecX has higher bank of registers when there is support for avx512vl avx512bw and avx512dq. The VecX works for Repl4F_zero as the xorps calls vpxor when avx512vl bw dq are not available. This is the snippet from macroAssembler which is used here: void MacroAssembler::xorps(XMMRegister dst, XMMRegister src) { if (UseAVX > 2 && !VM_Version::supports_avx512dq() && (dst->encoding() == src->encoding())) { Assembler::vpxor(dst, dst, src, Assembler::AVX_512bit); } else { Assembler::xorps(dst, src); } } For the 2nd thing in MoveVecX2Leg, you may be right and could be an opportunity to improve. Regards, Vivek -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Monday, October 7, 2019 10:18 AM To: Deshpande, Vivek R ; 'hotspot-compiler-dev at openjdk.java.net' Cc: 'Robert Strout' ; 'Scott Oaks' Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors Vivek, Thinking more about it, I got a question: src/hotspot/cpu/x86/x86.ad: instruct Repl4F_zero(vecX dst, immF0 zero) %{ - predicate(n->as_Vector()->length() == 4 && UseAVX < 3); + predicate(n->as_Vector()->length() == 4); match(Set dst (ReplicateF zero)); format %{ "xorps $dst,$dst\t! replicate4F zero" %} ins_encode %{ __ xorps($dst$$XMMRegister, $dst$$XMMRegister); %} ins_pipe( fpu_reg_reg ); %} -instruct Repl4F_zero_evex(vecX dst, immF0 zero) %{ - predicate(n->as_Vector()->length() == 4 && UseAVX > 2); - match(Set dst (ReplicateF zero)); - format %{ "vpxor $dst k0,$dst,$dst\t! replicate4F zero" %} - ins_encode %{ - // Use vpxor in place of vxorps since EVEX has a constriant on dq for vxorps: this is a 512-bit operation - int vector_len = 2; - __ vpxor($dst$$XMMRegister,$dst$$XMMRegister, $dst$$XMMRegister, vector_len); - %} - ins_pipe( fpu_reg_reg ); -%} Any issues with vecX when encoding xorps with dst in higher half (xmm16-31) without avx512vl support? Should it be turned to legVecX? Also: // Load vectors (16 bytes long) instruct MoveVecX2Leg(legVecX dst, vecX src) %{ match(Set dst src); format %{ "movdqu $dst,$src\t! load vector (16 bytes)" %} ins_encode %{ if (UseAVX > 2 && !VM_Version::supports_avx512vl()) { int vector_len = 2; __ evmovdquq($dst$$XMMRegister, $src$$XMMRegister, vector_len); } else { __ movdqu($dst$$XMMRegister, $src$$XMMRegister); } %} ins_pipe( fpu_reg_reg ); %} From performance perspective, does it make any sense to further limit EVEX-encoded case when src is in lower half of the range (0-15)? Best regards, Vladimir Ivanov On 07/10/2019 14:03, Vladimir Ivanov wrote: > >> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.01/ > > Looks good. > > Best regards, > Vladimir Ivanov > >> -----Original Message----- >> From: Deshpande, Vivek R >> Sent: Thursday, September 26, 2019 10:52 AM >> To: Vladimir Kozlov ; >> hotspot-compiler-dev at openjdk.java.net >> Cc: Scott Oaks ; eric.caspole >> ; Robert Strout >> Subject: RE: RFR: 8221092: UseAVX=3 has performance degredation on >> Skylake (X7) processors >> >> Thanks you Vladimir for the review. >> I will work on the adding the comments and changes to the bug report. >> >> Yes the threshold is for architectures after skylake which support >> AVX512. >> With this threshold( value = 4096 bytes found experimentally), AVX512 >> will be used if the array size is bigger than that. >> >> Regards, >> Vivek >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Wednesday, September 25, 2019 12:41 PM >> To: Deshpande, Vivek R ; >> hotspot-compiler-dev at openjdk.java.net >> Cc: Scott Oaks ; eric.caspole >> ; Robert Strout >> Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on >> Skylake (X7) processors >> >> Thank you, Vivek >> >> I see you did several changes including intrinsics code. Would be nice >> if you list changes you did in bug report. I see you removed _evex >> instructions variants in .ad file, replaced evex instructions in stubs >> and set UseAVX to 2 for Skylake. It is easy to understand. >> >> But what about array limit AVX3Threshold? I assume it is for >> non-Skylake CPUs with AVX512. Right? >> What number 4096 is based on. It seems AVX3Threshold == 0 has special >> meaning - add line in globals_x86.hpp explaining it. I would need more >> time to look on related changes. >> >> Thanks, >> Vladimir >> >> On 9/3/19 5:02 PM, Deshpande, Vivek R wrote: >>> Hi All >>> >>> I have created a patch which sets AVX2 for Skylake and selectively >>> uses EVEX instructions based on threshold for platforms after Skylake. >>> I don't observe the regressions for SPECjvm2008 on Skylake with this >>> patch. >>> JBS id: >>> https://bugs.openjdk.java.net/browse/JDK-8221092 >>> Webrev: >>> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.00/ >>> Could you all please review the patch. >>> >>> Regards, >>> Vivek >>> From vladimir.x.ivanov at oracle.com Tue Oct 8 18:10:22 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 8 Oct 2019 21:10:22 +0300 Subject: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7CDA58@fmsmsx121.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB731EE6@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> <7f41aab7-4c53-6254-3518-49691d527a6a@oracle.com> <6dd7c943-c79e-c384-c94e-c3ad16f8c7a5@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7CDA58@fmsmsx121.amr.corp.intel.com> Message-ID: <918e6bcc-1f96-ee57-2ec9-a4e58446ded0@oracle.com> Thanks for the clarifications, Vivek. > VecX has higher bank of registers when there is support for avx512vl avx512bw and avx512dq. > The VecX works for Repl4F_zero as the xorps calls vpxor when avx512vl bw dq are not available. > > This is the snippet from macroAssembler which is used here: > void MacroAssembler::xorps(XMMRegister dst, XMMRegister src) { > if (UseAVX > 2 && !VM_Version::supports_avx512dq() && (dst->encoding() == src->encoding())) { > Assembler::vpxor(dst, dst, src, Assembler::AVX_512bit); > } else { > Assembler::xorps(dst, src); > } > } Should supports_avx512vldq() be used instead? Or does the presence of DQ mean VL is also available? > For the 2nd thing in MoveVecX2Leg, you may be right and could be an opportunity to improve. Good to know. FTR I'm fine with exploring it separately. Best regards, Vladimir Ivanov > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Monday, October 7, 2019 10:18 AM > To: Deshpande, Vivek R ; 'hotspot-compiler-dev at openjdk.java.net' > Cc: 'Robert Strout' ; 'Scott Oaks' > Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors > > Vivek, > > Thinking more about it, I got a question: > > src/hotspot/cpu/x86/x86.ad: > > instruct Repl4F_zero(vecX dst, immF0 zero) %{ > - predicate(n->as_Vector()->length() == 4 && UseAVX < 3); > + predicate(n->as_Vector()->length() == 4); > match(Set dst (ReplicateF zero)); > format %{ "xorps $dst,$dst\t! replicate4F zero" %} > ins_encode %{ > __ xorps($dst$$XMMRegister, $dst$$XMMRegister); > %} > ins_pipe( fpu_reg_reg ); > %} > > -instruct Repl4F_zero_evex(vecX dst, immF0 zero) %{ > - predicate(n->as_Vector()->length() == 4 && UseAVX > 2); > - match(Set dst (ReplicateF zero)); > - format %{ "vpxor $dst k0,$dst,$dst\t! replicate4F zero" %} > - ins_encode %{ > - // Use vpxor in place of vxorps since EVEX has a constriant on dq > for vxorps: this is a 512-bit operation > - int vector_len = 2; > - __ vpxor($dst$$XMMRegister,$dst$$XMMRegister, $dst$$XMMRegister, > vector_len); > - %} > - ins_pipe( fpu_reg_reg ); > -%} > > Any issues with vecX when encoding xorps with dst in higher half > (xmm16-31) without avx512vl support? Should it be turned to legVecX? > > > > Also: > > // Load vectors (16 bytes long) > instruct MoveVecX2Leg(legVecX dst, vecX src) %{ > match(Set dst src); > format %{ "movdqu $dst,$src\t! load vector (16 bytes)" %} > ins_encode %{ > if (UseAVX > 2 && !VM_Version::supports_avx512vl()) { > int vector_len = 2; > __ evmovdquq($dst$$XMMRegister, $src$$XMMRegister, vector_len); > } else { > __ movdqu($dst$$XMMRegister, $src$$XMMRegister); > } > %} > ins_pipe( fpu_reg_reg ); > %} > > From performance perspective, does it make any sense to further limit > EVEX-encoded case when src is in lower half of the range (0-15)? > > > Best regards, > Vladimir Ivanov > > On 07/10/2019 14:03, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.01/ >> >> Looks good. >> >> Best regards, >> Vladimir Ivanov >> >>> -----Original Message----- >>> From: Deshpande, Vivek R >>> Sent: Thursday, September 26, 2019 10:52 AM >>> To: Vladimir Kozlov ; >>> hotspot-compiler-dev at openjdk.java.net >>> Cc: Scott Oaks ; eric.caspole >>> ; Robert Strout >>> Subject: RE: RFR: 8221092: UseAVX=3 has performance degredation on >>> Skylake (X7) processors >>> >>> Thanks you Vladimir for the review. >>> I will work on the adding the comments and changes to the bug report. >>> >>> Yes the threshold is for architectures after skylake which support >>> AVX512. >>> With this threshold( value = 4096 bytes found experimentally), AVX512 >>> will be used if the array size is bigger than that. >>> >>> Regards, >>> Vivek >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, September 25, 2019 12:41 PM >>> To: Deshpande, Vivek R ; >>> hotspot-compiler-dev at openjdk.java.net >>> Cc: Scott Oaks ; eric.caspole >>> ; Robert Strout >>> Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on >>> Skylake (X7) processors >>> >>> Thank you, Vivek >>> >>> I see you did several changes including intrinsics code. Would be nice >>> if you list changes you did in bug report. I see you removed _evex >>> instructions variants in .ad file, replaced evex instructions in stubs >>> and set UseAVX to 2 for Skylake. It is easy to understand. >>> >>> But what about array limit AVX3Threshold? I assume it is for >>> non-Skylake CPUs with AVX512. Right? >>> What number 4096 is based on. It seems AVX3Threshold == 0 has special >>> meaning - add line in globals_x86.hpp explaining it. I would need more >>> time to look on related changes. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/3/19 5:02 PM, Deshpande, Vivek R wrote: >>>> Hi All >>>> >>>> I have created a patch which sets AVX2 for Skylake and selectively >>>> uses EVEX instructions based on threshold for platforms after Skylake. >>>> I don't observe the regressions for SPECjvm2008 on Skylake with this >>>> patch. >>>> JBS id: >>>> https://bugs.openjdk.java.net/browse/JDK-8221092 >>>> Webrev: >>>> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.00/ >>>> Could you all please review the patch. >>>> >>>> Regards, >>>> Vivek >>>> From sandhya.viswanathan at intel.com Tue Oct 8 18:28:55 2019 From: sandhya.viswanathan at intel.com (Viswanathan, Sandhya) Date: Tue, 8 Oct 2019 18:28:55 +0000 Subject: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors In-Reply-To: <918e6bcc-1f96-ee57-2ec9-a4e58446ded0@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB731EE6@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> <7f41aab7-4c53-6254-3518-49691d527a6a@oracle.com> <6dd7c943-c79e-c384-c94e-c3ad16f8c7a5@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7CDA58@fmsmsx121.amr.corp.intel.com> <918e6bcc-1f96-ee57-2ec9-a4e58446ded0@oracle.com> Message-ID: Hi Vladimir, The declaration of vecX operand type takes care of including upper bank appropriately only on architectures that support vl, bw and dq: reg_class_dynamic vectorx_reg(vectorx_reg_evex, vectorx_reg_legacy, %{ VM_Version::supports_evex() %} ); reg_class_dynamic vectorx_reg_vlbwdq(vectorx_reg_evex, vectorx_reg_legacy, %{ VM_Version::supports_avx512vlbwdq() %} ); operand vecX() %{ constraint(ALLOC_IN_RC(vectorx_reg_vlbwdq)); match(VecX); format %{ %} interface(REG_INTER); %} Best Regards, Sandhya -----Original Message----- From: Vladimir Ivanov Sent: Tuesday, October 08, 2019 11:10 AM To: Deshpande, Vivek R ; 'hotspot-compiler-dev at openjdk.java.net' Cc: 'Robert Strout' ; 'Scott Oaks' ; Viswanathan, Sandhya Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors Thanks for the clarifications, Vivek. > VecX has higher bank of registers when there is support for avx512vl avx512bw and avx512dq. > The VecX works for Repl4F_zero as the xorps calls vpxor when avx512vl bw dq are not available. > > This is the snippet from macroAssembler which is used here: > void MacroAssembler::xorps(XMMRegister dst, XMMRegister src) { > if (UseAVX > 2 && !VM_Version::supports_avx512dq() && (dst->encoding() == src->encoding())) { > Assembler::vpxor(dst, dst, src, Assembler::AVX_512bit); > } else { > Assembler::xorps(dst, src); > } > } Should supports_avx512vldq() be used instead? Or does the presence of DQ mean VL is also available? > For the 2nd thing in MoveVecX2Leg, you may be right and could be an opportunity to improve. Good to know. FTR I'm fine with exploring it separately. Best regards, Vladimir Ivanov > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Monday, October 7, 2019 10:18 AM > To: Deshpande, Vivek R ; > 'hotspot-compiler-dev at openjdk.java.net' > > Cc: 'Robert Strout' ; 'Scott Oaks' > > Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on > Skylake (X7) processors > > Vivek, > > Thinking more about it, I got a question: > > src/hotspot/cpu/x86/x86.ad: > > instruct Repl4F_zero(vecX dst, immF0 zero) %{ > - predicate(n->as_Vector()->length() == 4 && UseAVX < 3); > + predicate(n->as_Vector()->length() == 4); > match(Set dst (ReplicateF zero)); > format %{ "xorps $dst,$dst\t! replicate4F zero" %} > ins_encode %{ > __ xorps($dst$$XMMRegister, $dst$$XMMRegister); > %} > ins_pipe( fpu_reg_reg ); > %} > > -instruct Repl4F_zero_evex(vecX dst, immF0 zero) %{ > - predicate(n->as_Vector()->length() == 4 && UseAVX > 2); > - match(Set dst (ReplicateF zero)); > - format %{ "vpxor $dst k0,$dst,$dst\t! replicate4F zero" %} > - ins_encode %{ > - // Use vpxor in place of vxorps since EVEX has a constriant on dq > for vxorps: this is a 512-bit operation > - int vector_len = 2; > - __ vpxor($dst$$XMMRegister,$dst$$XMMRegister, $dst$$XMMRegister, > vector_len); > - %} > - ins_pipe( fpu_reg_reg ); > -%} > > Any issues with vecX when encoding xorps with dst in higher half > (xmm16-31) without avx512vl support? Should it be turned to legVecX? > > > > Also: > > // Load vectors (16 bytes long) > instruct MoveVecX2Leg(legVecX dst, vecX src) %{ > match(Set dst src); > format %{ "movdqu $dst,$src\t! load vector (16 bytes)" %} > ins_encode %{ > if (UseAVX > 2 && !VM_Version::supports_avx512vl()) { > int vector_len = 2; > __ evmovdquq($dst$$XMMRegister, $src$$XMMRegister, vector_len); > } else { > __ movdqu($dst$$XMMRegister, $src$$XMMRegister); > } > %} > ins_pipe( fpu_reg_reg ); > %} > > From performance perspective, does it make any sense to further > limit EVEX-encoded case when src is in lower half of the range (0-15)? > > > Best regards, > Vladimir Ivanov > > On 07/10/2019 14:03, Vladimir Ivanov wrote: >> >>> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.01/ >> >> Looks good. >> >> Best regards, >> Vladimir Ivanov >> >>> -----Original Message----- >>> From: Deshpande, Vivek R >>> Sent: Thursday, September 26, 2019 10:52 AM >>> To: Vladimir Kozlov ; >>> hotspot-compiler-dev at openjdk.java.net >>> Cc: Scott Oaks ; eric.caspole >>> ; Robert Strout >>> Subject: RE: RFR: 8221092: UseAVX=3 has performance degredation on >>> Skylake (X7) processors >>> >>> Thanks you Vladimir for the review. >>> I will work on the adding the comments and changes to the bug report. >>> >>> Yes the threshold is for architectures after skylake which support >>> AVX512. >>> With this threshold( value = 4096 bytes found experimentally), >>> AVX512 will be used if the array size is bigger than that. >>> >>> Regards, >>> Vivek >>> >>> -----Original Message----- >>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>> Sent: Wednesday, September 25, 2019 12:41 PM >>> To: Deshpande, Vivek R ; >>> hotspot-compiler-dev at openjdk.java.net >>> Cc: Scott Oaks ; eric.caspole >>> ; Robert Strout >>> Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on >>> Skylake (X7) processors >>> >>> Thank you, Vivek >>> >>> I see you did several changes including intrinsics code. Would be >>> nice if you list changes you did in bug report. I see you removed >>> _evex instructions variants in .ad file, replaced evex instructions >>> in stubs and set UseAVX to 2 for Skylake. It is easy to understand. >>> >>> But what about array limit AVX3Threshold? I assume it is for >>> non-Skylake CPUs with AVX512. Right? >>> What number 4096 is based on. It seems AVX3Threshold == 0 has >>> special meaning - add line in globals_x86.hpp explaining it. I would >>> need more time to look on related changes. >>> >>> Thanks, >>> Vladimir >>> >>> On 9/3/19 5:02 PM, Deshpande, Vivek R wrote: >>>> Hi All >>>> >>>> I have created a patch which sets AVX2 for Skylake and selectively >>>> uses EVEX instructions based on threshold for platforms after Skylake. >>>> I don't observe the regressions for SPECjvm2008 on Skylake with >>>> this patch. >>>> JBS id: >>>> https://bugs.openjdk.java.net/browse/JDK-8221092 >>>> Webrev: >>>> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.00/ >>>> Could you all please review the patch. >>>> >>>> Regards, >>>> Vivek >>>> From vladimir.x.ivanov at oracle.com Tue Oct 8 18:37:12 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 8 Oct 2019 21:37:12 +0300 Subject: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB731EE6@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C4D1A@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C84BF@fmsmsx121.amr.corp.intel.com> <7f41aab7-4c53-6254-3518-49691d527a6a@oracle.com> <6dd7c943-c79e-c384-c94e-c3ad16f8c7a5@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7CDA58@fmsmsx121.amr.corp.intel.com> <918e6bcc-1f96-ee57-2ec9-a4e58446ded0@oracle.com> Message-ID: <02b618eb-a52c-119c-298a-3b74468a6623@oracle.com> > The declaration of vecX operand type takes care of including upper bank appropriately only on architectures that support vl, bw and dq: Ah, now I got it. Thanks! Best regards, Vladimir Ivanov > > reg_class_dynamic vectorx_reg(vectorx_reg_evex, vectorx_reg_legacy, %{ VM_Version::supports_evex() %} ); > reg_class_dynamic vectorx_reg_vlbwdq(vectorx_reg_evex, vectorx_reg_legacy, %{ VM_Version::supports_avx512vlbwdq() %} ); > > operand vecX() %{ > constraint(ALLOC_IN_RC(vectorx_reg_vlbwdq)); > match(VecX); > > format %{ %} > interface(REG_INTER); > %} > > Best Regards, > Sandhya > > > > -----Original Message----- > From: Vladimir Ivanov > Sent: Tuesday, October 08, 2019 11:10 AM > To: Deshpande, Vivek R ; 'hotspot-compiler-dev at openjdk.java.net' > Cc: 'Robert Strout' ; 'Scott Oaks' ; Viswanathan, Sandhya > Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on Skylake (X7) processors > > Thanks for the clarifications, Vivek. > >> VecX has higher bank of registers when there is support for avx512vl avx512bw and avx512dq. >> The VecX works for Repl4F_zero as the xorps calls vpxor when avx512vl bw dq are not available. >> >> This is the snippet from macroAssembler which is used here: >> void MacroAssembler::xorps(XMMRegister dst, XMMRegister src) { >> if (UseAVX > 2 && !VM_Version::supports_avx512dq() && (dst->encoding() == src->encoding())) { >> Assembler::vpxor(dst, dst, src, Assembler::AVX_512bit); >> } else { >> Assembler::xorps(dst, src); >> } >> } > > Should supports_avx512vldq() be used instead? Or does the presence of DQ mean VL is also available? > >> For the 2nd thing in MoveVecX2Leg, you may be right and could be an opportunity to improve. > > Good to know. FTR I'm fine with exploring it separately. > > Best regards, > Vladimir Ivanov > >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Monday, October 7, 2019 10:18 AM >> To: Deshpande, Vivek R ; >> 'hotspot-compiler-dev at openjdk.java.net' >> >> Cc: 'Robert Strout' ; 'Scott Oaks' >> >> Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on >> Skylake (X7) processors >> >> Vivek, >> >> Thinking more about it, I got a question: >> >> src/hotspot/cpu/x86/x86.ad: >> >> instruct Repl4F_zero(vecX dst, immF0 zero) %{ >> - predicate(n->as_Vector()->length() == 4 && UseAVX < 3); >> + predicate(n->as_Vector()->length() == 4); >> match(Set dst (ReplicateF zero)); >> format %{ "xorps $dst,$dst\t! replicate4F zero" %} >> ins_encode %{ >> __ xorps($dst$$XMMRegister, $dst$$XMMRegister); >> %} >> ins_pipe( fpu_reg_reg ); >> %} >> >> -instruct Repl4F_zero_evex(vecX dst, immF0 zero) %{ >> - predicate(n->as_Vector()->length() == 4 && UseAVX > 2); >> - match(Set dst (ReplicateF zero)); >> - format %{ "vpxor $dst k0,$dst,$dst\t! replicate4F zero" %} >> - ins_encode %{ >> - // Use vpxor in place of vxorps since EVEX has a constriant on dq >> for vxorps: this is a 512-bit operation >> - int vector_len = 2; >> - __ vpxor($dst$$XMMRegister,$dst$$XMMRegister, $dst$$XMMRegister, >> vector_len); >> - %} >> - ins_pipe( fpu_reg_reg ); >> -%} >> >> Any issues with vecX when encoding xorps with dst in higher half >> (xmm16-31) without avx512vl support? Should it be turned to legVecX? >> >> >> >> Also: >> >> // Load vectors (16 bytes long) >> instruct MoveVecX2Leg(legVecX dst, vecX src) %{ >> match(Set dst src); >> format %{ "movdqu $dst,$src\t! load vector (16 bytes)" %} >> ins_encode %{ >> if (UseAVX > 2 && !VM_Version::supports_avx512vl()) { >> int vector_len = 2; >> __ evmovdquq($dst$$XMMRegister, $src$$XMMRegister, vector_len); >> } else { >> __ movdqu($dst$$XMMRegister, $src$$XMMRegister); >> } >> %} >> ins_pipe( fpu_reg_reg ); >> %} >> >> From performance perspective, does it make any sense to further >> limit EVEX-encoded case when src is in lower half of the range (0-15)? >> >> >> Best regards, >> Vladimir Ivanov >> >> On 07/10/2019 14:03, Vladimir Ivanov wrote: >>> >>>> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.01/ >>> >>> Looks good. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>>> -----Original Message----- >>>> From: Deshpande, Vivek R >>>> Sent: Thursday, September 26, 2019 10:52 AM >>>> To: Vladimir Kozlov ; >>>> hotspot-compiler-dev at openjdk.java.net >>>> Cc: Scott Oaks ; eric.caspole >>>> ; Robert Strout >>>> Subject: RE: RFR: 8221092: UseAVX=3 has performance degredation on >>>> Skylake (X7) processors >>>> >>>> Thanks you Vladimir for the review. >>>> I will work on the adding the comments and changes to the bug report. >>>> >>>> Yes the threshold is for architectures after skylake which support >>>> AVX512. >>>> With this threshold( value = 4096 bytes found experimentally), >>>> AVX512 will be used if the array size is bigger than that. >>>> >>>> Regards, >>>> Vivek >>>> >>>> -----Original Message----- >>>> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >>>> Sent: Wednesday, September 25, 2019 12:41 PM >>>> To: Deshpande, Vivek R ; >>>> hotspot-compiler-dev at openjdk.java.net >>>> Cc: Scott Oaks ; eric.caspole >>>> ; Robert Strout >>>> Subject: Re: RFR: 8221092: UseAVX=3 has performance degredation on >>>> Skylake (X7) processors >>>> >>>> Thank you, Vivek >>>> >>>> I see you did several changes including intrinsics code. Would be >>>> nice if you list changes you did in bug report. I see you removed >>>> _evex instructions variants in .ad file, replaced evex instructions >>>> in stubs and set UseAVX to 2 for Skylake. It is easy to understand. >>>> >>>> But what about array limit AVX3Threshold? I assume it is for >>>> non-Skylake CPUs with AVX512. Right? >>>> What number 4096 is based on. It seems AVX3Threshold == 0 has >>>> special meaning - add line in globals_x86.hpp explaining it. I would >>>> need more time to look on related changes. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 9/3/19 5:02 PM, Deshpande, Vivek R wrote: >>>>> Hi All >>>>> >>>>> I have created a patch which sets AVX2 for Skylake and selectively >>>>> uses EVEX instructions based on threshold for platforms after Skylake. >>>>> I don't observe the regressions for SPECjvm2008 on Skylake with >>>>> this patch. >>>>> JBS id: >>>>> https://bugs.openjdk.java.net/browse/JDK-8221092 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~vdeshpande/8221092/webrev.00/ >>>>> Could you all please review the patch. >>>>> >>>>> Regards, >>>>> Vivek >>>>> From ekaterina.pavlova at oracle.com Tue Oct 8 19:04:59 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 8 Oct 2019 12:04:59 -0700 Subject: RFR(T/S) 8231903: [Graal] Update com.oracle.mxtool.junit classes In-Reply-To: <7770495a-c1bd-c248-217f-fc307ff2c3f9@oracle.com> References: <7770495a-c1bd-c248-217f-fc307ff2c3f9@oracle.com> Message-ID: <4e80c9a4-3256-baa8-bfea-63608cc38325@oracle.com> Hi, can somebody pls have a look? This is quite straightforward change. thanks, -katya On 10/4/19 1:58 PM, Ekaterina Pavlova wrote: > Hi, > > please review the following change which syncs com.oracle.mxtool.junit classes with ones from graal ws. > Also > - removed org.graalvm.compiler.core.test.CheckGraalInvariants from test/hotspot/jtreg/ProblemList-graal.txt > ? as the test doesn't fail anymore > > - updated test/hotspot/jtreg/compiler/graalunit/TestPackages.txt to match latest list of test packages > > > ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8231903 > ? webrev: http://cr.openjdk.java.net/~epavlova//8231903/webrev.00/index.html > ?testing: graal unit tests > > thanks, > -katya > From tom.rodriguez at oracle.com Tue Oct 8 19:42:29 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Oct 2019 12:42:29 -0700 Subject: RFR(S) 8231586: enlarge encoding space for OopMapValue offsets In-Reply-To: <43425f68-cb1d-9569-5ea8-e337b28b879b@oracle.com> References: <92e6a5a2-c806-843d-a8e0-84f0aa3718b7@oracle.com> <6fa4389f-81f2-7591-de61-9edc60a18187@oracle.com> <5ff481d6-f440-90d6-6f04-3576879afbf5@oracle.com> <43425f68-cb1d-9569-5ea8-e337b28b879b@oracle.com> Message-ID: <7f2ceaf2-79bf-cd04-d303-081b7c8797ae@oracle.com> dean.long at oracle.com wrote on 10/7/19 10:43 PM: > Looks good.? The only thing I noticed is that while you moved the > asserts into the OopMapValue ctor, the read_from method still bypasses > those asserts.? Would it make sense to move those asserts into > set_content_reg()? Yes. I've moved them and the new webrev is http://cr.openjdk.java.net/~never/8231586.2/webrev. I've submitted a new mach5 job. tom > > dl > > On 10/7/19 10:11 AM, Tom Rodriguez wrote: >> >> >> dean.long at oracle.com wrote on 10/5/19 9:25 PM: >>> You're right, my mistake.? Your change looks good.? I was actually >>> looking at the set_* methods in OopMapValue, not OopMap, and >>> incorrectly thought the | would preserve the previous value.? On >>> closer inspection, it doesn't, and those methods don't even get >>> called, because the ctor uses a different set method.? Can we remove >>> these unused methods? >> >> Good idea.? I've deleted those along with some other dead methods and >> rearranged the code a little bit to hide more of the API so it's >> clearer what might be done to an OopMapValue.? The delta webrev is >> just my changes and the .1 webrev is the full new webrev.? I'm >> submitting a mach5 run now. >> >> http://cr.openjdk.java.net/~never/8231586-delta/webrev/ >> http://cr.openjdk.java.net/~never/8231586.1/webrev/ >> >> tom >> >>> >>> ???? void set_oop()????????????? { set_value((value() & >>> register_mask_in_place) | oop_value); } >>> ???? void set_narrowoop()????????? { set_value((value() & >>> register_mask_in_place) | narrowoop_value); } >>> ???? void set_callee_saved()???? { set_value((value() & >>> register_mask_in_place) | callee_saved_value); } >>> ???? void set_derived_oop()????? { set_value((value() & >>> register_mask_in_place) | derived_oop_value); } >>> >>> dl >>> >>> On 10/5/19 10:41 AM, Tom Rodriguez wrote: >>>> >>>> >>>> dean.long at oracle.com wrote on 10/4/19 4:27 PM: >>>>> It's not obvious that we only set 1 bit. The set methods don't >>>>> enforce that.? And this code looks like it is setting both >>>>> "derived" and "oop": >>>> >>>> Each of those calls produce independent OopMapValues. >>>> http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/compiler/oopMap.cpp#l137 >>>> ?Also all tests against the type are equality tests, not bitmasks, >>>> so if more than one bit was set it would fail to match anything. The >>>> bitmask-ness of the values is only used for filtering the iteration. >>>> >>>> tom >>>> >>>>> >>>>> http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/opto/buildOopMap.cpp#l315 >>>>> >>>>> >>>>> dl >>>>> >>>>> On 10/4/19 10:26 AM, Tom Rodriguez wrote: >>>>>> http://cr.openjdk.java.net/~never/8231586/webrev >>>>>> https://bugs.openjdk.java.net/browse/JDK-8231586 >>>>>> >>>>>> The current OopMapValue encoding uses a bit mask for each value >>>>>> even though only one bit is ever set.? Since only 16 bits are >>>>>> available for encoding this limits the offsets it can express. >>>>>> Compilation with a large number of stack slots can bailout because >>>>>> of this limit.? This changes the encoding to use 2 bits which >>>>>> gives 2 bits back to the offset. >>>>>> >>>>>> I also deleted some StressDerivedPointers machinery that's been >>>>>> completely unimplemented for years (decades?).? The flag itself is >>>>>> now dead but I wasn't sure if there are test references to it >>>>>> somewhere. Should I delete the flag as well? >>>>>> >>>>>> mach5 testing is in progress. >>>>>> >>>>>> tom >>>>> >>> > From tom.rodriguez at oracle.com Tue Oct 8 19:43:12 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 8 Oct 2019 12:43:12 -0700 Subject: RFR: 8231659: [JVMCI] Could not work PrintAssembly for JVMCI installed code In-Reply-To: References: <8ee7143a-15cb-5761-528c-c5fa687d89f3@gmail.com> <501e7e05-3334-62f9-c765-ea2c35326d32@oracle.com> Message-ID: <0a06fa4e-18a4-850f-6793-1b13e8e329af@oracle.com> Here's a webrev for my version http://cr.openjdk.java.net/~never/8231659/webrev. I'll take our discussion for review approval. tom Yasumasa Suenaga wrote on 10/4/19 5:40 PM: > Hi Tom, > > I agree with you. > Your change looks good. > > Can you push it? or may I create changeset for this? > > > Thanks, > > Yasumasa > > > On 2019/10/05 4:23, Tom Rodriguez wrote: >> >> >> Yasumasa Suenaga wrote on 10/1/19 1:57 AM: >>> Hi all, >>> >>> Please review this change. >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8231659 >>> ?? webrev: https://cr.openjdk.java.net/~ysuenaga/JDK-8231659/webrev.00/ >>> >>> PrintAssembly would work in twice for JVMCI installed code before, so >>> I fixed it in JDK-8180601. >>> However PrintAseembly would not work for them in JDK 13 or later. It >>> seems due to JDK-8220623. >>> >>> JDK-8220623 lacks print_nmethod() call. Thus I revert JDK-8180601 to >>> work PrintAssembly. >> >> I'd noticed this but forgot to go back and investigate.? I think it >> would be nicer to make that code look like the code that was >> accidentally removed from JVMCIEnv.cpp: >> >> diff -r 647e896479ff src/hotspot/share/jvmci/jvmciCodeInstaller.cpp >> --- a/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp >> +++ b/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp >> @@ -642,11 +642,9 @@ >> ????????????????????????????????????????? failed_speculations, >> speculations, speculations_len); >> ????? cb = nm->as_codeblob_or_null(); >> ????? if (nm != NULL && compile_state == NULL) { >> +????? // This compile didn't come through the CompileBroker so >> perform the printing here >> ??????? DirectiveSet* directive = >> DirectivesStack::getMatchingDirective(method, compiler); >> -????? bool printnmethods = directive->PrintAssemblyOption || >> directive->PrintNMethodsOption; >> -????? if (!printnmethods && (PrintDebugInfo || PrintRelocations || >> PrintDependencies || PrintExceptionHandlers)) { >> -??????? nm->print_nmethod(printnmethods); >> -????? } >> +????? nm->maybe_print_nmethod(directive); >> ??????? DirectivesStack::release(directive); >> ????? } >> ??? } >> >> No point in duplicating that logic. >> >> tom From vladimir.kozlov at oracle.com Tue Oct 8 21:40:21 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 8 Oct 2019 14:40:21 -0700 Subject: RFR(T/S) 8231903: [Graal] Update com.oracle.mxtool.junit classes In-Reply-To: <4e80c9a4-3256-baa8-bfea-63608cc38325@oracle.com> References: <7770495a-c1bd-c248-217f-fc307ff2c3f9@oracle.com> <4e80c9a4-3256-baa8-bfea-63608cc38325@oracle.com> Message-ID: <4e1e3459-6f0d-b7a8-313d-af5c02b0a0d0@oracle.com> Looks good. Thanks, Vladimir On 10/8/19 12:04 PM, Ekaterina Pavlova wrote: > Hi, > > can somebody pls have a look? This is quite straightforward change. > > thanks, > -katya > > On 10/4/19 1:58 PM, Ekaterina Pavlova wrote: >> Hi, >> >> please review the following change which syncs com.oracle.mxtool.junit classes with ones from graal ws. >> Also >> - removed org.graalvm.compiler.core.test.CheckGraalInvariants from test/hotspot/jtreg/ProblemList-graal.txt >> ?? as the test doesn't fail anymore >> >> - updated test/hotspot/jtreg/compiler/graalunit/TestPackages.txt to match latest list of test packages >> >> >> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8231903 >> ?? webrev: http://cr.openjdk.java.net/~epavlova//8231903/webrev.00/index.html >> ??testing: graal unit tests >> >> thanks, >> -katya >> > From dean.long at oracle.com Tue Oct 8 21:53:15 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 8 Oct 2019 14:53:15 -0700 Subject: RFR(S) 8231586: enlarge encoding space for OopMapValue offsets In-Reply-To: <7f2ceaf2-79bf-cd04-d303-081b7c8797ae@oracle.com> References: <92e6a5a2-c806-843d-a8e0-84f0aa3718b7@oracle.com> <6fa4389f-81f2-7591-de61-9edc60a18187@oracle.com> <5ff481d6-f440-90d6-6f04-3576879afbf5@oracle.com> <43425f68-cb1d-9569-5ea8-e337b28b879b@oracle.com> <7f2ceaf2-79bf-cd04-d303-081b7c8797ae@oracle.com> Message-ID: Looks great! dl On 10/8/19 12:42 PM, Tom Rodriguez wrote: > > > dean.long at oracle.com wrote on 10/7/19 10:43 PM: >> Looks good.? The only thing I noticed is that while you moved the >> asserts into the OopMapValue ctor, the read_from method still >> bypasses those asserts.? Would it make sense to move those asserts >> into set_content_reg()? > > Yes.? I've moved them and the new webrev is > http://cr.openjdk.java.net/~never/8231586.2/webrev.? I've submitted a > new mach5 job. > > tom > >> >> dl >> >> On 10/7/19 10:11 AM, Tom Rodriguez wrote: >>> >>> >>> dean.long at oracle.com wrote on 10/5/19 9:25 PM: >>>> You're right, my mistake.? Your change looks good.? I was actually >>>> looking at the set_* methods in OopMapValue, not OopMap, and >>>> incorrectly thought the | would preserve the previous value.? On >>>> closer inspection, it doesn't, and those methods don't even get >>>> called, because the ctor uses a different set method.? Can we >>>> remove these unused methods? >>> >>> Good idea.? I've deleted those along with some other dead methods >>> and rearranged the code a little bit to hide more of the API so it's >>> clearer what might be done to an OopMapValue. The delta webrev is >>> just my changes and the .1 webrev is the full new webrev.? I'm >>> submitting a mach5 run now. >>> >>> http://cr.openjdk.java.net/~never/8231586-delta/webrev/ >>> http://cr.openjdk.java.net/~never/8231586.1/webrev/ >>> >>> tom >>> >>>> >>>> ???? void set_oop()????????????? { set_value((value() & >>>> register_mask_in_place) | oop_value); } >>>> ???? void set_narrowoop()????????? { set_value((value() & >>>> register_mask_in_place) | narrowoop_value); } >>>> ???? void set_callee_saved()???? { set_value((value() & >>>> register_mask_in_place) | callee_saved_value); } >>>> ???? void set_derived_oop()????? { set_value((value() & >>>> register_mask_in_place) | derived_oop_value); } >>>> >>>> dl >>>> >>>> On 10/5/19 10:41 AM, Tom Rodriguez wrote: >>>>> >>>>> >>>>> dean.long at oracle.com wrote on 10/4/19 4:27 PM: >>>>>> It's not obvious that we only set 1 bit. The set methods don't >>>>>> enforce that.? And this code looks like it is setting both >>>>>> "derived" and "oop": >>>>> >>>>> Each of those calls produce independent OopMapValues. >>>>> http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/compiler/oopMap.cpp#l137 >>>>> ?Also all tests against the type are equality tests, not bitmasks, >>>>> so if more than one bit was set it would fail to match anything. >>>>> The bitmask-ness of the values is only used for filtering the >>>>> iteration. >>>>> >>>>> tom >>>>> >>>>>> >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/ff45c1bf8129/src/hotspot/share/opto/buildOopMap.cpp#l315 >>>>>> >>>>>> >>>>>> dl >>>>>> >>>>>> On 10/4/19 10:26 AM, Tom Rodriguez wrote: >>>>>>> http://cr.openjdk.java.net/~never/8231586/webrev >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231586 >>>>>>> >>>>>>> The current OopMapValue encoding uses a bit mask for each value >>>>>>> even though only one bit is ever set. Since only 16 bits are >>>>>>> available for encoding this limits the offsets it can express. >>>>>>> Compilation with a large number of stack slots can bailout >>>>>>> because of this limit.? This changes the encoding to use 2 bits >>>>>>> which gives 2 bits back to the offset. >>>>>>> >>>>>>> I also deleted some StressDerivedPointers machinery that's been >>>>>>> completely unimplemented for years (decades?).? The flag itself >>>>>>> is now dead but I wasn't sure if there are test references to it >>>>>>> somewhere. Should I delete the flag as well? >>>>>>> >>>>>>> mach5 testing is in progress. >>>>>>> >>>>>>> tom >>>>>> >>>> >> From ekaterina.pavlova at oracle.com Tue Oct 8 22:49:37 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Tue, 8 Oct 2019 15:49:37 -0700 Subject: RFR(T/S) 8231903: [Graal] Update com.oracle.mxtool.junit classes In-Reply-To: <4e1e3459-6f0d-b7a8-313d-af5c02b0a0d0@oracle.com> References: <7770495a-c1bd-c248-217f-fc307ff2c3f9@oracle.com> <4e80c9a4-3256-baa8-bfea-63608cc38325@oracle.com> <4e1e3459-6f0d-b7a8-313d-af5c02b0a0d0@oracle.com> Message-ID: thanks Vladimir! On 10/8/19 2:40 PM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/8/19 12:04 PM, Ekaterina Pavlova wrote: >> Hi, >> >> can somebody pls have a look? This is quite straightforward change. >> >> thanks, >> -katya >> >> On 10/4/19 1:58 PM, Ekaterina Pavlova wrote: >>> Hi, >>> >>> please review the following change which syncs com.oracle.mxtool.junit classes with ones from graal ws. >>> Also >>> - removed org.graalvm.compiler.core.test.CheckGraalInvariants from test/hotspot/jtreg/ProblemList-graal.txt >>> ?? as the test doesn't fail anymore >>> >>> - updated test/hotspot/jtreg/compiler/graalunit/TestPackages.txt to match latest list of test packages >>> >>> >>> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8231903 >>> ?? webrev: http://cr.openjdk.java.net/~epavlova//8231903/webrev.00/index.html >>> ??testing: graal unit tests >>> >>> thanks, >>> -katya >>> >> From yasuenag at gmail.com Tue Oct 8 22:58:35 2019 From: yasuenag at gmail.com (Yasumasa Suenaga) Date: Wed, 9 Oct 2019 07:58:35 +0900 Subject: RFR: 8231659: [JVMCI] Could not work PrintAssembly for JVMCI installed code In-Reply-To: <0a06fa4e-18a4-850f-6793-1b13e8e329af@oracle.com> References: <8ee7143a-15cb-5761-528c-c5fa687d89f3@gmail.com> <501e7e05-3334-62f9-c765-ea2c35326d32@oracle.com> <0a06fa4e-18a4-850f-6793-1b13e8e329af@oracle.com> Message-ID: Looks good! Thanks for taking it. Yasumasa 2019?10?9?(?) 4:43 Tom Rodriguez : > Here's a webrev for my version > http://cr.openjdk.java.net/~never/8231659/webrev. I'll take our > discussion for review approval. > > tom > > Yasumasa Suenaga wrote on 10/4/19 5:40 PM: > > Hi Tom, > > > > I agree with you. > > Your change looks good. > > > > Can you push it? or may I create changeset for this? > > > > > > Thanks, > > > > Yasumasa > > > > > > On 2019/10/05 4:23, Tom Rodriguez wrote: > >> > >> > >> Yasumasa Suenaga wrote on 10/1/19 1:57 AM: > >>> Hi all, > >>> > >>> Please review this change. > >>> > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8231659 > >>> webrev: > https://cr.openjdk.java.net/~ysuenaga/JDK-8231659/webrev.00/ > >>> > >>> PrintAssembly would work in twice for JVMCI installed code before, so > >>> I fixed it in JDK-8180601. > >>> However PrintAseembly would not work for them in JDK 13 or later. It > >>> seems due to JDK-8220623. > >>> > >>> JDK-8220623 lacks print_nmethod() call. Thus I revert JDK-8180601 to > >>> work PrintAssembly. > >> > >> I'd noticed this but forgot to go back and investigate. I think it > >> would be nicer to make that code look like the code that was > >> accidentally removed from JVMCIEnv.cpp: > >> > >> diff -r 647e896479ff src/hotspot/share/jvmci/jvmciCodeInstaller.cpp > >> --- a/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp > >> +++ b/src/hotspot/share/jvmci/jvmciCodeInstaller.cpp > >> @@ -642,11 +642,9 @@ > >> failed_speculations, > >> speculations, speculations_len); > >> cb = nm->as_codeblob_or_null(); > >> if (nm != NULL && compile_state == NULL) { > >> + // This compile didn't come through the CompileBroker so > >> perform the printing here > >> DirectiveSet* directive = > >> DirectivesStack::getMatchingDirective(method, compiler); > >> - bool printnmethods = directive->PrintAssemblyOption || > >> directive->PrintNMethodsOption; > >> - if (!printnmethods && (PrintDebugInfo || PrintRelocations || > >> PrintDependencies || PrintExceptionHandlers)) { > >> - nm->print_nmethod(printnmethods); > >> - } > >> + nm->maybe_print_nmethod(directive); > >> DirectivesStack::release(directive); > >> } > >> } > >> > >> No point in duplicating that logic. > >> > >> tom > From felix.yang at huawei.com Wed Oct 9 08:35:02 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 9 Oct 2019 08:35:02 +0000 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop Message-ID: Hi, Webrev: http://cr.openjdk.java.net/~fyang/8231988/webrev.00/ Note that the Test::mainTest method was compiled by C2 for two times. The bug triggers for the second C2 compile. JTreg tested on aarch64 linux platform. Is it OK? Thanks for your help, Felix From: Yangfei (Felix) Sent: Tuesday, October 8, 2019 4:14 PM To: 'hotspot-compiler-dev at openjdk.java.net' Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop Hi, Could I have a review for this trivial C2 bugfix please? Bug: https://bugs.openjdk.java.net/browse/JDK-8231988 This bug is always reproducible with 8u, 11u, 13 and latest 14. After some investigation, we found that the cmp node in one empty loop was deleted by IdealLoopTree::do_remove_empty_loop, but it still has another user outside the empty loop. C2 call stack: #0 IdealLoopTree::do_remove_empty_loop (this=0x96b060, phase=0xffff5c3815c0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3131 #1 0x0000ffffb7077f70 in IdealLoopTree::iteration_split_impl (this=0x96b060, phase=0xffff5c3815c0, old_new=...) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3186 #2 0x0000ffffb7078590 in IdealLoopTree::iteration_split (this=0x96b060, phase=0xffff5c3815c0, old_new=...) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3336 #3 0x0000ffffb70784a8 in IdealLoopTree::iteration_split (this=0x96b130, phase=0xffff5c3815c0, old_new=...) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3320 #4 0x0000ffffb708a2c8 in PhaseIdealLoop::build_and_optimize (this=0xffff5c3815c0, mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.cpp:3088 #5 0x0000ffffb6a46e58 in PhaseIdealLoop::PhaseIdealLoop (this=0xffff5c3815c0, igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:945 #6 0x0000ffffb6a46f18 in PhaseIdealLoop::optimize (igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:1020 #7 0x0000ffffb6a3abc8 in Compile::Optimize (this=0xffff5c3847a8) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:2328 #8 0x0000ffffb6a3458c in Compile::Compile (this=0xffff5c3847a8, ci_env=0xffff5c385558, compiler=0xffff581e2110, target=0x928e20, osr_bci=-1, subsume_loads=true, do_escape_analysis=true, eliminate_boxing=true, directive=0xffff581b1e70) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:874 #9 0x0000ffffb690a508 in C2Compiler::compile_method (this=0xffff581e2110, env=0xffff5c385558, target=0x928e20, entry_bci=-1, directive=0xffff581b1e70) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/c2compiler.cpp:110 #10 0x0000ffffb6a506c8 in CompileBroker::invoke_compiler_on_method (task=0xffff5824df80) at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2115 #11 0x0000ffffb6a4f554 in CompileBroker::compiler_thread_loop () at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:1800 #12 0x0000ffffb747be0c in compiler_thread_entry (thread=0xffff581e2800, __the_thread__=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:3401 #13 0x0000ffffb7477208 in JavaThread::thread_main_inner (this=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1917 #14 0x0000ffffb747708c in JavaThread::run (this=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1900 #15 0x0000ffffb7473270 in Thread::call_run (this=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:398 #16 0x0000ffffb71e1574 in thread_native_entry (thread=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/os/linux/os_linux.cpp:792 #17 0x0000ffffb7f3edc4 in start_thread () from /lib64/libpthread.so.0 #18 0x0000ffffb7e73fd0 in thread_start () from /lib64/libc.so.6 The other use of the cmp node was created by: #0 PhaseStringOpts::getChars (this=0xffff5c383630, kit=..., arg=0xafaf88, dst_array=0xffff58021cd8, bt=T_BYTE, end=0xaef210, final_merge=0xffff58022b18, final_mem=0xffff58022bb0, merge_index=0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:1251 #1 0x0000ffffb73d72b4 in PhaseStringOpts::int_getChars (this=0xffff5c383630, kit=..., arg=0xafaf88, dst_array=0xffff58021cd8, dst_coder=0xb2d080, start=0xffff580226f8, size=0xaebdf0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:1396 #2 0x0000ffffb73d93bc in PhaseStringOpts::replace_string_concat (this=0xffff5c383630, sc=0xb1bf10) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:1932 #3 0x0000ffffb73d3cfc in PhaseStringOpts::PhaseStringOpts (this=0xffff5c383630, gvn=0xffff5c383aa8) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:667 #4 0x0000ffffb6a39798 in Compile::inline_string_calls (this=0xffff5c384528, parse_time=true) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:2026 #5 0x0000ffffb6a343d4 in Compile::Compile (this=0xffff5c384528, ci_env=0xffff5c3852d8, compiler=0xffff58002f70, target=0xb03050, osr_bci=-1, subsume_loads=true, do_escape_analysis=true, eliminate_boxing=true, directive=0xa85fb0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:834 #6 0x0000ffffb690a508 in C2Compiler::compile_method (this=0xffff58002f70, env=0xffff5c3852d8, target=0xb03050, entry_bci=-1, directive=0xa85fb0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/c2compiler.cpp:110 #7 0x0000ffffb6a506c8 in CompileBroker::invoke_compiler_on_method (task=0xffff58085340) at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2115 #8 0x0000ffffb6a4f554 in CompileBroker::compiler_thread_loop () at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:1800 #9 0x0000ffffb747be0c in compiler_thread_entry (thread=0xffff58010800, __the_thread__=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:3401 #10 0x0000ffffb7477208 in JavaThread::thread_main_inner (this=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1917 #11 0x0000ffffb747708c in JavaThread::run (this=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1900 #12 0x0000ffffb7473270 in Thread::call_run (this=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:398 #13 0x0000ffffb71e1574 in thread_native_entry (thread=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/os/linux/os_linux.cpp:792 #14 0x0000ffffb7f3edc4 in start_thread () from /lib64/libpthread.so.0 #15 0x0000ffffb7e73fd0 in thread_start () from /lib64/libc.so.6 Cmp node was deleted by: #0 PhaseIterGVN::optimize (this=0xffff5c381f28) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/phaseX.cpp:1162 #1 0x0000ffffb708a630 in PhaseIdealLoop::build_and_optimize (this=0xffff5c3812c0, mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.cpp:3163 #2 0x0000ffffb6a46e58 in PhaseIdealLoop::PhaseIdealLoop (this=0xffff5c3812c0, igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:945 #3 0x0000ffffb6a46f18 in PhaseIdealLoop::optimize (igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:1020 #4 0x0000ffffb6a3abc8 in Compile::Optimize (this=0xffff5c3844a8) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:2328 #5 0x0000ffffb6a3458c in Compile::Compile (this=0xffff5c3844a8, ci_env=0xffff5c385258, compiler=0xaaf7a0, target=0xb19630, osr_bci=-1, subsume_loads=true, do_escape_analysis=true, eliminate_boxing=true, directive=0xa85fb0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:874 #6 0x0000ffffb690a508 in C2Compiler::compile_method (this=0xaaf7a0, env=0xffff5c385258, target=0xb19630, entry_bci=-1, directive=0xa85fb0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/c2compiler.cpp:110 #7 0x0000ffffb6a506c8 in CompileBroker::invoke_compiler_on_method (task=0xffff58067330) at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2115 #8 0x0000ffffb6a4f554 in CompileBroker::compiler_thread_loop () at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:1800 #9 0x0000ffffb747be0c in compiler_thread_entry (thread=0xabd000, __the_thread__=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:3401 #10 0x0000ffffb7477208 in JavaThread::thread_main_inner (this=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1917 #11 0x0000ffffb747708c in JavaThread::run (this=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1900 #12 0x0000ffffb7473270 in Thread::call_run (this=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:398 #13 0x0000ffffb71e1574 in thread_native_entry (thread=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/os/linux/os_linux.cpp:792 #14 0x0000ffffb7f3edc4 in start_thread () from /lib64/libpthread.so.0 #15 0x0000ffffb7e73fd0 in thread_start () from /lib64/libc.so.6 Proposed patch duplicate the cmp node if it has other users: diff -r 5b5de2618756 src/hotspot/share/opto/loopTransform.cpp --- a/src/hotspot/share/opto/loopTransform.cpp Mon Oct 07 17:13:59 2019 -0700 +++ b/src/hotspot/share/opto/loopTransform.cpp Wed Oct 09 15:39:42 2019 +0800 @@ -3129,6 +3129,13 @@ // We also need to replace the original limit to collapse loop exit. Node* cmp = cl->loopexit()->cmp_node(); assert(cl->limit() == cmp->in(2), "sanity"); + // Duplicate cmp node if it has other users + if (cmp->outcnt() > 1) { + cmp = cmp->clone(); + cmp = phase->_igvn.register_new_node_with_optimizer(cmp); + BoolNode *bol = cl->loopexit()->in(CountedLoopEndNode::TestValue)->as_Bool(); + phase->_igvn.replace_input_of(bol, 1, cmp); // put bol on worklist + } phase->_igvn._worklist.push(cmp->in(2)); // put limit on worklist phase->_igvn.replace_input_of(cmp, 2, exact_limit); // put cmp on worklist } Patch is currently under testing. Thanks, Felix From christian.hagedorn at oracle.com Wed Oct 9 08:45:37 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 9 Oct 2019 10:45:37 +0200 Subject: [14] RFR(XS): 8231720: Some perf regressions after 8225653 Message-ID: <3792073e-8a46-4ffd-8d13-d61aba22d70c@oracle.com> Hi Please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8231720 http://cr.openjdk.java.net/~chagedorn/8231720/webrev.00/ After JDK-8225653 [1], we call MacroAssembler::stop() instead of Assembler::ud2() for a HaltNode in the x86.ad file. In the 64 bit case, it prepares the arguments for MacroAssembler::debug64() by primarily emitting move instructions for each of the 16 registers in Assembler::pusha(). This consumes more code cache space and thus has a negative impact on performance of tight loops although never executed. The impact for 32 bit should be negligible since it directly emits a single pusha instruction instead. MacroAssembler::debug64() only uses the arguments in addition to the message itself if the ShowMessageBoxOnError flag is used. The fix therefore only emits those arguments if this flag is actually set. This avoids consuming unnecessary code cache space and achieves equal performance as with using ud2() instead of stop() (verified with regressing benchmarks). Thank you! Best regards, Christian [1] https://bugs.openjdk.java.net/browse/JDK-8225653 From nils.eliasson at oracle.com Wed Oct 9 08:50:32 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Wed, 9 Oct 2019 10:50:32 +0200 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop In-Reply-To: References: Message-ID: <041e13e4-a860-0523-c01d-f7d8d40230e4@oracle.com> Hi Felix, Do you have a test case that triggers this problem? Could you add that as a jtreg test? I have run your patch through testing tier1-3 and the results look good. Regards, Nils On 2019-10-09 10:35, Yangfei (Felix) wrote: > Hi, > > Webrev: http://cr.openjdk.java.net/~fyang/8231988/webrev.00/ > > Note that the Test::mainTest method was compiled by C2 for two times. The bug triggers for the second C2 compile. > > JTreg tested on aarch64 linux platform. Is it OK? > > Thanks for your help, > Felix > > From: Yangfei (Felix) > Sent: Tuesday, October 8, 2019 4:14 PM > To: 'hotspot-compiler-dev at openjdk.java.net' > Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop > > Hi, > > > Could I have a review for this trivial C2 bugfix please? > Bug: https://bugs.openjdk.java.net/browse/JDK-8231988 > This bug is always reproducible with 8u, 11u, 13 and latest 14. > After some investigation, we found that the cmp node in one empty loop was deleted by IdealLoopTree::do_remove_empty_loop, but it still has another user outside the empty loop. > > C2 call stack: > #0 IdealLoopTree::do_remove_empty_loop (this=0x96b060, phase=0xffff5c3815c0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3131 > #1 0x0000ffffb7077f70 in IdealLoopTree::iteration_split_impl (this=0x96b060, phase=0xffff5c3815c0, old_new=...) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3186 > #2 0x0000ffffb7078590 in IdealLoopTree::iteration_split (this=0x96b060, phase=0xffff5c3815c0, old_new=...) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3336 > #3 0x0000ffffb70784a8 in IdealLoopTree::iteration_split (this=0x96b130, phase=0xffff5c3815c0, old_new=...) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopTransform.cpp:3320 > #4 0x0000ffffb708a2c8 in PhaseIdealLoop::build_and_optimize (this=0xffff5c3815c0, mode=LoopOptsDefault) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.cpp:3088 > #5 0x0000ffffb6a46e58 in PhaseIdealLoop::PhaseIdealLoop (this=0xffff5c3815c0, igvn=..., mode=LoopOptsDefault) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:945 > #6 0x0000ffffb6a46f18 in PhaseIdealLoop::optimize (igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:1020 > #7 0x0000ffffb6a3abc8 in Compile::Optimize (this=0xffff5c3847a8) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:2328 > #8 0x0000ffffb6a3458c in Compile::Compile (this=0xffff5c3847a8, ci_env=0xffff5c385558, compiler=0xffff581e2110, target=0x928e20, osr_bci=-1, > subsume_loads=true, do_escape_analysis=true, eliminate_boxing=true, directive=0xffff581b1e70) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:874 > #9 0x0000ffffb690a508 in C2Compiler::compile_method (this=0xffff581e2110, env=0xffff5c385558, target=0x928e20, entry_bci=-1, directive=0xffff581b1e70) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/c2compiler.cpp:110 > #10 0x0000ffffb6a506c8 in CompileBroker::invoke_compiler_on_method (task=0xffff5824df80) > at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2115 > #11 0x0000ffffb6a4f554 in CompileBroker::compiler_thread_loop () at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:1800 > #12 0x0000ffffb747be0c in compiler_thread_entry (thread=0xffff581e2800, __the_thread__=0xffff581e2800) > at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:3401 > #13 0x0000ffffb7477208 in JavaThread::thread_main_inner (this=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1917 > #14 0x0000ffffb747708c in JavaThread::run (this=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1900 > #15 0x0000ffffb7473270 in Thread::call_run (this=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:398 > #16 0x0000ffffb71e1574 in thread_native_entry (thread=0xffff581e2800) at /home/yangfei/openjdk-jdk/src/hotspot/os/linux/os_linux.cpp:792 > #17 0x0000ffffb7f3edc4 in start_thread () from /lib64/libpthread.so.0 > #18 0x0000ffffb7e73fd0 in thread_start () from /lib64/libc.so.6 > > The other use of the cmp node was created by: > #0 PhaseStringOpts::getChars (this=0xffff5c383630, kit=..., arg=0xafaf88, dst_array=0xffff58021cd8, bt=T_BYTE, end=0xaef210, final_merge=0xffff58022b18, > final_mem=0xffff58022bb0, merge_index=0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:1251 > #1 0x0000ffffb73d72b4 in PhaseStringOpts::int_getChars (this=0xffff5c383630, kit=..., arg=0xafaf88, dst_array=0xffff58021cd8, dst_coder=0xb2d080, > start=0xffff580226f8, size=0xaebdf0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:1396 > #2 0x0000ffffb73d93bc in PhaseStringOpts::replace_string_concat (this=0xffff5c383630, sc=0xb1bf10) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:1932 > #3 0x0000ffffb73d3cfc in PhaseStringOpts::PhaseStringOpts (this=0xffff5c383630, gvn=0xffff5c383aa8) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/stringopts.cpp:667 > #4 0x0000ffffb6a39798 in Compile::inline_string_calls (this=0xffff5c384528, parse_time=true) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:2026 > #5 0x0000ffffb6a343d4 in Compile::Compile (this=0xffff5c384528, ci_env=0xffff5c3852d8, compiler=0xffff58002f70, target=0xb03050, osr_bci=-1, > subsume_loads=true, do_escape_analysis=true, eliminate_boxing=true, directive=0xa85fb0) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:834 > #6 0x0000ffffb690a508 in C2Compiler::compile_method (this=0xffff58002f70, env=0xffff5c3852d8, target=0xb03050, entry_bci=-1, directive=0xa85fb0) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/c2compiler.cpp:110 > #7 0x0000ffffb6a506c8 in CompileBroker::invoke_compiler_on_method (task=0xffff58085340) > at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2115 > #8 0x0000ffffb6a4f554 in CompileBroker::compiler_thread_loop () at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:1800 > #9 0x0000ffffb747be0c in compiler_thread_entry (thread=0xffff58010800, __the_thread__=0xffff58010800) > at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:3401 > #10 0x0000ffffb7477208 in JavaThread::thread_main_inner (this=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1917 > #11 0x0000ffffb747708c in JavaThread::run (this=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1900 > #12 0x0000ffffb7473270 in Thread::call_run (this=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:398 > #13 0x0000ffffb71e1574 in thread_native_entry (thread=0xffff58010800) at /home/yangfei/openjdk-jdk/src/hotspot/os/linux/os_linux.cpp:792 > #14 0x0000ffffb7f3edc4 in start_thread () from /lib64/libpthread.so.0 > #15 0x0000ffffb7e73fd0 in thread_start () from /lib64/libc.so.6 > > Cmp node was deleted by: > #0 PhaseIterGVN::optimize (this=0xffff5c381f28) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/phaseX.cpp:1162 > #1 0x0000ffffb708a630 in PhaseIdealLoop::build_and_optimize (this=0xffff5c3812c0, mode=LoopOptsDefault) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.cpp:3163 > #2 0x0000ffffb6a46e58 in PhaseIdealLoop::PhaseIdealLoop (this=0xffff5c3812c0, igvn=..., mode=LoopOptsDefault) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:945 > #3 0x0000ffffb6a46f18 in PhaseIdealLoop::optimize (igvn=..., mode=LoopOptsDefault) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/loopnode.hpp:1020 > #4 0x0000ffffb6a3abc8 in Compile::Optimize (this=0xffff5c3844a8) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:2328 > #5 0x0000ffffb6a3458c in Compile::Compile (this=0xffff5c3844a8, ci_env=0xffff5c385258, compiler=0xaaf7a0, target=0xb19630, osr_bci=-1, subsume_loads=true, > do_escape_analysis=true, eliminate_boxing=true, directive=0xa85fb0) at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/compile.cpp:874 > #6 0x0000ffffb690a508 in C2Compiler::compile_method (this=0xaaf7a0, env=0xffff5c385258, target=0xb19630, entry_bci=-1, directive=0xa85fb0) > at /home/yangfei/openjdk-jdk/src/hotspot/share/opto/c2compiler.cpp:110 > #7 0x0000ffffb6a506c8 in CompileBroker::invoke_compiler_on_method (task=0xffff58067330) > at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:2115 > #8 0x0000ffffb6a4f554 in CompileBroker::compiler_thread_loop () at /home/yangfei/openjdk-jdk/src/hotspot/share/compiler/compileBroker.cpp:1800 > #9 0x0000ffffb747be0c in compiler_thread_entry (thread=0xabd000, __the_thread__=0xabd000) > at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:3401 > #10 0x0000ffffb7477208 in JavaThread::thread_main_inner (this=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1917 > #11 0x0000ffffb747708c in JavaThread::run (this=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:1900 > #12 0x0000ffffb7473270 in Thread::call_run (this=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/share/runtime/thread.cpp:398 > #13 0x0000ffffb71e1574 in thread_native_entry (thread=0xabd000) at /home/yangfei/openjdk-jdk/src/hotspot/os/linux/os_linux.cpp:792 > #14 0x0000ffffb7f3edc4 in start_thread () from /lib64/libpthread.so.0 > #15 0x0000ffffb7e73fd0 in thread_start () from /lib64/libc.so.6 > > > Proposed patch duplicate the cmp node if it has other users: > diff -r 5b5de2618756 src/hotspot/share/opto/loopTransform.cpp > --- a/src/hotspot/share/opto/loopTransform.cpp Mon Oct 07 17:13:59 2019 -0700 > +++ b/src/hotspot/share/opto/loopTransform.cpp Wed Oct 09 15:39:42 2019 +0800 > @@ -3129,6 +3129,13 @@ > // We also need to replace the original limit to collapse loop exit. > Node* cmp = cl->loopexit()->cmp_node(); > assert(cl->limit() == cmp->in(2), "sanity"); > + // Duplicate cmp node if it has other users > + if (cmp->outcnt() > 1) { > + cmp = cmp->clone(); > + cmp = phase->_igvn.register_new_node_with_optimizer(cmp); > + BoolNode *bol = cl->loopexit()->in(CountedLoopEndNode::TestValue)->as_Bool(); > + phase->_igvn.replace_input_of(bol, 1, cmp); // put bol on worklist > + } > phase->_igvn._worklist.push(cmp->in(2)); // put limit on worklist > phase->_igvn.replace_input_of(cmp, 2, exact_limit); // put cmp on worklist > } > > Patch is currently under testing. > > Thanks, > Felix From felix.yang at huawei.com Wed Oct 9 09:02:11 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 9 Oct 2019 09:02:11 +0000 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop In-Reply-To: <041e13e4-a860-0523-c01d-f7d8d40230e4@oracle.com> References: <041e13e4-a860-0523-c01d-f7d8d40230e4@oracle.com> Message-ID: Hi Nils, Thanks for performing the test. Sure, let me add one based on the reduced test case on the bugzilla. Felix > > Hi Felix, > > Do you have a test case that triggers this problem? Could you add that as a > jtreg test? > > I have run your patch through testing tier1-3 and the results look good. > > Regards, > > Nils > > On 2019-10-09 10:35, Yangfei (Felix) wrote: > > Hi, > > > > Webrev: http://cr.openjdk.java.net/~fyang/8231988/webrev.00/ > > > > Note that the Test::mainTest method was compiled by C2 for two times. > The bug triggers for the second C2 compile. > > > > JTreg tested on aarch64 linux platform. Is it OK? > > > > Thanks for your help, > > Felix From navy.xliu at gmail.com Wed Oct 9 09:12:17 2019 From: navy.xliu at gmail.com (Liu Xin) Date: Wed, 9 Oct 2019 02:12:17 -0700 Subject: RFR(S): 8165056: move JIT Compiler related files from runtime/ to compiler/ directory Message-ID: Hi, Reviewers, Could you review this webrev? https://cr.openjdk.java.net/~xliu/8165056/webrev/ JBS: https://bugs.openjdk.java.net/browse/JDK-8165056 The change is straightforward. Those 3 files below have been merged into compilationPolicy.hpp/cpp. simpleThresholdPolicy.cpp simpleThresholdPolicy.hpp simpleThresholdPolicy.inline.hpp I ran hotspot/compiler tests and it's clear. thanks, --lx From martin.doerr at sap.com Wed Oct 9 09:29:53 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 9 Oct 2019 09:29:53 +0000 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> Message-ID: Hi Vladimir and Michihiro, > ConINode::make() allocates a new node which has to be seen by GVN, so > there's a type recorded for it. Makes sense. I'd prefer RoundDoubleModeNode(Node *in1, Node *rmode): Node(0, in1, rmode) {} and case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(RoundDoubleModeNode::rmode_floor))); break; case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(RoundDoubleModeNode::rmode_rint))); break; That avoids additional includes in convertnode.hpp which can easily lead to cyclic dependencies for future changes. Best regards, Martin > -----Original Message----- > From: Vladimir Ivanov > Sent: Dienstag, 8. Oktober 2019 12:31 > To: Doerr, Martin ; Michihiro Horie > > Cc: hotspot compiler ; ppc-aix- > port-dev at openjdk.java.net > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > > > > On 08/10/2019 13:14, Doerr, Martin wrote: > > Hi Vladimir and Michihiro, > > > > I like webrev.04 more than webrev.05. > > I think it's not good to include graphKit.hpp in convertnode.hpp. This > creates a weird dependency. > > What was the reason for this change? > > webrev.04 has a bug. Quote from earlier email: > > "src/hotspot/share/opto/convertnode.hpp: > > + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, > ConINode::make(rmode)) {} > > ConINode::make() allocates a new node which has to be seen by GVN, so > there's a type recorded for it. That's why I mentioned GraphKit*. But > you can use PhaseGVN & intcon as well." > > Alternatively, Compile* can be used as well. > > Best regards, > Vladimir Ivanov > > >> -----Original Message----- > >> From: Vladimir Ivanov > >> Sent: Dienstag, 8. Oktober 2019 11:47 > >> To: Michihiro Horie > >> Cc: hotspot compiler ; Doerr, > >> Martin ; ppc-aix-port-dev at openjdk.java.net > >> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on > Power > >> > >> > >>> http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/ > >> > >> Looks good. > >> > >> (Test results are clean.) > >> > >> Best regards, > >> Vladimir Ivanov > >> > >>> > I think it would be better to use adlc?s include generator instead of > >>> > including "opto/convertnode.hpp" explicitly in the ad file. > >>> > > >>> > src/hotspot/share/adlc/main.cpp > >>> > > >>> > ??? AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > >>> > > >>> > +? AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > >>> > > >>> > ??? AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > >>> > > >>> > @Vladimir: Do you agree? Would you do it this way, too? > >>> > >>> I prefer current version. > >>> > >>> When proposing the refactoring I thought about the change in adlc as > >>> well, but when I saw the patch I noticed that putting it in AD file > >>> stresses it's a platform-specific dependency. > >>> > >>> I think that's the right way to look at it until we get a way to funnel > >>> attributes from ideal nodes to mach nodes and use them during code > >>> emission. > >>> > >>> Best regards, > >>> Vladimir Ivanov > >>> > >>> > *From:*Michihiro Horie > >>> > *Sent:* Montag, 7. Oktober 2019 17:54 > >>> > *To:* Vladimir Ivanov > >>> > *Cc:* hotspot compiler ; > >> Doerr, > >>> > Martin ; ppc-aix-port- > dev at openjdk.java.net > >>> > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>> > rint on Power > >>> > > >>> > Hi Martin, Vladimir, > >>> > Thanks a lot for your further feedback, which makes sense. > >>> > > >>> > New webrev: > http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ > >>> > > >>> > Best regards, > >>> > Michihiro > >>> > > >>> > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > >>> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > >>> > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, > Michihiro. > >>> > > >>> > From: Vladimir Ivanov >>> > > > >>> > To: Michihiro Horie >, > >>> > "Doerr, Martin" >> > > >>> > Cc: hotspot compiler >>> > >, > >>> > "ppc-aix-port-dev at openjdk.java.net > >>> > " > >>> > >>> > > > >>> > Date: 2019/10/07 22:51 > >>> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > >>> > floor, rint on Power > >>> > > >>> > ------------------------------------------------------------------------ > >>> > > >>> > > >>> > > >>> > > >>> > > >>> >> Fixed webrev is as follows. > >>> > > >>> > Thanks, Michihiro. > >>> > > >>> >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ > >>> > > >>> > src/hotspot/share/opto/convertnode.hpp: > >>> > > >>> > + ?enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > >>> > > >>> > Please, explicitly initialize the elements. Numbering is important since > >>> > it is aligned with instruction encoding on x86. > >>> > > >>> > > >>> > src/hotspot/share/opto/library_call.cpp: > >>> > > >>> > + ?case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > >>> > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); > >> break; > >>> > > >>> > Please, change RoundDoubleModeNode to accept the enum instead > and > >>> > instantiate the ConI node inside it or introduce a static factory > >>> > (::make(GraphKit*,RoundingMode)) for that purpose. > >>> > > >>> > > >>> > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > >>> > > >>> > + ?void math_round(const FloatRegister t, const FloatRegister b, int > >>> rmode); > >>> > + ?void math_round_vec(const VectorSRegister t, const > VectorSRegister > >> b, > >>> > int rmode); > >>> > > >>> > I suggest to get rid of helpers in MacroAssembler and simply move > the > >>> > code into corresponding AD instructions. > >>> > > >>> > Best regards, > >>> > Vladimir Ivanov > >>> > > >>> >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I > >>> >> suggest to put the enum in RoundDoubleModeNode > (convertn"Doerr, > >> Martin" > >>> >> ---2019/10/07 22:09:15---> I suggest to put the enum in > >>> >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction > >> selectio > >>> >> > >>> >> From: "Doerr, Martin" >>> > > >>> >> To: Vladimir Ivanov >>> >, > >>> > Michihiro Horie > >>> >> > > >>> >> Cc: hotspot compiler >>> > >, > >>> >> "ppc-aix-port-dev at openjdk.java.net > >>> > " > >>> > >>> > > > >>> >> Date: 2019/10/07 22:09 > >>> >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, > >>> >> floor, rint on Power > >>> >> > >>> >> ------------------------------------------------------------------------ > >>> >> > >>> >> > >>> >> > >>> >> ?> I suggest to put the enum in RoundDoubleModeNode > >> (convertnode.hpp) > >>> >> ?> and lift instruction selection logic from macroAssembler_ppc.cpp > >>> into > >>> >> ppc.ad. > >>> >> That sounds good. > >>> >> > >>> >> Thanks, > >>> >> Martin > >>> >> > >>> >> > >>> >> ?> -----Original Message----- > >>> >> ?> From: Vladimir Ivanov >>> > > >>> >> ?> Sent: Montag, 7. Oktober 2019 12:55 > >>> >> ?> To: Doerr, Martin >>> >; Michihiro Horie > >>> >> ?> > > >>> >> ?> Cc: hotspot compiler >>> > >; ppc-aix- > >>> >> ?> port-dev at openjdk.java.net dev at openjdk.java.net> > >>> >> ?> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>> >> rint on Power > >>> >> ?> > >>> >> ?> > I think sharedRuntime is not a good place for the C2 enum. > >>> >> ?> Agree. > >>> >> ?> > >>> >> ?> I suggest to put the enum in RoundDoubleModeNode > >> (convertnode.hpp) > >>> >> ?> and > >>> >> ?> lift instruction selection logic from macroAssembler_ppc.cpp into > >>> ppc.ad. > >>> >> ?> > >>> >> ?> Best regards, > >>> >> ?> Vladimir Ivanov > >>> >> ?> > >>> >> ?> > > >>> >> ?> > Maybe intrinsicnode.hpp would be a better pace for it. But > >>> then, the > >>> >> ?> > code in macroAssembler should be guarded by #ifdef > COMPILER2. > >>> >> ?> > > >>> >> ?> > Best regards, > >>> >> ?> > > >>> >> ?> > Martin > >>> >> ?> > > >>> >> ?> > *From:*Michihiro Horie >> > > >>> >> ?> > *Sent:* Montag, 7. Oktober 2019 09:14 > >>> >> ?> > *To:* Vladimir Ivanov >>> > > >>> >> ?> > *Cc:* hotspot compiler dev at openjdk.java.net > >>> > >; > >>> >> ?> > ppc-aix-port-dev at openjdk.java.net > >>> > ; Doerr, Martin > >>> >> ?> > > >>> >> ?> > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > >>> floor, > >>> >> ?> > rint on Power > >>> >> ?> > > >>> >> ?> > Hi Vladimir, > >>> >> ?> > > >>> >> ?> > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > >>> >> ?> > I'm wondering if the enum constants can be declared in > >>> >> ?> sharedRuntime.hpp. > >>> >> ?> > Webrev: > http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > >>> >> ?> > > >>> >> ?> > Best regards, > >>> >> ?> > Michihiro > >>> >> ?> > > >>> >> ?> > Inactive hide details for Vladimir Ivanov ---2019/10/04 > >>> 23:05:48---Hi > >>> >> ?> > Michihiro, > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > >>> Ivanov > >>> >> ?> > ---2019/10/04 23:05:48---Hi Michihiro, > >>> >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>> >> ?> > > >>> >> ?> > From: Vladimir Ivanov >>> > > ?> > > >>> > > > >>> >> ?> > To: Michihiro Horie >> >, > >>> >> ?> > ppc-aix-port-dev at openjdk.java.net > >>> > >>> >> ?> > , hotspot compiler > >>> >> ?> > >>> > > ?> > > >>> > > > >>> >> ?> > Date: 2019/10/04 23:05 > >>> >> ?> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > >>> Math.ceil, > >>> >> ?> > floor, rint on Power > >>> >> ?> > > >>> >> ?> > > >>> >> ------------------------------------------------------------------------ > >>> >> ?> > > >>> >> ?> > > >>> >> ?> > > >>> >> ?> > > >>> >> ?> > Hi Michihiro, > >>> >> ?> > > >>> >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>> >> ?> > + ?switch (rmode) { > >>> >> ?> > + ? ?case 0: // rint > >>> >> ?> > + ? ? ?frin(t, b); > >>> >> ?> > + ? ? ?break; > >>> >> ?> > + ? ?case 1: // floor > >>> >> ?> > + ? ? ?frim(t, b); > >>> >> ?> > + ? ? ?break; > >>> >> ?> > + ? ?case 2: // ceil > >>> >> ?> > + ? ? ?frip(t, b); > >>> >> ?> > + ? ? ?break; > >>> >> ?> > + ? ?default: > >>> >> ?> > + ? ? ?ShouldNotReachHere(); > >>> >> ?> > + ?} > >>> >> ?> > > >>> >> ?> > What do you think about introducing enum constants instead of > >> using > >>> >> ?> > hard-coded 0/1/2? > >>> >> ?> > > >>> >> ?> > src/hotspot/share/opto/library_call.cpp: > >>> >> ?> > > >>> >> ?> > ?? case vmIntrinsics::_ceil: ? n = new > RoundDoubleModeNode(arg, > >>> >> ?> > makecon(TypeInt::make(2))); break; > >>> >> ?> > ?? case vmIntrinsics::_floor: ?n = new > RoundDoubleModeNode(arg, > >>> >> ?> > makecon(TypeInt::make(1))); break; > >>> >> ?> > ?? case vmIntrinsics::_rint: ? n = new > RoundDoubleModeNode(arg, > >>> >> ?> > makecon(TypeInt::make(0))); break; > >>> >> ?> > > >>> >> ?> > The downside is you have to move the switch from > >> macroAssembler > >>> >> ?> because > >>> >> ?> > enum should be visible from both places. (Is there a better > >>> place for > >>> >> ?> > that than roundD_regNode::emit() in AD file?) > >>> >> ?> > > >>> >> ?> > Best regards, > >>> >> ?> > Vladimir Ivanov > >>> >> ?> > > >>> >> ?> > On 02/10/2019 07:27, Michihiro Horie wrote: > >>> >> ?> >> > >>> >> ?> >> Dear all, > >>> >> ?> >> > >>> >> ?> >> Would you please review the following change? > >>> >> ?> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > >>> >> ?> >> Webrev: > http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > >>> >> ?> >> > >>> >> ?> >> This change adds intrinsics for Math's ceil, floor, and rint for > >>> >> PPC64, on > >>> >> ?> >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > >>> >> ?> >> > >>> >> ?> >> Best regards, > >>> >> ?> >> Michihiro > >>> >> ?> >> > >>> >> ?> > > >>> >> ?> > > >>> >> ?> > > >>> >> > >>> >> > >>> >> > >>> >> > >>> > > >>> > > >>> > > >>> > >>> > >>> > >>> From per.liden at oracle.com Wed Oct 9 13:19:40 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 9 Oct 2019 15:19:40 +0200 Subject: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small Message-ID: <1e351c6d-5154-25ae-3292-828295804cf0@oracle.com> 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 From david.holmes at oracle.com Wed Oct 9 13:53:20 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 9 Oct 2019 23:53:20 +1000 Subject: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small In-Reply-To: <1e351c6d-5154-25ae-3292-828295804cf0@oracle.com> References: <1e351c6d-5154-25ae-3292-828295804cf0@oracle.com> Message-ID: <18525e83-d1f8-4109-455a-a76bee217bfe@oracle.com> Hi Per, Thanks for fixing this one. On 9/10/2019 11:19 pm, Per Liden wrote: > The newly added: > > GetOwnedMonitorInfoWithEATest.java > GetOwnedMonitorStackDepthInfoWithEATest.java > > fail when run with ZGC as they set -Xmx to 32M which is too. Bumping to > 128m. Seems okay. I can't see any specific reason the test needs to use such a small heap. Thanks, David > Bug: https://bugs.openjdk.java.net/browse/JDK-8232056 > Webrev: http://cr.openjdk.java.net/~pliden/8232056/webrev.0 > > /Per From richard.reingruber at sap.com Wed Oct 9 14:04:38 2019 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 9 Oct 2019 14:04:38 +0000 Subject: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small In-Reply-To: <1e351c6d-5154-25ae-3292-828295804cf0@oracle.com> References: <1e351c6d-5154-25ae-3292-828295804cf0@oracle.com> Message-ID: 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 at 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 From per.liden at oracle.com Wed Oct 9 18:15:49 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 9 Oct 2019 20:15:49 +0200 Subject: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small In-Reply-To: <18525e83-d1f8-4109-455a-a76bee217bfe@oracle.com> References: <1e351c6d-5154-25ae-3292-828295804cf0@oracle.com> <18525e83-d1f8-4109-455a-a76bee217bfe@oracle.com> Message-ID: <54dca03b-b6ac-2017-4f60-7dd26397a18c@oracle.com> Thanks for reviewing, David! /Per On 10/9/19 3:53 PM, David Holmes wrote: > Hi Per, > > Thanks for fixing this one. > > On 9/10/2019 11:19 pm, Per Liden wrote: >> The newly added: >> >> GetOwnedMonitorInfoWithEATest.java >> GetOwnedMonitorStackDepthInfoWithEATest.java >> >> fail when run with ZGC as they set -Xmx to 32M which is too. Bumping >> to 128m. > > Seems okay. I can't see any specific reason the test needs to use such a > small heap. > > Thanks, > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8232056 >> Webrev: http://cr.openjdk.java.net/~pliden/8232056/webrev.0 >> >> /Per From per.liden at oracle.com Wed Oct 9 18:24:20 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 9 Oct 2019 20:24:20 +0200 Subject: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small In-Reply-To: References: <1e351c6d-5154-25ae-3292-828295804cf0@oracle.com> Message-ID: <30a09a82-d2c1-3ed0-64b5-5ae6b0ed3db8@oracle.com> 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 at 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 > From vladimir.kozlov at oracle.com Wed Oct 9 18:37:48 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 9 Oct 2019 11:37:48 -0700 Subject: [14] RFR(XS): 8231720: Some perf regressions after 8225653 In-Reply-To: <3792073e-8a46-4ffd-8d13-d61aba22d70c@oracle.com> References: <3792073e-8a46-4ffd-8d13-d61aba22d70c@oracle.com> Message-ID: <13c3762f-04d2-3066-ed54-dde39f11be5a@oracle.com> Looks good. Thanks, Vladimir On 10/9/19 1:45 AM, Christian Hagedorn wrote: > Hi > > Please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8231720 > http://cr.openjdk.java.net/~chagedorn/8231720/webrev.00/ > > After JDK-8225653 [1], we call MacroAssembler::stop() instead of > Assembler::ud2() for a HaltNode in the x86.ad file. In the 64 bit case, > it prepares the arguments for MacroAssembler::debug64() by primarily > emitting move instructions for each of the 16 registers in > Assembler::pusha(). This consumes more code cache space and thus has a > negative impact on performance of tight loops although never executed. > The impact for 32 bit should be negligible since it directly emits a > single pusha instruction instead. > > MacroAssembler::debug64() only uses the arguments in addition to the > message itself if the ShowMessageBoxOnError flag is used. The fix > therefore only emits those arguments if this flag is actually set. This > avoids consuming unnecessary code cache space and achieves equal > performance as with using ud2() instead of stop() (verified with > regressing benchmarks). > > Thank you! > > Best regards, > Christian > > > [1] https://bugs.openjdk.java.net/browse/JDK-8225653 From richard.reingruber at sap.com Wed Oct 9 20:02:43 2019 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 9 Oct 2019 20:02:43 +0000 Subject: RFR: 8232056: GetOwnedMonitorInfoWithEATest.java fails with ZGC: Heap too small In-Reply-To: <30a09a82-d2c1-3ed0-64b5-5ae6b0ed3db8@oracle.com> References: <1e351c6d-5154-25ae-3292-828295804cf0@oracle.com> <30a09a82-d2c1-3ed0-64b5-5ae6b0ed3db8@oracle.com> Message-ID: > 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 at 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 at 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 > From dean.long at oracle.com Wed Oct 9 20:35:13 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 9 Oct 2019 13:35:13 -0700 Subject: RFR(XL) 8231973: Update Graal Message-ID: <757ae432-47b6-94a1-5ab3-4205ba1fc709@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8231973 http://cr.openjdk.java.net/~dlong/8231973/webrev/ This is a Graal update.? Changes since the last update (JDK-8229201) are listed in the bug description. dl From vladimir.kozlov at oracle.com Thu Oct 10 01:29:29 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 9 Oct 2019 18:29:29 -0700 Subject: RFR(XL) 8231973: Update Graal In-Reply-To: <757ae432-47b6-94a1-5ab3-4205ba1fc709@oracle.com> References: <757ae432-47b6-94a1-5ab3-4205ba1fc709@oracle.com> Message-ID: Looks good. VarHandle tests timeout because we run Graal with -XX:-TieredCompilation. Most failures are old and linked to bugs. Thanks, Vladimir On 10/9/19 1:35 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8231973 > http://cr.openjdk.java.net/~dlong/8231973/webrev/ > > This is a Graal update.? Changes since the last update (JDK-8229201) are listed in the bug description. > > dl > From igor.ignatyev at oracle.com Thu Oct 10 01:24:47 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 9 Oct 2019 18:24:47 -0700 Subject: RFR(M) [14] : 8225654 : rework vmTestbase/jit/graph In-Reply-To: <86F0F16D-4170-4548-9E3B-84AEC0C7CEB4@oracle.com> References: <3A418E88-2FBA-4253-A249-C30A6DC1C5CC@oracle.com> <86F0F16D-4170-4548-9E3B-84AEC0C7CEB4@oracle.com> Message-ID: <2F61AC46-EDFF-4A74-8CC7-95AEEBB1E565@oracle.com> anyone? the patch still applies cleanly to the current jdk/jdk. the testing has been re-run. -- Igor > On Jun 27, 2019, at 3:27 PM, Igor Ignatyev wrote: > > ping? > > -- Igor > >> On Jun 19, 2019, at 5:32 PM, Igor Ignatyev wrote: >> >> http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html >>> 2536 lines changed: 354 ins; 787 del; 1395 mod; >> >> >> Hi all, >> >> could you please review the patch which reworks vmTestbase/jit/graph to make them more readable and reliable? that includes the following changes: >> - as none of our cgt* tests used more than 1 thread, all test execution is now done in main thread; >> - use exception instead of System::exit to signal problems; >> - replaced ExecDriver execution mode w/ regular 'main'; >> - make the tests to use reproducible random from jdk.test.lib.Utils ; >> - close filereader opened by jit/graph/Globals ; >> - moved tests to one directory; >> - mark a test as skipped if OOME or SOE happens >> - editorial changes such as adding { }, fixing typos, removing commented code, etc. >> >> webrev: http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html >> JBS: https://bugs.openjdk.java.net/browse/JDK-8225654 >> testing: test/hotspot/jtreg/vmTestbase/jit/graph on linux-x64,windows-x64,macosx-x64,solaris-sparcv9 >> >> Thanks, >> -- Igor >> >> > From dean.long at oracle.com Thu Oct 10 01:35:15 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 9 Oct 2019 18:35:15 -0700 Subject: RFR(XL) 8231973: Update Graal In-Reply-To: References: <757ae432-47b6-94a1-5ab3-4205ba1fc709@oracle.com> Message-ID: Thanks Vladimir. dl On 10/9/19 6:29 PM, Vladimir Kozlov wrote: > Looks good. > > VarHandle tests timeout because we run Graal with -XX:-TieredCompilation. > Most failures are old and linked to bugs. > > Thanks, > Vladimir > > On 10/9/19 1:35 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8231973 >> http://cr.openjdk.java.net/~dlong/8231973/webrev/ >> >> This is a Graal update.? Changes since the last update (JDK-8229201) >> are listed in the bug description. >> >> dl >> From felix.yang at huawei.com Thu Oct 10 02:13:01 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 10 Oct 2019 02:13:01 +0000 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop References: <041e13e4-a860-0523-c01d-f7d8d40230e4@oracle.com> Message-ID: Hmm... Looks like the reduced test case on the bugzilla is not suitable for us. It needs to be compiled by a 8u javac in order to triggers this problem. The bug will not trigger if we compile the test case by 11u javac or higher versions. I don't have other test cases to trigger this bug for now. Thanks, Felix > > Hi Nils, > > Thanks for performing the test. > Sure, let me add one based on the reduced test case on the bugzilla. > > Felix > > > > > Hi Felix, > > > > Do you have a test case that triggers this problem? Could you add that > > as a jtreg test? > > > > I have run your patch through testing tier1-3 and the results look good. > > From felix.yang at huawei.com Thu Oct 10 04:55:16 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 10 Oct 2019 04:55:16 +0000 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop References: <041e13e4-a860-0523-c01d-f7d8d40230e4@oracle.com> Message-ID: Hi, After some more try, I finally came up with a test case which does not depend on 8u javac to trigger the problem. public class Test8231988 { public void mainTest() { int i = 34; for (; i > 0; i -= 11); if (i < 0) { // Test passed } else { throw new RuntimeException("Test failed"); } } public static void main(String[] args) { Test8231988 _instance = new Test8231988(); for (int i = 0; i < 50000; i++) { _instance.mainTest(); } System.out.println("Test passed."); } } $ java -version openjdk version "14-internal" 2020-03-17 OpenJDK Runtime Environment (build 14-internal+0-adhoc.yangfei.openjdk-jdk) OpenJDK 64-Bit Server VM (build 14-internal+0-adhoc.yangfei.openjdk-jdk, mixed mode, sharing) $ javac Test8231988.java $ java -Xint Test8231988 Test passed. $ java -XX:-BackgroundCompilation -XX:-TieredCompilation Test8231988 Exception in thread "main" java.lang.RuntimeException: Test failed at Test8231988.mainTest(Test8231988.java:44) at Test8231988.main(Test8231988.java:51) I am going to add this under test/hotspot/jtreg/compiler/c2 directory. Thanks, Felix > > Hmm... > Looks like the reduced test case on the bugzilla is not suitable for us. > It needs to be compiled by a 8u javac in order to triggers this problem. > The bug will not trigger if we compile the test case by 11u javac or higher > versions. > I don't have other test cases to trigger this bug for now. > > Thanks, > Felix > > > > > Hi Nils, > > > > Thanks for performing the test. > > Sure, let me add one based on the reduced test case on the bugzilla. > > > > Felix > > > > > > > > Hi Felix, > > > > > > Do you have a test case that triggers this problem? Could you add > > > that as a jtreg test? > > > > > > I have run your patch through testing tier1-3 and the results look good. > > > From tobias.hartmann at oracle.com Thu Oct 10 05:10:32 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 10 Oct 2019 07:10:32 +0200 Subject: [14] RFR(XS): 8231720: Some perf regressions after 8225653 In-Reply-To: <13c3762f-04d2-3066-ed54-dde39f11be5a@oracle.com> References: <3792073e-8a46-4ffd-8d13-d61aba22d70c@oracle.com> <13c3762f-04d2-3066-ed54-dde39f11be5a@oracle.com> Message-ID: <27fa9daf-23af-9966-3513-7886f5cf7b47@oracle.com> +1 Best regards, Tobias On 09.10.19 20:37, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 10/9/19 1:45 AM, Christian Hagedorn wrote: >> Hi >> >> Please review the following patch: >> https://bugs.openjdk.java.net/browse/JDK-8231720 >> http://cr.openjdk.java.net/~chagedorn/8231720/webrev.00/ >> >> After JDK-8225653 [1], we call MacroAssembler::stop() instead of Assembler::ud2() for a HaltNode >> in the x86.ad file. In the 64 bit case, it prepares the arguments for MacroAssembler::debug64() by >> primarily emitting move instructions for each of the 16 registers in Assembler::pusha(). This >> consumes more code cache space and thus has a negative impact on performance of tight loops >> although never executed. The impact for 32 bit should be negligible since it directly emits a >> single pusha instruction instead. >> >> MacroAssembler::debug64() only uses the arguments in addition to the message itself if the >> ShowMessageBoxOnError flag is used. The fix therefore only emits those arguments if this flag is >> actually set. This avoids consuming unnecessary code cache space and achieves equal performance as >> with using ud2() instead of stop() (verified with regressing benchmarks). >> >> Thank you! >> >> Best regards, >> Christian >> >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8225653 From fujie at loongson.cn Thu Oct 10 05:39:00 2019 From: fujie at loongson.cn (Jie Fu) Date: Thu, 10 Oct 2019 13:39:00 +0800 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 Message-ID: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> Hi all, May I get reviews for this fix? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232083 Webrev: http://cr.openjdk.java.net/~jiefu/8232083/webrev.00/ Thanks a lot. Best regards, Jie From suenaga at oss.nttdata.com Thu Oct 10 05:55:42 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 10 Oct 2019 14:55:42 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 Message-ID: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> Hi all, Please review this change: JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was failed in macroAssembler_x86.hpp and diagnosticArgument.cpp . (Please see JBS for details) This change has passed tests on submit repo. Thanks, Yasumasa (ysuenaga) From david.holmes at oracle.com Thu Oct 10 06:36:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2019 16:36:12 +1000 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> Message-ID: Hi Yasumasa, On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote: > Hi all, > > Please review this change: > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ > > > I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was > failed in macroAssembler_x86.hpp and diagnosticArgument.cpp . The macroAssembler fix is fine - we need to ensure there is a NULL check for variables that are passed to %s. The strncpy fix in diagnosticArgument.cpp I'm less clear about. I don't understand what the warning is warning about. It seems to be concerned about possible truncation, but IIUC truncation is fine, in fact that's exactly why we use strncpy to ensure we don't overflow the buffer if the value we are copying is too long! Is this a case of gcc trying to be too helpful ?? I found this article: https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ which suggests that pattern we have of explicitly setting the NUL after the strncpy should be fine. I can't see anything wrong with the existing code. That said the modified code is also not incorrect. Thanks, David ----- > (Please see JBS for details) > > This change has passed tests on submit repo. > > > Thanks, > > Yasumasa (ysuenaga) From chris.plummer at oracle.com Thu Oct 10 06:39:55 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 9 Oct 2019 23:39:55 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> Message-ID: <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> I think the +1 gets rid of the warning, but it also means there is no need for the following line that sets buf[len]. Chris On 10/9/19 11:31 PM, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay. > > But I don't understand why you need this fix in > src/hotspot/share/services/diagnosticArgument.cpp ?: > char* buf = NEW_RESOURCE_ARRAY(char, len + 1); > - strncpy(buf, str, len); > + strncpy(buf, str, len + 1); > buf[len] = '\0'; > The buf[len] is set to '\0' anyway. > > Thanks, > Serguei > > > On 10/9/19 22:55, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >> >> >> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was >> failed in >> macroAssembler_x86.hpp and diagnosticArgument.cpp . >> (Please see JBS for details) >> >> This change has passed tests on submit repo. >> >> >> Thanks, >> >> Yasumasa (ysuenaga) > From chris.plummer at oracle.com Thu Oct 10 06:50:39 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 9 Oct 2019 23:50:39 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> Message-ID: On 10/9/19 11:36 PM, David Holmes wrote: > Hi Yasumasa, > > On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote: >> Hi all, >> >> Please review this change: >> >> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >> >> >> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was >> failed in macroAssembler_x86.hpp and diagnosticArgument.cpp . > > The macroAssembler fix is fine - we need to ensure there is a NULL > check for variables that are passed to %s. > > The strncpy fix in diagnosticArgument.cpp I'm less clear about. I > don't understand what the warning is warning about. It seems to be > concerned about possible truncation, but IIUC truncation is fine, in > fact that's exactly why we use strncpy to ensure we don't overflow the > buffer if the value we are copying is too long! Is this a case of gcc > trying to be too helpful ?? I found this article: > > https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ > > > which suggests that pattern we have of explicitly setting the NUL > after the strncpy should be fine. I can't see anything wrong with the > existing code. That said the modified code is also not incorrect. From JBS: ?/home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] ? 154 | strncpy(buf, str, len); ????? | ~~~~~~~^~~~~~~~~~~~~~~ I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to recall another recent similar fix that was done by switching to using memcpy instead. Here's a discussion of interest, also suggesting memcpy: https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice Chris > > Thanks, > David > ----- > > >> (Please see JBS for details) >> >> This change has passed tests on submit repo. >> >> >> Thanks, >> >> Yasumasa (ysuenaga) From suenaga at oss.nttdata.com Thu Oct 10 07:01:10 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 10 Oct 2019 16:01:10 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> Message-ID: <35c2d455-cbeb-03c7-84d6-8b3496cfde4d@oss.nttdata.com> On 2019/10/10 15:50, Chris Plummer wrote: > On 10/9/19 11:36 PM, David Holmes wrote: >> Hi Yasumasa, >> >> On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>> >>> >>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was failed in macroAssembler_x86.hpp and diagnosticArgument.cpp . >> >> The macroAssembler fix is fine - we need to ensure there is a NULL check for variables that are passed to %s. >> >> The strncpy fix in diagnosticArgument.cpp I'm less clear about. I don't understand what the warning is warning about. It seems to be concerned about possible truncation, but IIUC truncation is fine, in fact that's exactly why we use strncpy to ensure we don't overflow the buffer if the value we are copying is too long! Is this a case of gcc trying to be too helpful ?? I found this article: >> >> https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ >> >> which suggests that pattern we have of explicitly setting the NUL after the strncpy should be fine. I can't see anything wrong with the existing code. That said the modified code is also not incorrect. > From JBS: > > ?/home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] > ? 154 | strncpy(buf, str, len); > ????? | ~~~~~~~^~~~~~~~~~~~~~~ > > I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to recall another recent similar fix that was done by switching to using memcpy instead. > > Here's a discussion of interest, also suggesting memcpy: > > https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice Yeah, we can alternate to use memcpy(). I will upload memcpy() version webrev if it is comfortable. Thanks, Yasumasa > Chris >> >> Thanks, >> David >> ----- >> >> >>> (Please see JBS for details) >>> >>> This change has passed tests on submit repo. >>> >>> >>> Thanks, >>> >>> Yasumasa (ysuenaga) > > From david.holmes at oracle.com Thu Oct 10 07:03:50 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2019 17:03:50 +1000 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> Message-ID: <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> On 10/10/2019 4:50 pm, Chris Plummer wrote: > On 10/9/19 11:36 PM, David Holmes wrote: >> Hi Yasumasa, >> >> On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>> >>> >>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was >>> failed in macroAssembler_x86.hpp and diagnosticArgument.cpp . >> >> The macroAssembler fix is fine - we need to ensure there is a NULL >> check for variables that are passed to %s. >> >> The strncpy fix in diagnosticArgument.cpp I'm less clear about. I >> don't understand what the warning is warning about. It seems to be >> concerned about possible truncation, but IIUC truncation is fine, in >> fact that's exactly why we use strncpy to ensure we don't overflow the >> buffer if the value we are copying is too long! Is this a case of gcc >> trying to be too helpful ?? I found this article: >> >> https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ >> >> >> which suggests that pattern we have of explicitly setting the NUL >> after the strncpy should be fine. I can't see anything wrong with the >> existing code. That said the modified code is also not incorrect. > From JBS: > > ?/home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] > ? 154 | strncpy(buf, str, len); > ????? | ~~~~~~~^~~~~~~~~~~~~~~ > > I assume this means that in all cases the "len" value is seen to be > derived from strlen, and therefore strncpy is always copying one byte > short of \0, and this is most likely not what the user wants. I seem to Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. > recall another recent similar fix that was done by switching to using > memcpy instead. > > Here's a discussion of interest, also suggesting memcpy: > > https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wstringop-truncation" solution. YMMV. Cheers, David > > Chris >> >> Thanks, >> David >> ----- >> >> >>> (Please see JBS for details) >>> >>> This change has passed tests on submit repo. >>> >>> >>> Thanks, >>> >>> Yasumasa (ysuenaga) > > From chris.plummer at oracle.com Thu Oct 10 07:11:25 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 10 Oct 2019 00:11:25 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> Message-ID: <272372f7-33d9-b359-fb77-4abe6c2413c3@oracle.com> On 10/10/19 12:03 AM, David Holmes wrote: > On 10/10/2019 4:50 pm, Chris Plummer wrote: >> On 10/9/19 11:36 PM, David Holmes wrote: >>> Hi Yasumasa, >>> >>> On 10/10/2019 3:55 pm, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>>> >>>> >>>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it >>>> was failed in macroAssembler_x86.hpp and diagnosticArgument.cpp . >>> >>> The macroAssembler fix is fine - we need to ensure there is a NULL >>> check for variables that are passed to %s. >>> >>> The strncpy fix in diagnosticArgument.cpp I'm less clear about. I >>> don't understand what the warning is warning about. It seems to be >>> concerned about possible truncation, but IIUC truncation is fine, in >>> fact that's exactly why we use strncpy to ensure we don't overflow >>> the buffer if the value we are copying is too long! Is this a case >>> of gcc trying to be too helpful ?? I found this article: >>> >>> https://developers.redhat.com/blog/2018/05/24/detecting-string-truncation-with-gcc-8/ >>> >>> >>> which suggests that pattern we have of explicitly setting the NUL >>> after the strncpy should be fine. I can't see anything wrong with >>> the existing code. That said the modified code is also not incorrect. >> ?From JBS: >> >> ??/home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >> warning: 'char* strncpy(char*, const char*, size_t)' output truncated >> before terminating nul copying as many bytes from a string as its >> length [-Wstringop-truncation] >> ?? 154 | strncpy(buf, str, len); >> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >> >> I assume this means that in all cases the "len" value is seen to be >> derived from strlen, and therefore strncpy is always copying one byte >> short of \0, and this is most likely not what the user wants. I seem to > > Yes but we then explicitly set the NULL at buf[len] which is the > expected/required pattern for this. Yes. Would be nice if gcc picked up on this and not give the warning. Chris > >> recall another recent similar fix that was done by switching to using >> memcpy instead. >> >> Here's a discussion of interest, also suggesting memcpy: >> >> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice > > > Seems to me that strncpy and memcpy are semantically equivalent here > so all this does is avoid gcc's over zealous warnings. I'm inclined to > use the: > > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wstringop-truncation" > > solution. > > YMMV. > > Cheers, > David > >> >> Chris >>> >>> Thanks, >>> David >>> ----- >>> >>> >>>> (Please see JBS for details) >>>> >>>> This change has passed tests on submit repo. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa (ysuenaga) >> >> From serguei.spitsyn at oracle.com Thu Oct 10 07:25:19 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 10 Oct 2019 00:25:19 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> Message-ID: <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> On 10/9/19 23:39, Chris Plummer wrote: > I think the +1 gets rid of the warning, but it also means there is no > need for the following line that sets buf[len]. Yes, it was my guess. Then I agree this statement must be removed: buf[len] = '\0'; Thanks, Serguei > > Chris > > On 10/9/19 11:31 PM, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay. >> >> But I don't understand why you need this fix in >> src/hotspot/share/services/diagnosticArgument.cpp ?: >> ??????? char* buf = NEW_RESOURCE_ARRAY(char, len + 1); >> - strncpy(buf, str, len); >> + strncpy(buf, str, len + 1); >> ??????? buf[len] = '\0'; >> The buf[len] is set to '\0' anyway. >> >> Thanks, >> Serguei >> >> >> On 10/9/19 22:55, Yasumasa Suenaga wrote: >>> Hi all, >>> >>> Please review this change: >>> >>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>> >>> >>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was >>> failed in >>> macroAssembler_x86.hpp and diagnosticArgument.cpp . >>> (Please see JBS for details) >>> >>> This change has passed tests on submit repo. >>> >>> >>> Thanks, >>> >>> Yasumasa (ysuenaga) >> > > From suenaga at oss.nttdata.com Thu Oct 10 07:42:47 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 10 Oct 2019 16:42:47 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> Message-ID: On 2019/10/10 16:25, serguei.spitsyn at oracle.com wrote: > On 10/9/19 23:39, Chris Plummer wrote: >> I think the +1 gets rid of the warning, but it also means there is no need for the following line that sets buf[len]. > > Yes, it was my guess. > Then I agree this statement must be removed: buf[len] = '\0'; I uploaded new webrev. It removes "buf[len] = '\0';" http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.01/ Thanks, Yasumasa > Thanks, > Serguei > > >> >> Chris >> >> On 10/9/19 11:31 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay. >>> >>> But I don't understand why you need this fix in src/hotspot/share/services/diagnosticArgument.cpp ?: >>> ??????? char* buf = NEW_RESOURCE_ARRAY(char, len + 1); >>> - strncpy(buf, str, len); >>> + strncpy(buf, str, len + 1); >>> ??????? buf[len] = '\0'; >>> The buf[len] is set to '\0' anyway. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/9/19 22:55, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>>> >>>> >>>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was failed in >>>> macroAssembler_x86.hpp and diagnosticArgument.cpp . >>>> (Please see JBS for details) >>>> >>>> This change has passed tests on submit repo. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa (ysuenaga) >>> >> >> > From david.holmes at oracle.com Thu Oct 10 07:42:59 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 10 Oct 2019 17:42:59 +1000 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> Message-ID: <548ca42e-35ac-2337-ed74-70569e9a9247@oracle.com> On 10/10/2019 5:25 pm, serguei.spitsyn at oracle.com wrote: > On 10/9/19 23:39, Chris Plummer wrote: >> I think the +1 gets rid of the warning, but it also means there is no >> need for the following line that sets buf[len]. > > Yes, it was my guess. > Then I agree this statement must be removed: buf[len] = '\0'; I don't think so! Given this description: template <> void DCmdArgument::parse_value(const char* str, size_t len, TRAPS) { // len is the length of the current token starting at str it is not evident to me that we are even dealing with a NUL-terminated str. Rather str is the start of the next token, with length len, after which may be another token and so forth. So we may be passing in: str = "token1 token2" len = 6 so we still need the explicit buf[len]='\0' David > Thanks, > Serguei > > >> >> Chris >> >> On 10/9/19 11:31 PM, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay. >>> >>> But I don't understand why you need this fix in >>> src/hotspot/share/services/diagnosticArgument.cpp ?: >>> ??????? char* buf = NEW_RESOURCE_ARRAY(char, len + 1); >>> - strncpy(buf, str, len); >>> + strncpy(buf, str, len + 1); >>> ??????? buf[len] = '\0'; >>> The buf[len] is set to '\0' anyway. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/9/19 22:55, Yasumasa Suenaga wrote: >>>> Hi all, >>>> >>>> Please review this change: >>>> >>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>>> >>>> >>>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was >>>> failed in >>>> macroAssembler_x86.hpp and diagnosticArgument.cpp . >>>> (Please see JBS for details) >>>> >>>> This change has passed tests on submit repo. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa (ysuenaga) >>> >> >> > From suenaga at oss.nttdata.com Thu Oct 10 08:07:28 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 10 Oct 2019 17:07:28 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <548ca42e-35ac-2337-ed74-70569e9a9247@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> <548ca42e-35ac-2337-ed74-70569e9a9247@oracle.com> Message-ID: <35338d1b-3f35-a2da-ba92-6964e388d201@oss.nttdata.com> On 2019/10/10 16:42, David Holmes wrote: > On 10/10/2019 5:25 pm, serguei.spitsyn at oracle.com wrote: >> On 10/9/19 23:39, Chris Plummer wrote: >>> I think the +1 gets rid of the warning, but it also means there is no need for the following line that sets buf[len]. >> >> Yes, it was my guess. >> Then I agree this statement must be removed: buf[len] = '\0'; > > I don't think so! > > Given this description: > > template <> void DCmdArgument::parse_value(const char* str, > ???????????????????????????????????????????????? size_t len, TRAPS) { > ? // len is the length of the current token starting at str > > it is not evident to me that we are even dealing with a NUL-terminated str. Rather str is the start of the next token, with length len, after which may be another token and so forth. So we may be passing in: > > str = "token1 token2" > len = 6 > > so we still need the explicit buf[len]='\0' I missed it, thanks! I think we can fix it as below. ------------- diff -r b4f2e13d20ea src/hotspot/share/services/diagnosticArgument.cpp --- a/src/hotspot/share/services/diagnosticArgument.cpp Wed Oct 09 19:38:11 2019 -0700 +++ b/src/hotspot/share/services/diagnosticArgument.cpp Thu Oct 10 17:04:09 2019 +0900 @@ -151,7 +151,7 @@ ResourceMark rm; char* buf = NEW_RESOURCE_ARRAY(char, len + 1); - strncpy(buf, str, len); memcpy(buf, str, len); buf[len] = '\0'; Exceptions::fthrow(THREAD_AND_LOCATION, vmSymbols::java_lang_IllegalArgumentException(), "Boolean parsing error in command argument '%s'. Could not parse: %s.\n", _name, buf); ------------- I will upload webrev if it is ok. Thanks, Yasumasa > David > >> Thanks, >> Serguei >> >> >>> >>> Chris >>> >>> On 10/9/19 11:31 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay. >>>> >>>> But I don't understand why you need this fix in src/hotspot/share/services/diagnosticArgument.cpp ?: >>>> ??????? char* buf = NEW_RESOURCE_ARRAY(char, len + 1); >>>> - strncpy(buf, str, len); >>>> + strncpy(buf, str, len + 1); >>>> ??????? buf[len] = '\0'; >>>> The buf[len] is set to '\0' anyway. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/9/19 22:55, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>>>> >>>>> >>>>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was failed in >>>>> macroAssembler_x86.hpp and diagnosticArgument.cpp . >>>>> (Please see JBS for details) >>>>> >>>>> This change has passed tests on submit repo. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa (ysuenaga) >>>> >>> >>> >> From suenaga at oss.nttdata.com Thu Oct 10 08:11:04 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 10 Oct 2019 17:11:04 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <336a5cc2-b450-22c4-41ba-6489df82a607@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> <548ca42e-35ac-2337-ed74-70569e9a9247@oracle.com> <336a5cc2-b450-22c4-41ba-6489df82a607@oracle.com> Message-ID: On 2019/10/10 17:06, serguei.spitsyn at oracle.com wrote: > On 10/10/19 00:42, David Holmes wrote: >> On 10/10/2019 5:25 pm, serguei.spitsyn at oracle.com wrote: >>> On 10/9/19 23:39, Chris Plummer wrote: >>>> I think the +1 gets rid of the warning, but it also means there is no need for the following line that sets buf[len]. >>> >>> Yes, it was my guess. >>> Then I agree this statement must be removed: buf[len] = '\0'; >> >> I don't think so! >> >> Given this description: >> >> template <> void DCmdArgument::parse_value(const char* str, >> ???????????????????????????????????????????????? size_t len, TRAPS) { >> ? // len is the length of the current token starting at str >> >> it is not evident to me that we are even dealing with a NUL-terminated str. Rather str is the start of the next token, with length len, after which may be another token and so forth. So we may be passing in: >> >> str = "token1 token2" >> len = 6 >> >> so we still need the explicit buf[len]='\0' > > Agreed. > Then I do not like this solution to get rid of a false positive warning with this: > strncpy(buf, str, len + 1); > > The solutions with #pragma and memcpy() look better. I saw the discussion in some OpenJDK mail list #pragma is uncomfortable because it disables to find implicit bug - but I could not find out them. So I want to fix to use memcpy() only. Yasumasa > Thanks, > Serguei > >> >> David >> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> Chris >>>> >>>> On 10/9/19 11:31 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay. >>>>> >>>>> But I don't understand why you need this fix in src/hotspot/share/services/diagnosticArgument.cpp ?: >>>>> ??????? char* buf = NEW_RESOURCE_ARRAY(char, len + 1); >>>>> - strncpy(buf, str, len); >>>>> + strncpy(buf, str, len + 1); >>>>> ??????? buf[len] = '\0'; >>>>> The buf[len] is set to '\0' anyway. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/9/19 22:55, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change: >>>>>> >>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>>>>> >>>>>> >>>>>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was failed in >>>>>> macroAssembler_x86.hpp and diagnosticArgument.cpp . >>>>>> (Please see JBS for details) >>>>>> >>>>>> This change has passed tests on submit repo. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa (ysuenaga) >>>>> >>>> >>>> >>> > From suenaga at oss.nttdata.com Thu Oct 10 08:14:11 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 10 Oct 2019 17:14:11 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> <548ca42e-35ac-2337-ed74-70569e9a9247@oracle.com> <336a5cc2-b450-22c4-41ba-6489df82a607@oracle.com> Message-ID: <5057467c-6538-cc11-b084-9de015ab52c7@oss.nttdata.com> > I saw the discussion in some OpenJDK mail list #pragma is uncomfortable > because it disables to find implicit bug - but I could not find out them. It also includes -Wno-* option in GCC. Yasumasa On 2019/10/10 17:11, Yasumasa Suenaga wrote: > On 2019/10/10 17:06, serguei.spitsyn at oracle.com wrote: >> On 10/10/19 00:42, David Holmes wrote: >>> On 10/10/2019 5:25 pm, serguei.spitsyn at oracle.com wrote: >>>> On 10/9/19 23:39, Chris Plummer wrote: >>>>> I think the +1 gets rid of the warning, but it also means there is no need for the following line that sets buf[len]. >>>> >>>> Yes, it was my guess. >>>> Then I agree this statement must be removed: buf[len] = '\0'; >>> >>> I don't think so! >>> >>> Given this description: >>> >>> template <> void DCmdArgument::parse_value(const char* str, >>> ???????????????????????????????????????????????? size_t len, TRAPS) { >>> ? // len is the length of the current token starting at str >>> >>> it is not evident to me that we are even dealing with a NUL-terminated str. Rather str is the start of the next token, with length len, after which may be another token and so forth. So we may be passing in: >>> >>> str = "token1 token2" >>> len = 6 >>> >>> so we still need the explicit buf[len]='\0' >> >> Agreed. >> Then I do not like this solution to get rid of a false positive warning with this: >> strncpy(buf, str, len + 1); >> >> The solutions with #pragma and memcpy() look better. > > I saw the discussion in some OpenJDK mail list #pragma is uncomfortable > because it disables to find implicit bug - but I could not find out them. > > So I want to fix to use memcpy() only. > > > Yasumasa > > >> Thanks, >> Serguei >> >>> >>> David >>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>>> >>>>> Chris >>>>> >>>>> On 10/9/19 11:31 PM, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay. >>>>>> >>>>>> But I don't understand why you need this fix in src/hotspot/share/services/diagnosticArgument.cpp ?: >>>>>> ??????? char* buf = NEW_RESOURCE_ARRAY(char, len + 1); >>>>>> - strncpy(buf, str, len); >>>>>> + strncpy(buf, str, len + 1); >>>>>> ??????? buf[len] = '\0'; >>>>>> The buf[len] is set to '\0' anyway. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/9/19 22:55, Yasumasa Suenaga wrote: >>>>>>> Hi all, >>>>>>> >>>>>>> Please review this change: >>>>>>> >>>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>>>>>> >>>>>>> >>>>>>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it was failed in >>>>>>> macroAssembler_x86.hpp and diagnosticArgument.cpp . >>>>>>> (Please see JBS for details) >>>>>>> >>>>>>> This change has passed tests on submit repo. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa (ysuenaga) >>>>>> >>>>> >>>>> >>>> >> From yudi.zheng at oracle.com Thu Oct 10 08:34:40 2019 From: yudi.zheng at oracle.com (Yudi Zheng) Date: Thu, 10 Oct 2019 10:34:40 +0200 Subject: RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI Message-ID: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> Hello, Please review the following small change to reserve r27 (heap base register) on AArch64 unconditionally, i.e., regardless of whether compressed oops is enabled or not. http://cr.openjdk.java.net/~yzheng/8231754/ https://bugs.openjdk.java.net/browse/JDK-8231754 Many thanks, -Yudi From nils.eliasson at oracle.com Thu Oct 10 09:05:21 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 10 Oct 2019 11:05:21 +0200 Subject: RFR(M) [14] : 8225654 : rework vmTestbase/jit/graph In-Reply-To: <2F61AC46-EDFF-4A74-8CC7-95AEEBB1E565@oracle.com> References: <3A418E88-2FBA-4253-A249-C30A6DC1C5CC@oracle.com> <86F0F16D-4170-4548-9E3B-84AEC0C7CEB4@oracle.com> <2F61AC46-EDFF-4A74-8CC7-95AEEBB1E565@oracle.com> Message-ID: <5e7bbf03-14c7-0c7d-5f69-d89da5d405a3@oracle.com> Hi, Sorry for missing your review request for so long. Don't be afraid to bump your review once in a while. You have done a great job updating the test. Reviewed, Nils You have done On 2019-10-10 03:24, Igor Ignatyev wrote: > anyone? the patch still applies cleanly to the current jdk/jdk. the testing has been re-run. > > -- Igor > >> On Jun 27, 2019, at 3:27 PM, Igor Ignatyev wrote: >> >> ping? >> >> -- Igor >> >>> On Jun 19, 2019, at 5:32 PM, Igor Ignatyev wrote: >>> >>> http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html >>>> 2536 lines changed: 354 ins; 787 del; 1395 mod; >>> >>> Hi all, >>> >>> could you please review the patch which reworks vmTestbase/jit/graph to make them more readable and reliable? that includes the following changes: >>> - as none of our cgt* tests used more than 1 thread, all test execution is now done in main thread; >>> - use exception instead of System::exit to signal problems; >>> - replaced ExecDriver execution mode w/ regular 'main'; >>> - make the tests to use reproducible random from jdk.test.lib.Utils ; >>> - close filereader opened by jit/graph/Globals ; >>> - moved tests to one directory; >>> - mark a test as skipped if OOME or SOE happens >>> - editorial changes such as adding { }, fixing typos, removing commented code, etc. >>> >>> webrev: http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8225654 >>> testing: test/hotspot/jtreg/vmTestbase/jit/graph on linux-x64,windows-x64,macosx-x64,solaris-sparcv9 >>> >>> Thanks, >>> -- Igor >>> >>> From claes.redestad at oracle.com Thu Oct 10 09:39:20 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 10 Oct 2019 11:39:20 +0200 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> Message-ID: <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> How about: -XX:CompilationMode= enum := default|tiered|quickOnly|highOnly|highOnlyQuickInternal|... quickOnly => "TieredStopAtLevel=1" highOnly => "-TieredCompilation for all" highOnlyQuickInternal => -TieredCompilation with C1 for graal" I think this makes it clearer, and also easier to extend[1]. I'm less enthused by the ability to manually pick threshold levels - that we at all expose and thus lock us to what tier levels exists feels like a mistake - and think we should move all such flag to diagnostic, be wary of adding any more and take bigger liberties with changing them as we see fit ergonomically. $.02 Thanks! /Claes [1] For example I think there might be room for a plain "quick" mode that goes something like interpreter -> L2 -> L4 with less profiling, lower thresholds (and a smaller code cache, and fewer C2/Graal threads...), which might have similar startup and footprint behavior to TieredStopAtLevel=1 but get closer to full tiered in peak performance. On 2019-10-05 00:44, Igor Veresov wrote: > >> On Oct 4, 2019, at 10:55 AM, Tom Rodriguez wrote: >> >>> I?d like to introduce a -XX:TieredMode= flag to control this. See the webrev for its description. >> > > Command line parameter naming is the hardest problem in computer science indeed. > >> I think the policy you are suggesting sounds reasonable to me, but I find the use of a bit mask to select it to be confusing. Several of the bit mask states seem invalid like TieredMode=7 seems to just be TieredMode=1 apart from inconsistent flags settings. How is TieredMode=1 different from TieredStopAtLevel=1? Isn't TieredMode=6 equivalent to the old -TieredCompilation? We've disabled level 1-3 for everyone but JVMCI and then we've disable the special level 1 for JVMCI, so isn't level 4 the only thing left? >> > > So, first thing is that I?d like to get rid of the non-tiered policy in the future, so the goal of TieredMode was to be able to select all the possible execution modes. The ability to combine 2 | 4 is intentional. Some tests want to switch C1 off entirely. The two tests in this webrev are one of those. It is also useful if you suspect that C1 is a problem and want to turn it off. TieredMode=1 for now is the same as TieredStopAtLevel=1, yes, but my intention is to make the adjustments to the policy to do it more refined. TieredStopAtLevel=1 is really a debug flag that people started using to get a C1-only mode, but it has not been tuned for that really, it just limits the compile level at the last moment before a compile request is submitted. Anyways, my intent was to make TieredMode to be a *set* of flags that adjust the policy behavior. You?re right that some bit combinations are making the policy to ignore some other bits (although all the bit combinations are valid, there is even a test that checks that). > >> Why not have some symbolic names with a clearer description of what those modes are? > > That?s a good idea, except I wan?t able to come up with the good names. I don?t want to mention C1 or C2 in the names of these flags, because it may all be different modes of Graal in the future. If we name the options now we are struck with them forever. Bits are on the other hand anonymous. > > May be 0 - default, 1 - simple, 2 - no_intermediate, 4 - no_force_simple ? > >> Do we even need/want this much flexibility exposed? Maybe -TieredCompilation defaults to the new behaviour in the presence of +UseJVMCICompiler and a new StrictTieredCompilation gives you the old behaviour. >> > > I had this in one of the revisions. I think it?s more confusing. > > -XX:-TieredCompilation - C1 only for Graal > -XX:-StrictTieredCompilation - no C1 at all. > -XX:+TieredCompilation - normal behavior > > And then there are combinations of these flags with ambiguous meanings. It becomes this ?I seriously mean no tiered this time? flag. I?m not a big fan of how it reads. > > Igor > > >> tom >> >> >>> To make the tests work out-of-the-box I check if the flags -XX:-TieredCompilation and -XX:+UseJVMCICompiler are on the command line and turn the tiered compilation back on in non-tiered emulation mode. A warning is issued to alert the user to the change. This mode is also a step towards being able to remove the non-tiered policy. >>> Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.00/ >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8227003 >>> igor > From christian.hagedorn at oracle.com Thu Oct 10 10:30:51 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Thu, 10 Oct 2019 12:30:51 +0200 Subject: [14] RFR(XS): 8231720: Some perf regressions after 8225653 In-Reply-To: <27fa9daf-23af-9966-3513-7886f5cf7b47@oracle.com> References: <3792073e-8a46-4ffd-8d13-d61aba22d70c@oracle.com> <13c3762f-04d2-3066-ed54-dde39f11be5a@oracle.com> <27fa9daf-23af-9966-3513-7886f5cf7b47@oracle.com> Message-ID: Thank you Vladimir and Tobias for your reviews! Best regards, Christian On 10.10.19 07:10, Tobias Hartmann wrote: > +1 > > Best regards, > Tobias > > On 09.10.19 20:37, Vladimir Kozlov wrote: >> Looks good. >> >> Thanks, >> Vladimir >> >> On 10/9/19 1:45 AM, Christian Hagedorn wrote: >>> Hi >>> >>> Please review the following patch: >>> https://bugs.openjdk.java.net/browse/JDK-8231720 >>> http://cr.openjdk.java.net/~chagedorn/8231720/webrev.00/ >>> >>> After JDK-8225653 [1], we call MacroAssembler::stop() instead of Assembler::ud2() for a HaltNode >>> in the x86.ad file. In the 64 bit case, it prepares the arguments for MacroAssembler::debug64() by >>> primarily emitting move instructions for each of the 16 registers in Assembler::pusha(). This >>> consumes more code cache space and thus has a negative impact on performance of tight loops >>> although never executed. The impact for 32 bit should be negligible since it directly emits a >>> single pusha instruction instead. >>> >>> MacroAssembler::debug64() only uses the arguments in addition to the message itself if the >>> ShowMessageBoxOnError flag is used. The fix therefore only emits those arguments if this flag is >>> actually set. This avoids consuming unnecessary code cache space and achieves equal performance as >>> with using ud2() instead of stop() (verified with regressing benchmarks). >>> >>> Thank you! >>> >>> Best regards, >>> Christian >>> >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8225653 From adinn at redhat.com Thu Oct 10 10:48:55 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 10 Oct 2019 11:48:55 +0100 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> Message-ID: On 10/10/2019 10:39, Claes Redestad wrote: > How about: > > -XX:CompilationMode= > > enum := default|tiered|quickOnly|highOnly|highOnlyQuickInternal|... > > quickOnly => "TieredStopAtLevel=1" > highOnly => "-TieredCompilation for all" > highOnlyQuickInternal => -TieredCompilation with C1 for graal" > > I think this makes it clearer, and also easier to extend[1]. Agreed. > I'm less enthused by the ability to manually pick threshold levels > - that we at all expose and thus lock us to what tier levels > exists feels like a mistake - and think we should move all such flag to > diagnostic, be wary of adding any more and take bigger liberties with > changing them as we see fit ergonomically. Also agreed. > $.02 Krrching! $.04! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From martin.doerr at sap.com Thu Oct 10 12:29:18 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 10 Oct 2019 12:29:18 +0000 Subject: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 instructions on processors which don't support it Message-ID: Hi, we have observed a JVM crash in JDK13u on an AMD Opteron machine. Instructions like pabsb/w/d, phaddd get emitted when SSE3 is available, but are not supported without SSSE3. E.g. AMD Opteron(tm) Processor 2218 has SSE3, but not SSSE3. Should we fix it this way? http://cr.openjdk.java.net/~mdoerr/8232106_x86_ssse3/webrev.00/ Best regards, Martin From christoph.goettschkes at microdoc.com Thu Oct 10 14:28:27 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Thu, 10 Oct 2019 16:28:27 +0200 Subject: RFR: 8231952: ARM32: Wrong assumption in assertion in LIRGenerator::atomic_xchg and LIRGenerator::atomic_add Message-ID: Hi, please review the following changeset. This patch fixes a wrong assumption in an assertion of the C1 LIR generator for 32-bit ARM. The assertion assumed that atomic operations are only possible for int types on 32-bit arm. This is not true, since the LDREXD/STREXB instructions are use by the C1 JIT. This fixes the 3 hotspot tier1 tests mentioned in the issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8231952 Webrev: https://cr.openjdk.java.net/~bulasevich/8231952/webrev.00/ Thanks, Christoph From christoph.goettschkes at microdoc.com Thu Oct 10 14:29:11 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Thu, 10 Oct 2019 16:29:11 +0200 Subject: RFR: 8231955: ARM32: Address displacement is 0 for volatile field access because of Unsafe field access. Message-ID: Hi, please review the following changeset. This patch fixes the volatile field access for 32-bit ARM. The functions LIRGenerator::volatile_field_store and LIRGenerator::volatile_field_load both assume that the displacement for the given address is always 0. Both use the given address and pass the values to add_large_constant() [1], which asserts that the given displacement is not 0. The change does not call add_large_constant if the given displacement is 0. The displacement can be 0, because of the implementation of the unsafe intrinsics. This happens, because the offset into the object from which the field is accessed is not a constant value. This fixes the hotspot tier1 tests mentioned in the issue. Bug: https://bugs.openjdk.java.net/browse/JDK-8231955 Webrev: https://cr.openjdk.java.net/~bulasevich/8231955/webrev.00/ Thanks, Christoph [1] https://hg.openjdk.java.net/jdk/jdk/file/30a9612a657d/src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp#l166 From chris.plummer at oracle.com Thu Oct 10 15:57:44 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 10 Oct 2019 08:57:44 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <548ca42e-35ac-2337-ed74-70569e9a9247@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> <548ca42e-35ac-2337-ed74-70569e9a9247@oracle.com> Message-ID: On 10/10/19 12:42 AM, David Holmes wrote: > On 10/10/2019 5:25 pm, serguei.spitsyn at oracle.com wrote: >> On 10/9/19 23:39, Chris Plummer wrote: >>> I think the +1 gets rid of the warning, but it also means there is >>> no need for the following line that sets buf[len]. >> >> Yes, it was my guess. >> Then I agree this statement must be removed: buf[len] = '\0'; > > I don't think so! > > Given this description: > > template <> void DCmdArgument::parse_value(const char* str, > ???????????????????????????????????????????????? size_t len, TRAPS) { > ? // len is the length of the current token starting at str > > it is not evident to me that we are even dealing with a NUL-terminated > str. Rather str is the start of the next token, with length len, after > which may be another token and so forth. So we may be passing in: > > str = "token1 token2" > len = 6 > > so we still need the explicit buf[len]='\0' > All calls to parse_value() are passing in strlen(str) for the len argument. That's why gcc knows to produce this warning. That also means we could safely use strcpy() instead. We use strncpy() in a bunch of other places and don't get this warning. However, the comment and the fact that len is passed in makes me think that at one point it worked as you suggested and the string was not nul terminated. As things stand now? you could just pass in str and let parse_value() do the strlen computation. But if at one point it was not nul terminated, then that would not have worked, thus len is passed in. Chris > David > >> Thanks, >> Serguei >> >> >>> >>> Chris >>> >>> On 10/9/19 11:31 PM, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay. >>>> >>>> But I don't understand why you need this fix in >>>> src/hotspot/share/services/diagnosticArgument.cpp ?: >>>> ??????? char* buf = NEW_RESOURCE_ARRAY(char, len + 1); >>>> - strncpy(buf, str, len); >>>> + strncpy(buf, str, len + 1); >>>> ??????? buf[len] = '\0'; >>>> The buf[len] is set to '\0' anyway. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/9/19 22:55, Yasumasa Suenaga wrote: >>>>> Hi all, >>>>> >>>>> Please review this change: >>>>> >>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>>>> >>>>> >>>>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it >>>>> was failed in >>>>> macroAssembler_x86.hpp and diagnosticArgument.cpp . >>>>> (Please see JBS for details) >>>>> >>>>> This change has passed tests on submit repo. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa (ysuenaga) >>>> >>> >>> >> From chris.plummer at oracle.com Thu Oct 10 15:58:23 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 10 Oct 2019 08:58:23 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <35338d1b-3f35-a2da-ba92-6964e388d201@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <5c94d1cc-d185-c36d-8002-3ef0b52c42dc@oracle.com> <3d5094e3-12f0-690f-a2b3-a3e87db91999@oracle.com> <87dca8bd-24fd-df02-f4b6-d0bd0b69bbd8@oracle.com> <548ca42e-35ac-2337-ed74-70569e9a9247@oracle.com> <35338d1b-3f35-a2da-ba92-6964e388d201@oss.nttdata.com> Message-ID: <75053e3c-86b8-3fc5-f1aa-d35b341cf881@oracle.com> On 10/10/19 1:07 AM, Yasumasa Suenaga wrote: > On 2019/10/10 16:42, David Holmes wrote: >> On 10/10/2019 5:25 pm, serguei.spitsyn at oracle.com wrote: >>> On 10/9/19 23:39, Chris Plummer wrote: >>>> I think the +1 gets rid of the warning, but it also means there is >>>> no need for the following line that sets buf[len]. >>> >>> Yes, it was my guess. >>> Then I agree this statement must be removed: buf[len] = '\0'; >> >> I don't think so! >> >> Given this description: >> >> template <> void DCmdArgument::parse_value(const char* str, >> ????????????????????????????????????????????????? size_t len, TRAPS) { >> ?? // len is the length of the current token starting at str >> >> it is not evident to me that we are even dealing with a >> NUL-terminated str. Rather str is the start of the next token, with >> length len, after which may be another token and so forth. So we may >> be passing in: >> >> str = "token1 token2" >> len = 6 >> >> so we still need the explicit buf[len]='\0' > > I missed it, thanks! > I think we can fix it as below. > > ------------- > diff -r b4f2e13d20ea src/hotspot/share/services/diagnosticArgument.cpp > --- a/src/hotspot/share/services/diagnosticArgument.cpp Wed Oct 09 > 19:38:11 2019 -0700 > +++ b/src/hotspot/share/services/diagnosticArgument.cpp Thu Oct 10 > 17:04:09 2019 +0900 > @@ -151,7 +151,7 @@ > ResourceMark rm; > > ?????? char* buf = NEW_RESOURCE_ARRAY(char, len + 1); > -????? strncpy(buf, str, len); > memcpy(buf, str, len); > buf[len] = '\0'; > ?????? Exceptions::fthrow(THREAD_AND_LOCATION, > vmSymbols::java_lang_IllegalArgumentException(), > ???????? "Boolean parsing error in command argument '%s'. Could not > parse: %s.\n", _name, buf); > ------------- > > I will upload webrev if it is ok. That looks right, although it's odd that the memcpy line does not have a + in front of it to show that it's an addition. Chris > > > Thanks, > > Yasumasa > > >> David >> >>> Thanks, >>> Serguei >>> >>> >>>> >>>> Chris >>>> >>>> On 10/9/19 11:31 PM, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> The fix in src/hotspot/cpu/x86/macroAssembler_x86.hpp looks Okay. >>>>> >>>>> But I don't understand why you need this fix in >>>>> src/hotspot/share/services/diagnosticArgument.cpp ?: >>>>> ??????? char* buf = NEW_RESOURCE_ARRAY(char, len + 1); >>>>> - strncpy(buf, str, len); >>>>> + strncpy(buf, str, len + 1); >>>>> ??????? buf[len] = '\0'; >>>>> The buf[len] is set to '\0' anyway. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/9/19 22:55, Yasumasa Suenaga wrote: >>>>>> Hi all, >>>>>> >>>>>> Please review this change: >>>>>> >>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>>> ? webrev: >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.00/ >>>>>> >>>>>> >>>>>> I tried to build OpenJDK on Fedora 30 x64 with GCC 9.2.1, but it >>>>>> was failed in >>>>>> macroAssembler_x86.hpp and diagnosticArgument.cpp . >>>>>> (Please see JBS for details) >>>>>> >>>>>> This change has passed tests on submit repo. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa (ysuenaga) >>>>> >>>> >>>> >>> From vladimir.kozlov at oracle.com Thu Oct 10 17:22:18 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 10 Oct 2019 10:22:18 -0700 Subject: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 instructions on processors which don't support it In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 10/10/19 5:29 AM, Doerr, Martin wrote: > Hi, > > we have observed a JVM crash in JDK13u on an AMD Opteron machine. > > Instructions like pabsb/w/d, phaddd get emitted when SSE3 is available, but are not supported without SSSE3. > E.g. AMD Opteron(tm) Processor 2218 has SSE3, but not SSSE3. > > Should we fix it this way? > http://cr.openjdk.java.net/~mdoerr/8232106_x86_ssse3/webrev.00/ > > Best regards, > Martin > From igor.ignatyev at oracle.com Thu Oct 10 17:45:50 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Thu, 10 Oct 2019 10:45:50 -0700 Subject: RFR(M) [14] : 8225654 : rework vmTestbase/jit/graph In-Reply-To: <5e7bbf03-14c7-0c7d-5f69-d89da5d405a3@oracle.com> References: <3A418E88-2FBA-4253-A249-C30A6DC1C5CC@oracle.com> <86F0F16D-4170-4548-9E3B-84AEC0C7CEB4@oracle.com> <2F61AC46-EDFF-4A74-8CC7-95AEEBB1E565@oracle.com> <5e7bbf03-14c7-0c7d-5f69-d89da5d405a3@oracle.com> Message-ID: <9F47BF2F-C122-40B6-9BA5-86504AA0503F@oracle.com> @Nils, I am not (and never was) afraid to bump up my reviews, it's just I myself forgot that I have this one pending, so it's on me ;) anyhow, thanks for your review. @list can I get a second review? Thanks, -- Igor > On Oct 10, 2019, at 2:05 AM, Nils Eliasson wrote: > > Hi, > > Sorry for missing your review request for so long. Don't be afraid to bump your review once in a while. > > You have done a great job updating the test. > > Reviewed, > > Nils > > > You have done > > On 2019-10-10 03:24, Igor Ignatyev wrote: >> anyone? the patch still applies cleanly to the current jdk/jdk. the testing has been re-run. >> >> -- Igor >> >>> On Jun 27, 2019, at 3:27 PM, Igor Ignatyev wrote: >>> >>> ping? >>> >>> -- Igor >>> >>>> On Jun 19, 2019, at 5:32 PM, Igor Ignatyev wrote: >>>> >>>> http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html >>>>> 2536 lines changed: 354 ins; 787 del; 1395 mod; >>>> >>>> Hi all, >>>> >>>> could you please review the patch which reworks vmTestbase/jit/graph to make them more readable and reliable? that includes the following changes: >>>> - as none of our cgt* tests used more than 1 thread, all test execution is now done in main thread; >>>> - use exception instead of System::exit to signal problems; >>>> - replaced ExecDriver execution mode w/ regular 'main'; >>>> - make the tests to use reproducible random from jdk.test.lib.Utils ; >>>> - close filereader opened by jit/graph/Globals ; >>>> - moved tests to one directory; >>>> - mark a test as skipped if OOME or SOE happens >>>> - editorial changes such as adding { }, fixing typos, removing commented code, etc. >>>> >>>> webrev: http://cr.openjdk.java.net/~iignatyev//8225654/webrev.00/index.html >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8225654 >>>> testing: test/hotspot/jtreg/vmTestbase/jit/graph on linux-x64,windows-x64,macosx-x64,solaris-sparcv9 >>>> >>>> Thanks, >>>> -- Igor >>>> >>>> From aph at redhat.com Thu Oct 10 18:57:53 2019 From: aph at redhat.com (Andrew Haley) Date: Thu, 10 Oct 2019 19:57:53 +0100 Subject: RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: <655c746e-2456-4422-5c14-d49e08864acf@oracle.com> References: <41d1807c-f4b7-2b74-11c2-e0d9fc5784ca@oracle.com> <655c746e-2456-4422-5c14-d49e08864acf@oracle.com> Message-ID: On 10/8/19 2:37 PM, Nils Eliasson wrote: > For the non-Aarch64 parts: Looks good! +int MacroAssembler::pop_fp(unsigned int bitset, Register stack) { + int words_pushed = 0; + + // Scan bitset to accumulate register pairs + unsigned char regs[32]; + int count = 0; + for (int reg = 0; reg <= 31; reg++) { + if (1 & bitset) + regs[count++] = reg; + bitset >>= 1; + } + regs[count++] = zr->encoding_nocheck(); This use of ZR looks wrong in FP code. There is no floating-point ZR. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From kim.barrett at oracle.com Thu Oct 10 20:54:40 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Oct 2019 16:54:40 -0400 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> Message-ID: <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> > On Oct 10, 2019, at 3:03 AM, David Holmes wrote: > > On 10/10/2019 4:50 pm, Chris Plummer wrote: >> From JBS: >> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >> 154 | strncpy(buf, str, len); >> | ~~~~~~~^~~~~~~~~~~~~~~ >> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to > > Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. > >> recall another recent similar fix that was done by switching to using memcpy instead. >> Here's a discussion of interest, also suggesting memcpy: >> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice > > Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: > > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wstringop-truncation" > > solution. > > YMMV. We've run into and discussed problems with -Wstringop-truncation before. (See discussions of JDK-8214777 and JDK-8223186.) This is a relatively recent warning option (introduced in gcc8, and included in -Wall), and seems to have a considerable bug tail: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 A metabug for -Wstringop-truncation, currently with 16 open and 10 resolved associated bugs. I'm not a fan of replacing correct and idiomatic uses of strncpy with strcpy or memcpy. I've suggested in the past that we should turn off this warning while it is so buggy. From kim.barrett at oracle.com Thu Oct 10 21:01:02 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Thu, 10 Oct 2019 17:01:02 -0400 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> Message-ID: > On Oct 10, 2019, at 4:54 PM, Kim Barrett wrote: > This is a > relatively recent warning option (introduced in gcc8, and included in > -Wall) Maybe it was added to -Wall in gcc9, since we aren?t seeing these warnings with gcc8? From dean.long at oracle.com Fri Oct 11 00:05:44 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 10 Oct 2019 17:05:44 -0700 Subject: RFR: 8231952: ARM32: Wrong assumption in assertion in LIRGenerator::atomic_xchg and LIRGenerator::atomic_add In-Reply-To: <20191010143214.24A3B319F24@aojmv0009> References: <20191010143214.24A3B319F24@aojmv0009> Message-ID: Looks good to me. dl On 10/10/19 7:28 AM, christoph.goettschkes at microdoc.com wrote: > Hi, > > please review the following changeset. This patch fixes a wrong assumption > in an assertion of the C1 LIR generator for 32-bit ARM. The assertion > assumed that atomic operations are only possible for int types on 32-bit > arm. This is not true, since the LDREXD/STREXB instructions are use by the > C1 JIT. > > This fixes the 3 hotspot tier1 tests mentioned in the issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231952 > Webrev: https://cr.openjdk.java.net/~bulasevich/8231952/webrev.00/ > > Thanks, > Christoph > From felix.yang at huawei.com Fri Oct 11 00:45:18 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 11 Oct 2019 00:45:18 +0000 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop References: <041e13e4-a860-0523-c01d-f7d8d40230e4@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~fyang/8231988/webrev.01/ Is it OK to go? Thanks, Felix > > Hi, > > After some more try, I finally came up with a test case which does not > depend on 8u javac to trigger the problem. > > public class Test8231988 { > > public void mainTest() { > int i = 34; > for (; i > 0; i -= 11); > if (i < 0) { > // Test passed > } else { > throw new RuntimeException("Test failed"); > } > } > > public static void main(String[] args) { > Test8231988 _instance = new Test8231988(); > for (int i = 0; i < 50000; i++) { > _instance.mainTest(); > } > System.out.println("Test passed."); > } > > } > > $ java -version > openjdk version "14-internal" 2020-03-17 OpenJDK Runtime Environment (build > 14-internal+0-adhoc.yangfei.openjdk-jdk) > OpenJDK 64-Bit Server VM (build 14-internal+0-adhoc.yangfei.openjdk-jdk, > mixed mode, sharing) > > $ javac Test8231988.java > > $ java -Xint Test8231988 > Test passed. > > $ java -XX:-BackgroundCompilation -XX:-TieredCompilation Test8231988 > Exception in thread "main" java.lang.RuntimeException: Test failed > at Test8231988.mainTest(Test8231988.java:44) > at Test8231988.main(Test8231988.java:51) > > I am going to add this under test/hotspot/jtreg/compiler/c2 directory. From suenaga at oss.nttdata.com Fri Oct 11 01:34:05 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 11 Oct 2019 10:34:05 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> Message-ID: <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> Hi, I want to get conclusion of this discussion. I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion how we should fix diagnosticArgument.cpp . I think we can fix diagnosticArgument.cpp as following: A. Use memcpy() http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk This option will be added diagnosticArgument.cpp only. C. Set -Wno-stringop-truncation in globally make/hotspot/lib/CompileJvm.gmk I prefer to fix like A because it affects minimally. Some issues might be found out by stringop-truncation in future. Thanks, Yasumasa On 2019/10/11 5:54, Kim Barrett wrote: >> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >> >> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>> From JBS: >>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>> 154 | strncpy(buf, str, len); >>> | ~~~~~~~^~~~~~~~~~~~~~~ >>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >> >> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >> >>> recall another recent similar fix that was done by switching to using memcpy instead. >>> Here's a discussion of interest, also suggesting memcpy: >>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >> >> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >> >> #pragma GCC diagnostic push >> #pragma GCC diagnostic ignored "-Wstringop-truncation" >> >> solution. >> >> YMMV. > > We've run into and discussed problems with -Wstringop-truncation > before. (See discussions of JDK-8214777 and JDK-8223186.) This is a > relatively recent warning option (introduced in gcc8, and included in > -Wall), and seems to have a considerable bug tail: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 > A metabug for -Wstringop-truncation, currently with 16 open and 10 > resolved associated bugs. > > I'm not a fan of replacing correct and idiomatic uses of strncpy with > strcpy or memcpy. I've suggested in the past that we should turn off > this warning while it is so buggy. > From Pengfei.Li at arm.com Fri Oct 11 01:43:40 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 11 Oct 2019 01:43:40 +0000 Subject: RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> Message-ID: FW aarch64-port-dev as this is AArch64 related. -- Thanks, Pengfei > Hello, > > Please review the following small change to reserve r27 (heap base > register) on AArch64 unconditionally, i.e., regardless of whether compressed > oops is enabled or not. > > http://cr.openjdk.java.net/~yzheng/8231754/ > https://bugs.openjdk.java.net/browse/JDK-8231754 > > Many thanks, > -Yudi From chris.plummer at oracle.com Fri Oct 11 01:50:12 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Thu, 10 Oct 2019 18:50:12 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> Message-ID: <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> These solutions all have their merits and their warts, but we have to pick something. I'm ok with with A or C. For B I'd rather you instead used the #pragma at the warning site. If you go with (C), the review should go out to all of hotspot-dev and build-dev. Chris On 10/10/19 6:34 PM, Yasumasa Suenaga wrote: > Hi, > > I want to get conclusion of this discussion. > > I understand the fix of macroAssembler_x86.hpp is ok, but we have not > yet had conclusion > how we should fix diagnosticArgument.cpp . > > I think we can fix diagnosticArgument.cpp as following: > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B. Add -Wno-stringop-truncation to > make/hotspot/lib/JvmOverrideFiles.gmk > ?????? This option will be added diagnosticArgument.cpp only. > > ? C. Set -Wno-stringop-truncation in globally > ?????? make/hotspot/lib/CompileJvm.gmk > > > I prefer to fix like A because it affects minimally. > Some issues might be found out by stringop-truncation in future. > > > Thanks, > > Yasumasa > > > On 2019/10/11 5:54, Kim Barrett wrote: >>> On Oct 10, 2019, at 3:03 AM, David Holmes >>> wrote: >>> >>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>> ?From JBS: >>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>> truncated before terminating nul copying as many bytes from a >>>> string as its length [-Wstringop-truncation] >>>> ?? 154 | strncpy(buf, str, len); >>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>> I assume this means that in all cases the "len" value is seen to be >>>> derived from strlen, and therefore strncpy is always copying one >>>> byte short of \0, and this is most likely not what the user wants. >>>> I seem to >>> >>> Yes but we then explicitly set the NULL at buf[len] which is the >>> expected/required pattern for this. >>> >>>> recall another recent similar fix that was done by switching to >>>> using memcpy instead. >>>> Here's a discussion of interest, also suggesting memcpy: >>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>> >>> >>> Seems to me that strncpy and memcpy are semantically equivalent here >>> so all this does is avoid gcc's over zealous warnings. I'm inclined >>> to use the: >>> >>> #pragma GCC diagnostic push >>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>> >>> solution. >>> >>> YMMV. >> >> We've run into and discussed problems with -Wstringop-truncation >> before.? (See discussions of JDK-8214777 and JDK-8223186.)? This is a >> relatively recent warning option (introduced in gcc8, and included in >> -Wall), and seems to have a considerable bug tail: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >> A metabug for -Wstringop-truncation, currently with 16 open and 10 >> resolved associated bugs. >> >> I'm not a fan of replacing correct and idiomatic uses of strncpy with >> strcpy or memcpy.? I've suggested in the past that we should turn off >> this warning while it is so buggy. >> From suenaga at oss.nttdata.com Fri Oct 11 02:02:39 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 11 Oct 2019 11:02:39 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> Message-ID: Thanks Chris! If others agree with A, I will push webrev.02 . Yasumasa On 2019/10/11 10:50, Chris Plummer wrote: > These solutions all have their merits and their warts, but we have to pick something. I'm ok with with A or C. For B I'd rather you instead used the #pragma at the warning site. If you go with (C), the review should go out to all of hotspot-dev and build-dev. > > Chris > > On 10/10/19 6:34 PM, Yasumasa Suenaga wrote: >> Hi, >> >> I want to get conclusion of this discussion. >> >> I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion >> how we should fix diagnosticArgument.cpp . >> >> I think we can fix diagnosticArgument.cpp as following: >> >> >> ? A. Use memcpy() >> ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ? B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk >> ?????? This option will be added diagnosticArgument.cpp only. >> >> ? C. Set -Wno-stringop-truncation in globally >> ?????? make/hotspot/lib/CompileJvm.gmk >> >> >> I prefer to fix like A because it affects minimally. >> Some issues might be found out by stringop-truncation in future. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/10/11 5:54, Kim Barrett wrote: >>>> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >>>> >>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>> ?From JBS: >>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>>>> ?? 154 | strncpy(buf, str, len); >>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >>>> >>>> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >>>> >>>>> recall another recent similar fix that was done by switching to using memcpy instead. >>>>> Here's a discussion of interest, also suggesting memcpy: >>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>> >>>> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >>>> >>>> #pragma GCC diagnostic push >>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>> >>>> solution. >>>> >>>> YMMV. >>> >>> We've run into and discussed problems with -Wstringop-truncation >>> before.? (See discussions of JDK-8214777 and JDK-8223186.)? This is a >>> relatively recent warning option (introduced in gcc8, and included in >>> -Wall), and seems to have a considerable bug tail: >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>> resolved associated bugs. >>> >>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>> strcpy or memcpy.? I've suggested in the past that we should turn off >>> this warning while it is so buggy. >>> > > From daniel.daugherty at oracle.com Fri Oct 11 02:07:11 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 10 Oct 2019 22:07:11 -0400 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> Message-ID: <435c345b-46d4-6aa5-8c17-10a832ac0324@oracle.com> I think Kim has already been clear that he is not a fan of option A: > I'm not a fan of replacing correct and idiomatic uses of strncpy with > strcpy or memcpy.? I've suggested in the past that we should turn off > this warning while it is so buggy. Dan On 10/10/19 10:02 PM, Yasumasa Suenaga wrote: > Thanks Chris! > > If others agree with A, I will push webrev.02 . > > > Yasumasa > > > On 2019/10/11 10:50, Chris Plummer wrote: >> These solutions all have their merits and their warts, but we have to >> pick something. I'm ok with with A or C. For B I'd rather you instead >> used the #pragma at the warning site. If you go with (C), the review >> should go out to all of hotspot-dev and build-dev. >> >> Chris >> >> On 10/10/19 6:34 PM, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I want to get conclusion of this discussion. >>> >>> I understand the fix of macroAssembler_x86.hpp is ok, but we have >>> not yet had conclusion >>> how we should fix diagnosticArgument.cpp . >>> >>> I think we can fix diagnosticArgument.cpp as following: >>> >>> >>> ? A. Use memcpy() >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>> >>> ? B. Add -Wno-stringop-truncation to >>> make/hotspot/lib/JvmOverrideFiles.gmk >>> ?????? This option will be added diagnosticArgument.cpp only. >>> >>> ? C. Set -Wno-stringop-truncation in globally >>> ?????? make/hotspot/lib/CompileJvm.gmk >>> >>> >>> I prefer to fix like A because it affects minimally. >>> Some issues might be found out by stringop-truncation in future. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>> On Oct 10, 2019, at 3:03 AM, David Holmes >>>>> wrote: >>>>> >>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>> ?From JBS: >>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>>>> truncated before terminating nul copying as many bytes from a >>>>>> string as its length [-Wstringop-truncation] >>>>>> ?? 154 | strncpy(buf, str, len); >>>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>> I assume this means that in all cases the "len" value is seen to >>>>>> be derived from strlen, and therefore strncpy is always copying >>>>>> one byte short of \0, and this is most likely not what the user >>>>>> wants. I seem to >>>>> >>>>> Yes but we then explicitly set the NULL at buf[len] which is the >>>>> expected/required pattern for this. >>>>> >>>>>> recall another recent similar fix that was done by switching to >>>>>> using memcpy instead. >>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>> >>>>> >>>>> Seems to me that strncpy and memcpy are semantically equivalent >>>>> here so all this does is avoid gcc's over zealous warnings. I'm >>>>> inclined to use the: >>>>> >>>>> #pragma GCC diagnostic push >>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>> >>>>> solution. >>>>> >>>>> YMMV. >>>> >>>> We've run into and discussed problems with -Wstringop-truncation >>>> before.? (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>> relatively recent warning option (introduced in gcc8, and included in >>>> -Wall), and seems to have a considerable bug tail: >>>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>> resolved associated bugs. >>>> >>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>> this warning while it is so buggy. >>>> >> >> From serguei.spitsyn at oracle.com Fri Oct 11 03:38:34 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 10 Oct 2019 20:38:34 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> Message-ID: Hi Yasumasa, If this problem is local then I'd prefer variant A as this solution is local too. If this problem is observed in other places then variant C would be better. Thanks, Serguei On 10/10/19 18:34, Yasumasa Suenaga wrote: > Hi, > > I want to get conclusion of this discussion. > > I understand the fix of macroAssembler_x86.hpp is ok, but we have not > yet had conclusion > how we should fix diagnosticArgument.cpp . > > I think we can fix diagnosticArgument.cpp as following: > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B. Add -Wno-stringop-truncation to > make/hotspot/lib/JvmOverrideFiles.gmk > ?????? This option will be added diagnosticArgument.cpp only. > > ? C. Set -Wno-stringop-truncation in globally > ?????? make/hotspot/lib/CompileJvm.gmk > > > I prefer to fix like A because it affects minimally. > Some issues might be found out by stringop-truncation in future. > > > Thanks, > > Yasumasa > > > On 2019/10/11 5:54, Kim Barrett wrote: >>> On Oct 10, 2019, at 3:03 AM, David Holmes >>> wrote: >>> >>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>> ?From JBS: >>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>> truncated before terminating nul copying as many bytes from a >>>> string as its length [-Wstringop-truncation] >>>> ?? 154 | strncpy(buf, str, len); >>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>> I assume this means that in all cases the "len" value is seen to be >>>> derived from strlen, and therefore strncpy is always copying one >>>> byte short of \0, and this is most likely not what the user wants. >>>> I seem to >>> >>> Yes but we then explicitly set the NULL at buf[len] which is the >>> expected/required pattern for this. >>> >>>> recall another recent similar fix that was done by switching to >>>> using memcpy instead. >>>> Here's a discussion of interest, also suggesting memcpy: >>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>> >>> >>> Seems to me that strncpy and memcpy are semantically equivalent here >>> so all this does is avoid gcc's over zealous warnings. I'm inclined >>> to use the: >>> >>> #pragma GCC diagnostic push >>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>> >>> solution. >>> >>> YMMV. >> >> We've run into and discussed problems with -Wstringop-truncation >> before.? (See discussions of JDK-8214777 and JDK-8223186.)? This is a >> relatively recent warning option (introduced in gcc8, and included in >> -Wall), and seems to have a considerable bug tail: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >> A metabug for -Wstringop-truncation, currently with 16 open and 10 >> resolved associated bugs. >> >> I'm not a fan of replacing correct and idiomatic uses of strncpy with >> strcpy or memcpy.? I've suggested in the past that we should turn off >> this warning while it is so buggy. >> From fujie at loongson.cn Fri Oct 11 03:42:07 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Oct 2019 11:42:07 +0800 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> Message-ID: <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> Please hold off reviewing this until JDK-8232151 is fixed. Thanks. On 2019/10/10 ??1:39, Jie Fu wrote: > Hi all, > > May I get reviews for this fix? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232083 > Webrev: http://cr.openjdk.java.net/~jiefu/8232083/webrev.00/ > > Thanks a lot. > Best regards, > Jie > > From suenaga at oss.nttdata.com Fri Oct 11 04:33:43 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 11 Oct 2019 13:33:43 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> Message-ID: Hi Serguei, On 2019/10/11 12:38, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > If this problem is local then I'd prefer variant A as this solution is local too. > If this problem is observed in other places then variant C would be better. This problem might occur in other places in the future. In fact we can see warnings which have not warned in GCC 8. At least Ioi pointed out it in [1]. I guess it is caused by static analysis of GCC - tracing memory allocation, str length, and copy operation. It will be improved as Kim pointed [2]. Thanks, Yasumasa [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029565.html [2] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029567.html > Thanks, > Serguei > > > On 10/10/19 18:34, Yasumasa Suenaga wrote: >> Hi, >> >> I want to get conclusion of this discussion. >> >> I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion >> how we should fix diagnosticArgument.cpp . >> >> I think we can fix diagnosticArgument.cpp as following: >> >> >> ? A. Use memcpy() >> ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ? B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk >> ?????? This option will be added diagnosticArgument.cpp only. >> >> ? C. Set -Wno-stringop-truncation in globally >> ?????? make/hotspot/lib/CompileJvm.gmk >> >> >> I prefer to fix like A because it affects minimally. >> Some issues might be found out by stringop-truncation in future. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/10/11 5:54, Kim Barrett wrote: >>>> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >>>> >>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>> ?From JBS: >>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>>>> ?? 154 | strncpy(buf, str, len); >>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >>>> >>>> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >>>> >>>>> recall another recent similar fix that was done by switching to using memcpy instead. >>>>> Here's a discussion of interest, also suggesting memcpy: >>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>> >>>> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >>>> >>>> #pragma GCC diagnostic push >>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>> >>>> solution. >>>> >>>> YMMV. >>> >>> We've run into and discussed problems with -Wstringop-truncation >>> before.? (See discussions of JDK-8214777 and JDK-8223186.)? This is a >>> relatively recent warning option (introduced in gcc8, and included in >>> -Wall), and seems to have a considerable bug tail: >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>> resolved associated bugs. >>> >>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>> strcpy or memcpy.? I've suggested in the past that we should turn off >>> this warning while it is so buggy. >>> > From serguei.spitsyn at oracle.com Fri Oct 11 04:58:36 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Thu, 10 Oct 2019 21:58:36 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> Message-ID: <536de9cb-7b21-a524-f73a-d1e0a4c558f5@oracle.com> Hi Yasumasa, On 10/10/19 21:33, Yasumasa Suenaga wrote: > Hi Serguei, > > On 2019/10/11 12:38, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> If this problem is local then I'd prefer variant A as this solution >> is local too. >> If this problem is observed in other places then variant C would be >> better. > > This problem might occur in other places in the future. > In fact we can see warnings which have not warned in GCC 8. > > At least Ioi pointed out it in [1]. > I guess it is caused by static analysis of GCC - tracing memory > allocation, str length, and copy operation. > It will be improved as Kim pointed [2]. Okay, thanks. Yes, I see other emails on this. So, disabling these GCC 9.2.* warnings looks reasonable. Ioi even considered to avoid supporting gcc 9.2 until these issues have been fixed. Now, it needs to be reviewed by hotspot-dev and build-dev as Chris suggested. Thanks, Serguei > Thanks, > > Yasumasa > > > [1] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029565.html > [2] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029567.html > > >> Thanks, >> Serguei >> >> >> On 10/10/19 18:34, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I want to get conclusion of this discussion. >>> >>> I understand the fix of macroAssembler_x86.hpp is ok, but we have >>> not yet had conclusion >>> how we should fix diagnosticArgument.cpp . >>> >>> I think we can fix diagnosticArgument.cpp as following: >>> >>> >>> ? A. Use memcpy() >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>> >>> ? B. Add -Wno-stringop-truncation to >>> make/hotspot/lib/JvmOverrideFiles.gmk >>> ?????? This option will be added diagnosticArgument.cpp only. >>> >>> ? C. Set -Wno-stringop-truncation in globally >>> ?????? make/hotspot/lib/CompileJvm.gmk >>> >>> >>> I prefer to fix like A because it affects minimally. >>> Some issues might be found out by stringop-truncation in future. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>> On Oct 10, 2019, at 3:03 AM, David Holmes >>>>> wrote: >>>>> >>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>> ?From JBS: >>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>>>> truncated before terminating nul copying as many bytes from a >>>>>> string as its length [-Wstringop-truncation] >>>>>> ?? 154 | strncpy(buf, str, len); >>>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>> I assume this means that in all cases the "len" value is seen to >>>>>> be derived from strlen, and therefore strncpy is always copying >>>>>> one byte short of \0, and this is most likely not what the user >>>>>> wants. I seem to >>>>> >>>>> Yes but we then explicitly set the NULL at buf[len] which is the >>>>> expected/required pattern for this. >>>>> >>>>>> recall another recent similar fix that was done by switching to >>>>>> using memcpy instead. >>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>> >>>>> >>>>> Seems to me that strncpy and memcpy are semantically equivalent >>>>> here so all this does is avoid gcc's over zealous warnings. I'm >>>>> inclined to use the: >>>>> >>>>> #pragma GCC diagnostic push >>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>> >>>>> solution. >>>>> >>>>> YMMV. >>>> >>>> We've run into and discussed problems with -Wstringop-truncation >>>> before.? (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>> relatively recent warning option (introduced in gcc8, and included in >>>> -Wall), and seems to have a considerable bug tail: >>>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>> resolved associated bugs. >>>> >>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>> this warning while it is so buggy. >>>> >> From ioi.lam at oracle.com Fri Oct 11 05:37:29 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 10 Oct 2019 22:37:29 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> Message-ID: <52f37ca9-a152-1b85-644f-6d6d9d1c089e@oracle.com> For diagnosticArgument.cpp, I would prefer adding inline #pragma at only the sites affected (as suggested by David Holmes), with a comment about why this is necessary. But if others decide to go with other solutions, that's fine with me, too, but please remember to add a comment :-) Thanks - Ioi On 10/10/19 6:50 PM, Chris Plummer wrote: > These solutions all have their merits and their warts, but we have to > pick something. I'm ok with with A or C. For B I'd rather you instead > used the #pragma at the warning site. If you go with (C), the review > should go out to all of hotspot-dev and build-dev. > > Chris > > On 10/10/19 6:34 PM, Yasumasa Suenaga wrote: >> Hi, >> >> I want to get conclusion of this discussion. >> >> I understand the fix of macroAssembler_x86.hpp is ok, but we have not >> yet had conclusion >> how we should fix diagnosticArgument.cpp . >> >> I think we can fix diagnosticArgument.cpp as following: >> >> >> ? A. Use memcpy() >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ? B. Add -Wno-stringop-truncation to >> make/hotspot/lib/JvmOverrideFiles.gmk >> ?????? This option will be added diagnosticArgument.cpp only. >> >> ? C. Set -Wno-stringop-truncation in globally >> ?????? make/hotspot/lib/CompileJvm.gmk >> >> >> I prefer to fix like A because it affects minimally. >> Some issues might be found out by stringop-truncation in future. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/10/11 5:54, Kim Barrett wrote: >>>> On Oct 10, 2019, at 3:03 AM, David Holmes >>>> wrote: >>>> >>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>> ?From JBS: >>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>>> truncated before terminating nul copying as many bytes from a >>>>> string as its length [-Wstringop-truncation] >>>>> ?? 154 | strncpy(buf, str, len); >>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>> I assume this means that in all cases the "len" value is seen to >>>>> be derived from strlen, and therefore strncpy is always copying >>>>> one byte short of \0, and this is most likely not what the user >>>>> wants. I seem to >>>> >>>> Yes but we then explicitly set the NULL at buf[len] which is the >>>> expected/required pattern for this. >>>> >>>>> recall another recent similar fix that was done by switching to >>>>> using memcpy instead. >>>>> Here's a discussion of interest, also suggesting memcpy: >>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>> >>>> >>>> Seems to me that strncpy and memcpy are semantically equivalent >>>> here so all this does is avoid gcc's over zealous warnings. I'm >>>> inclined to use the: >>>> >>>> #pragma GCC diagnostic push >>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>> >>>> solution. >>>> >>>> YMMV. >>> >>> We've run into and discussed problems with -Wstringop-truncation >>> before.? (See discussions of JDK-8214777 and JDK-8223186.) This is a >>> relatively recent warning option (introduced in gcc8, and included in >>> -Wall), and seems to have a considerable bug tail: >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>> resolved associated bugs. >>> >>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>> strcpy or memcpy.? I've suggested in the past that we should turn off >>> this warning while it is so buggy. >>> > > From dean.long at oracle.com Fri Oct 11 05:47:01 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 10 Oct 2019 22:47:01 -0700 Subject: RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> Message-ID: Wouldn't it be better to make r27 callee-saved in cpu/aarch64/sharedRuntime_aarch64.cpp:RegisterSaver::save_live_registers()? dl On 10/10/19 6:43 PM, Pengfei Li (Arm Technology China) wrote: > FW aarch64-port-dev as this is AArch64 related. > > -- > Thanks, > Pengfei > >> Hello, >> >> Please review the following small change to reserve r27 (heap base >> register) on AArch64 unconditionally, i.e., regardless of whether compressed >> oops is enabled or not. >> >> http://cr.openjdk.java.net/~yzheng/8231754/ >> https://bugs.openjdk.java.net/browse/JDK-8231754 >> >> Many thanks, >> -Yudi From david.holmes at oracle.com Fri Oct 11 06:54:20 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2019 16:54:20 +1000 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <52f37ca9-a152-1b85-644f-6d6d9d1c089e@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> <52f37ca9-a152-1b85-644f-6d6d9d1c089e@oracle.com> Message-ID: <85845679-b98e-cc6d-0870-2b069bef3240@oracle.com> Yes I prefer: D. Use #pragma ... at the callsite to disable this particular diagnostic. over changing the makefiles. David On 11/10/2019 3:37 pm, Ioi Lam wrote: > For diagnosticArgument.cpp, I would prefer adding inline #pragma at only > the sites affected (as suggested by David Holmes), with a comment about > why this is necessary. > > But if others decide to go with other solutions, that's fine with me, > too, but please remember to add a comment :-) > > Thanks > - Ioi > > On 10/10/19 6:50 PM, Chris Plummer wrote: >> These solutions all have their merits and their warts, but we have to >> pick something. I'm ok with with A or C. For B I'd rather you instead >> used the #pragma at the warning site. If you go with (C), the review >> should go out to all of hotspot-dev and build-dev. >> >> Chris >> >> On 10/10/19 6:34 PM, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I want to get conclusion of this discussion. >>> >>> I understand the fix of macroAssembler_x86.hpp is ok, but we have not >>> yet had conclusion >>> how we should fix diagnosticArgument.cpp . >>> >>> I think we can fix diagnosticArgument.cpp as following: >>> >>> >>> ? A. Use memcpy() >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>> >>> ? B. Add -Wno-stringop-truncation to >>> make/hotspot/lib/JvmOverrideFiles.gmk >>> ?????? This option will be added diagnosticArgument.cpp only. >>> >>> ? C. Set -Wno-stringop-truncation in globally >>> ?????? make/hotspot/lib/CompileJvm.gmk >>> >>> >>> I prefer to fix like A because it affects minimally. >>> Some issues might be found out by stringop-truncation in future. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>> On Oct 10, 2019, at 3:03 AM, David Holmes >>>>> wrote: >>>>> >>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>> ?From JBS: >>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>>>> truncated before terminating nul copying as many bytes from a >>>>>> string as its length [-Wstringop-truncation] >>>>>> ?? 154 | strncpy(buf, str, len); >>>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>> I assume this means that in all cases the "len" value is seen to >>>>>> be derived from strlen, and therefore strncpy is always copying >>>>>> one byte short of \0, and this is most likely not what the user >>>>>> wants. I seem to >>>>> >>>>> Yes but we then explicitly set the NULL at buf[len] which is the >>>>> expected/required pattern for this. >>>>> >>>>>> recall another recent similar fix that was done by switching to >>>>>> using memcpy instead. >>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>> >>>>> >>>>> Seems to me that strncpy and memcpy are semantically equivalent >>>>> here so all this does is avoid gcc's over zealous warnings. I'm >>>>> inclined to use the: >>>>> >>>>> #pragma GCC diagnostic push >>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>> >>>>> solution. >>>>> >>>>> YMMV. >>>> >>>> We've run into and discussed problems with -Wstringop-truncation >>>> before.? (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>> relatively recent warning option (introduced in gcc8, and included in >>>> -Wall), and seems to have a considerable bug tail: >>>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>> resolved associated bugs. >>>> >>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>> this warning while it is so buggy. >>>> >> >> > From suenaga at oss.nttdata.com Fri Oct 11 06:55:06 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 11 Oct 2019 15:55:06 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> Message-ID: Hi, Thanks for a lot advises! We have following solutions for this issue. I'd like to send RFR again with much consented patch in early next week. A. Use memcpy() http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ B-1. Use #pragma http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ C. Set -Wno-stringop-truncation in globally http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ If we fix with C, I will send RFR to hotspot-dev and build-dev. Plan C also fixes other stringop-truncation problems such as JDK-8220074. Thus it affects all of JDK code, but it would be useful if stringop-truncation should be disabled in JDK build process. Comments are welcome. Yasumasa On 2019/10/11 10:34, Yasumasa Suenaga wrote: > Hi, > > I want to get conclusion of this discussion. > > I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion > how we should fix diagnosticArgument.cpp . > > I think we can fix diagnosticArgument.cpp as following: > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk > ?????? This option will be added diagnosticArgument.cpp only. > > ? C. Set -Wno-stringop-truncation in globally > ?????? make/hotspot/lib/CompileJvm.gmk > > > I prefer to fix like A because it affects minimally. > Some issues might be found out by stringop-truncation in future. > > > Thanks, > > Yasumasa > > > On 2019/10/11 5:54, Kim Barrett wrote: >>> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >>> >>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>> ?From JBS: >>>> ? /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>>> ?? 154 | strncpy(buf, str, len); >>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >>> >>> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >>> >>>> recall another recent similar fix that was done by switching to using memcpy instead. >>>> Here's a discussion of interest, also suggesting memcpy: >>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>> >>> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >>> >>> #pragma GCC diagnostic push >>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>> >>> solution. >>> >>> YMMV. >> >> We've run into and discussed problems with -Wstringop-truncation >> before.? (See discussions of JDK-8214777 and JDK-8223186.)? This is a >> relatively recent warning option (introduced in gcc8, and included in >> -Wall), and seems to have a considerable bug tail: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >> A metabug for -Wstringop-truncation, currently with 16 open and 10 >> resolved associated bugs. >> >> I'm not a fan of replacing correct and idiomatic uses of strncpy with >> strcpy or memcpy.? I've suggested in the past that we should turn off >> this warning while it is so buggy. >> From gilles.m.duboscq at oracle.com Fri Oct 11 07:55:41 2019 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Fri, 11 Oct 2019 09:55:41 +0200 Subject: RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> Message-ID: The idea was to first bring JVMCI in line with what the other compilers do (never allocate r27) and then investigate how we could make r27 conditionally allocatable if there is interest. Gilles On 11/10/2019 07:47, dean.long at oracle.com wrote: > Wouldn't it be better to make r27 callee-saved in cpu/aarch64/sharedRuntime_aarch64.cpp:RegisterSaver::save_live_registers()? > > dl > > On 10/10/19 6:43 PM, Pengfei Li (Arm Technology China) wrote: >> FW aarch64-port-dev as this is AArch64 related. >> >> -- >> Thanks, >> Pengfei >> >>> Hello, >>> >>> Please review the following small change to reserve r27 (heap base >>> register) on AArch64 unconditionally, i.e., regardless of whether compressed >>> oops is enabled or not. >>> >>> http://cr.openjdk.java.net/~yzheng/8231754/ >>> https://bugs.openjdk.java.net/browse/JDK-8231754 >>> >>> Many thanks, >>> -Yudi > From tobias.hartmann at oracle.com Fri Oct 11 08:16:26 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 11 Oct 2019 10:16:26 +0200 Subject: RFR(M) [14] : 8225654 : rework vmTestbase/jit/graph In-Reply-To: <9F47BF2F-C122-40B6-9BA5-86504AA0503F@oracle.com> References: <3A418E88-2FBA-4253-A249-C30A6DC1C5CC@oracle.com> <86F0F16D-4170-4548-9E3B-84AEC0C7CEB4@oracle.com> <2F61AC46-EDFF-4A74-8CC7-95AEEBB1E565@oracle.com> <5e7bbf03-14c7-0c7d-5f69-d89da5d405a3@oracle.com> <9F47BF2F-C122-40B6-9BA5-86504AA0503F@oracle.com> Message-ID: <8a58a3a0-edc5-be0a-2b2a-bd7a41e3e9dc@oracle.com> Hi Igor, On 10.10.19 19:45, Igor Ignatyev wrote: > can I get a second review? This looks good to me too. Best regards, Tobias From nils.eliasson at oracle.com Fri Oct 11 08:15:14 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Fri, 11 Oct 2019 10:15:14 +0200 Subject: RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: References: <41d1807c-f4b7-2b74-11c2-e0d9fc5784ca@oracle.com> <655c746e-2456-4422-5c14-d49e08864acf@oracle.com> Message-ID: <2d1a4717-76cc-fea6-727d-5ffb21a2fe9c@oracle.com> On 2019-10-10 20:57, Andrew Haley wrote: > On 10/8/19 2:37 PM, Nils Eliasson wrote: >> For the non-Aarch64 parts: Looks good! > +int MacroAssembler::pop_fp(unsigned int bitset, Register stack) { > + int words_pushed = 0; > + > + // Scan bitset to accumulate register pairs > + unsigned char regs[32]; > + int count = 0; > + for (int reg = 0; reg <= 31; reg++) { > + if (1 & bitset) > + regs[count++] = reg; > + bitset >>= 1; > + } > + regs[count++] = zr->encoding_nocheck(); > > This use of ZR looks wrong in FP code. There is no floating-point ZR. > Right. We shouldn't use zr here - but any register will do since its just padding to get an even count of spills. -? regs[count++] = zr->encoding_nocheck(); + regs[count++] = 0; // Add reg 0 as padding - we want to spill an even number of registers // Nils From tobias.hartmann at oracle.com Fri Oct 11 08:25:09 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 11 Oct 2019 10:25:09 +0200 Subject: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 instructions on processors which don't support it In-Reply-To: References: Message-ID: <5ccebd52-0bff-75b3-c3e0-c201597b6943@oracle.com> Hi Martin, so this was introduced by JDK-8222074, right? Just wondering, does AddReductionVI require SSSE3 as well? Thanks, Tobias On 10.10.19 14:29, Doerr, Martin wrote: > Hi, > > we have observed a JVM crash in JDK13u on an AMD Opteron machine. > > Instructions like pabsb/w/d, phaddd get emitted when SSE3 is available, but are not supported without SSSE3. > E.g. AMD Opteron(tm) Processor 2218 has SSE3, but not SSSE3. > > Should we fix it this way? > http://cr.openjdk.java.net/~mdoerr/8232106_x86_ssse3/webrev.00/ > > Best regards, > Martin > From adinn at redhat.com Fri Oct 11 08:27:19 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 Oct 2019 09:27:19 +0100 Subject: RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> Message-ID: <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> > On 11/10/2019 07:47, dean.long at oracle.com wrote: >> Wouldn't it be better to make r27 callee-saved in >> cpu/aarch64/sharedRuntime_aarch64.cpp:RegisterSaver::save_live_registers()? On 11/10/2019 08:55, Gilles Duboscq wrote: > The idea was to first bring JVMCI in line with what the other compilers > do (never allocate r27) and then investigate how we could make r27 > conditionally allocatable if there is interest. I prefer Dean's suggestion. If I understand this patch correctly it seems it was motivated by a desire to deal with the failure to mark r27 as callee-saved in save_live_registers when it has been made allocatable. Bypassing that bug by disabling the optimization seems to me to be a needless regression; why not just fix the bug? (also, see below). n.b. I guess that also answers your speculation as to whether anyone is interested in allocating conditionally -- we were interested enough some time ago to implement this. When you say 'other compilers' are you referring to the Graal JIT? Or is there also a problem with C1 and/or C2? (or maybe some other JVMCI compiler we don't yet know about? ;-). If the problem is just that Graal cannot work safely when r27 is allocatable then can we not change the condition for enabling use of r27 to include a test that JVMCI is disabled? (and fix the callee_saved issue at the same time, of course :). regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From richard.reingruber at sap.com Fri Oct 11 08:41:02 2019 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Fri, 11 Oct 2019 08:41:02 +0000 Subject: RFR(XXS) 8232162: Object reallocation in Deoptimization::fetch_unroll_info_helper should not depend on EliminateNestedLocks Message-ID: Hi, could I please get reviews for Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8232162/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8232162 The fix removes the C2 flag EliminateNestedLocks from the condition for reallocating objects, because C2 eliminates allocations depending only on DoEscapeAnalysis && EliminateAllocations. I put the patch through SAP's nightly testing (includes all platforms, jtreg tests, and more). Thanks, Richard. From gilles.m.duboscq at oracle.com Fri Oct 11 08:47:02 2019 From: gilles.m.duboscq at oracle.com (Gilles Duboscq) Date: Fri, 11 Oct 2019 10:47:02 +0200 Subject: RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> Message-ID: Hi Andrew, By "other compilers" i meant C1 and C2. Neither of those compilers ever allocates r27. If they would they would likely also run into issue like Graal did when we tried to follow what JVMCI says before this fix (i.e., "r27 can be allocated if compressed oops are disabled"). For context, Graal currently avoids r27 regardless of what JVMCI says. To me it looks like the aarch64 port just does not support allocating r27 in its current state and we want to make JVMCI reflect that. Out of curiosity we tried to see what is currently preventing r27 from being allocated and the issue that Yudi described is a problem we spotted. That does not mean there are no other issues. Determining that would require a much more careful review of the code and testing (for example by making is alloctable by C1, C2, and Graal and running extensive test suites). Regards, Gilles On 11/10/2019 10:27, Andrew Dinn wrote: >> On 11/10/2019 07:47, dean.long at oracle.com wrote: >>> Wouldn't it be better to make r27 callee-saved in >>> cpu/aarch64/sharedRuntime_aarch64.cpp:RegisterSaver::save_live_registers()? > > On 11/10/2019 08:55, Gilles Duboscq wrote: >> The idea was to first bring JVMCI in line with what the other compilers >> do (never allocate r27) and then investigate how we could make r27 >> conditionally allocatable if there is interest. > > I prefer Dean's suggestion. If I understand this patch correctly it > seems it was motivated by a desire to deal with the failure to mark r27 > as callee-saved in save_live_registers when it has been made > allocatable. Bypassing that bug by disabling the optimization seems to > me to be a needless regression; why not just fix the bug? (also, see below). > > n.b. I guess that also answers your speculation as to whether anyone is > interested in allocating conditionally -- we were interested enough some > time ago to implement this. > > When you say 'other compilers' are you referring to the Graal JIT? Or is > there also a problem with C1 and/or C2? (or maybe some other JVMCI > compiler we don't yet know about? ;-). > > If the problem is just that Graal cannot work safely when r27 is > allocatable then can we not change the condition for enabling use of r27 > to include a test that JVMCI is disabled? (and fix the callee_saved > issue at the same time, of course :). > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From yudi.zheng at oracle.com Fri Oct 11 08:55:44 2019 From: yudi.zheng at oracle.com (Yudi Zheng) Date: Fri, 11 Oct 2019 10:55:44 +0200 Subject: RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> Message-ID: <47e7634c-7512-5036-fa94-43bee3688351@oracle.com> As Gilles said, at the moment we took a conservative approach and align with C1/C2 by not marking r27 as allocatable. We did not investigate further and check whether cpu/aarch64/sharedRuntime_aarch64.cpp:RegisterSaver::save_live_registers is the only place assuming r27 is not allocatable. It would be great to use some help from the AArch64 experts to properly address this issue. To reproduce, follow the instructions at https://github.com/oracle/graal/issues/1704 You will need to revert https://github.com/oracle/graal/commit/e4d9c5f09a3c9be9f3c66ff0feff787519875a12 to allow Graal compiler allocate r27. -Yudi On 10/11/19 10:27 AM, Andrew Dinn wrote: >> On 11/10/2019 07:47, dean.long at oracle.com wrote: >>> Wouldn't it be better to make r27 callee-saved in >>> cpu/aarch64/sharedRuntime_aarch64.cpp:RegisterSaver::save_live_registers()? > On 11/10/2019 08:55, Gilles Duboscq wrote: >> The idea was to first bring JVMCI in line with what the other compilers >> do (never allocate r27) and then investigate how we could make r27 >> conditionally allocatable if there is interest. > I prefer Dean's suggestion. If I understand this patch correctly it > seems it was motivated by a desire to deal with the failure to mark r27 > as callee-saved in save_live_registers when it has been made > allocatable. Bypassing that bug by disabling the optimization seems to > me to be a needless regression; why not just fix the bug? (also, see below). > > n.b. I guess that also answers your speculation as to whether anyone is > interested in allocating conditionally -- we were interested enough some > time ago to implement this. > > When you say 'other compilers' are you referring to the Graal JIT? Or is > there also a problem with C1 and/or C2? (or maybe some other JVMCI > compiler we don't yet know about? ;-). > > If the problem is just that Graal cannot work safely when r27 is > allocatable then can we not change the condition for enabling use of r27 > to include a test that JVMCI is disabled? (and fix the callee_saved > issue at the same time, of course :). > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From tobias.hartmann at oracle.com Fri Oct 11 09:03:57 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 11 Oct 2019 11:03:57 +0200 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop In-Reply-To: References: <041e13e4-a860-0523-c01d-f7d8d40230e4@oracle.com> Message-ID: <3098cce0-bf26-9bba-554e-7e5b66930371@oracle.com> Hi Felix, On 11.10.19 02:45, Yangfei (Felix) wrote: > Updated webrev: http://cr.openjdk.java.net/~fyang/8231988/webrev.01/ If possible, tests should have a name that describes their purpose and should be put into one of the corresponding folders. In this case, I would suggest TestRemoveEmptyLoop and put it into compiler/loopopts/. Thanks, Tobias From tobias.hartmann at oracle.com Fri Oct 11 09:22:58 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 11 Oct 2019 11:22:58 +0200 Subject: RFR(XXS) 8232162: Object reallocation in Deoptimization::fetch_unroll_info_helper should not depend on EliminateNestedLocks In-Reply-To: References: Message-ID: <0b007915-27bd-5c66-ced6-e9223925aeaa@oracle.com> Hi Richard, looks good to me. Bets regards, Tobias On 11.10.19 10:41, Reingruber, Richard wrote: > Hi, > > could I please get reviews for > > Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8232162/webrev.0/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8232162 > > The fix removes the C2 flag EliminateNestedLocks from the condition for reallocating objects, > because C2 eliminates allocations depending only on DoEscapeAnalysis && EliminateAllocations. > > I put the patch through SAP's nightly testing (includes all platforms, jtreg tests, and more). > > Thanks, Richard. > From adinn at redhat.com Fri Oct 11 09:41:04 2019 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 11 Oct 2019 10:41:04 +0100 Subject: RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> Message-ID: Hi Gilles, On 11/10/2019 09:47, Gilles Duboscq wrote: > By "other compilers" i meant C1 and C2. Neither of those compilers ever > allocates r27. Ah, my apologies. I thought Roman Kennke investigated and pushed a patch for this optimization earlier in the year. Clearly, that experiment never escaped from the lab. In which case, I'm happy for Yudi's patch to go ahead as is. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From christian.hagedorn at oracle.com Fri Oct 11 10:34:32 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Fri, 11 Oct 2019 12:34:32 +0200 Subject: [14] RFR(S): 8231412: C2: InitializeNode::detect_init_independence() bails out on simple IR shapes Message-ID: Hi Please review the following enhancement: https://bugs.openjdk.java.net/browse/JDK-8231412 http://cr.openjdk.java.net/~chagedorn/8231412/webrev.00/ This enhancement addresses the early bailout of capturing a field store to remove unnecessary zeroing [1] in simple methods containing only non-escaping objects. As a consequence, some allocations were marked not scalar replaceable by the escape analysis which prevented their elimination. The patch translates the recursive algorithm of the InitializeNode::detect_init_independence() method into an iterative one to avoid processing the same nodes twice. Additionally, a dominator check is inserted to further reduce iterations: If a CFG node dominates the current allocation then there cannot be any dependency beyond that node. In order to successfully apply this check for the sample program from the original discussion where this enhancement came up [2] and the corresponding jtreg test in the patch, the constant [3] was increased. As a result the field store can be captured and the escape analysis can remove all allocations in those methods. The larger value of the constant [3] had no negative impact on performance (verified with some standard benchmarks). Thank you! Best regards, Christian [1] http://hg.openjdk.java.net/jdk/jdk/file/e98509cb3867/src/hotspot/share/opto/memnode.cpp#l3602 [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035135.html [3] http://hg.openjdk.java.net/jdk/jdk/file/e98509cb3867/src/hotspot/share/opto/phaseX.cpp#l902 From claes.redestad at oracle.com Fri Oct 11 11:42:40 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 11 Oct 2019 13:42:40 +0200 Subject: RFR: 8232165: Reduce allocations in ValueStack copying constructor Message-ID: <5e1dd9d7-2ea1-1026-13f9-8da698b8a110@oracle.com> Hi, this patch optimizes C1 ValueStack copying, which reduces unnecessary allocations and has a small but measurable impact on compilation speed. Webrev: http://cr.openjdk.java.net/~redestad/8232165/open.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8232165 Testing: tier1-2 (tier3-4 ongoing) Thanks! /Claes From fujie at loongson.cn Fri Oct 11 12:07:28 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 11 Oct 2019 20:07:28 +0800 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> Message-ID: <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> Hi all, JDK-8232151 had been fixed. Could you please review this fix and give me some advice? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232083 Webrev: http://cr.openjdk.java.net/~jiefu/8232083/webrev.00/ Thanks a lot. Best regards, Jie On 2019/10/11 ??11:42, Jie Fu wrote: > Please hold off reviewing this until JDK-8232151 > is fixed. From christos at zoulas.com Fri Oct 11 12:47:15 2019 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 11 Oct 2019 08:47:15 -0400 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <85845679-b98e-cc6d-0870-2b069bef3240@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> <52f37ca9-a152-1b85-644f-6d6d9d1c089e@oracle.com> <85845679-b98e-cc6d-0870-2b069bef3240@oracle.com> Message-ID: At NetBSD we decided to change the Makefiles because we compile with both clang and gcc and clang does not have those warnings and it complains about the pragmas. christos > On Oct 11, 2019, at 2:54 AM, David Holmes wrote: > > Yes I prefer: > > D. Use #pragma ... at the callsite to disable this particular diagnostic. > > over changing the makefiles. > > David > > On 11/10/2019 3:37 pm, Ioi Lam wrote: >> For diagnosticArgument.cpp, I would prefer adding inline #pragma at only the sites affected (as suggested by David Holmes), with a comment about why this is necessary. >> But if others decide to go with other solutions, that's fine with me, too, but please remember to add a comment :-) >> Thanks >> - Ioi >> On 10/10/19 6:50 PM, Chris Plummer wrote: >>> These solutions all have their merits and their warts, but we have to pick something. I'm ok with with A or C. For B I'd rather you instead used the #pragma at the warning site. If you go with (C), the review should go out to all of hotspot-dev and build-dev. >>> >>> Chris >>> >>> On 10/10/19 6:34 PM, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>> I want to get conclusion of this discussion. >>>> >>>> I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion >>>> how we should fix diagnosticArgument.cpp . >>>> >>>> I think we can fix diagnosticArgument.cpp as following: >>>> >>>> >>>> A. Use memcpy() >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>>> >>>> B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk >>>> This option will be added diagnosticArgument.cpp only. >>>> >>>> C. Set -Wno-stringop-truncation in globally >>>> make/hotspot/lib/CompileJvm.gmk >>>> >>>> >>>> I prefer to fix like A because it affects minimally. >>>> Some issues might be found out by stringop-truncation in future. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>>> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >>>>>> >>>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>>> From JBS: >>>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>>>>>> 154 | strncpy(buf, str, len); >>>>>>> | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >>>>>> >>>>>> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >>>>>> >>>>>>> recall another recent similar fix that was done by switching to using memcpy instead. >>>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>> >>>>>> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >>>>>> >>>>>> #pragma GCC diagnostic push >>>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>>> >>>>>> solution. >>>>>> >>>>>> YMMV. >>>>> >>>>> We've run into and discussed problems with -Wstringop-truncation >>>>> before. (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>>> relatively recent warning option (introduced in gcc8, and included in >>>>> -Wall), and seems to have a considerable bug tail: >>>>> >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>>> resolved associated bugs. >>>>> >>>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>>> strcpy or memcpy. I've suggested in the past that we should turn off >>>>> this warning while it is so buggy. >>>>> >>> >>> From david.holmes at oracle.com Fri Oct 11 12:51:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 11 Oct 2019 22:51:10 +1000 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> <52f37ca9-a152-1b85-644f-6d6d9d1c089e@oracle.com> <85845679-b98e-cc6d-0870-2b069bef3240@oracle.com> Message-ID: <5d723f1b-9623-5527-2ef5-98694129b955@oracle.com> On 11/10/2019 10:47 pm, Christos Zoulas wrote: > At NetBSD we decided to change the Makefiles because we compile with both clang and gcc > and clang does not have those warnings and it complains about the pragmas. Compilers are supposed to ignore pragmas they don't understand. Complaining about an unknown pragma defeats the whole purpose of having pragmas. I suppose to prevent problems with clang we must disable the warning in the makefile. David > christos > >> On Oct 11, 2019, at 2:54 AM, David Holmes wrote: >> >> Yes I prefer: >> >> D. Use #pragma ... at the callsite to disable this particular diagnostic. >> >> over changing the makefiles. >> >> David >> >> On 11/10/2019 3:37 pm, Ioi Lam wrote: >>> For diagnosticArgument.cpp, I would prefer adding inline #pragma at only the sites affected (as suggested by David Holmes), with a comment about why this is necessary. >>> But if others decide to go with other solutions, that's fine with me, too, but please remember to add a comment :-) >>> Thanks >>> - Ioi >>> On 10/10/19 6:50 PM, Chris Plummer wrote: >>>> These solutions all have their merits and their warts, but we have to pick something. I'm ok with with A or C. For B I'd rather you instead used the #pragma at the warning site. If you go with (C), the review should go out to all of hotspot-dev and build-dev. >>>> >>>> Chris >>>> >>>> On 10/10/19 6:34 PM, Yasumasa Suenaga wrote: >>>>> Hi, >>>>> >>>>> I want to get conclusion of this discussion. >>>>> >>>>> I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion >>>>> how we should fix diagnosticArgument.cpp . >>>>> >>>>> I think we can fix diagnosticArgument.cpp as following: >>>>> >>>>> >>>>> A. Use memcpy() >>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>>>> >>>>> B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk >>>>> This option will be added diagnosticArgument.cpp only. >>>>> >>>>> C. Set -Wno-stringop-truncation in globally >>>>> make/hotspot/lib/CompileJvm.gmk >>>>> >>>>> >>>>> I prefer to fix like A because it affects minimally. >>>>> Some issues might be found out by stringop-truncation in future. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>>>> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >>>>>>> >>>>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>>>> From JBS: >>>>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>>>>>>> 154 | strncpy(buf, str, len); >>>>>>>> | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>>>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >>>>>>> >>>>>>> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >>>>>>> >>>>>>>> recall another recent similar fix that was done by switching to using memcpy instead. >>>>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>>> >>>>>>> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >>>>>>> >>>>>>> #pragma GCC diagnostic push >>>>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>>>> >>>>>>> solution. >>>>>>> >>>>>>> YMMV. >>>>>> >>>>>> We've run into and discussed problems with -Wstringop-truncation >>>>>> before. (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>>>> relatively recent warning option (introduced in gcc8, and included in >>>>>> -Wall), and seems to have a considerable bug tail: >>>>>> >>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>>>> resolved associated bugs. >>>>>> >>>>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>>>> strcpy or memcpy. I've suggested in the past that we should turn off >>>>>> this warning while it is so buggy. >>>>>> >>>> >>>> > From suenaga at oss.nttdata.com Fri Oct 11 12:57:07 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 11 Oct 2019 21:57:07 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <5d723f1b-9623-5527-2ef5-98694129b955@oracle.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> <52f37ca9-a152-1b85-644f-6d6d9d1c089e@oracle.com> <85845679-b98e-cc6d-0870-2b069bef3240@oracle.com> <5d723f1b-9623-5527-2ef5-98694129b955@oracle.com> Message-ID: <6568104d-bb7a-a41e-7154-7940e983c4b9@oss.nttdata.com> Hi, I proposed 3 solutions in [1]. Plan B-1 is #pragma, but HotSpot provides valid macro to compiler. I added stringop-truncation to it [2], and it would work each compilers. Yasumasa [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029580.html [2] http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ On 2019/10/11 21:51, David Holmes wrote: > On 11/10/2019 10:47 pm, Christos Zoulas wrote: >> At NetBSD we decided to change the Makefiles because? we compile with both clang and gcc >> and clang does not have those warnings and it complains about the pragmas. > > Compilers are supposed to ignore pragmas they don't understand. Complaining about an unknown pragma defeats the whole purpose of having pragmas. > > I suppose to prevent problems with clang we must disable the warning in the makefile. > > David > >> christos >> >>> On Oct 11, 2019, at 2:54 AM, David Holmes wrote: >>> >>> Yes I prefer: >>> >>> D. Use #pragma ... at the callsite to disable this particular diagnostic. >>> >>> over changing the makefiles. >>> >>> David >>> >>> On 11/10/2019 3:37 pm, Ioi Lam wrote: >>>> For diagnosticArgument.cpp, I would prefer adding inline #pragma at only the sites affected (as suggested by David Holmes), with a comment about why this is necessary. >>>> But if others decide to go with other solutions, that's fine with me, too, but please remember to add a comment :-) >>>> Thanks >>>> - Ioi >>>> On 10/10/19 6:50 PM, Chris Plummer wrote: >>>>> These solutions all have their merits and their warts, but we have to pick something. I'm ok with with A or C. For B I'd rather you instead used the #pragma at the warning site. If you go with (C), the review should go out to all of hotspot-dev and build-dev. >>>>> >>>>> Chris >>>>> >>>>> On 10/10/19 6:34 PM, Yasumasa Suenaga wrote: >>>>>> Hi, >>>>>> >>>>>> I want to get conclusion of this discussion. >>>>>> >>>>>> I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion >>>>>> how we should fix diagnosticArgument.cpp . >>>>>> >>>>>> I think we can fix diagnosticArgument.cpp as following: >>>>>> >>>>>> >>>>>> ?? A. Use memcpy() >>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>>>>> >>>>>> ?? B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk >>>>>> ??????? This option will be added diagnosticArgument.cpp only. >>>>>> >>>>>> ?? C. Set -Wno-stringop-truncation in globally >>>>>> ??????? make/hotspot/lib/CompileJvm.gmk >>>>>> >>>>>> >>>>>> I prefer to fix like A because it affects minimally. >>>>>> Some issues might be found out by stringop-truncation in future. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>>>>> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >>>>>>>> >>>>>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>>>>> ? From JBS: >>>>>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>>>>>>>> ??? 154 | strncpy(buf, str, len); >>>>>>>>> ??????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>>>>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >>>>>>>> >>>>>>>> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >>>>>>>> >>>>>>>>> recall another recent similar fix that was done by switching to using memcpy instead. >>>>>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>>>> >>>>>>>> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >>>>>>>> >>>>>>>> #pragma GCC diagnostic push >>>>>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>>>>> >>>>>>>> solution. >>>>>>>> >>>>>>>> YMMV. >>>>>>> >>>>>>> We've run into and discussed problems with -Wstringop-truncation >>>>>>> before.? (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>>>>> relatively recent warning option (introduced in gcc8, and included in >>>>>>> -Wall), and seems to have a considerable bug tail: >>>>>>> >>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>>>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>>>>> resolved associated bugs. >>>>>>> >>>>>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>>>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>>>>> this warning while it is so buggy. >>>>>>> >>>>> >>>>> >> From christos at zoulas.com Fri Oct 11 13:01:59 2019 From: christos at zoulas.com (Christos Zoulas) Date: Fri, 11 Oct 2019 09:01:59 -0400 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <6568104d-bb7a-a41e-7154-7940e983c4b9@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <3258d71c-5298-0e64-7bfe-2187a8c0a31c@oracle.com> <52f37ca9-a152-1b85-644f-6d6d9d1c089e@oracle.com> <85845679-b98e-cc6d-0870-2b069bef3240@oracle.com> <5d723f1b-9623-5527-2ef5-98694129b955@oracle.com> <6568104d-bb7a-a41e-7154-7940e983c4b9@oss.nttdata.com> Message-ID: Thanks! That's seems to be a nicer way to fix it, but remember that both gcc and clang define __GNUC__ so I think this patch should be more restrictive: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/src/hotspot/share/utilities/compilerWarnings_gcc.hpp.udiff.html christos > On Oct 11, 2019, at 8:57 AM, Yasumasa Suenaga wrote: > > Hi, > > I proposed 3 solutions in [1]. > > Plan B-1 is #pragma, but HotSpot provides valid macro to compiler. > I added stringop-truncation to it [2], and it would work each compilers. > > > Yasumasa > > > [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029580.html > [2] http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ > > > On 2019/10/11 21:51, David Holmes wrote: >> On 11/10/2019 10:47 pm, Christos Zoulas wrote: >>> At NetBSD we decided to change the Makefiles because we compile with both clang and gcc >>> and clang does not have those warnings and it complains about the pragmas. >> Compilers are supposed to ignore pragmas they don't understand. Complaining about an unknown pragma defeats the whole purpose of having pragmas. >> I suppose to prevent problems with clang we must disable the warning in the makefile. >> David >>> christos >>> >>>> On Oct 11, 2019, at 2:54 AM, David Holmes wrote: >>>> >>>> Yes I prefer: >>>> >>>> D. Use #pragma ... at the callsite to disable this particular diagnostic. >>>> >>>> over changing the makefiles. >>>> >>>> David >>>> >>>> On 11/10/2019 3:37 pm, Ioi Lam wrote: >>>>> For diagnosticArgument.cpp, I would prefer adding inline #pragma at only the sites affected (as suggested by David Holmes), with a comment about why this is necessary. >>>>> But if others decide to go with other solutions, that's fine with me, too, but please remember to add a comment :-) >>>>> Thanks >>>>> - Ioi >>>>> On 10/10/19 6:50 PM, Chris Plummer wrote: >>>>>> These solutions all have their merits and their warts, but we have to pick something. I'm ok with with A or C. For B I'd rather you instead used the #pragma at the warning site. If you go with (C), the review should go out to all of hotspot-dev and build-dev. >>>>>> >>>>>> Chris >>>>>> >>>>>> On 10/10/19 6:34 PM, Yasumasa Suenaga wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I want to get conclusion of this discussion. >>>>>>> >>>>>>> I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion >>>>>>> how we should fix diagnosticArgument.cpp . >>>>>>> >>>>>>> I think we can fix diagnosticArgument.cpp as following: >>>>>>> >>>>>>> >>>>>>> A. Use memcpy() >>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>>>>>> >>>>>>> B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk >>>>>>> This option will be added diagnosticArgument.cpp only. >>>>>>> >>>>>>> C. Set -Wno-stringop-truncation in globally >>>>>>> make/hotspot/lib/CompileJvm.gmk >>>>>>> >>>>>>> >>>>>>> I prefer to fix like A because it affects minimally. >>>>>>> Some issues might be found out by stringop-truncation in future. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>>>>>> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >>>>>>>>> >>>>>>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>>>>>> From JBS: >>>>>>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>>>>>>>>> 154 | strncpy(buf, str, len); >>>>>>>>>> | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>>>>>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >>>>>>>>> >>>>>>>>> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >>>>>>>>> >>>>>>>>>> recall another recent similar fix that was done by switching to using memcpy instead. >>>>>>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>>>>> >>>>>>>>> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >>>>>>>>> >>>>>>>>> #pragma GCC diagnostic push >>>>>>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>>>>>> >>>>>>>>> solution. >>>>>>>>> >>>>>>>>> YMMV. >>>>>>>> >>>>>>>> We've run into and discussed problems with -Wstringop-truncation >>>>>>>> before. (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>>>>>> relatively recent warning option (introduced in gcc8, and included in >>>>>>>> -Wall), and seems to have a considerable bug tail: >>>>>>>> >>>>>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>>>>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>>>>>> resolved associated bugs. >>>>>>>> >>>>>>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>>>>>> strcpy or memcpy. I've suggested in the past that we should turn off >>>>>>>> this warning while it is so buggy. >>>>>>>> >>>>>> >>>>>> >>> From suenaga at oss.nttdata.com Fri Oct 11 13:38:05 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 11 Oct 2019 22:38:05 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> Message-ID: <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> Hi, Christos commented to B-1. Thanks! clang defines __GNU_C__ , but stringop-truncation is not supported. So I updated Plan B-1. It works fine on my Fedora30 box. A. Use memcpy() http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ B-1. Use #pragma http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.02/ C. Set -Wno-stringop-truncation in globally http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ Of course I will push the change to submit repo before sending review request. Thanks, Yasumasa On 2019/10/11 15:55, Yasumasa Suenaga wrote: > Hi, > > Thanks for a lot advises! > > We have following solutions for this issue. > I'd like to send RFR again with much consented patch in early next week. > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B-1. Use #pragma > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ > > ? C. Set -Wno-stringop-truncation in globally > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ > > > If we fix with C, I will send RFR to hotspot-dev and build-dev. > Plan C also fixes other stringop-truncation problems such as JDK-8220074. > Thus it affects all of JDK code, but it would be useful if stringop-truncation > should be disabled in JDK build process. > > > Comments are welcome. > > Yasumasa > > > On 2019/10/11 10:34, Yasumasa Suenaga wrote: >> Hi, >> >> I want to get conclusion of this discussion. >> >> I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion >> how we should fix diagnosticArgument.cpp . >> >> I think we can fix diagnosticArgument.cpp as following: >> >> >> ?? A. Use memcpy() >> ??????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ?? B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk >> ??????? This option will be added diagnosticArgument.cpp only. >> >> ?? C. Set -Wno-stringop-truncation in globally >> ??????? make/hotspot/lib/CompileJvm.gmk >> >> >> I prefer to fix like A because it affects minimally. >> Some issues might be found out by stringop-truncation in future. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/10/11 5:54, Kim Barrett wrote: >>>> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >>>> >>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>> ?From JBS: >>>>> ? /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>>>> ?? 154 | strncpy(buf, str, len); >>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >>>> >>>> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >>>> >>>>> recall another recent similar fix that was done by switching to using memcpy instead. >>>>> Here's a discussion of interest, also suggesting memcpy: >>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>> >>>> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >>>> >>>> #pragma GCC diagnostic push >>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>> >>>> solution. >>>> >>>> YMMV. >>> >>> We've run into and discussed problems with -Wstringop-truncation >>> before.? (See discussions of JDK-8214777 and JDK-8223186.)? This is a >>> relatively recent warning option (introduced in gcc8, and included in >>> -Wall), and seems to have a considerable bug tail: >>> >>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>> resolved associated bugs. >>> >>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>> strcpy or memcpy.? I've suggested in the past that we should turn off >>> this warning while it is so buggy. >>> From martin.doerr at sap.com Fri Oct 11 15:53:36 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 11 Oct 2019 15:53:36 +0000 Subject: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 instructions on processors which don't support it In-Reply-To: <5ccebd52-0bff-75b3-c3e0-c201597b6943@oracle.com> References: <5ccebd52-0bff-75b3-c3e0-c201597b6943@oracle.com> Message-ID: Hi Tobias, the instructions introduced by JDK-8222074 are leading to the crash we're seing. But AddReductionVI uses phaddd which also belongs to SSSE3. So we should make these match rules unavailable for processors without SSSE3, too. I have never seen crashes due to AddReductionVI, but I guess we should backport the fix to 11u, too. Best regards, Martin > -----Original Message----- > From: Tobias Hartmann > Sent: Freitag, 11. Oktober 2019 10:25 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: Re: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 > instructions on processors which don't support it > > Hi Martin, > > so this was introduced by JDK-8222074, right? > > Just wondering, does AddReductionVI require SSSE3 as well? > > Thanks, > Tobias > > On 10.10.19 14:29, Doerr, Martin wrote: > > Hi, > > > > we have observed a JVM crash in JDK13u on an AMD Opteron machine. > > > > Instructions like pabsb/w/d, phaddd get emitted when SSE3 is available, > but are not supported without SSSE3. > > E.g. AMD Opteron(tm) Processor 2218 has SSE3, but not SSSE3. > > > > Should we fix it this way? > > http://cr.openjdk.java.net/~mdoerr/8232106_x86_ssse3/webrev.00/ > > > > Best regards, > > Martin > > From vladimir.kozlov at oracle.com Fri Oct 11 16:48:36 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 11 Oct 2019 09:48:36 -0700 Subject: RFR: 8232165: Reduce allocations in ValueStack copying constructor In-Reply-To: <5e1dd9d7-2ea1-1026-13f9-8da698b8a110@oracle.com> References: <5e1dd9d7-2ea1-1026-13f9-8da698b8a110@oracle.com> Message-ID: Looks good. thanks, Vladimir On 10/11/19 4:42 AM, Claes Redestad wrote: > Hi, > > this patch optimizes C1 ValueStack copying, which reduces unnecessary > allocations and has a small but measurable impact on compilation speed. > > Webrev: http://cr.openjdk.java.net/~redestad/8232165/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232165 > > Testing: tier1-2 (tier3-4 ongoing) > > Thanks! > > /Claes From igor.ignatyev at oracle.com Fri Oct 11 16:57:19 2019 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 11 Oct 2019 09:57:19 -0700 Subject: RFR(M) [14] : 8225654 : rework vmTestbase/jit/graph In-Reply-To: <8a58a3a0-edc5-be0a-2b2a-bd7a41e3e9dc@oracle.com> References: <3A418E88-2FBA-4253-A249-C30A6DC1C5CC@oracle.com> <86F0F16D-4170-4548-9E3B-84AEC0C7CEB4@oracle.com> <2F61AC46-EDFF-4A74-8CC7-95AEEBB1E565@oracle.com> <5e7bbf03-14c7-0c7d-5f69-d89da5d405a3@oracle.com> <9F47BF2F-C122-40B6-9BA5-86504AA0503F@oracle.com> <8a58a3a0-edc5-be0a-2b2a-bd7a41e3e9dc@oracle.com> Message-ID: Tobias, Nils thank you for your review. pushed. -- Igor > On Oct 11, 2019, at 1:16 AM, Tobias Hartmann wrote: > > Hi Igor, > > On 10.10.19 19:45, Igor Ignatyev wrote: >> can I get a second review? > > This looks good to me too. > > Best regards, > Tobias From chris.plummer at oracle.com Fri Oct 11 19:29:50 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 11 Oct 2019 12:29:50 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> Message-ID: Hi Yasumasa, A couple of comments on (B). First there is a typo in "stringop-truncatino". Second, can the macros be used just before and after the strncpy reference rather than around the whole function? It would clarify both that the strncpy use has these macros in place and that the macros are there for the strncpy. As it stands now, if you see the macro references it won't be readily obvious why they are there. As for which I prefer, I'm leaning towards (A) for it's simplicity. Yes, I understands Kim's reason for opposing it, but (B) and (C) are no better in that regard. In all cases we are doing something that should be completely unnecessary to work around a gcc bug. I could see preferring (C) if we are concerned about this issue popping up in other places. BTW, I had mentioned seeing another instance of this recently in a review I did: http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-September/029361.html I was thinking of pushing back on having to fix a perfectly valid strncpy, and like Kim was not that happy about having to switch it to a memcpy. I considered suggesting disabling the warning but decided that for this one issue bowing to memcpy was probably best, so I never brought it up. So following along on those same thoughts, for your fix memcpy might be acceptable (it's just "one" case if we ignore already fixed cases), but disabling the warning is probably best if we think this is going to be an issue that continues to pop up. thanks, Chris On 10/11/19 6:38 AM, Yasumasa Suenaga wrote: > Hi, > > Christos commented to B-1. Thanks! > clang defines __GNU_C__ , but stringop-truncation is not supported. > > So I updated Plan B-1. It works fine on my Fedora30 box. > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B-1. Use #pragma > http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.02/ > > ? C. Set -Wno-stringop-truncation in globally > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ > > > Of course I will push the change to submit repo before sending review > request. > > > Thanks, > > Yasumasa > > > On 2019/10/11 15:55, Yasumasa Suenaga wrote: >> Hi, >> >> Thanks for a lot advises! >> >> We have following solutions for this issue. >> I'd like to send RFR again with much consented patch in early next week. >> >> >> ?? A. Use memcpy() >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ?? B-1. Use #pragma >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ >> >> ?? C. Set -Wno-stringop-truncation in globally >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ >> >> >> If we fix with C, I will send RFR to hotspot-dev and build-dev. >> Plan C also fixes other stringop-truncation problems such as >> JDK-8220074. >> Thus it affects all of JDK code, but it would be useful if >> stringop-truncation >> should be disabled in JDK build process. >> >> >> Comments are welcome. >> >> Yasumasa >> >> >> On 2019/10/11 10:34, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I want to get conclusion of this discussion. >>> >>> I understand the fix of macroAssembler_x86.hpp is ok, but we have >>> not yet had conclusion >>> how we should fix diagnosticArgument.cpp . >>> >>> I think we can fix diagnosticArgument.cpp as following: >>> >>> >>> ?? A. Use memcpy() >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>> >>> ?? B. Add -Wno-stringop-truncation to >>> make/hotspot/lib/JvmOverrideFiles.gmk >>> ??????? This option will be added diagnosticArgument.cpp only. >>> >>> ?? C. Set -Wno-stringop-truncation in globally >>> ??????? make/hotspot/lib/CompileJvm.gmk >>> >>> >>> I prefer to fix like A because it affects minimally. >>> Some issues might be found out by stringop-truncation in future. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>> On Oct 10, 2019, at 3:03 AM, David Holmes >>>>> wrote: >>>>> >>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>> ?From JBS: >>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>>>> truncated before terminating nul copying as many bytes from a >>>>>> string as its length [-Wstringop-truncation] >>>>>> ?? 154 | strncpy(buf, str, len); >>>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>> I assume this means that in all cases the "len" value is seen to >>>>>> be derived from strlen, and therefore strncpy is always copying >>>>>> one byte short of \0, and this is most likely not what the user >>>>>> wants. I seem to >>>>> >>>>> Yes but we then explicitly set the NULL at buf[len] which is the >>>>> expected/required pattern for this. >>>>> >>>>>> recall another recent similar fix that was done by switching to >>>>>> using memcpy instead. >>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>> >>>>> >>>>> Seems to me that strncpy and memcpy are semantically equivalent >>>>> here so all this does is avoid gcc's over zealous warnings. I'm >>>>> inclined to use the: >>>>> >>>>> #pragma GCC diagnostic push >>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>> >>>>> solution. >>>>> >>>>> YMMV. >>>> >>>> We've run into and discussed problems with -Wstringop-truncation >>>> before.? (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>> relatively recent warning option (introduced in gcc8, and included in >>>> -Wall), and seems to have a considerable bug tail: >>>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>> resolved associated bugs. >>>> >>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>> this warning while it is so buggy. >>>> From kim.barrett at oracle.com Fri Oct 11 22:18:06 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Oct 2019 18:18:06 -0400 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> Message-ID: > On Oct 11, 2019, at 3:29 PM, Chris Plummer wrote: > > Hi Yasumasa, > > A couple of comments on (B). First there is a typo in "stringop-truncatino". Second, can the macros be used just before and after the strncpy reference rather than around the whole function? It would clarify both that the strncpy use has these macros in place and that the macros are there for the strncpy. As it stands now, if you see the macro references it won't be readily obvious why they are there. > > As for which I prefer, I'm leaning towards (A) for it's simplicity. Yes, I understands Kim's reason for opposing it, but (B) and (C) are no better in that regard. In all cases we are doing something that should be completely unnecessary to work around a gcc bug. I could see preferring (C) if we are concerned about this issue popping up in other places. > > BTW, I had mentioned seeing another instance of this recently in a review I did: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-September/029361.html > > I was thinking of pushing back on having to fix a perfectly valid strncpy, and like Kim was not that happy about having to switch it to a memcpy. I considered suggesting disabling the warning but decided that for this one issue bowing to memcpy was probably best, so I never brought it up. So following along on those same thoughts, for your fix memcpy might be acceptable (it's just "one" case if we ignore already fixed cases), but disabling the warning is probably best if we think this is going to be an issue that continues to pop up. Right now it seems to me that -Wstringop-truncation is seriously buggy, both in the false positive and false negative directions. This seems to be true at least through 9.x for some recent x. And all of the occurrences of this warning in our code that I've heard of have been false positives. So I think this warning is not carrying its weight, and I'd be okay with globally disabling it for now, pending improvements in its implementation. I'd also be okay with the local pragma-based suppression approach. I strongly dislike substituting memcpy. When taking the #pragma approach, the need to conditionalize for clang points out that we currently treat clang as equivalent to gcc at that level. That probably ought to change, but that's a separate issue. Since these strncpy vs -Wstringop-truncation problems seem to be cropping up periodically, I suggest we add and use os::strncpy_s, modelled on the C11 function of that name. Doing so should be a separate followup issue. From kim.barrett at oracle.com Fri Oct 11 22:30:04 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Oct 2019 18:30:04 -0400 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> Message-ID: > On Oct 11, 2019, at 3:29 PM, Chris Plummer wrote: > Second, can the macros be used just before and after the strncpy reference rather than around the whole function? It would clarify both that the strncpy use has these macros in place and that the macros are there for the strncpy. As it stands now, if you see the macro references it won't be readily obvious why they are there. +1, unless there?s some reason that doesn?t work. The scoping rules for pragmas are not standardized (because pragmas aren?t), and the gcc documentation is rather thin. From kim.barrett at oracle.com Fri Oct 11 23:04:37 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Oct 2019 19:04:37 -0400 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> Message-ID: > On Oct 11, 2019, at 6:18 PM, Kim Barrett wrote: > Right now it seems to me that -Wstringop-truncation is seriously > buggy, both in the false positive and false negative directions. This > seems to be true at least through 9.x for some recent x. And all of > the occurrences of this warning in our code that I've heard of have > been false positives. So I think this warning is not carrying its > weight, and I'd be okay with globally disabling it for now, pending > improvements in its implementation. It was pointed out to me that there have been some actual bugs in our code detected by this warning, so I?m withdrawing my support for turning off the warning completely. From vladimir.x.ivanov at oracle.com Sat Oct 12 00:41:12 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 11 Oct 2019 17:41:12 -0700 Subject: 8230015: [instruction selector] generic vector operands support. In-Reply-To: References: Message-ID: <0868bad5-c573-362f-0ff6-4a4332d95ecb@oracle.com> Hi Jatin, FTR I'm looking at: http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.03/ Good work, Jatin. The reduction in number of instructions looks impressive. Also, it's nice to see excessive vec? <-> legVec? moves being eliminated. High-level comments on the patch: - Please, separate the patch in 2 changes: generic vector type support and AD instruction unification. It would significantly simplify review. - Try to avoid x86-specific changes (#ifdefs) in shared files. I'm still looking through the implementation, but here are the bugs in AD unification spotted so far: ==================================================================== src/hotspot/cpu/x86/x86_64.ad: +operand vecG() %{ + constraint(ALLOC_IN_RC(vectorg_reg)); +operand legVecG() %{ + constraint(ALLOC_IN_RC(vectorg_reg)); legVecG definition shouldn't be equivalent to vecG: on AVX512-capable host legVecG should never include zmm16-zmm31 while vecG can. ==================================================================== src/hotspot/cpu/x86/x86.ad: +instruct ReplF_zero_avx(vecG dst, immF0 zero) %{ + predicate(UseAVX < 3 && UseAVX > 0 check is missing (same with ReplD_zero_avx). ==================================================================== +instruct vaddB_mem(vecG dst, vecG src, memory mem) %{ + predicate(UseAVX && (UseAVX <= 2 || VM_Version::supports_avx512bw()) && + n->as_Vector()->length() >= 4 && n->as_Vector()->length() <= 64); It doesn't match the following case anymore: UseAVX == 3 && VM_Version::supports_avx512bw() == false && n->as_Vector()->length() < 64 // smaller than 512bit There are other AD instructions (with VMVersion::supports_avx512bw() check) which are affected the same way. Best regards, Vladimir Ivanov On 22/08/2019 09:49, Bhateja, Jatin wrote: > Hi All, > > Please find below a patch for generic vector operands[1] support during > instruction selection. > > Motivation behind the patch is to reduce the number of vector selection > patterns whose operands meagerly differ in vector lengths. > > This will not only result in lesser code being generated by ADLC which > effectively translates to size reduction in libjvm.so but also > > help in better maintenance of AD files. > > Using generic operands we were able to collapse multiple vector patterns > over mainline > > ?????? ??????Initial number of vector instruction patterns (vec[XYZSD] > + legVec[ZXYSD] ? : *510* > > ?????????????Reduced vector instruction patterns? (vecG + > legVecG)?????? ?????????????? ? ? ? ? ? ? : *222* > > ** > > With this we could see around 1MB size reduction in libjvm.so. > > In order to have minimal impact over downstream compiler passes, a > post-selection pass has been introduced (currently enabled only for X86 > target) > > which replaces these generic operands with their corresponding concreter > vector length variants. > > JBS?? ???: https://bugs.openjdk.java.net/browse/JDK-8230015 > > Patch ?: > http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/webrev.00/ > > Kindly review and share your feedback. > > Best Regards, > > Jatin Bhateja > > [1] > http://cr.openjdk.java.net/~jbhateja/genericVectorOperands/generic_operands_support_v1.0.pdf > From vladimir.x.ivanov at oracle.com Sat Oct 12 01:26:36 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 11 Oct 2019 18:26:36 -0700 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> Message-ID: <002c7bcf-97cd-e4ef-400c-b40ef812a99e@oracle.com> I agree that GraphKit as a ctor argument looks weird. What about having a static factory and encapsulate the code there instead? convertnode.hpp: RoundDoubleModeNode(Node* in1, ConINode* rmode): Node(0, in1, rmode) {} static RoundDoubleModeNode make(Compile* C, Node* arg, RoundDoubleModeNode::RoundingMode rmode); convertnode.cpp: RoundDoubleModeNode* RoundDoubleModeNode::make(Compile* C, Node* arg, RoundDoubleModeNode::RoundingMode rmode) { ConINode* rm = C->initial_gvn()->intcon(rmode); return new RoundDoubleModeNode(arg, rm); } library_call.cpp: case vmIntrinsics::_ceil: n = RoundDoubleModeNode::make(C, arg, RoundDoubleModeNode::rmode_ceil); Best regards, Vladimir Ivanov On 09/10/2019 12:29, Doerr, Martin wrote: > Hi Vladimir and Michihiro, > >> ConINode::make() allocates a new node which has to be seen by GVN, so >> there's a type recorded for it. > Makes sense. > > I'd prefer > RoundDoubleModeNode(Node *in1, Node *rmode): Node(0, in1, rmode) {} > > and > case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(RoundDoubleModeNode::rmode_floor))); break; > case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, makecon(TypeInt::make(RoundDoubleModeNode::rmode_rint))); break; > > That avoids additional includes in convertnode.hpp which can easily lead to cyclic dependencies for future changes. > > Best regards, > Martin > > >> -----Original Message----- >> From: Vladimir Ivanov >> Sent: Dienstag, 8. Oktober 2019 12:31 >> To: Doerr, Martin ; Michihiro Horie >> >> Cc: hotspot compiler ; ppc-aix- >> port-dev at openjdk.java.net >> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power >> >> >> >> On 08/10/2019 13:14, Doerr, Martin wrote: >>> Hi Vladimir and Michihiro, >>> >>> I like webrev.04 more than webrev.05. >>> I think it's not good to include graphKit.hpp in convertnode.hpp. This >> creates a weird dependency. >>> What was the reason for this change? >> >> webrev.04 has a bug. Quote from earlier email: >> >> "src/hotspot/share/opto/convertnode.hpp: >> >> + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, >> ConINode::make(rmode)) {} >> >> ConINode::make() allocates a new node which has to be seen by GVN, so >> there's a type recorded for it. That's why I mentioned GraphKit*. But >> you can use PhaseGVN & intcon as well." >> >> Alternatively, Compile* can be used as well. >> >> Best regards, >> Vladimir Ivanov >> >>>> -----Original Message----- >>>> From: Vladimir Ivanov >>>> Sent: Dienstag, 8. Oktober 2019 11:47 >>>> To: Michihiro Horie >>>> Cc: hotspot compiler ; Doerr, >>>> Martin ; ppc-aix-port-dev at openjdk.java.net >>>> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on >> Power >>>> >>>> >>>>> http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/ >>>> >>>> Looks good. >>>> >>>> (Test results are clean.) >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>>> > I think it would be better to use adlc?s include generator instead of >>>>> > including "opto/convertnode.hpp" explicitly in the ad file. >>>>> > >>>>> > src/hotspot/share/adlc/main.cpp >>>>> > >>>>> > ??? AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); >>>>> > >>>>> > +? AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); >>>>> > >>>>> > ??? AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); >>>>> > >>>>> > @Vladimir: Do you agree? Would you do it this way, too? >>>>> >>>>> I prefer current version. >>>>> >>>>> When proposing the refactoring I thought about the change in adlc as >>>>> well, but when I saw the patch I noticed that putting it in AD file >>>>> stresses it's a platform-specific dependency. >>>>> >>>>> I think that's the right way to look at it until we get a way to funnel >>>>> attributes from ideal nodes to mach nodes and use them during code >>>>> emission. >>>>> >>>>> Best regards, >>>>> Vladimir Ivanov >>>>> >>>>> > *From:*Michihiro Horie >>>>> > *Sent:* Montag, 7. Oktober 2019 17:54 >>>>> > *To:* Vladimir Ivanov >>>>> > *Cc:* hotspot compiler ; >>>> Doerr, >>>>> > Martin ; ppc-aix-port- >> dev at openjdk.java.net >>>>> > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, >>>>> > rint on Power >>>>> > >>>>> > Hi Martin, Vladimir, >>>>> > Thanks a lot for your further feedback, which makes sense. >>>>> > >>>>> > New webrev: >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ >>>>> > >>>>> > Best regards, >>>>> > Michihiro >>>>> > >>>>> > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> >>>>> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov >>>>> > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, >> Michihiro. >>>>> > >>>>> > From: Vladimir Ivanov >>>> > > >>>>> > To: Michihiro Horie > >, >>>>> > "Doerr, Martin" >>> > >>>>> > Cc: hotspot compiler >>>> > >, >>>>> > "ppc-aix-port-dev at openjdk.java.net >>>>> > " >>>>> > >>>> > > >>>>> > Date: 2019/10/07 22:51 >>>>> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, >>>>> > floor, rint on Power >>>>> > >>>>> > ------------------------------------------------------------------------ >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> >> Fixed webrev is as follows. >>>>> > >>>>> > Thanks, Michihiro. >>>>> > >>>>> >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ >>>>> > >>>>> > src/hotspot/share/opto/convertnode.hpp: >>>>> > >>>>> > + ?enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; >>>>> > >>>>> > Please, explicitly initialize the elements. Numbering is important since >>>>> > it is aligned with instruction encoding on x86. >>>>> > >>>>> > >>>>> > src/hotspot/share/opto/library_call.cpp: >>>>> > >>>>> > + ?case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, >>>>> > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); >>>> break; >>>>> > >>>>> > Please, change RoundDoubleModeNode to accept the enum instead >> and >>>>> > instantiate the ConI node inside it or introduce a static factory >>>>> > (::make(GraphKit*,RoundingMode)) for that purpose. >>>>> > >>>>> > >>>>> > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: >>>>> > >>>>> > + ?void math_round(const FloatRegister t, const FloatRegister b, int >>>>> rmode); >>>>> > + ?void math_round_vec(const VectorSRegister t, const >> VectorSRegister >>>> b, >>>>> > int rmode); >>>>> > >>>>> > I suggest to get rid of helpers in MacroAssembler and simply move >> the >>>>> > code into corresponding AD instructions. >>>>> > >>>>> > Best regards, >>>>> > Vladimir Ivanov >>>>> > >>>>> >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15---> I >>>>> >> suggest to put the enum in RoundDoubleModeNode >> (convertn"Doerr, >>>> Martin" >>>>> >> ---2019/10/07 22:09:15---> I suggest to put the enum in >>>>> >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction >>>> selectio >>>>> >> >>>>> >> From: "Doerr, Martin" >>>> > >>>>> >> To: Vladimir Ivanov >>>> >, >>>>> > Michihiro Horie >>>>> >> > >>>>> >> Cc: hotspot compiler >>>> > >, >>>>> >> "ppc-aix-port-dev at openjdk.java.net >>>>> > " >>>>> > >>>> > > >>>>> >> Date: 2019/10/07 22:09 >>>>> >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for >> Math.ceil, >>>>> >> floor, rint on Power >>>>> >> >>>>> >> ------------------------------------------------------------------------ >>>>> >> >>>>> >> >>>>> >> >>>>> >> ?> I suggest to put the enum in RoundDoubleModeNode >>>> (convertnode.hpp) >>>>> >> ?> and lift instruction selection logic from macroAssembler_ppc.cpp >>>>> into >>>>> >> ppc.ad. >>>>> >> That sounds good. >>>>> >> >>>>> >> Thanks, >>>>> >> Martin >>>>> >> >>>>> >> >>>>> >> ?> -----Original Message----- >>>>> >> ?> From: Vladimir Ivanov >>>> > >>>>> >> ?> Sent: Montag, 7. Oktober 2019 12:55 >>>>> >> ?> To: Doerr, Martin >>>> >; Michihiro Horie >>>>> >> ?> > >>>>> >> ?> Cc: hotspot compiler >>>> > >; ppc-aix- >>>>> >> ?> port-dev at openjdk.java.net > dev at openjdk.java.net> >>>>> >> ?> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, >>>>> >> rint on Power >>>>> >> ?> >>>>> >> ?> > I think sharedRuntime is not a good place for the C2 enum. >>>>> >> ?> Agree. >>>>> >> ?> >>>>> >> ?> I suggest to put the enum in RoundDoubleModeNode >>>> (convertnode.hpp) >>>>> >> ?> and >>>>> >> ?> lift instruction selection logic from macroAssembler_ppc.cpp into >>>>> ppc.ad. >>>>> >> ?> >>>>> >> ?> Best regards, >>>>> >> ?> Vladimir Ivanov >>>>> >> ?> >>>>> >> ?> > >>>>> >> ?> > Maybe intrinsicnode.hpp would be a better pace for it. But >>>>> then, the >>>>> >> ?> > code in macroAssembler should be guarded by #ifdef >> COMPILER2. >>>>> >> ?> > >>>>> >> ?> > Best regards, >>>>> >> ?> > >>>>> >> ?> > Martin >>>>> >> ?> > >>>>> >> ?> > *From:*Michihiro Horie >>> > >>>>> >> ?> > *Sent:* Montag, 7. Oktober 2019 09:14 >>>>> >> ?> > *To:* Vladimir Ivanov >>>> > >>>>> >> ?> > *Cc:* hotspot compiler > dev at openjdk.java.net >>>>> > >; >>>>> >> ?> > ppc-aix-port-dev at openjdk.java.net >>>>> > ; Doerr, Martin >>>>> >> ?> > >>>>> >> ?> > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, >>>>> floor, >>>>> >> ?> > rint on Power >>>>> >> ?> > >>>>> >> ?> > Hi Vladimir, >>>>> >> ?> > >>>>> >> ?> > Thanks a lot for your nice suggestion. Yes, I prefer enum use. >>>>> >> ?> > I'm wondering if the enum constants can be declared in >>>>> >> ?> sharedRuntime.hpp. >>>>> >> ?> > Webrev: >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ >>>>> >> ?> > >>>>> >> ?> > Best regards, >>>>> >> ?> > Michihiro >>>>> >> ?> > >>>>> >> ?> > Inactive hide details for Vladimir Ivanov ---2019/10/04 >>>>> 23:05:48---Hi >>>>> >> ?> > Michihiro, >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir >>>>> Ivanov >>>>> >> ?> > ---2019/10/04 23:05:48---Hi Michihiro, >>>>> >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: >>>>> >> ?> > >>>>> >> ?> > From: Vladimir Ivanov >>>> > > ?> > >>>>> > > >>>>> >> ?> > To: Michihiro Horie >>> >, >>>>> >> ?> > ppc-aix-port-dev at openjdk.java.net >>>>> >>>>> >> ?> > , hotspot compiler >>>>> >> ?> > >>>> > > ?> > >>>>> > > >>>>> >> ?> > Date: 2019/10/04 23:05 >>>>> >> ?> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for >>>>> Math.ceil, >>>>> >> ?> > floor, rint on Power >>>>> >> ?> > >>>>> >> ?> > >>>>> >> ------------------------------------------------------------------------ >>>>> >> ?> > >>>>> >> ?> > >>>>> >> ?> > >>>>> >> ?> > >>>>> >> ?> > Hi Michihiro, >>>>> >> ?> > >>>>> >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: >>>>> >> ?> > + ?switch (rmode) { >>>>> >> ?> > + ? ?case 0: // rint >>>>> >> ?> > + ? ? ?frin(t, b); >>>>> >> ?> > + ? ? ?break; >>>>> >> ?> > + ? ?case 1: // floor >>>>> >> ?> > + ? ? ?frim(t, b); >>>>> >> ?> > + ? ? ?break; >>>>> >> ?> > + ? ?case 2: // ceil >>>>> >> ?> > + ? ? ?frip(t, b); >>>>> >> ?> > + ? ? ?break; >>>>> >> ?> > + ? ?default: >>>>> >> ?> > + ? ? ?ShouldNotReachHere(); >>>>> >> ?> > + ?} >>>>> >> ?> > >>>>> >> ?> > What do you think about introducing enum constants instead of >>>> using >>>>> >> ?> > hard-coded 0/1/2? >>>>> >> ?> > >>>>> >> ?> > src/hotspot/share/opto/library_call.cpp: >>>>> >> ?> > >>>>> >> ?> > ?? case vmIntrinsics::_ceil: ? n = new >> RoundDoubleModeNode(arg, >>>>> >> ?> > makecon(TypeInt::make(2))); break; >>>>> >> ?> > ?? case vmIntrinsics::_floor: ?n = new >> RoundDoubleModeNode(arg, >>>>> >> ?> > makecon(TypeInt::make(1))); break; >>>>> >> ?> > ?? case vmIntrinsics::_rint: ? n = new >> RoundDoubleModeNode(arg, >>>>> >> ?> > makecon(TypeInt::make(0))); break; >>>>> >> ?> > >>>>> >> ?> > The downside is you have to move the switch from >>>> macroAssembler >>>>> >> ?> because >>>>> >> ?> > enum should be visible from both places. (Is there a better >>>>> place for >>>>> >> ?> > that than roundD_regNode::emit() in AD file?) >>>>> >> ?> > >>>>> >> ?> > Best regards, >>>>> >> ?> > Vladimir Ivanov >>>>> >> ?> > >>>>> >> ?> > On 02/10/2019 07:27, Michihiro Horie wrote: >>>>> >> ?> >> >>>>> >> ?> >> Dear all, >>>>> >> ?> >> >>>>> >> ?> >> Would you please review the following change? >>>>> >> ?> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 >>>>> >> ?> >> Webrev: >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 >>>>> >> ?> >> >>>>> >> ?> >> This change adds intrinsics for Math's ceil, floor, and rint for >>>>> >> PPC64, on >>>>> >> ?> >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. >>>>> >> ?> >> >>>>> >> ?> >> Best regards, >>>>> >> ?> >> Michihiro >>>>> >> ?> >> >>>>> >> ?> > >>>>> >> ?> > >>>>> >> ?> > >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> > >>>>> > >>>>> > >>>>> >>>>> >>>>> >>>>> From felix.yang at huawei.com Sat Oct 12 01:58:55 2019 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sat, 12 Oct 2019 01:58:55 +0000 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop In-Reply-To: <3098cce0-bf26-9bba-554e-7e5b66930371@oracle.com> References: <041e13e4-a860-0523-c01d-f7d8d40230e4@oracle.com> <3098cce0-bf26-9bba-554e-7e5b66930371@oracle.com> Message-ID: >> Hi Felix, > > On 11.10.19 02:45, Yangfei (Felix) wrote: > > Updated webrev: http://cr.openjdk.java.net/~fyang/8231988/webrev.01/ > > If possible, tests should have a name that describes their purpose and should > be put into one of the corresponding folders. In this case, I would suggest > TestRemoveEmptyLoop and put it into compiler/loopopts/. > Hi Tobias, That sounds good. Updated webrev: http://cr.openjdk.java.net/~fyang/8231988/webrev.02/ Newly added test pass on aarch64 & x64 platform. Is it OK? Thanks, Felix From suenaga at oss.nttdata.com Sat Oct 12 02:56:30 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Sat, 12 Oct 2019 11:56:30 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> Message-ID: On 2019/10/12 7:30, Kim Barrett wrote: >> On Oct 11, 2019, at 3:29 PM, Chris Plummer wrote: >> Second, can the macros be used just before and after the strncpy reference rather than around the whole function? It would clarify both that the strncpy use has these macros in place and that the macros are there for the strncpy. As it stands now, if you see the macro references it won't be readily obvious why they are there. > > +1, unless there?s some reason that doesn?t work. > > The scoping rules for pragmas are not standardized (because pragmas aren?t), and the gcc documentation is rather thin. I recently saw similar issue in HeapStats [1] as below: ``` logManager.cpp:1439: error: #pragma GCC diagnostic not allowed inside functions ``` Thus I set #pragma around the function. CentOS 6 which issue is seen has GCC 4.4.7, but this issue is gone on CentOS 7 which has GCC 4.8.5 . So I will set #pragma around strncpy() instead of around the function. Yasumasa [1] https://github.com/HeapStats/heapstats/pull/149 From suenaga at oss.nttdata.com Sat Oct 12 03:22:53 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Sat, 12 Oct 2019 12:22:53 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> Message-ID: <2ce989bb-e802-e427-d960-4976b4664c63@oss.nttdata.com> Hi, I updated Plan B-1 (#pragma) due to the comment from Chris [1]. A. Use memcpy() http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ B-1. Use #pragma http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.03/ I dropped Plan C (disable stringop-truncation in globally) from the solutions because Kim pointed this warning found out some actual bugs [2]. Thanks, Yasumasa [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029586.html [2] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029590.html On 2019/10/11 22:38, Yasumasa Suenaga wrote: > Hi, > > Christos commented to B-1. Thanks! > clang defines __GNU_C__ , but stringop-truncation is not supported. > > So I updated Plan B-1. It works fine on my Fedora30 box. > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B-1. Use #pragma > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.02/ > > ? C. Set -Wno-stringop-truncation in globally > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ > > > Of course I will push the change to submit repo before sending review request. > > > Thanks, > > Yasumasa > > > On 2019/10/11 15:55, Yasumasa Suenaga wrote: >> Hi, >> >> Thanks for a lot advises! >> >> We have following solutions for this issue. >> I'd like to send RFR again with much consented patch in early next week. >> >> >> ?? A. Use memcpy() >> ??????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ?? B-1. Use #pragma >> ??????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ >> >> ?? C. Set -Wno-stringop-truncation in globally >> ??????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ >> >> >> If we fix with C, I will send RFR to hotspot-dev and build-dev. >> Plan C also fixes other stringop-truncation problems such as JDK-8220074. >> Thus it affects all of JDK code, but it would be useful if stringop-truncation >> should be disabled in JDK build process. >> >> >> Comments are welcome. >> >> Yasumasa >> >> >> On 2019/10/11 10:34, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I want to get conclusion of this discussion. >>> >>> I understand the fix of macroAssembler_x86.hpp is ok, but we have not yet had conclusion >>> how we should fix diagnosticArgument.cpp . >>> >>> I think we can fix diagnosticArgument.cpp as following: >>> >>> >>> ?? A. Use memcpy() >>> ??????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>> >>> ?? B. Add -Wno-stringop-truncation to make/hotspot/lib/JvmOverrideFiles.gmk >>> ??????? This option will be added diagnosticArgument.cpp only. >>> >>> ?? C. Set -Wno-stringop-truncation in globally >>> ??????? make/hotspot/lib/CompileJvm.gmk >>> >>> >>> I prefer to fix like A because it affects minimally. >>> Some issues might be found out by stringop-truncation in future. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>> On Oct 10, 2019, at 3:03 AM, David Holmes wrote: >>>>> >>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>> ?From JBS: >>>>>> ? /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: warning: 'char* strncpy(char*, const char*, size_t)' output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] >>>>>> ?? 154 | strncpy(buf, str, len); >>>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>> I assume this means that in all cases the "len" value is seen to be derived from strlen, and therefore strncpy is always copying one byte short of \0, and this is most likely not what the user wants. I seem to >>>>> >>>>> Yes but we then explicitly set the NULL at buf[len] which is the expected/required pattern for this. >>>>> >>>>>> recall another recent similar fix that was done by switching to using memcpy instead. >>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>> >>>>> Seems to me that strncpy and memcpy are semantically equivalent here so all this does is avoid gcc's over zealous warnings. I'm inclined to use the: >>>>> >>>>> #pragma GCC diagnostic push >>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>> >>>>> solution. >>>>> >>>>> YMMV. >>>> >>>> We've run into and discussed problems with -Wstringop-truncation >>>> before.? (See discussions of JDK-8214777 and JDK-8223186.)? This is a >>>> relatively recent warning option (introduced in gcc8, and included in >>>> -Wall), and seems to have a considerable bug tail: >>>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>> resolved associated bugs. >>>> >>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>> this warning while it is so buggy. >>>> From chris.plummer at oracle.com Sat Oct 12 03:31:09 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Fri, 11 Oct 2019 20:31:09 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <2ce989bb-e802-e427-d960-4976b4664c63@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> <2ce989bb-e802-e427-d960-4976b4664c63@oss.nttdata.com> Message-ID: They both look good to me, so I assume we go with B-1 since that's what Kim prefers. thanks, Chris On 10/11/19 8:22 PM, Yasumasa Suenaga wrote: > Hi, > > I updated Plan B-1 (#pragma) due to the comment from Chris [1]. > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B-1. Use #pragma > http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.03/ > > > I dropped Plan C (disable stringop-truncation in globally) from the > solutions > because Kim pointed this warning found out some actual bugs [2]. > > > Thanks, > > Yasumasa > > > [1] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029586.html > [2] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029590.html > > > On 2019/10/11 22:38, Yasumasa Suenaga wrote: >> Hi, >> >> Christos commented to B-1. Thanks! >> clang defines __GNU_C__ , but stringop-truncation is not supported. >> >> So I updated Plan B-1. It works fine on my Fedora30 box. >> >> >> ?? A. Use memcpy() >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ?? B-1. Use #pragma >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.02/ >> >> ?? C. Set -Wno-stringop-truncation in globally >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ >> >> >> Of course I will push the change to submit repo before sending review >> request. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/10/11 15:55, Yasumasa Suenaga wrote: >>> Hi, >>> >>> Thanks for a lot advises! >>> >>> We have following solutions for this issue. >>> I'd like to send RFR again with much consented patch in early next >>> week. >>> >>> >>> ?? A. Use memcpy() >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>> >>> ?? B-1. Use #pragma >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ >>> >>> ?? C. Set -Wno-stringop-truncation in globally >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ >>> >>> >>> If we fix with C, I will send RFR to hotspot-dev and build-dev. >>> Plan C also fixes other stringop-truncation problems such as >>> JDK-8220074. >>> Thus it affects all of JDK code, but it would be useful if >>> stringop-truncation >>> should be disabled in JDK build process. >>> >>> >>> Comments are welcome. >>> >>> Yasumasa >>> >>> >>> On 2019/10/11 10:34, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>> I want to get conclusion of this discussion. >>>> >>>> I understand the fix of macroAssembler_x86.hpp is ok, but we have >>>> not yet had conclusion >>>> how we should fix diagnosticArgument.cpp . >>>> >>>> I think we can fix diagnosticArgument.cpp as following: >>>> >>>> >>>> ?? A. Use memcpy() >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>>> >>>> ?? B. Add -Wno-stringop-truncation to >>>> make/hotspot/lib/JvmOverrideFiles.gmk >>>> ??????? This option will be added diagnosticArgument.cpp only. >>>> >>>> ?? C. Set -Wno-stringop-truncation in globally >>>> ??????? make/hotspot/lib/CompileJvm.gmk >>>> >>>> >>>> I prefer to fix like A because it affects minimally. >>>> Some issues might be found out by stringop-truncation in future. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>>> On Oct 10, 2019, at 3:03 AM, David Holmes >>>>>> wrote: >>>>>> >>>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>>> ?From JBS: >>>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>>>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>>>>> truncated before terminating nul copying as many bytes from a >>>>>>> string as its length [-Wstringop-truncation] >>>>>>> ?? 154 | strncpy(buf, str, len); >>>>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>>> I assume this means that in all cases the "len" value is seen to >>>>>>> be derived from strlen, and therefore strncpy is always copying >>>>>>> one byte short of \0, and this is most likely not what the user >>>>>>> wants. I seem to >>>>>> >>>>>> Yes but we then explicitly set the NULL at buf[len] which is the >>>>>> expected/required pattern for this. >>>>>> >>>>>>> recall another recent similar fix that was done by switching to >>>>>>> using memcpy instead. >>>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>>> >>>>>> >>>>>> Seems to me that strncpy and memcpy are semantically equivalent >>>>>> here so all this does is avoid gcc's over zealous warnings. I'm >>>>>> inclined to use the: >>>>>> >>>>>> #pragma GCC diagnostic push >>>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>>> >>>>>> solution. >>>>>> >>>>>> YMMV. >>>>> >>>>> We've run into and discussed problems with -Wstringop-truncation >>>>> before.? (See discussions of JDK-8214777 and JDK-8223186.)? This is a >>>>> relatively recent warning option (introduced in gcc8, and included in >>>>> -Wall), and seems to have a considerable bug tail: >>>>> >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>>> resolved associated bugs. >>>>> >>>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>>> this warning while it is so buggy. >>>>> From dean.long at oracle.com Sat Oct 12 04:12:57 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 11 Oct 2019 21:12:57 -0700 Subject: RFR: 8231754: [JVMCI] Make r27 unconditionally reserved in JVMCI In-Reply-To: References: <64ebe6c9-9313-9ac9-5117-c1f6073c4b8f@oracle.com> <981363ff-62a0-6be1-93f5-f4661d82a6fc@redhat.com> Message-ID: <4b4fb481-541c-ad35-d247-d3f838da0f0e@oracle.com> On 10/11/19 2:41 AM, Andrew Dinn wrote: > Hi Gilles, > > On 11/10/2019 09:47, Gilles Duboscq wrote: >> By "other compilers" i meant C1 and C2. Neither of those compilers ever >> allocates r27. > Ah, my apologies. I thought Roman Kennke investigated and pushed a patch > for this optimization earlier in the year. Clearly, that experiment > never escaped from the lab. I was thinking the same, but when I checked, it was only for x64: JDK-8217909. > In which case, I'm happy for Yudi's patch to go ahead as is. Me too. dl > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From kim.barrett at oracle.com Sat Oct 12 04:32:03 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 11 Oct 2019 21:32:03 -0700 (PDT) Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <2ce989bb-e802-e427-d960-4976b4664c63@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> <2ce989bb-e802-e427-d960-4976b4664c63@oss.nttdata.com> Message-ID: > On Oct 11, 2019, at 11:22 PM, Yasumasa Suenaga wrote: > > Hi, > > I updated Plan B-1 (#pragma) due to the comment from Chris [1]. > > > A. Use memcpy() > http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > B-1. Use #pragma > http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.03/ > > > I dropped Plan C (disable stringop-truncation in globally) from the solutions > because Kim pointed this warning found out some actual bugs [2]. Option B1 looks okay to me. I don't think the second line of the comment: 156 // So we avoid it via PRAGMA_STRINGOP_TRUNCATION_IGNORED macro. adds any information and just adds to clutter, given that the pragma is now right there. From my POV, remove or don't, as you prefer. From igor.veresov at oracle.com Sun Oct 13 16:51:37 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Sun, 13 Oct 2019 09:51:37 -0700 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> Message-ID: <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> Ok, I followed the notation you proposed, here?s the webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.01/ igor > On Oct 10, 2019, at 3:48 AM, Andrew Dinn wrote: > > On 10/10/2019 10:39, Claes Redestad wrote: >> How about: >> >> -XX:CompilationMode= >> >> enum := default|tiered|quickOnly|highOnly|highOnlyQuickInternal|... >> >> quickOnly => "TieredStopAtLevel=1" >> highOnly => "-TieredCompilation for all" >> highOnlyQuickInternal => -TieredCompilation with C1 for graal" >> >> I think this makes it clearer, and also easier to extend[1]. > > Agreed. > >> I'm less enthused by the ability to manually pick threshold levels >> - that we at all expose and thus lock us to what tier levels >> exists feels like a mistake - and think we should move all such flag to >> diagnostic, be wary of adding any more and take bigger liberties with >> changing them as we see fit ergonomically. > > Also agreed. > >> $.02 > Krrching! $.04! > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From fujie at loongson.cn Mon Oct 14 06:35:30 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 14 Oct 2019 14:35:30 +0800 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> Message-ID: <17aa1a3a-6129-73e0-c374-902f31cd1300@loongson.cn> Forward this to Tom. Thanks. On 2019/10/11 ??8:07, Jie Fu wrote: > Hi all, > > JDK-8232151 had been fixed. > > Could you please review this fix and give me some advice? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232083 > Webrev: http://cr.openjdk.java.net/~jiefu/8232083/webrev.00/ > > Thanks a lot. > Best regards, > Jie > > On 2019/10/11 ??11:42, Jie Fu wrote: >> Please hold off reviewing this until JDK-8232151 >> is fixed. > From martin.doerr at sap.com Mon Oct 14 08:27:08 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Oct 2019 08:27:08 +0000 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: <002c7bcf-97cd-e4ef-400c-b40ef812a99e@oracle.com> References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> <002c7bcf-97cd-e4ef-400c-b40ef812a99e@oracle.com> Message-ID: Hi Vladimir, that looks much better. Thank you. Alternatively, the PhaseGVN could get passed instead of the Compile pointer. (Prototype is already included via node.hpp.) This is already used by some other nodes like LoadNode::make(PhaseGVN& gvn, ... So this seems to be a common pattern. Best regards, Martin > -----Original Message----- > From: Vladimir Ivanov > Sent: Samstag, 12. Oktober 2019 03:27 > To: Doerr, Martin ; Michihiro Horie > > Cc: hotspot compiler ; ppc-aix- > port-dev at openjdk.java.net > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > > I agree that GraphKit as a ctor argument looks weird. > > What about having a static factory and encapsulate the code there instead? > > convertnode.hpp: > > RoundDoubleModeNode(Node* in1, ConINode* rmode): Node(0, in1, > rmode) {} > > static RoundDoubleModeNode make(Compile* C, Node* arg, > RoundDoubleModeNode::RoundingMode rmode); > > > convertnode.cpp: > > RoundDoubleModeNode* RoundDoubleModeNode::make(Compile* C, > Node* arg, > RoundDoubleModeNode::RoundingMode rmode) { > ConINode* rm = C->initial_gvn()->intcon(rmode); > return new RoundDoubleModeNode(arg, rm); > } > > > library_call.cpp: > > case vmIntrinsics::_ceil: n = RoundDoubleModeNode::make(C, arg, > RoundDoubleModeNode::rmode_ceil); > > > > > Best regards, > Vladimir Ivanov > > On 09/10/2019 12:29, Doerr, Martin wrote: > > Hi Vladimir and Michihiro, > > > >> ConINode::make() allocates a new node which has to be seen by GVN, so > >> there's a type recorded for it. > > Makes sense. > > > > I'd prefer > > RoundDoubleModeNode(Node *in1, Node *rmode): Node(0, in1, rmode) > {} > > > > and > > case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_floor))); break; > > case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_rint))); break; > > > > That avoids additional includes in convertnode.hpp which can easily lead to > cyclic dependencies for future changes. > > > > Best regards, > > Martin > > > > > >> -----Original Message----- > >> From: Vladimir Ivanov > >> Sent: Dienstag, 8. Oktober 2019 12:31 > >> To: Doerr, Martin ; Michihiro Horie > >> > >> Cc: hotspot compiler ; ppc- > aix- > >> port-dev at openjdk.java.net > >> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on > Power > >> > >> > >> > >> On 08/10/2019 13:14, Doerr, Martin wrote: > >>> Hi Vladimir and Michihiro, > >>> > >>> I like webrev.04 more than webrev.05. > >>> I think it's not good to include graphKit.hpp in convertnode.hpp. This > >> creates a weird dependency. > >>> What was the reason for this change? > >> > >> webrev.04 has a bug. Quote from earlier email: > >> > >> "src/hotspot/share/opto/convertnode.hpp: > >> > >> + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, > >> ConINode::make(rmode)) {} > >> > >> ConINode::make() allocates a new node which has to be seen by GVN, so > >> there's a type recorded for it. That's why I mentioned GraphKit*. But > >> you can use PhaseGVN & intcon as well." > >> > >> Alternatively, Compile* can be used as well. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >>>> -----Original Message----- > >>>> From: Vladimir Ivanov > >>>> Sent: Dienstag, 8. Oktober 2019 11:47 > >>>> To: Michihiro Horie > >>>> Cc: hotspot compiler ; > Doerr, > >>>> Martin ; ppc-aix-port-dev at openjdk.java.net > >>>> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on > >> Power > >>>> > >>>> > >>>>> http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/ > >>>> > >>>> Looks good. > >>>> > >>>> (Test results are clean.) > >>>> > >>>> Best regards, > >>>> Vladimir Ivanov > >>>> > >>>>> > I think it would be better to use adlc?s include generator instead of > >>>>> > including "opto/convertnode.hpp" explicitly in the ad file. > >>>>> > > >>>>> > src/hotspot/share/adlc/main.cpp > >>>>> > > >>>>> > ??? AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > >>>>> > > >>>>> > +? AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > >>>>> > > >>>>> > ??? AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > >>>>> > > >>>>> > @Vladimir: Do you agree? Would you do it this way, too? > >>>>> > >>>>> I prefer current version. > >>>>> > >>>>> When proposing the refactoring I thought about the change in adlc as > >>>>> well, but when I saw the patch I noticed that putting it in AD file > >>>>> stresses it's a platform-specific dependency. > >>>>> > >>>>> I think that's the right way to look at it until we get a way to funnel > >>>>> attributes from ideal nodes to mach nodes and use them during code > >>>>> emission. > >>>>> > >>>>> Best regards, > >>>>> Vladimir Ivanov > >>>>> > >>>>> > *From:*Michihiro Horie > >>>>> > *Sent:* Montag, 7. Oktober 2019 17:54 > >>>>> > *To:* Vladimir Ivanov > >>>>> > *Cc:* hotspot compiler dev at openjdk.java.net>; > >>>> Doerr, > >>>>> > Martin ; ppc-aix-port- > >> dev at openjdk.java.net > >>>>> > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>>>> > rint on Power > >>>>> > > >>>>> > Hi Martin, Vladimir, > >>>>> > Thanks a lot for your further feedback, which makes sense. > >>>>> > > >>>>> > New webrev: > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ > >>>>> > > >>>>> > Best regards, > >>>>> > Michihiro > >>>>> > > >>>>> > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > >>>>> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > >>>>> > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, > >> Michihiro. > >>>>> > > >>>>> > From: Vladimir Ivanov >>>>> > > > >>>>> > To: Michihiro Horie >> >, > >>>>> > "Doerr, Martin" >>>> > > >>>>> > Cc: hotspot compiler >>>>> > >, > >>>>> > "ppc-aix-port-dev at openjdk.java.net > >>>>> > " > >>>>> > >>>>> > > > >>>>> > Date: 2019/10/07 22:51 > >>>>> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, > >>>>> > floor, rint on Power > >>>>> > > >>>>> > ------------------------------------------------------------------------ > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> >> Fixed webrev is as follows. > >>>>> > > >>>>> > Thanks, Michihiro. > >>>>> > > >>>>> >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ > >>>>> > > >>>>> > src/hotspot/share/opto/convertnode.hpp: > >>>>> > > >>>>> > + ?enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > >>>>> > > >>>>> > Please, explicitly initialize the elements. Numbering is important > since > >>>>> > it is aligned with instruction encoding on x86. > >>>>> > > >>>>> > > >>>>> > src/hotspot/share/opto/library_call.cpp: > >>>>> > > >>>>> > + ?case vmIntrinsics::_ceil: ? n = new RoundDoubleModeNode(arg, > >>>>> > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); > >>>> break; > >>>>> > > >>>>> > Please, change RoundDoubleModeNode to accept the enum > instead > >> and > >>>>> > instantiate the ConI node inside it or introduce a static factory > >>>>> > (::make(GraphKit*,RoundingMode)) for that purpose. > >>>>> > > >>>>> > > >>>>> > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > >>>>> > > >>>>> > + ?void math_round(const FloatRegister t, const FloatRegister b, int > >>>>> rmode); > >>>>> > + ?void math_round_vec(const VectorSRegister t, const > >> VectorSRegister > >>>> b, > >>>>> > int rmode); > >>>>> > > >>>>> > I suggest to get rid of helpers in MacroAssembler and simply move > >> the > >>>>> > code into corresponding AD instructions. > >>>>> > > >>>>> > Best regards, > >>>>> > Vladimir Ivanov > >>>>> > > >>>>> >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15--- > > I > >>>>> >> suggest to put the enum in RoundDoubleModeNode > >> (convertn"Doerr, > >>>> Martin" > >>>>> >> ---2019/10/07 22:09:15---> I suggest to put the enum in > >>>>> >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction > >>>> selectio > >>>>> >> > >>>>> >> From: "Doerr, Martin" >>>>> > > >>>>> >> To: Vladimir Ivanov >>>>> >, > >>>>> > Michihiro Horie > >>>>> >> > > >>>>> >> Cc: hotspot compiler >>>>> > >, > >>>>> >> "ppc-aix-port-dev at openjdk.java.net > >>>>> > " > >>>>> > >>>>> > > > >>>>> >> Date: 2019/10/07 22:09 > >>>>> >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for > >> Math.ceil, > >>>>> >> floor, rint on Power > >>>>> >> > >>>>> >> ------------------------------------------------------------------------ > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> ?> I suggest to put the enum in RoundDoubleModeNode > >>>> (convertnode.hpp) > >>>>> >> ?> and lift instruction selection logic from > macroAssembler_ppc.cpp > >>>>> into > >>>>> >> ppc.ad. > >>>>> >> That sounds good. > >>>>> >> > >>>>> >> Thanks, > >>>>> >> Martin > >>>>> >> > >>>>> >> > >>>>> >> ?> -----Original Message----- > >>>>> >> ?> From: Vladimir Ivanov >>>>> > > >>>>> >> ?> Sent: Montag, 7. Oktober 2019 12:55 > >>>>> >> ?> To: Doerr, Martin >>>>> >; Michihiro Horie > >>>>> >> ?> > > >>>>> >> ?> Cc: hotspot compiler dev at openjdk.java.net > >>>>> > >; ppc-aix- > >>>>> >> ?> port-dev at openjdk.java.net >> dev at openjdk.java.net> > >>>>> >> ?> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>>>> >> rint on Power > >>>>> >> ?> > >>>>> >> ?> > I think sharedRuntime is not a good place for the C2 enum. > >>>>> >> ?> Agree. > >>>>> >> ?> > >>>>> >> ?> I suggest to put the enum in RoundDoubleModeNode > >>>> (convertnode.hpp) > >>>>> >> ?> and > >>>>> >> ?> lift instruction selection logic from macroAssembler_ppc.cpp > into > >>>>> ppc.ad. > >>>>> >> ?> > >>>>> >> ?> Best regards, > >>>>> >> ?> Vladimir Ivanov > >>>>> >> ?> > >>>>> >> ?> > > >>>>> >> ?> > Maybe intrinsicnode.hpp would be a better pace for it. But > >>>>> then, the > >>>>> >> ?> > code in macroAssembler should be guarded by #ifdef > >> COMPILER2. > >>>>> >> ?> > > >>>>> >> ?> > Best regards, > >>>>> >> ?> > > >>>>> >> ?> > Martin > >>>>> >> ?> > > >>>>> >> ?> > *From:*Michihiro Horie >>>> > > >>>>> >> ?> > *Sent:* Montag, 7. Oktober 2019 09:14 > >>>>> >> ?> > *To:* Vladimir Ivanov >>>>> > > >>>>> >> ?> > *Cc:* hotspot compiler >> dev at openjdk.java.net > >>>>> > >; > >>>>> >> ?> > ppc-aix-port-dev at openjdk.java.net > >>>>> > ; Doerr, Martin > >>>>> >> ?> > > >>>>> >> ?> > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > >>>>> floor, > >>>>> >> ?> > rint on Power > >>>>> >> ?> > > >>>>> >> ?> > Hi Vladimir, > >>>>> >> ?> > > >>>>> >> ?> > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > >>>>> >> ?> > I'm wondering if the enum constants can be declared in > >>>>> >> ?> sharedRuntime.hpp. > >>>>> >> ?> > Webrev: > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > >>>>> >> ?> > > >>>>> >> ?> > Best regards, > >>>>> >> ?> > Michihiro > >>>>> >> ?> > > >>>>> >> ?> > Inactive hide details for Vladimir Ivanov ---2019/10/04 > >>>>> 23:05:48---Hi > >>>>> >> ?> > Michihiro, > >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > >>>>> Ivanov > >>>>> >> ?> > ---2019/10/04 23:05:48---Hi Michihiro, > >>>>> >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>>>> >> ?> > > >>>>> >> ?> > From: Vladimir Ivanov >>>>> > > ?> > > >>>>> > > > >>>>> >> ?> > To: Michihiro Horie >>>> >, > >>>>> >> ?> > ppc-aix-port-dev at openjdk.java.net > >>>>> > >>>>> >> ?> > , hotspot > compiler > >>>>> >> ?> > >>>>> > > ?> > > >>>>> > > > >>>>> >> ?> > Date: 2019/10/04 23:05 > >>>>> >> ?> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > >>>>> Math.ceil, > >>>>> >> ?> > floor, rint on Power > >>>>> >> ?> > > >>>>> >> ?> > > >>>>> >> ------------------------------------------------------------------------ > >>>>> >> ?> > > >>>>> >> ?> > > >>>>> >> ?> > > >>>>> >> ?> > > >>>>> >> ?> > Hi Michihiro, > >>>>> >> ?> > > >>>>> >> ?> > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>>>> >> ?> > + ?switch (rmode) { > >>>>> >> ?> > + ? ?case 0: // rint > >>>>> >> ?> > + ? ? ?frin(t, b); > >>>>> >> ?> > + ? ? ?break; > >>>>> >> ?> > + ? ?case 1: // floor > >>>>> >> ?> > + ? ? ?frim(t, b); > >>>>> >> ?> > + ? ? ?break; > >>>>> >> ?> > + ? ?case 2: // ceil > >>>>> >> ?> > + ? ? ?frip(t, b); > >>>>> >> ?> > + ? ? ?break; > >>>>> >> ?> > + ? ?default: > >>>>> >> ?> > + ? ? ?ShouldNotReachHere(); > >>>>> >> ?> > + ?} > >>>>> >> ?> > > >>>>> >> ?> > What do you think about introducing enum constants instead > of > >>>> using > >>>>> >> ?> > hard-coded 0/1/2? > >>>>> >> ?> > > >>>>> >> ?> > src/hotspot/share/opto/library_call.cpp: > >>>>> >> ?> > > >>>>> >> ?> > ?? case vmIntrinsics::_ceil: ? n = new > >> RoundDoubleModeNode(arg, > >>>>> >> ?> > makecon(TypeInt::make(2))); break; > >>>>> >> ?> > ?? case vmIntrinsics::_floor: ?n = new > >> RoundDoubleModeNode(arg, > >>>>> >> ?> > makecon(TypeInt::make(1))); break; > >>>>> >> ?> > ?? case vmIntrinsics::_rint: ? n = new > >> RoundDoubleModeNode(arg, > >>>>> >> ?> > makecon(TypeInt::make(0))); break; > >>>>> >> ?> > > >>>>> >> ?> > The downside is you have to move the switch from > >>>> macroAssembler > >>>>> >> ?> because > >>>>> >> ?> > enum should be visible from both places. (Is there a better > >>>>> place for > >>>>> >> ?> > that than roundD_regNode::emit() in AD file?) > >>>>> >> ?> > > >>>>> >> ?> > Best regards, > >>>>> >> ?> > Vladimir Ivanov > >>>>> >> ?> > > >>>>> >> ?> > On 02/10/2019 07:27, Michihiro Horie wrote: > >>>>> >> ?> >> > >>>>> >> ?> >> Dear all, > >>>>> >> ?> >> > >>>>> >> ?> >> Would you please review the following change? > >>>>> >> ?> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > >>>>> >> ?> >> Webrev: > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > >>>>> >> ?> >> > >>>>> >> ?> >> This change adds intrinsics for Math's ceil, floor, and rint for > >>>>> >> PPC64, on > >>>>> >> ?> >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > >>>>> >> ?> >> > >>>>> >> ?> >> Best regards, > >>>>> >> ?> >> Michihiro > >>>>> >> ?> >> > >>>>> >> ?> > > >>>>> >> ?> > > >>>>> >> ?> > > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> From magnus.ihse.bursie at oracle.com Mon Oct 14 08:37:57 2019 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 14 Oct 2019 10:37:57 +0200 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> Message-ID: On 2019-10-11 15:38, Yasumasa Suenaga wrote: > Hi, > > Christos commented to B-1. Thanks! > clang defines __GNU_C__ , but stringop-truncation is not supported. > > So I updated Plan B-1. It works fine on my Fedora30 box. > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B-1. Use #pragma > http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.02/ > > ? C. Set -Wno-stringop-truncation in globally > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ Please note that if you chose to go with route C, you need to get this reviewed on build-dev (as all changes in the makefiles are). The patch as currently suggested is not acceptable; the built-in functions for testing compiler version needs to be used, as a minimum. /Magnus > > > Of course I will push the change to submit repo before sending review > request. > > > Thanks, > > Yasumasa > > > On 2019/10/11 15:55, Yasumasa Suenaga wrote: >> Hi, >> >> Thanks for a lot advises! >> >> We have following solutions for this issue. >> I'd like to send RFR again with much consented patch in early next week. >> >> >> ?? A. Use memcpy() >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ?? B-1. Use #pragma >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ >> >> ?? C. Set -Wno-stringop-truncation in globally >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ >> >> >> If we fix with C, I will send RFR to hotspot-dev and build-dev. >> Plan C also fixes other stringop-truncation problems such as >> JDK-8220074. >> Thus it affects all of JDK code, but it would be useful if >> stringop-truncation >> should be disabled in JDK build process. >> >> >> Comments are welcome. >> >> Yasumasa >> >> >> On 2019/10/11 10:34, Yasumasa Suenaga wrote: >>> Hi, >>> >>> I want to get conclusion of this discussion. >>> >>> I understand the fix of macroAssembler_x86.hpp is ok, but we have >>> not yet had conclusion >>> how we should fix diagnosticArgument.cpp . >>> >>> I think we can fix diagnosticArgument.cpp as following: >>> >>> >>> ?? A. Use memcpy() >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>> >>> ?? B. Add -Wno-stringop-truncation to >>> make/hotspot/lib/JvmOverrideFiles.gmk >>> ??????? This option will be added diagnosticArgument.cpp only. >>> >>> ?? C. Set -Wno-stringop-truncation in globally >>> ??????? make/hotspot/lib/CompileJvm.gmk >>> >>> >>> I prefer to fix like A because it affects minimally. >>> Some issues might be found out by stringop-truncation in future. >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>> On Oct 10, 2019, at 3:03 AM, David Holmes >>>>> wrote: >>>>> >>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>> ?From JBS: >>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>>>> truncated before terminating nul copying as many bytes from a >>>>>> string as its length [-Wstringop-truncation] >>>>>> ?? 154 | strncpy(buf, str, len); >>>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>> I assume this means that in all cases the "len" value is seen to >>>>>> be derived from strlen, and therefore strncpy is always copying >>>>>> one byte short of \0, and this is most likely not what the user >>>>>> wants. I seem to >>>>> >>>>> Yes but we then explicitly set the NULL at buf[len] which is the >>>>> expected/required pattern for this. >>>>> >>>>>> recall another recent similar fix that was done by switching to >>>>>> using memcpy instead. >>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>> >>>>> >>>>> Seems to me that strncpy and memcpy are semantically equivalent >>>>> here so all this does is avoid gcc's over zealous warnings. I'm >>>>> inclined to use the: >>>>> >>>>> #pragma GCC diagnostic push >>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>> >>>>> solution. >>>>> >>>>> YMMV. >>>> >>>> We've run into and discussed problems with -Wstringop-truncation >>>> before.? (See discussions of JDK-8214777 and JDK-8223186.) This is a >>>> relatively recent warning option (introduced in gcc8, and included in >>>> -Wall), and seems to have a considerable bug tail: >>>> >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>> resolved associated bugs. >>>> >>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>> this warning while it is so buggy. >>>> From claes.redestad at oracle.com Mon Oct 14 10:19:48 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Oct 2019 12:19:48 +0200 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> Message-ID: <1195c234-39a9-d0a2-51c6-ca4ab5af1de5@oracle.com> On 2019-10-13 18:51, Igor Veresov wrote: > ?Ok, I followed the notation you proposed, here?s the webrev: > http://cr.openjdk.java.net/~iveresov/8227003/webrev.01/ Thanks for picking up the proposal! :-) Some comments: - For the sake of completeness the default value should be explicit, i.e., tiered or default, and not NULL. Default flag values show up when running -XX:PrintFlagsFinal and such, so it's good with unsurprising output. - src/hotspot/share/runtime/globals.hpp: "TieredMode=4" in comments a number of times, should be something like "CompilationMode=highOnly|highOnlyQuickInternal"? - Since we're adding flags then I think a CSR is needed. My suggestion is to change subject to something like "Add high-level JIT compilation mode control mechanism". Thanks! /Claes From martin.doerr at sap.com Mon Oct 14 13:44:11 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Oct 2019 13:44:11 +0000 Subject: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 instructions on processors which don't support it In-Reply-To: References: Message-ID: Hi Vladimir and Tobias, @Vladimir thanks for the review. @Tobias Can I consider it reviewed? Or are there any concerns? Best regards, Martin > -----Original Message----- > From: hotspot-compiler-dev bounces at openjdk.java.net> On Behalf Of Vladimir Kozlov > Sent: Donnerstag, 10. Oktober 2019 19:22 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 > instructions on processors which don't support it > > Good. > > Thanks, > Vladimir > > On 10/10/19 5:29 AM, Doerr, Martin wrote: > > Hi, > > > > we have observed a JVM crash in JDK13u on an AMD Opteron machine. > > > > Instructions like pabsb/w/d, phaddd get emitted when SSE3 is available, > but are not supported without SSSE3. > > E.g. AMD Opteron(tm) Processor 2218 has SSE3, but not SSSE3. > > > > Should we fix it this way? > > http://cr.openjdk.java.net/~mdoerr/8232106_x86_ssse3/webrev.00/ > > > > Best regards, > > Martin > > From martin.doerr at sap.com Mon Oct 14 14:50:19 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 14 Oct 2019 14:50:19 +0000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread Message-ID: Hi David, >> As C1 and C2 compiler threads are hidden, I still don't see any problems reusing the Thread objects. > They are not completely hidden. Those j.l.Thread objects are still part of the system thread group and can be found by other code. I know that they are part of the system thread group, but I thought they should not be visible to Java. E.g. ThreadGroup tg = new ThreadGroup("A"); ThreadGroup stg = tg.getParent().getParent(); Thread[] list = new Thread[100]; stg.enumerate(list); System.out.println("Listing elements of " + stg); for (int i = 0; i < list.length; ++i) { if (list[i] != null) { System.out.println(i + ": " + list[i]); } } Finds: Listing elements of java.lang.ThreadGroup[name=system,maxpri=10] 0: Thread[Reference Handler,10,system] 1: Thread[Finalizer,8,system] 2: Thread[Signal Dispatcher,9,system] 3: Thread[main,5,main] I can't see any compiler threads. Do you mean finding them by JVMTI agent? As I understand the Spec, compiler threads should be excluded for GetAllThreads: "The threads are Java programming language threads" Or what did you mean by "other code" which can see C1 and C2 threads? Best regards, Martin From igor.veresov at oracle.com Mon Oct 14 18:03:00 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 14 Oct 2019 11:03:00 -0700 Subject: RFR(M) 8227003: Add high-level JIT compilation mode control mechanism In-Reply-To: <1195c234-39a9-d0a2-51c6-ca4ab5af1de5@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> <1195c234-39a9-d0a2-51c6-ca4ab5af1de5@oracle.com> Message-ID: <503CCDF7-B688-4C45-8093-267E481A6D20@oracle.com> > On Oct 14, 2019, at 3:19 AM, Claes Redestad wrote: > > > On 2019-10-13 18:51, Igor Veresov wrote: >> Ok, I followed the notation you proposed, here?s the webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.01/ > > Thanks for picking up the proposal! :-) > > Some comments: > > - For the sake of completeness the default value should be explicit, > i.e., tiered or default, and not NULL. Default flag values show up > when running -XX:PrintFlagsFinal and such, so it's good with > unsurprising output. Sure. > > - src/hotspot/share/runtime/globals.hpp: > > "TieredMode=4" in comments a number of times, should be something > like "CompilationMode=highOnly|highOnlyQuickInternal"? > Right, thanks, I?ll fix this. Webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.02/ > - Since we're adding flags then I think a CSR is needed. My suggestion > is to change subject to something like "Add high-level JIT > compilation mode control mechanism". I don?t think we need a CSR, we?re only adding flags. Everything stay backwards-compatible. Igor > > Thanks! > > /Claes From tobias.hartmann at oracle.com Mon Oct 14 18:21:50 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 14 Oct 2019 11:21:50 -0700 Subject: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 instructions on processors which don't support it In-Reply-To: References: <5ccebd52-0bff-75b3-c3e0-c201597b6943@oracle.com> Message-ID: <96f0e7c1-2e72-dc0a-ed1a-3013631d1bbf@oracle.com> Hi Martin, okay, thanks for the clarifications. Best regards, Tobias On 11.10.19 08:53, Doerr, Martin wrote: > Hi Tobias, > > the instructions introduced by JDK-8222074 are leading to the crash we're seing. > But AddReductionVI uses phaddd which also belongs to SSSE3. So we should make these match rules unavailable for processors without SSSE3, too. > > I have never seen crashes due to AddReductionVI, but I guess we should backport the fix to 11u, too. > > Best regards, > Martin > > >> -----Original Message----- >> From: Tobias Hartmann >> Sent: Freitag, 11. Oktober 2019 10:25 >> To: Doerr, Martin ; 'hotspot-compiler- >> dev at openjdk.java.net' >> Subject: Re: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 >> instructions on processors which don't support it >> >> Hi Martin, >> >> so this was introduced by JDK-8222074, right? >> >> Just wondering, does AddReductionVI require SSSE3 as well? >> >> Thanks, >> Tobias >> >> On 10.10.19 14:29, Doerr, Martin wrote: >>> Hi, >>> >>> we have observed a JVM crash in JDK13u on an AMD Opteron machine. >>> >>> Instructions like pabsb/w/d, phaddd get emitted when SSE3 is available, >> but are not supported without SSSE3. >>> E.g. AMD Opteron(tm) Processor 2218 has SSE3, but not SSSE3. >>> >>> Should we fix it this way? >>> http://cr.openjdk.java.net/~mdoerr/8232106_x86_ssse3/webrev.00/ >>> >>> Best regards, >>> Martin >>> From tobias.hartmann at oracle.com Mon Oct 14 18:22:14 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 14 Oct 2019 11:22:14 -0700 Subject: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 instructions on processors which don't support it In-Reply-To: References: Message-ID: <4a95f98e-828f-cacc-830c-41de918dda9f@oracle.com> On 14.10.19 06:44, Doerr, Martin wrote: > @Tobias > Can I consider it reviewed? Or are there any concerns? Reviewed. Best regards, Tobias From tobias.hartmann at oracle.com Mon Oct 14 18:23:47 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 14 Oct 2019 11:23:47 -0700 Subject: RFR(S): 8231988: Unexpected test result caused by C2 IdealLoopTree::do_remove_empty_loop In-Reply-To: References: <041e13e4-a860-0523-c01d-f7d8d40230e4@oracle.com> <3098cce0-bf26-9bba-554e-7e5b66930371@oracle.com> Message-ID: <6d415939-0881-de78-872f-a8369b239f3b@oracle.com> Hi Felix, looks good. Thanks, Tobias On 11.10.19 18:58, Yangfei (Felix) wrote: >>> Hi Felix, >> >> On 11.10.19 02:45, Yangfei (Felix) wrote: >>> Updated webrev: http://cr.openjdk.java.net/~fyang/8231988/webrev.01/ >> >> If possible, tests should have a name that describes their purpose and should >> be put into one of the corresponding folders. In this case, I would suggest >> TestRemoveEmptyLoop and put it into compiler/loopopts/. >> > > Hi Tobias, > > That sounds good. Updated webrev: http://cr.openjdk.java.net/~fyang/8231988/webrev.02/ > Newly added test pass on aarch64 & x64 platform. Is it OK? > > Thanks, > Felix > From serguei.spitsyn at oracle.com Mon Oct 14 18:37:36 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Mon, 14 Oct 2019 11:37:36 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <2ce989bb-e802-e427-d960-4976b4664c63@oss.nttdata.com> References: <1b78ecb5-0637-f31c-8c90-f74020a575c3@oss.nttdata.com> <4f5f0c97-41b7-1c81-b190-82bfa540c068@oracle.com> <1CBC4309-5D33-4503-89AA-305F92779ECB@oracle.com> <950bb874-f36c-920a-f8d5-52e0a10048e7@oss.nttdata.com> <6151ddfa-488a-5d7d-3c11-e516a568628a@oss.nttdata.com> <2ce989bb-e802-e427-d960-4976b4664c63@oss.nttdata.com> Message-ID: <092ca355-c3df-43d3-4657-5af2aa790314@oracle.com> Hi Yasumasa, I'm Okay with both A and B-1. Personally, I like the simplicity of A but understand this issue is more broad. Thanks, Serguei On 10/11/19 20:22, Yasumasa Suenaga wrote: > Hi, > > I updated Plan B-1 (#pragma) due to the comment from Chris [1]. > > > ? A. Use memcpy() > ?????? http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ > > ? B-1. Use #pragma > http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.03/ > > > I dropped Plan C (disable stringop-truncation in globally) from the > solutions > because Kim pointed this warning found out some actual bugs [2]. > > > Thanks, > > Yasumasa > > > [1] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029586.html > [2] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029590.html > > > On 2019/10/11 22:38, Yasumasa Suenaga wrote: >> Hi, >> >> Christos commented to B-1. Thanks! >> clang defines __GNU_C__ , but stringop-truncation is not supported. >> >> So I updated Plan B-1. It works fine on my Fedora30 box. >> >> >> ?? A. Use memcpy() >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >> >> ?? B-1. Use #pragma >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma.02/ >> >> ?? C. Set -Wno-stringop-truncation in globally >> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ >> >> >> Of course I will push the change to submit repo before sending review >> request. >> >> >> Thanks, >> >> Yasumasa >> >> >> On 2019/10/11 15:55, Yasumasa Suenaga wrote: >>> Hi, >>> >>> Thanks for a lot advises! >>> >>> We have following solutions for this issue. >>> I'd like to send RFR again with much consented patch in early next >>> week. >>> >>> >>> ?? A. Use memcpy() >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>> >>> ?? B-1. Use #pragma >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.B1-pragma/ >>> >>> ?? C. Set -Wno-stringop-truncation in globally >>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.C/ >>> >>> >>> If we fix with C, I will send RFR to hotspot-dev and build-dev. >>> Plan C also fixes other stringop-truncation problems such as >>> JDK-8220074. >>> Thus it affects all of JDK code, but it would be useful if >>> stringop-truncation >>> should be disabled in JDK build process. >>> >>> >>> Comments are welcome. >>> >>> Yasumasa >>> >>> >>> On 2019/10/11 10:34, Yasumasa Suenaga wrote: >>>> Hi, >>>> >>>> I want to get conclusion of this discussion. >>>> >>>> I understand the fix of macroAssembler_x86.hpp is ok, but we have >>>> not yet had conclusion >>>> how we should fix diagnosticArgument.cpp . >>>> >>>> I think we can fix diagnosticArgument.cpp as following: >>>> >>>> >>>> ?? A. Use memcpy() >>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.02/ >>>> >>>> ?? B. Add -Wno-stringop-truncation to >>>> make/hotspot/lib/JvmOverrideFiles.gmk >>>> ??????? This option will be added diagnosticArgument.cpp only. >>>> >>>> ?? C. Set -Wno-stringop-truncation in globally >>>> ??????? make/hotspot/lib/CompileJvm.gmk >>>> >>>> >>>> I prefer to fix like A because it affects minimally. >>>> Some issues might be found out by stringop-truncation in future. >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> On 2019/10/11 5:54, Kim Barrett wrote: >>>>>> On Oct 10, 2019, at 3:03 AM, David Holmes >>>>>> wrote: >>>>>> >>>>>> On 10/10/2019 4:50 pm, Chris Plummer wrote: >>>>>>> ?From JBS: >>>>>>> /home/ysuenaga/OpenJDK/jdk/src/hotspot/share/services/diagnosticArgument.cpp:154:14: >>>>>>> warning: 'char* strncpy(char*, const char*, size_t)' output >>>>>>> truncated before terminating nul copying as many bytes from a >>>>>>> string as its length [-Wstringop-truncation] >>>>>>> ?? 154 | strncpy(buf, str, len); >>>>>>> ?????? | ~~~~~~~^~~~~~~~~~~~~~~ >>>>>>> I assume this means that in all cases the "len" value is seen to >>>>>>> be derived from strlen, and therefore strncpy is always copying >>>>>>> one byte short of \0, and this is most likely not what the user >>>>>>> wants. I seem to >>>>>> >>>>>> Yes but we then explicitly set the NULL at buf[len] which is the >>>>>> expected/required pattern for this. >>>>>> >>>>>>> recall another recent similar fix that was done by switching to >>>>>>> using memcpy instead. >>>>>>> Here's a discussion of interest, also suggesting memcpy: >>>>>>> https://stackoverflow.com/questions/50198319/gcc-8-wstringop-truncation-what-is-the-good-practice >>>>>>> >>>>>> >>>>>> Seems to me that strncpy and memcpy are semantically equivalent >>>>>> here so all this does is avoid gcc's over zealous warnings. I'm >>>>>> inclined to use the: >>>>>> >>>>>> #pragma GCC diagnostic push >>>>>> #pragma GCC diagnostic ignored "-Wstringop-truncation" >>>>>> >>>>>> solution. >>>>>> >>>>>> YMMV. >>>>> >>>>> We've run into and discussed problems with -Wstringop-truncation >>>>> before.? (See discussions of JDK-8214777 and JDK-8223186.)? This is a >>>>> relatively recent warning option (introduced in gcc8, and included in >>>>> -Wall), and seems to have a considerable bug tail: >>>>> >>>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88781 >>>>> A metabug for -Wstringop-truncation, currently with 16 open and 10 >>>>> resolved associated bugs. >>>>> >>>>> I'm not a fan of replacing correct and idiomatic uses of strncpy with >>>>> strcpy or memcpy.? I've suggested in the past that we should turn off >>>>> this warning while it is so buggy. >>>>> From claes.redestad at oracle.com Mon Oct 14 19:13:23 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 14 Oct 2019 21:13:23 +0200 Subject: RFR(M) 8227003: Add high-level JIT compilation mode control mechanism In-Reply-To: <503CCDF7-B688-4C45-8093-267E481A6D20@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> <1195c234-39a9-d0a2-51c6-ca4ab5af1de5@oracle.com> <503CCDF7-B688-4C45-8093-267E481A6D20@oracle.com> Message-ID: <027c46ce-c243-b392-cbdd-a16c55438252@oracle.com> On 2019-10-14 20:03, Igor Veresov wrote: >> - Since we're adding flags then I think a CSR is needed. My suggestion >> is to change subject to something like "Add high-level JIT >> compilation mode control mechanism". > I don?t think we need a CSR, we?re only adding flags. Everything stay backwards-compatible. "For CSR purposes, only Hotspot's 'product' and 'manageable' flags are considered exported interfaces that require a CSR request when they are *added*, [...]": https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process My understanding is that we need a CSR for the product flag, but not the diagnostic ones. /Claes From tom.rodriguez at oracle.com Mon Oct 14 20:34:38 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Mon, 14 Oct 2019 13:34:38 -0700 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: <17aa1a3a-6129-73e0-c374-902f31cd1300@loongson.cn> References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> <17aa1a3a-6129-73e0-c374-902f31cd1300@loongson.cn> Message-ID: Yes I mistranslated this code in the case where that ifndef triggers. I think this http://cr.openjdk.java.net/~never/8232083/webrev/ is a better translation of the original code. Can I get a review of this and I will push it. tom Jie Fu wrote on 10/13/19 11:35 PM: > Forward this to Tom. Thanks. > > On 2019/10/11 ??8:07, Jie Fu wrote: >> Hi all, >> >> JDK-8232151 had been fixed. >> >> Could you please review this fix and give me some advice? >> >> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232083 >> Webrev: http://cr.openjdk.java.net/~jiefu/8232083/webrev.00/ >> >> Thanks a lot. >> Best regards, >> Jie >> >> On 2019/10/11 ??11:42, Jie Fu wrote: >>> Please hold off reviewing this until JDK-8232151 >>> is fixed. >> > From per.liden at oracle.com Mon Oct 14 21:43:16 2019 From: per.liden at oracle.com (Per Liden) Date: Mon, 14 Oct 2019 23:43:16 +0200 Subject: [13u] RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level Message-ID: <928d529c-02f4-f9f9-ea04-198d0659dc77@oracle.com> Hi, Please review this back port of JDK-8230565 to 13u. This fix significantly improves stability of ZGC (or more specifically ZGC's C2 load barrier). The back port was trivial, but not completely clean, as it required manual merge to resolve 4 simple conflicts. Original bug: https://bugs.openjdk.java.net/browse/JDK-8230565 Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/d376d86b0a01 JDK 13u webrev: http://cr.openjdk.java.net/~pliden/8230565/webrev.jdk13u Testing: - Tier1-3 on all Oracle platforms. - Tier1-6 on Linux/x64. - Multiple iterations of gc-test-suite on Linux/x64. - Builds on Linux/AArch64. /Per From fujie at loongson.cn Tue Oct 15 00:56:30 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 15 Oct 2019 08:56:30 +0800 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> <17aa1a3a-6129-73e0-c374-902f31cd1300@loongson.cn> Message-ID: <9b4d95f0-0a22-44b4-3bd8-ae61e4c2c293@loongson.cn> Hi Tom, Thanks for fixing this. The patch seems to break the vm build: --------------------------------------------- /home/fool/workspace/jdk-dev/src/hotspot/share/compiler/oopMap.cpp:343:3: error: expected unqualified-id before '{' token ?? { ?? ^ /home/fool/workspace/jdk-dev/src/hotspot/share/compiler/oopMap.cpp:394:1: error: expected declaration before '}' token ?} ?^ lib/CompileJvm.gmk:176: recipe for target '/home/fool/workspace/jdk-dev/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/oopMap.o' failed --------------------------------------------- Best regards, Jie On 2019/10/15 ??4:34, Tom Rodriguez wrote: > Yes I mistranslated this code in the case where that ifndef triggers.? > I think this http://cr.openjdk.java.net/~never/8232083/webrev/ is a > better translation of the original code.? Can I get a review of this > and I will push it. > > tom > > Jie Fu wrote on 10/13/19 11:35 PM: >> Forward this to Tom. Thanks. >> >> On 2019/10/11 ??8:07, Jie Fu wrote: >>> Hi all, >>> >>> JDK-8232151 had been fixed. >>> >>> Could you please review this fix and give me some advice? >>> >>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232083 >>> Webrev: http://cr.openjdk.java.net/~jiefu/8232083/webrev.00/ >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> On 2019/10/11 ??11:42, Jie Fu wrote: >>>> Please hold off reviewing this until JDK-8232151 >>>> is fixed. >>> >> From nils.eliasson at oracle.com Mon Oct 14 20:11:37 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 14 Oct 2019 22:11:37 +0200 Subject: [13u] RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: <928d529c-02f4-f9f9-ea04-198d0659dc77@oracle.com> References: <928d529c-02f4-f9f9-ea04-198d0659dc77@oracle.com> Message-ID: Hi Per, Looks good! // Nils On 2019-10-14 23:43, Per Liden wrote: > Hi, > > Please review this back port of JDK-8230565 to 13u. This fix > significantly improves stability of ZGC (or more specifically ZGC's C2 > load barrier). The back port was trivial, but not completely clean, as > it required manual merge to resolve 4 simple conflicts. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8230565 > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/d376d86b0a01 > > JDK 13u webrev: http://cr.openjdk.java.net/~pliden/8230565/webrev.jdk13u > > Testing: > - Tier1-3 on all Oracle platforms. > - Tier1-6 on Linux/x64. > - Multiple iterations of gc-test-suite on Linux/x64. > - Builds on Linux/AArch64. > > /Per From per.liden at oracle.com Tue Oct 15 06:52:23 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 15 Oct 2019 08:52:23 +0200 Subject: [13u] RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: References: <928d529c-02f4-f9f9-ea04-198d0659dc77@oracle.com> Message-ID: <5500ca0f-81a2-3869-0a6e-530ed1dbaa69@oracle.com> Thanks Nils! /Per On 10/14/19 10:11 PM, Nils Eliasson wrote: > Hi Per, > > Looks good! > > // Nils > > On 2019-10-14 23:43, Per Liden wrote: >> Hi, >> >> Please review this back port of JDK-8230565 to 13u. This fix >> significantly improves stability of ZGC (or more specifically ZGC's C2 >> load barrier). The back port was trivial, but not completely clean, as >> it required manual merge to resolve 4 simple conflicts. >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8230565 >> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/d376d86b0a01 >> >> JDK 13u webrev: http://cr.openjdk.java.net/~pliden/8230565/webrev.jdk13u >> >> Testing: >> - Tier1-3 on all Oracle platforms. >> - Tier1-6 on Linux/x64. >> - Multiple iterations of gc-test-suite on Linux/x64. >> - Builds on Linux/AArch64. >> >> /Per From igor.veresov at oracle.com Tue Oct 15 06:57:17 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 14 Oct 2019 23:57:17 -0700 Subject: RFR(M) 8227003: Add high-level JIT compilation mode control mechanism In-Reply-To: <027c46ce-c243-b392-cbdd-a16c55438252@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> <1195c234-39a9-d0a2-51c6-ca4ab5af1de5@oracle.com> <503CCDF7-B688-4C45-8093-267E481A6D20@oracle.com> <027c46ce-c243-b392-cbdd-a16c55438252@oracle.com> Message-ID: <6AA316E4-0533-48D8-A575-C1B5E633C145@oracle.com> igor > On Oct 14, 2019, at 12:13 PM, Claes Redestad wrote: > > On 2019-10-14 20:03, Igor Veresov wrote: >>> - Since we're adding flags then I think a CSR is needed. My suggestion >>> is to change subject to something like "Add high-level JIT >>> compilation mode control mechanism". >> I don?t think we need a CSR, we?re only adding flags. Everything stay backwards-compatible. > > "For CSR purposes, only Hotspot's 'product' and 'manageable' flags are > considered exported interfaces that require a CSR request when they are > *added*, [...]": > > https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process > > My understanding is that we need a CSR for the product flag, but not the > diagnostic ones. Must be a new rule. Nobody every did it before. Igor > > /Claes From claes.redestad at oracle.com Tue Oct 15 07:05:38 2019 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 15 Oct 2019 09:05:38 +0200 Subject: RFR(M) 8227003: Add high-level JIT compilation mode control mechanism In-Reply-To: <6AA316E4-0533-48D8-A575-C1B5E633C145@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> <1195c234-39a9-d0a2-51c6-ca4ab5af1de5@oracle.com> <503CCDF7-B688-4C45-8093-267E481A6D20@oracle.com> <027c46ce-c243-b392-cbdd-a16c55438252@oracle.com> <6AA316E4-0533-48D8-A575-C1B5E633C145@oracle.com> Message-ID: On 2019-10-15 08:57, Igor Veresov wrote: >> "For CSR purposes, only Hotspot's 'product' and 'manageable' flags are >> considered exported interfaces that require a CSR request when they are >> *added*, [...]": >> >> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process >> >> My understanding is that we need a CSR for the product flag, but not the >> diagnostic ones. > > Must be a new rule. Nobody every did it before. > I don't make the rules. But a CSR isn't that much trouble either, really. /Claes From erik.osterlund at oracle.com Tue Oct 15 07:15:52 2019 From: erik.osterlund at oracle.com (Erik =?ISO-8859-1?Q?=D6sterlund?=) Date: Tue, 15 Oct 2019 09:15:52 +0200 Subject: [13u] RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: <928d529c-02f4-f9f9-ea04-198d0659dc77@oracle.com> References: <928d529c-02f4-f9f9-ea04-198d0659dc77@oracle.com> Message-ID: <8233977.IFtUbavBte@erik-theta> Hi Per, Looks good. Thanks, /Erik On m?ndag 14 oktober 2019 kl. 23:43:16 CEST Per Liden wrote: > Hi, > > Please review this back port of JDK-8230565 to 13u. This fix > significantly improves stability of ZGC (or more specifically ZGC's C2 > load barrier). The back port was trivial, but not completely clean, as > it required manual merge to resolve 4 simple conflicts. > > Original bug: https://bugs.openjdk.java.net/browse/JDK-8230565 > Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/d376d86b0a01 > > JDK 13u webrev: http://cr.openjdk.java.net/~pliden/8230565/webrev.jdk13u > > Testing: > - Tier1-3 on all Oracle platforms. > - Tier1-6 on Linux/x64. > - Multiple iterations of gc-test-suite on Linux/x64. > - Builds on Linux/AArch64. > > /Per From christoph.goettschkes at microdoc.com Tue Oct 15 07:30:16 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Tue, 15 Oct 2019 09:30:16 +0200 Subject: RFR: 8231955: ARM32: Address displacement is 0 for volatile field access because of Unsafe field access. In-Reply-To: <20191010143426.BA4B6319F46@aojmv0009> References: <20191010143426.BA4B6319F46@aojmv0009> Message-ID: Is there anyone who could take a look at this change and give feedback please? Thanks, Christoph "hotspot-compiler-dev" wrote on 2019-10-10 16:29:11: > From: christoph.goettschkes at microdoc.com > To: hotspot-compiler-dev at openjdk.java.net > Date: 2019-10-10 16:35 > Subject: RFR: 8231955: ARM32: Address displacement is 0 for volatile field > access because of Unsafe field access. > Sent by: "hotspot-compiler-dev" > > Hi, > > please review the following changeset. This patch fixes the volatile field > access for 32-bit ARM. The functions LIRGenerator::volatile_field_store > and LIRGenerator::volatile_field_load both assume that the displacement > for the given address is always 0. Both use the given address and pass the > values to add_large_constant() [1], which asserts that the given > displacement is not 0. The change does not call add_large_constant if the > given displacement is 0. The displacement can be 0, because of the > implementation of the unsafe intrinsics. This happens, because the offset > into the object from which the field is accessed is not a constant value. > > This fixes the hotspot tier1 tests mentioned in the issue. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231955 > Webrev: https://cr.openjdk.java.net/~bulasevich/8231955/webrev.00/ > > Thanks, > Christoph > > [1] > https://hg.openjdk.java.net/jdk/jdk/file/30a9612a657d/src/hotspot/cpu/arm/ > c1_LIRGenerator_arm.cpp#l166 > From christoph.goettschkes at microdoc.com Tue Oct 15 07:32:00 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Tue, 15 Oct 2019 09:32:00 +0200 Subject: RFR: 8231952: ARM32: Wrong assumption in assertion in LIRGenerator::atomic_xchg and LIRGenerator::atomic_add In-Reply-To: References: <20191010143214.24A3B319F24@aojmv0009> Message-ID: Thanks for your feedback Dean. Does some else have any feedback or can I ask Boris to push the changeset into the repository? -- Christoph "hotspot-compiler-dev" wrote on 2019-10-11 02:05:44: > From: dean.long at oracle.com > To: hotspot-compiler-dev at openjdk.java.net > Date: 2019-10-11 02:07 > Subject: Re: RFR: 8231952: ARM32: Wrong assumption in assertion in > LIRGenerator::atomic_xchg and LIRGenerator::atomic_add > Sent by: "hotspot-compiler-dev" > > Looks good to me. > > dl > > On 10/10/19 7:28 AM, christoph.goettschkes at microdoc.com wrote: > > Hi, > > > > please review the following changeset. This patch fixes a wrong assumption > > in an assertion of the C1 LIR generator for 32-bit ARM. The assertion > > assumed that atomic operations are only possible for int types on 32-bit > > arm. This is not true, since the LDREXD/STREXB instructions are use by the > > C1 JIT. > > > > This fixes the 3 hotspot tier1 tests mentioned in the issue. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231952 > > Webrev: https://cr.openjdk.java.net/~bulasevich/8231952/webrev.00/ > > > > Thanks, > > Christoph > > > From per.liden at oracle.com Tue Oct 15 08:12:51 2019 From: per.liden at oracle.com (Per Liden) Date: Tue, 15 Oct 2019 10:12:51 +0200 Subject: [13u] RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: <8233977.IFtUbavBte@erik-theta> References: <928d529c-02f4-f9f9-ea04-198d0659dc77@oracle.com> <8233977.IFtUbavBte@erik-theta> Message-ID: Thanks Erik! /Per On 10/15/19 9:15 AM, Erik ?sterlund wrote: > Hi Per, > > Looks good. > > Thanks, > /Erik > > On m?ndag 14 oktober 2019 kl. 23:43:16 CEST Per Liden wrote: >> Hi, >> >> Please review this back port of JDK-8230565 to 13u. This fix >> significantly improves stability of ZGC (or more specifically ZGC's C2 >> load barrier). The back port was trivial, but not completely clean, as >> it required manual merge to resolve 4 simple conflicts. >> >> Original bug: https://bugs.openjdk.java.net/browse/JDK-8230565 >> Original commit: https://hg.openjdk.java.net/jdk/jdk/rev/d376d86b0a01 >> >> JDK 13u webrev: http://cr.openjdk.java.net/~pliden/8230565/webrev.jdk13u >> >> Testing: >> - Tier1-3 on all Oracle platforms. >> - Tier1-6 on Linux/x64. >> - Multiple iterations of gc-test-suite on Linux/x64. >> - Builds on Linux/AArch64. >> >> /Per > From igor.veresov at oracle.com Tue Oct 15 13:26:15 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 15 Oct 2019 06:26:15 -0700 Subject: RFR(M) 8227003: Add high-level JIT compilation mode control mechanism In-Reply-To: References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> <1195c234-39a9-d0a2-51c6-ca4ab5af1de5@oracle.com> <503CCDF7-B688-4C45-8093-267E481A6D20@oracle.com> <027c46ce-c243-b392-cbdd-a16c55438252@oracle.com> <6AA316E4-0533-48D8-A575-C1B5E633C145@oracle.com> Message-ID: <262626E2-4BE8-47E7-86B5-57558E216E4C@oracle.com> > On Oct 15, 2019, at 12:05 AM, Claes Redestad wrote: > > > > On 2019-10-15 08:57, Igor Veresov wrote: >>> "For CSR purposes, only Hotspot's 'product' and 'manageable' flags are >>> considered exported interfaces that require a CSR request when they are >>> *added*, [...]": >>> >>> https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process >>> >>> My understanding is that we need a CSR for the product flag, but not the >>> diagnostic ones. >> Must be a new rule. Nobody every did it before. > > I don't make the rules. But a CSR isn't that much trouble either, > really. > I?ll look into that, thanks for the review. igor > /Claes From patric.hedlin at oracle.com Tue Oct 15 14:20:12 2019 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Tue, 15 Oct 2019 16:20:12 +0200 Subject: RFR(S): 8231565: More node budget assert in fuzzed test Message-ID: <7a0b347a-02f3-b841-82eb-f0887fd6d7f3@oracle.com> Dear all, I would like to ask for help to review the following change/update: Issue:? https://bugs.openjdk.java.net/browse/JDK-8231565 Webrev: http://cr.openjdk.java.net/~phedlin/tr8231565/ 8231565: More node budget assert in fuzzed test ??? Another bad estimate. Loop rotation is too poorly approximated ??? as a clone operation alone. Same ad-hoc. Testing: hs-tier1..3, hs-precheckin-comp, JavaFuzzer ??? Including new TC Best regards, Patric From tom.rodriguez at oracle.com Tue Oct 15 16:58:27 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 15 Oct 2019 09:58:27 -0700 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: <9b4d95f0-0a22-44b4-3bd8-ae61e4c2c293@loongson.cn> References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> <17aa1a3a-6129-73e0-c374-902f31cd1300@loongson.cn> <9b4d95f0-0a22-44b4-3bd8-ae61e4c2c293@loongson.cn> Message-ID: <2b2243d4-e067-417a-3854-8c2852a111b4@oracle.com> Sorry, I'd prepared this too quickly during a meeting. I've corrected the code at http://cr.openjdk.java.net/~never/8232083.1/webrev and built and ran both a normal and minimal JVM using these changes. tom Jie Fu wrote on 10/14/19 5:56 PM: > Hi Tom, > > Thanks for fixing this. > > The patch seems to break the vm build: > --------------------------------------------- > /home/fool/workspace/jdk-dev/src/hotspot/share/compiler/oopMap.cpp:343:3: error: > expected unqualified-id before '{' token > ?? { > ?? ^ > /home/fool/workspace/jdk-dev/src/hotspot/share/compiler/oopMap.cpp:394:1: error: > expected declaration before '}' token > ?} > ?^ > lib/CompileJvm.gmk:176: recipe for target > '/home/fool/workspace/jdk-dev/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/objs/oopMap.o' > failed > --------------------------------------------- > > Best regards, > Jie > > On 2019/10/15 ??4:34, Tom Rodriguez wrote: >> Yes I mistranslated this code in the case where that ifndef triggers. >> I think this http://cr.openjdk.java.net/~never/8232083/webrev/ is a >> better translation of the original code.? Can I get a review of this >> and I will push it. >> >> tom >> >> Jie Fu wrote on 10/13/19 11:35 PM: >>> Forward this to Tom. Thanks. >>> >>> On 2019/10/11 ??8:07, Jie Fu wrote: >>>> Hi all, >>>> >>>> JDK-8232151 had been fixed. >>>> >>>> Could you please review this fix and give me some advice? >>>> >>>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232083 >>>> Webrev: http://cr.openjdk.java.net/~jiefu/8232083/webrev.00/ >>>> >>>> Thanks a lot. >>>> Best regards, >>>> Jie >>>> >>>> On 2019/10/11 ??11:42, Jie Fu wrote: >>>>> Please hold off reviewing this until JDK-8232151 >>>>> is fixed. >>>> >>> > From nils.eliasson at oracle.com Tue Oct 15 10:07:51 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 15 Oct 2019 12:07:51 +0200 Subject: RFR: 8232165: Reduce allocations in ValueStack copying constructor In-Reply-To: <5e1dd9d7-2ea1-1026-13f9-8da698b8a110@oracle.com> References: <5e1dd9d7-2ea1-1026-13f9-8da698b8a110@oracle.com> Message-ID: <5c15d9d7-63a9-dce6-3721-24e0e2533e67@oracle.com> Hi Claes, Looks good. // Nils On 2019-10-11 13:42, Claes Redestad wrote: > Hi, > > this patch optimizes C1 ValueStack copying, which reduces unnecessary > allocations and has a small but measurable impact on compilation speed. > > Webrev: http://cr.openjdk.java.net/~redestad/8232165/open.00/ > Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232165 > > Testing: tier1-2 (tier3-4 ongoing) > > Thanks! > > /Claes From nils.eliasson at oracle.com Tue Oct 15 10:28:25 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 15 Oct 2019 12:28:25 +0200 Subject: RFR(XXS) 8232162: Object reallocation in Deoptimization::fetch_unroll_info_helper should not depend on EliminateNestedLocks In-Reply-To: <0b007915-27bd-5c66-ced6-e9223925aeaa@oracle.com> References: <0b007915-27bd-5c66-ced6-e9223925aeaa@oracle.com> Message-ID: <7225cc47-dab2-2f15-49ad-6121096e0e37@oracle.com> +1 // Nils On 2019-10-11 11:22, Tobias Hartmann wrote: > Hi Richard, > > looks good to me. > > Bets regards, > Tobias > > On 11.10.19 10:41, Reingruber, Richard wrote: >> Hi, >> >> could I please get reviews for >> >> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8232162/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8232162 >> >> The fix removes the C2 flag EliminateNestedLocks from the condition for reallocating objects, >> because C2 eliminates allocations depending only on DoEscapeAnalysis && EliminateAllocations. >> >> I put the patch through SAP's nightly testing (includes all platforms, jtreg tests, and more). >> >> Thanks, Richard. >> From nils.eliasson at oracle.com Tue Oct 15 10:49:45 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Tue, 15 Oct 2019 12:49:45 +0200 Subject: RFR(S): 8231565: More node budget assert in fuzzed test In-Reply-To: <7a0b347a-02f3-b841-82eb-f0887fd6d7f3@oracle.com> References: <7a0b347a-02f3-b841-82eb-f0887fd6d7f3@oracle.com> Message-ID: <041995d9-5211-fad0-b3c4-e69f22a6407e@oracle.com> Hi Patric, Looks good! // Nils On 2019-10-15 16:20, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8231565 > Webrev: http://cr.openjdk.java.net/~phedlin/tr8231565/ > > 8231565: More node budget assert in fuzzed test > > ??? Another bad estimate. Loop rotation is too poorly approximated > ??? as a clone operation alone. Same ad-hoc. > > > Testing: hs-tier1..3, hs-precheckin-comp, JavaFuzzer > ??? Including new TC > > > Best regards, > Patric > From fujie at loongson.cn Wed Oct 16 01:42:30 2019 From: fujie at loongson.cn (Jie Fu) Date: Wed, 16 Oct 2019 09:42:30 +0800 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: <2b2243d4-e067-417a-3854-8c2852a111b4@oracle.com> References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> <17aa1a3a-6129-73e0-c374-902f31cd1300@loongson.cn> <9b4d95f0-0a22-44b4-3bd8-ae61e4c2c293@loongson.cn> <2b2243d4-e067-417a-3854-8c2852a111b4@oracle.com> Message-ID: <340748b4-dc42-850f-9c51-d2667002a1bf@loongson.cn> Hi Tom, It looks good to me. I'm NOT a reviewer. How about the following change to the indentation? ------------------------------------------ diff -r a3b0294dfbb5 src/hotspot/share/compiler/oopMap.cpp --- a/src/hotspot/share/compiler/oopMap.cpp???? Wed Oct 16 09:27:33 2019 +0800 +++ b/src/hotspot/share/compiler/oopMap.cpp???? Wed Oct 16 09:32:48 2019 +0800 @@ -313,14 +313,14 @@ ?????? OopMapValue omv = oms.current(); ?????? if (omv.type() != OopMapValue::derived_oop_value) { ???????? continue; -??????? } +????? } ?#ifndef TIERED ?????? COMPILER1_PRESENT(ShouldNotReachHere();) ?#if INCLUDE_JVMCI -??????? if (UseJVMCICompiler) { -????????? ShouldNotReachHere(); -??????? } +????? if (UseJVMCICompiler) { +??????? ShouldNotReachHere(); +????? } ?#endif ?#endif // !TIERED ?????? oop* loc = fr->oopmapreg_to_location(omv.reg(),reg_map); ------------------------------------------ Thanks a lot. Best regards, Jie On 2019/10/16 ??12:58, Tom Rodriguez wrote: > I've corrected the code at > http://cr.openjdk.java.net/~never/8232083.1/webrev and built and ran > both a normal and minimal JVM using these changes. From david.holmes at oracle.com Wed Oct 16 07:11:07 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 16 Oct 2019 17:11:07 +1000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: Message-ID: Hi Martin, On 15/10/2019 12:50 am, Doerr, Martin wrote: > Hi David, > >>> As C1 and C2 compiler threads are hidden, I still don't see any problems reusing the Thread objects. > >> They are not completely hidden. Those j.l.Thread objects are still part of the system thread group and can be found by other code. > > I know that they are part of the system thread group, but I thought they > should not be visible to Java. > > E.g. > > ??????? ThreadGroup tg = new ThreadGroup("A"); > ??????? ThreadGroup stg = tg.getParent().getParent(); > ??????? Thread[] list = new Thread[100]; > ??????? stg.enumerate(list); > ??????? System.out.println("Listing elements of " + stg); > ??????? for (int i = 0; i < list.length; ++i) { > ??????????? if (list[i] != null) { > ??????????????? System.out.println(i + ": " + list[i]); > ??????????? } > ??????? } > > Finds: > > Listing elements of java.lang.ThreadGroup[name=system,maxpri=10] > > 0: Thread[Reference Handler,10,system] > 1: Thread[Finalizer,8,system] > 2: Thread[Signal Dispatcher,9,system] > 3: Thread[main,5,main] > > I can?t see any compiler threads. Yes you are right. I had forgotten about this other quirk in this whole arrangement. Threads started directly by the VM, rather than via Thread.start, don't call ThreadGroup.add unless the VM explicitly makes that call - which it does for the Signal Dispatcher thread and a couple of others. The compiler threads aren't included so while they consider themselves to be part of the system ThreadGroup, from the group's perspective they are "unstarted threads" - something which is itself somewhat of an oddity. But that does mean they are not discoverable that way. > Do you mean finding them by JVMTI agent? > > As I understand the Spec, compiler threads should be excluded for > GetAllThreads: ?The threads are Java programming language threads? They are hidden from JVMTI (unlike the JVMCI compiler threads) > Or what did you mean by ?other code? which can see C1 and C2 threads? I did mean by enumerating the system ThreadGroup. So for C1/C2 compiler threads we can probably get away with reusing the j.l.Thread object. Thanks, David ----- > Best regards, > > Martin > From martin.doerr at sap.com Wed Oct 16 09:55:37 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 16 Oct 2019 09:55:37 +0000 Subject: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 instructions on processors which don't support it In-Reply-To: <4a95f98e-828f-cacc-830c-41de918dda9f@oracle.com> References: <4a95f98e-828f-cacc-830c-41de918dda9f@oracle.com> Message-ID: Thanks for the review. Pushed. Best regards, Martin > -----Original Message----- > From: Tobias Hartmann > Sent: Montag, 14. Oktober 2019 20:22 > To: Doerr, Martin ; Vladimir Kozlov > ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(XS): 8232106: [x86] C2: SIGILL due to usage of SSSE3 > instructions on processors which don't support it > > > On 14.10.19 06:44, Doerr, Martin wrote: > > @Tobias > > Can I consider it reviewed? Or are there any concerns? > > Reviewed. > > Best regards, > Tobias From per.liden at oracle.com Wed Oct 16 10:43:23 2019 From: per.liden at oracle.com (Per Liden) Date: Wed, 16 Oct 2019 12:43:23 +0200 Subject: RFR: 8230565: ZGC: Redesign C2 load barrier to expand on the MachNode level In-Reply-To: <2d1a4717-76cc-fea6-727d-5ffb21a2fe9c@oracle.com> References: <41d1807c-f4b7-2b74-11c2-e0d9fc5784ca@oracle.com> <655c746e-2456-4422-5c14-d49e08864acf@oracle.com> <2d1a4717-76cc-fea6-727d-5ffb21a2fe9c@oracle.com> Message-ID: <284b4375-130c-0138-bcc7-66179132ff56@oracle.com> Hi, On 10/11/19 10:15 AM, Nils Eliasson wrote: > > On 2019-10-10 20:57, Andrew Haley wrote: >> On 10/8/19 2:37 PM, Nils Eliasson wrote: >>> For the non-Aarch64 parts: Looks good! >> +int MacroAssembler::pop_fp(unsigned int bitset, Register stack) { >> +? int words_pushed = 0; >> + >> +? // Scan bitset to accumulate register pairs >> +? unsigned char regs[32]; >> +? int count = 0; >> +? for (int reg = 0; reg <= 31; reg++) { >> +??? if (1 & bitset) >> +????? regs[count++] = reg; >> +??? bitset >>= 1; >> +? } >> +? regs[count++] = zr->encoding_nocheck(); >> >> This use of ZR looks wrong in FP code. There is no floating-point ZR. >> > Right. We shouldn't use zr here - but any register will do since its > just padding to get an even count of spills. > > -? regs[count++] = zr->encoding_nocheck(); > > + regs[count++] = 0; // Add reg 0 as padding - we want to spill an even > number of registers > > // Nils > Nils, will you file a bug and fix this? cheers, Per From martin.doerr at sap.com Wed Oct 16 13:09:17 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 16 Oct 2019 13:09:17 +0000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: Message-ID: Hi David, thanks for confirming. So I suggest to fix it like this: http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.00/ Best regards, Martin > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 16. Oktober 2019 09:11 > To: Doerr, Martin > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; David Holmes > Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread > > Hi Martin, > > On 15/10/2019 12:50 am, Doerr, Martin wrote: > > Hi David, > > > >>> As C1 and C2 compiler threads are hidden, I still don't see any problems > reusing the Thread objects. > > > >> They are not completely hidden. Those j.l.Thread objects are still part of > the system thread group and can be found by other code. > > > > I know that they are part of the system thread group, but I thought they > > should not be visible to Java. > > > > E.g. > > > > ??????? ThreadGroup tg = new ThreadGroup("A"); > > ??????? ThreadGroup stg = tg.getParent().getParent(); > > ??????? Thread[] list = new Thread[100]; > > ??????? stg.enumerate(list); > > ??????? System.out.println("Listing elements of " + stg); > > ??????? for (int i = 0; i < list.length; ++i) { > > ??????????? if (list[i] != null) { > > ??????????????? System.out.println(i + ": " + list[i]); > > ??????????? } > > ??????? } > > > > Finds: > > > > Listing elements of java.lang.ThreadGroup[name=system,maxpri=10] > > > > 0: Thread[Reference Handler,10,system] > > 1: Thread[Finalizer,8,system] > > 2: Thread[Signal Dispatcher,9,system] > > 3: Thread[main,5,main] > > > > I can't see any compiler threads. > > Yes you are right. I had forgotten about this other quirk in this whole > arrangement. Threads started directly by the VM, rather than via > Thread.start, don't call ThreadGroup.add unless the VM explicitly makes > that call - which it does for the Signal Dispatcher thread and a couple > of others. The compiler threads aren't included so while they consider > themselves to be part of the system ThreadGroup, from the group's > perspective they are "unstarted threads" - something which is itself > somewhat of an oddity. But that does mean they are not discoverable that > way. > > > Do you mean finding them by JVMTI agent? > > > > As I understand the Spec, compiler threads should be excluded for > > GetAllThreads: "The threads are Java programming language threads" > > They are hidden from JVMTI (unlike the JVMCI compiler threads) > > > Or what did you mean by "other code" which can see C1 and C2 threads? > > I did mean by enumerating the system ThreadGroup. > > So for C1/C2 compiler threads we can probably get away with reusing the > j.l.Thread object. > > Thanks, > David > ----- > > > Best regards, > > > > Martin > > From richard.reingruber at sap.com Wed Oct 16 15:02:01 2019 From: richard.reingruber at sap.com (Reingruber, Richard) Date: Wed, 16 Oct 2019 15:02:01 +0000 Subject: RFR(XXS) 8232162: Object reallocation in Deoptimization::fetch_unroll_info_helper should not depend on EliminateNestedLocks In-Reply-To: <7225cc47-dab2-2f15-49ad-6121096e0e37@oracle.com> References: <0b007915-27bd-5c66-ced6-e9223925aeaa@oracle.com> <7225cc47-dab2-2f15-49ad-6121096e0e37@oracle.com> Message-ID: Hi Nils and Tobias, thanks for your reviews. I will push the change tomorrow. Best regards, Richard. -----Original Message----- From: hotspot-compiler-dev On Behalf Of Nils Eliasson Sent: Dienstag, 15. Oktober 2019 12:28 To: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(XXS) 8232162: Object reallocation in Deoptimization::fetch_unroll_info_helper should not depend on EliminateNestedLocks +1 // Nils On 2019-10-11 11:22, Tobias Hartmann wrote: > Hi Richard, > > looks good to me. > > Bets regards, > Tobias > > On 11.10.19 10:41, Reingruber, Richard wrote: >> Hi, >> >> could I please get reviews for >> >> Webrev: http://cr.openjdk.java.net/~rrich/webrevs/2019/8232162/webrev.0/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8232162 >> >> The fix removes the C2 flag EliminateNestedLocks from the condition for reallocating objects, >> because C2 eliminates allocations depending only on DoEscapeAnalysis && EliminateAllocations. >> >> I put the patch through SAP's nightly testing (includes all platforms, jtreg tests, and more). >> >> Thanks, Richard. >> From tom.rodriguez at oracle.com Wed Oct 16 20:11:56 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Oct 2019 13:11:56 -0700 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: <340748b4-dc42-850f-9c51-d2667002a1bf@loongson.cn> References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> <17aa1a3a-6129-73e0-c374-902f31cd1300@loongson.cn> <9b4d95f0-0a22-44b4-3bd8-ae61e4c2c293@loongson.cn> <2b2243d4-e067-417a-3854-8c2852a111b4@oracle.com> <340748b4-dc42-850f-9c51-d2667002a1bf@loongson.cn> Message-ID: Jie Fu wrote on 10/15/19 6:42 PM: > Hi Tom, > > It looks good to me. I'm NOT a reviewer. > > How about the following change to the indentation? Yes I've corrected that in place. Can I get a review from a reviewer? tom > ------------------------------------------ > diff -r a3b0294dfbb5 src/hotspot/share/compiler/oopMap.cpp > --- a/src/hotspot/share/compiler/oopMap.cpp???? Wed Oct 16 09:27:33 2019 > +0800 > +++ b/src/hotspot/share/compiler/oopMap.cpp???? Wed Oct 16 09:32:48 2019 > +0800 > @@ -313,14 +313,14 @@ > ?????? OopMapValue omv = oms.current(); > ?????? if (omv.type() != OopMapValue::derived_oop_value) { > ???????? continue; > -??????? } > +????? } > > ?#ifndef TIERED > ?????? COMPILER1_PRESENT(ShouldNotReachHere();) > ?#if INCLUDE_JVMCI > -??????? if (UseJVMCICompiler) { > -????????? ShouldNotReachHere(); > -??????? } > +????? if (UseJVMCICompiler) { > +??????? ShouldNotReachHere(); > +????? } > ?#endif > ?#endif // !TIERED > ?????? oop* loc = fr->oopmapreg_to_location(omv.reg(),reg_map); > ------------------------------------------ > > Thanks a lot. > Best regards, > Jie > > On 2019/10/16 ??12:58, Tom Rodriguez wrote: >> I've corrected the code at >> http://cr.openjdk.java.net/~never/8232083.1/webrev and built and ran >> both a normal and minimal JVM using these changes. > From suenaga at oss.nttdata.com Wed Oct 16 23:25:50 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 17 Oct 2019 08:25:50 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 Message-ID: (Re-send email because I could not send original email to serviceability-dev and hotspot-compiler-dev) Hi, We discussed the fix for JDK-8232084 in [1], and I think we should fix it with #pragma. I uploaded new webrev. Could you review it? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ This change has passed the tests on submit repo (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). Thanks, Yasumasa [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html From suenaga at oss.nttdata.com Wed Oct 16 23:19:53 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 17 Oct 2019 08:19:53 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 Message-ID: <76501d6e-51b4-c092-8fc6-13f5ea80ddd7@oss.nttdata.com> Hi, We discussed the fix for JDK-8232084 in [1], and I think we should fix it with #pragma. I uploaded new webrev. Could you review it? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ This change has passed the tests on submit repo (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). Thanks, Yasumasa [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html From chris.plummer at oracle.com Thu Oct 17 00:16:43 2019 From: chris.plummer at oracle.com (Chris Plummer) Date: Wed, 16 Oct 2019 17:16:43 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: Message-ID: <049c16bd-bd0b-23c2-032e-638cd67f9800@oracle.com> Looks good. Chris On 10/16/19 4:25 PM, Yasumasa Suenaga wrote: > (Re-send email because I could not send original email to > serviceability-dev and hotspot-compiler-dev) > > Hi, > > We discussed the fix for JDK-8232084 in [1], and I think we should fix > it with #pragma. > I uploaded new webrev. Could you review it? > > ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 > ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ > > This change has passed the tests on submit repo > (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). > > > Thanks, > > Yasumasa > > > [1] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html From suenaga at oss.nttdata.com Thu Oct 17 00:32:18 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 17 Oct 2019 09:32:18 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> Message-ID: <5cbf8932-4143-f459-b3cb-a18efbfbfae0@oss.nttdata.com> Hi Serguei, On 2019/10/17 9:07, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > It looks good. > One tip: > > + // This code would be warned as "stringop-truncation" by GCC 8 or later. > +PRAGMA_DIAG_PUSH > +PRAGMA_STRINGOP_TRUNCATION_IGNORED > strncpy(buf, str, len); > +PRAGMA_DIAG_POP > > > I'd suggest to place the comment before the line with strncopy(). Ok, I will move the comment before push. Yasumasa > Not? subject for re-review. > > Thanks, > Serguei > > > On 10/16/19 16:25, Yasumasa Suenaga wrote: >> (Re-send email because I could not send original email to serviceability-dev and hotspot-compiler-dev) >> >> Hi, >> >> We discussed the fix for JDK-8232084 in [1], and I think we should fix it with #pragma. >> I uploaded new webrev. Could you review it? >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >> >> This change has passed the tests on submit repo (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html > From david.holmes at oracle.com Thu Oct 17 00:34:57 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2019 10:34:57 +1000 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> Message-ID: <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: > Hi Yasumasa, > > It looks good. > One tip: > > + // This code would be warned as "stringop-truncation" by GCC 8 or later. > +PRAGMA_DIAG_PUSH > +PRAGMA_STRINGOP_TRUNCATION_IGNORED > strncpy(buf, str, len); > +PRAGMA_DIAG_POP > > > I'd suggest to place the comment before the line with strncopy(). I'd suggest just dropping the comment as it adds nothing, further gcc 8 is not flagging this use of strncpy. Otherwise okay. Thanks, David > Not? subject for re-review. > > Thanks, > Serguei > > > On 10/16/19 16:25, Yasumasa Suenaga wrote: >> (Re-send email because I could not send original email to >> serviceability-dev and hotspot-compiler-dev) >> >> Hi, >> >> We discussed the fix for JDK-8232084 in [1], and I think we should fix >> it with #pragma. >> I uploaded new webrev. Could you review it? >> >> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >> >> This change has passed the tests on submit repo >> (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >> >> >> Thanks, >> >> Yasumasa >> >> >> [1] >> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html > From suenaga at oss.nttdata.com Thu Oct 17 02:19:42 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 17 Oct 2019 11:19:42 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> Message-ID: <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> On 2019/10/17 9:34, David Holmes wrote: > On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: >> Hi Yasumasa, >> >> It looks good. >> One tip: >> >> + // This code would be warned as "stringop-truncation" by GCC 8 or later. >> +PRAGMA_DIAG_PUSH >> +PRAGMA_STRINGOP_TRUNCATION_IGNORED >> ??????? strncpy(buf, str, len); >> +PRAGMA_DIAG_POP >> >> >> I'd suggest to place the comment before the line with strncopy(). > > I'd suggest just dropping the comment as it adds nothing, further gcc 8 is not flagging this use of strncpy. The comment is suggested in [1]. Indeed stringop-truncation warning was not reported by GCC 8, but this option introduced in it, and I agree with Ioi to add the comment for other developers why this #pragma is needed. Yasumasa [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029578.html > Otherwise okay. > > Thanks, > David > >> Not? subject for re-review. >> >> Thanks, >> Serguei >> >> >> On 10/16/19 16:25, Yasumasa Suenaga wrote: >>> (Re-send email because I could not send original email to serviceability-dev and hotspot-compiler-dev) >>> >>> Hi, >>> >>> We discussed the fix for JDK-8232084 in [1], and I think we should fix it with #pragma. >>> I uploaded new webrev. Could you review it? >>> >>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >>> >>> This change has passed the tests on submit repo (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >>> >>> >>> Thanks, >>> >>> Yasumasa >>> >>> >>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html >> From david.holmes at oracle.com Thu Oct 17 02:39:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2019 12:39:03 +1000 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> Message-ID: On 17/10/2019 12:19 pm, Yasumasa Suenaga wrote: > On 2019/10/17 9:34, David Holmes wrote: >> On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: >>> Hi Yasumasa, >>> >>> It looks good. >>> One tip: >>> >>> + // This code would be warned as "stringop-truncation" by GCC 8 or >>> later. >>> +PRAGMA_DIAG_PUSH >>> +PRAGMA_STRINGOP_TRUNCATION_IGNORED >>> ??????? strncpy(buf, str, len); >>> +PRAGMA_DIAG_POP >>> >>> >>> I'd suggest to place the comment before the line with strncopy(). >> >> I'd suggest just dropping the comment as it adds nothing, further gcc >> 8 is not flagging this use of strncpy. > > The comment is suggested in [1]. > Indeed stringop-truncation warning was not reported by GCC 8, but this > option introduced in it, > and I agree with Ioi to add the comment for other developers why this > #pragma is needed. PRAGMA_STRINGOP_TRUNCATION_IGNORED seems to pretty clearly state what the issue is to me. But if you want to add a comment to make that more clear fine. But don't mention gcc 8 as it is not relevant to the need for the pragma now. Thanks, David > > Yasumasa > > > [1] > https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029578.html > > >> Otherwise okay. >> >> Thanks, >> David >> >>> Not? subject for re-review. >>> >>> Thanks, >>> Serguei >>> >>> >>> On 10/16/19 16:25, Yasumasa Suenaga wrote: >>>> (Re-send email because I could not send original email to >>>> serviceability-dev and hotspot-compiler-dev) >>>> >>>> Hi, >>>> >>>> We discussed the fix for JDK-8232084 in [1], and I think we should >>>> fix it with #pragma. >>>> I uploaded new webrev. Could you review it? >>>> >>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >>>> >>>> This change has passed the tests on submit repo >>>> (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >>>> >>>> >>>> Thanks, >>>> >>>> Yasumasa >>>> >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html >>>> >>> From suenaga at oss.nttdata.com Thu Oct 17 02:45:56 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 17 Oct 2019 11:45:56 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> Message-ID: On 2019/10/17 11:39, David Holmes wrote: > On 17/10/2019 12:19 pm, Yasumasa Suenaga wrote: >> On 2019/10/17 9:34, David Holmes wrote: >>> On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: >>>> Hi Yasumasa, >>>> >>>> It looks good. >>>> One tip: >>>> >>>> + // This code would be warned as "stringop-truncation" by GCC 8 or later. >>>> +PRAGMA_DIAG_PUSH >>>> +PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>> ??????? strncpy(buf, str, len); >>>> +PRAGMA_DIAG_POP >>>> >>>> >>>> I'd suggest to place the comment before the line with strncopy(). >>> >>> I'd suggest just dropping the comment as it adds nothing, further gcc 8 is not flagging this use of strncpy. >> >> The comment is suggested in [1]. >> Indeed stringop-truncation warning was not reported by GCC 8, but this option introduced in it, >> and I agree with Ioi to add the comment for other developers why this #pragma is needed. > > PRAGMA_STRINGOP_TRUNCATION_IGNORED > > seems to pretty clearly state what the issue is to me. But if you want to add a comment to make that more clear fine. But don't mention gcc 8 as it is not relevant to the need for the pragma now. I'd like to change the comment as below: This code would be warned as "stringop-truncation" by modern GCC Is it ok? Yasumasa > Thanks, > David > >> >> Yasumasa >> >> >> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029578.html >> >>> Otherwise okay. >>> >>> Thanks, >>> David >>> >>>> Not? subject for re-review. >>>> >>>> Thanks, >>>> Serguei >>>> >>>> >>>> On 10/16/19 16:25, Yasumasa Suenaga wrote: >>>>> (Re-send email because I could not send original email to serviceability-dev and hotspot-compiler-dev) >>>>> >>>>> Hi, >>>>> >>>>> We discussed the fix for JDK-8232084 in [1], and I think we should fix it with #pragma. >>>>> I uploaded new webrev. Could you review it? >>>>> >>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >>>>> >>>>> This change has passed the tests on submit repo (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html >>>> From david.holmes at oracle.com Thu Oct 17 03:49:48 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2019 13:49:48 +1000 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> Message-ID: <49bdd2e7-50ef-3009-3ca0-ed4ae2a14f4d@oracle.com> On 17/10/2019 12:45 pm, Yasumasa Suenaga wrote: > On 2019/10/17 11:39, David Holmes wrote: >> On 17/10/2019 12:19 pm, Yasumasa Suenaga wrote: >>> On 2019/10/17 9:34, David Holmes wrote: >>>> On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: >>>>> Hi Yasumasa, >>>>> >>>>> It looks good. >>>>> One tip: >>>>> >>>>> + // This code would be warned as "stringop-truncation" by GCC 8 or >>>>> later. >>>>> +PRAGMA_DIAG_PUSH >>>>> +PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>>> ??????? strncpy(buf, str, len); >>>>> +PRAGMA_DIAG_POP >>>>> >>>>> >>>>> I'd suggest to place the comment before the line with strncopy(). >>>> >>>> I'd suggest just dropping the comment as it adds nothing, further >>>> gcc 8 is not flagging this use of strncpy. >>> >>> The comment is suggested in [1]. >>> Indeed stringop-truncation warning was not reported by GCC 8, but >>> this option introduced in it, >>> and I agree with Ioi to add the comment for other developers why this >>> #pragma is needed. >> >> PRAGMA_STRINGOP_TRUNCATION_IGNORED >> >> seems to pretty clearly state what the issue is to me. But if you want >> to add a comment to make that more clear fine. But don't mention gcc 8 >> as it is not relevant to the need for the pragma now. > > I'd like to change the comment as below: > > ??? This code would be warned as "stringop-truncation" by modern GCC > > Is it ok? Grammatically it needs work. I propose // This code can cause a "stringop-truncation" warning with gcc "modern" will become inaccurate as time goes by. Thanks, David > > Yasumasa > > >> Thanks, >> David >> >>> >>> Yasumasa >>> >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029578.html >>> >>> >>>> Otherwise okay. >>>> >>>> Thanks, >>>> David >>>> >>>>> Not? subject for re-review. >>>>> >>>>> Thanks, >>>>> Serguei >>>>> >>>>> >>>>> On 10/16/19 16:25, Yasumasa Suenaga wrote: >>>>>> (Re-send email because I could not send original email to >>>>>> serviceability-dev and hotspot-compiler-dev) >>>>>> >>>>>> Hi, >>>>>> >>>>>> We discussed the fix for JDK-8232084 in [1], and I think we should >>>>>> fix it with #pragma. >>>>>> I uploaded new webrev. Could you review it? >>>>>> >>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >>>>>> >>>>>> This change has passed the tests on submit repo >>>>>> (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] >>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html >>>>>> >>>>> From suenaga at oss.nttdata.com Thu Oct 17 04:20:10 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 17 Oct 2019 13:20:10 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <49bdd2e7-50ef-3009-3ca0-ed4ae2a14f4d@oracle.com> References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> <49bdd2e7-50ef-3009-3ca0-ed4ae2a14f4d@oracle.com> Message-ID: <7b9158b9-f119-8a03-59e3-28194bad703b@oss.nttdata.com> On 2019/10/17 12:49, David Holmes wrote: > On 17/10/2019 12:45 pm, Yasumasa Suenaga wrote: >> On 2019/10/17 11:39, David Holmes wrote: >>> On 17/10/2019 12:19 pm, Yasumasa Suenaga wrote: >>>> On 2019/10/17 9:34, David Holmes wrote: >>>>> On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: >>>>>> Hi Yasumasa, >>>>>> >>>>>> It looks good. >>>>>> One tip: >>>>>> >>>>>> + // This code would be warned as "stringop-truncation" by GCC 8 or later. >>>>>> +PRAGMA_DIAG_PUSH >>>>>> +PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>>>> ??????? strncpy(buf, str, len); >>>>>> +PRAGMA_DIAG_POP >>>>>> >>>>>> >>>>>> I'd suggest to place the comment before the line with strncopy(). >>>>> >>>>> I'd suggest just dropping the comment as it adds nothing, further gcc 8 is not flagging this use of strncpy. >>>> >>>> The comment is suggested in [1]. >>>> Indeed stringop-truncation warning was not reported by GCC 8, but this option introduced in it, >>>> and I agree with Ioi to add the comment for other developers why this #pragma is needed. >>> >>> PRAGMA_STRINGOP_TRUNCATION_IGNORED >>> >>> seems to pretty clearly state what the issue is to me. But if you want to add a comment to make that more clear fine. But don't mention gcc 8 as it is not relevant to the need for the pragma now. >> >> I'd like to change the comment as below: >> >> ???? This code would be warned as "stringop-truncation" by modern GCC >> >> Is it ok? > > Grammatically it needs work. I propose > > // This code can cause a "stringop-truncation" warning with gcc > > "modern" will become inaccurate as time goes by. Thanks! To be clear that our code is correct, I will change the comment as below: // This code can cause a "stringop-truncation" warning with gcc incorrectly Yasumasa > Thanks, > David > >> >> Yasumasa >> >> >>> Thanks, >>> David >>> >>>> >>>> Yasumasa >>>> >>>> >>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029578.html >>>> >>>>> Otherwise okay. >>>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> Not? subject for re-review. >>>>>> >>>>>> Thanks, >>>>>> Serguei >>>>>> >>>>>> >>>>>> On 10/16/19 16:25, Yasumasa Suenaga wrote: >>>>>>> (Re-send email because I could not send original email to serviceability-dev and hotspot-compiler-dev) >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> We discussed the fix for JDK-8232084 in [1], and I think we should fix it with #pragma. >>>>>>> I uploaded new webrev. Could you review it? >>>>>>> >>>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >>>>>>> >>>>>>> This change has passed the tests on submit repo (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html >>>>>> From david.holmes at oracle.com Thu Oct 17 04:21:34 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2019 14:21:34 +1000 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <7b9158b9-f119-8a03-59e3-28194bad703b@oss.nttdata.com> References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> <49bdd2e7-50ef-3009-3ca0-ed4ae2a14f4d@oracle.com> <7b9158b9-f119-8a03-59e3-28194bad703b@oss.nttdata.com> Message-ID: <2d459846-8329-0df0-17d0-8f544b0daf81@oracle.com> On 17/10/2019 2:20 pm, Yasumasa Suenaga wrote: > On 2019/10/17 12:49, David Holmes wrote: >> On 17/10/2019 12:45 pm, Yasumasa Suenaga wrote: >>> On 2019/10/17 11:39, David Holmes wrote: >>>> On 17/10/2019 12:19 pm, Yasumasa Suenaga wrote: >>>>> On 2019/10/17 9:34, David Holmes wrote: >>>>>> On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>> Hi Yasumasa, >>>>>>> >>>>>>> It looks good. >>>>>>> One tip: >>>>>>> >>>>>>> + // This code would be warned as "stringop-truncation" by GCC 8 >>>>>>> or later. >>>>>>> +PRAGMA_DIAG_PUSH >>>>>>> +PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>>>>> ??????? strncpy(buf, str, len); >>>>>>> +PRAGMA_DIAG_POP >>>>>>> >>>>>>> >>>>>>> I'd suggest to place the comment before the line with strncopy(). >>>>>> >>>>>> I'd suggest just dropping the comment as it adds nothing, further >>>>>> gcc 8 is not flagging this use of strncpy. >>>>> >>>>> The comment is suggested in [1]. >>>>> Indeed stringop-truncation warning was not reported by GCC 8, but >>>>> this option introduced in it, >>>>> and I agree with Ioi to add the comment for other developers why >>>>> this #pragma is needed. >>>> >>>> PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>> >>>> seems to pretty clearly state what the issue is to me. But if you >>>> want to add a comment to make that more clear fine. But don't >>>> mention gcc 8 as it is not relevant to the need for the pragma now. >>> >>> I'd like to change the comment as below: >>> >>> ???? This code would be warned as "stringop-truncation" by modern GCC >>> >>> Is it ok? >> >> Grammatically it needs work. I propose >> >> // This code can cause a "stringop-truncation" warning with gcc >> >> "modern" will become inaccurate as time goes by. > > Thanks! > To be clear that our code is correct, I will change the comment as below: > > ? // This code can cause a "stringop-truncation" warning with gcc > incorrectly // This code can incorrectly cause a "stringop-truncation" warning with gcc Assuming Ioi feels that is sufficient. Thanks, David > > Yasumasa > > >> Thanks, >> David >> >>> >>> Yasumasa >>> >>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>> [1] >>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029578.html >>>>> >>>>> >>>>>> Otherwise okay. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Not? subject for re-review. >>>>>>> >>>>>>> Thanks, >>>>>>> Serguei >>>>>>> >>>>>>> >>>>>>> On 10/16/19 16:25, Yasumasa Suenaga wrote: >>>>>>>> (Re-send email because I could not send original email to >>>>>>>> serviceability-dev and hotspot-compiler-dev) >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We discussed the fix for JDK-8232084 in [1], and I think we >>>>>>>> should fix it with #pragma. >>>>>>>> I uploaded new webrev. Could you review it? >>>>>>>> >>>>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>>>>> ? webrev: >>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >>>>>>>> >>>>>>>> This change has passed the tests on submit repo >>>>>>>> (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >>>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] >>>>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html >>>>>>>> >>>>>>> From suenaga at oss.nttdata.com Thu Oct 17 04:25:30 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Thu, 17 Oct 2019 13:25:30 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: <2d459846-8329-0df0-17d0-8f544b0daf81@oracle.com> References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> <49bdd2e7-50ef-3009-3ca0-ed4ae2a14f4d@oracle.com> <7b9158b9-f119-8a03-59e3-28194bad703b@oss.nttdata.com> <2d459846-8329-0df0-17d0-8f544b0daf81@oracle.com> Message-ID: On 2019/10/17 13:21, David Holmes wrote: > On 17/10/2019 2:20 pm, Yasumasa Suenaga wrote: >> On 2019/10/17 12:49, David Holmes wrote: >>> On 17/10/2019 12:45 pm, Yasumasa Suenaga wrote: >>>> On 2019/10/17 11:39, David Holmes wrote: >>>>> On 17/10/2019 12:19 pm, Yasumasa Suenaga wrote: >>>>>> On 2019/10/17 9:34, David Holmes wrote: >>>>>>> On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>> Hi Yasumasa, >>>>>>>> >>>>>>>> It looks good. >>>>>>>> One tip: >>>>>>>> >>>>>>>> + // This code would be warned as "stringop-truncation" by GCC 8 or later. >>>>>>>> +PRAGMA_DIAG_PUSH >>>>>>>> +PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>>>>>> ??????? strncpy(buf, str, len); >>>>>>>> +PRAGMA_DIAG_POP >>>>>>>> >>>>>>>> >>>>>>>> I'd suggest to place the comment before the line with strncopy(). >>>>>>> >>>>>>> I'd suggest just dropping the comment as it adds nothing, further gcc 8 is not flagging this use of strncpy. >>>>>> >>>>>> The comment is suggested in [1]. >>>>>> Indeed stringop-truncation warning was not reported by GCC 8, but this option introduced in it, >>>>>> and I agree with Ioi to add the comment for other developers why this #pragma is needed. >>>>> >>>>> PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>>> >>>>> seems to pretty clearly state what the issue is to me. But if you want to add a comment to make that more clear fine. But don't mention gcc 8 as it is not relevant to the need for the pragma now. >>>> >>>> I'd like to change the comment as below: >>>> >>>> ???? This code would be warned as "stringop-truncation" by modern GCC >>>> >>>> Is it ok? >>> >>> Grammatically it needs work. I propose >>> >>> // This code can cause a "stringop-truncation" warning with gcc >>> >>> "modern" will become inaccurate as time goes by. >> >> Thanks! >> To be clear that our code is correct, I will change the comment as below: >> >> ?? // This code can cause a "stringop-truncation" warning with gcc incorrectly > > // This code can incorrectly cause a "stringop-truncation" warning with gcc > > Assuming Ioi feels that is sufficient. Thanks! and sorry for my English... Yasumasa > Thanks, > David > >> >> Yasumasa >> >> >>> Thanks, >>> David >>> >>>> >>>> Yasumasa >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029578.html >>>>>> >>>>>>> Otherwise okay. >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> Not? subject for re-review. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Serguei >>>>>>>> >>>>>>>> >>>>>>>> On 10/16/19 16:25, Yasumasa Suenaga wrote: >>>>>>>>> (Re-send email because I could not send original email to serviceability-dev and hotspot-compiler-dev) >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> We discussed the fix for JDK-8232084 in [1], and I think we should fix it with #pragma. >>>>>>>>> I uploaded new webrev. Could you review it? >>>>>>>>> >>>>>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >>>>>>>>> >>>>>>>>> This change has passed the tests on submit repo (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> >>>>>>>>> Yasumasa >>>>>>>>> >>>>>>>>> >>>>>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html >>>>>>>> From ioi.lam at oracle.com Thu Oct 17 04:54:22 2019 From: ioi.lam at oracle.com (Ioi Lam) Date: Wed, 16 Oct 2019 21:54:22 -0700 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> <49bdd2e7-50ef-3009-3ca0-ed4ae2a14f4d@oracle.com> <7b9158b9-f119-8a03-59e3-28194bad703b@oss.nttdata.com> <2d459846-8329-0df0-17d0-8f544b0daf81@oracle.com> Message-ID: On 10/16/19 9:25 PM, Yasumasa Suenaga wrote: > On 2019/10/17 13:21, David Holmes wrote: >> On 17/10/2019 2:20 pm, Yasumasa Suenaga wrote: >>> On 2019/10/17 12:49, David Holmes wrote: >>>> On 17/10/2019 12:45 pm, Yasumasa Suenaga wrote: >>>>> On 2019/10/17 11:39, David Holmes wrote: >>>>>> On 17/10/2019 12:19 pm, Yasumasa Suenaga wrote: >>>>>>> On 2019/10/17 9:34, David Holmes wrote: >>>>>>>> On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>> Hi Yasumasa, >>>>>>>>> >>>>>>>>> It looks good. >>>>>>>>> One tip: >>>>>>>>> >>>>>>>>> + // This code would be warned as "stringop-truncation" by GCC >>>>>>>>> 8 or later. >>>>>>>>> +PRAGMA_DIAG_PUSH >>>>>>>>> +PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>>>>>>> ??????? strncpy(buf, str, len); >>>>>>>>> +PRAGMA_DIAG_POP >>>>>>>>> >>>>>>>>> >>>>>>>>> I'd suggest to place the comment before the line with strncopy(). >>>>>>>> >>>>>>>> I'd suggest just dropping the comment as it adds nothing, >>>>>>>> further gcc 8 is not flagging this use of strncpy. >>>>>>> >>>>>>> The comment is suggested in [1]. >>>>>>> Indeed stringop-truncation warning was not reported by GCC 8, >>>>>>> but this option introduced in it, >>>>>>> and I agree with Ioi to add the comment for other developers why >>>>>>> this #pragma is needed. >>>>>> >>>>>> PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>>>> >>>>>> seems to pretty clearly state what the issue is to me. But if you >>>>>> want to add a comment to make that more clear fine. But don't >>>>>> mention gcc 8 as it is not relevant to the need for the pragma now. >>>>> >>>>> I'd like to change the comment as below: >>>>> >>>>> ???? This code would be warned as "stringop-truncation" by modern GCC >>>>> >>>>> Is it ok? >>>> >>>> Grammatically it needs work. I propose >>>> >>>> // This code can cause a "stringop-truncation" warning with gcc >>>> >>>> "modern" will become inaccurate as time goes by. >>> >>> Thanks! >>> To be clear that our code is correct, I will change the comment as >>> below: >>> >>> ?? // This code can cause a "stringop-truncation" warning with gcc >>> incorrectly >> >> // This code can incorrectly cause a "stringop-truncation" warning >> with gcc >> >> Assuming Ioi feels that is sufficient. > > Thanks! and sorry for my English... > > Yasumasa > I am happy with David's version. Let's get this over with :-) Thanks to everyone, especially to Yasumasa's patience with this. ??????? - Ioi > >> Thanks, >> David >> >>> >>> Yasumasa >>> >>> >>>> Thanks, >>>> David >>>> >>>>> >>>>> Yasumasa >>>>> >>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> >>>>>>> Yasumasa >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029578.html >>>>>>> >>>>>>>> Otherwise okay. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> >>>>>>>>> Not? subject for re-review. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Serguei >>>>>>>>> >>>>>>>>> >>>>>>>>> On 10/16/19 16:25, Yasumasa Suenaga wrote: >>>>>>>>>> (Re-send email because I could not send original email to >>>>>>>>>> serviceability-dev and hotspot-compiler-dev) >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> We discussed the fix for JDK-8232084 in [1], and I think we >>>>>>>>>> should fix it with #pragma. >>>>>>>>>> I uploaded new webrev. Could you review it? >>>>>>>>>> >>>>>>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>>>>>>> ? webrev: >>>>>>>>>> http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >>>>>>>>>> >>>>>>>>>> This change has passed the tests on submit repo >>>>>>>>>> (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> Yasumasa >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1] >>>>>>>>>> https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html >>>>>>>>> From tom.rodriguez at oracle.com Thu Oct 17 05:57:09 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Wed, 16 Oct 2019 22:57:09 -0700 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> Message-ID: <9b0b3073-1f97-78c4-5b3c-1dacacb630aa@oracle.com> This looks good to me. tom Igor Veresov wrote on 10/13/19 9:51 AM: > ?Ok, I followed the notation you proposed, here?s the webrev: > http://cr.openjdk.java.net/~iveresov/8227003/webrev.01/ > > > igor > > > >> On Oct 10, 2019, at 3:48 AM, Andrew Dinn > > wrote: >> >> On 10/10/2019 10:39, Claes Redestad wrote: >>> How about: >>> >>> -XX:CompilationMode= >>> >>> enum := default|tiered|quickOnly|highOnly|highOnlyQuickInternal|... >>> >>> quickOnly => "TieredStopAtLevel=1" >>> highOnly => "-TieredCompilation for all" >>> highOnlyQuickInternal => -TieredCompilation with C1 for graal" >>> >>> I think this makes it clearer, and also easier to extend[1]. >> >> Agreed. >> >>> I'm less enthused by the ability to manually pick threshold levels >>> - that we at all expose and thus lock us to what tier levels >>> exists feels like a mistake - and think we should move all such flag to >>> diagnostic, be wary of adding any more and take bigger liberties with >>> changing them as we see fit ergonomically. >> >> Also agreed. >> >>> $.02 >> Krrching! $.04! >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Senior Principal Software Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander > From HORIE at jp.ibm.com Thu Oct 17 07:15:28 2019 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Thu, 17 Oct 2019 16:15:28 +0900 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: , <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> <002c7bcf-97cd-e4ef-400c-b40ef812a99e@oracle.com> Message-ID: Hi Vladimir, Martin, I'm sorry for my late response. > > I agree that GraphKit as a ctor argument looks weird. > > > > What about having a static factory and encapsulate the code there instead? I agree and thank you for showing concrete code, which were helpful to fix the change. > Alternatively, the PhaseGVN could get passed instead of the Compile pointer. (Prototype is already included via node.hpp.) > This is already used by some other nodes like > LoadNode::make(PhaseGVN& gvn, ... > So this seems to be a common pattern. Also agree, I followed LoadNode::make. Thank you. Latest webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.06/ Best regards, Michihiro ----- Original message ----- From: "Doerr, Martin" To: Vladimir Ivanov , Michihiro Horie Cc: hotspot compiler , "ppc-aix-port-dev at openjdk.java.net" Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Date: Mon, Oct 14, 2019 5:27 PM Hi Vladimir, that looks much better. Thank you. Alternatively, the PhaseGVN could get passed instead of the Compile pointer. (Prototype is already included via node.hpp.) This is already used by some other nodes like LoadNode::make(PhaseGVN& gvn, ... So this seems to be a common pattern. Best regards, Martin > -----Original Message----- > From: Vladimir Ivanov > Sent: Samstag, 12. Oktober 2019 03:27 > To: Doerr, Martin ; Michihiro Horie > > Cc: hotspot compiler ; ppc-aix- > port-dev at openjdk.java.net > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > > I agree that GraphKit as a ctor argument looks weird. > > What about having a static factory and encapsulate the code there instead? > > convertnode.hpp: > > RoundDoubleModeNode(Node* in1, ConINode* rmode): Node(0, in1, > rmode) {} > > static RoundDoubleModeNode make(Compile* C, Node* arg, > RoundDoubleModeNode::RoundingMode rmode); > > > convertnode.cpp: > > RoundDoubleModeNode* RoundDoubleModeNode::make(Compile* C, > Node* arg, > RoundDoubleModeNode::RoundingMode rmode) { > ConINode* rm = C->initial_gvn()->intcon(rmode); > return new RoundDoubleModeNode(arg, rm); > } > > > library_call.cpp: > > case vmIntrinsics::_ceil: n = RoundDoubleModeNode::make(C, arg, > RoundDoubleModeNode::rmode_ceil); > > > > > Best regards, > Vladimir Ivanov > > On 09/10/2019 12:29, Doerr, Martin wrote: > > Hi Vladimir and Michihiro, > > > >> ConINode::make() allocates a new node which has to be seen by GVN, so > >> there's a type recorded for it. > > Makes sense. > > > > I'd prefer > > RoundDoubleModeNode(Node *in1, Node *rmode): Node(0, in1, rmode) > {} > > > > and > > case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_floor))); break; > > case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_rint))); break; > > > > That avoids additional includes in convertnode.hpp which can easily lead to > cyclic dependencies for future changes. > > > > Best regards, > > Martin > > > > > >> -----Original Message----- > >> From: Vladimir Ivanov > >> Sent: Dienstag, 8. Oktober 2019 12:31 > >> To: Doerr, Martin ; Michihiro Horie > >> > >> Cc: hotspot compiler ; ppc- > aix- > >> port-dev at openjdk.java.net > >> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on > Power > >> > >> > >> > >> On 08/10/2019 13:14, Doerr, Martin wrote: > >>> Hi Vladimir and Michihiro, > >>> > >>> I like webrev.04 more than webrev.05. > >>> I think it's not good to include graphKit.hpp in convertnode.hpp. This > >> creates a weird dependency. > >>> What was the reason for this change? > >> > >> webrev.04 has a bug. Quote from earlier email: > >> > >> "src/hotspot/share/opto/convertnode.hpp: > >> > >> + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, > >> ConINode::make(rmode)) {} > >> > >> ConINode::make() allocates a new node which has to be seen by GVN, so > >> there's a type recorded for it. That's why I mentioned GraphKit*. But > >> you can use PhaseGVN & intcon as well." > >> > >> Alternatively, Compile* can be used as well. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >>>> -----Original Message----- > >>>> From: Vladimir Ivanov > >>>> Sent: Dienstag, 8. Oktober 2019 11:47 > >>>> To: Michihiro Horie > >>>> Cc: hotspot compiler ; > Doerr, > >>>> Martin ; ppc-aix-port-dev at openjdk.java.net > >>>> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on > >> Power > >>>> > >>>> > >>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.05_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=x9xelSss4243t4zEwkQj1HUEcxpcRs1nPPmkmDJJL3E&s=XcwWs38yeJVjNUXXxTsM50kYcJWH5OvNMgXYHu6LFfU&e= > >>>> > >>>> Looks good. > >>>> > >>>> (Test results are clean.) > >>>> > >>>> Best regards, > >>>> Vladimir Ivanov > >>>> > >>>>> > I think it would be better to use adlc?s include generator instead of > >>>>> > including "opto/convertnode.hpp" explicitly in the ad file. > >>>>> > > >>>>> > src/hotspot/share/adlc/main.cpp > >>>>> > > >>>>> > AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > >>>>> > > >>>>> > + AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > >>>>> > > >>>>> > AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > >>>>> > > >>>>> > @Vladimir: Do you agree? Would you do it this way, too? > >>>>> > >>>>> I prefer current version. > >>>>> > >>>>> When proposing the refactoring I thought about the change in adlc as > >>>>> well, but when I saw the patch I noticed that putting it in AD file > >>>>> stresses it's a platform-specific dependency. > >>>>> > >>>>> I think that's the right way to look at it until we get a way to funnel > >>>>> attributes from ideal nodes to mach nodes and use them during code > >>>>> emission. > >>>>> > >>>>> Best regards, > >>>>> Vladimir Ivanov > >>>>> > >>>>> > *From:*Michihiro Horie > >>>>> > *Sent:* Montag, 7. Oktober 2019 17:54 > >>>>> > *To:* Vladimir Ivanov > >>>>> > *Cc:* hotspot compiler dev at openjdk.java.net>; > >>>> Doerr, > >>>>> > Martin ; ppc-aix-port- > >> dev at openjdk.java.net > >>>>> > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>>>> > rint on Power > >>>>> > > >>>>> > Hi Martin, Vladimir, > >>>>> > Thanks a lot for your further feedback, which makes sense. > >>>>> > > >>>>> > New webrev: > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.04_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=x9xelSss4243t4zEwkQj1HUEcxpcRs1nPPmkmDJJL3E&s=CyjY86GEFhZehxWFJ0K-vtAexnQwP2QlxmClQn4Bc-A&e= > >>>>> > > >>>>> > Best regards, > >>>>> > Michihiro > >>>>> > > >>>>> > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > >>>>> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > >>>>> > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, > >> Michihiro. > >>>>> > > >>>>> > From: Vladimir Ivanov >>>>> > > > >>>>> > To: Michihiro Horie >> >, > >>>>> > "Doerr, Martin" >>>> > > >>>>> > Cc: hotspot compiler >>>>> > >, > >>>>> > "ppc-aix-port-dev at openjdk.java.net > >>>>> > " > >>>>> > >>>>> > > > >>>>> > Date: 2019/10/07 22:51 > >>>>> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, > >>>>> > floor, rint on Power > >>>>> > > >>>>> > ------------------------------------------------------------------------ > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> >> Fixed webrev is as follows. > >>>>> > > >>>>> > Thanks, Michihiro. > >>>>> > > >>>>> >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.03_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=x9xelSss4243t4zEwkQj1HUEcxpcRs1nPPmkmDJJL3E&s=Cfcs5wd6hJk0lIfvI2aHkSi-8DlWMe_hZx4QSUKOdp0&e= > >>>>> > > >>>>> > src/hotspot/share/opto/convertnode.hpp: > >>>>> > > >>>>> > + enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > >>>>> > > >>>>> > Please, explicitly initialize the elements. Numbering is important > since > >>>>> > it is aligned with instruction encoding on x86. > >>>>> > > >>>>> > > >>>>> > src/hotspot/share/opto/library_call.cpp: > >>>>> > > >>>>> > + case vmIntrinsics::_ceil: n = new RoundDoubleModeNode (arg, > >>>>> > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); > >>>> break; > >>>>> > > >>>>> > Please, change RoundDoubleModeNode to accept the enum > instead > >> and > >>>>> > instantiate the ConI node inside it or introduce a static factory > >>>>> > (::make(GraphKit*,RoundingMode)) for that purpose. > >>>>> > > >>>>> > > >>>>> > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > >>>>> > > >>>>> > + void math_round(const FloatRegister t, const FloatRegister b, int > >>>>> rmode); > >>>>> > + void math_round_vec(const VectorSRegister t, const > >> VectorSRegister > >>>> b, > >>>>> > int rmode); > >>>>> > > >>>>> > I suggest to get rid of helpers in MacroAssembler and simply move > >> the > >>>>> > code into corresponding AD instructions. > >>>>> > > >>>>> > Best regards, > >>>>> > Vladimir Ivanov > >>>>> > > >>>>> >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15--- > > I > >>>>> >> suggest to put the enum in RoundDoubleModeNode > >> (convertn"Doerr, > >>>> Martin" > >>>>> >> ---2019/10/07 22:09:15---> I suggest to put the enum in > >>>>> >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction > >>>> selectio > >>>>> >> > >>>>> >> From: "Doerr, Martin" >>>>> > > >>>>> >> To: Vladimir Ivanov >>>>> >, > >>>>> > Michihiro Horie > >>>>> >> > > >>>>> >> Cc: hotspot compiler >>>>> > >, > >>>>> >> "ppc-aix-port-dev at openjdk.java.net > >>>>> > " > >>>>> > >>>>> > > > >>>>> >> Date: 2019/10/07 22:09 > >>>>> >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for > >> Math.ceil, > >>>>> >> floor, rint on Power > >>>>> >> > >>>>> >> ------------------------------------------------------------------------ > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > >>>> (convertnode.hpp) > >>>>> >> > and lift instruction selection logic from > macroAssembler_ppc.cpp > >>>>> into > >>>>> >> ppc.ad. > >>>>> >> That sounds good. > >>>>> >> > >>>>> >> Thanks, > >>>>> >> Martin > >>>>> >> > >>>>> >> > >>>>> >> > -----Original Message----- > >>>>> >> > From: Vladimir Ivanov >>>>> > > >>>>> >> > Sent: Montag, 7. Oktober 2019 12:55 > >>>>> >> > To: Doerr, Martin >>>>> >; Michihiro Horie > >>>>> >> > > > >>>>> >> > Cc: hotspot compiler dev at openjdk.java.net > >>>>> > >; ppc-aix- > >>>>> >> > port-dev at openjdk.java.net >> dev at openjdk.java.net> > >>>>> >> > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>>>> >> rint on Power > >>>>> >> > > >>>>> >> > > I think sharedRuntime is not a good place for the C2 enum. > >>>>> >> > Agree. > >>>>> >> > > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > >>>> (convertnode.hpp) > >>>>> >> > and > >>>>> >> > lift instruction selection logic from macroAssembler_ppc.cpp > into > >>>>> ppc.ad. > >>>>> >> > > >>>>> >> > Best regards, > >>>>> >> > Vladimir Ivanov > >>>>> >> > > >>>>> >> > > > >>>>> >> > > Maybe intrinsicnode.hpp would be a better pace for it. But > >>>>> then, the > >>>>> >> > > code in macroAssembler should be guarded by #ifdef > >> COMPILER2. > >>>>> >> > > > >>>>> >> > > Best regards, > >>>>> >> > > > >>>>> >> > > Martin > >>>>> >> > > > >>>>> >> > > *From:*Michihiro Horie >>>> > > >>>>> >> > > *Sent:* Montag, 7. Oktober 2019 09:14 > >>>>> >> > > *To:* Vladimir Ivanov >>>>> > > >>>>> >> > > *Cc:* hotspot compiler >> dev at openjdk.java.net > >>>>> > >; > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > >>>>> > ; Doerr, Martin > >>>>> >> > > > >>>>> >> > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > >>>>> floor, > >>>>> >> > > rint on Power > >>>>> >> > > > >>>>> >> > > Hi Vladimir, > >>>>> >> > > > >>>>> >> > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > >>>>> >> > > I'm wondering if the enum constants can be declared in > >>>>> >> > sharedRuntime.hpp. > >>>>> >> > > Webrev: > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.02_&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=x9xelSss4243t4zEwkQj1HUEcxpcRs1nPPmkmDJJL3E&s=m8iwK29pZKGlHSODOuvjkM-B_A4fzRz_xELX_ImjE48&e= > >>>>> >> > > > >>>>> >> > > Best regards, > >>>>> >> > > Michihiro > >>>>> >> > > > >>>>> >> > > Inactive hide details for Vladimir Ivanov ---2019/10/04 > >>>>> 23:05:48---Hi > >>>>> >> > > Michihiro, > >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > >>>>> Ivanov > >>>>> >> > > ---2019/10/04 23:05:48---Hi Michihiro, > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>>>> >> > > > >>>>> >> > > From: Vladimir Ivanov >>>>> > > > > > >>>>> > > > >>>>> >> > > To: Michihiro Horie >>>> >, > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > >>>>> > >>>>> >> > > , hotspot > compiler > >>>>> >> > > >>>>> > > > > > >>>>> > > > >>>>> >> > > Date: 2019/10/04 23:05 > >>>>> >> > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > >>>>> Math.ceil, > >>>>> >> > > floor, rint on Power > >>>>> >> > > > >>>>> >> > > > >>>>> >> ------------------------------------------------------------------------ > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > Hi Michihiro, > >>>>> >> > > > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>>>> >> > > + switch (rmode) { > >>>>> >> > > + case 0: // rint > >>>>> >> > > + frin(t, b); > >>>>> >> > > + break; > >>>>> >> > > + case 1: // floor > >>>>> >> > > + frim(t, b); > >>>>> >> > > + break; > >>>>> >> > > + case 2: // ceil > >>>>> >> > > + frip(t, b); > >>>>> >> > > + break; > >>>>> >> > > + default: > >>>>> >> > > + ShouldNotReachHere(); > >>>>> >> > > + } > >>>>> >> > > > >>>>> >> > > What do you think about introducing enum constants instead > of > >>>> using > >>>>> >> > > hard-coded 0/1/2? > >>>>> >> > > > >>>>> >> > > src/hotspot/share/opto/library_call.cpp: > >>>>> >> > > > >>>>> >> > > case vmIntrinsics::_ceil: n = new > >> RoundDoubleModeNode(arg, > >>>>> >> > > makecon(TypeInt::make(2))); break; > >>>>> >> > > case vmIntrinsics::_floor: n = new > >> RoundDoubleModeNode(arg, > >>>>> >> > > makecon(TypeInt::make(1))); break; > >>>>> >> > > case vmIntrinsics::_rint: n = new > >> RoundDoubleModeNode(arg, > >>>>> >> > > makecon(TypeInt::make(0))); break; > >>>>> >> > > > >>>>> >> > > The downside is you have to move the switch from > >>>> macroAssembler > >>>>> >> > because > >>>>> >> > > enum should be visible from both places. (Is there a better > >>>>> place for > >>>>> >> > > that than roundD_regNode::emit() in AD file?) > >>>>> >> > > > >>>>> >> > > Best regards, > >>>>> >> > > Vladimir Ivanov > >>>>> >> > > > >>>>> >> > > On 02/10/2019 07:27, Michihiro Horie wrote: > >>>>> >> > >> > >>>>> >> > >> Dear all, > >>>>> >> > >> > >>>>> >> > >> Would you please review the following change? > >>>>> >> > >> Bug: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8231649&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=x9xelSss4243t4zEwkQj1HUEcxpcRs1nPPmkmDJJL3E&s=CKTTBG0o-xxSEq3-DB0vC6rAr7uNHeJ8lEe985fsv4o&e= > >>>>> >> > >> Webrev: > >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.00&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=x9xelSss4243t4zEwkQj1HUEcxpcRs1nPPmkmDJJL3E&s=pKDvzoP0Swa1t5oRYjEouUDcN_rZCNTufCzBivcGy9E&e= > >>>>> >> > >> > >>>>> >> > >> This change adds intrinsics for Math's ceil, floor, and rint for > >>>>> >> PPC64, on > >>>>> >> > >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > >>>>> >> > >> > >>>>> >> > >> Best regards, > >>>>> >> > >> Michihiro > >>>>> >> > >> > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> From lutz.schmidt at sap.com Thu Oct 17 07:28:17 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 17 Oct 2019 07:28:17 +0000 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks Message-ID: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> Dear all, may I please request reviews for this fix, addressing actually two current performance issues in CodeHeap management. One issue (the stupid one) could be eliminated completely. The other one, in the context of maintaining the code heap segment map, was tamed considerably. From old to new, the following absolute times and speedup factors were observed: speedup absolute time [Milliseconds] old version new version ppc fastdebug 4,700 69,593.484 14.833 (30,000 calls) ppc release 4,600 70,069.517 15.215 (30,000 calls) s390 fastdebug 3,500 7,778.500 2.220 (40,000 calls) s390 release 6,700 6,935.371 1.026 (40,000 calls) These results are far from clean room measurements. On the other hand, the improvements are so extreme that it can't be just measurement errors. And is it important if the factor is 4k or 3k? The performance gain is achieved by taking advantage of properties of the CodeHeap segment map, not by improved coding techniques. You can find more detail in the bug description and as inline documentation in the source code. Bug: https://bugs.openjdk.java.net/browse/JDK-8231460 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8231460.00/ Please have a look. Thank you, Lutz From goetz.lindenmaier at sap.com Thu Oct 17 10:55:19 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 17 Oct 2019 10:55:19 +0000 Subject: 8231757: [ppc] Fix VerifyOops. Errors show since 8231058. Message-ID: Hi, 8231058 introduced a test that enables +VerifyOops. This fails on ppc, because this was not used in a very long time. The crash is caused by passing compressed oops from LIR_Assembler::store() to the checker routine. I fix this by implementing a checker routine verify_coop that first decompresses the coop. This makes the new test pass. Further testing showed that the additional checker coding makes Patching Stubs overflow. These can not be increased in size to fit the code. I disable generating verify_oop code in LIRAssembler::load() which fixes the issue. Further I extended the message printed when verification of an oop failed. First, I print the location in the source code where the checker code was generated. Second, I print the faulty oop. I also improved the message printed when PatchingStubs overflow. Finally, I improve the test to run with and without compressed Oops. Please review: http://cr.openjdk.java.net/~goetz/wr19/8231757-fix_VerifyOops/01/ @runtime as I modify the test introduced there @compiler as the error is in C1. Best regards, Goetz. From david.holmes at oracle.com Thu Oct 17 11:17:55 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 17 Oct 2019 21:17:55 +1000 Subject: 8231757: [ppc] Fix VerifyOops. Errors show since 8231058. In-Reply-To: References: Message-ID: <3f1be78d-b5e3-192b-d05f-e81ed520d65a@oracle.com> Hi Goetz, UseCompressedOops is a 64-bit flag only so your change will break the test on 32-bit systems. David On 17/10/2019 8:55 pm, Lindenmaier, Goetz wrote: > Hi, > > 8231058 introduced a test that enables +VerifyOops. > This fails on ppc, because this was not used in a very > long time. > > The crash is caused by passing compressed oops from > LIR_Assembler::store() to the checker routine. > I fix this by implementing a checker routine verify_coop > that first decompresses the coop. This makes the new > test pass. > > Further testing showed that the additional checker > coding makes Patching Stubs overflow. These > can not be increased in size to fit the code. I > disable generating verify_oop code in LIRAssembler::load() > which fixes the issue. > > Further I extended the message printed when verification > of an oop failed. First, I print the location in the source > code where the checker code was generated. Second, > I print the faulty oop. > > I also improved the message printed when PatchingStubs > overflow. > > Finally, I improve the test to run with and without compressed > Oops. > > Please review: > http://cr.openjdk.java.net/~goetz/wr19/8231757-fix_VerifyOops/01/ > > @runtime as I modify the test introduced there > @compiler as the error is in C1. > > Best regards, > Goetz. > From adinn at redhat.com Thu Oct 17 11:19:14 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 17 Oct 2019 12:19:14 +0100 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> Message-ID: <37969751-34df-da93-90cc-5746ca4b5a4d@redhat.com> Hi Lutz, On 17/10/2019 08:28, Schmidt, Lutz wrote: > may I please request reviews for this fix, addressing actually two > current performance issues in CodeHeap management. One issue (the stupid > one) could be eliminated completely. The other one, in the context of > maintaining the code heap segment map, was tamed considerably. > > From old to new, the following absolute times and speedup factors > were observed: > > speedup absolute time [Milliseconds] > old version new version > ppc fastdebug 4,700 69,593.484 14.833 (30,000 calls) > ppc release 4,600 70,069.517 15.215 (30,000 calls) > s390 fastdebug 3,500 7,778.500 2.220 (40,000 calls) > s390 release 6,700 6,935.371 1.026 (40,000 calls) > > > These results are far from clean room measurements. On the other > hand, the improvements are so extreme that it can't be just measurement > errors. And is it important if the factor is 4k or 3k? > > The performance gain is achieved by taking advantage of properties > of the CodeHeap segment map, not by improved coding techniques. You can > find more detail in the bug description and as inline documentation in > the source code. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231460 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8231460.00/ > > Please have a look. This is an interesting optimization and I think it may well be worth having. The test results are very impressive looking. However, I don't suppose the test bears a strong relation to what actually happens at runtime. I think it would be useful to create a test that exercises the code cache with one (or several?) more realistic profiles for addition and deletion of blocks. You could synthesize something that generates a variety of different size methods and also does periodic fees of some subset of the live methods. Alternatively, you could maybe modify the JVM to produce some traces which can be used guide such a test. The one concern I have about the optimization is that over time splitting and fusing of blocks is going to lead to fragmentation in the segment maps. Am I correct to assume that given enough split and fuse operations (for a varying ranges of block sizes) that eventually all the live entries in segment maps will converge to 1? (i.e. the hop count will tend towards the maximum possible). If that is so then this will add a gradually increasing penalty to traversals from a code address to the code header block. Better testing might help to quantify how 'gradual' this is and also how much of a penalty the extra traversal cost is in real deployments. If either/both of those raises concerns then is there some way you could track and, where appropriate, reverse this fragmentation by fully reinitialising a merged map to remove an excess of embedded hops? I have only one code comment (the rest is admirably clear): heap.cpp:383 - 419 I think the extra detail in this comment is worth having. However, the comment could benefit from a few edits: @403-404: * - The contents of the segment map elements has to be interpreted * as unsigned integer." hmm? * - elements of the segment map (byte) array are interpreted * as unsigned integers" @ 405-407: * - Each segment map element contain the distance (in segment size units) * of the related segment to the start of the block. * be subtracted from the current index to get closer to the start. I assume that last line got pasted in from below by mistake. I'd reword the preceding two lines as follows: * - Element values normally identify an offset backwards (in segment * size units) from the associated segment towards the start of * the block. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From goetz.lindenmaier at sap.com Thu Oct 17 14:10:21 2019 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 17 Oct 2019 14:10:21 +0000 Subject: 8231757: [ppc] Fix VerifyOops. Errors show since 8231058. In-Reply-To: <3f1be78d-b5e3-192b-d05f-e81ed520d65a@oracle.com> References: <3f1be78d-b5e3-192b-d05f-e81ed520d65a@oracle.com> Message-ID: Hi David, you are right, thanks for pointing me to that! Doing one test for vm.bits=64 and one for 32 should fix it: http://cr.openjdk.java.net/~goetz/wr19/8231757-fix_VerifyOops/01/ Best regards, Goetz. > -----Original Message----- > From: David Holmes > Sent: Donnerstag, 17. Oktober 2019 13:18 > To: Lindenmaier, Goetz ; hotspot-runtime- > dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' compiler-dev at openjdk.java.net> > Subject: Re: 8231757: [ppc] Fix VerifyOops. Errors show since 8231058. > > Hi Goetz, > > UseCompressedOops is a 64-bit flag only so your change will break the > test on 32-bit systems. > > David > > On 17/10/2019 8:55 pm, Lindenmaier, Goetz wrote: > > Hi, > > > > 8231058 introduced a test that enables +VerifyOops. > > This fails on ppc, because this was not used in a very > > long time. > > > > The crash is caused by passing compressed oops from > > LIR_Assembler::store() to the checker routine. > > I fix this by implementing a checker routine verify_coop > > that first decompresses the coop. This makes the new > > test pass. > > > > Further testing showed that the additional checker > > coding makes Patching Stubs overflow. These > > can not be increased in size to fit the code. I > > disable generating verify_oop code in LIRAssembler::load() > > which fixes the issue. > > > > Further I extended the message printed when verification > > of an oop failed. First, I print the location in the source > > code where the checker code was generated. Second, > > I print the faulty oop. > > > > I also improved the message printed when PatchingStubs > > overflow. > > > > Finally, I improve the test to run with and without compressed > > Oops. > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr19/8231757-fix_VerifyOops/01/ > > > > @runtime as I modify the test introduced there > > @compiler as the error is in C1. > > > > Best regards, > > Goetz. > > From lutz.schmidt at sap.com Thu Oct 17 15:36:40 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 17 Oct 2019 15:36:40 +0000 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: <37969751-34df-da93-90cc-5746ca4b5a4d@redhat.com> References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> <37969751-34df-da93-90cc-5746ca4b5a4d@redhat.com> Message-ID: Hi Andrew, Thank you for looking at the change and, of course, for your thoughts and comments. Let me cover the easy part (heap.cpp:383 - 419) first: ====================================================== I fully agree to your suggestions. Your wording is much clearer and easier to understand. Your suggestions will be contained in the next webrev iteration. I will not create a separate webrev just for that. About the particular test: ========================== Yes, the test is completely synthetic in freeing thousands of CodeHeap blocks in a row. Such a situation will most likely never occur in a real-world workload. I was digging into this only because the test timed out on some of our machines. I'm not sure if we need another synthetic test to model the real world. It would be possible as well to add the timing to some real-world test(s) and analyze what's happening there. Would JBB2005 or JBB2013 be close enough to the real world? About the risk of segment map fragmentation: ============================================ Yes, there will be some fragmentation. I never observed fragmentation to become excessive, however. And there is reason for that: each time a HeapBlock allocation is satisfied out of the FreeBlock list, that segment map interval is re-initialized. Simply put: block allocation inherently provides self-healing for segment map fragmentation due to block deallocation. Knowing that, your "horror scenario" (all segment map entries converging to one) is not a factor. If concerns remain, defragmenting the segment table is of course possible. I expect it to be not extremely expensive. The expensive part would be fragmentation tracking and deciding when to defragment. I do have an idea for that. Let me try it out... Thanks, Lutz ?On 17.10.19, 13:19, "Andrew Dinn" wrote: Hi Lutz, On 17/10/2019 08:28, Schmidt, Lutz wrote: > may I please request reviews for this fix, addressing actually two > current performance issues in CodeHeap management. One issue (the stupid > one) could be eliminated completely. The other one, in the context of > maintaining the code heap segment map, was tamed considerably. > > From old to new, the following absolute times and speedup factors > were observed: > > speedup absolute time [Milliseconds] > old version new version > ppc fastdebug 4,700 69,593.484 14.833 (30,000 calls) > ppc release 4,600 70,069.517 15.215 (30,000 calls) > s390 fastdebug 3,500 7,778.500 2.220 (40,000 calls) > s390 release 6,700 6,935.371 1.026 (40,000 calls) > > > These results are far from clean room measurements. On the other > hand, the improvements are so extreme that it can't be just measurement > errors. And is it important if the factor is 4k or 3k? > > The performance gain is achieved by taking advantage of properties > of the CodeHeap segment map, not by improved coding techniques. You can > find more detail in the bug description and as inline documentation in > the source code. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231460 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8231460.00/ > > Please have a look. This is an interesting optimization and I think it may well be worth having. The test results are very impressive looking. However, I don't suppose the test bears a strong relation to what actually happens at runtime. I think it would be useful to create a test that exercises the code cache with one (or several?) more realistic profiles for addition and deletion of blocks. You could synthesize something that generates a variety of different size methods and also does periodic fees of some subset of the live methods. Alternatively, you could maybe modify the JVM to produce some traces which can be used guide such a test. The one concern I have about the optimization is that over time splitting and fusing of blocks is going to lead to fragmentation in the segment maps. Am I correct to assume that given enough split and fuse operations (for a varying ranges of block sizes) that eventually all the live entries in segment maps will converge to 1? (i.e. the hop count will tend towards the maximum possible). If that is so then this will add a gradually increasing penalty to traversals from a code address to the code header block. Better testing might help to quantify how 'gradual' this is and also how much of a penalty the extra traversal cost is in real deployments. If either/both of those raises concerns then is there some way you could track and, where appropriate, reverse this fragmentation by fully reinitialising a merged map to remove an excess of embedded hops? I have only one code comment (the rest is admirably clear): heap.cpp:383 - 419 I think the extra detail in this comment is worth having. However, the comment could benefit from a few edits: @403-404: * - The contents of the segment map elements has to be interpreted * as unsigned integer." hmm? * - elements of the segment map (byte) array are interpreted * as unsigned integers" @ 405-407: * - Each segment map element contain the distance (in segment size units) * of the related segment to the start of the block. * be subtracted from the current index to get closer to the start. I assume that last line got pasted in from below by mistake. I'd reword the preceding two lines as follows: * - Element values normally identify an offset backwards (in segment * size units) from the associated segment towards the start of * the block. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From igor.veresov at oracle.com Thu Oct 17 15:42:17 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 17 Oct 2019 08:42:17 -0700 Subject: RFR(M) 8227003: [Graal] java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java time out In-Reply-To: <9b0b3073-1f97-78c4-5b3c-1dacacb630aa@oracle.com> References: <225F3498-145A-46B2-AE9D-9DAC5BBBBE36@oracle.com> <79df09e3-42ff-d047-8d51-a1afdfc846c5@oracle.com> <2A6EFB3B-247E-4DBD-B652-D9B567268898@oracle.com> <150c60a8-e160-2ff6-1f58-15913ee057e1@oracle.com> <73310BDF-B9AA-4C8C-8587-D6ED6E5BCBFF@oracle.com> <9b0b3073-1f97-78c4-5b3c-1dacacb630aa@oracle.com> Message-ID: <370817EE-7334-4DB0-8AFF-13B6FF156C5B@oracle.com> Thanks, Tom! igor > On Oct 16, 2019, at 10:57 PM, Tom Rodriguez wrote: > > This looks good to me. > > tom > > Igor Veresov wrote on 10/13/19 9:51 AM: >> Ok, I followed the notation you proposed, here?s the webrev: http://cr.openjdk.java.net/~iveresov/8227003/webrev.01/ >> igor >>> On Oct 10, 2019, at 3:48 AM, Andrew Dinn > wrote: >>> >>> On 10/10/2019 10:39, Claes Redestad wrote: >>>> How about: >>>> >>>> -XX:CompilationMode= >>>> >>>> enum := default|tiered|quickOnly|highOnly|highOnlyQuickInternal|... >>>> >>>> quickOnly => "TieredStopAtLevel=1" >>>> highOnly => "-TieredCompilation for all" >>>> highOnlyQuickInternal => -TieredCompilation with C1 for graal" >>>> >>>> I think this makes it clearer, and also easier to extend[1]. >>> >>> Agreed. >>> >>>> I'm less enthused by the ability to manually pick threshold levels >>>> - that we at all expose and thus lock us to what tier levels >>>> exists feels like a mistake - and think we should move all such flag to >>>> diagnostic, be wary of adding any more and take bigger liberties with >>>> changing them as we see fit ergonomically. >>> >>> Also agreed. >>> >>>> $.02 >>> Krrching! $.04! >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Senior Principal Software Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From vitalyd at gmail.com Thu Oct 17 15:53:16 2019 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 17 Oct 2019 11:53:16 -0400 Subject: SIGSEGV in C2 Node::unique_ctrl_out on 11.0.4 In-Reply-To: References: <1aec071e0d514377b623ce0d25946063@EXMBNJE5.ad.twosigma.com> <87muf0iurm.fsf@redhat.com> <87k1a4ijar.fsf@redhat.com> Message-ID: Hi Roland, On Fri, Sep 20, 2019 at 9:17 AM Vitaly Davidovich wrote: > > > On Thu, Sep 19, 2019 at 8:04 AM Roland Westrelin > wrote: > >> >> > So assuming I have one, how would I go about using it? Try running the >> > program and specify the replay file to be used to replay compilations? I >> > know you guys introduced this thing a while back, but I?ve never >> actually >> > used it :). >> >> Replay compilation only replays the compilation and is run with: >> >> java -cp .... -XX:+ReplayCompiles >> -XX:ReplayDataFile=replay_pidxxx.log -XX:+ReplayIgnoreInitErrors >> >> Assuming the classpath is set correctly and there's no generated methods >> that c2 can't find in the classpath (from lambdas for instance), the >> crash should reproduce. >> >> Roland. > > Thanks Roland! I?ll see if I can make some progress on this. > So I believe I have a minimal replay that crashes in fastdebug for the same reason as product build. There's a tarball at https://www.astron.com/pri/jvm_sigsegv-20191017.tar.gz, which contains a "replayer.sh" and a few scala jars (the crashes we're seeing are when compiling scala generated bytecodes, as mentioned before. The bash script is pointing at a fastdebug jdk I had locally, but you can of course point it to your own (I took Aleksey's fastdebug builds off his site). Hopefully it repros on your end, but if not, perhaps we can iterate a bit more on this. Thanks! > > I briefly examined the disassembly and register info from the coredump and > am reasonably certain it?s the `this` ptr that?s null (ie we?re calling > unique_ctrl_out on a NULL Node). That?s not super useful to figure out the > root issue, of course. > > It also looks like it?s compiling some Scala generated bytecode (ie scalac > output). Perhaps it?s producing something peculiar, not seen with Java > compilers. > >> >> -- > Sent from my phone > From adinn at redhat.com Thu Oct 17 16:35:57 2019 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 17 Oct 2019 17:35:57 +0100 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> <37969751-34df-da93-90cc-5746ca4b5a4d@redhat.com> Message-ID: <6a9e3306-ff2b-1ded-c0fc-22af5831e776@redhat.com> Hi Lutz, On 17/10/2019 16:36, Schmidt, Lutz wrote: > Thank you for looking at the change and, of course, for your thoughts > and comments. > > Let me cover the easy part (heap.cpp:383 - 419) first: > ====================================================== > I fully agree to your suggestions. Your wording is much clearer and > easier to understand. Your suggestions will be contained in the next > webrev iteration. I will not create a separate webrev just for that. Sure, no need to see another webrev on that account. > About the particular test: > ========================== > Yes, the test is completely synthetic in freeing thousands of > CodeHeap blocks in a row. Such a situation will most likely never > occur in a real-world workload. I was digging into this only because > the test timed out on some of our machines. > > I'm not sure if we need another synthetic test to model the real > world. It would be possible as well to add the timing to some > real-world test(s) and analyze what's happening there. Would JBB2005 > or JBB2013 be close enough to the real world? A real test is probably a good place to start. My thought re a synthetic test was that if the cache management time is only a small percentage of the total runtime then that may make it hard to accurately measure the benefit of the patch. Why not start by seeing if a real-world test provides a clear measurable difference? If that fails it might then be worth resorting to running a synthetic test that only exercises the cache management code. It would be good to have evidence that this is actually going to improve performance. > About the risk of segment map fragmentation: > > ============================================ > > Yes, there will be some fragmentation. I never observed fragmentation > to become excessive, however. And there is reason for that: each time > a HeapBlock allocation is satisfied out of the FreeBlock list, that > segment map interval is re-initialized. ... Ah yes, (doh!). I guess you would need a truly pathological pattern of allocs and merges for that to fail to defrag the map. regards, Andrew Dinn ----------- From rwestrel at redhat.com Thu Oct 17 17:03:42 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 17 Oct 2019 19:03:42 +0200 Subject: SIGSEGV in C2 Node::unique_ctrl_out on 11.0.4 In-Reply-To: References: <1aec071e0d514377b623ce0d25946063@EXMBNJE5.ad.twosigma.com> <87muf0iurm.fsf@redhat.com> <87k1a4ijar.fsf@redhat.com> Message-ID: <87sgnr2tjl.fsf@redhat.com> Hi Vitaly, > So I believe I have a minimal replay that crashes in fastdebug for the > same reason as product build. There's a tarball at > https://www.astron.com/pri/jvm_sigsegv-20191017.tar.gz, which contains a > "replayer.sh" and a few scala jars (the crashes we're seeing are when > compiling scala generated bytecodes, as mentioned before. The bash script > is pointing at a fastdebug jdk I had locally, but you can of course point > it to your own (I took Aleksey's fastdebug builds off his site). Thanks for taking the time to put a reproducer together. I get: # assert((Opcode() != Op_If && Opcode() != Op_RangeCheck) || outcnt() == 2) failed: bad if #1 I filed https://bugs.openjdk.java.net/browse/JDK-8232539 Roland. From vitalyd at gmail.com Thu Oct 17 17:08:40 2019 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Thu, 17 Oct 2019 13:08:40 -0400 Subject: SIGSEGV in C2 Node::unique_ctrl_out on 11.0.4 In-Reply-To: <87sgnr2tjl.fsf@redhat.com> References: <1aec071e0d514377b623ce0d25946063@EXMBNJE5.ad.twosigma.com> <87muf0iurm.fsf@redhat.com> <87k1a4ijar.fsf@redhat.com> <87sgnr2tjl.fsf@redhat.com> Message-ID: Hey Roland, On Thu, Oct 17, 2019 at 1:03 PM Roland Westrelin wrote: > > Hi Vitaly, > > > So I believe I have a minimal replay that crashes in fastdebug for the > > same reason as product build. There's a tarball at > > https://www.astron.com/pri/jvm_sigsegv-20191017.tar.gz, which contains a > > "replayer.sh" and a few scala jars (the crashes we're seeing are when > > compiling scala generated bytecodes, as mentioned before. The bash > script > > is pointing at a fastdebug jdk I had locally, but you can of course point > > it to your own (I took Aleksey's fastdebug builds off his site). > > Thanks for taking the time to put a reproducer together. I get: > > # assert((Opcode() != Op_If && Opcode() != Op_RangeCheck) || outcnt() == > 2) failed: bad if #1 > Yup, that's what I see locally as well! Glad nothing got lost "in transit" :). > > I filed https://bugs.openjdk.java.net/browse/JDK-8232539 Thank you! > > > Roland. > From vivek.r.deshpande at intel.com Thu Oct 17 18:45:02 2019 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 17 Oct 2019 18:45:02 +0000 Subject: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to over loop unrolling In-Reply-To: References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB726AFB@fmsmsx121.amr.corp.intel.com> <1fa86506-797b-6f18-bcc3-1d7f8d2a32ca@loongson.cn> <53E8E64DB2403849AFD89B7D4DAC8B2AAB72806A@fmsmsx121.amr.corp.intel.com> <3724faa6-c57c-744a-d7e8-22daa4231078@loongson.cn> <93e239f5-a718-0d24-a799-9a4e586761c8@loongson.cn> <53E8E64DB2403849AFD89B7D4DAC8B2AAB73051E@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7366EF@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7BD33A@fmsmsx121.amr.corp.intel.com> <4e62f5e8-9c14-20e0-3d13-680c527f9d68@loongson.cn> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C1E35@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C552E@fmsmsx121.amr.corp.intel.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7DF517@fmsmsx121.amr.corp.intel.com> Hi Jie I experimented with your patch and observed that the performance is lower for smaller sizes arrays such as NUM=4, 8 , 16, 32 for byte and long arrays with same test. There is a function policy_unroll(PhaseIdealLoop *phase) in loopTransform.cpp, which avoids over unrolling of the loop. Is there any way you can use or modify that to have the same effect you are intended with this patch? Regards, Vivek -----Original Message----- From: Jie Fu [mailto:fujie at loongson.cn] Sent: Thursday, September 26, 2019 6:07 PM To: Deshpande, Vivek R ; Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net; Viswanathan, Sandhya Subject: Re: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to over loop unrolling Thanks Vivek for? your help. On 2019/9/27 ??7:16, Deshpande, Vivek R wrote: > Hi Jie > > I tried the patch from webrev.04 with NUM=4096 and looks like the instructions with AVX512 are getting generated. > I will do some more perf runs and let you know. > > Regards, > Vivek > > -----Original Message----- > From: Jie Fu [mailto:fujie at loongson.cn] > Sent: Wednesday, September 25, 2019 8:51 AM > To: Deshpande, Vivek R ; Vladimir Kozlov > ; hotspot-compiler-dev at openjdk.java.net; > Viswanathan, Sandhya > Subject: Re: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to > over loop unrolling > > Hi Vivek, > > Thanks for your review and help. Please see responses below. > > 1. According to my observation, compiling with full vector length may not always be the smartest choice, especially for small loops. > ?? For example, if running your test case with NUM = 256 and 128 on > my > avx-256 machine, the performance can be improved by 28% and 36% respectively if using 16-byte vectors, instead of full available vector width (32-byte vectors). > > 2. My fix [1] aims at improving performance with small loops, while keeping the same performance for large loops compared with the original implementation. > ?? The patch adds a heuristic to protect against over-unrolling with SuperWordLoopUnrollAnalysis. > ?? For a more detailed quantitative analysis, please refer to [2]. > > 3. I don't quite understand why your test case has to be compiled with 512-bit vector. Could you please explain why? > ?? For your test case, vector-256 is used in my patch to protect against over-unrolling. > ?? If I recall correctly, there is no performance difference between 512-bit and 256-bit vectors on your machine. > ?? However, it doesn't mean vector-512 won't be generated. > ?? If you try to increase the NUM in your program (e.g., NUM=4096), you will find vector-512 will be generated on your machine. > ?? I can't see the benefit of using 512-bit vector. That's why I'm asking this question all the time. > ?? I'd be really appreciated if you would like to answer it. > > To validate the effectiveness of the patch, you can test the performance for NUM = 256 and 128 on your avx-512 machine. > > Looking forward to your reply. > > Thanks a lot. > Best regards, > Jie > > [1] http://cr.openjdk.java.net/~jiefu/8227505/webrev.04/ > [2] > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-Augu > st/034783.html > > > On 2019/9/25 ??1:20, Deshpande, Vivek R wrote: >> Hi Jie >> >> May be you missed my earlier reply, I had tried your patch from webrev.04. >> It does not use full 512 bits of the vector and generates 256 bit vector instructions. >> The log is similar to earlier patch from webrev.03. >> May be if you tweak this condition it would work. >> if (future_unroll_factor > cur_trip_cnt) break; >> >> Regards, >> Vivek >> >> >> -----Original Message----- >> From: Jie Fu [mailto:fujie at loongson.cn] >> Sent: Tuesday, September 24, 2019 7:59 AM >> To: Deshpande, Vivek R ; Vladimir Kozlov >> ; hotspot-compiler-dev at openjdk.java.net; >> Viswanathan, Sandhya >> Subject: Re: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to >> over loop unrolling >> >> Hi Vivek, >> >> May I get to know whether the not-unroll-after-vectorization problem was fixed by webrev.04 on your avx-512 machine? >> If not, could you please share me the compile log? >> >> Thanks a lot. >> Best regards, >> Jie >> >> [1] >> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-Aug >> ust/034817.html >> >> On 2019/9/18 ??9:46, Jie Fu wrote: >>> Hi Vivek, >>> >>> Thank you for your help. >>> >>> Does webrev.04 fix the the not-unroll-after-vectorization problem >>> you mentioned in [1] on your avx-512 machine? >>> >>> The patch just adds a heuristic [2] to protect against >>> over-unrolling with SuperWordLoopUnrollAnalysis. >>> In order to use the full available vector width, >>> SuperWordLoopUnrollAnalysis performs loop unrolling much more >>> aggressively, which may hurt the performance for some cases. >>> One of the important reasons for the performance degradation of >>> SuperWordLoopUnrollAnalysis is that it doesn't consider the negative >>> impact of pre/post-loop at all. >>> The current SuperWordLoopUnrollAnalysis focuses on reducing the >>> iterations of the main-loop, but ignores the increment of iterations >>> in pre/post-loop. >>> For a more detailed quantitative analysis of that case, please refer >>> to [2]. >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-Au >>> gu >>> st/034817.html >>> [2] >>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-Au >>> gu >>> st/034783.html >>> >>> On 2019/9/17 ??10:55, Deshpande, Vivek R wrote: >>>> Hi Jie >>>> >>>> I tried your patch from webrev.04. I still see the similar behavior >>>> as earlier patch. So I am trying to understand what your new patch >>>> is doing and how we can fix it. >>>> >>>> Regards, >>>> Vivek >>>> >>>> -----Original Message----- >>>> From: Jie Fu [mailto:fujie at loongson.cn] >>>> Sent: Tuesday, September 10, 2019 8:42 PM >>>> To: Deshpande, Vivek R ; Vladimir >>>> Kozlov ; >>>> hotspot-compiler-dev at openjdk.java.net; >>>> Viswanathan, Sandhya >>>> Subject: Re: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to >>>> over loop unrolling >>>> >>>> Hi Vivek, >>>> >>>> Updated: http://cr.openjdk.java.net/~jiefu/8227505/webrev.04/ >>>> >>>> With the help of your compile logs, I successfully reproduced the >>>> not-unroll-after-vectorization problem you mentioned in [1]. >>>> It had been fixed on my avx-256 machine with this version. >>>> The patch just adds a heuristic [2] to protect against >>>> over-unrolling with SuperWordLoopUnrollAnalysis. >>>> Please review it and give me some advice. >>>> >>>> Again, if you have any questions on your avx-512 machine, could you >>>> please share me the compile logs, especially for NUM = 256, 2048 >>>> and 4096? >>>> Please see comments inline. >>>> >>>> Thanks a lot. >>>> Best regards, >>>> Jie >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-A >>>> ug >>>> ust/034817.html >>>> >>>> [2] >>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-A >>>> ug >>>> ust/034783.html >>>> >>>> >>>> On 2019/9/7 ??7:35, Deshpande, Vivek R wrote: >>>>> Hi Jie >>>>> >>>>> I experimented with both the sizes 1024 and 2048 bytes and looks >>>>> like the 2nd compilation generates the suboptimal code with >>>>> shorter vector width. >>>> I still don't think it's a problem since there is no performance >>>> gain with full available vector width according to your performance analysis. >>>> >>>> >>>>> Please find it attached. >>>>> IMO, the fix you have should be able to unroll enough to use the >>>>> full available vector width. >>>> Why? >>>> Unfortunately, compiling with full available vector width can be >>>> harmful to performance. >>>> I experimented your test case with NUM = 256 and 128 on my avx-256 >>>> machine, finding that the performance was frustrated with full >>>> available vector width (32-byte vectors). >>>> After the patch, the performance (16-byte vectors) for NUM = 256 >>>> and >>>> 128 had been improved by 28% and 36% respectively. >>>> >>>> So I wonder about the performance before and after the patch for >>>> NUM = >>>> 256 and 128 on your avx-512 machine. >>>> Could you please also share us? >>>> >>>> Thanks. >>>> >>>> >>>>> Regards, >>>>> Vivek From vladimir.kozlov at oracle.com Thu Oct 17 18:48:41 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Oct 2019 11:48:41 -0700 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> Message-ID: Hi Lutz It should be RFC - change seems experimental since it uses #if 0 and UseNewCode2. Nice improvement. Thanks, Vladimir On 10/17/19 12:28 AM, Schmidt, Lutz wrote: > Dear all, > > may I please request reviews for this fix, addressing actually two current performance issues in CodeHeap management. One issue (the stupid one) could be eliminated completely. The other one, in the context of maintaining the code heap segment map, was tamed considerably. > > From old to new, the following absolute times and speedup factors were observed: > > speedup absolute time [Milliseconds] > old version new version > ppc fastdebug 4,700 69,593.484 14.833 (30,000 calls) > ppc release 4,600 70,069.517 15.215 (30,000 calls) > s390 fastdebug 3,500 7,778.500 2.220 (40,000 calls) > s390 release 6,700 6,935.371 1.026 (40,000 calls) > > > These results are far from clean room measurements. On the other hand, the improvements are so extreme that it can't be just measurement errors. And is it important if the factor is 4k or 3k? > > The performance gain is achieved by taking advantage of properties of the CodeHeap segment map, not by improved coding techniques. You can find more detail in the bug description and as inline documentation in the source code. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231460 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8231460.00/ > > Please have a look. > Thank you, > Lutz > From lutz.schmidt at sap.com Thu Oct 17 19:32:16 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 17 Oct 2019 19:32:16 +0000 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> Message-ID: Hi Vladimir, thanks for looking at the change. You should have seen "if (!UseNewCode)". The intention was to leave in the "old" code that I tested against. The "old" code already has improvements over the "original" code. This will definitely be removed before submit. The "#if 0" disables code which I regard helpful but which is just too expensive to have it active, even when guarded with !PRODUCT and VerifyCodeHeap. If I understand your comments correctly, it is strongly discouraged - if not forbidden - to have #if 0 blocks in the code base. Lesson learned. Both blocks will be gone in the next webrev I'll post. That'll be tomorrow, if all goes well. I'd like to keep it as RFR. In my opinion, the code is more mature than experimental. Regards, Lutz ?On 17.10.19, 20:48, "Vladimir Kozlov" wrote: Hi Lutz It should be RFC - change seems experimental since it uses #if 0 and UseNewCode2. Nice improvement. Thanks, Vladimir On 10/17/19 12:28 AM, Schmidt, Lutz wrote: > Dear all, > > may I please request reviews for this fix, addressing actually two current performance issues in CodeHeap management. One issue (the stupid one) could be eliminated completely. The other one, in the context of maintaining the code heap segment map, was tamed considerably. > > From old to new, the following absolute times and speedup factors were observed: > > speedup absolute time [Milliseconds] > old version new version > ppc fastdebug 4,700 69,593.484 14.833 (30,000 calls) > ppc release 4,600 70,069.517 15.215 (30,000 calls) > s390 fastdebug 3,500 7,778.500 2.220 (40,000 calls) > s390 release 6,700 6,935.371 1.026 (40,000 calls) > > > These results are far from clean room measurements. On the other hand, the improvements are so extreme that it can't be just measurement errors. And is it important if the factor is 4k or 3k? > > The performance gain is achieved by taking advantage of properties of the CodeHeap segment map, not by improved coding techniques. You can find more detail in the bug description and as inline documentation in the source code. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231460 > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8231460.00/ > > Please have a look. > Thank you, > Lutz > From lutz.schmidt at sap.com Thu Oct 17 19:52:29 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 17 Oct 2019 19:52:29 +0000 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: <6a9e3306-ff2b-1ded-c0fc-22af5831e776@redhat.com> References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> <37969751-34df-da93-90cc-5746ca4b5a4d@redhat.com> <6a9e3306-ff2b-1ded-c0fc-22af5831e776@redhat.com> Message-ID: <5A263499-D410-4D2A-B257-2F3849BE6D9C@sap.com> Hi Andrew, I don't expect a real-world test to show an effect which pops out of measurement noise. But I'll try. And I will add timing in the CodeHeap management methods to see how often they were called and how much time was spent in there. The most pathological (synthetic) test I could think of is test/hotspot/jtreg/compiler/codecache/OverflowCodeCacheTest.java It obviously frees the code blobs in "the right order", such that there is just one free block which grows, and grows, and grows. If the sequence would be such that it would result in ten free blocks, the inefficiency would be much less visible. Why? The original algorithm has an effort of O(n*n). If you divide the effort into ten parts, you get ten times O((n/10)*(n/10)) = O(n*n)/100. I hope this is somehow understandable. I'm not skilled in explaining mathematical facts in English. Regards, Lutz ?On 17.10.19, 18:35, "Andrew Dinn" wrote: Hi Lutz, On 17/10/2019 16:36, Schmidt, Lutz wrote: > Thank you for looking at the change and, of course, for your thoughts > and comments. > > Let me cover the easy part (heap.cpp:383 - 419) first: > ====================================================== > I fully agree to your suggestions. Your wording is much clearer and > easier to understand. Your suggestions will be contained in the next > webrev iteration. I will not create a separate webrev just for that. Sure, no need to see another webrev on that account. > About the particular test: > ========================== > Yes, the test is completely synthetic in freeing thousands of > CodeHeap blocks in a row. Such a situation will most likely never > occur in a real-world workload. I was digging into this only because > the test timed out on some of our machines. > > I'm not sure if we need another synthetic test to model the real > world. It would be possible as well to add the timing to some > real-world test(s) and analyze what's happening there. Would JBB2005 > or JBB2013 be close enough to the real world? A real test is probably a good place to start. My thought re a synthetic test was that if the cache management time is only a small percentage of the total runtime then that may make it hard to accurately measure the benefit of the patch. Why not start by seeing if a real-world test provides a clear measurable difference? If that fails it might then be worth resorting to running a synthetic test that only exercises the cache management code. It would be good to have evidence that this is actually going to improve performance. > About the risk of segment map fragmentation: > > ============================================ > > Yes, there will be some fragmentation. I never observed fragmentation > to become excessive, however. And there is reason for that: each time > a HeapBlock allocation is satisfied out of the FreeBlock list, that > segment map interval is re-initialized. ... Ah yes, (doh!). I guess you would need a truly pathological pattern of allocs and merges for that to fail to defrag the map. regards, Andrew Dinn ----------- From vladimir.kozlov at oracle.com Thu Oct 17 21:30:40 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 17 Oct 2019 14:30:40 -0700 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> Message-ID: On 10/17/19 12:32 PM, Schmidt, Lutz wrote: > Hi Vladimir, > > thanks for looking at the change. > > You should have seen "if (!UseNewCode)". The intention was to leave in the "old" code that I tested against. The "old" code already has improvements over the "original" code. This will definitely be removed before submit. > > The "#if 0" disables code which I regard helpful but which is just too expensive to have it active, even when guarded with !PRODUCT and VerifyCodeHeap. > > If I understand your comments correctly, it is strongly discouraged - if not forbidden - to have #if 0 blocks in the code base. Lesson learned. RFR assume that the code is tested and is ready to be pushed. It should not contain any experimental or dead code. It is difficult to see what final code will be if you use UseNewCode. > > Both blocks will be gone in the next webrev I'll post. That'll be tomorrow, if all goes well. I'd like to keep it as RFR. In my opinion, the code is more mature than experimental. Sounds good. Thanks, Vladimir > > Regards, > Lutz > > > ?On 17.10.19, 20:48, "Vladimir Kozlov" wrote: > > Hi Lutz > > It should be RFC - change seems experimental since it uses #if 0 and > UseNewCode2. > > Nice improvement. > > Thanks, > Vladimir > > On 10/17/19 12:28 AM, Schmidt, Lutz wrote: > > Dear all, > > > > may I please request reviews for this fix, addressing actually two current performance issues in CodeHeap management. One issue (the stupid one) could be eliminated completely. The other one, in the context of maintaining the code heap segment map, was tamed considerably. > > > > From old to new, the following absolute times and speedup factors were observed: > > > > speedup absolute time [Milliseconds] > > old version new version > > ppc fastdebug 4,700 69,593.484 14.833 (30,000 calls) > > ppc release 4,600 70,069.517 15.215 (30,000 calls) > > s390 fastdebug 3,500 7,778.500 2.220 (40,000 calls) > > s390 release 6,700 6,935.371 1.026 (40,000 calls) > > > > > > These results are far from clean room measurements. On the other hand, the improvements are so extreme that it can't be just measurement errors. And is it important if the factor is 4k or 3k? > > > > The performance gain is achieved by taking advantage of properties of the CodeHeap segment map, not by improved coding techniques. You can find more detail in the bug description and as inline documentation in the source code. > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231460 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8231460.00/ > > > > Please have a look. > > Thank you, > > Lutz > > > > From david.holmes at oracle.com Thu Oct 17 23:37:32 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2019 09:37:32 +1000 Subject: 8231757: [ppc] Fix VerifyOops. Errors show since 8231058. In-Reply-To: References: <3f1be78d-b5e3-192b-d05f-e81ed520d65a@oracle.com> Message-ID: <5e283ed2-1f93-f3a1-1762-da6d5cf465a2@oracle.com> On 18/10/2019 12:10 am, Lindenmaier, Goetz wrote: > Hi David, > > you are right, thanks for pointing me to that! > Doing one test for vm.bits=64 and one for 32 should fix it: > http://cr.openjdk.java.net/~goetz/wr19/8231757-fix_VerifyOops/01/ s/01/02/ :) For the 32-bit case you can delete the line: * @requires vm.debug & (os.arch != "sparc") & (os.arch != "sparcv9") For the 64-but case you can delete the "sparc" check from the same line. Thanks, David > > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes >> Sent: Donnerstag, 17. Oktober 2019 13:18 >> To: Lindenmaier, Goetz ; hotspot-runtime- >> dev at openjdk.java.net; 'hotspot-compiler-dev at openjdk.java.net' > compiler-dev at openjdk.java.net> >> Subject: Re: 8231757: [ppc] Fix VerifyOops. Errors show since 8231058. >> >> Hi Goetz, >> >> UseCompressedOops is a 64-bit flag only so your change will break the >> test on 32-bit systems. >> >> David >> >> On 17/10/2019 8:55 pm, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> 8231058 introduced a test that enables +VerifyOops. >>> This fails on ppc, because this was not used in a very >>> long time. >>> >>> The crash is caused by passing compressed oops from >>> LIR_Assembler::store() to the checker routine. >>> I fix this by implementing a checker routine verify_coop >>> that first decompresses the coop. This makes the new >>> test pass. >>> >>> Further testing showed that the additional checker >>> coding makes Patching Stubs overflow. These >>> can not be increased in size to fit the code. I >>> disable generating verify_oop code in LIRAssembler::load() >>> which fixes the issue. >>> >>> Further I extended the message printed when verification >>> of an oop failed. First, I print the location in the source >>> code where the checker code was generated. Second, >>> I print the faulty oop. >>> >>> I also improved the message printed when PatchingStubs >>> overflow. >>> >>> Finally, I improve the test to run with and without compressed >>> Oops. >>> >>> Please review: >>> http://cr.openjdk.java.net/~goetz/wr19/8231757-fix_VerifyOops/01/ >>> >>> @runtime as I modify the test introduced there >>> @compiler as the error is in C1. >>> >>> Best regards, >>> Goetz. >>> From suenaga at oss.nttdata.com Fri Oct 18 01:03:39 2019 From: suenaga at oss.nttdata.com (Yasumasa Suenaga) Date: Fri, 18 Oct 2019 10:03:39 +0900 Subject: RFR: 8232084: HotSpot build failed with GCC 9.2.1 In-Reply-To: References: <8a78cc16-d077-a9ff-a3fa-01f6d210ffab@oracle.com> <0038f9fd-9544-e905-0ab1-f047b929c5c7@oracle.com> <8bbd54eb-b852-a540-36b8-eba3b24e8f2e@oss.nttdata.com> <49bdd2e7-50ef-3009-3ca0-ed4ae2a14f4d@oracle.com> <7b9158b9-f119-8a03-59e3-28194bad703b@oss.nttdata.com> <2d459846-8329-0df0-17d0-8f544b0daf81@oracle.com> Message-ID: Hi all, I pushed the change: https://hg.openjdk.java.net/jdk/jdk/rev/9f5b92d5a1b2 I hope PRAGMA_STRINGOP_TRUNCATION_IGNORED which introduced in this commit will be used when similar issues occur in future. Thanks for all your help! ?????? Yasumasa On 2019/10/17 13:54, Ioi Lam wrote: > > > On 10/16/19 9:25 PM, Yasumasa Suenaga wrote: >> On 2019/10/17 13:21, David Holmes wrote: >>> On 17/10/2019 2:20 pm, Yasumasa Suenaga wrote: >>>> On 2019/10/17 12:49, David Holmes wrote: >>>>> On 17/10/2019 12:45 pm, Yasumasa Suenaga wrote: >>>>>> On 2019/10/17 11:39, David Holmes wrote: >>>>>>> On 17/10/2019 12:19 pm, Yasumasa Suenaga wrote: >>>>>>>> On 2019/10/17 9:34, David Holmes wrote: >>>>>>>>> On 17/10/2019 10:07 am, serguei.spitsyn at oracle.com wrote: >>>>>>>>>> Hi Yasumasa, >>>>>>>>>> >>>>>>>>>> It looks good. >>>>>>>>>> One tip: >>>>>>>>>> >>>>>>>>>> + // This code would be warned as "stringop-truncation" by GCC 8 or later. >>>>>>>>>> +PRAGMA_DIAG_PUSH >>>>>>>>>> +PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>>>>>>>> ??????? strncpy(buf, str, len); >>>>>>>>>> +PRAGMA_DIAG_POP >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I'd suggest to place the comment before the line with strncopy(). >>>>>>>>> >>>>>>>>> I'd suggest just dropping the comment as it adds nothing, further gcc 8 is not flagging this use of strncpy. >>>>>>>> >>>>>>>> The comment is suggested in [1]. >>>>>>>> Indeed stringop-truncation warning was not reported by GCC 8, but this option introduced in it, >>>>>>>> and I agree with Ioi to add the comment for other developers why this #pragma is needed. >>>>>>> >>>>>>> PRAGMA_STRINGOP_TRUNCATION_IGNORED >>>>>>> >>>>>>> seems to pretty clearly state what the issue is to me. But if you want to add a comment to make that more clear fine. But don't mention gcc 8 as it is not relevant to the need for the pragma now. >>>>>> >>>>>> I'd like to change the comment as below: >>>>>> >>>>>> ???? This code would be warned as "stringop-truncation" by modern GCC >>>>>> >>>>>> Is it ok? >>>>> >>>>> Grammatically it needs work. I propose >>>>> >>>>> // This code can cause a "stringop-truncation" warning with gcc >>>>> >>>>> "modern" will become inaccurate as time goes by. >>>> >>>> Thanks! >>>> To be clear that our code is correct, I will change the comment as below: >>>> >>>> ?? // This code can cause a "stringop-truncation" warning with gcc incorrectly >>> >>> // This code can incorrectly cause a "stringop-truncation" warning with gcc >>> >>> Assuming Ioi feels that is sufficient. >> >> Thanks! and sorry for my English... >> >> Yasumasa >> > > I am happy with David's version. Let's get this over with :-) > > Thanks to everyone, especially to Yasumasa's patience with this. ??????? > > - Ioi >> >>> Thanks, >>> David >>> >>>> >>>> Yasumasa >>>> >>>> >>>>> Thanks, >>>>> David >>>>> >>>>>> >>>>>> Yasumasa >>>>>> >>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> >>>>>>>> >>>>>>>> Yasumasa >>>>>>>> >>>>>>>> >>>>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029578.html >>>>>>>> >>>>>>>>> Otherwise okay. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> >>>>>>>>>> Not? subject for re-review. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Serguei >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 10/16/19 16:25, Yasumasa Suenaga wrote: >>>>>>>>>>> (Re-send email because I could not send original email to serviceability-dev and hotspot-compiler-dev) >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> We discussed the fix for JDK-8232084 in [1], and I think we should fix it with #pragma. >>>>>>>>>>> I uploaded new webrev. Could you review it? >>>>>>>>>>> >>>>>>>>>>> ? JBS: https://bugs.openjdk.java.net/browse/JDK-8232084 >>>>>>>>>>> ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8232084/webrev.03/ >>>>>>>>>>> >>>>>>>>>>> This change has passed the tests on submit repo (mach5-one-ysuenaga-JDK-8232084-1-20191016-1534-5969882). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> Yasumasa >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> [1] https://mail.openjdk.java.net/pipermail/serviceability-dev/2019-October/029547.html >>>>>>>>>> > From david.holmes at oracle.com Fri Oct 18 03:53:10 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 18 Oct 2019 13:53:10 +1000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: Message-ID: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> Hi Martin, On 16/10/2019 11:09 pm, Doerr, Martin wrote: > Hi David, > > thanks for confirming. > > So I suggest to fix it like this: > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.00/ I have no idea why you made any change to CompileBroker::init_compiler_sweeper_threads() as there are no issues at initialization time as that is done by the main thread during VM init. ?? For the changes in CompileBroker::possibly_add_compiler_threads() I would suggest adding an initial comment to replace what you have here: 921 // C1 threads can't create thread objects. 923 // JVMCI compilers are allowed to call Java for creating thread objects. 924 // They should not reuse old ones because unexpected thread state transitions would be observable. to more clearly explain things i.e.: for (int i = old_c2_count; i < new_c2_count; i++) { // Native compiler threads as used in C1/C2 can reuse the j.l.Thread // objects as their existence is completely hidden from the rest of // the VM (and those compiler threads can't call Java code to do the // creation anyway). For JVMCI we have to create new j.l.Thread objects // as they are visible and we can see unexpected thread lifecycle transitions // if we bind them to new JavaThreads. #if INCLUDE_JVMCI ... --- 922 if (!CompilerThread::current()->can_call_java()) break; Just want to confirm this code can only ever be called by compiler threads? Also unclear if UseJVMCICompiler is true, how we might have a compiler thread that can't call Java ?? --- 926 sprintf(name_buffer, "%s CompilerThread%d", _compilers[1]->name(), i); I'm wondering if we should make the name more unique rather than reusing the same name as the old Thread had? This would make debugging somewhat clearer I think. --- 927 Handle thread_oop = create_thread_oop(name_buffer, CHECK); This use of CHECK, and the preexisting use of it with make_thread, is wrong! There is an EXCEPTION_MARK at the start of this method. If either of these calls result in an exception then it will cause a VM abort. I would expect in this case that if any exception occurs we should just clear it, possibly logging it first, and then abandon the operation. Further if this code is being executed by native compiler threads then exceptions are impossible as they couldn't have executed the Java code that would post them! So something seems amiss with regards to exceptions and this code (and what it calls). --- 929 _compiler2_objects[i] = thread_handle; // Old one dies here if it exists. You need to call JNIHandles::destroy_global on the old handle if it exists. Thanks, David ----- > Best regards, > Martin > > >> -----Original Message----- >> From: David Holmes >> Sent: Mittwoch, 16. Oktober 2019 09:11 >> To: Doerr, Martin >> Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; David Holmes >> Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread >> >> Hi Martin, >> >> On 15/10/2019 12:50 am, Doerr, Martin wrote: >>> Hi David, >>> >>>>> As C1 and C2 compiler threads are hidden, I still don't see any problems >> reusing the Thread objects. >>> >>>> They are not completely hidden. Those j.l.Thread objects are still part of >> the system thread group and can be found by other code. >>> >>> I know that they are part of the system thread group, but I thought they >>> should not be visible to Java. >>> >>> E.g. >>> >>> ??????? ThreadGroup tg = new ThreadGroup("A"); >>> ??????? ThreadGroup stg = tg.getParent().getParent(); >>> ??????? Thread[] list = new Thread[100]; >>> ??????? stg.enumerate(list); >>> ??????? System.out.println("Listing elements of " + stg); >>> ??????? for (int i = 0; i < list.length; ++i) { >>> ??????????? if (list[i] != null) { >>> ??????????????? System.out.println(i + ": " + list[i]); >>> ??????????? } >>> ??????? } >>> >>> Finds: >>> >>> Listing elements of java.lang.ThreadGroup[name=system,maxpri=10] >>> >>> 0: Thread[Reference Handler,10,system] >>> 1: Thread[Finalizer,8,system] >>> 2: Thread[Signal Dispatcher,9,system] >>> 3: Thread[main,5,main] >>> >>> I can't see any compiler threads. >> >> Yes you are right. I had forgotten about this other quirk in this whole >> arrangement. Threads started directly by the VM, rather than via >> Thread.start, don't call ThreadGroup.add unless the VM explicitly makes >> that call - which it does for the Signal Dispatcher thread and a couple >> of others. The compiler threads aren't included so while they consider >> themselves to be part of the system ThreadGroup, from the group's >> perspective they are "unstarted threads" - something which is itself >> somewhat of an oddity. But that does mean they are not discoverable that >> way. >> >>> Do you mean finding them by JVMTI agent? >>> >>> As I understand the Spec, compiler threads should be excluded for >>> GetAllThreads: "The threads are Java programming language threads" >> >> They are hidden from JVMTI (unlike the JVMCI compiler threads) >> >>> Or what did you mean by "other code" which can see C1 and C2 threads? >> >> I did mean by enumerating the system ThreadGroup. >> >> So for C1/C2 compiler threads we can probably get away with reusing the >> j.l.Thread object. >> >> Thanks, >> David >> ----- >> >>> Best regards, >>> >>> Martin >>> From fujie at loongson.cn Fri Oct 18 12:50:33 2019 From: fujie at loongson.cn (Jie Fu) Date: Fri, 18 Oct 2019 20:50:33 +0800 Subject: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to over loop unrolling In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2AAB7DF517@fmsmsx121.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2AAB72806A@fmsmsx121.amr.corp.intel.com> <3724faa6-c57c-744a-d7e8-22daa4231078@loongson.cn> <93e239f5-a718-0d24-a799-9a4e586761c8@loongson.cn> <53E8E64DB2403849AFD89B7D4DAC8B2AAB73051E@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7366EF@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7BD33A@fmsmsx121.amr.corp.intel.com> <4e62f5e8-9c14-20e0-3d13-680c527f9d68@loongson.cn> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C1E35@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7C552E@fmsmsx121.amr.corp.intel.com> <53E8E64DB2403849AFD89B7D4DAC8B2AAB7DF517@fmsmsx121.amr.corp.intel.com> Message-ID: <5c824592-6d3b-700f-7f8c-cde22f4c1260@loongson.cn> Hi Vivek, Thanks for your help and feedback. I'll do more investigation next week. Thanks a lot. Best regards, Jie On 2019/10/18 ??2:45, Deshpande, Vivek R wrote: > Hi Jie > > I experimented with your patch and observed that the performance is lower for smaller sizes arrays such as NUM=4, 8 , 16, 32 for byte and long arrays with same test. > > There is a function policy_unroll(PhaseIdealLoop *phase) in loopTransform.cpp, which avoids over unrolling of the loop. > Is there any way you can use or modify that to have the same effect you are intended with this patch? > > Regards, > Vivek > > > -----Original Message----- > From: Jie Fu [mailto:fujie at loongson.cn] > Sent: Thursday, September 26, 2019 6:07 PM > To: Deshpande, Vivek R ; Vladimir Kozlov ; hotspot-compiler-dev at openjdk.java.net; Viswanathan, Sandhya > Subject: Re: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to over loop unrolling > > Thanks Vivek for? your help. > > On 2019/9/27 ??7:16, Deshpande, Vivek R wrote: >> Hi Jie >> >> I tried the patch from webrev.04 with NUM=4096 and looks like the instructions with AVX512 are getting generated. >> I will do some more perf runs and let you know. >> >> Regards, >> Vivek >> >> -----Original Message----- >> From: Jie Fu [mailto:fujie at loongson.cn] >> Sent: Wednesday, September 25, 2019 8:51 AM >> To: Deshpande, Vivek R ; Vladimir Kozlov >> ; hotspot-compiler-dev at openjdk.java.net; >> Viswanathan, Sandhya >> Subject: Re: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to >> over loop unrolling >> >> Hi Vivek, >> >> Thanks for your review and help. Please see responses below. >> >> 1. According to my observation, compiling with full vector length may not always be the smartest choice, especially for small loops. >> ?? For example, if running your test case with NUM = 256 and 128 on >> my >> avx-256 machine, the performance can be improved by 28% and 36% respectively if using 16-byte vectors, instead of full available vector width (32-byte vectors). >> >> 2. My fix [1] aims at improving performance with small loops, while keeping the same performance for large loops compared with the original implementation. >> ?? The patch adds a heuristic to protect against over-unrolling with SuperWordLoopUnrollAnalysis. >> ?? For a more detailed quantitative analysis, please refer to [2]. >> >> 3. I don't quite understand why your test case has to be compiled with 512-bit vector. Could you please explain why? >> ?? For your test case, vector-256 is used in my patch to protect against over-unrolling. >> ?? If I recall correctly, there is no performance difference between 512-bit and 256-bit vectors on your machine. >> ?? However, it doesn't mean vector-512 won't be generated. >> ?? If you try to increase the NUM in your program (e.g., NUM=4096), you will find vector-512 will be generated on your machine. >> ?? I can't see the benefit of using 512-bit vector. That's why I'm asking this question all the time. >> ?? I'd be really appreciated if you would like to answer it. >> >> To validate the effectiveness of the patch, you can test the performance for NUM = 256 and 128 on your avx-512 machine. >> >> Looking forward to your reply. >> >> Thanks a lot. >> Best regards, >> Jie >> >> [1] http://cr.openjdk.java.net/~jiefu/8227505/webrev.04/ >> [2] >> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-Augu >> st/034783.html >> >> >> On 2019/9/25 ??1:20, Deshpande, Vivek R wrote: >>> Hi Jie >>> >>> May be you missed my earlier reply, I had tried your patch from webrev.04. >>> It does not use full 512 bits of the vector and generates 256 bit vector instructions. >>> The log is similar to earlier patch from webrev.03. >>> May be if you tweak this condition it would work. >>> if (future_unroll_factor > cur_trip_cnt) break; >>> >>> Regards, >>> Vivek >>> >>> >>> -----Original Message----- >>> From: Jie Fu [mailto:fujie at loongson.cn] >>> Sent: Tuesday, September 24, 2019 7:59 AM >>> To: Deshpande, Vivek R ; Vladimir Kozlov >>> ; hotspot-compiler-dev at openjdk.java.net; >>> Viswanathan, Sandhya >>> Subject: Re: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to >>> over loop unrolling >>> >>> Hi Vivek, >>> >>> May I get to know whether the not-unroll-after-vectorization problem was fixed by webrev.04 on your avx-512 machine? >>> If not, could you please share me the compile log? >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-Aug >>> ust/034817.html >>> >>> On 2019/9/18 ??9:46, Jie Fu wrote: >>>> Hi Vivek, >>>> >>>> Thank you for your help. >>>> >>>> Does webrev.04 fix the the not-unroll-after-vectorization problem >>>> you mentioned in [1] on your avx-512 machine? >>>> >>>> The patch just adds a heuristic [2] to protect against >>>> over-unrolling with SuperWordLoopUnrollAnalysis. >>>> In order to use the full available vector width, >>>> SuperWordLoopUnrollAnalysis performs loop unrolling much more >>>> aggressively, which may hurt the performance for some cases. >>>> One of the important reasons for the performance degradation of >>>> SuperWordLoopUnrollAnalysis is that it doesn't consider the negative >>>> impact of pre/post-loop at all. >>>> The current SuperWordLoopUnrollAnalysis focuses on reducing the >>>> iterations of the main-loop, but ignores the increment of iterations >>>> in pre/post-loop. >>>> For a more detailed quantitative analysis of that case, please refer >>>> to [2]. >>>> >>>> Thanks a lot. >>>> Best regards, >>>> Jie >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-Au >>>> gu >>>> st/034817.html >>>> [2] >>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-Au >>>> gu >>>> st/034783.html >>>> >>>> On 2019/9/17 ??10:55, Deshpande, Vivek R wrote: >>>>> Hi Jie >>>>> >>>>> I tried your patch from webrev.04. I still see the similar behavior >>>>> as earlier patch. So I am trying to understand what your new patch >>>>> is doing and how we can fix it. >>>>> >>>>> Regards, >>>>> Vivek >>>>> >>>>> -----Original Message----- >>>>> From: Jie Fu [mailto:fujie at loongson.cn] >>>>> Sent: Tuesday, September 10, 2019 8:42 PM >>>>> To: Deshpande, Vivek R ; Vladimir >>>>> Kozlov ; >>>>> hotspot-compiler-dev at openjdk.java.net; >>>>> Viswanathan, Sandhya >>>>> Subject: Re: RFR: 8227505: SuperWordLoopUnrollAnalysis may lead to >>>>> over loop unrolling >>>>> >>>>> Hi Vivek, >>>>> >>>>> Updated: http://cr.openjdk.java.net/~jiefu/8227505/webrev.04/ >>>>> >>>>> With the help of your compile logs, I successfully reproduced the >>>>> not-unroll-after-vectorization problem you mentioned in [1]. >>>>> It had been fixed on my avx-256 machine with this version. >>>>> The patch just adds a heuristic [2] to protect against >>>>> over-unrolling with SuperWordLoopUnrollAnalysis. >>>>> Please review it and give me some advice. >>>>> >>>>> Again, if you have any questions on your avx-512 machine, could you >>>>> please share me the compile logs, especially for NUM = 256, 2048 >>>>> and 4096? >>>>> Please see comments inline. >>>>> >>>>> Thanks a lot. >>>>> Best regards, >>>>> Jie >>>>> >>>>> [1] >>>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-A >>>>> ug >>>>> ust/034817.html >>>>> >>>>> [2] >>>>> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-A >>>>> ug >>>>> ust/034783.html >>>>> >>>>> >>>>> On 2019/9/7 ??7:35, Deshpande, Vivek R wrote: >>>>>> Hi Jie >>>>>> >>>>>> I experimented with both the sizes 1024 and 2048 bytes and looks >>>>>> like the 2nd compilation generates the suboptimal code with >>>>>> shorter vector width. >>>>> I still don't think it's a problem since there is no performance >>>>> gain with full available vector width according to your performance analysis. >>>>> >>>>> >>>>>> Please find it attached. >>>>>> IMO, the fix you have should be able to unroll enough to use the >>>>>> full available vector width. >>>>> Why? >>>>> Unfortunately, compiling with full available vector width can be >>>>> harmful to performance. >>>>> I experimented your test case with NUM = 256 and 128 on my avx-256 >>>>> machine, finding that the performance was frustrated with full >>>>> available vector width (32-byte vectors). >>>>> After the patch, the performance (16-byte vectors) for NUM = 256 >>>>> and >>>>> 128 had been improved by 28% and 36% respectively. >>>>> >>>>> So I wonder about the performance before and after the patch for >>>>> NUM = >>>>> 256 and 128 on your avx-512 machine. >>>>> Could you please also share us? >>>>> >>>>> Thanks. >>>>> >>>>> >>>>>> Regards, >>>>>> Vivek From fujie at loongson.cn Mon Oct 21 09:32:22 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 21 Oct 2019 17:32:22 +0800 Subject: RFR(trivial): 8232692: [TESTBUG] compiler/aot/fingerprint/SelfChangedCDS.java fails when cds is disabled Message-ID: Hi all, May I get reviews for this one-line fix? JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232692 Webrev: http://cr.openjdk.java.net/~jiefu/8232692/webrev.00/ This bug was found after JDK-8232616 had been fixed. When cds is disabled, all tests under compiler/aot passed except this one. So it might be better to fix it. Thanks a lot. Best regards, Jie From fujie at loongson.cn Mon Oct 21 09:50:02 2019 From: fujie at loongson.cn (Jie Fu) Date: Mon, 21 Oct 2019 17:50:02 +0800 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> <17aa1a3a-6129-73e0-c374-902f31cd1300@loongson.cn> <9b4d95f0-0a22-44b4-3bd8-ae61e4c2c293@loongson.cn> <2b2243d4-e067-417a-3854-8c2852a111b4@oracle.com> <340748b4-dc42-850f-9c51-d2667002a1bf@loongson.cn> Message-ID: <7bed3879-9400-4e3c-394e-bf85eaea0e82@loongson.cn> Hi all, Could someone help to review Tom's fix for this issue? Thanks a lot. Best regards, Jie On 2019/10/17 ??4:11, Tom Rodriguez wrote: > > > Jie Fu wrote on 10/15/19 6:42 PM: >> Hi Tom, >> >> It looks good to me. I'm NOT a reviewer. >> >> How about the following change to the indentation? > > Yes I've corrected that in place.? Can I get a review from a reviewer? > > tom > >> ------------------------------------------ >> diff -r a3b0294dfbb5 src/hotspot/share/compiler/oopMap.cpp >> --- a/src/hotspot/share/compiler/oopMap.cpp???? Wed Oct 16 09:27:33 >> 2019 +0800 >> +++ b/src/hotspot/share/compiler/oopMap.cpp???? Wed Oct 16 09:32:48 >> 2019 +0800 >> @@ -313,14 +313,14 @@ >> ??????? OopMapValue omv = oms.current(); >> ??????? if (omv.type() != OopMapValue::derived_oop_value) { >> ????????? continue; >> -??????? } >> +????? } >> >> ??#ifndef TIERED >> ??????? COMPILER1_PRESENT(ShouldNotReachHere();) >> ??#if INCLUDE_JVMCI >> -??????? if (UseJVMCICompiler) { >> -????????? ShouldNotReachHere(); >> -??????? } >> +????? if (UseJVMCICompiler) { >> +??????? ShouldNotReachHere(); >> +????? } >> ??#endif >> ??#endif // !TIERED >> ??????? oop* loc = fr->oopmapreg_to_location(omv.reg(),reg_map); >> ------------------------------------------ >> >> Thanks a lot. >> Best regards, >> Jie >> >> On 2019/10/16 ??12:58, Tom Rodriguez wrote: >>> I've corrected the code at >>> http://cr.openjdk.java.net/~never/8232083.1/webrev and built and ran >>> both a normal and minimal JVM using these changes. >> From Pengfei.Li at arm.com Mon Oct 21 09:55:58 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 21 Oct 2019 09:55:58 +0000 Subject: RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl Message-ID: Hi, Please review this small patch on AArch64 codegen. JBS: https://bugs.openjdk.java.net/browse/JDK-8232591 Webrev: http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.00/ This adds AArch64 match rules for multiplying two 32-bit integers into a 64-bit long with an additional add/sub/neg-long operation. After this patch, AArch64 generated instructions like | smull x10, w1, w2 | add x0, x3, x10 are combined to | smaddl x0, w1, w2, x3 Generated instructions like | smull x10, w1, w2 | sub x0, x3, x10 are combined to | smsubl x0, w1, w2, x3 And generated instructions like | sxtw x11, w2 | sxtw x10, w1 | mneg x0, x11, x10 are combined to | smnegl x0, w2, w1 No new failure is found in full jtreg tests. No obvious performance difference can be seen after this patch. This just reduces the code size a little bit. -- Thanks, Pengfei From adinn at redhat.com Mon Oct 21 11:13:37 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 21 Oct 2019 12:13:37 +0100 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: <5A263499-D410-4D2A-B257-2F3849BE6D9C@sap.com> References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> <37969751-34df-da93-90cc-5746ca4b5a4d@redhat.com> <6a9e3306-ff2b-1ded-c0fc-22af5831e776@redhat.com> <5A263499-D410-4D2A-B257-2F3849BE6D9C@sap.com> Message-ID: <3fce238d-33c8-3ea1-8ba2-b843faca13c2@redhat.com> Hi Lutz, On 17/10/2019 20:52, Schmidt, Lutz wrote: > Hi Andrew, > > I don't expect a real-world test to show an effect which pops out of > measurement noise. But I'll try. And I will add timing in the > CodeHeap management methods to see how often they were called and how > much time was spent in there. Agreed. > The most pathological (synthetic) test I could think of is > test/hotspot/jtreg/compiler/codecache/OverflowCodeCacheTest.java It > obviously frees the code blobs in "the right order", such that there > is just one free block which grows, and grows, and grows. If the > sequence would be such that it would result in ten free blocks, the > inefficiency would be much less visible. > > Why? The original algorithm has an effort of O(n*n). If you divide > the effort into ten parts, you get ten times O((n/10)*(n/10)) = > O(n*n)/100. I hope this is somehow understandable. I'm not skilled in > explaining mathematical facts in English. I follow what you are saying. However, I'm interested to see how much gain you get in a non-pathological case. The worst case gain is less interesting than the common case gain. I tweaked OverflowCodeCacheTest a little to provide a more realistic allocate/free scenario. It woudl be useful to see before and after figures for this test. The code is available here: http://cr.openjdk.java.net/~adinn/stresscodecache/StressCodeCacheTest.java Here is a brief explanation of what it does: The test allocates up to 90% of the cache with varying size blobs (between 70% and 130% of the size used in the Overflow test). Once the cache reaches 90% full it then frees some fraction of the allocated blobs and starts allocating again. That process is repeated 10 times. The frees are done in randomly sized runs of 3 to 15 successively allocated blobs, with a probability of 1 blob being freed in each run. Retained blobs are freed first on the next run before any newly allocated blobs so the cache is slowly cycled. n.b. feel free to tweak or improve it! regards, Andrew Dinn ----------- From lutz.schmidt at sap.com Mon Oct 21 12:37:49 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Mon, 21 Oct 2019 12:37:49 +0000 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: <3fce238d-33c8-3ea1-8ba2-b843faca13c2@redhat.com> References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> <37969751-34df-da93-90cc-5746ca4b5a4d@redhat.com> <6a9e3306-ff2b-1ded-c0fc-22af5831e776@redhat.com> <5A263499-D410-4D2A-B257-2F3849BE6D9C@sap.com> <3fce238d-33c8-3ea1-8ba2-b843faca13c2@redhat.com> Message-ID: <604ED3F3-7A81-46A6-AD44-AB838DE018D3@sap.com> Hi Andrew, I understand what you are interested in. And I was hoping to be able to provide some (first) numbers by today. Unfortunately, the measurement code I activated last Friday was buggy and blew most of the tests I had hoped to run over the weekend. I will take your modified test and run it with and without my optimization. In parallel, I will try to generate some (non-random) numbers for other tests. I'll be back as soon as I have results. Thanks, Lutz ?On 21.10.19, 13:13, "Andrew Dinn" wrote: Hi Lutz, On 17/10/2019 20:52, Schmidt, Lutz wrote: > Hi Andrew, > > I don't expect a real-world test to show an effect which pops out of > measurement noise. But I'll try. And I will add timing in the > CodeHeap management methods to see how often they were called and how > much time was spent in there. Agreed. > The most pathological (synthetic) test I could think of is > test/hotspot/jtreg/compiler/codecache/OverflowCodeCacheTest.java It > obviously frees the code blobs in "the right order", such that there > is just one free block which grows, and grows, and grows. If the > sequence would be such that it would result in ten free blocks, the > inefficiency would be much less visible. > > Why? The original algorithm has an effort of O(n*n). If you divide > the effort into ten parts, you get ten times O((n/10)*(n/10)) = > O(n*n)/100. I hope this is somehow understandable. I'm not skilled in > explaining mathematical facts in English. I follow what you are saying. However, I'm interested to see how much gain you get in a non-pathological case. The worst case gain is less interesting than the common case gain. I tweaked OverflowCodeCacheTest a little to provide a more realistic allocate/free scenario. It woudl be useful to see before and after figures for this test. The code is available here: http://cr.openjdk.java.net/~adinn/stresscodecache/StressCodeCacheTest.java Here is a brief explanation of what it does: The test allocates up to 90% of the cache with varying size blobs (between 70% and 130% of the size used in the Overflow test). Once the cache reaches 90% full it then frees some fraction of the allocated blobs and starts allocating again. That process is repeated 10 times. The frees are done in randomly sized runs of 3 to 15 successively allocated blobs, with a probability of 1 blob being freed in each run. Retained blobs are freed first on the next run before any newly allocated blobs so the cache is slowly cycled. n.b. feel free to tweak or improve it! regards, Andrew Dinn ----------- From adinn at redhat.com Mon Oct 21 13:06:01 2019 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 21 Oct 2019 14:06:01 +0100 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: <604ED3F3-7A81-46A6-AD44-AB838DE018D3@sap.com> References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> <37969751-34df-da93-90cc-5746ca4b5a4d@redhat.com> <6a9e3306-ff2b-1ded-c0fc-22af5831e776@redhat.com> <5A263499-D410-4D2A-B257-2F3849BE6D9C@sap.com> <3fce238d-33c8-3ea1-8ba2-b843faca13c2@redhat.com> <604ED3F3-7A81-46A6-AD44-AB838DE018D3@sap.com> Message-ID: <254f2bf0-94f8-8e78-b043-f428f2d2a0f1@redhat.com> Hi Lutz, On 21/10/2019 13:37, Schmidt, Lutz wrote: > I understand what you are interested in. And I was hoping to be able > to provide some (first) numbers by today. Unfortunately, the > measurement code I activated last Friday was buggy and blew most of > the tests I had hoped to run over the weekend. > > I will take your modified test and run it with and without my > optimization. In parallel, I will try to generate some (non-random) > numbers for other tests. > > I'll be back as soon as I have results. Thanks for trying the test and also for deriving some call stats from a real example. I'm keen to see how much your patch improves things. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From martin.doerr at sap.com Mon Oct 21 13:04:36 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Oct 2019 13:04:36 +0000 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: , <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> <002c7bcf-97cd-e4ef-400c-b40ef812a99e@oracle.com> Message-ID: Hi Michihiro, that looks good to me. Thank you for improving it. Best regards, Martin From: Michihiro Horie Sent: Donnerstag, 17. Oktober 2019 09:15 To: Doerr, Martin Cc: hotspot-compiler-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; vladimir.x.ivanov at oracle.com Subject: RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Hi Vladimir, Martin, I'm sorry for my late response. > > I agree that GraphKit as a ctor argument looks weird. > > > > What about having a static factory and encapsulate the code there instead? I agree and thank you for showing concrete code, which were helpful to fix the change. > Alternatively, the PhaseGVN could get passed instead of the Compile pointer. (Prototype is already included via node.hpp.) > This is already used by some other nodes like > LoadNode::make(PhaseGVN& gvn, ... > So this seems to be a common pattern. Also agree, I followed LoadNode::make. Thank you. Latest webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.06/ Best regards, Michihiro ----- Original message ----- From: "Doerr, Martin" > To: Vladimir Ivanov >, Michihiro Horie > Cc: hotspot compiler >, "ppc-aix-port-dev at openjdk.java.net" > Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Date: Mon, Oct 14, 2019 5:27 PM Hi Vladimir, that looks much better. Thank you. Alternatively, the PhaseGVN could get passed instead of the Compile pointer. (Prototype is already included via node.hpp.) This is already used by some other nodes like LoadNode::make(PhaseGVN& gvn, ... So this seems to be a common pattern. Best regards, Martin > -----Original Message----- > From: Vladimir Ivanov > > Sent: Samstag, 12. Oktober 2019 03:27 > To: Doerr, Martin >; Michihiro Horie > > > Cc: hotspot compiler >; ppc-aix- > port-dev at openjdk.java.net > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > > I agree that GraphKit as a ctor argument looks weird. > > What about having a static factory and encapsulate the code there instead? > > convertnode.hpp: > > RoundDoubleModeNode(Node* in1, ConINode* rmode): Node(0, in1, > rmode) {} > > static RoundDoubleModeNode make(Compile* C, Node* arg, > RoundDoubleModeNode::RoundingMode rmode); > > > convertnode.cpp: > > RoundDoubleModeNode* RoundDoubleModeNode::make(Compile* C, > Node* arg, > RoundDoubleModeNode::RoundingMode rmode) { > ConINode* rm = C->initial_gvn()->intcon(rmode); > return new RoundDoubleModeNode(arg, rm); > } > > > library_call.cpp: > > case vmIntrinsics::_ceil: n = RoundDoubleModeNode::make(C, arg, > RoundDoubleModeNode::rmode_ceil); > > > > > Best regards, > Vladimir Ivanov > > On 09/10/2019 12:29, Doerr, Martin wrote: > > Hi Vladimir and Michihiro, > > > >> ConINode::make() allocates a new node which has to be seen by GVN, so > >> there's a type recorded for it. > > Makes sense. > > > > I'd prefer > > RoundDoubleModeNode(Node *in1, Node *rmode): Node(0, in1, rmode) > {} > > > > and > > case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_floor))); break; > > case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_rint))); break; > > > > That avoids additional includes in convertnode.hpp which can easily lead to > cyclic dependencies for future changes. > > > > Best regards, > > Martin > > > > > >> -----Original Message----- > >> From: Vladimir Ivanov > > >> Sent: Dienstag, 8. Oktober 2019 12:31 > >> To: Doerr, Martin >; Michihiro Horie > >> > > >> Cc: hotspot compiler >; ppc- > aix- > >> port-dev at openjdk.java.net > >> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on > Power > >> > >> > >> > >> On 08/10/2019 13:14, Doerr, Martin wrote: > >>> Hi Vladimir and Michihiro, > >>> > >>> I like webrev.04 more than webrev.05. > >>> I think it's not good to include graphKit.hpp in convertnode.hpp. This > >> creates a weird dependency. > >>> What was the reason for this change? > >> > >> webrev.04 has a bug. Quote from earlier email: > >> > >> "src/hotspot/share/opto/convertnode.hpp: > >> > >> + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, > >> ConINode::make(rmode)) {} > >> > >> ConINode::make() allocates a new node which has to be seen by GVN, so > >> there's a type recorded for it. That's why I mentioned GraphKit*. But > >> you can use PhaseGVN & intcon as well." > >> > >> Alternatively, Compile* can be used as well. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >>>> -----Original Message----- > >>>> From: Vladimir Ivanov > > >>>> Sent: Dienstag, 8. Oktober 2019 11:47 > >>>> To: Michihiro Horie > > >>>> Cc: hotspot compiler >; > Doerr, > >>>> Martin >; ppc-aix-port-dev at openjdk.java.net > >>>> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on > >> Power > >>>> > >>>> > >>>>> http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/ > >>>> > >>>> Looks good. > >>>> > >>>> (Test results are clean.) > >>>> > >>>> Best regards, > >>>> Vladimir Ivanov > >>>> > >>>>> > I think it would be better to use adlc?s include generator instead of > >>>>> > including "opto/convertnode.hpp" explicitly in the ad file. > >>>>> > > >>>>> > src/hotspot/share/adlc/main.cpp > >>>>> > > >>>>> > AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > >>>>> > > >>>>> > + AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > >>>>> > > >>>>> > AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > >>>>> > > >>>>> > @Vladimir: Do you agree? Would you do it this way, too? > >>>>> > >>>>> I prefer current version. > >>>>> > >>>>> When proposing the refactoring I thought about the change in adlc as > >>>>> well, but when I saw the patch I noticed that putting it in AD file > >>>>> stresses it's a platform-specific dependency. > >>>>> > >>>>> I think that's the right way to look at it until we get a way to funnel > >>>>> attributes from ideal nodes to mach nodes and use them during code > >>>>> emission. > >>>>> > >>>>> Best regards, > >>>>> Vladimir Ivanov > >>>>> > >>>>> > *From:*Michihiro Horie > > >>>>> > *Sent:* Montag, 7. Oktober 2019 17:54 > >>>>> > *To:* Vladimir Ivanov > > >>>>> > *Cc:* hotspot compiler dev at openjdk.java.net>; > >>>> Doerr, > >>>>> > Martin >; ppc-aix-port- > >> dev at openjdk.java.net > >>>>> > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>>>> > rint on Power > >>>>> > > >>>>> > Hi Martin, Vladimir, > >>>>> > Thanks a lot for your further feedback, which makes sense. > >>>>> > > >>>>> > New webrev: > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ > >>>>> > > >>>>> > Best regards, > >>>>> > Michihiro > >>>>> > > >>>>> > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > >>>>> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > >>>>> > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, > >> Michihiro. > >>>>> > > >>>>> > From: Vladimir Ivanov > >>>>> > > > >>>>> > To: Michihiro Horie > >> >, > >>>>> > "Doerr, Martin" > >>>> > > >>>>> > Cc: hotspot compiler > >>>>> > >, > >>>>> > "ppc-aix-port-dev at openjdk.java.net > >>>>> > " > >>>>> > > >>>>> > > > >>>>> > Date: 2019/10/07 22:51 > >>>>> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, > >>>>> > floor, rint on Power > >>>>> > > >>>>> > ------------------------------------------------------------------------ > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> >> Fixed webrev is as follows. > >>>>> > > >>>>> > Thanks, Michihiro. > >>>>> > > >>>>> >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ > >>>>> > > >>>>> > src/hotspot/share/opto/convertnode.hpp: > >>>>> > > >>>>> > + enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > >>>>> > > >>>>> > Please, explicitly initialize the elements. Numbering is important > since > >>>>> > it is aligned with instruction encoding on x86. > >>>>> > > >>>>> > > >>>>> > src/hotspot/share/opto/library_call.cpp: > >>>>> > > >>>>> > + case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > >>>>> > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); > >>>> break; > >>>>> > > >>>>> > Please, change RoundDoubleModeNode to accept the enum > instead > >> and > >>>>> > instantiate the ConI node inside it or introduce a static factory > >>>>> > (::make(GraphKit*,RoundingMode)) for that purpose. > >>>>> > > >>>>> > > >>>>> > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > >>>>> > > >>>>> > + void math_round(const FloatRegister t, const FloatRegister b, int > >>>>> rmode); > >>>>> > + void math_round_vec(const VectorSRegister t, const > >> VectorSRegister > >>>> b, > >>>>> > int rmode); > >>>>> > > >>>>> > I suggest to get rid of helpers in MacroAssembler and simply move > >> the > >>>>> > code into corresponding AD instructions. > >>>>> > > >>>>> > Best regards, > >>>>> > Vladimir Ivanov > >>>>> > > >>>>> >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15--- > > I > >>>>> >> suggest to put the enum in RoundDoubleModeNode > >> (convertn"Doerr, > >>>> Martin" > >>>>> >> ---2019/10/07 22:09:15---> I suggest to put the enum in > >>>>> >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction > >>>> selectio > >>>>> >> > >>>>> >> From: "Doerr, Martin" > >>>>> > > >>>>> >> To: Vladimir Ivanov > >>>>> >, > >>>>> > Michihiro Horie > >>>>> >> > > >>>>> >> Cc: hotspot compiler > >>>>> > >, > >>>>> >> "ppc-aix-port-dev at openjdk.java.net > >>>>> > " > >>>>> > > >>>>> > > > >>>>> >> Date: 2019/10/07 22:09 > >>>>> >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for > >> Math.ceil, > >>>>> >> floor, rint on Power > >>>>> >> > >>>>> >> ------------------------------------------------------------------------ > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > >>>> (convertnode.hpp) > >>>>> >> > and lift instruction selection logic from > macroAssembler_ppc.cpp > >>>>> into > >>>>> >> ppc.ad. > >>>>> >> That sounds good. > >>>>> >> > >>>>> >> Thanks, > >>>>> >> Martin > >>>>> >> > >>>>> >> > >>>>> >> > -----Original Message----- > >>>>> >> > From: Vladimir Ivanov > >>>>> > > >>>>> >> > Sent: Montag, 7. Oktober 2019 12:55 > >>>>> >> > To: Doerr, Martin > >>>>> >; Michihiro Horie > >>>>> >> > > > >>>>> >> > Cc: hotspot compiler dev at openjdk.java.net > >>>>> > >; ppc-aix- > >>>>> >> > port-dev at openjdk.java.net >> dev at openjdk.java.net> > >>>>> >> > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>>>> >> rint on Power > >>>>> >> > > >>>>> >> > > I think sharedRuntime is not a good place for the C2 enum. > >>>>> >> > Agree. > >>>>> >> > > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > >>>> (convertnode.hpp) > >>>>> >> > and > >>>>> >> > lift instruction selection logic from macroAssembler_ppc.cpp > into > >>>>> ppc.ad. > >>>>> >> > > >>>>> >> > Best regards, > >>>>> >> > Vladimir Ivanov > >>>>> >> > > >>>>> >> > > > >>>>> >> > > Maybe intrinsicnode.hpp would be a better pace for it. But > >>>>> then, the > >>>>> >> > > code in macroAssembler should be guarded by #ifdef > >> COMPILER2. > >>>>> >> > > > >>>>> >> > > Best regards, > >>>>> >> > > > >>>>> >> > > Martin > >>>>> >> > > > >>>>> >> > > *From:*Michihiro Horie > >>>> > > >>>>> >> > > *Sent:* Montag, 7. Oktober 2019 09:14 > >>>>> >> > > *To:* Vladimir Ivanov > >>>>> > > >>>>> >> > > *Cc:* hotspot compiler >> dev at openjdk.java.net > >>>>> > >; > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > >>>>> > ; Doerr, Martin > >>>>> >> > > > >>>>> >> > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > >>>>> floor, > >>>>> >> > > rint on Power > >>>>> >> > > > >>>>> >> > > Hi Vladimir, > >>>>> >> > > > >>>>> >> > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > >>>>> >> > > I'm wondering if the enum constants can be declared in > >>>>> >> > sharedRuntime.hpp. > >>>>> >> > > Webrev: > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > >>>>> >> > > > >>>>> >> > > Best regards, > >>>>> >> > > Michihiro > >>>>> >> > > > >>>>> >> > > Inactive hide details for Vladimir Ivanov ---2019/10/04 > >>>>> 23:05:48---Hi > >>>>> >> > > Michihiro, > >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > >>>>> Ivanov > >>>>> >> > > ---2019/10/04 23:05:48---Hi Michihiro, > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>>>> >> > > > >>>>> >> > > From: Vladimir Ivanov > >>>>> > > > > > >>>>> > > > >>>>> >> > > To: Michihiro Horie > >>>> >, > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > >>>>> > >>>>> >> > > , hotspot > compiler > >>>>> >> > > > >>>>> > > > > > >>>>> > > > >>>>> >> > > Date: 2019/10/04 23:05 > >>>>> >> > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > >>>>> Math.ceil, > >>>>> >> > > floor, rint on Power > >>>>> >> > > > >>>>> >> > > > >>>>> >> ------------------------------------------------------------------------ > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > Hi Michihiro, > >>>>> >> > > > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>>>> >> > > + switch (rmode) { > >>>>> >> > > + case 0: // rint > >>>>> >> > > + frin(t, b); > >>>>> >> > > + break; > >>>>> >> > > + case 1: // floor > >>>>> >> > > + frim(t, b); > >>>>> >> > > + break; > >>>>> >> > > + case 2: // ceil > >>>>> >> > > + frip(t, b); > >>>>> >> > > + break; > >>>>> >> > > + default: > >>>>> >> > > + ShouldNotReachHere(); > >>>>> >> > > + } > >>>>> >> > > > >>>>> >> > > What do you think about introducing enum constants instead > of > >>>> using > >>>>> >> > > hard-coded 0/1/2? > >>>>> >> > > > >>>>> >> > > src/hotspot/share/opto/library_call.cpp: > >>>>> >> > > > >>>>> >> > > case vmIntrinsics::_ceil: n = new > >> RoundDoubleModeNode(arg, > >>>>> >> > > makecon(TypeInt::make(2))); break; > >>>>> >> > > case vmIntrinsics::_floor: n = new > >> RoundDoubleModeNode(arg, > >>>>> >> > > makecon(TypeInt::make(1))); break; > >>>>> >> > > case vmIntrinsics::_rint: n = new > >> RoundDoubleModeNode(arg, > >>>>> >> > > makecon(TypeInt::make(0))); break; > >>>>> >> > > > >>>>> >> > > The downside is you have to move the switch from > >>>> macroAssembler > >>>>> >> > because > >>>>> >> > > enum should be visible from both places. (Is there a better > >>>>> place for > >>>>> >> > > that than roundD_regNode::emit() in AD file?) > >>>>> >> > > > >>>>> >> > > Best regards, > >>>>> >> > > Vladimir Ivanov > >>>>> >> > > > >>>>> >> > > On 02/10/2019 07:27, Michihiro Horie wrote: > >>>>> >> > >> > >>>>> >> > >> Dear all, > >>>>> >> > >> > >>>>> >> > >> Would you please review the following change? > >>>>> >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > >>>>> >> > >> Webrev: > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > >>>>> >> > >> > >>>>> >> > >> This change adds intrinsics for Math's ceil, floor, and rint for > >>>>> >> PPC64, on > >>>>> >> > >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > >>>>> >> > >> > >>>>> >> > >> Best regards, > >>>>> >> > >> Michihiro > >>>>> >> > >> > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> From HORIE at jp.ibm.com Mon Oct 21 13:38:01 2019 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Mon, 21 Oct 2019 22:38:01 +0900 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> Message-ID: > that looks good to me. Thank you for improving it. Thank you, Martin! Best regards, Michihiro From: "Doerr, Martin" To: Michihiro Horie Cc: "hotspot-compiler-dev at openjdk.java.net" , "ppc-aix-port-dev at openjdk.java.net" , "vladimir.x.ivanov at oracle.com" Date: 2019/10/21 22:06 Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Hi Michihiro, that looks good to me. Thank you for improving it. Best regards, Martin From: Michihiro Horie Sent: Donnerstag, 17. Oktober 2019 09:15 To: Doerr, Martin Cc: hotspot-compiler-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; vladimir.x.ivanov at oracle.com Subject: RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Hi Vladimir, Martin, I'm sorry for my late response. > > I agree that GraphKit as a ctor argument looks weird. > > > > What about having a static factory and encapsulate the code there instead? I agree and thank you for showing concrete code, which were helpful to fix the change. > Alternatively, the PhaseGVN could get passed instead of the Compile pointer. (Prototype is already included via node.hpp.) > This is already used by some other nodes like > LoadNode::make(PhaseGVN& gvn, ... > So this seems to be a common pattern. Also agree, I followed LoadNode::make. Thank you. Latest webrev: http://cr.openjdk.java.net/~mhorie/8231649/webrev.06/ Best regards, Michihiro ----- Original message ----- From: "Doerr, Martin" To: Vladimir Ivanov , Michihiro Horie < HORIE at jp.ibm.com> Cc: hotspot compiler , " ppc-aix-port-dev at openjdk.java.net" Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power Date: Mon, Oct 14, 2019 5:27 PM Hi Vladimir, that looks much better. Thank you. Alternatively, the PhaseGVN could get passed instead of the Compile pointer. (Prototype is already included via node.hpp.) This is already used by some other nodes like LoadNode::make(PhaseGVN& gvn, ... So this seems to be a common pattern. Best regards, Martin > -----Original Message----- > From: Vladimir Ivanov > Sent: Samstag, 12. Oktober 2019 03:27 > To: Doerr, Martin ; Michihiro Horie > > Cc: hotspot compiler ; ppc-aix- > port-dev at openjdk.java.net > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > > I agree that GraphKit as a ctor argument looks weird. > > What about having a static factory and encapsulate the code there instead? > > convertnode.hpp: > > RoundDoubleModeNode(Node* in1, ConINode* rmode): Node(0, in1, > rmode) {} > > static RoundDoubleModeNode make(Compile* C, Node* arg, > RoundDoubleModeNode::RoundingMode rmode); > > > convertnode.cpp: > > RoundDoubleModeNode* RoundDoubleModeNode::make(Compile* C, > Node* arg, > RoundDoubleModeNode::RoundingMode rmode) { > ConINode* rm = C->initial_gvn()->intcon(rmode); > return new RoundDoubleModeNode(arg, rm); > } > > > library_call.cpp: > > case vmIntrinsics::_ceil: n = RoundDoubleModeNode::make(C, arg, > RoundDoubleModeNode::rmode_ceil); > > > > > Best regards, > Vladimir Ivanov > > On 09/10/2019 12:29, Doerr, Martin wrote: > > Hi Vladimir and Michihiro, > > > >> ConINode::make() allocates a new node which has to be seen by GVN, so > >> there's a type recorded for it. > > Makes sense. > > > > I'd prefer > > RoundDoubleModeNode(Node *in1, Node *rmode): Node(0, in1, rmode) > {} > > > > and > > case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_floor))); break; > > case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, > makecon(TypeInt::make(RoundDoubleModeNode::rmode_rint))); break; > > > > That avoids additional includes in convertnode.hpp which can easily lead to > cyclic dependencies for future changes. > > > > Best regards, > > Martin > > > > > >> -----Original Message----- > >> From: Vladimir Ivanov > >> Sent: Dienstag, 8. Oktober 2019 12:31 > >> To: Doerr, Martin ; Michihiro Horie > >> > >> Cc: hotspot compiler ; ppc- > aix- > >> port-dev at openjdk.java.net > >> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on > Power > >> > >> > >> > >> On 08/10/2019 13:14, Doerr, Martin wrote: > >>> Hi Vladimir and Michihiro, > >>> > >>> I like webrev.04 more than webrev.05. > >>> I think it's not good to include graphKit.hpp in convertnode.hpp. This > >> creates a weird dependency. > >>> What was the reason for this change? > >> > >> webrev.04 has a bug. Quote from earlier email: > >> > >> "src/hotspot/share/opto/convertnode.hpp: > >> > >> + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, > >> ConINode::make(rmode)) {} > >> > >> ConINode::make() allocates a new node which has to be seen by GVN, so > >> there's a type recorded for it. That's why I mentioned GraphKit*. But > >> you can use PhaseGVN & intcon as well." > >> > >> Alternatively, Compile* can be used as well. > >> > >> Best regards, > >> Vladimir Ivanov > >> > >>>> -----Original Message----- > >>>> From: Vladimir Ivanov > >>>> Sent: Dienstag, 8. Oktober 2019 11:47 > >>>> To: Michihiro Horie > >>>> Cc: hotspot compiler ; > Doerr, > >>>> Martin ; ppc-aix-port-dev at openjdk.java.net > >>>> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on > >> Power > >>>> > >>>> > >>>>> http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/ > >>>> > >>>> Looks good. > >>>> > >>>> (Test results are clean.) > >>>> > >>>> Best regards, > >>>> Vladimir Ivanov > >>>> > >>>>> > I think it would be better to use adlc?s include generator instead of > >>>>> > including "opto/convertnode.hpp" explicitly in the ad file. > >>>>> > > >>>>> > src/hotspot/share/adlc/main.cpp > >>>>> > > >>>>> > AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > >>>>> > > >>>>> > + AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > >>>>> > > >>>>> > AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > >>>>> > > >>>>> > @Vladimir: Do you agree? Would you do it this way, too? > >>>>> > >>>>> I prefer current version. > >>>>> > >>>>> When proposing the refactoring I thought about the change in adlc as > >>>>> well, but when I saw the patch I noticed that putting it in AD file > >>>>> stresses it's a platform-specific dependency. > >>>>> > >>>>> I think that's the right way to look at it until we get a way to funnel > >>>>> attributes from ideal nodes to mach nodes and use them during code > >>>>> emission. > >>>>> > >>>>> Best regards, > >>>>> Vladimir Ivanov > >>>>> > >>>>> > *From:*Michihiro Horie > >>>>> > *Sent:* Montag, 7. Oktober 2019 17:54 > >>>>> > *To:* Vladimir Ivanov > >>>>> > *Cc:* hotspot compiler dev at openjdk.java.net>; > >>>> Doerr, > >>>>> > Martin ; ppc-aix-port- > >> dev at openjdk.java.net > >>>>> > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>>>> > rint on Power > >>>>> > > >>>>> > Hi Martin, Vladimir, > >>>>> > Thanks a lot for your further feedback, which makes sense. > >>>>> > > >>>>> > New webrev: > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/ > >>>>> > > >>>>> > Best regards, > >>>>> > Michihiro > >>>>> > > >>>>> > Inactive hide details for Vladimir Ivanov ---2019/10/07 22:51:21---> > >>>>> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > >>>>> > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, > >> Michihiro. > >>>>> > > >>>>> > From: Vladimir Ivanov >>>>> > > > >>>>> > To: Michihiro Horie >> >, > >>>>> > "Doerr, Martin" >>>> > > >>>>> > Cc: hotspot compiler >>>>> > >, > >>>>> > "ppc-aix-port-dev at openjdk.java.net > >>>>> > " > >>>>> > >>>>> > > > >>>>> > Date: 2019/10/07 22:51 > >>>>> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, > >>>>> > floor, rint on Power > >>>>> > > >>>>> > ------------------------------------------------------------------------ > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> >> Fixed webrev is as follows. > >>>>> > > >>>>> > Thanks, Michihiro. > >>>>> > > >>>>> >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/ > >>>>> > > >>>>> > src/hotspot/share/opto/convertnode.hpp: > >>>>> > > >>>>> > + enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > >>>>> > > >>>>> > Please, explicitly initialize the elements. Numbering is important > since > >>>>> > it is aligned with instruction encoding on x86. > >>>>> > > >>>>> > > >>>>> > src/hotspot/share/opto/library_call.cpp: > >>>>> > > >>>>> > + case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > >>>>> > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); > >>>> break; > >>>>> > > >>>>> > Please, change RoundDoubleModeNode to accept the enum > instead > >> and > >>>>> > instantiate the ConI node inside it or introduce a static factory > >>>>> > (::make(GraphKit*,RoundingMode)) for that purpose. > >>>>> > > >>>>> > > >>>>> > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > >>>>> > > >>>>> > + void math_round(const FloatRegister t, const FloatRegister b, int > >>>>> rmode); > >>>>> > + void math_round_vec(const VectorSRegister t, const > >> VectorSRegister > >>>> b, > >>>>> > int rmode); > >>>>> > > >>>>> > I suggest to get rid of helpers in MacroAssembler and simply move > >> the > >>>>> > code into corresponding AD instructions. > >>>>> > > >>>>> > Best regards, > >>>>> > Vladimir Ivanov > >>>>> > > >>>>> >> Inactive hide details for "Doerr, Martin" ---2019/10/07 22:09:15--- > > I > >>>>> >> suggest to put the enum in RoundDoubleModeNode > >> (convertn"Doerr, > >>>> Martin" > >>>>> >> ---2019/10/07 22:09:15---> I suggest to put the enum in > >>>>> >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction > >>>> selectio > >>>>> >> > >>>>> >> From: "Doerr, Martin" >>>>> > > >>>>> >> To: Vladimir Ivanov >>>>> >, > >>>>> > Michihiro Horie > >>>>> >> > > >>>>> >> Cc: hotspot compiler >>>>> > >, > >>>>> >> "ppc-aix-port-dev at openjdk.java.net > >>>>> > " > >>>>> > >>>>> > > > >>>>> >> Date: 2019/10/07 22:09 > >>>>> >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for > >> Math.ceil, > >>>>> >> floor, rint on Power > >>>>> >> > >>>>> >> ------------------------------------------------------------------------ > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > >>>> (convertnode.hpp) > >>>>> >> > and lift instruction selection logic from > macroAssembler_ppc.cpp > >>>>> into > >>>>> >> ppc.ad. > >>>>> >> That sounds good. > >>>>> >> > >>>>> >> Thanks, > >>>>> >> Martin > >>>>> >> > >>>>> >> > >>>>> >> > -----Original Message----- > >>>>> >> > From: Vladimir Ivanov >>>>> > > >>>>> >> > Sent: Montag, 7. Oktober 2019 12:55 > >>>>> >> > To: Doerr, Martin >>>>> >; Michihiro Horie > >>>>> >> > > > >>>>> >> > Cc: hotspot compiler dev at openjdk.java.net > >>>>> > >; ppc-aix- > >>>>> >> > port-dev at openjdk.java.net >> dev at openjdk.java.net> > >>>>> >> > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > >>>>> >> rint on Power > >>>>> >> > > >>>>> >> > > I think sharedRuntime is not a good place for the C2 enum. > >>>>> >> > Agree. > >>>>> >> > > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > >>>> (convertnode.hpp) > >>>>> >> > and > >>>>> >> > lift instruction selection logic from macroAssembler_ppc.cpp > into > >>>>> ppc.ad. > >>>>> >> > > >>>>> >> > Best regards, > >>>>> >> > Vladimir Ivanov > >>>>> >> > > >>>>> >> > > > >>>>> >> > > Maybe intrinsicnode.hpp would be a better pace for it. But > >>>>> then, the > >>>>> >> > > code in macroAssembler should be guarded by #ifdef > >> COMPILER2. > >>>>> >> > > > >>>>> >> > > Best regards, > >>>>> >> > > > >>>>> >> > > Martin > >>>>> >> > > > >>>>> >> > > *From:*Michihiro Horie >>>> > > >>>>> >> > > *Sent:* Montag, 7. Oktober 2019 09:14 > >>>>> >> > > *To:* Vladimir Ivanov >>>>> > > >>>>> >> > > *Cc:* hotspot compiler >> dev at openjdk.java.net > >>>>> > >; > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > >>>>> > ; Doerr, Martin > >>>>> >> > > > >>>>> >> > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > >>>>> floor, > >>>>> >> > > rint on Power > >>>>> >> > > > >>>>> >> > > Hi Vladimir, > >>>>> >> > > > >>>>> >> > > Thanks a lot for your nice suggestion. Yes, I prefer enum use. > >>>>> >> > > I'm wondering if the enum constants can be declared in > >>>>> >> > sharedRuntime.hpp. > >>>>> >> > > Webrev: > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/ > >>>>> >> > > > >>>>> >> > > Best regards, > >>>>> >> > > Michihiro > >>>>> >> > > > >>>>> >> > > Inactive hide details for Vladimir Ivanov ---2019/10/04 > >>>>> 23:05:48---Hi > >>>>> >> > > Michihiro, > >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > >>>>> Ivanov > >>>>> >> > > ---2019/10/04 23:05:48---Hi Michihiro, > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>>>> >> > > > >>>>> >> > > From: Vladimir Ivanov >>>>> > > > > > >>>>> > > > >>>>> >> > > To: Michihiro Horie >>>> >, > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > >>>>> > >>>>> >> > > , hotspot > compiler > >>>>> >> > > >>>>> > > > > > >>>>> > > > >>>>> >> > > Date: 2019/10/04 23:05 > >>>>> >> > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > >>>>> Math.ceil, > >>>>> >> > > floor, rint on Power > >>>>> >> > > > >>>>> >> > > > >>>>> >> ------------------------------------------------------------------------ > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > Hi Michihiro, > >>>>> >> > > > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > >>>>> >> > > + switch (rmode) { > >>>>> >> > > + case 0: // rint > >>>>> >> > > + frin(t, b); > >>>>> >> > > + break; > >>>>> >> > > + case 1: // floor > >>>>> >> > > + frim(t, b); > >>>>> >> > > + break; > >>>>> >> > > + case 2: // ceil > >>>>> >> > > + frip(t, b); > >>>>> >> > > + break; > >>>>> >> > > + default: > >>>>> >> > > + ShouldNotReachHere(); > >>>>> >> > > + } > >>>>> >> > > > >>>>> >> > > What do you think about introducing enum constants instead > of > >>>> using > >>>>> >> > > hard-coded 0/1/2? > >>>>> >> > > > >>>>> >> > > src/hotspot/share/opto/library_call.cpp: > >>>>> >> > > > >>>>> >> > > case vmIntrinsics::_ceil: n = new > >> RoundDoubleModeNode(arg, > >>>>> >> > > makecon(TypeInt::make(2))); break; > >>>>> >> > > case vmIntrinsics::_floor: n = new > >> RoundDoubleModeNode(arg, > >>>>> >> > > makecon(TypeInt::make(1))); break; > >>>>> >> > > case vmIntrinsics::_rint: n = new > >> RoundDoubleModeNode(arg, > >>>>> >> > > makecon(TypeInt::make(0))); break; > >>>>> >> > > > >>>>> >> > > The downside is you have to move the switch from > >>>> macroAssembler > >>>>> >> > because > >>>>> >> > > enum should be visible from both places. (Is there a better > >>>>> place for > >>>>> >> > > that than roundD_regNode::emit() in AD file?) > >>>>> >> > > > >>>>> >> > > Best regards, > >>>>> >> > > Vladimir Ivanov > >>>>> >> > > > >>>>> >> > > On 02/10/2019 07:27, Michihiro Horie wrote: > >>>>> >> > >> > >>>>> >> > >> Dear all, > >>>>> >> > >> > >>>>> >> > >> Would you please review the following change? > >>>>> >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231649 > >>>>> >> > >> Webrev: > >> http://cr.openjdk.java.net/~mhorie/8231649/webrev.00 > >>>>> >> > >> > >>>>> >> > >> This change adds intrinsics for Math's ceil, floor, and rint for > >>>>> >> PPC64, on > >>>>> >> > >> top of 8226721: Missing intrinsics for Math.ceil, floor, rint. > >>>>> >> > >> > >>>>> >> > >> Best regards, > >>>>> >> > >> Michihiro > >>>>> >> > >> > >>>>> >> > > > >>>>> >> > > > >>>>> >> > > > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> > > >>>>> > > >>>>> > > >>>>> > >>>>> > >>>>> > >>>>> From aph at redhat.com Mon Oct 21 14:15:52 2019 From: aph at redhat.com (Andrew Haley) Date: Mon, 21 Oct 2019 15:15:52 +0100 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: References: Message-ID: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> On 10/21/19 10:55 AM, Pengfei Li (Arm Technology China) wrote: > No new failure is found in full jtreg tests. No obvious performance difference can be seen after this patch. This just reduces the code size a little bit. The patch looks reasonable enough, but do any jtreg tests check for the corner cases, etc.? If not, please add some. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Mon Oct 21 18:02:55 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 21 Oct 2019 18:02:55 +0000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> Message-ID: Hi David, > I have no idea why you made any change to > CompileBroker::init_compiler_sweeper_threads() as there are no issues at > initialization time as that is done by the main thread during VM init. ?? This part of the change is not strictly necessary, but otherwise, we'd create thread objects which would never be used. We only need one JVMCI thread object during init. possibly_add_compiler_threads() creates new ones directly before using them (on demand). > For the changes in CompileBroker::possibly_add_compiler_threads() I > would suggest adding an initial comment to replace what you have here: > > 921 // C1 threads can't create thread objects. > 923 // JVMCI compilers are allowed to call Java for creating > thread objects. > 924 // They should not reuse old ones because unexpected > thread state transitions would be observable. > > to more clearly explain things i.e.: > > for (int i = old_c2_count; i < new_c2_count; i++) { > // Native compiler threads as used in C1/C2 can reuse the j.l.Thread > // objects as their existence is completely hidden from the rest of > // the VM (and those compiler threads can't call Java code to do the > // creation anyway). For JVMCI we have to create new j.l.Thread objects > // as they are visible and we can see unexpected thread lifecycle > transitions > // if we bind them to new JavaThreads. > #if INCLUDE_JVMCI > ... > > --- Sure, I can replace the comment. > 922 if (!CompilerThread::current()->can_call_java()) break; > > Just want to confirm this code can only ever be called by compiler threads? It's only called by compiler_thread_loop which asserts this. > Also unclear if UseJVMCICompiler is true, how we might have a compiler > thread that can't call Java ?? With TieredCompilation, C1 compiler threads also adds C2 threads if their queue is long. However, only JVMCI threads can create new JVMCI threads if they have to create thread objects. > 926 sprintf(name_buffer, "%s CompilerThread%d", > _compilers[1]->name(), i); > > I'm wondering if we should make the name more unique rather than reusing > the same name as the old Thread had? This would make debugging > somewhat > clearer I think. Not sure if gaps between compiler thread numbers would be expected / desired. But if all reviewers prefer that, I can change it. > 927 Handle thread_oop = create_thread_oop(name_buffer, CHECK); > > This use of CHECK, and the preexisting use of it with make_thread, is > wrong! There is an EXCEPTION_MARK at the start of this method. If either > of these calls result in an exception then it will cause a VM abort. I > would expect in this case that if any exception occurs we should just > clear it, possibly logging it first, and then abandon the operation. > Further if this code is being executed by native compiler threads then > exceptions are impossible as they couldn't have executed the Java code > that would post them! So something seems amiss with regards to > exceptions and this code (and what it calls). Right. We should clear the exception and abort the JVMCI thread creation. > 929 _compiler2_objects[i] = thread_handle; // Old one dies > here if it exists. > > You need to call JNIHandles::destroy_global on the old handle if it exists. I don't want to release the handle. Just to replace the thread object in the handle. Comment updated. New webrev: http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.01/ Best regards, Martin From vladimir.kozlov at oracle.com Mon Oct 21 18:09:08 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Oct 2019 11:09:08 -0700 Subject: RFR(trivial): 8232692: [TESTBUG] compiler/aot/fingerprint/SelfChangedCDS.java fails when cds is disabled In-Reply-To: References: Message-ID: <6376462f-dcb1-2c90-4298-07b257ae40a9@oracle.com> Right! Thank you for fixing it. Vladimir On 10/21/19 2:32 AM, Jie Fu wrote: > Hi all, > > May I get reviews for this one-line fix? > > JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232692 > Webrev: http://cr.openjdk.java.net/~jiefu/8232692/webrev.00/ > > This bug was found after JDK-8232616 had been fixed. > When cds is disabled, all tests under compiler/aot passed except this one. > So it might be better to fix it. > > Thanks a lot. > Best regards, > Jie > > From fujie at loongson.cn Tue Oct 22 01:13:35 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 22 Oct 2019 09:13:35 +0800 Subject: RFR(trivial): 8232692: [TESTBUG] compiler/aot/fingerprint/SelfChangedCDS.java fails when cds is disabled In-Reply-To: <6376462f-dcb1-2c90-4298-07b257ae40a9@oracle.com> References: <6376462f-dcb1-2c90-4298-07b257ae40a9@oracle.com> Message-ID: <7253e2da-ae72-e2cf-6698-8b572b35f1fb@loongson.cn> Hi Vladimir, Thanks for your review. Updated: http://cr.openjdk.java.net/~jiefu/8232692/webrev.01/ ?- just added the reviewer in it. Is it OK to be pushed? I think it's trivial. And I need a sponsor. Thanks a lot. Best regards, Jie On 2019/10/22 ??2:09, Vladimir Kozlov wrote: > Right! Thank you for fixing it. > > Vladimir > > On 10/21/19 2:32 AM, Jie Fu wrote: >> Hi all, >> >> May I get reviews for this one-line fix? >> >> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232692 >> Webrev: http://cr.openjdk.java.net/~jiefu/8232692/webrev.00/ >> >> This bug was found after JDK-8232616 had been fixed. >> When cds is disabled, all tests under compiler/aot passed except this >> one. >> So it might be better to fix it. >> >> Thanks a lot. >> Best regards, >> Jie >> >> From vladimir.kozlov at oracle.com Tue Oct 22 02:02:20 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Oct 2019 19:02:20 -0700 Subject: RFR(trivial): 8232692: [TESTBUG] compiler/aot/fingerprint/SelfChangedCDS.java fails when cds is disabled In-Reply-To: <7253e2da-ae72-e2cf-6698-8b572b35f1fb@loongson.cn> References: <6376462f-dcb1-2c90-4298-07b257ae40a9@oracle.com> <7253e2da-ae72-e2cf-6698-8b572b35f1fb@loongson.cn> Message-ID: Yes, it is trivial Vladimir On 10/21/19 6:13 PM, Jie Fu wrote: > Hi Vladimir, > > Thanks for your review. > > Updated: http://cr.openjdk.java.net/~jiefu/8232692/webrev.01/ > ?- just added the reviewer in it. > > Is it OK to be pushed? I think it's trivial. > And I need a sponsor. > > Thanks a lot. > Best regards, > Jie > > On 2019/10/22 ??2:09, Vladimir Kozlov wrote: >> Right! Thank you for fixing it. >> >> Vladimir >> >> On 10/21/19 2:32 AM, Jie Fu wrote: >>> Hi all, >>> >>> May I get reviews for this one-line fix? >>> >>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232692 >>> Webrev: http://cr.openjdk.java.net/~jiefu/8232692/webrev.00/ >>> >>> This bug was found after JDK-8232616 had been fixed. >>> When cds is disabled, all tests under compiler/aot passed except this one. >>> So it might be better to fix it. >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> > From vladimir.kozlov at oracle.com Tue Oct 22 02:04:52 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 21 Oct 2019 19:04:52 -0700 Subject: RFR(trivial): 8232692: [TESTBUG] compiler/aot/fingerprint/SelfChangedCDS.java fails when cds is disabled In-Reply-To: References: <6376462f-dcb1-2c90-4298-07b257ae40a9@oracle.com> <7253e2da-ae72-e2cf-6698-8b572b35f1fb@loongson.cn> Message-ID: <2d681520-4b9f-9e68-8980-1d3265d6aee3@oracle.com> Sorry, I missed that you need sponsor. I pushed changes. Regards, Vladimir On 10/21/19 7:02 PM, Vladimir Kozlov wrote: > Yes, it is trivial > > Vladimir > > On 10/21/19 6:13 PM, Jie Fu wrote: >> Hi Vladimir, >> >> Thanks for your review. >> >> Updated: http://cr.openjdk.java.net/~jiefu/8232692/webrev.01/ >> ??- just added the reviewer in it. >> >> Is it OK to be pushed? I think it's trivial. >> And I need a sponsor. >> >> Thanks a lot. >> Best regards, >> Jie >> >> On 2019/10/22 ??2:09, Vladimir Kozlov wrote: >>> Right! Thank you for fixing it. >>> >>> Vladimir >>> >>> On 10/21/19 2:32 AM, Jie Fu wrote: >>>> Hi all, >>>> >>>> May I get reviews for this one-line fix? >>>> >>>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232692 >>>> Webrev: http://cr.openjdk.java.net/~jiefu/8232692/webrev.00/ >>>> >>>> This bug was found after JDK-8232616 had been fixed. >>>> When cds is disabled, all tests under compiler/aot passed except this one. >>>> So it might be better to fix it. >>>> >>>> Thanks a lot. >>>> Best regards, >>>> Jie >>>> >>>> >> From fujie at loongson.cn Tue Oct 22 02:06:51 2019 From: fujie at loongson.cn (Jie Fu) Date: Tue, 22 Oct 2019 10:06:51 +0800 Subject: RFR(trivial): 8232692: [TESTBUG] compiler/aot/fingerprint/SelfChangedCDS.java fails when cds is disabled In-Reply-To: <2d681520-4b9f-9e68-8980-1d3265d6aee3@oracle.com> References: <6376462f-dcb1-2c90-4298-07b257ae40a9@oracle.com> <7253e2da-ae72-e2cf-6698-8b572b35f1fb@loongson.cn> <2d681520-4b9f-9e68-8980-1d3265d6aee3@oracle.com> Message-ID: Thank you so much, Vladimir. On 2019/10/22 ??10:04, Vladimir Kozlov wrote: > Sorry, I missed that you need sponsor. > > I pushed changes. > > Regards, > Vladimir > > On 10/21/19 7:02 PM, Vladimir Kozlov wrote: >> Yes, it is trivial >> >> Vladimir >> >> On 10/21/19 6:13 PM, Jie Fu wrote: >>> Hi Vladimir, >>> >>> Thanks for your review. >>> >>> Updated: http://cr.openjdk.java.net/~jiefu/8232692/webrev.01/ >>> ??- just added the reviewer in it. >>> >>> Is it OK to be pushed? I think it's trivial. >>> And I need a sponsor. >>> >>> Thanks a lot. >>> Best regards, >>> Jie >>> >>> On 2019/10/22 ??2:09, Vladimir Kozlov wrote: >>>> Right! Thank you for fixing it. >>>> >>>> Vladimir >>>> >>>> On 10/21/19 2:32 AM, Jie Fu wrote: >>>>> Hi all, >>>>> >>>>> May I get reviews for this one-line fix? >>>>> >>>>> JBS:??? https://bugs.openjdk.java.net/browse/JDK-8232692 >>>>> Webrev: http://cr.openjdk.java.net/~jiefu/8232692/webrev.00/ >>>>> >>>>> This bug was found after JDK-8232616 had been fixed. >>>>> When cds is disabled, all tests under compiler/aot passed except >>>>> this one. >>>>> So it might be better to fix it. >>>>> >>>>> Thanks a lot. >>>>> Best regards, >>>>> Jie >>>>> >>>>> >>> From vladimir.x.ivanov at oracle.com Tue Oct 22 03:50:06 2019 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 22 Oct 2019 06:50:06 +0300 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> <002c7bcf-97cd-e4ef-400c-b40ef812a99e@oracle.com> Message-ID: > http://cr.openjdk.java.net/~mhorie/8231649/webrev.06/ Changes in shared code look good! Best regards, Vladimir Ivanov > ----- Original message ----- > From: "Doerr, Martin" > To: Vladimir Ivanov , Michihiro Horie > > Cc: hotspot compiler , > "ppc-aix-port-dev at openjdk.java.net" > Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on Power > Date: Mon, Oct 14, 2019 5:27 PM > > Hi Vladimir, > > that looks much better. Thank you. > > Alternatively, the PhaseGVN could get passed instead of the Compile > pointer. (Prototype is already included via node.hpp.) > This is already used by some other nodes like > LoadNode::make(PhaseGVN& gvn, ... > So this seems to be a common pattern. > > Best regards, > Martin > > > > -----Original Message----- > > From: Vladimir Ivanov > > Sent: Samstag, 12. Oktober 2019 03:27 > > To: Doerr, Martin ; Michihiro Horie > > > > Cc: hotspot compiler ; ppc-aix- > > port-dev at openjdk.java.net > > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on Power > > > > I agree that GraphKit as a ctor argument looks weird. > > > > What about having a static factory and encapsulate the code there > instead? > > > > convertnode.hpp: > > > > RoundDoubleModeNode(Node* in1, ConINode* rmode): Node(0, in1, > > rmode) {} > > > > static RoundDoubleModeNode make(Compile* C, Node* arg, > > RoundDoubleModeNode::RoundingMode rmode); > > > > > > convertnode.cpp: > > > > RoundDoubleModeNode* RoundDoubleModeNode::make(Compile* C, > > Node* arg, > > RoundDoubleModeNode::RoundingMode rmode) { > > ConINode* rm = C->initial_gvn()->intcon(rmode); > > return new RoundDoubleModeNode(arg, rm); > > } > > > > > > library_call.cpp: > > > > case vmIntrinsics::_ceil: n = RoundDoubleModeNode::make(C, arg, > > RoundDoubleModeNode::rmode_ceil); > > > > > > > > > > Best regards, > > Vladimir Ivanov > > > > On 09/10/2019 12:29, Doerr, Martin wrote: > > > Hi Vladimir and Michihiro, > > > > > >> ConINode::make() allocates a new node which has to be seen by GVN, so > > >> there's a type recorded for it. > > > Makes sense. > > > > > > I'd prefer > > > RoundDoubleModeNode(Node *in1, Node *rmode): Node(0, in1, rmode) > > {} > > > > > > and > > > case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > > case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(RoundDoubleModeNode::rmode_floor))); break; > > > case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(RoundDoubleModeNode::rmode_rint))); break; > > > > > > That avoids additional includes in convertnode.hpp which can easily > lead to > > cyclic dependencies for future changes. > > > > > > Best regards, > > > Martin > > > > > > > > >> -----Original Message----- > > >> From: Vladimir Ivanov > > >> Sent: Dienstag, 8. Oktober 2019 12:31 > > >> To: Doerr, Martin ; Michihiro Horie > > >> > > >> Cc: hotspot compiler ; ppc- > > aix- > > >> port-dev at openjdk.java.net > > >> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on > > Power > > >> > > >> > > >> > > >> On 08/10/2019 13:14, Doerr, Martin wrote: > > >>> Hi Vladimir and Michihiro, > > >>> > > >>> I like webrev.04 more than webrev.05. > > >>> I think it's not good to include graphKit.hpp in convertnode.hpp. > This > > >> creates a weird dependency. > > >>> What was the reason for this change? > > >> > > >> webrev.04 has a bug. Quote from earlier email: > > >> > > >> "src/hotspot/share/opto/convertnode.hpp: > > >> > > >> + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, > > >> ConINode::make(rmode)) {} > > >> > > >> ConINode::make() allocates a new node which has to be seen by GVN, so > > >> there's a type recorded for it. That's why I mentioned GraphKit*. But > > >> you can use PhaseGVN & intcon as well." > > >> > > >> Alternatively, Compile* can be used as well. > > >> > > >> Best regards, > > >> Vladimir Ivanov > > >> > > >>>> -----Original Message----- > > >>>> From: Vladimir Ivanov > > >>>> Sent: Dienstag, 8. Oktober 2019 11:47 > > >>>> To: Michihiro Horie > > >>>> Cc: hotspot compiler ; > > Doerr, > > >>>> Martin ; ppc-aix-port-dev at openjdk.java.net > > >>>> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on > > >> Power > > >>>> > > >>>> > > >>>>> _http://cr.openjdk.java.net/~mhorie/8231649/webrev.05/_ > > >>>> > > >>>> Looks good. > > >>>> > > >>>> (Test results are clean.) > > >>>> > > >>>> Best regards, > > >>>> Vladimir Ivanov > > >>>> > > >>>>> > I think it would be better to use adlc?s include generator > instead of > > >>>>> > including "opto/convertnode.hpp" explicitly in the ad file. > > >>>>> > > > >>>>> > src/hotspot/share/adlc/main.cpp > > >>>>> > > > >>>>> > AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > > >>>>> > > > >>>>> > + AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > > >>>>> > > > >>>>> > AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > > >>>>> > > > >>>>> > @Vladimir: Do you agree? Would you do it this way, too? > > >>>>> > > >>>>> I prefer current version. > > >>>>> > > >>>>> When proposing the refactoring I thought about the change in > adlc as > > >>>>> well, but when I saw the patch I noticed that putting it in AD file > > >>>>> stresses it's a platform-specific dependency. > > >>>>> > > >>>>> I think that's the right way to look at it until we get a way > to funnel > > >>>>> attributes from ideal nodes to mach nodes and use them during code > > >>>>> emission. > > >>>>> > > >>>>> Best regards, > > >>>>> Vladimir Ivanov > > >>>>> > > >>>>> > *From:*Michihiro Horie > > >>>>> > *Sent:* Montag, 7. Oktober 2019 17:54 > > >>>>> > *To:* Vladimir Ivanov > > >>>>> > *Cc:* hotspot compiler > dev at openjdk.java.net>; > > >>>> Doerr, > > >>>>> > Martin ; ppc-aix-port- > > >> dev at openjdk.java.net > > >>>>> > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, > > >>>>> > rint on Power > > >>>>> > > > >>>>> > Hi Martin, Vladimir, > > >>>>> > Thanks a lot for your further feedback, which makes sense. > > >>>>> > > > >>>>> > New webrev: > > >> _http://cr.openjdk.java.net/~mhorie/8231649/webrev.04/_ > > >>>>> > > > >>>>> > Best regards, > > >>>>> > Michihiro > > >>>>> > > > >>>>> > Inactive hide details for Vladimir Ivanov ---2019/10/07 > 22:51:21---> > > >>>>> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > > >>>>> > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, > > >> Michihiro. > > >>>>> > > > >>>>> > From: Vladimir Ivanov > >>>>> > <_mailto:vladimir.x.ivanov at oracle.com_>> > > >>>>> > To: Michihiro Horie > >> <_mailto:HORIE at jp.ibm.com_>>, > > >>>>> > "Doerr, Martin" > >>>> <_mailto:martin.doerr at sap.com_>> > > >>>>> > Cc: hotspot compiler > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>>, > > >>>>> > "ppc-aix-port-dev at openjdk.java.net > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > >>>>> > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > > >>>>> > Date: 2019/10/07 22:51 > > >>>>> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > > Math.ceil, > > >>>>> > floor, rint on Power > > >>>>> > > > >>>>> > > ------------------------------------------------------------------------ > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> >> Fixed webrev is as follows. > > >>>>> > > > >>>>> > Thanks, Michihiro. > > >>>>> > > > >>>>> >> _http://cr.openjdk.java.net/~mhorie/8231649/webrev.03/_ > > >>>>> > > > >>>>> > src/hotspot/share/opto/convertnode.hpp: > > >>>>> > > > >>>>> > + enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > > >>>>> > > > >>>>> > Please, explicitly initialize the elements. Numbering is > important > > since > > >>>>> > it is aligned with instruction encoding on x86. > > >>>>> > > > >>>>> > > > >>>>> > src/hotspot/share/opto/library_call.cpp: > > >>>>> > > > >>>>> > + case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > > >>>>> > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); > > >>>> break; > > >>>>> > > > >>>>> > Please, change RoundDoubleModeNode to accept the enum > > instead > > >> and > > >>>>> > instantiate the ConI node inside it or introduce a static factory > > >>>>> > (::make(GraphKit*,RoundingMode)) for that purpose. > > >>>>> > > > >>>>> > > > >>>>> > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > > >>>>> > > > >>>>> > + void math_round(const FloatRegister t, const FloatRegister > b, int > > >>>>> rmode); > > >>>>> > + void math_round_vec(const VectorSRegister t, const > > >> VectorSRegister > > >>>> b, > > >>>>> > int rmode); > > >>>>> > > > >>>>> > I suggest to get rid of helpers in MacroAssembler and simply move > > >> the > > >>>>> > code into corresponding AD instructions. > > >>>>> > > > >>>>> > Best regards, > > >>>>> > Vladimir Ivanov > > >>>>> > > > >>>>> >> Inactive hide details for "Doerr, Martin" ---2019/10/07 > 22:09:15--- > > > I > > >>>>> >> suggest to put the enum in RoundDoubleModeNode > > >> (convertn"Doerr, > > >>>> Martin" > > >>>>> >> ---2019/10/07 22:09:15---> I suggest to put the enum in > > >>>>> >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction > > >>>> selectio > > >>>>> >> > > >>>>> >> From: "Doerr, Martin" > >>>>> <_mailto:martin.doerr at sap.com_>> > > >>>>> >> To: Vladimir Ivanov > >>>>> <_mailto:vladimir.x.ivanov at oracle.com_>>, > > >>>>> > Michihiro Horie > > >>>>> >> > > > >>>>> >> Cc: hotspot compiler > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>>, > > >>>>> >> "ppc-aix-port-dev at openjdk.java.net > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > >>>>> > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > > >>>>> >> Date: 2019/10/07 22:09 > > >>>>> >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for > > >> Math.ceil, > > >>>>> >> floor, rint on Power > > >>>>> >> > > >>>>> >> > ------------------------------------------------------------------------ > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > > >>>> (convertnode.hpp) > > >>>>> >> > and lift instruction selection logic from > > macroAssembler_ppc.cpp > > >>>>> into > > >>>>> >> ppc.ad. > > >>>>> >> That sounds good. > > >>>>> >> > > >>>>> >> Thanks, > > >>>>> >> Martin > > >>>>> >> > > >>>>> >> > > >>>>> >> > -----Original Message----- > > >>>>> >> > From: Vladimir Ivanov > >>>>> <_mailto:vladimir.x.ivanov at oracle.com_>> > > >>>>> >> > Sent: Montag, 7. Oktober 2019 12:55 > > >>>>> >> > To: Doerr, Martin > >>>>> <_mailto:martin.doerr at sap.com_>>; Michihiro Horie > > >>>>> >> > > > > >>>>> >> > Cc: hotspot compiler > dev at openjdk.java.net > > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>>; ppc-aix- > > >>>>> >> > port-dev at openjdk.java.net <_mailto:port-_ > > >> dev at openjdk.java.net> > > >>>>> >> > Subject: Re: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, floor, > > >>>>> >> rint on Power > > >>>>> >> > > > >>>>> >> > > I think sharedRuntime is not a good place for the C2 enum. > > >>>>> >> > Agree. > > >>>>> >> > > > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > > >>>> (convertnode.hpp) > > >>>>> >> > and > > >>>>> >> > lift instruction selection logic from macroAssembler_ppc.cpp > > into > > >>>>> ppc.ad. > > >>>>> >> > > > >>>>> >> > Best regards, > > >>>>> >> > Vladimir Ivanov > > >>>>> >> > > > >>>>> >> > > > > >>>>> >> > > Maybe intrinsicnode.hpp would be a better pace for it. But > > >>>>> then, the > > >>>>> >> > > code in macroAssembler should be guarded by #ifdef > > >> COMPILER2. > > >>>>> >> > > > > >>>>> >> > > Best regards, > > >>>>> >> > > > > >>>>> >> > > Martin > > >>>>> >> > > > > >>>>> >> > > *From:*Michihiro Horie > >>>> <_mailto:HORIE at jp.ibm.com_>> > > >>>>> >> > > *Sent:* Montag, 7. Oktober 2019 09:14 > > >>>>> >> > > *To:* Vladimir Ivanov > >>>>> <_mailto:vladimir.x.ivanov at oracle.com_>> > > >>>>> >> > > *Cc:* hotspot compiler > >> dev at openjdk.java.net > > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>>; > > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>; Doerr, Martin > > >>>>> >> > > > > >>>>> >> > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, > > >>>>> floor, > > >>>>> >> > > rint on Power > > >>>>> >> > > > > >>>>> >> > > Hi Vladimir, > > >>>>> >> > > > > >>>>> >> > > Thanks a lot for your nice suggestion. Yes, I prefer > enum use. > > >>>>> >> > > I'm wondering if the enum constants can be declared in > > >>>>> >> > sharedRuntime.hpp. > > >>>>> >> > > Webrev: > > >> _http://cr.openjdk.java.net/~mhorie/8231649/webrev.02/_ > > >>>>> >> > > > > >>>>> >> > > Best regards, > > >>>>> >> > > Michihiro > > >>>>> >> > > > > >>>>> >> > > Inactive hide details for Vladimir Ivanov ---2019/10/04 > > >>>>> 23:05:48---Hi > > >>>>> >> > > Michihiro, > > >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > > >>>>> Ivanov > > >>>>> >> > > ---2019/10/04 23:05:48---Hi Michihiro, > > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > >>>>> >> > > > > >>>>> >> > > From: Vladimir Ivanov > >>>>> > <_mailto:vladimir.x.ivanov at oracle.com%0b_>> > > > > >>>>> > <_mailto:vladimir.x.ivanov at oracle.com_>> > > >>>>> >> > > To: Michihiro Horie > >>>> <_mailto:HORIE at jp.ibm.com_>>, > > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > > >>>>> <_mailto:ppc-aix-port-dev at openjdk.java.net_> > > >>>>> >> > > <_mailto:ppc-aix-port-dev at openjdk.java.net_>, hotspot > > compiler > > >>>>> >> > > > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net%0b_>> > > > > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>> > > >>>>> >> > > Date: 2019/10/04 23:05 > > >>>>> >> > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > > >>>>> Math.ceil, > > >>>>> >> > > floor, rint on Power > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > ------------------------------------------------------------------------ > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > Hi Michihiro, > > >>>>> >> > > > > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > >>>>> >> > > + switch (rmode) { > > >>>>> >> > > + case 0: // rint > > >>>>> >> > > + frin(t, b); > > >>>>> >> > > + break; > > >>>>> >> > > + case 1: // floor > > >>>>> >> > > + frim(t, b); > > >>>>> >> > > + break; > > >>>>> >> > > + case 2: // ceil > > >>>>> >> > > + frip(t, b); > > >>>>> >> > > + break; > > >>>>> >> > > + default: > > >>>>> >> > > + ShouldNotReachHere(); > > >>>>> >> > > + } > > >>>>> >> > > > > >>>>> >> > > What do you think about introducing enum constants instead > > of > > >>>> using > > >>>>> >> > > hard-coded 0/1/2? > > >>>>> >> > > > > >>>>> >> > > src/hotspot/share/opto/library_call.cpp: > > >>>>> >> > > > > >>>>> >> > > case vmIntrinsics::_ceil: n = new > > >> RoundDoubleModeNode(arg, > > >>>>> >> > > makecon(TypeInt::make(2))); break; > > >>>>> >> > > case vmIntrinsics::_floor: n = new > > >> RoundDoubleModeNode(arg, > > >>>>> >> > > makecon(TypeInt::make(1))); break; > > >>>>> >> > > case vmIntrinsics::_rint: n = new > > >> RoundDoubleModeNode(arg, > > >>>>> >> > > makecon(TypeInt::make(0))); break; > > >>>>> >> > > > > >>>>> >> > > The downside is you have to move the switch from > > >>>> macroAssembler > > >>>>> >> > because > > >>>>> >> > > enum should be visible from both places. (Is there a better > > >>>>> place for > > >>>>> >> > > that than roundD_regNode::emit() in AD file?) > > >>>>> >> > > > > >>>>> >> > > Best regards, > > >>>>> >> > > Vladimir Ivanov > > >>>>> >> > > > > >>>>> >> > > On 02/10/2019 07:27, Michihiro Horie wrote: > > >>>>> >> > >> > > >>>>> >> > >> Dear all, > > >>>>> >> > >> > > >>>>> >> > >> Would you please review the following change? > > >>>>> >> > >> Bug: _https://bugs.openjdk.java.net/browse/JDK-8231649_ > > >>>>> >> > >> Webrev: > > >> _http://cr.openjdk.java.net/~mhorie/8231649/webrev.00_ > > >>>>> >> > >> > > >>>>> >> > >> This change adds intrinsics for Math's ceil, floor, and > rint for > > >>>>> >> PPC64, on > > >>>>> >> > >> top of 8226721: Missing intrinsics for Math.ceil, > floor, rint. > > >>>>> >> > >> > > >>>>> >> > >> Best regards, > > >>>>> >> > >> Michihiro > > >>>>> >> > >> > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > From dean.long at oracle.com Tue Oct 22 05:46:27 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 21 Oct 2019 22:46:27 -0700 Subject: RFR(XS): 8232083: Minimal VM is broken after JDK-8231586 In-Reply-To: References: <56d1aa5a-8ff4-8d55-3178-2b113660574e@loongson.cn> <56cf1032-76aa-f27f-124a-9591a4825a98@loongson.cn> <37ae73f1-8491-7477-b211-790031fe15ec@loongson.cn> <17aa1a3a-6129-73e0-c374-902f31cd1300@loongson.cn> <9b4d95f0-0a22-44b4-3bd8-ae61e4c2c293@loongson.cn> <2b2243d4-e067-417a-3854-8c2852a111b4@oracle.com> <340748b4-dc42-850f-9c51-d2667002a1bf@loongson.cn> Message-ID: <359a6ad5-4bf1-b581-7d10-acf77145d9c9@oracle.com> Looks good. dl On 10/16/19 1:11 PM, Tom Rodriguez wrote: > > > Jie Fu wrote on 10/15/19 6:42 PM: >> Hi Tom, >> >> It looks good to me. I'm NOT a reviewer. >> >> How about the following change to the indentation? > > Yes I've corrected that in place.? Can I get a review from a reviewer? > > tom > >> ------------------------------------------ >> diff -r a3b0294dfbb5 src/hotspot/share/compiler/oopMap.cpp >> --- a/src/hotspot/share/compiler/oopMap.cpp???? Wed Oct 16 09:27:33 >> 2019 +0800 >> +++ b/src/hotspot/share/compiler/oopMap.cpp???? Wed Oct 16 09:32:48 >> 2019 +0800 >> @@ -313,14 +313,14 @@ >> ??????? OopMapValue omv = oms.current(); >> ??????? if (omv.type() != OopMapValue::derived_oop_value) { >> ????????? continue; >> -??????? } >> +????? } >> >> ??#ifndef TIERED >> ??????? COMPILER1_PRESENT(ShouldNotReachHere();) >> ??#if INCLUDE_JVMCI >> -??????? if (UseJVMCICompiler) { >> -????????? ShouldNotReachHere(); >> -??????? } >> +????? if (UseJVMCICompiler) { >> +??????? ShouldNotReachHere(); >> +????? } >> ??#endif >> ??#endif // !TIERED >> ??????? oop* loc = fr->oopmapreg_to_location(omv.reg(),reg_map); >> ------------------------------------------ >> >> Thanks a lot. >> Best regards, >> Jie >> >> On 2019/10/16 ??12:58, Tom Rodriguez wrote: >>> I've corrected the code at >>> http://cr.openjdk.java.net/~never/8232083.1/webrev and built and ran >>> both a normal and minimal JVM using these changes. >> From david.holmes at oracle.com Tue Oct 22 06:15:19 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Oct 2019 16:15:19 +1000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> Message-ID: <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> Hi Martin, On 22/10/2019 4:02 am, Doerr, Martin wrote: > Hi David, > >> I have no idea why you made any change to >> CompileBroker::init_compiler_sweeper_threads() as there are no issues at >> initialization time as that is done by the main thread during VM init. ?? > > This part of the change is not strictly necessary, but otherwise, we'd create thread objects which would never be used. > We only need one JVMCI thread object during init. possibly_add_compiler_threads() creates new ones directly before using them (on demand). Okay. > >> For the changes in CompileBroker::possibly_add_compiler_threads() I >> would suggest adding an initial comment to replace what you have here: >> >> 921 // C1 threads can't create thread objects. >> 923 // JVMCI compilers are allowed to call Java for creating >> thread objects. >> 924 // They should not reuse old ones because unexpected >> thread state transitions would be observable. >> >> to more clearly explain things i.e.: >> >> for (int i = old_c2_count; i < new_c2_count; i++) { >> // Native compiler threads as used in C1/C2 can reuse the j.l.Thread >> // objects as their existence is completely hidden from the rest of >> // the VM (and those compiler threads can't call Java code to do the >> // creation anyway). For JVMCI we have to create new j.l.Thread objects >> // as they are visible and we can see unexpected thread lifecycle >> transitions >> // if we bind them to new JavaThreads. >> #if INCLUDE_JVMCI >> ... >> >> --- > > Sure, I can replace the comment. Thanks. > >> 922 if (!CompilerThread::current()->can_call_java()) break; >> >> Just want to confirm this code can only ever be called by compiler threads? > > It's only called by compiler_thread_loop which asserts this. Okay. > >> Also unclear if UseJVMCICompiler is true, how we might have a compiler >> thread that can't call Java ?? > > With TieredCompilation, C1 compiler threads also adds C2 threads if their queue is long. > However, only JVMCI threads can create new JVMCI threads if they have to create thread objects. Okay - It wasn't clear to me that JVMCI threads and native compiler threads can co-exist in the same incarnation of the VM. > >> 926 sprintf(name_buffer, "%s CompilerThread%d", >> _compilers[1]->name(), i); >> >> I'm wondering if we should make the name more unique rather than reusing >> the same name as the old Thread had? This would make debugging >> somewhat clearer I think. > > Not sure if gaps between compiler thread numbers would be expected / desired. > But if all reviewers prefer that, I can change it. The flip side of that is if you see CompilerThread2 in logging output etc and try to reason about things you could get very confused if it was actually entirely different threads. But I'll defer to compiler folk as they will be the ones that have to deal with that confusion. > >> 927 Handle thread_oop = create_thread_oop(name_buffer, CHECK); >> >> This use of CHECK, and the preexisting use of it with make_thread, is >> wrong! There is an EXCEPTION_MARK at the start of this method. If either >> of these calls result in an exception then it will cause a VM abort. I >> would expect in this case that if any exception occurs we should just >> clear it, possibly logging it first, and then abandon the operation. >> Further if this code is being executed by native compiler threads then >> exceptions are impossible as they couldn't have executed the Java code >> that would post them! So something seems amiss with regards to >> exceptions and this code (and what it calls). > > Right. We should clear the exception and abort the JVMCI thread creation. Okay. The preexisting: 946 JavaThread *ct = make_thread(compiler2_object(i), _c2_compile_queue, _compilers[1], CHECK); should have a bug filed to have it fixed as well. > >> 929 _compiler2_objects[i] = thread_handle; // Old one dies >> here if it exists. >> >> You need to call JNIHandles::destroy_global on the old handle if it exists. > > I don't want to release the handle. Just to replace the thread object in the handle. > Comment updated. Sorry I don't follow. The initial Handle stored in the array was a global handle. You just allocated a second global Handle. I don't see any operator=() magic happening here to free one of those global handles, so AFAICS you need to free one of them. Thanks, David ----- > > New webrev: > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.01/ > > > Best regards, > Martin > From tobias.hartmann at oracle.com Tue Oct 22 07:26:12 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 22 Oct 2019 09:26:12 +0200 Subject: [14] RFR(S): 8231412: C2: InitializeNode::detect_init_independence() bails out on simple IR shapes In-Reply-To: References: Message-ID: <700fe698-066f-dec1-492c-6e748f5462fa@oracle.com> Hi Christian, this looks good to me. Best regards, Tobias On 11.10.19 12:34, Christian Hagedorn wrote: > Hi > > Please review the following enhancement: > https://bugs.openjdk.java.net/browse/JDK-8231412 > http://cr.openjdk.java.net/~chagedorn/8231412/webrev.00/ > > This enhancement addresses the early bailout of capturing a field store to remove unnecessary > zeroing [1] in simple methods containing only non-escaping objects. As a consequence, some > allocations were marked not scalar replaceable by the escape analysis which prevented their > elimination. > > The patch translates the recursive algorithm of the InitializeNode::detect_init_independence() > method into an iterative one to avoid processing the same nodes twice. Additionally, a dominator > check is inserted to further reduce iterations: If a CFG node dominates the current allocation then > there cannot be any dependency beyond that node. In order to successfully apply this check for the > sample program from the original discussion where this enhancement came up [2] and the corresponding > jtreg test in the patch, the constant [3] was increased. As a result the field store can be captured > and the escape analysis can remove all allocations in those methods. The larger value of the > constant [3] had no negative impact on performance (verified with some standard benchmarks). > > Thank you! > > Best regards, > Christian > > > [1] http://hg.openjdk.java.net/jdk/jdk/file/e98509cb3867/src/hotspot/share/opto/memnode.cpp#l3602 > [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035135.html > [3] http://hg.openjdk.java.net/jdk/jdk/file/e98509cb3867/src/hotspot/share/opto/phaseX.cpp#l902 From tobias.hartmann at oracle.com Tue Oct 22 07:30:46 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 22 Oct 2019 09:30:46 +0200 Subject: RFR(S): 8231565: More node budget assert in fuzzed test In-Reply-To: <7a0b347a-02f3-b841-82eb-f0887fd6d7f3@oracle.com> References: <7a0b347a-02f3-b841-82eb-f0887fd6d7f3@oracle.com> Message-ID: <11bd5e70-9e0d-9df9-d345-a9d1ba0b30e5@oracle.com> Hi Patric, the fix looks good to me but why does the test contain multiple copies of the same run statements? Best regards, Tobias On 15.10.19 16:20, Patric Hedlin wrote: > Dear all, > > I would like to ask for help to review the following change/update: > > Issue:? https://bugs.openjdk.java.net/browse/JDK-8231565 > Webrev: http://cr.openjdk.java.net/~phedlin/tr8231565/ > > 8231565: More node budget assert in fuzzed test > > ??? Another bad estimate. Loop rotation is too poorly approximated > ??? as a clone operation alone. Same ad-hoc. > > > Testing: hs-tier1..3, hs-precheckin-comp, JavaFuzzer > ??? Including new TC > > > Best regards, > Patric > From rwestrel at redhat.com Tue Oct 22 09:11:54 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 22 Oct 2019 11:11:54 +0200 Subject: [14] RFR(S): 8231412: C2: InitializeNode::detect_init_independence() bails out on simple IR shapes In-Reply-To: References: Message-ID: <87h841b0v9.fsf@redhat.com> Hi Christian, Thanks for working on this. > http://cr.openjdk.java.net/~chagedorn/8231412/webrev.00/ Is this still required? 3553 uint first_i = n->find_edge(m); 3554 if (i != first_i) continue; // process duplicate edge just once If m was already processed, it's armless to push it on the work list again because it's a Unique_Node_List so the check above is redundant? Otherwise, looks good to me. Roland. From Pengfei.Li at arm.com Tue Oct 22 09:50:29 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 22 Oct 2019 09:50:29 +0000 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> Message-ID: Hi, > The patch looks reasonable enough, but do any jtreg tests check for the > corner cases, etc.? > > If not, please add some. I don't find any jtreg cases testing these. I've created a jtreg and uploaded a new webrev, please see http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.01/ Is it good enough? -- Thanks, Pengfei From christian.hagedorn at oracle.com Tue Oct 22 10:42:22 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Tue, 22 Oct 2019 12:42:22 +0200 Subject: [14] RFR(S): 8231412: C2: InitializeNode::detect_init_independence() bails out on simple IR shapes In-Reply-To: <87h841b0v9.fsf@redhat.com> References: <87h841b0v9.fsf@redhat.com> Message-ID: <281b3352-c1d1-cb4a-0ea7-3b762bff3faa@oracle.com> Thank you Tobias and Roland for your reviews! On 22.10.19 11:11, Roland Westrelin wrote: > Is this still required? > > 3553 uint first_i = n->find_edge(m); > 3554 if (i != first_i) continue; // process duplicate edge just once > > If m was already processed, it's armless to push it on the work list > again because it's a Unique_Node_List so the check above is redundant? You're right. This check is not necessary anymore with a Unique_Node_List. I updated the webrev again: http://cr.openjdk.java.net/~chagedorn/8231412/webrev.01/ Best regards, Christian From martin.doerr at sap.com Tue Oct 22 13:18:47 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 22 Oct 2019 13:18:47 +0000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> Message-ID: Hi David, > Okay. The preexisting: > > 946 JavaThread *ct = make_thread(compiler2_object(i), > _c2_compile_queue, _compilers[1], CHECK); > > > should have a bug filed to have it fixed as well. Since I'm touching this code with this change, I just fixed it. I guess this problem is rather a theoretical one. > Sorry I don't follow. The initial Handle stored in the array was a > global handle. You just allocated a second global Handle. I don't see > any operator=() magic happening here to free one of those global > handles, so AFAICS you need to free one of them. Sorry. I had implemented it differently than I wanted. Thanks for pointing me to it. Fixed: http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.02/ Best regards, Martin > -----Original Message----- > From: David Holmes > Sent: Dienstag, 22. Oktober 2019 08:15 > To: Doerr, Martin > Cc: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Vladimir Kozlov (vladimir.kozlov at oracle.com) > ; dean.long at oracle.com; David Holmes > > Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread > > Hi Martin, > > On 22/10/2019 4:02 am, Doerr, Martin wrote: > > Hi David, > > > >> I have no idea why you made any change to > >> CompileBroker::init_compiler_sweeper_threads() as there are no issues > at > >> initialization time as that is done by the main thread during VM init. ?? > > > > This part of the change is not strictly necessary, but otherwise, we'd create > thread objects which would never be used. > > We only need one JVMCI thread object during init. > possibly_add_compiler_threads() creates new ones directly before using > them (on demand). > > Okay. > > > > >> For the changes in CompileBroker::possibly_add_compiler_threads() I > >> would suggest adding an initial comment to replace what you have here: > >> > >> 921 // C1 threads can't create thread objects. > >> 923 // JVMCI compilers are allowed to call Java for creating > >> thread objects. > >> 924 // They should not reuse old ones because unexpected > >> thread state transitions would be observable. > >> > >> to more clearly explain things i.e.: > >> > >> for (int i = old_c2_count; i < new_c2_count; i++) { > >> // Native compiler threads as used in C1/C2 can reuse the j.l.Thread > >> // objects as their existence is completely hidden from the rest of > >> // the VM (and those compiler threads can't call Java code to do the > >> // creation anyway). For JVMCI we have to create new j.l.Thread > objects > >> // as they are visible and we can see unexpected thread lifecycle > >> transitions > >> // if we bind them to new JavaThreads. > >> #if INCLUDE_JVMCI > >> ... > >> > >> --- > > > > Sure, I can replace the comment. > > Thanks. > > > > >> 922 if (!CompilerThread::current()->can_call_java()) break; > >> > >> Just want to confirm this code can only ever be called by compiler > threads? > > > > It's only called by compiler_thread_loop which asserts this. > > Okay. > > > > >> Also unclear if UseJVMCICompiler is true, how we might have a compiler > >> thread that can't call Java ?? > > > > With TieredCompilation, C1 compiler threads also adds C2 threads if their > queue is long. > > However, only JVMCI threads can create new JVMCI threads if they have > to create thread objects. > > Okay - It wasn't clear to me that JVMCI threads and native compiler > threads can co-exist in the same incarnation of the VM. > > > > >> 926 sprintf(name_buffer, "%s CompilerThread%d", > >> _compilers[1]->name(), i); > >> > >> I'm wondering if we should make the name more unique rather than > reusing > >> the same name as the old Thread had? This would make debugging > >> somewhat clearer I think. > > > > Not sure if gaps between compiler thread numbers would be expected / > desired. > > But if all reviewers prefer that, I can change it. > > The flip side of that is if you see CompilerThread2 in logging output > etc and try to reason about things you could get very confused if it was > actually entirely different threads. But I'll defer to compiler folk as > they will be the ones that have to deal with that confusion. > > > > >> 927 Handle thread_oop = create_thread_oop(name_buffer, > CHECK); > >> > >> This use of CHECK, and the preexisting use of it with make_thread, is > >> wrong! There is an EXCEPTION_MARK at the start of this method. If either > >> of these calls result in an exception then it will cause a VM abort. I > >> would expect in this case that if any exception occurs we should just > >> clear it, possibly logging it first, and then abandon the operation. > >> Further if this code is being executed by native compiler threads then > >> exceptions are impossible as they couldn't have executed the Java code > >> that would post them! So something seems amiss with regards to > >> exceptions and this code (and what it calls). > > > > Right. We should clear the exception and abort the JVMCI thread creation. > > Okay. The preexisting: > > 946 JavaThread *ct = make_thread(compiler2_object(i), > _c2_compile_queue, _compilers[1], CHECK); > > > should have a bug filed to have it fixed as well. > > > > >> 929 _compiler2_objects[i] = thread_handle; // Old one dies > >> here if it exists. > >> > >> You need to call JNIHandles::destroy_global on the old handle if it exists. > > > > I don't want to release the handle. Just to replace the thread object in the > handle. > > Comment updated. > > Sorry I don't follow. The initial Handle stored in the array was a > global handle. You just allocated a second global Handle. I don't see > any operator=() magic happening here to free one of those global > handles, so AFAICS you need to free one of them. > > Thanks, > David > ----- > > > > > New webrev: > > > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr > ev.01/ > > > > > > Best regards, > > Martin > > From david.holmes at oracle.com Tue Oct 22 13:38:54 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 22 Oct 2019 23:38:54 +1000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> Message-ID: <57ba4889-a46b-9b8d-f762-1a1efddeb54a@oracle.com> On 22/10/2019 11:18 pm, Doerr, Martin wrote: > Hi David, > >> Okay. The preexisting: >> >> 946 JavaThread *ct = make_thread(compiler2_object(i), >> _c2_compile_queue, _compilers[1], CHECK); >> >> >> should have a bug filed to have it fixed as well. > > Since I'm touching this code with this change, I just fixed it. I guess this problem is rather a theoretical one. You didn't change line 946 as referenced above, you made changes to CompileBroker::init_compiler_sweeper_threads(). You don't need to make changes there as any issue is dealt with during VM init anyway. Additionally there are still many uses of CHECK in that function which would also need fixing. So I'd advise just leave that function alone. But please fix CompileBroker::possibly_add_compiler_threads (line 956 in your current webrev). > >> Sorry I don't follow. The initial Handle stored in the array was a >> global handle. You just allocated a second global Handle. I don't see >> any operator=() magic happening here to free one of those global >> handles, so AFAICS you need to free one of them. > > Sorry. I had implemented it differently than I wanted. Thanks for pointing me to it. I can't say I like the direct use of OopStorage and NativeAccess::oop_store. That seems to be breaking Handle encapsulation to me. I'd like to hear Kim Barrett's opinion on that in particular; or other runtime engineers. David ----- > Fixed: > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.02/ > > > Best regards, > Martin > > >> -----Original Message----- >> From: David Holmes >> Sent: Dienstag, 22. Oktober 2019 08:15 >> To: Doerr, Martin >> Cc: 'hotspot-compiler-dev at openjdk.java.net' > dev at openjdk.java.net>; Vladimir Kozlov (vladimir.kozlov at oracle.com) >> ; dean.long at oracle.com; David Holmes >> >> Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread >> >> Hi Martin, >> >> On 22/10/2019 4:02 am, Doerr, Martin wrote: >>> Hi David, >>> >>>> I have no idea why you made any change to >>>> CompileBroker::init_compiler_sweeper_threads() as there are no issues >> at >>>> initialization time as that is done by the main thread during VM init. ?? >>> >>> This part of the change is not strictly necessary, but otherwise, we'd create >> thread objects which would never be used. >>> We only need one JVMCI thread object during init. >> possibly_add_compiler_threads() creates new ones directly before using >> them (on demand). >> >> Okay. >> >>> >>>> For the changes in CompileBroker::possibly_add_compiler_threads() I >>>> would suggest adding an initial comment to replace what you have here: >>>> >>>> 921 // C1 threads can't create thread objects. >>>> 923 // JVMCI compilers are allowed to call Java for creating >>>> thread objects. >>>> 924 // They should not reuse old ones because unexpected >>>> thread state transitions would be observable. >>>> >>>> to more clearly explain things i.e.: >>>> >>>> for (int i = old_c2_count; i < new_c2_count; i++) { >>>> // Native compiler threads as used in C1/C2 can reuse the j.l.Thread >>>> // objects as their existence is completely hidden from the rest of >>>> // the VM (and those compiler threads can't call Java code to do the >>>> // creation anyway). For JVMCI we have to create new j.l.Thread >> objects >>>> // as they are visible and we can see unexpected thread lifecycle >>>> transitions >>>> // if we bind them to new JavaThreads. >>>> #if INCLUDE_JVMCI >>>> ... >>>> >>>> --- >>> >>> Sure, I can replace the comment. >> >> Thanks. >> >>> >>>> 922 if (!CompilerThread::current()->can_call_java()) break; >>>> >>>> Just want to confirm this code can only ever be called by compiler >> threads? >>> >>> It's only called by compiler_thread_loop which asserts this. >> >> Okay. >> >>> >>>> Also unclear if UseJVMCICompiler is true, how we might have a compiler >>>> thread that can't call Java ?? >>> >>> With TieredCompilation, C1 compiler threads also adds C2 threads if their >> queue is long. >>> However, only JVMCI threads can create new JVMCI threads if they have >> to create thread objects. >> >> Okay - It wasn't clear to me that JVMCI threads and native compiler >> threads can co-exist in the same incarnation of the VM. >> >>> >>>> 926 sprintf(name_buffer, "%s CompilerThread%d", >>>> _compilers[1]->name(), i); >>>> >>>> I'm wondering if we should make the name more unique rather than >> reusing >>>> the same name as the old Thread had? This would make debugging >>>> somewhat clearer I think. >>> >>> Not sure if gaps between compiler thread numbers would be expected / >> desired. >>> But if all reviewers prefer that, I can change it. >> >> The flip side of that is if you see CompilerThread2 in logging output >> etc and try to reason about things you could get very confused if it was >> actually entirely different threads. But I'll defer to compiler folk as >> they will be the ones that have to deal with that confusion. >> >>> >>>> 927 Handle thread_oop = create_thread_oop(name_buffer, >> CHECK); >>>> >>>> This use of CHECK, and the preexisting use of it with make_thread, is >>>> wrong! There is an EXCEPTION_MARK at the start of this method. If either >>>> of these calls result in an exception then it will cause a VM abort. I >>>> would expect in this case that if any exception occurs we should just >>>> clear it, possibly logging it first, and then abandon the operation. >>>> Further if this code is being executed by native compiler threads then >>>> exceptions are impossible as they couldn't have executed the Java code >>>> that would post them! So something seems amiss with regards to >>>> exceptions and this code (and what it calls). >>> >>> Right. We should clear the exception and abort the JVMCI thread creation. >> >> Okay. The preexisting: >> >> 946 JavaThread *ct = make_thread(compiler2_object(i), >> _c2_compile_queue, _compilers[1], CHECK); >> >> >> should have a bug filed to have it fixed as well. >> >>> >>>> 929 _compiler2_objects[i] = thread_handle; // Old one dies >>>> here if it exists. >>>> >>>> You need to call JNIHandles::destroy_global on the old handle if it exists. >>> >>> I don't want to release the handle. Just to replace the thread object in the >> handle. >>> Comment updated. >> >> Sorry I don't follow. The initial Handle stored in the array was a >> global handle. You just allocated a second global Handle. I don't see >> any operator=() magic happening here to free one of those global >> handles, so AFAICS you need to free one of them. >> >> Thanks, >> David >> ----- >> >>> >>> New webrev: >>> >> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr >> ev.01/ >>> >>> >>> Best regards, >>> Martin >>> From rwestrel at redhat.com Tue Oct 22 14:32:51 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 22 Oct 2019 16:32:51 +0200 Subject: [14] RFR(S): 8231412: C2: InitializeNode::detect_init_independence() bails out on simple IR shapes In-Reply-To: <281b3352-c1d1-cb4a-0ea7-3b762bff3faa@oracle.com> References: <87h841b0v9.fsf@redhat.com> <281b3352-c1d1-cb4a-0ea7-3b762bff3faa@oracle.com> Message-ID: <87blu8c0ks.fsf@redhat.com> > http://cr.openjdk.java.net/~chagedorn/8231412/webrev.01/ Looks good to me. Roland. From martin.doerr at sap.com Tue Oct 22 14:37:09 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 22 Oct 2019 14:37:09 +0000 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation In-Reply-To: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> Message-ID: Hi Gustavo, backport looks good. The parts you have collected from other changes make sense to me. Best regards, Martin > -----Original Message----- > From: Gustavo Romero > Sent: Freitag, 27. September 2019 05:31 > To: hotspot-compiler-dev at openjdk.java.net; Doerr, Martin > > Cc: jdk8u-dev at openjdk.java.net; Michihiro Horie ; > Kazunori Ogata > Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic > vector CRC implementation > > Hi, > > Could the following backport for jdk8u be reviewed please? > > The original change was mainly written to provide a better implementation > for > CRC32 and CRC32C, but it also improved the CRC32 performance in general. > This > backport is the first change of a patchset comprised of 4 changes aimed to > backport all the latest CRC32 missing parts from JDK 11u. > > It's a PPC64-only change. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8198894 > Original: http://hg.openjdk.java.net/jdk/jdk/rev/7cd503c499a0 > Backport: http://cr.openjdk.java.net/~gromero/crc32_jdk8u/for- > review/8198894/ > > It was necessary to backport it to: > > - Adapt the file names to OpenJDK 8u > - Remove CRC32C part, leaving only CRC32 part, since OpenJDK 8u has no > CRC32C > - Add Assembler::add_const_optimized() from "8077838: Recent > developments for ppc" [0] > - Fix vpermxor() opcode, replacing VPMSUMW_OPCODE by > VPERMXOR_OPCODE, > accordingly to fix in "8190781: ppc64 + s390: Fix CriticalJNINatives" [1] > - Adapt signatures for the following functions and their callers, accordingly to > "8175369: [ppc] Provide intrinsic implementation for CRC32C" [2], also to > ease > subsequent backports in this patchset: > a. MacroAssembler::update_byteLoop_crc32(), removing 'invertCRC' > parameter > b. MacroAssembler::kernel_crc32_1word(), adding 'invertCRC' parameter > > > Thank you. > > Best regards, > Gustavo > > [0] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/88847a1b3718 > [1] http://hg.openjdk.java.net/jdk/jdk/rev/5a69ba3a4fd1#l1.7 > [2] https://bugs.openjdk.java.net/browse/JDK-8175369 From kim.barrett at oracle.com Wed Oct 23 00:24:59 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Tue, 22 Oct 2019 20:24:59 -0400 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> Message-ID: <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> > On Oct 22, 2019, at 9:18 AM, Doerr, Martin wrote: >> Sorry I don't follow. The initial Handle stored in the array was a >> global handle. You just allocated a second global Handle. I don't see >> any operator=() magic happening here to free one of those global >> handles, so AFAICS you need to free one of them. > > Sorry. I had implemented it differently than I wanted. Thanks for pointing me to it. > > Fixed: > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.02/ Please don't do that. That's basically smashing through the JNHHandles abstraction and writing a bunch of (lower level and tightly coupled) code for no good reason. Just use JNIHandles::make_global and JNHHandles::destroy_global as David suggested. (Note that JNIHandles::make_global takes an AllocFailType argument; if you aren't going to handle allocation failure (e.g. are just going to call vm_exit_out_of_memory, as in webrev.02) the default will deal with that for you.) Alternatively, can you use JVMCI::make_global and JVMCI::destroy_global here? Perhaps not, if some of this code is !UseJVMCICompiler or whatever. That's kind of unfortunate. (It's also unfortunate that those functions deal with jobject, but that's a different problem.) From HORIE at jp.ibm.com Wed Oct 23 02:35:22 2019 From: HORIE at jp.ibm.com (Michihiro Horie) Date: Wed, 23 Oct 2019 11:35:22 +0900 Subject: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power In-Reply-To: References: <2de45173-7e10-5dca-4f49-4a09a0852705@oracle.com> <43419c1c-f8c8-cb1c-7248-9dbfbfd7ad41@oracle.com> <002c Message-ID: > Changes in shared code look good! Thank you, Vladimir! I pushed the change. Best regards, Michihiro From: Vladimir Ivanov To: Michihiro Horie Cc: martin.doerr at sap.com, hotspot-compiler-dev at openjdk.java.net, ppc-aix-port-dev at openjdk.java.net Date: 2019/10/22 12:50 Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, rint on Power > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.06_&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=vDe9rjQ-7CI-VsEbMsMNxAVLDjEC4zbim-JlvBsJGpw&s=ILXecCWY40B-nefD7MOtYHzhxcgF4ZHEf-gtEXs2Lo8&e= Changes in shared code look good! Best regards, Vladimir Ivanov > ----- Original message ----- > From: "Doerr, Martin" > To: Vladimir Ivanov , Michihiro Horie > > Cc: hotspot compiler , > "ppc-aix-port-dev at openjdk.java.net" > Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on Power > Date: Mon, Oct 14, 2019 5:27 PM > > Hi Vladimir, > > that looks much better. Thank you. > > Alternatively, the PhaseGVN could get passed instead of the Compile > pointer. (Prototype is already included via node.hpp.) > This is already used by some other nodes like > LoadNode::make(PhaseGVN& gvn, ... > So this seems to be a common pattern. > > Best regards, > Martin > > > > -----Original Message----- > > From: Vladimir Ivanov > > Sent: Samstag, 12. Oktober 2019 03:27 > > To: Doerr, Martin ; Michihiro Horie > > > > Cc: hotspot compiler ; ppc-aix- > > port-dev at openjdk.java.net > > Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on Power > > > > I agree that GraphKit as a ctor argument looks weird. > > > > What about having a static factory and encapsulate the code there > instead? > > > > convertnode.hpp: > > > > RoundDoubleModeNode(Node* in1, ConINode* rmode): Node(0, in1, > > rmode) {} > > > > static RoundDoubleModeNode make(Compile* C, Node* arg, > > RoundDoubleModeNode::RoundingMode rmode); > > > > > > convertnode.cpp: > > > > RoundDoubleModeNode* RoundDoubleModeNode::make(Compile* C, > > Node* arg, > > RoundDoubleModeNode::RoundingMode rmode) { > > ConINode* rm = C->initial_gvn()->intcon(rmode); > > return new RoundDoubleModeNode(arg, rm); > > } > > > > > > library_call.cpp: > > > > case vmIntrinsics::_ceil: n = RoundDoubleModeNode::make(C, arg, > > RoundDoubleModeNode::rmode_ceil); > > > > > > > > > > Best regards, > > Vladimir Ivanov > > > > On 09/10/2019 12:29, Doerr, Martin wrote: > > > Hi Vladimir and Michihiro, > > > > > >> ConINode::make() allocates a new node which has to be seen by GVN, so > > >> there's a type recorded for it. > > > Makes sense. > > > > > > I'd prefer > > > RoundDoubleModeNode(Node *in1, Node *rmode): Node(0, in1, rmode) > > {} > > > > > > and > > > case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); break; > > > case vmIntrinsics::_floor: n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(RoundDoubleModeNode::rmode_floor))); break; > > > case vmIntrinsics::_rint: n = new RoundDoubleModeNode(arg, > > makecon(TypeInt::make(RoundDoubleModeNode::rmode_rint))); break; > > > > > > That avoids additional includes in convertnode.hpp which can easily > lead to > > cyclic dependencies for future changes. > > > > > > Best regards, > > > Martin > > > > > > > > >> -----Original Message----- > > >> From: Vladimir Ivanov > > >> Sent: Dienstag, 8. Oktober 2019 12:31 > > >> To: Doerr, Martin ; Michihiro Horie > > >> > > >> Cc: hotspot compiler ; ppc- > > aix- > > >> port-dev at openjdk.java.net > > >> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, floor, > rint on > > Power > > >> > > >> > > >> > > >> On 08/10/2019 13:14, Doerr, Martin wrote: > > >>> Hi Vladimir and Michihiro, > > >>> > > >>> I like webrev.04 more than webrev.05. > > >>> I think it's not good to include graphKit.hpp in convertnode.hpp. > This > > >> creates a weird dependency. > > >>> What was the reason for this change? > > >> > > >> webrev.04 has a bug. Quote from earlier email: > > >> > > >> "src/hotspot/share/opto/convertnode.hpp: > > >> > > >> + RoundDoubleModeNode(Node *in1, int rmode): Node(0, in1, > > >> ConINode::make(rmode)) {} > > >> > > >> ConINode::make() allocates a new node which has to be seen by GVN, so > > >> there's a type recorded for it. That's why I mentioned GraphKit*. But > > >> you can use PhaseGVN & intcon as well." > > >> > > >> Alternatively, Compile* can be used as well. > > >> > > >> Best regards, > > >> Vladimir Ivanov > > >> > > >>>> -----Original Message----- > > >>>> From: Vladimir Ivanov > > >>>> Sent: Dienstag, 8. Oktober 2019 11:47 > > >>>> To: Michihiro Horie > > >>>> Cc: hotspot compiler ; > > Doerr, > > >>>> Martin ; ppc-aix-port-dev at openjdk.java.net > > >>>> Subject: Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, rint on > > >> Power > > >>>> > > >>>> > > >>>>> _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.05_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=vDe9rjQ-7CI-VsEbMsMNxAVLDjEC4zbim-JlvBsJGpw&s=VCjF-ES12olfcWnw3O0XcmVp46adfC-IUR30m8FSIeI&e= > > >>>> > > >>>> Looks good. > > >>>> > > >>>> (Test results are clean.) > > >>>> > > >>>> Best regards, > > >>>> Vladimir Ivanov > > >>>> > > >>>>> > I think it would be better to use adlc?s include generator > instead of > > >>>>> > including "opto/convertnode.hpp" explicitly in the ad file. > > >>>>> > > > >>>>> > src/hotspot/share/adlc/main.cpp > > >>>>> > > > >>>>> > AD.addInclude(AD._CPP_file, "opto/cfgnode.hpp"); > > >>>>> > > > >>>>> > + AD.addInclude(AD._CPP_file, "opto/convertnode.hpp"); > > >>>>> > > > >>>>> > AD.addInclude(AD._CPP_file, "opto/intrinsicnode.hpp"); > > >>>>> > > > >>>>> > @Vladimir: Do you agree? Would you do it this way, too? > > >>>>> > > >>>>> I prefer current version. > > >>>>> > > >>>>> When proposing the refactoring I thought about the change in > adlc as > > >>>>> well, but when I saw the patch I noticed that putting it in AD file > > >>>>> stresses it's a platform-specific dependency. > > >>>>> > > >>>>> I think that's the right way to look at it until we get a way > to funnel > > >>>>> attributes from ideal nodes to mach nodes and use them during code > > >>>>> emission. > > >>>>> > > >>>>> Best regards, > > >>>>> Vladimir Ivanov > > >>>>> > > >>>>> > *From:*Michihiro Horie > > >>>>> > *Sent:* Montag, 7. Oktober 2019 17:54 > > >>>>> > *To:* Vladimir Ivanov > > >>>>> > *Cc:* hotspot compiler > dev at openjdk.java.net>; > > >>>> Doerr, > > >>>>> > Martin ; ppc-aix-port- > > >> dev at openjdk.java.net > > >>>>> > *Subject:* Re: RFR: 8231649: PPC64: Intrinsics for Math.ceil, > floor, > > >>>>> > rint on Power > > >>>>> > > > >>>>> > Hi Martin, Vladimir, > > >>>>> > Thanks a lot for your further feedback, which makes sense. > > >>>>> > > > >>>>> > New webrev: > > >> _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.04_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=vDe9rjQ-7CI-VsEbMsMNxAVLDjEC4zbim-JlvBsJGpw&s=dnOOoSJhTlBfZup-kcMn04o7UB-NyEGsLmgjMoeznCQ&e= > > >>>>> > > > >>>>> > Best regards, > > >>>>> > Michihiro > > >>>>> > > > >>>>> > Inactive hide details for Vladimir Ivanov ---2019/10/07 > 22:51:21---> > > >>>>> > Fixed webrev is as follows. Thanks, Michihiro.Vladimir Ivanov > > >>>>> > ---2019/10/07 22:51:21---> Fixed webrev is as follows. Thanks, > > >> Michihiro. > > >>>>> > > > >>>>> > From: Vladimir Ivanov > >>>>> > <_mailto:vladimir.x.ivanov at oracle.com_>> > > >>>>> > To: Michihiro Horie > >> <_mailto:HORIE at jp.ibm.com_>>, > > >>>>> > "Doerr, Martin" > >>>> <_mailto:martin.doerr at sap.com_>> > > >>>>> > Cc: hotspot compiler > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>>, > > >>>>> > "ppc-aix-port-dev at openjdk.java.net > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > >>>>> > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > > >>>>> > Date: 2019/10/07 22:51 > > >>>>> > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > > Math.ceil, > > >>>>> > floor, rint on Power > > >>>>> > > > >>>>> > > ------------------------------------------------------------------------ > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> >> Fixed webrev is as follows. > > >>>>> > > > >>>>> > Thanks, Michihiro. > > >>>>> > > > >>>>> >> _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.03_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=vDe9rjQ-7CI-VsEbMsMNxAVLDjEC4zbim-JlvBsJGpw&s=w3iQgfvIiIlgM3VTTh4tGOce57gMMWmxS2ttUaLpkmA&e= > > >>>>> > > > >>>>> > src/hotspot/share/opto/convertnode.hpp: > > >>>>> > > > >>>>> > + enum RoundingMode { rmode_rint, rmode_floor, rmode_ceil}; > > >>>>> > > > >>>>> > Please, explicitly initialize the elements. Numbering is > important > > since > > >>>>> > it is aligned with instruction encoding on x86. > > >>>>> > > > >>>>> > > > >>>>> > src/hotspot/share/opto/library_call.cpp: > > >>>>> > > > >>>>> > + case vmIntrinsics::_ceil: n = new RoundDoubleModeNode(arg, > > >>>>> > makecon(TypeInt::make(RoundDoubleModeNode::rmode_ceil))); > > >>>> break; > > >>>>> > > > >>>>> > Please, change RoundDoubleModeNode to accept the enum > > instead > > >> and > > >>>>> > instantiate the ConI node inside it or introduce a static factory > > >>>>> > (::make(GraphKit*,RoundingMode)) for that purpose. > > >>>>> > > > >>>>> > > > >>>>> > src/hotspot/cpu/ppc/macroAssembler_ppc.hpp: > > >>>>> > > > >>>>> > + void math_round(const FloatRegister t, const FloatRegister > b, int > > >>>>> rmode); > > >>>>> > + void math_round_vec(const VectorSRegister t, const > > >> VectorSRegister > > >>>> b, > > >>>>> > int rmode); > > >>>>> > > > >>>>> > I suggest to get rid of helpers in MacroAssembler and simply move > > >> the > > >>>>> > code into corresponding AD instructions. > > >>>>> > > > >>>>> > Best regards, > > >>>>> > Vladimir Ivanov > > >>>>> > > > >>>>> >> Inactive hide details for "Doerr, Martin" ---2019/10/07 > 22:09:15--- > > > I > > >>>>> >> suggest to put the enum in RoundDoubleModeNode > > >> (convertn"Doerr, > > >>>> Martin" > > >>>>> >> ---2019/10/07 22:09:15---> I suggest to put the enum in > > >>>>> >> RoundDoubleModeNode (convertnode.hpp) > and lift instruction > > >>>> selectio > > >>>>> >> > > >>>>> >> From: "Doerr, Martin" > >>>>> <_mailto:martin.doerr at sap.com_>> > > >>>>> >> To: Vladimir Ivanov > >>>>> <_mailto:vladimir.x.ivanov at oracle.com_>>, > > >>>>> > Michihiro Horie > > >>>>> >> > > > >>>>> >> Cc: hotspot compiler > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>>, > > >>>>> >> "ppc-aix-port-dev at openjdk.java.net > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>" > > >>>>> > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>> > > >>>>> >> Date: 2019/10/07 22:09 > > >>>>> >> Subject: [EXTERNAL] RE: RFR: 8231649: PPC64: Intrinsics for > > >> Math.ceil, > > >>>>> >> floor, rint on Power > > >>>>> >> > > >>>>> >> > ------------------------------------------------------------------------ > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > > >>>> (convertnode.hpp) > > >>>>> >> > and lift instruction selection logic from > > macroAssembler_ppc.cpp > > >>>>> into > > >>>>> >> ppc.ad. > > >>>>> >> That sounds good. > > >>>>> >> > > >>>>> >> Thanks, > > >>>>> >> Martin > > >>>>> >> > > >>>>> >> > > >>>>> >> > -----Original Message----- > > >>>>> >> > From: Vladimir Ivanov > >>>>> <_mailto:vladimir.x.ivanov at oracle.com_>> > > >>>>> >> > Sent: Montag, 7. Oktober 2019 12:55 > > >>>>> >> > To: Doerr, Martin > >>>>> <_mailto:martin.doerr at sap.com_>>; Michihiro Horie > > >>>>> >> > > > > >>>>> >> > Cc: hotspot compiler > dev at openjdk.java.net > > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>>; ppc-aix- > > >>>>> >> > port-dev at openjdk.java.net <_mailto:port-_ > > >> dev at openjdk.java.net> > > >>>>> >> > Subject: Re: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, floor, > > >>>>> >> rint on Power > > >>>>> >> > > > >>>>> >> > > I think sharedRuntime is not a good place for the C2 enum. > > >>>>> >> > Agree. > > >>>>> >> > > > >>>>> >> > I suggest to put the enum in RoundDoubleModeNode > > >>>> (convertnode.hpp) > > >>>>> >> > and > > >>>>> >> > lift instruction selection logic from macroAssembler_ppc.cpp > > into > > >>>>> ppc.ad. > > >>>>> >> > > > >>>>> >> > Best regards, > > >>>>> >> > Vladimir Ivanov > > >>>>> >> > > > >>>>> >> > > > > >>>>> >> > > Maybe intrinsicnode.hpp would be a better pace for it. But > > >>>>> then, the > > >>>>> >> > > code in macroAssembler should be guarded by #ifdef > > >> COMPILER2. > > >>>>> >> > > > > >>>>> >> > > Best regards, > > >>>>> >> > > > > >>>>> >> > > Martin > > >>>>> >> > > > > >>>>> >> > > *From:*Michihiro Horie > >>>> <_mailto:HORIE at jp.ibm.com_>> > > >>>>> >> > > *Sent:* Montag, 7. Oktober 2019 09:14 > > >>>>> >> > > *To:* Vladimir Ivanov > >>>>> <_mailto:vladimir.x.ivanov at oracle.com_>> > > >>>>> >> > > *Cc:* hotspot compiler > >> dev at openjdk.java.net > > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>>; > > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > > >>>>> > <_mailto:ppc-aix-port-dev at openjdk.java.net_>; Doerr, Martin > > >>>>> >> > > > > >>>>> >> > > *Subject:* RE: RFR: 8231649: PPC64: Intrinsics for > Math.ceil, > > >>>>> floor, > > >>>>> >> > > rint on Power > > >>>>> >> > > > > >>>>> >> > > Hi Vladimir, > > >>>>> >> > > > > >>>>> >> > > Thanks a lot for your nice suggestion. Yes, I prefer > enum use. > > >>>>> >> > > I'm wondering if the enum constants can be declared in > > >>>>> >> > sharedRuntime.hpp. > > >>>>> >> > > Webrev: > > >> _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.02_-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=vDe9rjQ-7CI-VsEbMsMNxAVLDjEC4zbim-JlvBsJGpw&s=h0WZZoPEjP6yHQioeIVgUeAx9HJVGBnH4sjKlaxQAR8&e= > > >>>>> >> > > > > >>>>> >> > > Best regards, > > >>>>> >> > > Michihiro > > >>>>> >> > > > > >>>>> >> > > Inactive hide details for Vladimir Ivanov ---2019/10/04 > > >>>>> 23:05:48---Hi > > >>>>> >> > > Michihiro, > > >> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp:Vladimir > > >>>>> Ivanov > > >>>>> >> > > ---2019/10/04 23:05:48---Hi Michihiro, > > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > >>>>> >> > > > > >>>>> >> > > From: Vladimir Ivanov > >>>>> > <_mailto:vladimir.x.ivanov at oracle.com%0b_>> > > > > >>>>> > <_mailto:vladimir.x.ivanov at oracle.com_>> > > >>>>> >> > > To: Michihiro Horie > >>>> <_mailto:HORIE at jp.ibm.com_>>, > > >>>>> >> > > ppc-aix-port-dev at openjdk.java.net > > >>>>> <_mailto:ppc-aix-port-dev at openjdk.java.net_> > > >>>>> >> > > <_mailto:ppc-aix-port-dev at openjdk.java.net_>, hotspot > > compiler > > >>>>> >> > > > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net%0b_>> > > > > >>>>> > <_mailto:hotspot-compiler-dev at openjdk.java.net_>> > > >>>>> >> > > Date: 2019/10/04 23:05 > > >>>>> >> > > Subject: [EXTERNAL] Re: RFR: 8231649: PPC64: Intrinsics for > > >>>>> Math.ceil, > > >>>>> >> > > floor, rint on Power > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > ------------------------------------------------------------------------ > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > Hi Michihiro, > > >>>>> >> > > > > >>>>> >> > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp: > > >>>>> >> > > + switch (rmode) { > > >>>>> >> > > + case 0: // rint > > >>>>> >> > > + frin(t, b); > > >>>>> >> > > + break; > > >>>>> >> > > + case 1: // floor > > >>>>> >> > > + frim(t, b); > > >>>>> >> > > + break; > > >>>>> >> > > + case 2: // ceil > > >>>>> >> > > + frip(t, b); > > >>>>> >> > > + break; > > >>>>> >> > > + default: > > >>>>> >> > > + ShouldNotReachHere(); > > >>>>> >> > > + } > > >>>>> >> > > > > >>>>> >> > > What do you think about introducing enum constants instead > > of > > >>>> using > > >>>>> >> > > hard-coded 0/1/2? > > >>>>> >> > > > > >>>>> >> > > src/hotspot/share/opto/library_call.cpp: > > >>>>> >> > > > > >>>>> >> > > case vmIntrinsics::_ceil: n = new > > >> RoundDoubleModeNode(arg, > > >>>>> >> > > makecon(TypeInt::make(2))); break; > > >>>>> >> > > case vmIntrinsics::_floor: n = new > > >> RoundDoubleModeNode(arg, > > >>>>> >> > > makecon(TypeInt::make(1))); break; > > >>>>> >> > > case vmIntrinsics::_rint: n = new > > >> RoundDoubleModeNode(arg, > > >>>>> >> > > makecon(TypeInt::make(0))); break; > > >>>>> >> > > > > >>>>> >> > > The downside is you have to move the switch from > > >>>> macroAssembler > > >>>>> >> > because > > >>>>> >> > > enum should be visible from both places. (Is there a better > > >>>>> place for > > >>>>> >> > > that than roundD_regNode::emit() in AD file?) > > >>>>> >> > > > > >>>>> >> > > Best regards, > > >>>>> >> > > Vladimir Ivanov > > >>>>> >> > > > > >>>>> >> > > On 02/10/2019 07:27, Michihiro Horie wrote: > > >>>>> >> > >> > > >>>>> >> > >> Dear all, > > >>>>> >> > >> > > >>>>> >> > >> Would you please review the following change? > > >>>>> >> > >> Bug: _ https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8231649-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=vDe9rjQ-7CI-VsEbMsMNxAVLDjEC4zbim-JlvBsJGpw&s=9flvqTEzq7bKbVi2-4iifkIh09Yq_3bEBvmVGV7-JA0&e= > > >>>>> >> > >> Webrev: > > >> _ https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8231649_webrev.00-5F&d=DwIDaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=vDe9rjQ-7CI-VsEbMsMNxAVLDjEC4zbim-JlvBsJGpw&s=vauA4cQ7zW8AVBRXst0kGvFc8jQQ5__J4QoZo5Qt8eY&e= > > >>>>> >> > >> > > >>>>> >> > >> This change adds intrinsics for Math's ceil, floor, and > rint for > > >>>>> >> PPC64, on > > >>>>> >> > >> top of 8226721: Missing intrinsics for Math.ceil, > floor, rint. > > >>>>> >> > >> > > >>>>> >> > >> Best regards, > > >>>>> >> > >> Michihiro > > >>>>> >> > >> > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> >> > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > From tobias.hartmann at oracle.com Wed Oct 23 07:58:06 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Oct 2019 09:58:06 +0200 Subject: [14] RFR(S): 8231412: C2: InitializeNode::detect_init_independence() bails out on simple IR shapes In-Reply-To: <87blu8c0ks.fsf@redhat.com> References: <87h841b0v9.fsf@redhat.com> <281b3352-c1d1-cb4a-0ea7-3b762bff3faa@oracle.com> <87blu8c0ks.fsf@redhat.com> Message-ID: <65e57a7d-4ce7-9ef1-cf0e-d95578aa5474@oracle.com> +1 Best regards, Tobias On 22.10.19 16:32, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~chagedorn/8231412/webrev.01/ > > Looks good to me. > > Roland. > From christian.hagedorn at oracle.com Wed Oct 23 08:20:32 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 23 Oct 2019 10:20:32 +0200 Subject: [14] RFR(S): 8231412: C2: InitializeNode::detect_init_independence() bails out on simple IR shapes In-Reply-To: <65e57a7d-4ce7-9ef1-cf0e-d95578aa5474@oracle.com> References: <87h841b0v9.fsf@redhat.com> <281b3352-c1d1-cb4a-0ea7-3b762bff3faa@oracle.com> <87blu8c0ks.fsf@redhat.com> <65e57a7d-4ce7-9ef1-cf0e-d95578aa5474@oracle.com> Message-ID: Thank you Roland and Tobias for reviewing it again! Best regards, Christian On 23.10.19 09:58, Tobias Hartmann wrote: > +1 > > Best regards, > Tobias > > On 22.10.19 16:32, Roland Westrelin wrote: >> >>> http://cr.openjdk.java.net/~chagedorn/8231412/webrev.01/ >> >> Looks good to me. >> >> Roland. >> From rwestrel at redhat.com Wed Oct 23 08:50:15 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 23 Oct 2019 10:50:15 +0200 Subject: RFR(S): 8232539: SIGSEGV in C2 Node::unique_ctrl_out Message-ID: <878spbc0c8.fsf@redhat.com> http://cr.openjdk.java.net/~roland/8232539/webrev.00/ I couldn't come up with a test case because node processing order during IGVN matters. Bug was reported against 11 but I see no reason it wouldn't apply to current code as well. At parse time, predicates are added by Parse::maybe_add_predicate_after_if() but not loop is actually created. Compile::_major_progress is cleared. On the next round of IGVN, one input of a region points to predicates. The same region has an if as use that can be split through phi during IGVN. The predicates are going to be removed by IGVN. But that happens in multiple steps because there are several predicates (for reason Deoptimization::Reason_predicate, Deoptimization::Reason_loop_limit_check etc.) and because for each predicate one IGVN iteration must first remove the Opaque1 node, then another kill the IfFalse projection, finally another replace the IfTrue projection by the If control input. Split if occurs while predicates are in the process of being removed. It sees predicates, tries to walk over them, encounters a predicates that's been half removed (false projection removed) and we hit the assert/crash. I propose we simply not apply IGVN split if if we're splitting through a loop or if there's a predicate input to a region because: - Making split if robust to dying predicates is not straightforward as far as I can tell - Loop opts split if doesn't split through loop header so why would it make sense for IGVN split if? - I'm wondering if there are other cases where handling of predicates in split if could be wrong (and so more trouble ahead): + What if we split through a Loop region, predicates were added by loop optimizations, loop opts are now over so the predicates added at parse time were removed: then PhaseIdealLoop::find_predicate() wouldn't report a predicate but cloning predicates would still be required for correctness? + What if we have no loop, a region has predicates as input, predicates are going to die but have not yet been processed, split if uselessly duplicates predicates but one of then is control dependent on the branch it is in so cloning predicates actually causes a broken graph? So overall it feels safer to me to simply bail out from split if for loops/predicates. Roland. From christian.hagedorn at oracle.com Wed Oct 23 09:59:28 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 23 Oct 2019 11:59:28 +0200 Subject: [14] RFR(XS): 8232873/8232874: Add missing tests for 8220416 and 8230062 Message-ID: Hi Please review the following patches which add some missing tests for the linked bugs which were part of the original webrevs but were eventually forgotten to push: 8220416 [1]: http://cr.openjdk.java.net/~chagedorn/8232873/webrev.00/ 8230062 [2]: http://cr.openjdk.java.net/~chagedorn/8232874/webrev.00/ Thank you! Best regards, Christian [1] http://cr.openjdk.java.net/~chagedorn/8220416/webrev.00/ [2] http://cr.openjdk.java.net/~chagedorn/8230062/webrev.00/ From christoph.goettschkes at microdoc.com Wed Oct 23 09:59:37 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Wed, 23 Oct 2019 11:59:37 +0200 Subject: RFR: 8231952: ARM32: Wrong assumption in assertion in LIRGenerator::atomic_xchg and LIRGenerator::atomic_add In-Reply-To: <20191015073404.538703190EE@aojmv0009> References: <20191010143214.24A3B319F24@aojmv0009> <20191015073404.538703190EE@aojmv0009> Message-ID: Hi Boris, since no one else responded to the RFR, is the review of Dean enough for you to push the changeset into the repository? If so, could you please do it for me? If not, how should we proceed? Thanks, Christoph "hotspot-compiler-dev" wrote on 2019-10-15 09:32:00: > From: christoph.goettschkes at microdoc.com > To: hotspot-compiler-dev at openjdk.java.net > Date: 2019-10-15 09:34 > Subject: Re: RFR: 8231952: ARM32: Wrong assumption in assertion in > LIRGenerator::atomic_xchg and LIRGenerator::atomic_add > Sent by: "hotspot-compiler-dev" > > Thanks for your feedback Dean. > > Does some else have any feedback or can I ask Boris to push the changeset > into the repository? > > -- Christoph > > "hotspot-compiler-dev" > wrote on 2019-10-11 02:05:44: > > > From: dean.long at oracle.com > > To: hotspot-compiler-dev at openjdk.java.net > > Date: 2019-10-11 02:07 > > Subject: Re: RFR: 8231952: ARM32: Wrong assumption in assertion in > > LIRGenerator::atomic_xchg and LIRGenerator::atomic_add > > Sent by: "hotspot-compiler-dev" > > > > > Looks good to me. > > > > dl > > > > On 10/10/19 7:28 AM, christoph.goettschkes at microdoc.com wrote: > > > Hi, > > > > > > please review the following changeset. This patch fixes a wrong > assumption > > > in an assertion of the C1 LIR generator for 32-bit ARM. The assertion > > > assumed that atomic operations are only possible for int types on > 32-bit > > > arm. This is not true, since the LDREXD/STREXB instructions are use by > the > > > C1 JIT. > > > > > > This fixes the 3 hotspot tier1 tests mentioned in the issue. > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231952 > > > Webrev: https://cr.openjdk.java.net/~bulasevich/8231952/webrev.00/ > > > > > > Thanks, > > > Christoph > > > > > > From tobias.hartmann at oracle.com Wed Oct 23 10:02:26 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Oct 2019 12:02:26 +0200 Subject: [14] RFR(XS): 8232873/8232874: Add missing tests for 8220416 and 8230062 In-Reply-To: References: Message-ID: Hi Christian, looks good. For the record: I'll push this directly because the tests have already been reviewed with the original changes. Best regards, Tobias On 23.10.19 11:59, Christian Hagedorn wrote: > Hi > > Please review the following patches which add some missing tests for the linked bugs which were part > of the original webrevs but were eventually forgotten to push: > 8220416 [1]: http://cr.openjdk.java.net/~chagedorn/8232873/webrev.00/ > 8230062 [2]: http://cr.openjdk.java.net/~chagedorn/8232874/webrev.00/ > > Thank you! > > Best regards, > Christian > > > [1] http://cr.openjdk.java.net/~chagedorn/8220416/webrev.00/ > [2] http://cr.openjdk.java.net/~chagedorn/8230062/webrev.00/ From christian.hagedorn at oracle.com Wed Oct 23 10:04:47 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 23 Oct 2019 12:04:47 +0200 Subject: [14] RFR(XS): 8232873/8232874: Add missing tests for 8220416 and 8230062 In-Reply-To: References: Message-ID: <78f2d0c9-b95b-7822-74e4-5732e58c5038@oracle.com> Hi Tobias That's good, thank you! Best regards, Christian On 23.10.19 12:02, Tobias Hartmann wrote: > Hi Christian, > > looks good. > > For the record: I'll push this directly because the tests have already been reviewed with the > original changes. > > Best regards, > Tobias > > On 23.10.19 11:59, Christian Hagedorn wrote: >> Hi >> >> Please review the following patches which add some missing tests for the linked bugs which were part >> of the original webrevs but were eventually forgotten to push: >> 8220416 [1]: http://cr.openjdk.java.net/~chagedorn/8232873/webrev.00/ >> 8230062 [2]: http://cr.openjdk.java.net/~chagedorn/8232874/webrev.00/ >> >> Thank you! >> >> Best regards, >> Christian >> >> >> [1] http://cr.openjdk.java.net/~chagedorn/8220416/webrev.00/ >> [2] http://cr.openjdk.java.net/~chagedorn/8230062/webrev.00/ From shade at redhat.com Wed Oct 23 10:06:10 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Oct 2019 12:06:10 +0200 Subject: RFR: 8231952: ARM32: Wrong assumption in assertion in LIRGenerator::atomic_xchg and LIRGenerator::atomic_add In-Reply-To: <20191010143214.24A3B319F24@aojmv0009> References: <20191010143214.24A3B319F24@aojmv0009> Message-ID: On 10/10/19 4:28 PM, christoph.goettschkes at microdoc.com wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8231952 > Webrev: https://cr.openjdk.java.net/~bulasevich/8231952/webrev.00/ Looks good to me. You need a sponsor for this? Is Boris sponsoring? -- Thanks, -Aleksey From christoph.goettschkes at microdoc.com Wed Oct 23 10:17:24 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Wed, 23 Oct 2019 12:17:24 +0200 Subject: RFR: 8231952: ARM32: Wrong assumption in assertion in LIRGenerator::atomic_xchg and LIRGenerator::atomic_add In-Reply-To: References: <20191010143214.24A3B319F24@aojmv0009> Message-ID: Hi Aleksey, > Looks good to me. > > You need a sponsor for this? Is Boris sponsoring? thanks for your review. I am fairly new to the process of pushing changes into the OpenJDK. By sponsor you mean someone who can push the changeset into the repository? For my previous changes, Boris was so kind and did that for me. I would ask him again if he could so, but if its possible for you as well, I am fine with that too. Boris created the issues in the JBS for me though. Thanks, Christoph From shade at redhat.com Wed Oct 23 10:24:05 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Oct 2019 12:24:05 +0200 Subject: RFR: 8231952: ARM32: Wrong assumption in assertion in LIRGenerator::atomic_xchg and LIRGenerator::atomic_add In-Reply-To: <5db0291a.1c69fb81.19596.4822SMTPIN_ADDED_MISSING@mx.google.com> References: <20191010143214.24A3B319F24@aojmv0009> <5db0291a.1c69fb81.19596.4822SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <2e79509d-c639-8afc-f352-fde3d4ce6723@redhat.com> On 10/23/19 12:17 PM, christoph.goettschkes at microdoc.com wrote: > thanks for your review. I am fairly new to the process of pushing changes > into the OpenJDK. By sponsor you mean someone who can push the changeset > into the repository? Yes. > For my previous changes, Boris was so kind and did > that for me. I would ask him again if he could so, but if its possible for > you as well, I am fine with that too. Boris created the issues in the JBS > for me though. Let's wait if Boris wants to push. He already did work here, so it is better to let him be recorded as the sponsor. If this does not succeed, I can sponsor myself. -- Thanks, -Aleksey From tobias.hartmann at oracle.com Wed Oct 23 11:47:11 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Oct 2019 13:47:11 +0200 Subject: [14] RFR(T): 8232883: compiler/c2/CmpPNodeSubTest.java fails because test class name is wrong Message-ID: Hi, please review the following trivial patch that fixes an inconsistency between test class name and file name by simply renaming the file: https://bugs.openjdk.java.net/browse/JDK-8232883 http://cr.openjdk.java.net/~thartmann/8232883/webrev.00/ Thanks, Tobias From shade at redhat.com Wed Oct 23 11:51:38 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Oct 2019 13:51:38 +0200 Subject: [14] RFR(T): 8232883: compiler/c2/CmpPNodeSubTest.java fails because test class name is wrong In-Reply-To: References: Message-ID: On 10/23/19 1:47 PM, Tobias Hartmann wrote: > https://bugs.openjdk.java.net/browse/JDK-8232883 > http://cr.openjdk.java.net/~thartmann/8232883/webrev.00/ Looks good and trivial. -- Thanks, -Aleksey From shade at redhat.com Wed Oct 23 11:52:25 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Oct 2019 13:52:25 +0200 Subject: RFR (XS) 8232882: GCC 4.8.5 build failure after JDK-8211073 Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8232882 See the bug. There is an awkwardness in MemNode::calculate_adr_type that is exposed by recent build config change that produces warning in release config. The simplest way out I see is to avoid the dead store under PRODUCT. I believe cross_check is only ever used under ASSERT in that method. Fix: https://cr.openjdk.java.net/~shade/8232882/webrev.01/ Testing: gcc 4.8.5, 7.4.0 builds, both fastdebug and release; jdk-submit (running) -- Thanks, -Aleksey From tobias.hartmann at oracle.com Wed Oct 23 11:52:52 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Oct 2019 13:52:52 +0200 Subject: [14] RFR(T): 8232883: compiler/c2/CmpPNodeSubTest.java fails because test class name is wrong In-Reply-To: References: Message-ID: Thanks Roland! Pushed. Best regards, Tobias On 23.10.19 13:51, Aleksey Shipilev wrote: > On 10/23/19 1:47 PM, Tobias Hartmann wrote: >> https://bugs.openjdk.java.net/browse/JDK-8232883 >> http://cr.openjdk.java.net/~thartmann/8232883/webrev.00/ > > Looks good and trivial. > From rwestrel at redhat.com Wed Oct 23 11:53:42 2019 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 23 Oct 2019 13:53:42 +0200 Subject: [14] RFR(T): 8232883: compiler/c2/CmpPNodeSubTest.java fails because test class name is wrong In-Reply-To: References: Message-ID: <874kzzbruh.fsf@redhat.com> > http://cr.openjdk.java.net/~thartmann/8232883/webrev.00/ Looks good. Roland. From tobias.hartmann at oracle.com Wed Oct 23 11:57:33 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Oct 2019 13:57:33 +0200 Subject: [14] RFR(T): 8232883: compiler/c2/CmpPNodeSubTest.java fails because test class name is wrong In-Reply-To: <874kzzbruh.fsf@redhat.com> References: <874kzzbruh.fsf@redhat.com> Message-ID: Thanks Roland! Best regards, Tobias On 23.10.19 13:53, Roland Westrelin wrote: > >> http://cr.openjdk.java.net/~thartmann/8232883/webrev.00/ > > Looks good. > > Roland. > From tobias.hartmann at oracle.com Wed Oct 23 11:58:24 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Oct 2019 13:58:24 +0200 Subject: [14] RFR(T): 8232883: compiler/c2/CmpPNodeSubTest.java fails because test class name is wrong In-Reply-To: References: Message-ID: <11c9e211-884d-3f09-5d02-1b8a8a427ab2@oracle.com> On 23.10.19 13:52, Tobias Hartmann wrote: > Thanks Roland! Pushed. Sorry Aleksey, got confused here with the names :) Thanks again for the quick review. Best regards, Tobias From tobias.hartmann at oracle.com Wed Oct 23 12:03:35 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Oct 2019 14:03:35 +0200 Subject: RFR (XS) 8232882: GCC 4.8.5 build failure after JDK-8211073 In-Reply-To: References: Message-ID: <04e04f34-bffa-6225-7268-4d0cc1fba273@oracle.com> Hi Aleksey, looks good to me. Best regards, Tobias On 23.10.19 13:52, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8232882 > > See the bug. There is an awkwardness in MemNode::calculate_adr_type that is exposed by recent build > config change that produces warning in release config. The simplest way out I see is to avoid the > dead store under PRODUCT. I believe cross_check is only ever used under ASSERT in that method. > > Fix: > https://cr.openjdk.java.net/~shade/8232882/webrev.01/ > > Testing: gcc 4.8.5, 7.4.0 builds, both fastdebug and release; jdk-submit (running) > From christian.hagedorn at oracle.com Wed Oct 23 12:05:44 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 23 Oct 2019 14:05:44 +0200 Subject: [14] RFR(T): 8232883: compiler/c2/CmpPNodeSubTest.java fails because test class name is wrong In-Reply-To: <11c9e211-884d-3f09-5d02-1b8a8a427ab2@oracle.com> References: <11c9e211-884d-3f09-5d02-1b8a8a427ab2@oracle.com> Message-ID: <1de64135-a345-6ab0-658f-566b62352d94@oracle.com> Sorry for the trouble and thank you for fixing this! Dunno how I did not notice that back then when I created the webrev a month ago for 8220416 and yet again in 8232873. Best regards, Christian On 23.10.19 13:58, Tobias Hartmann wrote: > > On 23.10.19 13:52, Tobias Hartmann wrote: >> Thanks Roland! Pushed. > > Sorry Aleksey, got confused here with the names :) > > Thanks again for the quick review. > > Best regards, > Tobias > From shade at redhat.com Wed Oct 23 13:12:08 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Oct 2019 15:12:08 +0200 Subject: RFR (XS) 8232882: GCC 4.8.5 build failure after JDK-8211073 In-Reply-To: References: Message-ID: <28d17b47-0848-82b1-a8fe-057055571e19@redhat.com> On 10/23/19 1:52 PM, Aleksey Shipilev wrote: > Bug: > https://bugs.openjdk.java.net/browse/JDK-8232882 > > See the bug. There is an awkwardness in MemNode::calculate_adr_type that is exposed by recent build > config change that produces warning in release config. The simplest way out I see is to avoid the > dead store under PRODUCT. I believe cross_check is only ever used under ASSERT in that method. > > Fix: > https://cr.openjdk.java.net/~shade/8232882/webrev.01/ > > Testing: gcc 4.8.5, 7.4.0 builds, both fastdebug and release; jdk-submit (running) jdk-submit came clean (apart from known compiler/c2/CmpPNodeSubTest.java failures). Tobias had reviewed. Can we consider this one simple/trivial for immediate push? This would help to unbreak some of our CIs. -- Thanks, -Aleksey From boris.ulasevich at bell-sw.com Wed Oct 23 13:43:29 2019 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 23 Oct 2019 16:43:29 +0300 Subject: RFR: 8231952: ARM32: Wrong assumption in assertion in LIRGenerator::atomic_xchg and LIRGenerator::atomic_add In-Reply-To: <20191023130113.1DcqwQtr@mxfront5q.mail.yandex.net> References: <20191010143214.24A3B319F24@aojmv0009> <20191015073404.538703190EE@aojmv0009> <20191023130113.1DcqwQtr@mxfront5q.mail.yandex.net> Message-ID: <915d61a5-9f96-9430-8ae9-60f3155b77cd@bell-sw.com> Hi Christoph, You've got a review! I will push the change for you. Thank you for your job! regards, Boris On 23.10.2019 12:59, christoph.goettschkes at microdoc.com wrote: > Hi Boris, > > since no one else responded to the RFR, is the review of Dean enough for > you to push the changeset into the repository? > If so, could you please do it for me? > If not, how should we proceed? > > Thanks, Christoph > > "hotspot-compiler-dev" > wrote on 2019-10-15 09:32:00: > >> From: christoph.goettschkes at microdoc.com >> To: hotspot-compiler-dev at openjdk.java.net >> Date: 2019-10-15 09:34 >> Subject: Re: RFR: 8231952: ARM32: Wrong assumption in assertion in >> LIRGenerator::atomic_xchg and LIRGenerator::atomic_add >> Sent by: "hotspot-compiler-dev" > >> >> Thanks for your feedback Dean. >> >> Does some else have any feedback or can I ask Boris to push the > changeset >> into the repository? >> >> -- Christoph >> >> "hotspot-compiler-dev" >> wrote on 2019-10-11 02:05:44: >> >>> From: dean.long at oracle.com >>> To: hotspot-compiler-dev at openjdk.java.net >>> Date: 2019-10-11 02:07 >>> Subject: Re: RFR: 8231952: ARM32: Wrong assumption in assertion in >>> LIRGenerator::atomic_xchg and LIRGenerator::atomic_add >>> Sent by: "hotspot-compiler-dev" >> >>> >>> Looks good to me. >>> >>> dl >>> >>> On 10/10/19 7:28 AM, christoph.goettschkes at microdoc.com wrote: >>>> Hi, >>>> >>>> please review the following changeset. This patch fixes a wrong >> assumption >>>> in an assertion of the C1 LIR generator for 32-bit ARM. The > assertion >>>> assumed that atomic operations are only possible for int types on >> 32-bit >>>> arm. This is not true, since the LDREXD/STREXB instructions are use > by >> the >>>> C1 JIT. >>>> >>>> This fixes the 3 hotspot tier1 tests mentioned in the issue. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231952 >>>> Webrev: https://cr.openjdk.java.net/~bulasevich/8231952/webrev.00/ >>>> >>>> Thanks, >>>> Christoph >>>> >>> >> > From tobias.hartmann at oracle.com Wed Oct 23 13:46:29 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 23 Oct 2019 15:46:29 +0200 Subject: RFR (XS) 8232882: GCC 4.8.5 build failure after JDK-8211073 In-Reply-To: <28d17b47-0848-82b1-a8fe-057055571e19@redhat.com> References: <28d17b47-0848-82b1-a8fe-057055571e19@redhat.com> Message-ID: On 23.10.19 15:12, Aleksey Shipilev wrote: > Can we consider this one simple/trivial for immediate push? This would help to unbreak > some of our CIs. Looks trivial to me. Best regards, Tobias From rkennke at redhat.com Wed Oct 23 14:29:29 2019 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 23 Oct 2019 16:29:29 +0200 Subject: [11u] RFR: 8231085: C2/GC: Better GC-interface for expanding clone Message-ID: <582a0140-7b8e-cdd6-d0d3-d58c0964ccb0@redhat.com> I would like to backport the recent GC interface for expanding clones to jdk11u. This is a prerequisite to backport related Shenandoah changes to 11u without making a mess. The change differs from the original jdk14 change because it basically skips the intermediate GC interface for the same thing that's been introduced in jdk12. This one wholly replaces that. Bug: https://bugs.openjdk.java.net/browse/JDK-8231085 Original webrev: http://cr.openjdk.java.net/~rkennke/JDK-8231085/webrev.00/ JDK11u webrev: http://cr.openjdk.java.net/~rkennke/JDK-8231085/webrev.00.jdk11u/ Testing: tier1 and tier2 no regressions Good? Roman From martin.doerr at sap.com Wed Oct 23 14:47:54 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 23 Oct 2019 14:47:54 +0000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> Message-ID: Hi Kim, I didn't like using the OopStorage stuff directly, either. I just have not seen how to allocate a global handle and add the oop later. Thanks for pointing me to JVMCI::make_global. I was not aware of that. So I can imagine 3 ways to implement it: 1. Use JNIHandles::destroy_global to release the handles. I just added that to http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.01/ We may want to improve that further by setting the handle pointer to NULL and asserting that it is NULL before adding the new one. I had been concerned about NULLs in the array, but looks like the existing code can deal with that. 2. Use JVMCI::make_global, keep the handles and replace the j.t.Thread objects. Changed in place: http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.02/ JMVCI::make_global uses OopStorageSet::vm_global instead of jni_global. No clue if this is better or worse. But seems like JMVCI::make_global still doesn't like NULL handles in slowdebug build ?? assert(oopDesc::is_oop(obj()), "not an oop"); 3. Just use the possibly_add_compiler_threads part of webrev.02 and leave the initialization as is. This means we create j.l.Thread objects initially and replace them by new ones when the JVMCI threads get started. I'd be ok with this, too. Sorry for the in-place updates, but so many webrevs would confuse me after some time. Best regards, Martin > -----Original Message----- > From: Kim Barrett > Sent: Mittwoch, 23. Oktober 2019 02:25 > To: Doerr, Martin > Cc: David Holmes ; Vladimir Kozlov > (vladimir.kozlov at oracle.com) ; hotspot- > compiler-dev at openjdk.java.net > Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread > > > On Oct 22, 2019, at 9:18 AM, Doerr, Martin > wrote: > >> Sorry I don't follow. The initial Handle stored in the array was a > >> global handle. You just allocated a second global Handle. I don't see > >> any operator=() magic happening here to free one of those global > >> handles, so AFAICS you need to free one of them. > > > > Sorry. I had implemented it differently than I wanted. Thanks for pointing > me to it. > > > > Fixed: > > > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr > ev.02/ > > Please don't do that. That's basically smashing through the JNHHandles > abstraction and writing a bunch of (lower level and tightly coupled) > code for no good reason. Just use JNIHandles::make_global and > JNHHandles::destroy_global as David suggested. > > (Note that JNIHandles::make_global takes an AllocFailType argument; if > you aren't going to handle allocation failure (e.g. are just going to > call vm_exit_out_of_memory, as in webrev.02) the default will deal > with that for you.) > > Alternatively, can you use JVMCI::make_global and JVMCI::destroy_global > here? Perhaps not, if some of this code is !UseJVMCICompiler or whatever. > That's kind of unfortunate. (It's also unfortunate that those functions > deal with jobject, but that's a different problem.) > From bob.vandette at oracle.com Wed Oct 23 15:13:04 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Wed, 23 Oct 2019 11:13:04 -0400 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode Message-ID: Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, and alter a collection of JVM options to be product flags rather than experimental flags. EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 Bob. From shade at redhat.com Wed Oct 23 15:36:34 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 23 Oct 2019 17:36:34 +0200 Subject: RFR (XS) 8232882: GCC 4.8.5 build failure after JDK-8211073 In-Reply-To: References: <28d17b47-0848-82b1-a8fe-057055571e19@redhat.com> Message-ID: <80b17dd7-be3b-140b-8f47-543f4e4c33ac@redhat.com> On 10/23/19 3:46 PM, Tobias Hartmann wrote: > > On 23.10.19 15:12, Aleksey Shipilev wrote: >> Can we consider this one simple/trivial for immediate push? This would help to unbreak >> some of our CIs. > > Looks trivial to me. Thanks, pushed. -- -Aleksey From ekaterina.pavlova at oracle.com Wed Oct 23 19:13:08 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 23 Oct 2019 12:13:08 -0700 Subject: RFR(T/XS) 8166275: vm/mlvm/meth/stress/compiler/deoptimize keeps timeouting Message-ID: Hi, The number of threads the test is launching by default is equal to (see vm/mlvm/share/MultiThreadedTest.java) threadsPerCpu * Runtime.getRuntime().availableProcessors() + threadsExtra This is too much stress in case the build is debug one. For example on linux with 24 cores the test takes less than half of minute in case of product build and more than 20 mins in case of fastdebug build. The fix is quite trivial. It splits the test in two tests - one for product configuration and one for debug one. The number of threads per cpu/core is reduced from 4 to 2 in case of debug build. JBS: https://bugs.openjdk.java.net/browse/JDK-8166275 webrev: http://cr.openjdk.java.net/~epavlova//8166275/webrev.00/index.html testing: run the test on all platforms with debug and product bits thanks, -katya From vladimir.kozlov at oracle.com Wed Oct 23 19:21:38 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 23 Oct 2019 12:21:38 -0700 Subject: RFR(T/XS) 8166275: vm/mlvm/meth/stress/compiler/deoptimize keeps timeouting In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 10/23/19 12:13 PM, Ekaterina Pavlova wrote: > Hi, > > The number of threads the test is launching by default is equal to (see vm/mlvm/share/MultiThreadedTest.java) > ?threadsPerCpu * Runtime.getRuntime().availableProcessors() + threadsExtra > > This is too much stress in case the build is debug one. For example on linux with 24 cores the test takes less > than half of minute in case of product build and more than 20 mins in case of fastdebug build. > The fix is quite trivial. It splits the test in two tests - one for product configuration and one for debug one. > The number of threads per cpu/core is reduced from 4 to 2 in case of debug build. > > > ???? JBS: https://bugs.openjdk.java.net/browse/JDK-8166275 > ? webrev: http://cr.openjdk.java.net/~epavlova//8166275/webrev.00/index.html > ?testing: run the test on all platforms with debug and product bits > > > thanks, > -katya From hohensee at amazon.com Wed Oct 23 20:37:35 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 23 Oct 2019 20:37:35 +0000 Subject: [11u] RFR: 8231085: C2/GC: Better GC-interface for expanding clone In-Reply-To: <582a0140-7b8e-cdd6-d0d3-d58c0964ccb0@redhat.com> References: <582a0140-7b8e-cdd6-d0d3-d58c0964ccb0@redhat.com> Message-ID: <360A0C79-6CBF-467A-AF49-EB9F9CD003AC@amazon.com> Ok. Still a tiny skipped change. Paul ?On 10/23/19, 7:30 AM, "hotspot-compiler-dev on behalf of Roman Kennke" wrote: I would like to backport the recent GC interface for expanding clones to jdk11u. This is a prerequisite to backport related Shenandoah changes to 11u without making a mess. The change differs from the original jdk14 change because it basically skips the intermediate GC interface for the same thing that's been introduced in jdk12. This one wholly replaces that. Bug: https://bugs.openjdk.java.net/browse/JDK-8231085 Original webrev: http://cr.openjdk.java.net/~rkennke/JDK-8231085/webrev.00/ JDK11u webrev: http://cr.openjdk.java.net/~rkennke/JDK-8231085/webrev.00.jdk11u/ Testing: tier1 and tier2 no regressions Good? Roman From gromero at linux.vnet.ibm.com Wed Oct 23 21:36:26 2019 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Wed, 23 Oct 2019 18:36:26 -0300 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation In-Reply-To: References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> Message-ID: <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com> Hi Martin, On 10/22/2019 11:37 AM, Doerr, Martin wrote: > Hi Gustavo, > > backport looks good. The parts you have collected from other changes make sense to me. Thank you so much for the review. Should I consider patches 2, 3, and 4/4 [0, 1, 2] reviewed too? (since they are part of the CRC32 patchset) I intend to push 1, 2, 3, and 4 at the same time to jdk8u, but there is no harm too if they are not applied at once, it won't break the CRC32 or the JVM. I know that patchset is not small, so I really appreciate your time reviewing the patches. Thank you. Best regards, Gustavo [0] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035219.html [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035221.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-September/035220.html From ekaterina.pavlova at oracle.com Thu Oct 24 00:21:17 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Wed, 23 Oct 2019 17:21:17 -0700 Subject: RFR(T/XS) 8166275: vm/mlvm/meth/stress/compiler/deoptimize keeps timeouting In-Reply-To: References: Message-ID: <3c0ac94c-aa40-c1b1-7a40-fa13d77df885@oracle.com> Thanks for prompt review Vladimir. On 10/23/19 12:21 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 10/23/19 12:13 PM, Ekaterina Pavlova wrote: >> Hi, >> >> The number of threads the test is launching by default is equal to (see vm/mlvm/share/MultiThreadedTest.java) >> ??threadsPerCpu * Runtime.getRuntime().availableProcessors() + threadsExtra >> >> This is too much stress in case the build is debug one. For example on linux with 24 cores the test takes less >> than half of minute in case of product build and more than 20 mins in case of fastdebug build. >> The fix is quite trivial. It splits the test in two tests - one for product configuration and one for debug one. >> The number of threads per cpu/core is reduced from 4 to 2 in case of debug build. >> >> >> ????? JBS: https://bugs.openjdk.java.net/browse/JDK-8166275 >> ?? webrev: http://cr.openjdk.java.net/~epavlova//8166275/webrev.00/index.html >> ??testing: run the test on all platforms with debug and product bits >> >> >> thanks, >> -katya From david.holmes at oracle.com Thu Oct 24 05:22:27 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Oct 2019 15:22:27 +1000 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: References: Message-ID: Hi Bob, On 24/10/2019 1:13 am, Bob Vandette wrote: > Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, > and alter a collection of JVM options to be product flags rather than experimental flags. > > EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. > Okay, so there are few things happening here so let me step through them. The desire is to enable an experimental compiler by default, but not have to run with all experimental options unlocked (which I assume is just to try and protect the end user from their own mistakes?). So the way this would work is that the command-line would effectively be: -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts --XX:-UnlockExperimentalVMOptions when EnableJVMCIProducts is processed (and is true) it will force on a couple of key JVMCI related flags, and it will turn off the flag-is-experimental bit on all the JVMCI flags. The latter being desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in play, all those other JVMCI flags would be hidden and you want them to be visible to introspection (like JVM TI, Dcmd) - is that correct? > RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 > WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 Looking at the code in detail I have a few comments. src/hotspot/share/jvmci/jvmci_globals.cpp if (UseJVMCICompiler) { + if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && !UseJVMCINativeLibrary) { + char path[JVM_MAXPATHLEN]; + if (os::dll_locate_lib(path, sizeof(path), Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { + // If a JVMCI native library is present, + // we enable UseJVMCINativeLibrary by default. + FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); + } + } This change will affect use of JVMCI independent of whether EnableJVMCIProduct is set - was that intentional? In JVMCIGlobals::enable_jvmci_product_mode, if we return false then argument processing will return JNI_ERR and the loading of the VM will terminate. It is not clear to me that the user would get any useful information regarding what failed. That said I can't really see what could actually fail in that code ... but perhaps a warning would be useful? I see where you clear the experimental bit, but as far as I can see that won't turn the flag into a product flag but will leave it uncategorised. ?? That probably works for you as you just need to ensure is_unlocked() returns true, but it does leave the flag in a strange state IMO. --- src/hotspot/share/runtime/arguments.cpp + #if INCLUDE_JVMCI + } else if (match_option(option, "-XX:+EnableJVMCIProduct")) { + JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); + // Allow this flag if it has been unlocked. + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { + return JNI_ERR; + } + } else if (match_option(option, "-XX:", &tail)) { + if (!process_argument(tail, args->ignoreUnrecognized, origin)) { + return JNI_EINVAL; + } + } It took me quite a while to understand that the point of + } else if (match_option(option, "-XX:", &tail)) { is purely to isolate the "EnableJVMCIProduct" part so that it can be processed by process_argument and report the expected error message that the flag has not been unlocked. I think it would be much clearer to just do that explicitly: + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { + return JNI_ERR; + } + } + // The flag was locked so process normally to report that error + else if (!process_argument("EnableJVMCIProduct", args->ignoreUnrecognized, origin)) { + return JNI_EINVAL; + } Also the whole else-if block you added appears to be missing the final } to close it. ?? --- src/hotspot/share/runtime/flags/jvmFlag.cpp + case RESOURCE: + st->print("resource"); break; src/hotspot/share/runtime/flags/jvmFlag.hpp ! RESOURCE = 7, ! INTERNAL = 8, I think the RESOURCE changes are part of the other RFE. ?? --- Thanks, David ----- > [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 > > Bob. > > From christian.hagedorn at oracle.com Thu Oct 24 10:04:51 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Thu, 24 Oct 2019 12:04:51 +0200 Subject: [14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" Message-ID: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> Hi Please review the following patch: https://bugs.openjdk.java.net/browse/JDK-8230019 http://cr.openjdk.java.net/~chagedorn/8230019/webrev.00/ This is an optimization of the previous fix [1, 2] which had a negative impact on performance. A complete explanation of the problem and the original fix can be found at [3]. In this patch, only the receiver klass information is cleared (which was the source of the assertion failure) instead of using clear_row() which also cleared the total count of the profile data as done in the fix of 8225670. I assume this prevented some inlining decisions which relied on reading such a cleared counter as in Compile::call_generator() [4]. This patch had no negative impact on performance anymore (verified with regressing benchmarks). Thank you! Best regards, Christian [1] https://bugs.openjdk.java.net/browse/JDK-8225670 [2] http://cr.openjdk.java.net/~thartmann/8225670/webrev.00/ [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-August/034776.html [4] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l85 From martin.doerr at sap.com Thu Oct 24 10:17:12 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 24 Oct 2019 10:17:12 +0000 Subject: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More generic vector CRC implementation In-Reply-To: <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com> References: <0dc83fcb-4e09-5841-04be-aee615e5a7fd@linux.vnet.ibm.com> <67e6e482-df56-27d0-da20-7968615f3ea1@linux.vnet.ibm.com> Message-ID: Hi Gustavo, I think removing invertCRC is an unnecessary manual change. We should minimize that as far as possible. They may create merge conflicts for future backports. Best regards, Martin > -----Original Message----- > From: Gustavo Romero > Sent: Mittwoch, 23. Oktober 2019 23:36 > To: Doerr, Martin ; hotspot-compiler- > dev at openjdk.java.net > Cc: jdk8u-dev at openjdk.java.net > Subject: Re: [8u] RFR for backport of 8198894 (CRC32 1/4): [PPC64] More > generic vector CRC implementation > > Hi Martin, > > On 10/22/2019 11:37 AM, Doerr, Martin wrote: > > Hi Gustavo, > > > > backport looks good. The parts you have collected from other changes > make sense to me. > > Thank you so much for the review. > > Should I consider patches 2, 3, and 4/4 [0, 1, 2] reviewed too? (since they are > part of the CRC32 patchset) > > I intend to push 1, 2, 3, and 4 at the same time to jdk8u, but there is no > harm too if they are not applied at once, it won't break the CRC32 or the > JVM. > > I know that patchset is not small, so I really appreciate your time reviewing > the patches. Thank you. > > Best regards, > Gustavo > > [0] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- > September/035219.html > [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- > September/035221.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- > September/035220.html From nils.eliasson at oracle.com Thu Oct 24 13:51:10 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 24 Oct 2019 15:51:10 +0200 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> Message-ID: Hi Martin, Not that this is your fault, but the compileBroker has crossed the line for the number of "#if INCLUDE_JVMCI" a long time ago. This file screams for a refactoring where JVMCI is hidden behind an abstraction layer. I'm not going to request it out of this bug fix, but I can't leave it without comment. Regards, Nils On 2019-10-23 16:47, Doerr, Martin wrote: > Hi Kim, > > I didn't like using the OopStorage stuff directly, either. I just have not seen how to allocate a global handle and add the oop later. > > Thanks for pointing me to JVMCI::make_global. I was not aware of that. > > So I can imagine 3 ways to implement it: > > 1. Use JNIHandles::destroy_global to release the handles. I just added that to > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.01/ > We may want to improve that further by setting the handle pointer to NULL and asserting that it is NULL before adding the new one. > I had been concerned about NULLs in the array, but looks like the existing code can deal with that. > > 2. Use JVMCI::make_global, keep the handles and replace the j.t.Thread objects. Changed in place: > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.02/ > > JMVCI::make_global uses OopStorageSet::vm_global instead of jni_global. No clue if this is better or worse. > > But seems like JMVCI::make_global still doesn't like NULL handles in slowdebug build ?? > assert(oopDesc::is_oop(obj()), "not an oop"); > > 3. Just use the possibly_add_compiler_threads part of webrev.02 and leave the initialization as is. > This means we create j.l.Thread objects initially and replace them by new ones when the JVMCI threads get started. I'd be ok with this, too. > > > Sorry for the in-place updates, but so many webrevs would confuse me after some time. > > > Best regards, > Martin > > >> -----Original Message----- >> From: Kim Barrett >> Sent: Mittwoch, 23. Oktober 2019 02:25 >> To: Doerr, Martin >> Cc: David Holmes ; Vladimir Kozlov >> (vladimir.kozlov at oracle.com) ; hotspot- >> compiler-dev at openjdk.java.net >> Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread >> >>> On Oct 22, 2019, at 9:18 AM, Doerr, Martin >> wrote: >>>> Sorry I don't follow. The initial Handle stored in the array was a >>>> global handle. You just allocated a second global Handle. I don't see >>>> any operator=() magic happening here to free one of those global >>>> handles, so AFAICS you need to free one of them. >>> Sorry. I had implemented it differently than I wanted. Thanks for pointing >> me to it. >>> Fixed: >>> >> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr >> ev.02/ >> >> Please don't do that. That's basically smashing through the JNHHandles >> abstraction and writing a bunch of (lower level and tightly coupled) >> code for no good reason. Just use JNIHandles::make_global and >> JNHHandles::destroy_global as David suggested. >> >> (Note that JNIHandles::make_global takes an AllocFailType argument; if >> you aren't going to handle allocation failure (e.g. are just going to >> call vm_exit_out_of_memory, as in webrev.02) the default will deal >> with that for you.) >> >> Alternatively, can you use JVMCI::make_global and JVMCI::destroy_global >> here? Perhaps not, if some of this code is !UseJVMCICompiler or whatever. >> That's kind of unfortunate. (It's also unfortunate that those functions >> deal with jobject, but that's a different problem.) >> From bob.vandette at oracle.com Thu Oct 24 15:27:38 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Thu, 24 Oct 2019 11:27:38 -0400 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: References: Message-ID: Thanks for the review. See comments below. Updated webrev: http://cr.openjdk.java.net/~bobv/8232118/webrev.02 > On Oct 24, 2019, at 1:22 AM, David Holmes wrote: > > Hi Bob, > > On 24/10/2019 1:13 am, Bob Vandette wrote: >> Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, >> and alter a collection of JVM options to be product flags rather than experimental flags. >> EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. > > Okay, so there are few things happening here so let me step through them. The desire is to enable an experimental compiler by default, but not have to run with all experimental options unlocked (which I assume is just to try and protect the end user from their own mistakes?). So the way this would work is that the command-line would effectively be: > > -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts --XX:-UnlockExperimentalVMOptions > > when EnableJVMCIProducts is processed (and is true) it will force on a couple of key JVMCI related flags, and it will turn off the flag-is-experimental bit on all the JVMCI flags. The latter being desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in play, all those other JVMCI flags would be hidden and you want them to be visible to introspection (like JVM TI, Dcmd) - is that correct? Yes, that?s correct. > >> RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 >> WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 > > Looking at the code in detail I have a few comments. > > src/hotspot/share/jvmci/jvmci_globals.cpp > > if (UseJVMCICompiler) { > + if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && !UseJVMCINativeLibrary) { > + char path[JVM_MAXPATHLEN]; > + if (os::dll_locate_lib(path, sizeof(path), Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { > + // If a JVMCI native library is present, > + // we enable UseJVMCINativeLibrary by default. > + FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); > + } > + } > > This change will affect use of JVMCI independent of whether EnableJVMCIProduct is set - was that intentional? Yes, the compiler team is ok with this additional functionality being available when UseJVMCICompiler is true independent of EnableJVMCIProduct. I?ve updated the RFE text to be clearer that this change is independent of the new flag. > > In JVMCIGlobals::enable_jvmci_product_mode, if we return false then argument processing will return JNI_ERR and the loading of the VM will terminate. It is not clear to me that the user would get any useful information regarding what failed. That said I can't really see what could actually fail in that code ... but perhaps a warning would be useful? Ok. > > I see where you clear the experimental bit, but as far as I can see that won't turn the flag into a product flag but will leave it uncategorised. ?? That probably works for you as you just need to ensure is_unlocked() returns true, but it does leave the flag in a strange state IMO. Thanks for that find, I assumed !experimental was product. I?ll add a set_product function and call it when I remove the experimental bit. > > --- > > src/hotspot/share/runtime/arguments.cpp > > + #if INCLUDE_JVMCI > + } else if (match_option(option, "-XX:+EnableJVMCIProduct")) { > + JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); > + // Allow this flag if it has been unlocked. > + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { > + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { > + return JNI_ERR; > + } > + } else if (match_option(option, "-XX:", &tail)) { > + if (!process_argument(tail, args->ignoreUnrecognized, origin)) { > + return JNI_EINVAL; > + } > + } > > It took me quite a while to understand that the point of > > + } else if (match_option(option, "-XX:", &tail)) { > > is purely to isolate the "EnableJVMCIProduct" part so that it can be processed by process_argument and report the expected error message that the flag has not been unlocked. I think it would be much clearer to just do that explicitly: > > + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { > + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { > + return JNI_ERR; > + } > + } > + // The flag was locked so process normally to report that error > + else if (!process_argument("EnableJVMCIProduct", args->ignoreUnrecognized, origin)) { > + return JNI_EINVAL; > + } > > Ok. > Also the whole else-if block you added appears to be missing the final } to close it. ?? Its on the next line after the #endif. This is how all the if cases are structures. > > --- > > src/hotspot/share/runtime/flags/jvmFlag.cpp > > + case RESOURCE: > + st->print("resource"); break; > > src/hotspot/share/runtime/flags/jvmFlag.hpp > > ! RESOURCE = 7, > ! INTERNAL = 8, > > I think the RESOURCE changes are part of the other RFE. ?? Correct, these leaked in from another RFE and will be removed from my push. Thanks, Bob. > > --- > > Thanks, > David > ----- > > >> [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >> Bob. From vladimir.kozlov at oracle.com Thu Oct 24 16:55:43 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Oct 2019 09:55:43 -0700 Subject: [14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" In-Reply-To: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> References: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> Message-ID: I would like to see what happens with MDO data with Tobias fix which caused regression. If it is simple. May be from LogCompilation. Original fix for 6923002 explicitly assumed [1] that we will get monomorphic in such case (we record 2 types and cleaning one and leaving only one). Total count will be adjusted anyway if needed [2]. The only explanation I can think of if we had only one receiver in MDO which we cleaned up and it confuse C2 to treat call site as never executed [3] so that it can't use speculative_receiver_type which come from other data. Your fix seems reasonable and explains why it may help even so there is no type information in MDO, only count. Thanks, Vladimir [1] http://hg.openjdk.java.net/jdk/jdk/file/32d39d9525f9/src/hotspot/share/oops/methodData.hpp#l1158 [2] http://hg.openjdk.java.net/jdk/jdk/file/32d39d9525f9/src/hotspot/share/ci/ciMethod.cpp#l534 [3] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l205 On 10/24/19 3:04 AM, Christian Hagedorn wrote: > Hi > > Please review the following patch: > https://bugs.openjdk.java.net/browse/JDK-8230019 > http://cr.openjdk.java.net/~chagedorn/8230019/webrev.00/ > > This is an optimization of the previous fix [1, 2] which had a negative impact on performance. A complete explanation of > the problem and the original fix can be found at [3]. > > In this patch, only the receiver klass information is cleared (which was the source of the assertion failure) instead of > using clear_row() which also cleared the total count of the profile data as done in the fix of 8225670. I assume this > prevented some inlining decisions which relied on reading such a cleared counter as in Compile::call_generator() [4]. > This patch had no negative impact on performance anymore (verified with regressing benchmarks). > > Thank you! > > Best regards, > Christian > > > [1] https://bugs.openjdk.java.net/browse/JDK-8225670 > [2] http://cr.openjdk.java.net/~thartmann/8225670/webrev.00/ > [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-August/034776.html > [4] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l85 From vladimir.kozlov at oracle.com Thu Oct 24 18:51:05 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Oct 2019 11:51:05 -0700 Subject: [14] RFR(M) 8232904: Update JVMCI Message-ID: https://cr.openjdk.java.net/~kvn/8232904/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8232904 Sync latest changes from graal-jvmci-8: [GR-18629] Fix compilation problem on windows. [GR-17318] Add isBeingInitialized. [GR-18349] Add default implementation for encoded SpeculationReasons. [GR-17920] Handle missing or non-cloneable SHA-1 implementation. [GR-16353] Added a getter of an address of current JavaThread into HotSpotJVMCIRuntime. Tested with tier1, tier3-graal. Thanks, Vladimir From doug.simon at oracle.com Thu Oct 24 22:12:26 2019 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 25 Oct 2019 00:12:26 +0200 Subject: [14] RFR(M) 8232904: Update JVMCI In-Reply-To: References: Message-ID: <370D2F66-585D-4CCB-96A9-27AFB4383D64@oracle.com> Looks good to me. > On 24 Oct 2019, at 20:51, Vladimir Kozlov wrote: > > https://cr.openjdk.java.net/~kvn/8232904/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8232904 > > Sync latest changes from graal-jvmci-8: > [GR-18629] Fix compilation problem on windows. > [GR-17318] Add isBeingInitialized. > [GR-18349] Add default implementation for encoded SpeculationReasons. > [GR-17920] Handle missing or non-cloneable SHA-1 implementation. > [GR-16353] Added a getter of an address of current JavaThread into HotSpotJVMCIRuntime. > > Tested with tier1, tier3-graal. > > Thanks, > Vladimir From vladimir.kozlov at oracle.com Thu Oct 24 22:37:48 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 24 Oct 2019 15:37:48 -0700 Subject: [14] RFR(M) 8232904: Update JVMCI In-Reply-To: <370D2F66-585D-4CCB-96A9-27AFB4383D64@oracle.com> References: <370D2F66-585D-4CCB-96A9-27AFB4383D64@oracle.com> Message-ID: <907e1610-ee44-aa7d-4de7-18553c8a2e3c@oracle.com> Thank you, Doug Vladimir On 10/24/19 3:12 PM, Doug Simon wrote: > Looks good to me. > >> On 24 Oct 2019, at 20:51, Vladimir Kozlov wrote: >> >> https://cr.openjdk.java.net/~kvn/8232904/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8232904 >> >> Sync latest changes from graal-jvmci-8: >> [GR-18629] Fix compilation problem on windows. >> [GR-17318] Add isBeingInitialized. >> [GR-18349] Add default implementation for encoded SpeculationReasons. >> [GR-17920] Handle missing or non-cloneable SHA-1 implementation. >> [GR-16353] Added a getter of an address of current JavaThread into HotSpotJVMCIRuntime. >> >> Tested with tier1, tier3-graal. >> >> Thanks, >> Vladimir > From david.holmes at oracle.com Fri Oct 25 00:06:42 2019 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Oct 2019 10:06:42 +1000 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: References: Message-ID: On 25/10/2019 1:27 am, Bob Vandette wrote: > Thanks for the review. ?See comments below. > > Updated webrev: http://cr.openjdk.java.net/~bobv/8232118/webrev.02 That all seems fine. Minor nit in arguments.cpp: + "Unable to enable jvmci in product mode"); s/jvmci/JVMCI/ One follow up ... you don't modify all of the JVMCI flags. The following are omitted: BootstrapJVMCI JVMCIHostThreads JVMCITraceLevel MethodProfileWidth PrintBootstrap Thanks, David > >> On Oct 24, 2019, at 1:22 AM, David Holmes > > wrote: >> >> Hi Bob, >> >> On 24/10/2019 1:13 am, Bob Vandette wrote: >>> Please review this RFE that adds a new JVM option >>> "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the >>> default compiler, >>> and alter a collection of JVM options to be product flags rather than >>> experimental flags. >>> EnableJVMCIProduct is an experimental flag since the default JVMCI >>> running mode is still experimental. A vendor wishing to support their >>> JVMCI compiler as the default can enable JVMCI by default by >>> specifying this new -XX:+EnableJVMCIProduct flag after the >>> -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful >>> when added to a JDK runtime generated with the new jlink >>> --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based >>> compilers to be used, by default, without the user having to specify >>> any options. >> >> Okay, so there are few things happening here so let me step through >> them. The desire is to enable an experimental compiler by default, but >> not have to run with all experimental options unlocked (which I assume >> is just to try and protect the end user from their own mistakes?). So >> the way this would work is that the command-line would effectively be: >> >> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts >> --XX:-UnlockExperimentalVMOptions >> >> when EnableJVMCIProducts is processed (and is true) it will force on a >> couple of key JVMCI related flags, and it will turn off the >> flag-is-experimental bit on all the JVMCI flags. The latter being >> desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in >> play, all those other JVMCI flags would be hidden and you want them to >> be visible to introspection (like JVM TI, Dcmd) - is that correct? > > Yes, that?s correct. > >> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 >>> WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 >> >> Looking at the code in detail I have a few comments. >> >> src/hotspot/share/jvmci/jvmci_globals.cpp >> >> ???if (UseJVMCICompiler) { >> + ????if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && >> !UseJVMCINativeLibrary) { >> + ??????char path[JVM_MAXPATHLEN]; >> + ??????if (os::dll_locate_lib(path, sizeof(path), >> Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { >> + ????????// If a JVMCI native library is present, >> + ????????// we enable UseJVMCINativeLibrary by default. >> + ????????FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); >> + ??????} >> + ????} >> >> This change will affect use of JVMCI independent of whether >> EnableJVMCIProduct is set - was that intentional? > > Yes, the compiler team is ok with this additional functionality being > available when UseJVMCICompiler is true > independent of EnableJVMCIProduct. ?I?ve updated the RFE text to be > clearer that this change is independent of > the new flag. > >> >> In JVMCIGlobals::enable_jvmci_product_mode, if we return false then >> argument processing will return JNI_ERR and the loading of the VM will >> terminate. It is not clear to me that the user would get any useful >> information regarding what failed. That said I can't really see what >> could actually fail in that code ... but perhaps a warning would be >> useful? > > Ok. > >> >> I see where you clear the experimental bit, but as far as I can see >> that won't turn the flag into a product flag but will leave it >> uncategorised. ?? That probably works for you as you just need to >> ensure is_unlocked() returns true, but it does leave the flag in a >> strange state IMO. > > Thanks for that find, I assumed !experimental was product. ?I?ll add a > set_product function and call it when I remove the experimental bit. > >> >> --- >> >> src/hotspot/share/runtime/arguments.cpp >> >> + #if INCLUDE_JVMCI >> + ????} else if (match_option(option, "-XX:+EnableJVMCIProduct")) { >> + ??????JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); >> + ??????// Allow this flag if it has been unlocked. >> + ??????if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >> + ????????if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >> + ??????????return JNI_ERR; >> + ????????} >> + ??????} else if (match_option(option, "-XX:", &tail)) { >> + ????????if (!process_argument(tail, args->ignoreUnrecognized, origin)) { >> + ??????????return JNI_EINVAL; >> + ????????} >> + ??????} >> >> It took me quite a while to understand that the point of >> >> + ??????} else if (match_option(option, "-XX:", &tail)) { >> >> is purely to isolate the "EnableJVMCIProduct" part so that it can be >> processed by process_argument and report the expected error message >> that the flag has not been unlocked. I think it would be much clearer >> to just do that explicitly: >> >> + ??????if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >> + ????????if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >> + ??????????return JNI_ERR; >> + ????????} >> + ??????} >> + ??????// The flag was locked so process normally to report that error >> + ??????else if (!process_argument("EnableJVMCIProduct", >> args->ignoreUnrecognized, origin)) { >> + ????????return JNI_EINVAL; >> + ??????} >> >> > Ok. > >> Also the whole else-if block you added appears to be missing the final >> } to close it. ?? > > Its on the next line after the #endif. ?This is how all the if cases are > structures. > >> >> --- >> >> src/hotspot/share/runtime/flags/jvmFlag.cpp >> >> + ????case RESOURCE: >> + ??????st->print("resource"); break; >> >> src/hotspot/share/runtime/flags/jvmFlag.hpp >> >> ! ????RESOURCE ????????= 7, >> ! ????INTERNAL ????????= 8, >> >> I think the RESOURCE changes are part of the other RFE. ?? > > Correct, these leaked in from another RFE and will be removed from my push. > > Thanks, > Bob. > >> >> --- >> >> Thanks, >> David >> ----- >> >> >>> [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>> Bob. > From dean.long at oracle.com Fri Oct 25 00:37:56 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 24 Oct 2019 17:37:56 -0700 Subject: RFR: 8231955: ARM32: Address displacement is 0 for volatile field access because of Unsafe field access. In-Reply-To: <20191015073212.7FCCA319074@aojmv0009> References: <20191010143426.BA4B6319F46@aojmv0009> <20191015073212.7FCCA319074@aojmv0009> Message-ID: The shared code used to call generate_address(), which correctly handles various displacements, but I guess it got lost in the barrier refactoring in jdk11.? I think the correct fix is for the caller to use generate_address() again.? CCing GC alias. Alternatively, the arm code could call generate_address rather than changing the shared code. dl On 10/15/19 12:30 AM, christoph.goettschkes at microdoc.com wrote: > Is there anyone who could take a look at this change and give feedback > please? > > Thanks, > Christoph > > "hotspot-compiler-dev" > wrote on 2019-10-10 16:29:11: > >> From: christoph.goettschkes at microdoc.com >> To: hotspot-compiler-dev at openjdk.java.net >> Date: 2019-10-10 16:35 >> Subject: RFR: 8231955: ARM32: Address displacement is 0 for volatile > field >> access because of Unsafe field access. >> Sent by: "hotspot-compiler-dev" > >> Hi, >> >> please review the following changeset. This patch fixes the volatile > field >> access for 32-bit ARM. The functions LIRGenerator::volatile_field_store >> and LIRGenerator::volatile_field_load both assume that the displacement >> for the given address is always 0. Both use the given address and pass > the >> values to add_large_constant() [1], which asserts that the given >> displacement is not 0. The change does not call add_large_constant if > the >> given displacement is 0. The displacement can be 0, because of the >> implementation of the unsafe intrinsics. This happens, because the > offset >> into the object from which the field is accessed is not a constant > value. >> This fixes the hotspot tier1 tests mentioned in the issue. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231955 >> Webrev: https://cr.openjdk.java.net/~bulasevich/8231955/webrev.00/ >> >> Thanks, >> Christoph >> >> [1] >> > https://hg.openjdk.java.net/jdk/jdk/file/30a9612a657d/src/hotspot/cpu/arm/ >> c1_LIRGenerator_arm.cpp#l166 >> From dean.long at oracle.com Fri Oct 25 00:55:52 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 24 Oct 2019 17:55:52 -0700 Subject: RFR: 8231955: ARM32: Address displacement is 0 for volatile field access because of Unsafe field access. In-Reply-To: References: <20191010143426.BA4B6319F46@aojmv0009> <20191015073212.7FCCA319074@aojmv0009> Message-ID: <587f6363-bbdc-da12-9e50-82acc5bc5853@oracle.com> I see now that BarrierSetC1::resolve_address() is calling generate_address(), at least when access isn't patched.? So now I'm thinking that the address passed to volatile_field_load/volatile_field_store should be correct, and the call to add_large_constant() isn't necessary. dl On 10/24/19 5:37 PM, dean.long at oracle.com wrote: > The shared code used to call generate_address(), which correctly > handles various displacements, but I guess it got lost in the barrier > refactoring in jdk11.? I think the correct fix is for the caller to > use generate_address() again.? CCing GC alias. Alternatively, the arm > code could call generate_address rather than changing the shared code. > > dl > > On 10/15/19 12:30 AM, christoph.goettschkes at microdoc.com wrote: >> Is there anyone who could take a look at this change and give feedback >> please? >> >> Thanks, >> Christoph >> >> "hotspot-compiler-dev" >> wrote on 2019-10-10 16:29:11: >> >>> From: christoph.goettschkes at microdoc.com >>> To: hotspot-compiler-dev at openjdk.java.net >>> Date: 2019-10-10 16:35 >>> Subject: RFR: 8231955: ARM32: Address displacement is 0 for volatile >> field >>> access because of Unsafe field access. >>> Sent by: "hotspot-compiler-dev" >> >>> Hi, >>> >>> please review the following changeset. This patch fixes the volatile >> field >>> access for 32-bit ARM. The functions LIRGenerator::volatile_field_store >>> and LIRGenerator::volatile_field_load both assume that the displacement >>> for the given address is always 0. Both use the given address and pass >> the >>> values to add_large_constant() [1], which asserts that the given >>> displacement is not 0. The change does not call add_large_constant if >> the >>> given displacement is 0. The displacement can be 0, because of the >>> implementation of the unsafe intrinsics. This happens, because the >> offset >>> into the object from which the field is accessed is not a constant >> value. >>> This fixes the hotspot tier1 tests mentioned in the issue. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231955 >>> Webrev: https://cr.openjdk.java.net/~bulasevich/8231955/webrev.00/ >>> >>> Thanks, >>> Christoph >>> >>> [1] >>> >> https://hg.openjdk.java.net/jdk/jdk/file/30a9612a657d/src/hotspot/cpu/arm/ >> >>> c1_LIRGenerator_arm.cpp#l166 >>> > From ekaterina.pavlova at oracle.com Fri Oct 25 05:16:39 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Thu, 24 Oct 2019 22:16:39 -0700 Subject: RFR(T/XS) 8233000: Mark vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize test as stress test Message-ID: Hi, please review the extra small patch which tags vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize by 'stress' keyword. This test was recently re-enabled as part of 8166275 fix and started to run in tier3. However the test is stress one and is not intended to be run in tier3. Adding 'stress' keyword will exclude the test from tier3. JBS: https://bugs.openjdk.java.net/browse/JDK-8233000 webrev: http://cr.openjdk.java.net/~epavlova//8233000/webrev.00/index.html testing: tier3 thanks, -katya From igor.veresov at oracle.com Fri Oct 25 06:15:08 2019 From: igor.veresov at oracle.com (Igor Veresov) Date: Thu, 24 Oct 2019 23:15:08 -0700 Subject: RFR(T/XS) 8233000: Mark vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize test as stress test In-Reply-To: References: Message-ID: <93C28BD9-CE8D-423C-BFDF-D2013E09D45E@oracle.com> Looks good. igor > On Oct 24, 2019, at 10:16 PM, Ekaterina Pavlova wrote: > > Hi, > > please review the extra small patch which tags vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize by 'stress' keyword. > This test was recently re-enabled as part of 8166275 fix and started to run in tier3. > However the test is stress one and is not intended to be run in tier3. > Adding 'stress' keyword will exclude the test from tier3. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8233000 > webrev: http://cr.openjdk.java.net/~epavlova//8233000/webrev.00/index.html > testing: tier3 > > > thanks, > -katya From leonid.mesnik at oracle.com Fri Oct 25 06:54:41 2019 From: leonid.mesnik at oracle.com (Leonid Mesnik) Date: Thu, 24 Oct 2019 23:54:41 -0700 Subject: RFR(T/XS) 8233000: Mark vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize test as stress test In-Reply-To: References: Message-ID: Looks good. Leonid > On Oct 24, 2019, at 10:16 PM, Ekaterina Pavlova wrote: > > Hi, > > please review the extra small patch which tags vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize by 'stress' keyword. > This test was recently re-enabled as part of 8166275 fix and started to run in tier3. > However the test is stress one and is not intended to be run in tier3. > Adding 'stress' keyword will exclude the test from tier3. > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8233000 > webrev: http://cr.openjdk.java.net/~epavlova//8233000/webrev.00/index.html > testing: tier3 > > > thanks, > -katya From patric.hedlin at oracle.com Fri Oct 25 08:59:17 2019 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Fri, 25 Oct 2019 10:59:17 +0200 Subject: RFR(S): 8231565: More node budget assert in fuzzed test In-Reply-To: <11bd5e70-9e0d-9df9-d345-a9d1ba0b30e5@oracle.com> References: <7a0b347a-02f3-b841-82eb-f0887fd6d7f3@oracle.com> <11bd5e70-9e0d-9df9-d345-a9d1ba0b30e5@oracle.com> Message-ID: <6e699706-905c-79df-4fa3-0f8bcb3dc6d2@oracle.com> Thanks for reviewing Tobias and Nils. On 22/10/2019 09:30, Tobias Hartmann wrote: > Hi Patric, > > the fix looks good to me but why does the test contain multiple copies of the same run statements? Fixed. /Patric > Best regards, > Tobias > > On 15.10.19 16:20, Patric Hedlin wrote: >> Dear all, >> >> I would like to ask for help to review the following change/update: >> >> Issue:? https://bugs.openjdk.java.net/browse/JDK-8231565 >> Webrev: http://cr.openjdk.java.net/~phedlin/tr8231565/ >> >> 8231565: More node budget assert in fuzzed test >> >> ??? Another bad estimate. Loop rotation is too poorly approximated >> ??? as a clone operation alone. Same ad-hoc. >> >> >> Testing: hs-tier1..3, hs-precheckin-comp, JavaFuzzer >> ??? Including new TC >> >> >> Best regards, >> Patric From doug.simon at oracle.com Fri Oct 25 10:57:48 2019 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 25 Oct 2019 12:57:48 +0200 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: References: Message-ID: <860FAE8F-579A-4DE9-9862-AA0A4B20B4E7@oracle.com> > On 25 Oct 2019, at 02:06, David Holmes wrote: > > On 25/10/2019 1:27 am, Bob Vandette wrote: >> Thanks for the review. See comments below. >> Updated webrev: http://cr.openjdk.java.net/~bobv/8232118/webrev.02 > > That all seems fine. > > Minor nit in arguments.cpp: > > + "Unable to enable jvmci in product mode"); > > s/jvmci/JVMCI/ > > One follow up ... you don't modify all of the JVMCI flags. The following are omitted: > > BootstrapJVMCI > JVMCIHostThreads > JVMCITraceLevel > MethodProfileWidth > PrintBootstrap These are all diagnostic flags. Bob, can EnableJVMCIProduct make them into actual diagnostic flags? -Doug > > >>> On Oct 24, 2019, at 1:22 AM, David Holmes > wrote: >>> >>> Hi Bob, >>> >>> On 24/10/2019 1:13 am, Bob Vandette wrote: >>>> Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, >>>> and alter a collection of JVM options to be product flags rather than experimental flags. >>>> EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. >>> >>> Okay, so there are few things happening here so let me step through them. The desire is to enable an experimental compiler by default, but not have to run with all experimental options unlocked (which I assume is just to try and protect the end user from their own mistakes?). So the way this would work is that the command-line would effectively be: >>> >>> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts --XX:-UnlockExperimentalVMOptions >>> >>> when EnableJVMCIProducts is processed (and is true) it will force on a couple of key JVMCI related flags, and it will turn off the flag-is-experimental bit on all the JVMCI flags. The latter being desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in play, all those other JVMCI flags would be hidden and you want them to be visible to introspection (like JVM TI, Dcmd) - is that correct? >> Yes, that?s correct. >>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 >>>> WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 >>> >>> Looking at the code in detail I have a few comments. >>> >>> src/hotspot/share/jvmci/jvmci_globals.cpp >>> >>> if (UseJVMCICompiler) { >>> + if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && !UseJVMCINativeLibrary) { >>> + char path[JVM_MAXPATHLEN]; >>> + if (os::dll_locate_lib(path, sizeof(path), Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { >>> + // If a JVMCI native library is present, >>> + // we enable UseJVMCINativeLibrary by default. >>> + FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); >>> + } >>> + } >>> >>> This change will affect use of JVMCI independent of whether EnableJVMCIProduct is set - was that intentional? >> Yes, the compiler team is ok with this additional functionality being available when UseJVMCICompiler is true >> independent of EnableJVMCIProduct. I?ve updated the RFE text to be clearer that this change is independent of >> the new flag. >>> >>> In JVMCIGlobals::enable_jvmci_product_mode, if we return false then argument processing will return JNI_ERR and the loading of the VM will terminate. It is not clear to me that the user would get any useful information regarding what failed. That said I can't really see what could actually fail in that code ... but perhaps a warning would be useful? >> Ok. >>> >>> I see where you clear the experimental bit, but as far as I can see that won't turn the flag into a product flag but will leave it uncategorised. ?? That probably works for you as you just need to ensure is_unlocked() returns true, but it does leave the flag in a strange state IMO. >> Thanks for that find, I assumed !experimental was product. I?ll add a set_product function and call it when I remove the experimental bit. >>> >>> --- >>> >>> src/hotspot/share/runtime/arguments.cpp >>> >>> + #if INCLUDE_JVMCI >>> + } else if (match_option(option, "-XX:+EnableJVMCIProduct")) { >>> + JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); >>> + // Allow this flag if it has been unlocked. >>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>> + return JNI_ERR; >>> + } >>> + } else if (match_option(option, "-XX:", &tail)) { >>> + if (!process_argument(tail, args->ignoreUnrecognized, origin)) { >>> + return JNI_EINVAL; >>> + } >>> + } >>> >>> It took me quite a while to understand that the point of >>> >>> + } else if (match_option(option, "-XX:", &tail)) { >>> >>> is purely to isolate the "EnableJVMCIProduct" part so that it can be processed by process_argument and report the expected error message that the flag has not been unlocked. I think it would be much clearer to just do that explicitly: >>> >>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>> + return JNI_ERR; >>> + } >>> + } >>> + // The flag was locked so process normally to report that error >>> + else if (!process_argument("EnableJVMCIProduct", args->ignoreUnrecognized, origin)) { >>> + return JNI_EINVAL; >>> + } >>> >>> >> Ok. >>> Also the whole else-if block you added appears to be missing the final } to close it. ?? >> Its on the next line after the #endif. This is how all the if cases are structures. >>> >>> --- >>> >>> src/hotspot/share/runtime/flags/jvmFlag.cpp >>> >>> + case RESOURCE: >>> + st->print("resource"); break; >>> >>> src/hotspot/share/runtime/flags/jvmFlag.hpp >>> >>> ! RESOURCE = 7, >>> ! INTERNAL = 8, >>> >>> I think the RESOURCE changes are part of the other RFE. ?? >> Correct, these leaked in from another RFE and will be removed from my push. >> Thanks, >> Bob. >>> >>> --- >>> >>> Thanks, >>> David >>> ----- >>> >>> >>>> [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>>> Bob. From aph at redhat.com Fri Oct 25 13:11:23 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Oct 2019 14:11:23 +0100 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> Message-ID: <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> On 10/22/19 10:50 AM, Pengfei Li (Arm Technology China) wrote: > I don't find any jtreg cases testing these. I've created a jtreg and uploaded a new webrev, please see > http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.01/ > > Is it good enough? Yes, I think so. It's enough to make sure that the corner cases and overflows are handled correctly. We have to be sure that we really are generating the correct instructions. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Oct 25 14:42:18 2019 From: aph at redhat.com (Andrew Haley) Date: Fri, 25 Oct 2019 15:42:18 +0100 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> Message-ID: <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> On 10/25/19 2:11 PM, Andrew Haley wrote: > On 10/22/19 10:50 AM, Pengfei Li (Arm Technology China) wrote: >> I don't find any jtreg cases testing these. I've created a jtreg and uploaded a new webrev, please see >> http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.01/ >> >> Is it good enough? > > Yes, I think so. It's enough to make sure that the corner cases and overflows > are handled correctly. We have to be sure that we really are generating the > correct instructions. Thanks. By the way, I also checked with this Case: new Case(0xffffffff, 0xffffffff, 0xffffffffeL << 32, 0xfffffffe00000001L, 0xfffffffdffffffffL, -1L), which tests the carries frm highpart to lowpart. (It's the result of 0xffffffff * 0xffffffff == 0xfffffffe00000001.) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ekaterina.pavlova at oracle.com Fri Oct 25 14:44:19 2019 From: ekaterina.pavlova at oracle.com (Ekaterina Pavlova) Date: Fri, 25 Oct 2019 07:44:19 -0700 Subject: RFR(T/XS) 8233000: Mark vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize test as stress test In-Reply-To: References: Message-ID: <98ea122f-8fe0-304e-78d7-d416a3bb8949@oracle.com> Thank you Igor and Leonid. -katya On 10/24/19 11:54 PM, Leonid Mesnik wrote: > Looks good. > > Leonid > >> On Oct 24, 2019, at 10:16 PM, Ekaterina Pavlova wrote: >> >> Hi, >> >> please review the extra small patch which tags vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize by 'stress' keyword. >> This test was recently re-enabled as part of 8166275 fix and started to run in tier3. >> However the test is stress one and is not intended to be run in tier3. >> Adding 'stress' keyword will exclude the test from tier3. >> >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8233000 >> webrev: http://cr.openjdk.java.net/~epavlova//8233000/webrev.00/index.html >> testing: tier3 >> >> >> thanks, >> -katya > From thomas.stuefe at gmail.com Fri Oct 25 14:57:13 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 25 Oct 2019 16:57:13 +0200 Subject: RFR(xs): java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit Message-ID: Hello, Could I please have opinions and reviews for the following fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8233019 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8233019-c1-isprimitive/webrev.00/webrev/ While working with the prototype of the new metaspace allocator (JDK-8221173), I saw weird errors which looked like java.lang.Class.isPrimitive() returning sometimes incorrectly true for boolean[].class, which is not a primitive. The bug seems to only happen in c1. boolean[].class is the very first Klass* ever to be created in the life of a VM. For JDK-8221173 I removed metachunk headers from their payload. One unintended side effect is that the first Klass* is now allocated directly at the base of class space. If the class space base is aligned to 32bit, the Klass* for boolean[].class is so too, and all lower 32bits are zero. That seems to trigger what I think is a bug in C1, in isPrimitive. There, the Klass* pointer gets loaded from the mirror, and then compared with zero (class objects for primitives have no associated Klass*, so isPrimitive() returns true if that Klass* pointer is NULL). But to me it seems that this comparison is done with 32bit cmp: ------------- 6512 Compiled method (c1) 822 31 1 java.lang.invoke.MethodTypeForm::canonicalize (233 bytes) .... 6544 ;; block B2 [9, 13] 6545 0x00007f2ca8e76f3f: mov 0x50(%rsi),%rdi ; implicit exception: dispatches to 0x00007f2ca8e771ec 6546 0x00007f2ca8e76f43: cmp $0x0,%edi <<<< 32bit? 6547 0x00007f2ca8e76f46: mov $0x0,%edi 6548 0x00007f2ca8e76f4b: jne 0x00007f2ca8e76f56 6549 0x00007f2ca8e76f51: mov $0x1,%edi ;*invokevirtual isPrimitive {reexecute=0 rethrow=0 return_oop=0} 6550 ; - java.lang.invoke.MethodTypeForm::canonicalize at 10 (line 263) ------------- and therefore returns true for Klass pointers like 0x900000000. My fix makes the comparison 64bit. Would that be the correct way to fix it? Please note that I am new to the compiler and this is my first fix in c1. At least on my system the fix seems to solve the error, and isPrimitive now uses a 64bit compare, and the test errors are gone: 6544 ;; block B2 [9, 13] 6545 0x00007f7750e76f3f: mov 0x50(%rsi),%rdi ; implicit exception: dispatches to 0x00007f7750e771ec 6546 0x00007f7750e76f43: cmp $0x0,%rdi <<<<< 6547 0x00007f7750e76f47: mov $0x0,%edi 6548 0x00007f7750e76f4c: jne 0x00007f7750e76f57 6549 0x00007f7750e76f52: mov $0x1,%edi ;*invokevirtual isPrimitive {reexecute=0 rethrow=0 return_oop=0} 6550 ; - java.lang.invoke.MethodTypeForm::canonicalize at 10 (line 263) Thanks, Thomas From thomas.stuefe at gmail.com Fri Oct 25 16:32:31 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 25 Oct 2019 18:32:31 +0200 Subject: RFR(xs): java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: References: Message-ID: Just occurred to me that my proposed fix could break non-x86. I have to think this through a bit more. I'd still be thankful for feedback. Cheers, Thomas On Fri, Oct 25, 2019, 16:57 Thomas St?fe wrote: > > Hello, > > Could I please have opinions and reviews for the following fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233019 > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8233019-c1-isprimitive/webrev.00/webrev/ > > > While working with the prototype of the new metaspace allocator > (JDK-8221173), I saw weird errors which looked like > java.lang.Class.isPrimitive() returning sometimes incorrectly true for > boolean[].class, which is not a primitive. > > The bug seems to only happen in c1. > > boolean[].class is the very first Klass* ever to be created in the life of > a VM. For JDK-8221173 I removed metachunk headers from their payload. One > unintended side effect is that the first Klass* is now allocated directly > at the base of class space. If the class space base is aligned to 32bit, > the Klass* for boolean[].class is so too, and all lower 32bits are zero. > > That seems to trigger what I think is a bug in C1, in isPrimitive. There, > the Klass* pointer gets loaded from the mirror, and then compared with zero > (class objects for primitives have no associated Klass*, so isPrimitive() > returns true if that Klass* pointer is NULL). > > But to me it seems that this comparison is done with 32bit cmp: > > ------------- > > 6512 Compiled method (c1) 822 31 1 > java.lang.invoke.MethodTypeForm::canonicalize (233 bytes) > .... > > 6544 ;; block B2 [9, 13] > 6545 0x00007f2ca8e76f3f: mov 0x50(%rsi),%rdi ; > implicit exception: dispatches to 0x00007f2ca8e771ec > 6546 0x00007f2ca8e76f43: cmp $0x0,%edi <<<< 32bit? > 6547 0x00007f2ca8e76f46: mov $0x0,%edi > 6548 0x00007f2ca8e76f4b: jne 0x00007f2ca8e76f56 > 6549 0x00007f2ca8e76f51: mov $0x1,%edi > ;*invokevirtual isPrimitive {reexecute=0 rethrow=0 return_oop=0} > 6550 ; - > java.lang.invoke.MethodTypeForm::canonicalize at 10 (line 263) > > ------------- > > and therefore returns true for Klass pointers like 0x900000000. > > My fix makes the comparison 64bit. > > Would that be the correct way to fix it? Please note that I am new to the > compiler and this is my first fix in c1. > > At least on my system the fix seems to solve the error, and isPrimitive > now uses a 64bit compare, and the test errors are gone: > > 6544 ;; block B2 [9, 13] > 6545 0x00007f7750e76f3f: mov 0x50(%rsi),%rdi ; > implicit exception: dispatches to 0x00007f7750e771ec > 6546 0x00007f7750e76f43: cmp $0x0,%rdi <<<<< > 6547 0x00007f7750e76f47: mov $0x0,%edi > 6548 0x00007f7750e76f4c: jne 0x00007f7750e76f57 > 6549 0x00007f7750e76f52: mov $0x1,%edi > ;*invokevirtual isPrimitive {reexecute=0 rethrow=0 return_oop=0} > 6550 ; - > java.lang.invoke.MethodTypeForm::canonicalize at 10 (line 263) > > > Thanks, Thomas > > From tom.rodriguez at oracle.com Fri Oct 25 17:14:05 2019 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 25 Oct 2019 10:14:05 -0700 Subject: RFR 8233027: OopMapSet::all_do does oms.next() twice during iteration Message-ID: <494aa535-055a-4b23-3cf0-c7f71811f23f@oracle.com> http://cr.openjdk.java.net/~never/8233027/webrev https://bugs.openjdk.java.net/browse/JDK-8233027 The fix for 8232083 introduced an extra next call in the derived pointers code. This removes it. tom From christian.hagedorn at oracle.com Fri Oct 25 17:18:17 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Fri, 25 Oct 2019 19:18:17 +0200 Subject: [14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" In-Reply-To: References: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> Message-ID: Hi Vladimir Thank you for your review! On 24.10.19 18:55, Vladimir Kozlov wrote: > I would like to see what happens with MDO data with Tobias fix which > caused regression. If it is simple. May be from LogCompilation. > The only explanation I can think of if we had only one receiver in MDO > which we cleaned up and it confuse C2 to treat call site as never > executed [3] so that it can't use speculative_receiver_type which come > from other data It was actually my fix. I've tried to come up with a test case where the regression can easily be seen. I found the following example which shows the benefit of not clearing the counter with clear_row(): public void test() { String s = "test"; for (int i = 0; i < 1_000_000; i++ ) { s.replace("e", "t"); // Just a big enough method that does not get inlined by default } } If we use clear_row(), then String::replace is not inlined: org.sample.ClearRow::test @ 5 (27 bytes) made not entrant @ 16 java.lang.String::replace (255 bytes) too big The MDO counter for String::replace is reset to zero. This profile information is passed to ok_to_inline [1] and the zeroed counter is eventually read at [2]. The following frequency check [3] fails and thus InlineTree::should_inline returns false because the method is too big (and wrongly assumed to be never called). However, if we just use set_receiver(row, NULL) instead of clear_row(), which does not reset the counter, then call_site_count is big number greater than zero at [2] and the check at [3] succeeds. The maximum inline size is increased to FreqInlineSize (325 by default). Therefore String::replace is inlined: org.sample.ClearRow::test @ 5 (27 bytes) made not entrant @ 16 java.lang.String::replace (255 bytes) inline (hot) I also quickly put it into a local JMH benchmark. It can clearly be seen that not clearing the counter is beneficial: set_receiver(row, NULL): Benchmark Mode Cnt Score Error Units ClearRow.test thrpt 5 42.810 ? 1.572 ops/s clear_row(): Benchmark Mode Cnt Score Error Units ClearRow.test thrpt 5 32.658 ? 1.267 ops/s There are other cases, for example by using HashMap::put instead, in which call_does_dispatch is true [4]. It then skips directly to your mentioned check at [5]. The check succeeds having a non reset counter and the speculative_receiver_type can be used to inline the method. So I guess we've seen large performance regressions due to many such missed inline opportunities due to lost/wrong profiling information. Best regards, Christian [1] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l171 [2] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l163 [3] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l170 [4] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l167 [5] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l205 From shade at redhat.com Fri Oct 25 17:36:50 2019 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 25 Oct 2019 19:36:50 +0200 Subject: RFR 8233027: OopMapSet::all_do does oms.next() twice during iteration In-Reply-To: <494aa535-055a-4b23-3cf0-c7f71811f23f@oracle.com> References: <494aa535-055a-4b23-3cf0-c7f71811f23f@oracle.com> Message-ID: On 10/25/19 7:14 PM, Tom Rodriguez wrote: > http://cr.openjdk.java.net/~never/8233027/webrev > https://bugs.openjdk.java.net/browse/JDK-8233027 > > The fix for 8232083 introduced an extra next call in the derived pointers code.? This removes it. Looks good. Plus, looks trivial. I have been testing this patch for the last two hours, and it seems to resolve weird, random, intermittent C2/OSR failures we have seen with Shenandoah today. -- Thanks, -Aleksey From vladimir.kozlov at oracle.com Fri Oct 25 18:31:37 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Oct 2019 11:31:37 -0700 Subject: RFR 8233027: OopMapSet::all_do does oms.next() twice during iteration In-Reply-To: References: <494aa535-055a-4b23-3cf0-c7f71811f23f@oracle.com> Message-ID: +1 Please, push at least tier1 testing to confirm that it solves issue and push it. Thanks, Vladimir On 10/25/19 10:36 AM, Aleksey Shipilev wrote: > On 10/25/19 7:14 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/8233027/webrev >> https://bugs.openjdk.java.net/browse/JDK-8233027 >> >> The fix for 8232083 introduced an extra next call in the derived pointers code.? This removes it. > > Looks good. Plus, looks trivial. > > I have been testing this patch for the last two hours, and it seems to resolve weird, random, > intermittent C2/OSR failures we have seen with Shenandoah today. > From dean.long at oracle.com Fri Oct 25 19:53:49 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 25 Oct 2019 12:53:49 -0700 Subject: RFR(xs): java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: References: Message-ID: Hi Thomas.? Does it work if you compare against LIR_OprFact::addressConst(0)? dl On 10/25/19 9:32 AM, Thomas St?fe wrote: > Just occurred to me that my proposed fix could break non-x86. I have to > think this through a bit more. I'd still be thankful for feedback. > > Cheers, Thomas > > On Fri, Oct 25, 2019, 16:57 Thomas St?fe wrote: > >> Hello, >> >> Could I please have opinions and reviews for the following fix. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233019 >> webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/8233019-c1-isprimitive/webrev.00/webrev/ >> >> >> While working with the prototype of the new metaspace allocator >> (JDK-8221173), I saw weird errors which looked like >> java.lang.Class.isPrimitive() returning sometimes incorrectly true for >> boolean[].class, which is not a primitive. >> >> The bug seems to only happen in c1. >> >> boolean[].class is the very first Klass* ever to be created in the life of >> a VM. For JDK-8221173 I removed metachunk headers from their payload. One >> unintended side effect is that the first Klass* is now allocated directly >> at the base of class space. If the class space base is aligned to 32bit, >> the Klass* for boolean[].class is so too, and all lower 32bits are zero. >> >> That seems to trigger what I think is a bug in C1, in isPrimitive. There, >> the Klass* pointer gets loaded from the mirror, and then compared with zero >> (class objects for primitives have no associated Klass*, so isPrimitive() >> returns true if that Klass* pointer is NULL). >> >> But to me it seems that this comparison is done with 32bit cmp: >> >> ------------- >> >> 6512 Compiled method (c1) 822 31 1 >> java.lang.invoke.MethodTypeForm::canonicalize (233 bytes) >> .... >> >> 6544 ;; block B2 [9, 13] >> 6545 0x00007f2ca8e76f3f: mov 0x50(%rsi),%rdi ; >> implicit exception: dispatches to 0x00007f2ca8e771ec >> 6546 0x00007f2ca8e76f43: cmp $0x0,%edi <<<< 32bit? >> 6547 0x00007f2ca8e76f46: mov $0x0,%edi >> 6548 0x00007f2ca8e76f4b: jne 0x00007f2ca8e76f56 >> 6549 0x00007f2ca8e76f51: mov $0x1,%edi >> ;*invokevirtual isPrimitive {reexecute=0 rethrow=0 return_oop=0} >> 6550 ; - >> java.lang.invoke.MethodTypeForm::canonicalize at 10 (line 263) >> >> ------------- >> >> and therefore returns true for Klass pointers like 0x900000000. >> >> My fix makes the comparison 64bit. >> >> Would that be the correct way to fix it? Please note that I am new to the >> compiler and this is my first fix in c1. >> >> At least on my system the fix seems to solve the error, and isPrimitive >> now uses a 64bit compare, and the test errors are gone: >> >> 6544 ;; block B2 [9, 13] >> 6545 0x00007f7750e76f3f: mov 0x50(%rsi),%rdi ; >> implicit exception: dispatches to 0x00007f7750e771ec >> 6546 0x00007f7750e76f43: cmp $0x0,%rdi <<<<< >> 6547 0x00007f7750e76f47: mov $0x0,%edi >> 6548 0x00007f7750e76f4c: jne 0x00007f7750e76f57 >> 6549 0x00007f7750e76f52: mov $0x1,%edi >> ;*invokevirtual isPrimitive {reexecute=0 rethrow=0 return_oop=0} >> 6550 ; - >> java.lang.invoke.MethodTypeForm::canonicalize at 10 (line 263) >> >> >> Thanks, Thomas >> >> From kim.barrett at oracle.com Fri Oct 25 20:05:16 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Fri, 25 Oct 2019 16:05:16 -0400 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> Message-ID: <05D534DD-9003-416C-BA15-3795EDAC6E18@oracle.com> > On Oct 23, 2019, at 10:47 AM, Doerr, Martin wrote: > > Hi Kim, Note This isn't code that I'm familiar with, nor do I really want to spend the time to become so right now, e.g. don't count me as any kind of reviewer in this thread right now. I'm just here because of the questions about JNIHandles / OopStorage usage. > I didn't like using the OopStorage stuff directly, either. I just have not seen how to allocate a global handle and add the oop later. That's not a supported usage model. It hasn't been needed, and might not even be possible to support within the concurrency requirements for OopStorage. (I don't actually know whether it's possible now. I'm pretty sure it wasn't in some of the prototypes.) And I don't think it is needed or helpful with the problem at hand either. > Thanks for pointing me to JVMCI::make_global. I was not aware of that. > > So I can imagine 3 ways to implement it: > > 1. Use JNIHandles::destroy_global to release the handles. I just added that to > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.01/ > We may want to improve that further by setting the handle pointer to NULL and asserting that it is NULL before adding the new one. > I had been concerned about NULLs in the array, but looks like the existing code can deal with that. I think it's weird that can_remove() is a predicate with optional side effects. I think it would be simpler to have it be a pure predicate, and have the one caller with do_it = true perform the updates. That should include NULLing out the handle pointer (perhaps debug-only, but it doesn't cost much to cleanly maintain the data structure). But regardless of that possible refactoring, I don't see how this can work. 934 if (!THREAD->can_call_java()) break; So far as I can tell, THREAD == NULL here. I also think that here: 947 jobject thread_handle = JNIHandles::make_global(thread_oop); 948 _compiler2_objects[i] = thread_handle; should assert _compiler2_objects[i] == NULL. Or if that isn't a valid assertion then I think there are other problems. > 2. Use JVMCI::make_global, keep the handles and replace the j.t.Thread objects. Changed in place: > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.02/ > > JMVCI::make_global uses OopStorageSet::vm_global instead of jni_global. No clue if this is better or worse. The separation between the JNIHandles oopstorages and the vm_global / vm_weak oopstorages exists to make it a bit less trivial for native code to use JNI facilities to corrupt VM-internal data structures. It's unfortunate for that purpose that JVMCI uses jobject though. > But seems like JMVCI::make_global still doesn't like NULL handles in slowdebug build ?? > assert(oopDesc::is_oop(obj()), "not an oop?); JVMCI::make/destroy_global expect to be used with actual oops, and don't provide the NULL oop => NULL jobject mechanism provided by JNIHandles. > 3. Just use the possibly_add_compiler_threads part of webrev.02 and leave the initialization as is. > This means we create j.l.Thread objects initially and replace them by new ones when the JVMCI threads get started. I'd be ok with this, too. > > > Sorry for the in-place updates, but so many webrevs would confuse me after some time. From vladimir.kozlov at oracle.com Fri Oct 25 22:12:24 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Oct 2019 15:12:24 -0700 Subject: [14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" In-Reply-To: References: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> Message-ID: <0635964f-a093-074c-58d5-c4ce76703db5@oracle.com> Yes, that is what I suspected. MDO had only one receiver and if we clean counter it will look like it is never called. clear_row() assumes that at least one receiver is valid. Hmm, but if the class is unloaded when we construct copy of MDO then this compilation is invalid anyway. Right? You need to get new profiling information after unloading to get correct MDO. If one klass in MDO call site is still valid we can still compile and have uncommon trap for second case. But if no valid klass is recorded in MDO call site (all were nulled) we can't compile it based on counter. We should bailout and re-collect profiling info or generate uncommon trap instead of call. For later we have to separate cases when the site is never called or it was called but classes later were unloaded. hmm, C2 actually should generate uncommon trap if class is unloaded. Why classes are unloaded in a first place? Can you tell why class is unloaded in your test case? It is String!!! Or more accurate why clear_row() was called? Thanks, Vladimir On 10/25/19 10:18 AM, Christian Hagedorn wrote: > Hi Vladimir > > Thank you for your review! > > On 24.10.19 18:55, Vladimir Kozlov wrote: >> I would like to see what happens with MDO data with Tobias fix which caused regression. If it is simple. May be from >> LogCompilation. > >> The only explanation I can think of if we had only one receiver in MDO which we cleaned up and it confuse C2 to treat >> call site as never executed [3] so that it can't use speculative_receiver_type which come from other data > It was actually my fix. I've tried to come up with a test case where the regression can easily be seen. I found the > following example which shows the benefit of not clearing the counter with clear_row(): > > ??? public void test() { > ??????? String s = "test"; > ??????? for (int i = 0; i < 1_000_000; i++ ) { > ??????????? s.replace("e", "t"); // Just a big enough method that does not get inlined by default > ??????? } > ??? } > > If we use clear_row(), then String::replace is not inlined: > > org.sample.ClearRow::test @ 5 (27 bytes)?? made not entrant > ? @ 16?? java.lang.String::replace (255 bytes)?? too big > > The MDO counter for String::replace is reset to zero. This profile information is passed to ok_to_inline [1] and the > zeroed counter is eventually read at [2]. The following frequency check [3] fails and thus InlineTree::should_inline > returns false because the method is too big (and wrongly assumed to be never called). > > However, if we just use set_receiver(row, NULL) instead of clear_row(), which does not reset the counter, then > call_site_count is big number greater than zero at [2] and the check at [3] succeeds. The maximum inline size is > increased to FreqInlineSize (325 by default). Therefore String::replace is inlined: > > org.sample.ClearRow::test @ 5 (27 bytes)?? made not entrant > ? @ 16?? java.lang.String::replace (255 bytes)?? inline (hot) > > > I also quickly put it into a local JMH benchmark. It can clearly be seen that not clearing the counter is beneficial: > > set_receiver(row, NULL): > Benchmark?????? Mode? Cnt?? Score?? Error? Units > ClearRow.test? thrpt??? 5? 42.810 ? 1.572? ops/s > > clear_row(): > Benchmark?????? Mode? Cnt?? Score?? Error? Units > ClearRow.test? thrpt??? 5? 32.658 ? 1.267? ops/s > > > There are other cases, for example by using HashMap::put instead, in which call_does_dispatch is true [4]. It then skips > directly to your mentioned check at [5]. The check succeeds having a non reset counter and the speculative_receiver_type > can be used to inline the method. > > > So I guess we've seen large performance regressions due to many such missed inline opportunities due to lost/wrong > profiling information. > > Best regards, > Christian > > > [1] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l171 > [2] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l163 > [3] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l170 > [4] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l167 > [5] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l205 From vladimir.kozlov at oracle.com Fri Oct 25 23:56:24 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 25 Oct 2019 16:56:24 -0700 Subject: [14] RFR(M) 8232904: Update JVMCI Message-ID: https://cr.openjdk.java.net/~kvn/8233035/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8233035 Sync JVMCI changes from labsjdk-11 repo which are not in graal-jvmci-8. [PATCH 17] fixed checkstyle and Eclipse issues, synced some tests from jvmci-8 [PATCH 22] do not intrinsify methods loaded by the app class loader [PATCH 23] handle other case in findUniqueConcreteMethod where the method can be statically bound [PATCH 26] pass saved system properties to JVMCI shared library [PATCH 55] Sync some missing VirtualObject changes Tested tier1-2, hs-tier3-graal Thanks, Vladimir From thomas.stuefe at gmail.com Sat Oct 26 07:10:38 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 26 Oct 2019 09:10:38 +0200 Subject: RFR(xs): java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: References: Message-ID: Hi Dean, Yes, that might be clearer. I probably still would have to fix up LIR_Assembler::comp_op() for more than just x86, since most would not work for comparisons with T_ADDRESS constants. There are still a lot of tiny things I do not understand about the c1 coding, e.g. why addressConst() takes only a 32bit number. Or what "single_cpu" and "double_cpu" means for LIR operands. I have to study this code a bit more. So I withdraw this patch and will come up with a better one later. Thank you, Thomas On Fri, Oct 25, 2019 at 9:54 PM wrote: > Hi Thomas. Does it work if you compare against > LIR_OprFact::addressConst(0)? > > dl > > On 10/25/19 9:32 AM, Thomas St?fe wrote: > > Just occurred to me that my proposed fix could break non-x86. I have to > > think this through a bit more. I'd still be thankful for feedback. > > > > Cheers, Thomas > > > > On Fri, Oct 25, 2019, 16:57 Thomas St?fe > wrote: > > > >> Hello, > >> > >> Could I please have opinions and reviews for the following fix. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8233019 > >> webrev: > >> > http://cr.openjdk.java.net/~stuefe/webrevs/8233019-c1-isprimitive/webrev.00/webrev/ > >> > >> > >> While working with the prototype of the new metaspace allocator > >> (JDK-8221173), I saw weird errors which looked like > >> java.lang.Class.isPrimitive() returning sometimes incorrectly true for > >> boolean[].class, which is not a primitive. > >> > >> The bug seems to only happen in c1. > >> > >> boolean[].class is the very first Klass* ever to be created in the life > of > >> a VM. For JDK-8221173 I removed metachunk headers from their payload. > One > >> unintended side effect is that the first Klass* is now allocated > directly > >> at the base of class space. If the class space base is aligned to 32bit, > >> the Klass* for boolean[].class is so too, and all lower 32bits are zero. > >> > >> That seems to trigger what I think is a bug in C1, in isPrimitive. > There, > >> the Klass* pointer gets loaded from the mirror, and then compared with > zero > >> (class objects for primitives have no associated Klass*, so > isPrimitive() > >> returns true if that Klass* pointer is NULL). > >> > >> But to me it seems that this comparison is done with 32bit cmp: > >> > >> ------------- > >> > >> 6512 Compiled method (c1) 822 31 1 > >> java.lang.invoke.MethodTypeForm::canonicalize (233 bytes) > >> .... > >> > >> 6544 ;; block B2 [9, 13] > >> 6545 0x00007f2ca8e76f3f: mov 0x50(%rsi),%rdi ; > >> implicit exception: dispatches to 0x00007f2ca8e771ec > >> 6546 0x00007f2ca8e76f43: cmp $0x0,%edi <<<< 32bit? > >> 6547 0x00007f2ca8e76f46: mov $0x0,%edi > >> 6548 0x00007f2ca8e76f4b: jne 0x00007f2ca8e76f56 > >> 6549 0x00007f2ca8e76f51: mov $0x1,%edi > >> ;*invokevirtual isPrimitive {reexecute=0 rethrow=0 return_oop=0} > >> 6550 ; - > >> java.lang.invoke.MethodTypeForm::canonicalize at 10 (line 263) > >> > >> ------------- > >> > >> and therefore returns true for Klass pointers like 0x900000000. > >> > >> My fix makes the comparison 64bit. > >> > >> Would that be the correct way to fix it? Please note that I am new to > the > >> compiler and this is my first fix in c1. > >> > >> At least on my system the fix seems to solve the error, and isPrimitive > >> now uses a 64bit compare, and the test errors are gone: > >> > >> 6544 ;; block B2 [9, 13] > >> 6545 0x00007f7750e76f3f: mov 0x50(%rsi),%rdi ; > >> implicit exception: dispatches to 0x00007f7750e771ec > >> 6546 0x00007f7750e76f43: cmp $0x0,%rdi <<<<< > >> 6547 0x00007f7750e76f47: mov $0x0,%edi > >> 6548 0x00007f7750e76f4c: jne 0x00007f7750e76f57 > >> 6549 0x00007f7750e76f52: mov $0x1,%edi > >> ;*invokevirtual isPrimitive {reexecute=0 rethrow=0 return_oop=0} > >> 6550 ; - > >> java.lang.invoke.MethodTypeForm::canonicalize at 10 (line 263) > >> > >> > >> Thanks, Thomas > >> > >> > > From david.holmes at oracle.com Sun Oct 27 22:04:12 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Oct 2019 08:04:12 +1000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> Message-ID: <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> On 24/10/2019 12:47 am, Doerr, Martin wrote: > Hi Kim, > > I didn't like using the OopStorage stuff directly, either. I just have not seen how to allocate a global handle and add the oop later. > > Thanks for pointing me to JVMCI::make_global. I was not aware of that. > > So I can imagine 3 ways to implement it: > > 1. Use JNIHandles::destroy_global to release the handles. I just added that to > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.01/ > We may want to improve that further by setting the handle pointer to NULL and asserting that it is NULL before adding the new one. > I had been concerned about NULLs in the array, but looks like the existing code can deal with that. I think it would be cleaner to both destroy the global handle and NULL it in the array at the same time. This comment 325 // Old j.l.Thread object can die here. Isn't quite accurate. The j.l.Thread is still referenced via ct->threadObj() so can't "die" until that is also cleared during the actual termination process. The use of the CHECK macro at existing places in possibly_add_compilerthreads still needs to be fixed. The correct exception handling in your new code just highlights the deficiency of the existing code. > 2. Use JVMCI::make_global, keep the handles and replace the j.t.Thread objects. Changed in place: > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.02/ > > JMVCI::make_global uses OopStorageSet::vm_global instead of jni_global. No clue if this is better or worse. > > But seems like JMVCI::make_global still doesn't like NULL handles in slowdebug build ?? > assert(oopDesc::is_oop(obj()), "not an oop"); I don't see how this code is an improvement on anything. It duplicates some existing code as JVMCI threads now have to "make global" in a different way; and it still directly uses NativeAccess<>::oop_store which breaks encapsulation. > 3. Just use the possibly_add_compiler_threads part of webrev.02 and leave the initialization as is. > This means we create j.l.Thread objects initially and replace them by new ones when the JVMCI threads get started. I'd be ok with this, too. I much prefer simple direct use of JNIHandles::destroy_global as per version 1 above. Thanks, David ------ > > Sorry for the in-place updates, but so many webrevs would confuse me after some time. > > > Best regards, > Martin > > >> -----Original Message----- >> From: Kim Barrett >> Sent: Mittwoch, 23. Oktober 2019 02:25 >> To: Doerr, Martin >> Cc: David Holmes ; Vladimir Kozlov >> (vladimir.kozlov at oracle.com) ; hotspot- >> compiler-dev at openjdk.java.net >> Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread >> >>> On Oct 22, 2019, at 9:18 AM, Doerr, Martin >> wrote: >>>> Sorry I don't follow. The initial Handle stored in the array was a >>>> global handle. You just allocated a second global Handle. I don't see >>>> any operator=() magic happening here to free one of those global >>>> handles, so AFAICS you need to free one of them. >>> >>> Sorry. I had implemented it differently than I wanted. Thanks for pointing >> me to it. >>> >>> Fixed: >>> >> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr >> ev.02/ >> >> Please don't do that. That's basically smashing through the JNHHandles >> abstraction and writing a bunch of (lower level and tightly coupled) >> code for no good reason. Just use JNIHandles::make_global and >> JNHHandles::destroy_global as David suggested. >> >> (Note that JNIHandles::make_global takes an AllocFailType argument; if >> you aren't going to handle allocation failure (e.g. are just going to >> call vm_exit_out_of_memory, as in webrev.02) the default will deal >> with that for you.) >> >> Alternatively, can you use JVMCI::make_global and JVMCI::destroy_global >> here? Perhaps not, if some of this code is !UseJVMCICompiler or whatever. >> That's kind of unfortunate. (It's also unfortunate that those functions >> deal with jobject, but that's a different problem.) >> > From kim.barrett at oracle.com Mon Oct 28 03:42:43 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Sun, 27 Oct 2019 23:42:43 -0400 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> Message-ID: > On Oct 27, 2019, at 6:04 PM, David Holmes wrote: > > On 24/10/2019 12:47 am, Doerr, Martin wrote: >> Hi Kim, >> I didn't like using the OopStorage stuff directly, either. I just have not seen how to allocate a global handle and add the oop later. >> Thanks for pointing me to JVMCI::make_global. I was not aware of that. >> So I can imagine 3 ways to implement it: >> 1. Use JNIHandles::destroy_global to release the handles. I just added that to >> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.01/ >> We may want to improve that further by setting the handle pointer to NULL and asserting that it is NULL before adding the new one. >> I had been concerned about NULLs in the array, but looks like the existing code can deal with that. > > I think it would be cleaner to both destroy the global handle and NULL it in the array at the same time. > > This comment > > 325 // Old j.l.Thread object can die here. > > Isn't quite accurate. The j.l.Thread is still referenced via ct->threadObj() so can't "die" until that is also cleared during the actual termination process. I think if there is such a thread here that it can't die, because the death predicate (the can_remove stuff) won't see that old thread as the last thread in _compiler2_objects. That's what I meant by this: > On Oct 25, 2019, at 4:05 PM, Kim Barrett wrote: > I also think that here: > > 947 jobject thread_handle = JNIHandles::make_global(thread_oop); > 948 _compiler2_objects[i] = thread_handle; > > should assert _compiler2_objects[i] == NULL. Or if that isn't a valid > assertion then I think there are other problems. I think either that comment about an old thread is wrong (and the NULL assertion I suggested is okay), or I think the whole mechanism here has problems. Or at least I was unable to figure out how it could work... From david.holmes at oracle.com Mon Oct 28 04:04:09 2019 From: david.holmes at oracle.com (David Holmes) Date: Mon, 28 Oct 2019 14:04:09 +1000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> Message-ID: <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> On 28/10/2019 1:42 pm, Kim Barrett wrote: >> On Oct 27, 2019, at 6:04 PM, David Holmes wrote: >> >> On 24/10/2019 12:47 am, Doerr, Martin wrote: >>> Hi Kim, >>> I didn't like using the OopStorage stuff directly, either. I just have not seen how to allocate a global handle and add the oop later. >>> Thanks for pointing me to JVMCI::make_global. I was not aware of that. >>> So I can imagine 3 ways to implement it: >>> 1. Use JNIHandles::destroy_global to release the handles. I just added that to >>> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.01/ >>> We may want to improve that further by setting the handle pointer to NULL and asserting that it is NULL before adding the new one. >>> I had been concerned about NULLs in the array, but looks like the existing code can deal with that. >> >> I think it would be cleaner to both destroy the global handle and NULL it in the array at the same time. >> >> This comment >> >> 325 // Old j.l.Thread object can die here. >> >> Isn't quite accurate. The j.l.Thread is still referenced via ct->threadObj() so can't "die" until that is also cleared during the actual termination process. > > I think if there is such a thread here that it can't die, because the > death predicate (the can_remove stuff) won't see that old thread as > the last thread in _compiler2_objects. That's what I meant by this: > >> On Oct 25, 2019, at 4:05 PM, Kim Barrett wrote: >> I also think that here: >> >> 947 jobject thread_handle = JNIHandles::make_global(thread_oop); >> 948 _compiler2_objects[i] = thread_handle; >> >> should assert _compiler2_objects[i] == NULL. Or if that isn't a valid >> assertion then I think there are other problems. > > I think either that comment about an old thread is wrong (and the NULL > assertion I suggested is okay), or I think the whole mechanism here > has problems. Or at least I was unable to figure out how it could work... > I'm not following sorry. You can't assert NULL unless it's actually set to NULL which it presently isn't. But it could be set NULL as Martin suggested: "We may want to improve that further by setting the handle pointer to NULL and asserting that it is NULL before adding the new one." and which I also supported. But that aside once the delete_global has been called that JNIHandle no longer references the j.l.Thread that it did, at which point it is only reachable via the threadObj() of the CompilerThread. David From Pengfei.Li at arm.com Mon Oct 28 09:48:31 2019 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Mon, 28 Oct 2019 09:48:31 +0000 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> Message-ID: Hi, > > Yes, I think so. It's enough to make sure that the corner cases and > > overflows are handled correctly. We have to be sure that we really are > > generating the correct instructions. Thanks. > > By the way, I also checked with this Case: > > new Case(0xffffffff, 0xffffffff, 0xffffffffeL << 32, 0xfffffffe00000001L, > 0xfffffffdffffffffL, -1L), > > which tests the carries frm highpart to lowpart. > (It's the result of 0xffffffff * 0xffffffff == 0xfffffffe00000001.) Thanks for review. I've appended this case in my jtreg. See updated webrev: http://cr.openjdk.java.net/~pli/rfr/8232591/webrev.02/ Is another reviewer required for this change? If not, @Ningsheng Jian (Arm Technology China) could you help to push? -- Thanks, Pengfei From christian.hagedorn at oracle.com Mon Oct 28 10:38:30 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Mon, 28 Oct 2019 11:38:30 +0100 Subject: [14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" In-Reply-To: <0635964f-a093-074c-58d5-c4ce76703db5@oracle.com> References: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> <0635964f-a093-074c-58d5-c4ce76703db5@oracle.com> Message-ID: <677e34c5-ff1f-aac1-efca-84c6f30c2c9b@oracle.com> Hi Vladimir I don't think that the String class is unloaded. In the previous fix [6] I called clear_row() if either the klass 'k' was NULL or it was unloaded. This means that in my test case the MDO contains the String klass at row index 0 but the index 1 is empty, i.e. the klass is NULL. As a result, I cleared that counter with clear_row() by mistake when processing the row index 1 (since 'k' is NULL). My new fix will only set the klass to NULL with set_receiver(row, NULL) and will not clear the counter anymore. In my evaluation below I compared the previous fix [6] with my new fix. Best regards, Christian [6] http://cr.openjdk.java.net/~thartmann/8225670/webrev.00/ On 26.10.19 00:12, Vladimir Kozlov wrote: > Yes, that is what I suspected. MDO had only one receiver and if we clean > counter it will look like it is never called. > clear_row() assumes that at least one receiver is valid. > > Hmm, but if the class is unloaded when we construct copy of MDO then > this compilation is invalid anyway. Right? You need to get new profiling > information after unloading to get correct MDO. > > If one klass in MDO call site is still valid we can still compile and > have uncommon trap for second case. But if no valid klass is recorded in > MDO call site (all were nulled) we can't compile it based on counter. We > should bailout and re-collect profiling info or generate uncommon trap > instead of call. For later we have to separate cases when the site is > never called or it was called but classes later were unloaded. hmm, C2 > actually should generate uncommon trap if class is unloaded. Why classes > are unloaded in a first place? > > Can you tell why class is unloaded in your test case? It is String!!! Or > more accurate why clear_row() was called? > > Thanks, > Vladimir > > On 10/25/19 10:18 AM, Christian Hagedorn wrote: >> Hi Vladimir >> >> Thank you for your review! >> >> On 24.10.19 18:55, Vladimir Kozlov wrote: >>> I would like to see what happens with MDO data with Tobias fix which >>> caused regression. If it is simple. May be from LogCompilation. >> >>> The only explanation I can think of if we had only one receiver in >>> MDO which we cleaned up and it confuse C2 to treat call site as never >>> executed [3] so that it can't use speculative_receiver_type which >>> come from other data >> It was actually my fix. I've tried to come up with a test case where >> the regression can easily be seen. I found the following example which >> shows the benefit of not clearing the counter with clear_row(): >> >> ???? public void test() { >> ???????? String s = "test"; >> ???????? for (int i = 0; i < 1_000_000; i++ ) { >> ???????????? s.replace("e", "t"); // Just a big enough method that >> does not get inlined by default >> ???????? } >> ???? } >> >> If we use clear_row(), then String::replace is not inlined: >> >> org.sample.ClearRow::test @ 5 (27 bytes)?? made not entrant >> ?? @ 16?? java.lang.String::replace (255 bytes)?? too big >> >> The MDO counter for String::replace is reset to zero. This profile >> information is passed to ok_to_inline [1] and the zeroed counter is >> eventually read at [2]. The following frequency check [3] fails and >> thus InlineTree::should_inline returns false because the method is too >> big (and wrongly assumed to be never called). >> >> However, if we just use set_receiver(row, NULL) instead of >> clear_row(), which does not reset the counter, then call_site_count is >> big number greater than zero at [2] and the check at [3] succeeds. The >> maximum inline size is increased to FreqInlineSize (325 by default). >> Therefore String::replace is inlined: >> >> org.sample.ClearRow::test @ 5 (27 bytes)?? made not entrant >> ?? @ 16?? java.lang.String::replace (255 bytes)?? inline (hot) >> >> >> I also quickly put it into a local JMH benchmark. It can clearly be >> seen that not clearing the counter is beneficial: >> >> set_receiver(row, NULL): >> Benchmark?????? Mode? Cnt?? Score?? Error? Units >> ClearRow.test? thrpt??? 5? 42.810 ? 1.572? ops/s >> >> clear_row(): >> Benchmark?????? Mode? Cnt?? Score?? Error? Units >> ClearRow.test? thrpt??? 5? 32.658 ? 1.267? ops/s >> >> >> There are other cases, for example by using HashMap::put instead, in >> which call_does_dispatch is true [4]. It then skips directly to your >> mentioned check at [5]. The check succeeds having a non reset counter >> and the speculative_receiver_type can be used to inline the method. >> >> >> So I guess we've seen large performance regressions due to many such >> missed inline opportunities due to lost/wrong profiling information. >> >> Best regards, >> Christian >> >> >> [1] >> http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l171 >> >> [2] >> http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l163 >> >> [3] >> http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l170 >> >> [4] >> http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l167 >> >> [5] >> http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l205 >> From martin.doerr at sap.com Mon Oct 28 14:06:31 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 28 Oct 2019 14:06:31 +0000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> Message-ID: Hi David and Kim, I think it's easier to talk about code. So here's a new webrev: http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.03/ @Kim: Thanks for looking at the handle related parts. It's ok if you don't want to be a reviewer of the whole change. > I think it's weird that can_remove() is a predicate with optional side > effects. I think it would be simpler to have it be a pure predicate, > and have the one caller with do_it = true perform the updates. That > should include NULLing out the handle pointer (perhaps debug-only, but > it doesn't cost much to cleanly maintain the data structure). Nevertheless, it has the advantage that it enforces the update to be consistent. A caller could use it without holding the lock or mess it up otherwise. In addition, I don't what to change that as part of this fix. > So far as I can tell, THREAD == NULL here. This is a very tricky part (not my invention): EXCEPTION_MARK contains an ExceptionMark constructor call which sets __the_thread__ to Thread::current(). I don't want to publish my opinion about this ?? @David: Seems like this option is preferred over option 3 (possibly_add_compiler_threads part of webrev.02 and leave the initialization as is). So when you're ok with it, I'll request a 2nd review from the compiler folks (I should change the subject to contain RFR). Thanks, Martin > -----Original Message----- > From: David Holmes > Sent: Montag, 28. Oktober 2019 05:04 > To: Kim Barrett > Cc: Doerr, Martin ; Vladimir Kozlov > (vladimir.kozlov at oracle.com) ; hotspot- > compiler-dev at openjdk.java.net > Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread > > On 28/10/2019 1:42 pm, Kim Barrett wrote: > >> On Oct 27, 2019, at 6:04 PM, David Holmes > wrote: > >> > >> On 24/10/2019 12:47 am, Doerr, Martin wrote: > >>> Hi Kim, > >>> I didn't like using the OopStorage stuff directly, either. I just have not > seen how to allocate a global handle and add the oop later. > >>> Thanks for pointing me to JVMCI::make_global. I was not aware of that. > >>> So I can imagine 3 ways to implement it: > >>> 1. Use JNIHandles::destroy_global to release the handles. I just added > that to > >>> > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr > ev.01/ > >>> We may want to improve that further by setting the handle pointer to > NULL and asserting that it is NULL before adding the new one. > >>> I had been concerned about NULLs in the array, but looks like the > existing code can deal with that. > >> > >> I think it would be cleaner to both destroy the global handle and NULL it in > the array at the same time. > >> > >> This comment > >> > >> 325 // Old j.l.Thread object can die here. > >> > >> Isn't quite accurate. The j.l.Thread is still referenced via ct->threadObj() so > can't "die" until that is also cleared during the actual termination process. > > > > I think if there is such a thread here that it can't die, because the > > death predicate (the can_remove stuff) won't see that old thread as > > the last thread in _compiler2_objects. That's what I meant by this: > > > >> On Oct 25, 2019, at 4:05 PM, Kim Barrett > wrote: > >> I also think that here: > >> > >> 947 jobject thread_handle = JNIHandles::make_global(thread_oop); > >> 948 _compiler2_objects[i] = thread_handle; > >> > >> should assert _compiler2_objects[i] == NULL. Or if that isn't a valid > >> assertion then I think there are other problems. > > > > I think either that comment about an old thread is wrong (and the NULL > > assertion I suggested is okay), or I think the whole mechanism here > > has problems. Or at least I was unable to figure out how it could work... > > > > I'm not following sorry. You can't assert NULL unless it's actually set > to NULL which it presently isn't. But it could be set NULL as Martin > suggested: > > "We may want to improve that further by setting the handle pointer to > NULL and asserting that it is NULL before adding the new one." > > and which I also supported. But that aside once the delete_global has > been called that JNIHandle no longer references the j.l.Thread that it > did, at which point it is only reachable via the threadObj() of the > CompilerThread. > > David From vladimir.kozlov at oracle.com Mon Oct 28 15:26:10 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Oct 2019 08:26:10 -0700 Subject: [14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" In-Reply-To: <677e34c5-ff1f-aac1-efca-84c6f30c2c9b@oracle.com> References: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> <0635964f-a093-074c-58d5-c4ce76703db5@oracle.com> <677e34c5-ff1f-aac1-efca-84c6f30c2c9b@oracle.com> Message-ID: <4F9B6AED-C8C7-48EA-BB14-1B086E13D890@oracle.com> Okay, now I got it what was wrong with previous fix. Thank you for explaining. The current fix is good. Thanks Vladimir > On Oct 28, 2019, at 3:38 AM, Christian Hagedorn wrote: > > Hi Vladimir > > I don't think that the String class is unloaded. In the previous fix [6] I called clear_row() if either the klass 'k' was NULL or it was unloaded. This means that in my test case the MDO contains the String klass at row index 0 but the index 1 is empty, i.e. the klass is NULL. As a result, I cleared that counter with clear_row() by mistake when processing the row index 1 (since 'k' is NULL). My new fix will only set the klass to NULL with set_receiver(row, NULL) and will not clear the counter anymore. In my evaluation below I compared the previous fix [6] with my new fix. > > Best regards, > Christian > > [6] http://cr.openjdk.java.net/~thartmann/8225670/webrev.00/ > >> On 26.10.19 00:12, Vladimir Kozlov wrote: >> Yes, that is what I suspected. MDO had only one receiver and if we clean counter it will look like it is never called. >> clear_row() assumes that at least one receiver is valid. >> Hmm, but if the class is unloaded when we construct copy of MDO then this compilation is invalid anyway. Right? You need to get new profiling information after unloading to get correct MDO. >> If one klass in MDO call site is still valid we can still compile and have uncommon trap for second case. But if no valid klass is recorded in MDO call site (all were nulled) we can't compile it based on counter. We should bailout and re-collect profiling info or generate uncommon trap instead of call. For later we have to separate cases when the site is never called or it was called but classes later were unloaded. hmm, C2 actually should generate uncommon trap if class is unloaded. Why classes are unloaded in a first place? >> Can you tell why class is unloaded in your test case? It is String!!! Or more accurate why clear_row() was called? >> Thanks, >> Vladimir >>> On 10/25/19 10:18 AM, Christian Hagedorn wrote: >>> Hi Vladimir >>> >>> Thank you for your review! >>> >>>> On 24.10.19 18:55, Vladimir Kozlov wrote: >>>> I would like to see what happens with MDO data with Tobias fix which caused regression. If it is simple. May be from LogCompilation. >>> >>>> The only explanation I can think of if we had only one receiver in MDO which we cleaned up and it confuse C2 to treat call site as never executed [3] so that it can't use speculative_receiver_type which come from other data >>> It was actually my fix. I've tried to come up with a test case where the regression can easily be seen. I found the following example which shows the benefit of not clearing the counter with clear_row(): >>> >>> public void test() { >>> String s = "test"; >>> for (int i = 0; i < 1_000_000; i++ ) { >>> s.replace("e", "t"); // Just a big enough method that does not get inlined by default >>> } >>> } >>> >>> If we use clear_row(), then String::replace is not inlined: >>> >>> org.sample.ClearRow::test @ 5 (27 bytes) made not entrant >>> @ 16 java.lang.String::replace (255 bytes) too big >>> >>> The MDO counter for String::replace is reset to zero. This profile information is passed to ok_to_inline [1] and the zeroed counter is eventually read at [2]. The following frequency check [3] fails and thus InlineTree::should_inline returns false because the method is too big (and wrongly assumed to be never called). >>> >>> However, if we just use set_receiver(row, NULL) instead of clear_row(), which does not reset the counter, then call_site_count is big number greater than zero at [2] and the check at [3] succeeds. The maximum inline size is increased to FreqInlineSize (325 by default). Therefore String::replace is inlined: >>> >>> org.sample.ClearRow::test @ 5 (27 bytes) made not entrant >>> @ 16 java.lang.String::replace (255 bytes) inline (hot) >>> >>> >>> I also quickly put it into a local JMH benchmark. It can clearly be seen that not clearing the counter is beneficial: >>> >>> set_receiver(row, NULL): >>> Benchmark Mode Cnt Score Error Units >>> ClearRow.test thrpt 5 42.810 ? 1.572 ops/s >>> >>> clear_row(): >>> Benchmark Mode Cnt Score Error Units >>> ClearRow.test thrpt 5 32.658 ? 1.267 ops/s >>> >>> >>> There are other cases, for example by using HashMap::put instead, in which call_does_dispatch is true [4]. It then skips directly to your mentioned check at [5]. The check succeeds having a non reset counter and the speculative_receiver_type can be used to inline the method. >>> >>> >>> So I guess we've seen large performance regressions due to many such missed inline opportunities due to lost/wrong profiling information. >>> >>> Best regards, >>> Christian >>> >>> >>> [1] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l171 >>> [2] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l163 >>> [3] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l170 >>> [4] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l167 >>> [5] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l205 From bob.vandette at oracle.com Mon Oct 28 15:37:02 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 28 Oct 2019 11:37:02 -0400 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: <860FAE8F-579A-4DE9-9862-AA0A4B20B4E7@oracle.com> References: <860FAE8F-579A-4DE9-9862-AA0A4B20B4E7@oracle.com> Message-ID: <7D29EA36-465A-4905-A714-D48C1A3849AD@oracle.com> > On Oct 25, 2019, at 6:57 AM, Doug Simon wrote: > > > >> On 25 Oct 2019, at 02:06, David Holmes wrote: >> >> On 25/10/2019 1:27 am, Bob Vandette wrote: >>> Thanks for the review. See comments below. >>> Updated webrev: http://cr.openjdk.java.net/~bobv/8232118/webrev.02 >> >> That all seems fine. >> >> Minor nit in arguments.cpp: >> >> + "Unable to enable jvmci in product mode"); >> >> s/jvmci/JVMCI/ >> >> One follow up ... you don't modify all of the JVMCI flags. The following are omitted: >> >> BootstrapJVMCI >> JVMCIHostThreads >> JVMCITraceLevel >> MethodProfileWidth >> PrintBootstrap > > These are all diagnostic flags. Bob, can EnableJVMCIProduct make them into actual diagnostic flags? If they are really diagnostic flags, then they should be declared that way. Leaving them as is still allows you to use them, they just need to be unlocked with the Experimental flag. I?d prefer leaving leave them alone and let the compiler team decide what they want to do if/when JVMCI is no longer experimental. Bob. > > -Doug > >> >> >>>> On Oct 24, 2019, at 1:22 AM, David Holmes > wrote: >>>> >>>> Hi Bob, >>>> >>>> On 24/10/2019 1:13 am, Bob Vandette wrote: >>>>> Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, >>>>> and alter a collection of JVM options to be product flags rather than experimental flags. >>>>> EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. >>>> >>>> Okay, so there are few things happening here so let me step through them. The desire is to enable an experimental compiler by default, but not have to run with all experimental options unlocked (which I assume is just to try and protect the end user from their own mistakes?). So the way this would work is that the command-line would effectively be: >>>> >>>> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts --XX:-UnlockExperimentalVMOptions >>>> >>>> when EnableJVMCIProducts is processed (and is true) it will force on a couple of key JVMCI related flags, and it will turn off the flag-is-experimental bit on all the JVMCI flags. The latter being desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in play, all those other JVMCI flags would be hidden and you want them to be visible to introspection (like JVM TI, Dcmd) - is that correct? >>> Yes, that?s correct. >>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 >>>>> WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 >>>> >>>> Looking at the code in detail I have a few comments. >>>> >>>> src/hotspot/share/jvmci/jvmci_globals.cpp >>>> >>>> if (UseJVMCICompiler) { >>>> + if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && !UseJVMCINativeLibrary) { >>>> + char path[JVM_MAXPATHLEN]; >>>> + if (os::dll_locate_lib(path, sizeof(path), Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { >>>> + // If a JVMCI native library is present, >>>> + // we enable UseJVMCINativeLibrary by default. >>>> + FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); >>>> + } >>>> + } >>>> >>>> This change will affect use of JVMCI independent of whether EnableJVMCIProduct is set - was that intentional? >>> Yes, the compiler team is ok with this additional functionality being available when UseJVMCICompiler is true >>> independent of EnableJVMCIProduct. I?ve updated the RFE text to be clearer that this change is independent of >>> the new flag. >>>> >>>> In JVMCIGlobals::enable_jvmci_product_mode, if we return false then argument processing will return JNI_ERR and the loading of the VM will terminate. It is not clear to me that the user would get any useful information regarding what failed. That said I can't really see what could actually fail in that code ... but perhaps a warning would be useful? >>> Ok. >>>> >>>> I see where you clear the experimental bit, but as far as I can see that won't turn the flag into a product flag but will leave it uncategorised. ?? That probably works for you as you just need to ensure is_unlocked() returns true, but it does leave the flag in a strange state IMO. >>> Thanks for that find, I assumed !experimental was product. I?ll add a set_product function and call it when I remove the experimental bit. >>>> >>>> --- >>>> >>>> src/hotspot/share/runtime/arguments.cpp >>>> >>>> + #if INCLUDE_JVMCI >>>> + } else if (match_option(option, "-XX:+EnableJVMCIProduct")) { >>>> + JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); >>>> + // Allow this flag if it has been unlocked. >>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>> + return JNI_ERR; >>>> + } >>>> + } else if (match_option(option, "-XX:", &tail)) { >>>> + if (!process_argument(tail, args->ignoreUnrecognized, origin)) { >>>> + return JNI_EINVAL; >>>> + } >>>> + } >>>> >>>> It took me quite a while to understand that the point of >>>> >>>> + } else if (match_option(option, "-XX:", &tail)) { >>>> >>>> is purely to isolate the "EnableJVMCIProduct" part so that it can be processed by process_argument and report the expected error message that the flag has not been unlocked. I think it would be much clearer to just do that explicitly: >>>> >>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>> + return JNI_ERR; >>>> + } >>>> + } >>>> + // The flag was locked so process normally to report that error >>>> + else if (!process_argument("EnableJVMCIProduct", args->ignoreUnrecognized, origin)) { >>>> + return JNI_EINVAL; >>>> + } >>>> >>>> >>> Ok. >>>> Also the whole else-if block you added appears to be missing the final } to close it. ?? >>> Its on the next line after the #endif. This is how all the if cases are structures. >>>> >>>> --- >>>> >>>> src/hotspot/share/runtime/flags/jvmFlag.cpp >>>> >>>> + case RESOURCE: >>>> + st->print("resource"); break; >>>> >>>> src/hotspot/share/runtime/flags/jvmFlag.hpp >>>> >>>> ! RESOURCE = 7, >>>> ! INTERNAL = 8, >>>> >>>> I think the RESOURCE changes are part of the other RFE. ?? >>> Correct, these leaked in from another RFE and will be removed from my push. >>> Thanks, >>> Bob. >>>> >>>> --- >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>>> [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>>>> Bob. > From vladimir.kozlov at oracle.com Mon Oct 28 17:18:44 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Oct 2019 10:18:44 -0700 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: <7D29EA36-465A-4905-A714-D48C1A3849AD@oracle.com> References: <860FAE8F-579A-4DE9-9862-AA0A4B20B4E7@oracle.com> <7D29EA36-465A-4905-A714-D48C1A3849AD@oracle.com> Message-ID: <975f164f-1998-973a-0f8b-2e4d1274e8f7@oracle.com> On 10/28/19 8:37 AM, Bob Vandette wrote: > >> On Oct 25, 2019, at 6:57 AM, Doug Simon wrote: >> >> >> >>> On 25 Oct 2019, at 02:06, David Holmes wrote: >>> >>> On 25/10/2019 1:27 am, Bob Vandette wrote: >>>> Thanks for the review. See comments below. >>>> Updated webrev: http://cr.openjdk.java.net/~bobv/8232118/webrev.02 >>> >>> That all seems fine. >>> >>> Minor nit in arguments.cpp: >>> >>> + "Unable to enable jvmci in product mode"); >>> >>> s/jvmci/JVMCI/ >>> >>> One follow up ... you don't modify all of the JVMCI flags. The following are omitted: >>> >>> BootstrapJVMCI >>> JVMCIHostThreads >>> JVMCITraceLevel >>> MethodProfileWidth >>> PrintBootstrap >> >> These are all diagnostic flags. Bob, can EnableJVMCIProduct make them into actual diagnostic flags? Doug, the only question here if you want customers to use them for some diagnostic logging? Then we should consider converting them to diagnostic. If it is only for our internal debugging testing lets leave them experimental. We have JVMCI tests which use BootstrapJVMCI with UnlockExperimentalVMOptions. If we change the flag's type with EnableJVMCIProduct we need to update tests. > > If they are really diagnostic flags, then they should be declared that way. We can't declare them diagnostic in JDK yet until Graal become product. > > Leaving them as is still allows you to use them, they just need to be unlocked with the Experimental flag. > I?d prefer leaving leave them alone and let the compiler team decide what they want to do if/when JVMCI is no > longer experimental. I almost agree here but if they really needed to diagnose issues on customer side we should consider converting them as Doug asked. Vladimir > > Bob. > > >> >> -Doug >> >>> >>> >>>>> On Oct 24, 2019, at 1:22 AM, David Holmes > wrote: >>>>> >>>>> Hi Bob, >>>>> >>>>> On 24/10/2019 1:13 am, Bob Vandette wrote: >>>>>> Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, >>>>>> and alter a collection of JVM options to be product flags rather than experimental flags. >>>>>> EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. >>>>> >>>>> Okay, so there are few things happening here so let me step through them. The desire is to enable an experimental compiler by default, but not have to run with all experimental options unlocked (which I assume is just to try and protect the end user from their own mistakes?). So the way this would work is that the command-line would effectively be: >>>>> >>>>> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts --XX:-UnlockExperimentalVMOptions >>>>> >>>>> when EnableJVMCIProducts is processed (and is true) it will force on a couple of key JVMCI related flags, and it will turn off the flag-is-experimental bit on all the JVMCI flags. The latter being desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in play, all those other JVMCI flags would be hidden and you want them to be visible to introspection (like JVM TI, Dcmd) - is that correct? >>>> Yes, that?s correct. >>>>> >>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 >>>>>> WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 >>>>> >>>>> Looking at the code in detail I have a few comments. >>>>> >>>>> src/hotspot/share/jvmci/jvmci_globals.cpp >>>>> >>>>> if (UseJVMCICompiler) { >>>>> + if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && !UseJVMCINativeLibrary) { >>>>> + char path[JVM_MAXPATHLEN]; >>>>> + if (os::dll_locate_lib(path, sizeof(path), Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { >>>>> + // If a JVMCI native library is present, >>>>> + // we enable UseJVMCINativeLibrary by default. >>>>> + FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); >>>>> + } >>>>> + } >>>>> >>>>> This change will affect use of JVMCI independent of whether EnableJVMCIProduct is set - was that intentional? >>>> Yes, the compiler team is ok with this additional functionality being available when UseJVMCICompiler is true >>>> independent of EnableJVMCIProduct. I?ve updated the RFE text to be clearer that this change is independent of >>>> the new flag. >>>>> >>>>> In JVMCIGlobals::enable_jvmci_product_mode, if we return false then argument processing will return JNI_ERR and the loading of the VM will terminate. It is not clear to me that the user would get any useful information regarding what failed. That said I can't really see what could actually fail in that code ... but perhaps a warning would be useful? >>>> Ok. >>>>> >>>>> I see where you clear the experimental bit, but as far as I can see that won't turn the flag into a product flag but will leave it uncategorised. ?? That probably works for you as you just need to ensure is_unlocked() returns true, but it does leave the flag in a strange state IMO. >>>> Thanks for that find, I assumed !experimental was product. I?ll add a set_product function and call it when I remove the experimental bit. >>>>> >>>>> --- >>>>> >>>>> src/hotspot/share/runtime/arguments.cpp >>>>> >>>>> + #if INCLUDE_JVMCI >>>>> + } else if (match_option(option, "-XX:+EnableJVMCIProduct")) { >>>>> + JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); >>>>> + // Allow this flag if it has been unlocked. >>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>> + return JNI_ERR; >>>>> + } >>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>> + if (!process_argument(tail, args->ignoreUnrecognized, origin)) { >>>>> + return JNI_EINVAL; >>>>> + } >>>>> + } >>>>> >>>>> It took me quite a while to understand that the point of >>>>> >>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>> >>>>> is purely to isolate the "EnableJVMCIProduct" part so that it can be processed by process_argument and report the expected error message that the flag has not been unlocked. I think it would be much clearer to just do that explicitly: >>>>> >>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>> + return JNI_ERR; >>>>> + } >>>>> + } >>>>> + // The flag was locked so process normally to report that error >>>>> + else if (!process_argument("EnableJVMCIProduct", args->ignoreUnrecognized, origin)) { >>>>> + return JNI_EINVAL; >>>>> + } >>>>> >>>>> >>>> Ok. >>>>> Also the whole else-if block you added appears to be missing the final } to close it. ?? >>>> Its on the next line after the #endif. This is how all the if cases are structures. >>>>> >>>>> --- >>>>> >>>>> src/hotspot/share/runtime/flags/jvmFlag.cpp >>>>> >>>>> + case RESOURCE: >>>>> + st->print("resource"); break; >>>>> >>>>> src/hotspot/share/runtime/flags/jvmFlag.hpp >>>>> >>>>> ! RESOURCE = 7, >>>>> ! INTERNAL = 8, >>>>> >>>>> I think the RESOURCE changes are part of the other RFE. ?? >>>> Correct, these leaked in from another RFE and will be removed from my push. >>>> Thanks, >>>> Bob. >>>>> >>>>> --- >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>> >>>>>> [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>>>>> Bob. >> > From vladimir.kozlov at oracle.com Mon Oct 28 17:30:14 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Oct 2019 10:30:14 -0700 Subject: [14] RFR(M) 8233035: Update JVMCI Message-ID: <20668f8d-9aa8-f4e6-e313-88a7d15ad141@oracle.com> https://cr.openjdk.java.net/~kvn/8233035/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8233035 Sync JVMCI changes from labsjdk-11 repo which are not in graal-jvmci-8. [PATCH 17] fixed checkstyle and Eclipse issues, synced some tests from jvmci-8 [PATCH 22] do not intrinsify methods loaded by the app class loader [PATCH 23] handle other case in findUniqueConcreteMethod where the method can be statically bound [PATCH 26] pass saved system properties to JVMCI shared library [PATCH 55] Sync some missing VirtualObject changes Tested tier1-2, hs-tier3-graal Thanks, Vladimir From kim.barrett at oracle.com Mon Oct 28 19:40:08 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Oct 2019 15:40:08 -0400 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> Message-ID: <3298F64A-E975-4271-A42E-D6B9DACEFA94@oracle.com> > On Oct 28, 2019, at 10:06 AM, Doerr, Martin wrote: > @Kim: > Thanks for looking at the handle related parts. It's ok if you don't want to be a reviewer of the whole change. I?ll reply to the pending parts, and drop out. I think the handle related parts are going in the right direction now. >> I think it's weird that can_remove() is a predicate with optional side >> effects. I think it would be simpler to have it be a pure predicate, >> and have the one caller with do_it = true perform the updates. That >> should include NULLing out the handle pointer (perhaps debug-only, but >> it doesn't cost much to cleanly maintain the data structure). > Nevertheless, it has the advantage that it enforces the update to be consistent. > A caller could use it without holding the lock or mess it up otherwise. > In addition, I don't what to change that as part of this fix. Understood, though I think I recall the caller with do_it = true is holding the appropriate lock around the call. >> So far as I can tell, THREAD == NULL here. > This is a very tricky part (not my invention): > EXCEPTION_MARK contains an ExceptionMark constructor call which sets __the_thread__ to Thread::current(). > I don't want to publish my opinion about this ?? Oh, that?s interesting? I know exceptions.hpp contains some exciting code, but I?ve so far avoided looking at it closely. That stuff doesn?t come up much in gc code :) > @David: > Seems like this option is preferred over option 3 (possibly_add_compiler_threads part of webrev.02 and leave the initialization as is). > So when you're ok with it, I'll request a 2nd review from the compiler folks (I should change the subject to contain RFR). Handle usage here looks okay to me now. I think JVMCI global handles could be used instead, but I?ll leave that up to others. From kim.barrett at oracle.com Mon Oct 28 19:45:19 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Oct 2019 15:45:19 -0400 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> Message-ID: > On Oct 28, 2019, at 12:04 AM, David Holmes wrote: > > On 28/10/2019 1:42 pm, Kim Barrett wrote: >> I think either that comment about an old thread is wrong (and the NULL >> assertion I suggested is okay), or I think the whole mechanism here >> has problems. Or at least I was unable to figure out how it could work... > > I'm not following sorry. You can't assert NULL unless it's actually set to NULL which it presently isn't. But it could be set NULL as Martin suggested: > > "We may want to improve that further by setting the handle pointer to NULL and asserting that it is NULL before adding the new one." > > and which I also supported. But that aside once the delete_global has been called that JNIHandle no longer references the j.l.Thread that it did, at which point it is only reachable via the threadObj() of the CompilerThread. I spent some more time figuring out how it works, and agree I was confused. From kim.barrett at oracle.com Mon Oct 28 19:46:18 2019 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 28 Oct 2019 15:46:18 -0400 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> Message-ID: > On Oct 28, 2019, at 10:06 AM, Doerr, Martin wrote: > > Hi David and Kim, > > I think it's easier to talk about code. So here's a new webrev: > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.03/ src/hotspot/share/compiler/compileBroker.cpp 948 assert(compiler2_object(i) = NULL, "Old one must be released!?); That should be ?==? rather than ?=?. From doug.simon at oracle.com Mon Oct 28 20:40:48 2019 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 28 Oct 2019 21:40:48 +0100 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: <975f164f-1998-973a-0f8b-2e4d1274e8f7@oracle.com> References: <860FAE8F-579A-4DE9-9862-AA0A4B20B4E7@oracle.com> <7D29EA36-465A-4905-A714-D48C1A3849AD@oracle.com> <975f164f-1998-973a-0f8b-2e4d1274e8f7@oracle.com> Message-ID: <9BC7B458-F2C4-4A22-B850-1088AF81502B@oracle.com> > On 28 Oct 2019, at 18:18, Vladimir Kozlov wrote: > > On 10/28/19 8:37 AM, Bob Vandette wrote: >>> On Oct 25, 2019, at 6:57 AM, Doug Simon wrote: >>> >>> >>> >>>> On 25 Oct 2019, at 02:06, David Holmes wrote: >>>> >>>> On 25/10/2019 1:27 am, Bob Vandette wrote: >>>>> Thanks for the review. See comments below. >>>>> Updated webrev: http://cr.openjdk.java.net/~bobv/8232118/webrev.02 >>>> >>>> That all seems fine. >>>> >>>> Minor nit in arguments.cpp: >>>> >>>> + "Unable to enable jvmci in product mode"); >>>> >>>> s/jvmci/JVMCI/ >>>> >>>> One follow up ... you don't modify all of the JVMCI flags. The following are omitted: >>>> >>>> BootstrapJVMCI >>>> JVMCIHostThreads >>>> JVMCITraceLevel >>>> MethodProfileWidth >>>> PrintBootstrap >>> >>> These are all diagnostic flags. Bob, can EnableJVMCIProduct make them into actual diagnostic flags? > > Doug, the only question here if you want customers to use them for some diagnostic logging? Then we should consider converting them to diagnostic. If it is only for our internal debugging testing lets leave them experimental. > > We have JVMCI tests which use BootstrapJVMCI with UnlockExperimentalVMOptions. If we change the flag's type with EnableJVMCIProduct we need to update tests. We have a similar issue in GraalVM. >> If they are really diagnostic flags, then they should be declared that way. > > We can't declare them diagnostic in JDK yet until Graal become product. I thought the whole point of EnableJVMCIProduct is to change JVMCI flags to something other than experimental. Not sure why it?s ok to change some to ?product? but not others to ?diagnostic?. > >> Leaving them as is still allows you to use them, they just need to be unlocked with the Experimental flag. >> I?d prefer leaving leave them alone and let the compiler team decide what they want to do if/when JVMCI is no >> longer experimental. > > I almost agree here but if they really needed to diagnose issues on customer side we should consider converting them as Doug asked. Since we can also ask customers to enable experimental options for diagnostic purposes, its ok to leave as experimental. -Doug >> Bob. >>> >>> -Doug >>> >>>> >>>> >>>>>> On Oct 24, 2019, at 1:22 AM, David Holmes > wrote: >>>>>> >>>>>> Hi Bob, >>>>>> >>>>>> On 24/10/2019 1:13 am, Bob Vandette wrote: >>>>>>> Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, >>>>>>> and alter a collection of JVM options to be product flags rather than experimental flags. >>>>>>> EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. >>>>>> >>>>>> Okay, so there are few things happening here so let me step through them. The desire is to enable an experimental compiler by default, but not have to run with all experimental options unlocked (which I assume is just to try and protect the end user from their own mistakes?). So the way this would work is that the command-line would effectively be: >>>>>> >>>>>> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts --XX:-UnlockExperimentalVMOptions >>>>>> >>>>>> when EnableJVMCIProducts is processed (and is true) it will force on a couple of key JVMCI related flags, and it will turn off the flag-is-experimental bit on all the JVMCI flags. The latter being desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in play, all those other JVMCI flags would be hidden and you want them to be visible to introspection (like JVM TI, Dcmd) - is that correct? >>>>> Yes, that?s correct. >>>>>> >>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 >>>>>>> WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 >>>>>> >>>>>> Looking at the code in detail I have a few comments. >>>>>> >>>>>> src/hotspot/share/jvmci/jvmci_globals.cpp >>>>>> >>>>>> if (UseJVMCICompiler) { >>>>>> + if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && !UseJVMCINativeLibrary) { >>>>>> + char path[JVM_MAXPATHLEN]; >>>>>> + if (os::dll_locate_lib(path, sizeof(path), Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { >>>>>> + // If a JVMCI native library is present, >>>>>> + // we enable UseJVMCINativeLibrary by default. >>>>>> + FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); >>>>>> + } >>>>>> + } >>>>>> >>>>>> This change will affect use of JVMCI independent of whether EnableJVMCIProduct is set - was that intentional? >>>>> Yes, the compiler team is ok with this additional functionality being available when UseJVMCICompiler is true >>>>> independent of EnableJVMCIProduct. I?ve updated the RFE text to be clearer that this change is independent of >>>>> the new flag. >>>>>> >>>>>> In JVMCIGlobals::enable_jvmci_product_mode, if we return false then argument processing will return JNI_ERR and the loading of the VM will terminate. It is not clear to me that the user would get any useful information regarding what failed. That said I can't really see what could actually fail in that code ... but perhaps a warning would be useful? >>>>> Ok. >>>>>> >>>>>> I see where you clear the experimental bit, but as far as I can see that won't turn the flag into a product flag but will leave it uncategorised. ?? That probably works for you as you just need to ensure is_unlocked() returns true, but it does leave the flag in a strange state IMO. >>>>> Thanks for that find, I assumed !experimental was product. I?ll add a set_product function and call it when I remove the experimental bit. >>>>>> >>>>>> --- >>>>>> >>>>>> src/hotspot/share/runtime/arguments.cpp >>>>>> >>>>>> + #if INCLUDE_JVMCI >>>>>> + } else if (match_option(option, "-XX:+EnableJVMCIProduct")) { >>>>>> + JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); >>>>>> + // Allow this flag if it has been unlocked. >>>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>>> + return JNI_ERR; >>>>>> + } >>>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>>> + if (!process_argument(tail, args->ignoreUnrecognized, origin)) { >>>>>> + return JNI_EINVAL; >>>>>> + } >>>>>> + } >>>>>> >>>>>> It took me quite a while to understand that the point of >>>>>> >>>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>>> >>>>>> is purely to isolate the "EnableJVMCIProduct" part so that it can be processed by process_argument and report the expected error message that the flag has not been unlocked. I think it would be much clearer to just do that explicitly: >>>>>> >>>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>>> + return JNI_ERR; >>>>>> + } >>>>>> + } >>>>>> + // The flag was locked so process normally to report that error >>>>>> + else if (!process_argument("EnableJVMCIProduct", args->ignoreUnrecognized, origin)) { >>>>>> + return JNI_EINVAL; >>>>>> + } >>>>>> >>>>>> >>>>> Ok. >>>>>> Also the whole else-if block you added appears to be missing the final } to close it. ?? >>>>> Its on the next line after the #endif. This is how all the if cases are structures. >>>>>> >>>>>> --- >>>>>> >>>>>> src/hotspot/share/runtime/flags/jvmFlag.cpp >>>>>> >>>>>> + case RESOURCE: >>>>>> + st->print("resource"); break; >>>>>> >>>>>> src/hotspot/share/runtime/flags/jvmFlag.hpp >>>>>> >>>>>> ! RESOURCE = 7, >>>>>> ! INTERNAL = 8, >>>>>> >>>>>> I think the RESOURCE changes are part of the other RFE. ?? >>>>> Correct, these leaked in from another RFE and will be removed from my push. >>>>> Thanks, >>>>> Bob. >>>>>> >>>>>> --- >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>>> [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>>>>>> Bob. From dean.long at oracle.com Mon Oct 28 20:43:56 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 28 Oct 2019 13:43:56 -0700 Subject: [14] RFR(M) 8233035: Update JVMCI In-Reply-To: <20668f8d-9aa8-f4e6-e313-88a7d15ad141@oracle.com> References: <20668f8d-9aa8-f4e6-e313-88a7d15ad141@oracle.com> Message-ID: <0482632e-bd22-cc73-cb8b-9f612aa326a1@oracle.com> Looks OK to me. dl On 10/28/19 10:30 AM, Vladimir Kozlov wrote: > https://cr.openjdk.java.net/~kvn/8233035/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8233035 > > Sync JVMCI changes from labsjdk-11 repo which are not in graal-jvmci-8. > > [PATCH 17] fixed checkstyle and Eclipse issues, synced some tests from > jvmci-8 > [PATCH 22] do not intrinsify methods loaded by the app class loader > [PATCH 23] handle other case in findUniqueConcreteMethod where the > method can be statically bound > [PATCH 26] pass saved system properties to JVMCI shared library > [PATCH 55] Sync some missing VirtualObject changes > > Tested tier1-2, hs-tier3-graal > > Thanks, > Vladimir From bob.vandette at oracle.com Mon Oct 28 20:50:07 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 28 Oct 2019 16:50:07 -0400 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: <9BC7B458-F2C4-4A22-B850-1088AF81502B@oracle.com> References: <860FAE8F-579A-4DE9-9862-AA0A4B20B4E7@oracle.com> <7D29EA36-465A-4905-A714-D48C1A3849AD@oracle.com> <975f164f-1998-973a-0f8b-2e4d1274e8f7@oracle.com> <9BC7B458-F2C4-4A22-B850-1088AF81502B@oracle.com> Message-ID: <15AA39CE-6C16-409E-88CB-7DE424DBF801@oracle.com> > On Oct 28, 2019, at 4:40 PM, Doug Simon wrote: > > > >> On 28 Oct 2019, at 18:18, Vladimir Kozlov > wrote: >> >> On 10/28/19 8:37 AM, Bob Vandette wrote: >>>> On Oct 25, 2019, at 6:57 AM, Doug Simon > wrote: >>>> >>>> >>>> >>>>> On 25 Oct 2019, at 02:06, David Holmes > wrote: >>>>> >>>>> On 25/10/2019 1:27 am, Bob Vandette wrote: >>>>>> Thanks for the review. See comments below. >>>>>> Updated webrev: http://cr.openjdk.java.net/~bobv/8232118/webrev.02 >>>>> >>>>> That all seems fine. >>>>> >>>>> Minor nit in arguments.cpp: >>>>> >>>>> + "Unable to enable jvmci in product mode"); >>>>> >>>>> s/jvmci/JVMCI/ >>>>> >>>>> One follow up ... you don't modify all of the JVMCI flags. The following are omitted: >>>>> >>>>> BootstrapJVMCI >>>>> JVMCIHostThreads >>>>> JVMCITraceLevel >>>>> MethodProfileWidth >>>>> PrintBootstrap >>>> >>>> These are all diagnostic flags. Bob, can EnableJVMCIProduct make them into actual diagnostic flags? >> >> Doug, the only question here if you want customers to use them for some diagnostic logging? Then we should consider converting them to diagnostic. If it is only for our internal debugging testing lets leave them experimental. >> >> We have JVMCI tests which use BootstrapJVMCI with UnlockExperimentalVMOptions. If we change the flag's type with EnableJVMCIProduct we need to update tests. > > We have a similar issue in GraalVM. > >>> If they are really diagnostic flags, then they should be declared that way. >> >> We can't declare them diagnostic in JDK yet until Graal become product. > > I thought the whole point of EnableJVMCIProduct is to change JVMCI flags to something other than experimental. Not sure why it?s ok to change some to ?product? but not others to ?diagnostic?. Vladimir is responding to my comment about making these flags diagnostic independent of EnableJVMCIProduct. > >> >>> Leaving them as is still allows you to use them, they just need to be unlocked with the Experimental flag. >>> I?d prefer leaving leave them alone and let the compiler team decide what they want to do if/when JVMCI is no >>> longer experimental. >> >> I almost agree here but if they really needed to diagnose issues on customer side we should consider converting them as Doug asked. > > Since we can also ask customers to enable experimental options for diagnostic purposes, its ok to leave as experimental. We could do this but wouldn?t we have some confusion with support folks who might read the source and see that this flag is declared experimental but since EnableJVMCIProduct is hidden in the jlink?d module file, they won?t know which flag to use if we changed it under the covers to be a diagnostic one? Bob. > > -Doug > >>> Bob. >>>> >>>> -Doug >>>> >>>>> >>>>> >>>>>>> On Oct 24, 2019, at 1:22 AM, David Holmes >> wrote: >>>>>>> >>>>>>> Hi Bob, >>>>>>> >>>>>>> On 24/10/2019 1:13 am, Bob Vandette wrote: >>>>>>>> Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, >>>>>>>> and alter a collection of JVM options to be product flags rather than experimental flags. >>>>>>>> EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. >>>>>>> >>>>>>> Okay, so there are few things happening here so let me step through them. The desire is to enable an experimental compiler by default, but not have to run with all experimental options unlocked (which I assume is just to try and protect the end user from their own mistakes?). So the way this would work is that the command-line would effectively be: >>>>>>> >>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts --XX:-UnlockExperimentalVMOptions >>>>>>> >>>>>>> when EnableJVMCIProducts is processed (and is true) it will force on a couple of key JVMCI related flags, and it will turn off the flag-is-experimental bit on all the JVMCI flags. The latter being desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in play, all those other JVMCI flags would be hidden and you want them to be visible to introspection (like JVM TI, Dcmd) - is that correct? >>>>>> Yes, that?s correct. >>>>>>> >>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 >>>>>>>> WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 >>>>>>> >>>>>>> Looking at the code in detail I have a few comments. >>>>>>> >>>>>>> src/hotspot/share/jvmci/jvmci_globals.cpp >>>>>>> >>>>>>> if (UseJVMCICompiler) { >>>>>>> + if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && !UseJVMCINativeLibrary) { >>>>>>> + char path[JVM_MAXPATHLEN]; >>>>>>> + if (os::dll_locate_lib(path, sizeof(path), Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { >>>>>>> + // If a JVMCI native library is present, >>>>>>> + // we enable UseJVMCINativeLibrary by default. >>>>>>> + FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); >>>>>>> + } >>>>>>> + } >>>>>>> >>>>>>> This change will affect use of JVMCI independent of whether EnableJVMCIProduct is set - was that intentional? >>>>>> Yes, the compiler team is ok with this additional functionality being available when UseJVMCICompiler is true >>>>>> independent of EnableJVMCIProduct. I?ve updated the RFE text to be clearer that this change is independent of >>>>>> the new flag. >>>>>>> >>>>>>> In JVMCIGlobals::enable_jvmci_product_mode, if we return false then argument processing will return JNI_ERR and the loading of the VM will terminate. It is not clear to me that the user would get any useful information regarding what failed. That said I can't really see what could actually fail in that code ... but perhaps a warning would be useful? >>>>>> Ok. >>>>>>> >>>>>>> I see where you clear the experimental bit, but as far as I can see that won't turn the flag into a product flag but will leave it uncategorised. ?? That probably works for you as you just need to ensure is_unlocked() returns true, but it does leave the flag in a strange state IMO. >>>>>> Thanks for that find, I assumed !experimental was product. I?ll add a set_product function and call it when I remove the experimental bit. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/runtime/arguments.cpp >>>>>>> >>>>>>> + #if INCLUDE_JVMCI >>>>>>> + } else if (match_option(option, "-XX:+EnableJVMCIProduct")) { >>>>>>> + JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); >>>>>>> + // Allow this flag if it has been unlocked. >>>>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>>>> + return JNI_ERR; >>>>>>> + } >>>>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>>>> + if (!process_argument(tail, args->ignoreUnrecognized, origin)) { >>>>>>> + return JNI_EINVAL; >>>>>>> + } >>>>>>> + } >>>>>>> >>>>>>> It took me quite a while to understand that the point of >>>>>>> >>>>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>>>> >>>>>>> is purely to isolate the "EnableJVMCIProduct" part so that it can be processed by process_argument and report the expected error message that the flag has not been unlocked. I think it would be much clearer to just do that explicitly: >>>>>>> >>>>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>>>> + return JNI_ERR; >>>>>>> + } >>>>>>> + } >>>>>>> + // The flag was locked so process normally to report that error >>>>>>> + else if (!process_argument("EnableJVMCIProduct", args->ignoreUnrecognized, origin)) { >>>>>>> + return JNI_EINVAL; >>>>>>> + } >>>>>>> >>>>>>> >>>>>> Ok. >>>>>>> Also the whole else-if block you added appears to be missing the final } to close it. ?? >>>>>> Its on the next line after the #endif. This is how all the if cases are structures. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> src/hotspot/share/runtime/flags/jvmFlag.cpp >>>>>>> >>>>>>> + case RESOURCE: >>>>>>> + st->print("resource"); break; >>>>>>> >>>>>>> src/hotspot/share/runtime/flags/jvmFlag.hpp >>>>>>> >>>>>>> ! RESOURCE = 7, >>>>>>> ! INTERNAL = 8, >>>>>>> >>>>>>> I think the RESOURCE changes are part of the other RFE. ?? >>>>>> Correct, these leaked in from another RFE and will be removed from my push. >>>>>> Thanks, >>>>>> Bob. >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> Thanks, >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>>> [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>>>>>>> Bob. > From vladimir.kozlov at oracle.com Mon Oct 28 21:07:23 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 28 Oct 2019 14:07:23 -0700 Subject: [14] RFR(M) 8233035: Update JVMCI In-Reply-To: <0482632e-bd22-cc73-cb8b-9f612aa326a1@oracle.com> References: <20668f8d-9aa8-f4e6-e313-88a7d15ad141@oracle.com> <0482632e-bd22-cc73-cb8b-9f612aa326a1@oracle.com> Message-ID: <4d40453b-090b-e0e2-3135-1fb05b3e7fb2@oracle.com> Thank you, Dean Vladimir On 10/28/19 1:43 PM, dean.long at oracle.com wrote: > Looks OK to me. > > dl > > On 10/28/19 10:30 AM, Vladimir Kozlov wrote: >> https://cr.openjdk.java.net/~kvn/8233035/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8233035 >> >> Sync JVMCI changes from labsjdk-11 repo which are not in graal-jvmci-8. >> >> [PATCH 17] fixed checkstyle and Eclipse issues, synced some tests from >> jvmci-8 >> [PATCH 22] do not intrinsify methods loaded by the app class loader >> [PATCH 23] handle other case in findUniqueConcreteMethod where the >> method can be statically bound >> [PATCH 26] pass saved system properties to JVMCI shared library >> [PATCH 55] Sync some missing VirtualObject changes >> >> Tested tier1-2, hs-tier3-graal >> >> Thanks, >> Vladimir > From doug.simon at oracle.com Mon Oct 28 21:21:42 2019 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 28 Oct 2019 22:21:42 +0100 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: <15AA39CE-6C16-409E-88CB-7DE424DBF801@oracle.com> References: <860FAE8F-579A-4DE9-9862-AA0A4B20B4E7@oracle.com> <7D29EA36-465A-4905-A714-D48C1A3849AD@oracle.com> <975f164f-1998-973a-0f8b-2e4d1274e8f7@oracle.com> <9BC7B458-F2C4-4A22-B850-1088AF81502B@oracle.com> <15AA39CE-6C16-409E-88CB-7DE424DBF801@oracle.com> Message-ID: <8A6EF9FA-E36F-4A56-A9E9-F3AA378C0EA6@oracle.com> > On 28 Oct 2019, at 21:50, Bob Vandette wrote: > > >> On Oct 28, 2019, at 4:40 PM, Doug Simon > wrote: >> >> >> >>> On 28 Oct 2019, at 18:18, Vladimir Kozlov > wrote: >>> >>> On 10/28/19 8:37 AM, Bob Vandette wrote: >>>>> On Oct 25, 2019, at 6:57 AM, Doug Simon > wrote: >>>>> >>>>> >>>>> >>>>>> On 25 Oct 2019, at 02:06, David Holmes > wrote: >>>>>> >>>>>> On 25/10/2019 1:27 am, Bob Vandette wrote: >>>>>>> Thanks for the review. See comments below. >>>>>>> Updated webrev: http://cr.openjdk.java.net/~bobv/8232118/webrev.02 >>>>>> >>>>>> That all seems fine. >>>>>> >>>>>> Minor nit in arguments.cpp: >>>>>> >>>>>> + "Unable to enable jvmci in product mode"); >>>>>> >>>>>> s/jvmci/JVMCI/ >>>>>> >>>>>> One follow up ... you don't modify all of the JVMCI flags. The following are omitted: >>>>>> >>>>>> BootstrapJVMCI >>>>>> JVMCIHostThreads >>>>>> JVMCITraceLevel >>>>>> MethodProfileWidth >>>>>> PrintBootstrap >>>>> >>>>> These are all diagnostic flags. Bob, can EnableJVMCIProduct make them into actual diagnostic flags? >>> >>> Doug, the only question here if you want customers to use them for some diagnostic logging? Then we should consider converting them to diagnostic. If it is only for our internal debugging testing lets leave them experimental. >>> >>> We have JVMCI tests which use BootstrapJVMCI with UnlockExperimentalVMOptions. If we change the flag's type with EnableJVMCIProduct we need to update tests. >> >> We have a similar issue in GraalVM. >> >>>> If they are really diagnostic flags, then they should be declared that way. >>> >>> We can't declare them diagnostic in JDK yet until Graal become product. >> >> I thought the whole point of EnableJVMCIProduct is to change JVMCI flags to something other than experimental. Not sure why it?s ok to change some to ?product? but not others to ?diagnostic?. > > Vladimir is responding to my comment about making these flags diagnostic independent of EnableJVMCIProduct. > >> >>> >>>> Leaving them as is still allows you to use them, they just need to be unlocked with the Experimental flag. >>>> I?d prefer leaving leave them alone and let the compiler team decide what they want to do if/when JVMCI is no >>>> longer experimental. >>> >>> I almost agree here but if they really needed to diagnose issues on customer side we should consider converting them as Doug asked. >> >> Since we can also ask customers to enable experimental options for diagnostic purposes, its ok to leave as experimental. > > We could do this but wouldn?t we have some confusion with support folks who might read the source and see that this flag is > declared experimental but since EnableJVMCIProduct is hidden in the jlink?d module file, they won?t know which flag to use > if we changed it under the covers to be a diagnostic one? Won?t they have the same problem with any of the JVMCI flags that become product flags as a result of EnableJVMCIProduct? I have the feeling that I?m not understanding your question correctly. -Doug > >> >> -Doug >> >>>> Bob. >>>>> >>>>> -Doug >>>>> >>>>>> >>>>>> >>>>>>>> On Oct 24, 2019, at 1:22 AM, David Holmes >> wrote: >>>>>>>> >>>>>>>> Hi Bob, >>>>>>>> >>>>>>>> On 24/10/2019 1:13 am, Bob Vandette wrote: >>>>>>>>> Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, >>>>>>>>> and alter a collection of JVM options to be product flags rather than experimental flags. >>>>>>>>> EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. >>>>>>>> >>>>>>>> Okay, so there are few things happening here so let me step through them. The desire is to enable an experimental compiler by default, but not have to run with all experimental options unlocked (which I assume is just to try and protect the end user from their own mistakes?). So the way this would work is that the command-line would effectively be: >>>>>>>> >>>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts --XX:-UnlockExperimentalVMOptions >>>>>>>> >>>>>>>> when EnableJVMCIProducts is processed (and is true) it will force on a couple of key JVMCI related flags, and it will turn off the flag-is-experimental bit on all the JVMCI flags. The latter being desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in play, all those other JVMCI flags would be hidden and you want them to be visible to introspection (like JVM TI, Dcmd) - is that correct? >>>>>>> Yes, that?s correct. >>>>>>>> >>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 >>>>>>>>> WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 >>>>>>>> >>>>>>>> Looking at the code in detail I have a few comments. >>>>>>>> >>>>>>>> src/hotspot/share/jvmci/jvmci_globals.cpp >>>>>>>> >>>>>>>> if (UseJVMCICompiler) { >>>>>>>> + if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && !UseJVMCINativeLibrary) { >>>>>>>> + char path[JVM_MAXPATHLEN]; >>>>>>>> + if (os::dll_locate_lib(path, sizeof(path), Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { >>>>>>>> + // If a JVMCI native library is present, >>>>>>>> + // we enable UseJVMCINativeLibrary by default. >>>>>>>> + FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); >>>>>>>> + } >>>>>>>> + } >>>>>>>> >>>>>>>> This change will affect use of JVMCI independent of whether EnableJVMCIProduct is set - was that intentional? >>>>>>> Yes, the compiler team is ok with this additional functionality being available when UseJVMCICompiler is true >>>>>>> independent of EnableJVMCIProduct. I?ve updated the RFE text to be clearer that this change is independent of >>>>>>> the new flag. >>>>>>>> >>>>>>>> In JVMCIGlobals::enable_jvmci_product_mode, if we return false then argument processing will return JNI_ERR and the loading of the VM will terminate. It is not clear to me that the user would get any useful information regarding what failed. That said I can't really see what could actually fail in that code ... but perhaps a warning would be useful? >>>>>>> Ok. >>>>>>>> >>>>>>>> I see where you clear the experimental bit, but as far as I can see that won't turn the flag into a product flag but will leave it uncategorised. ?? That probably works for you as you just need to ensure is_unlocked() returns true, but it does leave the flag in a strange state IMO. >>>>>>> Thanks for that find, I assumed !experimental was product. I?ll add a set_product function and call it when I remove the experimental bit. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/hotspot/share/runtime/arguments.cpp >>>>>>>> >>>>>>>> + #if INCLUDE_JVMCI >>>>>>>> + } else if (match_option(option, "-XX:+EnableJVMCIProduct")) { >>>>>>>> + JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); >>>>>>>> + // Allow this flag if it has been unlocked. >>>>>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>>>>> + return JNI_ERR; >>>>>>>> + } >>>>>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>>>>> + if (!process_argument(tail, args->ignoreUnrecognized, origin)) { >>>>>>>> + return JNI_EINVAL; >>>>>>>> + } >>>>>>>> + } >>>>>>>> >>>>>>>> It took me quite a while to understand that the point of >>>>>>>> >>>>>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>>>>> >>>>>>>> is purely to isolate the "EnableJVMCIProduct" part so that it can be processed by process_argument and report the expected error message that the flag has not been unlocked. I think it would be much clearer to just do that explicitly: >>>>>>>> >>>>>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>>>>> + return JNI_ERR; >>>>>>>> + } >>>>>>>> + } >>>>>>>> + // The flag was locked so process normally to report that error >>>>>>>> + else if (!process_argument("EnableJVMCIProduct", args->ignoreUnrecognized, origin)) { >>>>>>>> + return JNI_EINVAL; >>>>>>>> + } >>>>>>>> >>>>>>>> >>>>>>> Ok. >>>>>>>> Also the whole else-if block you added appears to be missing the final } to close it. ?? >>>>>>> Its on the next line after the #endif. This is how all the if cases are structures. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/hotspot/share/runtime/flags/jvmFlag.cpp >>>>>>>> >>>>>>>> + case RESOURCE: >>>>>>>> + st->print("resource"); break; >>>>>>>> >>>>>>>> src/hotspot/share/runtime/flags/jvmFlag.hpp >>>>>>>> >>>>>>>> ! RESOURCE = 7, >>>>>>>> ! INTERNAL = 8, >>>>>>>> >>>>>>>> I think the RESOURCE changes are part of the other RFE. ?? >>>>>>> Correct, these leaked in from another RFE and will be removed from my push. >>>>>>> Thanks, >>>>>>> Bob. >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>>> [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>>>>>>>> Bob. >> > From bob.vandette at oracle.com Mon Oct 28 21:38:33 2019 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 28 Oct 2019 17:38:33 -0400 Subject: RFR: 8232118 - Add JVM option to enable JVMCI compilers in product mode In-Reply-To: <8A6EF9FA-E36F-4A56-A9E9-F3AA378C0EA6@oracle.com> References: <860FAE8F-579A-4DE9-9862-AA0A4B20B4E7@oracle.com> <7D29EA36-465A-4905-A714-D48C1A3849AD@oracle.com> <975f164f-1998-973a-0f8b-2e4d1274e8f7@oracle.com> <9BC7B458-F2C4-4A22-B850-1088AF81502B@oracle.com> <15AA39CE-6C16-409E-88CB-7DE424DBF801@oracle.com> <8A6EF9FA-E36F-4A56-A9E9-F3AA378C0EA6@oracle.com> Message-ID: <3203D054-4659-4A80-A01B-352EF85F1E43@oracle.com> > On Oct 28, 2019, at 5:21 PM, Doug Simon wrote: > > > >> On 28 Oct 2019, at 21:50, Bob Vandette > wrote: >> >> >>> On Oct 28, 2019, at 4:40 PM, Doug Simon > wrote: >>> >>> >>> >>>> On 28 Oct 2019, at 18:18, Vladimir Kozlov > wrote: >>>> >>>> On 10/28/19 8:37 AM, Bob Vandette wrote: >>>>>> On Oct 25, 2019, at 6:57 AM, Doug Simon > wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On 25 Oct 2019, at 02:06, David Holmes > wrote: >>>>>>> >>>>>>> On 25/10/2019 1:27 am, Bob Vandette wrote: >>>>>>>> Thanks for the review. See comments below. >>>>>>>> Updated webrev: http://cr.openjdk.java.net/~bobv/8232118/webrev.02 >>>>>>> >>>>>>> That all seems fine. >>>>>>> >>>>>>> Minor nit in arguments.cpp: >>>>>>> >>>>>>> + "Unable to enable jvmci in product mode"); >>>>>>> >>>>>>> s/jvmci/JVMCI/ >>>>>>> >>>>>>> One follow up ... you don't modify all of the JVMCI flags. The following are omitted: >>>>>>> >>>>>>> BootstrapJVMCI >>>>>>> JVMCIHostThreads >>>>>>> JVMCITraceLevel >>>>>>> MethodProfileWidth >>>>>>> PrintBootstrap >>>>>> >>>>>> These are all diagnostic flags. Bob, can EnableJVMCIProduct make them into actual diagnostic flags? >>>> >>>> Doug, the only question here if you want customers to use them for some diagnostic logging? Then we should consider converting them to diagnostic. If it is only for our internal debugging testing lets leave them experimental. >>>> >>>> We have JVMCI tests which use BootstrapJVMCI with UnlockExperimentalVMOptions. If we change the flag's type with EnableJVMCIProduct we need to update tests. >>> >>> We have a similar issue in GraalVM. >>> >>>>> If they are really diagnostic flags, then they should be declared that way. >>>> >>>> We can't declare them diagnostic in JDK yet until Graal become product. >>> >>> I thought the whole point of EnableJVMCIProduct is to change JVMCI flags to something other than experimental. Not sure why it?s ok to change some to ?product? but not others to ?diagnostic?. >> >> Vladimir is responding to my comment about making these flags diagnostic independent of EnableJVMCIProduct. >> >>> >>>> >>>>> Leaving them as is still allows you to use them, they just need to be unlocked with the Experimental flag. >>>>> I?d prefer leaving leave them alone and let the compiler team decide what they want to do if/when JVMCI is no >>>>> longer experimental. >>>> >>>> I almost agree here but if they really needed to diagnose issues on customer side we should consider converting them as Doug asked. >>> >>> Since we can also ask customers to enable experimental options for diagnostic purposes, its ok to leave as experimental. >> >> We could do this but wouldn?t we have some confusion with support folks who might read the source and see that this flag is >> declared experimental but since EnableJVMCIProduct is hidden in the jlink?d module file, they won?t know which flag to use >> if we changed it under the covers to be a diagnostic one? > > Won?t they have the same problem with any of the JVMCI flags that become product flags as a result of EnableJVMCIProduct? I have the feeling that I?m not understanding your question correctly. > The difference with Product flags is that they don?t need any unlocking. In any case, we?ll stick with experimental for these few flags for now and revisit this later. Bob. > -Doug > >> >>> >>> -Doug >>> >>>>> Bob. >>>>>> >>>>>> -Doug >>>>>> >>>>>>> >>>>>>> >>>>>>>>> On Oct 24, 2019, at 1:22 AM, David Holmes >> wrote: >>>>>>>>> >>>>>>>>> Hi Bob, >>>>>>>>> >>>>>>>>> On 24/10/2019 1:13 am, Bob Vandette wrote: >>>>>>>>>> Please review this RFE that adds a new JVM option "-XX:+EnableJVMCIProduct" which will allow JVMCI to be used as the default compiler, >>>>>>>>>> and alter a collection of JVM options to be product flags rather than experimental flags. >>>>>>>>>> EnableJVMCIProduct is an experimental flag since the default JVMCI running mode is still experimental. A vendor wishing to support their JVMCI compiler as the default can enable JVMCI by default by specifying this new -XX:+EnableJVMCIProduct flag after the -XX:+UnlockExperimentalVMOptions flag. This flag is especially useful when added to a JDK runtime generated with the new jlink --add-options plugin (see JDK-8232080 [1]). This allows JVMCI based compilers to be used, by default, without the user having to specify any options. >>>>>>>>> >>>>>>>>> Okay, so there are few things happening here so let me step through them. The desire is to enable an experimental compiler by default, but not have to run with all experimental options unlocked (which I assume is just to try and protect the end user from their own mistakes?). So the way this would work is that the command-line would effectively be: >>>>>>>>> >>>>>>>>> -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCIProducts --XX:-UnlockExperimentalVMOptions >>>>>>>>> >>>>>>>>> when EnableJVMCIProducts is processed (and is true) it will force on a couple of key JVMCI related flags, and it will turn off the flag-is-experimental bit on all the JVMCI flags. The latter being desirable because otherwise, with -XX:-UnlockExperimentalVMOptions in play, all those other JVMCI flags would be hidden and you want them to be visible to introspection (like JVM TI, Dcmd) - is that correct? >>>>>>>> Yes, that?s correct. >>>>>>>>> >>>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8232118 >>>>>>>>>> WEBREV: http://cr.openjdk.java.net/~bobv/8232118/webrev.01 >>>>>>>>> >>>>>>>>> Looking at the code in detail I have a few comments. >>>>>>>>> >>>>>>>>> src/hotspot/share/jvmci/jvmci_globals.cpp >>>>>>>>> >>>>>>>>> if (UseJVMCICompiler) { >>>>>>>>> + if (FLAG_IS_DEFAULT(UseJVMCINativeLibrary) && !UseJVMCINativeLibrary) { >>>>>>>>> + char path[JVM_MAXPATHLEN]; >>>>>>>>> + if (os::dll_locate_lib(path, sizeof(path), Arguments::get_dll_dir(), JVMCI_SHARED_LIBRARY_NAME)) { >>>>>>>>> + // If a JVMCI native library is present, >>>>>>>>> + // we enable UseJVMCINativeLibrary by default. >>>>>>>>> + FLAG_SET_DEFAULT(UseJVMCINativeLibrary, true); >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> >>>>>>>>> This change will affect use of JVMCI independent of whether EnableJVMCIProduct is set - was that intentional? >>>>>>>> Yes, the compiler team is ok with this additional functionality being available when UseJVMCICompiler is true >>>>>>>> independent of EnableJVMCIProduct. I?ve updated the RFE text to be clearer that this change is independent of >>>>>>>> the new flag. >>>>>>>>> >>>>>>>>> In JVMCIGlobals::enable_jvmci_product_mode, if we return false then argument processing will return JNI_ERR and the loading of the VM will terminate. It is not clear to me that the user would get any useful information regarding what failed. That said I can't really see what could actually fail in that code ... but perhaps a warning would be useful? >>>>>>>> Ok. >>>>>>>>> >>>>>>>>> I see where you clear the experimental bit, but as far as I can see that won't turn the flag into a product flag but will leave it uncategorised. ?? That probably works for you as you just need to ensure is_unlocked() returns true, but it does leave the flag in a strange state IMO. >>>>>>>> Thanks for that find, I assumed !experimental was product. I?ll add a set_product function and call it when I remove the experimental bit. >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/hotspot/share/runtime/arguments.cpp >>>>>>>>> >>>>>>>>> + #if INCLUDE_JVMCI >>>>>>>>> + } else if (match_option(option, "-XX:+EnableJVMCIProduct")) { >>>>>>>>> + JVMFlag *jvmciFlag = JVMFlag::find_flag("EnableJVMCIProduct"); >>>>>>>>> + // Allow this flag if it has been unlocked. >>>>>>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>>>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>>>>>> + return JNI_ERR; >>>>>>>>> + } >>>>>>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>>>>>> + if (!process_argument(tail, args->ignoreUnrecognized, origin)) { >>>>>>>>> + return JNI_EINVAL; >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> >>>>>>>>> It took me quite a while to understand that the point of >>>>>>>>> >>>>>>>>> + } else if (match_option(option, "-XX:", &tail)) { >>>>>>>>> >>>>>>>>> is purely to isolate the "EnableJVMCIProduct" part so that it can be processed by process_argument and report the expected error message that the flag has not been unlocked. I think it would be much clearer to just do that explicitly: >>>>>>>>> >>>>>>>>> + if (jvmciFlag != NULL && jvmciFlag->is_unlocked()) { >>>>>>>>> + if (!JVMCIGlobals::enable_jvmci_product_mode(origin)) { >>>>>>>>> + return JNI_ERR; >>>>>>>>> + } >>>>>>>>> + } >>>>>>>>> + // The flag was locked so process normally to report that error >>>>>>>>> + else if (!process_argument("EnableJVMCIProduct", args->ignoreUnrecognized, origin)) { >>>>>>>>> + return JNI_EINVAL; >>>>>>>>> + } >>>>>>>>> >>>>>>>>> >>>>>>>> Ok. >>>>>>>>> Also the whole else-if block you added appears to be missing the final } to close it. ?? >>>>>>>> Its on the next line after the #endif. This is how all the if cases are structures. >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> src/hotspot/share/runtime/flags/jvmFlag.cpp >>>>>>>>> >>>>>>>>> + case RESOURCE: >>>>>>>>> + st->print("resource"); break; >>>>>>>>> >>>>>>>>> src/hotspot/share/runtime/flags/jvmFlag.hpp >>>>>>>>> >>>>>>>>> ! RESOURCE = 7, >>>>>>>>> ! INTERNAL = 8, >>>>>>>>> >>>>>>>>> I think the RESOURCE changes are part of the other RFE. ?? >>>>>>>> Correct, these leaked in from another RFE and will be removed from my push. >>>>>>>> Thanks, >>>>>>>> Bob. >>>>>>>>> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> David >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> >>>>>>>>>> [1] Related RFE: https://bugs.openjdk.java.net/browse/JDK-8232080 >>>>>>>>>> Bob. >>> >> > From christian.hagedorn at oracle.com Tue Oct 29 07:02:52 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Tue, 29 Oct 2019 08:02:52 +0100 Subject: [14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" In-Reply-To: <4F9B6AED-C8C7-48EA-BB14-1B086E13D890@oracle.com> References: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> <0635964f-a093-074c-58d5-c4ce76703db5@oracle.com> <677e34c5-ff1f-aac1-efca-84c6f30c2c9b@oracle.com> <4F9B6AED-C8C7-48EA-BB14-1B086E13D890@oracle.com> Message-ID: <76cbfb8d-cb6a-c811-72b0-7b932c134c15@oracle.com> Thank you Vladimir for the review! Best regards, Christian On 28.10.19 16:26, Vladimir Kozlov wrote: > Okay, now I got it what was wrong with previous fix. Thank you for explaining. > The current fix is good. > > Thanks > Vladimir > >> On Oct 28, 2019, at 3:38 AM, Christian Hagedorn wrote: >> >> Hi Vladimir >> >> I don't think that the String class is unloaded. In the previous fix [6] I called clear_row() if either the klass 'k' was NULL or it was unloaded. This means that in my test case the MDO contains the String klass at row index 0 but the index 1 is empty, i.e. the klass is NULL. As a result, I cleared that counter with clear_row() by mistake when processing the row index 1 (since 'k' is NULL). My new fix will only set the klass to NULL with set_receiver(row, NULL) and will not clear the counter anymore. In my evaluation below I compared the previous fix [6] with my new fix. >> >> Best regards, >> Christian >> >> [6] http://cr.openjdk.java.net/~thartmann/8225670/webrev.00/ >> >>> On 26.10.19 00:12, Vladimir Kozlov wrote: >>> Yes, that is what I suspected. MDO had only one receiver and if we clean counter it will look like it is never called. >>> clear_row() assumes that at least one receiver is valid. >>> Hmm, but if the class is unloaded when we construct copy of MDO then this compilation is invalid anyway. Right? You need to get new profiling information after unloading to get correct MDO. >>> If one klass in MDO call site is still valid we can still compile and have uncommon trap for second case. But if no valid klass is recorded in MDO call site (all were nulled) we can't compile it based on counter. We should bailout and re-collect profiling info or generate uncommon trap instead of call. For later we have to separate cases when the site is never called or it was called but classes later were unloaded. hmm, C2 actually should generate uncommon trap if class is unloaded. Why classes are unloaded in a first place? >>> Can you tell why class is unloaded in your test case? It is String!!! Or more accurate why clear_row() was called? >>> Thanks, >>> Vladimir >>>> On 10/25/19 10:18 AM, Christian Hagedorn wrote: >>>> Hi Vladimir >>>> >>>> Thank you for your review! >>>> >>>>> On 24.10.19 18:55, Vladimir Kozlov wrote: >>>>> I would like to see what happens with MDO data with Tobias fix which caused regression. If it is simple. May be from LogCompilation. >>>> >>>>> The only explanation I can think of if we had only one receiver in MDO which we cleaned up and it confuse C2 to treat call site as never executed [3] so that it can't use speculative_receiver_type which come from other data >>>> It was actually my fix. I've tried to come up with a test case where the regression can easily be seen. I found the following example which shows the benefit of not clearing the counter with clear_row(): >>>> >>>> public void test() { >>>> String s = "test"; >>>> for (int i = 0; i < 1_000_000; i++ ) { >>>> s.replace("e", "t"); // Just a big enough method that does not get inlined by default >>>> } >>>> } >>>> >>>> If we use clear_row(), then String::replace is not inlined: >>>> >>>> org.sample.ClearRow::test @ 5 (27 bytes) made not entrant >>>> @ 16 java.lang.String::replace (255 bytes) too big >>>> >>>> The MDO counter for String::replace is reset to zero. This profile information is passed to ok_to_inline [1] and the zeroed counter is eventually read at [2]. The following frequency check [3] fails and thus InlineTree::should_inline returns false because the method is too big (and wrongly assumed to be never called). >>>> >>>> However, if we just use set_receiver(row, NULL) instead of clear_row(), which does not reset the counter, then call_site_count is big number greater than zero at [2] and the check at [3] succeeds. The maximum inline size is increased to FreqInlineSize (325 by default). Therefore String::replace is inlined: >>>> >>>> org.sample.ClearRow::test @ 5 (27 bytes) made not entrant >>>> @ 16 java.lang.String::replace (255 bytes) inline (hot) >>>> >>>> >>>> I also quickly put it into a local JMH benchmark. It can clearly be seen that not clearing the counter is beneficial: >>>> >>>> set_receiver(row, NULL): >>>> Benchmark Mode Cnt Score Error Units >>>> ClearRow.test thrpt 5 42.810 ? 1.572 ops/s >>>> >>>> clear_row(): >>>> Benchmark Mode Cnt Score Error Units >>>> ClearRow.test thrpt 5 32.658 ? 1.267 ops/s >>>> >>>> >>>> There are other cases, for example by using HashMap::put instead, in which call_does_dispatch is true [4]. It then skips directly to your mentioned check at [5]. The check succeeds having a non reset counter and the speculative_receiver_type can be used to inline the method. >>>> >>>> >>>> So I guess we've seen large performance regressions due to many such missed inline opportunities due to lost/wrong profiling information. >>>> >>>> Best regards, >>>> Christian >>>> >>>> >>>> [1] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l171 >>>> [2] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l163 >>>> [3] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l170 >>>> [4] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l167 >>>> [5] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l205 > From david.holmes at oracle.com Tue Oct 29 07:42:08 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Oct 2019 17:42:08 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination Message-ID: Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code. This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward: - old scheme - interrupted field is in osThread - VM can read/write directly - Java code calls into VM to read/write - new scheme - interrupted field is in java.lang.Thread - VM has to use javaCalls to read/write "directly" - Java code can read/write directly No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard! Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this. Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2. The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt: ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java Testing: - Tiers 1-3 on all Oracle platforms - Focused testing on Linux x64: - Stress runs of JSR166TestCase - Anything that seems to use interrupt(): - JDK - java/lang/Thread - java/util/concurrent - jdk/internal/loader/InterruptedClassLoad.java - javax/management - java/nio/file/Files - java/nio/channels - java/net/Socket/Timeouts.java - java/lang/Runtime/shutdown/ - java/lang/ProcessBuilder/Basic.java - com/sun/jdi/ - Hotspot - vmTestbase/nsk/monitoring/ - vmTestbase/nsk/jdwp - vmTestbase/nsk/jdb/ - vmTestbase/nsk/jdi/ - vmTestbase/nsk/jvmti/ - runtime/Thread - serviceability/jvmti/ - serviceability/jdwp - serviceability/sa Thanks, David ----- From doug.simon at oracle.com Tue Oct 29 08:55:56 2019 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 29 Oct 2019 09:55:56 +0100 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: References: Message-ID: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> Hi David, Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing: diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java index 0752a621215..baa2136a6ba 100644 --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase { public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor"); public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE); public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop"); - public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*"); + public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE); public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int"); public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop"); public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*"); diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java index 6b37fff083d..ffc8032d2b0 100644 --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins { } }); - r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); + if (config.osThreadOffset != Integer.MAX_VALUE) { + r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); + } } public static final String reflectionClass; diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java index 1d694fae2a4..8500c4de115 100644 --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil { @Fold public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) { + assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE; return config.osThreadOffset; } All the other JVMCI changes look good to me. -Doug > On 29 Oct 2019, at 08:42, David Holmes wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) > webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ > > This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code. > > This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward: > > - old scheme > - interrupted field is in osThread > - VM can read/write directly > - Java code calls into VM to read/write > > - new scheme > - interrupted field is in java.lang.Thread > - VM has to use javaCalls to read/write "directly" > - Java code can read/write directly > > No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard! > > Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this. > > Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2. > > The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt: > > ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java > > Testing: > - Tiers 1-3 on all Oracle platforms > - Focused testing on Linux x64: > - Stress runs of JSR166TestCase > - Anything that seems to use interrupt(): > - JDK > - java/lang/Thread > - java/util/concurrent > - jdk/internal/loader/InterruptedClassLoad.java > - javax/management > - java/nio/file/Files > - java/nio/channels > - java/net/Socket/Timeouts.java > - java/lang/Runtime/shutdown/ > - java/lang/ProcessBuilder/Basic.java > - com/sun/jdi/ > - Hotspot > - vmTestbase/nsk/monitoring/ > - vmTestbase/nsk/jdwp > - vmTestbase/nsk/jdb/ > - vmTestbase/nsk/jdi/ > - vmTestbase/nsk/jvmti/ > - runtime/Thread > - serviceability/jvmti/ > - serviceability/jdwp > - serviceability/sa > > Thanks, > David > ----- From david.holmes at oracle.com Tue Oct 29 09:12:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Tue, 29 Oct 2019 19:12:01 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> References: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> Message-ID: <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> Hi Doug, Thanks for taking a look so quickly! :) On 29/10/2019 6:55 pm, Doug Simon wrote: > Hi David, > > Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing: So to be clear I should revert all the Graal file changes I made and just apply the patch below? Thanks, David ----- > diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > index 0752a621215..baa2136a6ba 100644 > --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase { > public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor"); > public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE); > public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop"); > - public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*"); > + public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE); > public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int"); > public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop"); > public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*"); > diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java > index 6b37fff083d..ffc8032d2b0 100644 > --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java > +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java > @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins { > } > }); > > - r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); > + if (config.osThreadOffset != Integer.MAX_VALUE) { > + r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); > + } > } > > public static final String reflectionClass; > diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java > index 1d694fae2a4..8500c4de115 100644 > --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java > +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java > @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil { > > @Fold > public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) { > + assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE; > return config.osThreadOffset; > } > > All the other JVMCI changes look good to me. > > -Doug > >> On 29 Oct 2019, at 08:42, David Holmes wrote: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) >> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >> >> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code. >> >> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward: >> >> - old scheme >> - interrupted field is in osThread >> - VM can read/write directly >> - Java code calls into VM to read/write >> >> - new scheme >> - interrupted field is in java.lang.Thread >> - VM has to use javaCalls to read/write "directly" >> - Java code can read/write directly >> >> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard! >> >> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this. >> >> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2. >> >> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt: >> >> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >> >> Testing: >> - Tiers 1-3 on all Oracle platforms >> - Focused testing on Linux x64: >> - Stress runs of JSR166TestCase >> - Anything that seems to use interrupt(): >> - JDK >> - java/lang/Thread >> - java/util/concurrent >> - jdk/internal/loader/InterruptedClassLoad.java >> - javax/management >> - java/nio/file/Files >> - java/nio/channels >> - java/net/Socket/Timeouts.java >> - java/lang/Runtime/shutdown/ >> - java/lang/ProcessBuilder/Basic.java >> - com/sun/jdi/ >> - Hotspot >> - vmTestbase/nsk/monitoring/ >> - vmTestbase/nsk/jdwp >> - vmTestbase/nsk/jdb/ >> - vmTestbase/nsk/jdi/ >> - vmTestbase/nsk/jvmti/ >> - runtime/Thread >> - serviceability/jvmti/ >> - serviceability/jdwp >> - serviceability/sa >> >> Thanks, >> David >> ----- > From doug.simon at oracle.com Tue Oct 29 09:14:02 2019 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 29 Oct 2019 10:14:02 +0100 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> References: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> Message-ID: > On 29 Oct 2019, at 10:12, David Holmes wrote: > > Hi Doug, > > Thanks for taking a look so quickly! :) > > On 29/10/2019 6:55 pm, Doug Simon wrote: >> Hi David, >> Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing: > > So to be clear I should revert all the Graal file changes I made and just apply the patch below? Yes please. -Doug > >> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >> index 0752a621215..baa2136a6ba 100644 >> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase { >> public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor"); >> public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE); >> public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop"); >> - public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*"); >> + public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE); >> public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int"); >> public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop"); >> public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*"); >> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >> index 6b37fff083d..ffc8032d2b0 100644 >> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins { >> } >> }); >> - r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); >> + if (config.osThreadOffset != Integer.MAX_VALUE) { >> + r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); >> + } >> } >> public static final String reflectionClass; >> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >> index 1d694fae2a4..8500c4de115 100644 >> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil { >> @Fold >> public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) { >> + assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE; >> return config.osThreadOffset; >> } >> All the other JVMCI changes look good to me. >> -Doug >>> On 29 Oct 2019, at 08:42, David Holmes wrote: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) >>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >>> >>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code. >>> >>> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward: >>> >>> - old scheme >>> - interrupted field is in osThread >>> - VM can read/write directly >>> - Java code calls into VM to read/write >>> >>> - new scheme >>> - interrupted field is in java.lang.Thread >>> - VM has to use javaCalls to read/write "directly" >>> - Java code can read/write directly >>> >>> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard! >>> >>> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this. >>> >>> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2. >>> >>> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt: >>> >>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >>> >>> Testing: >>> - Tiers 1-3 on all Oracle platforms >>> - Focused testing on Linux x64: >>> - Stress runs of JSR166TestCase >>> - Anything that seems to use interrupt(): >>> - JDK >>> - java/lang/Thread >>> - java/util/concurrent >>> - jdk/internal/loader/InterruptedClassLoad.java >>> - javax/management >>> - java/nio/file/Files >>> - java/nio/channels >>> - java/net/Socket/Timeouts.java >>> - java/lang/Runtime/shutdown/ >>> - java/lang/ProcessBuilder/Basic.java >>> - com/sun/jdi/ >>> - Hotspot >>> - vmTestbase/nsk/monitoring/ >>> - vmTestbase/nsk/jdwp >>> - vmTestbase/nsk/jdb/ >>> - vmTestbase/nsk/jdi/ >>> - vmTestbase/nsk/jvmti/ >>> - runtime/Thread >>> - serviceability/jvmti/ >>> - serviceability/jdwp >>> - serviceability/sa >>> >>> Thanks, >>> David >>> ----- From aph at redhat.com Tue Oct 29 09:32:47 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Oct 2019 09:32:47 +0000 Subject: RFR(xs): java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: References: Message-ID: <5b551a83-3896-a1f6-0a24-d4b0ee19aebd@redhat.com> On 10/26/19 8:10 AM, Thomas St?fe wrote: > Yes, that might be clearer. I probably still would have to fix up > LIR_Assembler::comp_op() for more than just x86, since most would not work > for comparisons with T_ADDRESS constants. I think this is just a problem for x86. We don't do anything like that on AArch64, and we always generate a full-width comparison: void LIR_Assembler::comp_op(LIR_Condition condition, LIR_Opr opr1, LIR_Opr opr2, LIR_Op2* op) { ... if (opr2->is_constant()) { ... switch(opr2->type()) { ... case T_OBJECT: case T_ARRAY: jobject2reg(opr2->as_constant_ptr()->as_jobject(), rscratch1); __ cmpoop(reg1, rscratch1); -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Oct 29 09:33:23 2019 From: aph at redhat.com (Andrew Haley) Date: Tue, 29 Oct 2019 09:33:23 +0000 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> Message-ID: <5fe09111-cd87-cb53-19ac-e45367a5d490@redhat.com> On 10/28/19 9:48 AM, Pengfei Li (Arm Technology China) wrote: > Is another reviewer required for this change? If not, @Ningsheng Jian (Arm Technology China) could you help to push? Please push. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Tue Oct 29 10:11:06 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 29 Oct 2019 11:11:06 +0100 Subject: RFR(xs): java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: <5b551a83-3896-a1f6-0a24-d4b0ee19aebd@redhat.com> References: <5b551a83-3896-a1f6-0a24-d4b0ee19aebd@redhat.com> Message-ID: Hi Andrew, On Tue, Oct 29, 2019 at 10:32 AM Andrew Haley wrote: > On 10/26/19 8:10 AM, Thomas St?fe wrote: > > Yes, that might be clearer. I probably still would have to fix up > > LIR_Assembler::comp_op() for more than just x86, since most would not > work > > for comparisons with T_ADDRESS constants. > > I think this is just a problem for x86. We don't do anything like that > on AArch64, and we always generate a full-width comparison: > > void LIR_Assembler::comp_op(LIR_Condition condition, LIR_Opr opr1, LIR_Opr > opr2, LIR_Op2* op) { > ... > if (opr2->is_constant()) { > ... > switch(opr2->type()) { > ... > case T_OBJECT: > case T_ARRAY: > jobject2reg(opr2->as_constant_ptr()->as_jobject(), rscratch1); > __ cmpoop(reg1, rscratch1); > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > Thanks for looking at this. I'm not sure this is true though. The generic code compares a register with an int constant: // java.lang.Class::isPrimitive() void LIRGenerator::do_isPrimitive(Intrinsic* x) { ..... __ cmp(lir_cond_notEqual, temp, LIR_OprFact::intConst(0)); ..... } so would we not hit the T_INT path in LIR_Assembler::comp_op() and compare with a 32bit value? void LIR_Assembler::comp_op(LIR_Condition condition, LIR_Opr opr1, LIR_Opr opr2, LIR_Op2* op) { ... } else if (opr1->is_single_cpu() || opr1->is_double_cpu()) { Register reg1 = as_reg(opr1); if (opr2->is_single_cpu()) { ... if (opr2->is_constant()) { bool is_32bit = false; // width of register operand jlong imm; switch(opr2->type()) { case T_INT: imm = opr2->as_constant_ptr()->as_jint(); is_32bit = true; break; ... My current fix makes this constant a metadata constant and adds comparisons to T_METASPACE constants. I had to "dry-code" the aarch64 part, could you please take a look whether this makes sense to you? http://cr.openjdk.java.net/~stuefe/webrevs/8233019--c1-intrinsic-for-java.lang.class.isprimitive()-does-32bit-compare/webrev.00/webrev/ Thanks, Thomas From tobias.hartmann at oracle.com Tue Oct 29 11:16:17 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 29 Oct 2019 12:16:17 +0100 Subject: [14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" In-Reply-To: <76cbfb8d-cb6a-c811-72b0-7b932c134c15@oracle.com> References: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> <0635964f-a093-074c-58d5-c4ce76703db5@oracle.com> <677e34c5-ff1f-aac1-efca-84c6f30c2c9b@oracle.com> <4F9B6AED-C8C7-48EA-BB14-1B086E13D890@oracle.com> <76cbfb8d-cb6a-c811-72b0-7b932c134c15@oracle.com> Message-ID: <19ed063c-53a7-34a0-e27f-83d2950bb4b0@oracle.com> Hi Christian, this looks good to me too. Thanks for these detailed explanations. Best regards, Tobias On 29.10.19 08:02, Christian Hagedorn wrote: > Thank you Vladimir for the review! > > Best regards, > Christian > > On 28.10.19 16:26, Vladimir Kozlov wrote: >> Okay, now I got it what was wrong with previous fix. Thank you for explaining. >> The current fix is good. >> >> Thanks >> Vladimir >> >>> On Oct 28, 2019, at 3:38 AM, Christian Hagedorn wrote: >>> >>> Hi Vladimir >>> >>> I don't think that the String class is unloaded. In the previous fix [6] I called clear_row() if >>> either the klass 'k' was NULL or it was unloaded. This means that in my test case the MDO >>> contains the String klass at row index 0 but the index 1 is empty, i.e. the klass is NULL. As a >>> result, I cleared that counter with clear_row() by mistake when processing the row index 1 (since >>> 'k' is NULL). My new fix will only set the klass to NULL with set_receiver(row, NULL) and will >>> not clear the counter anymore. In my evaluation below I compared the previous fix [6] with my new >>> fix. >>> >>> Best regards, >>> Christian >>> >>> [6] http://cr.openjdk.java.net/~thartmann/8225670/webrev.00/ >>> >>>> On 26.10.19 00:12, Vladimir Kozlov wrote: >>>> Yes, that is what I suspected. MDO had only one receiver and if we clean counter it will look >>>> like it is never called. >>>> clear_row() assumes that at least one receiver is valid. >>>> Hmm, but if the class is unloaded when we construct copy of MDO then this compilation is invalid >>>> anyway. Right? You need to get new profiling information after unloading to get correct MDO. >>>> If one klass in MDO call site is still valid we can still compile and have uncommon trap for >>>> second case. But if no valid klass is recorded in MDO call site (all were nulled) we can't >>>> compile it based on counter. We should bailout and re-collect profiling info or generate >>>> uncommon trap instead of call. For later we have to separate cases when the site is never called >>>> or it was called but classes later were unloaded. hmm, C2 actually should generate uncommon trap >>>> if class is unloaded. Why classes are unloaded in a first place? >>>> Can you tell why class is unloaded in your test case? It is String!!! Or more accurate why >>>> clear_row() was called? >>>> Thanks, >>>> Vladimir >>>>> On 10/25/19 10:18 AM, Christian Hagedorn wrote: >>>>> Hi Vladimir >>>>> >>>>> Thank you for your review! >>>>> >>>>>> On 24.10.19 18:55, Vladimir Kozlov wrote: >>>>>> I would like to see what happens with MDO data with Tobias fix which caused regression. If it >>>>>> is simple. May be from LogCompilation. >>>>> >>>>>> The only explanation I can think of if we had only one receiver in MDO which we cleaned up and >>>>>> it confuse C2 to treat call site as never executed [3] so that it can't use >>>>>> speculative_receiver_type which come from other data >>>>> It was actually my fix. I've tried to come up with a test case where the regression can easily >>>>> be seen. I found the following example which shows the benefit of not clearing the counter with >>>>> clear_row(): >>>>> >>>>> ????? public void test() { >>>>> ????????? String s = "test"; >>>>> ????????? for (int i = 0; i < 1_000_000; i++ ) { >>>>> ????????????? s.replace("e", "t"); // Just a big enough method that does not get inlined by >>>>> default >>>>> ????????? } >>>>> ????? } >>>>> >>>>> If we use clear_row(), then String::replace is not inlined: >>>>> >>>>> org.sample.ClearRow::test @ 5 (27 bytes)?? made not entrant >>>>> ??? @ 16?? java.lang.String::replace (255 bytes)?? too big >>>>> >>>>> The MDO counter for String::replace is reset to zero. This profile information is passed to >>>>> ok_to_inline [1] and the zeroed counter is eventually read at [2]. The following frequency >>>>> check [3] fails and thus InlineTree::should_inline returns false because the method is too big >>>>> (and wrongly assumed to be never called). >>>>> >>>>> However, if we just use set_receiver(row, NULL) instead of clear_row(), which does not reset >>>>> the counter, then call_site_count is big number greater than zero at [2] and the check at [3] >>>>> succeeds. The maximum inline size is increased to FreqInlineSize (325 by default). Therefore >>>>> String::replace is inlined: >>>>> >>>>> org.sample.ClearRow::test @ 5 (27 bytes)?? made not entrant >>>>> ??? @ 16?? java.lang.String::replace (255 bytes)?? inline (hot) >>>>> >>>>> >>>>> I also quickly put it into a local JMH benchmark. It can clearly be seen that not clearing the >>>>> counter is beneficial: >>>>> >>>>> set_receiver(row, NULL): >>>>> Benchmark?????? Mode? Cnt?? Score?? Error? Units >>>>> ClearRow.test? thrpt??? 5? 42.810 ? 1.572? ops/s >>>>> >>>>> clear_row(): >>>>> Benchmark?????? Mode? Cnt?? Score?? Error? Units >>>>> ClearRow.test? thrpt??? 5? 32.658 ? 1.267? ops/s >>>>> >>>>> >>>>> There are other cases, for example by using HashMap::put instead, in which call_does_dispatch >>>>> is true [4]. It then skips directly to your mentioned check at [5]. The check succeeds having a >>>>> non reset counter and the speculative_receiver_type can be used to inline the method. >>>>> >>>>> >>>>> So I guess we've seen large performance regressions due to many such missed inline >>>>> opportunities due to lost/wrong profiling information. >>>>> >>>>> Best regards, >>>>> Christian >>>>> >>>>> >>>>> [1] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l171 >>>>> [2] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l163 >>>>> [3] >>>>> http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l170 >>>>> [4] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l167 >>>>> [5] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l205 >> From tobias.hartmann at oracle.com Tue Oct 29 11:17:36 2019 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 29 Oct 2019 12:17:36 +0100 Subject: RFR(S): 8231565: More node budget assert in fuzzed test In-Reply-To: <6e699706-905c-79df-4fa3-0f8bcb3dc6d2@oracle.com> References: <7a0b347a-02f3-b841-82eb-f0887fd6d7f3@oracle.com> <11bd5e70-9e0d-9df9-d345-a9d1ba0b30e5@oracle.com> <6e699706-905c-79df-4fa3-0f8bcb3dc6d2@oracle.com> Message-ID: <93720616-d3b4-be11-a808-b2df7ec377bc@oracle.com> On 25.10.19 10:59, Patric Hedlin wrote: > Fixed. Thanks, ship it! Best regards, Tobias From christian.hagedorn at oracle.com Tue Oct 29 13:18:03 2019 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Tue, 29 Oct 2019 14:18:03 +0100 Subject: [14] RFR(S): 8230019: [REDO] compiler/types/correctness/* tests fail with "assert(recv == __null || recv->is_klass()) failed: wrong type" In-Reply-To: <19ed063c-53a7-34a0-e27f-83d2950bb4b0@oracle.com> References: <7c61fd36-8442-86a1-c034-5e19882b8336@oracle.com> <0635964f-a093-074c-58d5-c4ce76703db5@oracle.com> <677e34c5-ff1f-aac1-efca-84c6f30c2c9b@oracle.com> <4F9B6AED-C8C7-48EA-BB14-1B086E13D890@oracle.com> <76cbfb8d-cb6a-c811-72b0-7b932c134c15@oracle.com> <19ed063c-53a7-34a0-e27f-83d2950bb4b0@oracle.com> Message-ID: <4bdd2acc-b3ce-f2cf-814b-43e836e8be9b@oracle.com> Thank you for the review Tobias! Best regards, Christian On 29.10.19 12:16, Tobias Hartmann wrote: > Hi Christian, > > this looks good to me too. Thanks for these detailed explanations. > > Best regards, > Tobias > > On 29.10.19 08:02, Christian Hagedorn wrote: >> Thank you Vladimir for the review! >> >> Best regards, >> Christian >> >> On 28.10.19 16:26, Vladimir Kozlov wrote: >>> Okay, now I got it what was wrong with previous fix. Thank you for explaining. >>> The current fix is good. >>> >>> Thanks >>> Vladimir >>> >>>> On Oct 28, 2019, at 3:38 AM, Christian Hagedorn wrote: >>>> >>>> Hi Vladimir >>>> >>>> I don't think that the String class is unloaded. In the previous fix [6] I called clear_row() if >>>> either the klass 'k' was NULL or it was unloaded. This means that in my test case the MDO >>>> contains the String klass at row index 0 but the index 1 is empty, i.e. the klass is NULL. As a >>>> result, I cleared that counter with clear_row() by mistake when processing the row index 1 (since >>>> 'k' is NULL). My new fix will only set the klass to NULL with set_receiver(row, NULL) and will >>>> not clear the counter anymore. In my evaluation below I compared the previous fix [6] with my new >>>> fix. >>>> >>>> Best regards, >>>> Christian >>>> >>>> [6] http://cr.openjdk.java.net/~thartmann/8225670/webrev.00/ >>>> >>>>> On 26.10.19 00:12, Vladimir Kozlov wrote: >>>>> Yes, that is what I suspected. MDO had only one receiver and if we clean counter it will look >>>>> like it is never called. >>>>> clear_row() assumes that at least one receiver is valid. >>>>> Hmm, but if the class is unloaded when we construct copy of MDO then this compilation is invalid >>>>> anyway. Right? You need to get new profiling information after unloading to get correct MDO. >>>>> If one klass in MDO call site is still valid we can still compile and have uncommon trap for >>>>> second case. But if no valid klass is recorded in MDO call site (all were nulled) we can't >>>>> compile it based on counter. We should bailout and re-collect profiling info or generate >>>>> uncommon trap instead of call. For later we have to separate cases when the site is never called >>>>> or it was called but classes later were unloaded. hmm, C2 actually should generate uncommon trap >>>>> if class is unloaded. Why classes are unloaded in a first place? >>>>> Can you tell why class is unloaded in your test case? It is String!!! Or more accurate why >>>>> clear_row() was called? >>>>> Thanks, >>>>> Vladimir >>>>>> On 10/25/19 10:18 AM, Christian Hagedorn wrote: >>>>>> Hi Vladimir >>>>>> >>>>>> Thank you for your review! >>>>>> >>>>>>> On 24.10.19 18:55, Vladimir Kozlov wrote: >>>>>>> I would like to see what happens with MDO data with Tobias fix which caused regression. If it >>>>>>> is simple. May be from LogCompilation. >>>>>> >>>>>>> The only explanation I can think of if we had only one receiver in MDO which we cleaned up and >>>>>>> it confuse C2 to treat call site as never executed [3] so that it can't use >>>>>>> speculative_receiver_type which come from other data >>>>>> It was actually my fix. I've tried to come up with a test case where the regression can easily >>>>>> be seen. I found the following example which shows the benefit of not clearing the counter with >>>>>> clear_row(): >>>>>> >>>>>> ????? public void test() { >>>>>> ????????? String s = "test"; >>>>>> ????????? for (int i = 0; i < 1_000_000; i++ ) { >>>>>> ????????????? s.replace("e", "t"); // Just a big enough method that does not get inlined by >>>>>> default >>>>>> ????????? } >>>>>> ????? } >>>>>> >>>>>> If we use clear_row(), then String::replace is not inlined: >>>>>> >>>>>> org.sample.ClearRow::test @ 5 (27 bytes)?? made not entrant >>>>>> ??? @ 16?? java.lang.String::replace (255 bytes)?? too big >>>>>> >>>>>> The MDO counter for String::replace is reset to zero. This profile information is passed to >>>>>> ok_to_inline [1] and the zeroed counter is eventually read at [2]. The following frequency >>>>>> check [3] fails and thus InlineTree::should_inline returns false because the method is too big >>>>>> (and wrongly assumed to be never called). >>>>>> >>>>>> However, if we just use set_receiver(row, NULL) instead of clear_row(), which does not reset >>>>>> the counter, then call_site_count is big number greater than zero at [2] and the check at [3] >>>>>> succeeds. The maximum inline size is increased to FreqInlineSize (325 by default). Therefore >>>>>> String::replace is inlined: >>>>>> >>>>>> org.sample.ClearRow::test @ 5 (27 bytes)?? made not entrant >>>>>> ??? @ 16?? java.lang.String::replace (255 bytes)?? inline (hot) >>>>>> >>>>>> >>>>>> I also quickly put it into a local JMH benchmark. It can clearly be seen that not clearing the >>>>>> counter is beneficial: >>>>>> >>>>>> set_receiver(row, NULL): >>>>>> Benchmark?????? Mode? Cnt?? Score?? Error? Units >>>>>> ClearRow.test? thrpt??? 5? 42.810 ? 1.572? ops/s >>>>>> >>>>>> clear_row(): >>>>>> Benchmark?????? Mode? Cnt?? Score?? Error? Units >>>>>> ClearRow.test? thrpt??? 5? 32.658 ? 1.267? ops/s >>>>>> >>>>>> >>>>>> There are other cases, for example by using HashMap::put instead, in which call_does_dispatch >>>>>> is true [4]. It then skips directly to your mentioned check at [5]. The check succeeds having a >>>>>> non reset counter and the speculative_receiver_type can be used to inline the method. >>>>>> >>>>>> >>>>>> So I guess we've seen large performance regressions due to many such missed inline >>>>>> opportunities due to lost/wrong profiling information. >>>>>> >>>>>> Best regards, >>>>>> Christian >>>>>> >>>>>> >>>>>> [1] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l171 >>>>>> [2] >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l163 >>>>>> [3] >>>>>> http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/bytecodeInfo.cpp#l170 >>>>>> [4] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l167 >>>>>> [5] http://hg.openjdk.java.net/jdk/jdk/file/18c246ad2ff9/src/hotspot/share/opto/doCall.cpp#l205 >>> From martin.doerr at sap.com Tue Oct 29 14:09:43 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Oct 2019 14:09:43 +0000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <3298F64A-E975-4271-A42E-D6B9DACEFA94@oracle.com> References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> <3298F64A-E975-4271-A42E-D6B9DACEFA94@oracle.com> Message-ID: Hi Kim, > src/hotspot/share/compiler/compileBroker.cpp > 948 assert(compiler2_object(i) = NULL, "Old one must be released!?); > > That should be ?==? rather than ?=?. Nice one ?? Fixed. Alright, thanks again for your input related to the handle usage. I guess we don't need to keep you in the loop for the other stuff. Best regards, Martin > -----Original Message----- > From: Kim Barrett > Sent: Montag, 28. Oktober 2019 20:40 > To: Doerr, Martin > Cc: David Holmes ; Vladimir Kozlov > (vladimir.kozlov at oracle.com) ; hotspot- > compiler-dev at openjdk.java.net > Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread > > > On Oct 28, 2019, at 10:06 AM, Doerr, Martin > wrote: > > @Kim: > > Thanks for looking at the handle related parts. It's ok if you don't want to > be a reviewer of the whole change. > > I?ll reply to the pending parts, and drop out. I think the handle related parts > are > going in the right direction now. > > >> I think it's weird that can_remove() is a predicate with optional side > >> effects. I think it would be simpler to have it be a pure predicate, > >> and have the one caller with do_it = true perform the updates. That > >> should include NULLing out the handle pointer (perhaps debug-only, but > >> it doesn't cost much to cleanly maintain the data structure). > > Nevertheless, it has the advantage that it enforces the update to be > consistent. > > A caller could use it without holding the lock or mess it up otherwise. > > In addition, I don't what to change that as part of this fix. > > Understood, though I think I recall the caller with do_it = true is holding the > appropriate lock > around the call. > > >> So far as I can tell, THREAD == NULL here. > > This is a very tricky part (not my invention): > > EXCEPTION_MARK contains an ExceptionMark constructor call which sets > __the_thread__ to Thread::current(). > > I don't want to publish my opinion about this ?? > > Oh, that?s interesting? I know exceptions.hpp contains some exciting code, > but I?ve so > far avoided looking at it closely. That stuff doesn?t come up much in gc code > :) > > > @David: > > Seems like this option is preferred over option 3 > (possibly_add_compiler_threads part of webrev.02 and leave the > initialization as is). > > So when you're ok with it, I'll request a 2nd review from the compiler folks > (I should change the subject to contain RFR). > > Handle usage here looks okay to me now. I think JVMCI global handles could > be used instead, > but I?ll leave that up to others. From martin.doerr at sap.com Tue Oct 29 15:17:46 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 29 Oct 2019 15:17:46 +0000 Subject: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread Message-ID: Hi, after some discussions with David and Kim, I think we have a direction to go forward. The discussion in the bug and on the mailing list is pretty long: https://bugs.openjdk.java.net/browse/JDK-8230459 http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-October/035462.html To make long story short, I suggest to create new j.l.Thread objects only for JVMCI threads when (re)starting more threads on demand. This avoids such issues with observable thread state transitions etc. This is my current proposal: http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.03/ Please review. Best regard, Martin From serguei.spitsyn at oracle.com Tue Oct 29 18:05:50 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 29 Oct 2019 11:05:50 -0700 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: References: Message-ID: Hi David, The fix looks good to me. I did not pay much attention to the Graal related changes though. The test coverage for Serviceability is complete. Running java/lang/instrument tests is not necessary. Thanks, Serguei On 10/29/19 00:42, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) > webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ > > This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but > only in small pieces each. There is also a small touch to > serviceability code. > > This change is "simply" moving the "interrupted" field out of the > osThread and into the java.lang.Thread so that it can be set > independently of whether the thread is alive (and to make things > easier for loom in the near future). It is very straightforward: > > - old scheme > ? - interrupted field is in osThread > ? - VM can read/write directly > ? - Java code calls into VM to read/write > > - new scheme > ? - interrupted field is in java.lang.Thread > ? - VM has to use javaCalls to read/write "directly" > ? - Java code can read/write directly > > No changes to any of the semantics regarding the actual interrupt > mechanism. Special thanks to Patricio for tracking down a bug I had > introduced in that regard! > > Special Note (Hi Roger!): on windows we still need to set/clear the > _interrupt_event used by the Process.waitFor logic. To facilitate > clearing via Thread.interrupted() I had to introduce a native method > that is a no-op except on Windows. This seemed the cheapest and least > intrusive means to achieve this. > > Other changes revolve around the fact we used to have an intrinsic for > Thread.isInterrupted and that is not needed any more. So we strip some > code out of C1/C2. > > The changes in the JVMCI/Graal code are a bit more far reaching as > entire classes disappear. I've cc'd Doug and Tom at Vladimir's request > so that they can comment on the JVMCI changes and whether I have gone > too far or not far enough. There are a bunch of tests for interruption > in JVMCI that could potentially be deleted if they are only intended > to test the JVMCI handling of interrupt: > > ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java > > > Testing: > ?- Tiers 1-3 on all Oracle platforms > ?- Focused testing on Linux x64: > ??? - Stress runs of JSR166TestCase > ??? - Anything that seems to use interrupt(): > ????? - JDK > ??????? - java/lang/Thread > ??????? - java/util/concurrent > ??????? - jdk/internal/loader/InterruptedClassLoad.java > ??????? - javax/management > ??????? - java/nio/file/Files > ??????? - java/nio/channels > ??????? - java/net/Socket/Timeouts.java > ??????? - java/lang/Runtime/shutdown/ > ??????? - java/lang/ProcessBuilder/Basic.java > ??????? - com/sun/jdi/ > ????? - Hotspot > ??????? - vmTestbase/nsk/monitoring/ > ??????? - vmTestbase/nsk/jdwp > ??????? - vmTestbase/nsk/jdb/ > ??????? - vmTestbase/nsk/jdi/ > ??????? - vmTestbase/nsk/jvmti/ > ??????? - runtime/Thread > ??????? - serviceability/jvmti/ > ??????? - serviceability/jdwp > ??????? - serviceability/sa > > Thanks, > David > ----- From daniel.daugherty at oracle.com Tue Oct 29 20:51:21 2019 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 29 Oct 2019 16:51:21 -0400 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: References: Message-ID: <422bc3b5-861f-0c86-0878-1ba392b342b1@oracle.com> On 10/29/19 3:42 AM, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) > webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ make/hotspot/symbols/symbols-unix ??? No comments. src/hotspot/os/windows/osThread_windows.cpp ??? No comments. src/hotspot/os/windows/osThread_windows.hpp ??? No comments. src/hotspot/share/aot/aotCodeHeap.cpp ??? Skipped. src/hotspot/share/classfile/javaClasses.cpp ??? No comments. src/hotspot/share/classfile/javaClasses.hpp ??? No comments. src/hotspot/share/classfile/vmSymbols.cpp ??? No comments. src/hotspot/share/classfile/vmSymbols.hpp ??? No comments. src/hotspot/share/include/jvm.h ??? No comments. src/hotspot/share/jvmci/jvmciRuntime.cpp src/hotspot/share/jvmci/jvmciRuntime.hpp src/hotspot/share/jvmci/vmStructs_jvmci.cpp ??? Skipped these three. src/hotspot/share/oops/oop.hpp ??? No comments. src/hotspot/share/oops/oop.inline.hpp ??? No comments. src/hotspot/share/opto/c2compiler.cpp ??? No comments. src/hotspot/share/opto/library_call.cpp ??? No comments. src/hotspot/share/prims/jvm.cpp ??? No comments. src/hotspot/share/prims/jvmtiEnv.cpp ??? No comments. src/hotspot/share/prims/jvmtiEnvBase.cpp ??? No comments. src/hotspot/share/runtime/osThread.cpp ??? No comments. src/hotspot/share/runtime/osThread.hpp ??? No comments. src/hotspot/share/runtime/thread.cpp ??? No comments. src/hotspot/share/runtime/vmStructs.cpp ??? No comments. src/java.base/share/classes/java/lang/Thread.java ??? No comments. src/java.base/share/native/libjava/Thread.c ??? L76: ? // Need to reset the interrupt event used by Process.waitFor ??? L77: ? ResetEvent((HANDLE) JVM_GetThreadInterruptEvent()); ??????? nit - the indent in JDK .c files is four spaces. src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/OSThread.java ??? No comments. src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/ThreadSubstitutions.java ??? Skipped these 5 graal files. Thumbs up! I only have one nit above and don't need to see another webrev if you decide to fix it. Thanks for being so thorough on your testing. Dan > > This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but > only in small pieces each. There is also a small touch to > serviceability code. > > This change is "simply" moving the "interrupted" field out of the > osThread and into the java.lang.Thread so that it can be set > independently of whether the thread is alive (and to make things > easier for loom in the near future). It is very straightforward: > > - old scheme > ? - interrupted field is in osThread > ? - VM can read/write directly > ? - Java code calls into VM to read/write > > - new scheme > ? - interrupted field is in java.lang.Thread > ? - VM has to use javaCalls to read/write "directly" > ? - Java code can read/write directly > > No changes to any of the semantics regarding the actual interrupt > mechanism. Special thanks to Patricio for tracking down a bug I had > introduced in that regard! > > Special Note (Hi Roger!): on windows we still need to set/clear the > _interrupt_event used by the Process.waitFor logic. To facilitate > clearing via Thread.interrupted() I had to introduce a native method > that is a no-op except on Windows. This seemed the cheapest and least > intrusive means to achieve this. > > Other changes revolve around the fact we used to have an intrinsic for > Thread.isInterrupted and that is not needed any more. So we strip some > code out of C1/C2. > > The changes in the JVMCI/Graal code are a bit more far reaching as > entire classes disappear. I've cc'd Doug and Tom at Vladimir's request > so that they can comment on the JVMCI changes and whether I have gone > too far or not far enough. There are a bunch of tests for interruption > in JVMCI that could potentially be deleted if they are only intended > to test the JVMCI handling of interrupt: > > ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java > > > Testing: > ?- Tiers 1-3 on all Oracle platforms > ?- Focused testing on Linux x64: > ??? - Stress runs of JSR166TestCase > ??? - Anything that seems to use interrupt(): > ????? - JDK > ??????? - java/lang/Thread > ??????? - java/util/concurrent > ??????? - jdk/internal/loader/InterruptedClassLoad.java > ??????? - javax/management > ??????? - java/nio/file/Files > ??????? - java/nio/channels > ??????? - java/net/Socket/Timeouts.java > ??????? - java/lang/Runtime/shutdown/ > ??????? - java/lang/ProcessBuilder/Basic.java > ??????? - com/sun/jdi/ > ????? - Hotspot > ??????? - vmTestbase/nsk/monitoring/ > ??????? - vmTestbase/nsk/jdwp > ??????? - vmTestbase/nsk/jdb/ > ??????? - vmTestbase/nsk/jdi/ > ??????? - vmTestbase/nsk/jvmti/ > ??????? - runtime/Thread > ??????? - serviceability/jvmti/ > ??????? - serviceability/jdwp > ??????? - serviceability/sa > > Thanks, > David > ----- From forax at univ-mlv.fr Tue Oct 29 21:38:55 2019 From: forax at univ-mlv.fr (Remi Forax) Date: Tue, 29 Oct 2019 22:38:55 +0100 (CET) Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: References: Message-ID: <228101443.839885.1572385135051.JavaMail.zimbra@u-pem.fr> Hi David, in java.lang.Thread interrupt0 should be renamed to setInterruptEvent, because what it does now and I don't really understand the comment in interrupted(), if a thread is interrupted by two other threads calling interrupt(), you will loose an interrupt anyway. R?mi ----- Mail original ----- > De: "David Holmes" > ?: "hotspot-runtime-dev" , "hotspot compiler" > , "core-libs-dev" , "Doug Simon" > , "TOM.RODRIGUEZ" , "serviceability-dev" > , "Roger Riggs" > Envoy?: Mardi 29 Octobre 2019 08:42:08 > Objet: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination > Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) > webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ > > This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but > only in small pieces each. There is also a small touch to serviceability > code. > > This change is "simply" moving the "interrupted" field out of the > osThread and into the java.lang.Thread so that it can be set > independently of whether the thread is alive (and to make things easier > for loom in the near future). It is very straightforward: > > - old scheme > - interrupted field is in osThread > - VM can read/write directly > - Java code calls into VM to read/write > > - new scheme > - interrupted field is in java.lang.Thread > - VM has to use javaCalls to read/write "directly" > - Java code can read/write directly > > No changes to any of the semantics regarding the actual interrupt > mechanism. Special thanks to Patricio for tracking down a bug I had > introduced in that regard! > > Special Note (Hi Roger!): on windows we still need to set/clear the > _interrupt_event used by the Process.waitFor logic. To facilitate > clearing via Thread.interrupted() I had to introduce a native method > that is a no-op except on Windows. This seemed the cheapest and least > intrusive means to achieve this. > > Other changes revolve around the fact we used to have an intrinsic for > Thread.isInterrupted and that is not needed any more. So we strip some > code out of C1/C2. > > The changes in the JVMCI/Graal code are a bit more far reaching as > entire classes disappear. I've cc'd Doug and Tom at Vladimir's request > so that they can comment on the JVMCI changes and whether I have gone > too far or not far enough. There are a bunch of tests for interruption > in JVMCI that could potentially be deleted if they are only intended to > test the JVMCI handling of interrupt: > > ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java > > Testing: > - Tiers 1-3 on all Oracle platforms > - Focused testing on Linux x64: > - Stress runs of JSR166TestCase > - Anything that seems to use interrupt(): > - JDK > - java/lang/Thread > - java/util/concurrent > - jdk/internal/loader/InterruptedClassLoad.java > - javax/management > - java/nio/file/Files > - java/nio/channels > - java/net/Socket/Timeouts.java > - java/lang/Runtime/shutdown/ > - java/lang/ProcessBuilder/Basic.java > - com/sun/jdi/ > - Hotspot > - vmTestbase/nsk/monitoring/ > - vmTestbase/nsk/jdwp > - vmTestbase/nsk/jdb/ > - vmTestbase/nsk/jdi/ > - vmTestbase/nsk/jvmti/ > - runtime/Thread > - serviceability/jvmti/ > - serviceability/jdwp > - serviceability/sa > > Thanks, > David > ----- From ningsheng.jian at arm.com Wed Oct 30 01:22:55 2019 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 30 Oct 2019 09:22:55 +0800 Subject: [aarch64-port-dev ] RFR(S): 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl In-Reply-To: <5fe09111-cd87-cb53-19ac-e45367a5d490@redhat.com> References: <65ac062b-a796-1c49-7020-255b3752b826@redhat.com> <9b592c03-be5f-7577-495d-c0543f97cc6c@redhat.com> <8ba7c989-c072-7ad2-ed72-346d8d213445@redhat.com> <5fe09111-cd87-cb53-19ac-e45367a5d490@redhat.com> Message-ID: <39e04e57-74a5-138e-1b87-e8b3f5bc4d50@arm.com> Pushed. On 10/29/19 5:33 PM, Andrew Haley wrote: > On 10/28/19 9:48 AM, Pengfei Li (Arm Technology China) wrote: >> Is another reviewer required for this change? If not, @Ningsheng Jian (Arm Technology China) could you help to push? > > Please push. > Thanks, Ningsheng From david.holmes at oracle.com Wed Oct 30 01:50:25 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Oct 2019 11:50:25 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: References: Message-ID: <2eccd9e9-7a6a-a16b-690f-424ef12cd1c6@oracle.com> On 30/10/2019 4:05 am, serguei.spitsyn at oracle.com wrote: > Hi David, > > The fix looks good to me. Thanks Serguei! David > I did not pay much attention to the Graal related changes though. > The test coverage for Serviceability is complete. > Running java/lang/instrument tests is not necessary. > > Thanks, > Serguei > > > On 10/29/19 00:42, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) >> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >> >> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but >> only in small pieces each. There is also a small touch to >> serviceability code. >> >> This change is "simply" moving the "interrupted" field out of the >> osThread and into the java.lang.Thread so that it can be set >> independently of whether the thread is alive (and to make things >> easier for loom in the near future). It is very straightforward: >> >> - old scheme >> ? - interrupted field is in osThread >> ? - VM can read/write directly >> ? - Java code calls into VM to read/write >> >> - new scheme >> ? - interrupted field is in java.lang.Thread >> ? - VM has to use javaCalls to read/write "directly" >> ? - Java code can read/write directly >> >> No changes to any of the semantics regarding the actual interrupt >> mechanism. Special thanks to Patricio for tracking down a bug I had >> introduced in that regard! >> >> Special Note (Hi Roger!): on windows we still need to set/clear the >> _interrupt_event used by the Process.waitFor logic. To facilitate >> clearing via Thread.interrupted() I had to introduce a native method >> that is a no-op except on Windows. This seemed the cheapest and least >> intrusive means to achieve this. >> >> Other changes revolve around the fact we used to have an intrinsic for >> Thread.isInterrupted and that is not needed any more. So we strip some >> code out of C1/C2. >> >> The changes in the JVMCI/Graal code are a bit more far reaching as >> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request >> so that they can comment on the JVMCI changes and whether I have gone >> too far or not far enough. There are a bunch of tests for interruption >> in JVMCI that could potentially be deleted if they are only intended >> to test the JVMCI handling of interrupt: >> >> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >> >> >> Testing: >> ?- Tiers 1-3 on all Oracle platforms >> ?- Focused testing on Linux x64: >> ??? - Stress runs of JSR166TestCase >> ??? - Anything that seems to use interrupt(): >> ????? - JDK >> ??????? - java/lang/Thread >> ??????? - java/util/concurrent >> ??????? - jdk/internal/loader/InterruptedClassLoad.java >> ??????? - javax/management >> ??????? - java/nio/file/Files >> ??????? - java/nio/channels >> ??????? - java/net/Socket/Timeouts.java >> ??????? - java/lang/Runtime/shutdown/ >> ??????? - java/lang/ProcessBuilder/Basic.java >> ??????? - com/sun/jdi/ >> ????? - Hotspot >> ??????? - vmTestbase/nsk/monitoring/ >> ??????? - vmTestbase/nsk/jdwp >> ??????? - vmTestbase/nsk/jdb/ >> ??????? - vmTestbase/nsk/jdi/ >> ??????? - vmTestbase/nsk/jvmti/ >> ??????? - runtime/Thread >> ??????? - serviceability/jvmti/ >> ??????? - serviceability/jdwp >> ??????? - serviceability/sa >> >> Thanks, >> David >> ----- > From david.holmes at oracle.com Wed Oct 30 01:52:03 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Oct 2019 11:52:03 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: <422bc3b5-861f-0c86-0878-1ba392b342b1@oracle.com> References: <422bc3b5-861f-0c86-0878-1ba392b342b1@oracle.com> Message-ID: Thanks for the review Dan! Fixed the nit in thread.c Thanks, David On 30/10/2019 6:51 am, Daniel D. Daugherty wrote: > On 10/29/19 3:42 AM, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) >> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ > > make/hotspot/symbols/symbols-unix > ??? No comments. > > src/hotspot/os/windows/osThread_windows.cpp > ??? No comments. > > src/hotspot/os/windows/osThread_windows.hpp > ??? No comments. > > src/hotspot/share/aot/aotCodeHeap.cpp > ??? Skipped. > > src/hotspot/share/classfile/javaClasses.cpp > ??? No comments. > > src/hotspot/share/classfile/javaClasses.hpp > ??? No comments. > > src/hotspot/share/classfile/vmSymbols.cpp > ??? No comments. > > src/hotspot/share/classfile/vmSymbols.hpp > ??? No comments. > > src/hotspot/share/include/jvm.h > ??? No comments. > > src/hotspot/share/jvmci/jvmciRuntime.cpp > src/hotspot/share/jvmci/jvmciRuntime.hpp > src/hotspot/share/jvmci/vmStructs_jvmci.cpp > ??? Skipped these three. > > src/hotspot/share/oops/oop.hpp > ??? No comments. > > src/hotspot/share/oops/oop.inline.hpp > ??? No comments. > > src/hotspot/share/opto/c2compiler.cpp > ??? No comments. > > src/hotspot/share/opto/library_call.cpp > ??? No comments. > > src/hotspot/share/prims/jvm.cpp > ??? No comments. > > src/hotspot/share/prims/jvmtiEnv.cpp > ??? No comments. > > src/hotspot/share/prims/jvmtiEnvBase.cpp > ??? No comments. > > src/hotspot/share/runtime/osThread.cpp > ??? No comments. > > src/hotspot/share/runtime/osThread.hpp > ??? No comments. > > src/hotspot/share/runtime/thread.cpp > ??? No comments. > > src/hotspot/share/runtime/vmStructs.cpp > ??? No comments. > > src/java.base/share/classes/java/lang/Thread.java > ??? No comments. > > src/java.base/share/native/libjava/Thread.c > ??? L76: ? // Need to reset the interrupt event used by Process.waitFor > ??? L77: ? ResetEvent((HANDLE) JVM_GetThreadInterruptEvent()); > ??????? nit - the indent in JDK .c files is four spaces. > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/OSThread.java > ??? No comments. > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java > > src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/ThreadSubstitutions.java > > ??? Skipped these 5 graal files. > > Thumbs up! I only have one nit above and don't need to see > another webrev if you decide to fix it. > > Thanks for being so thorough on your testing. > > Dan > > >> >> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but >> only in small pieces each. There is also a small touch to >> serviceability code. >> >> This change is "simply" moving the "interrupted" field out of the >> osThread and into the java.lang.Thread so that it can be set >> independently of whether the thread is alive (and to make things >> easier for loom in the near future). It is very straightforward: >> >> - old scheme >> ? - interrupted field is in osThread >> ? - VM can read/write directly >> ? - Java code calls into VM to read/write >> >> - new scheme >> ? - interrupted field is in java.lang.Thread >> ? - VM has to use javaCalls to read/write "directly" >> ? - Java code can read/write directly >> >> No changes to any of the semantics regarding the actual interrupt >> mechanism. Special thanks to Patricio for tracking down a bug I had >> introduced in that regard! >> >> Special Note (Hi Roger!): on windows we still need to set/clear the >> _interrupt_event used by the Process.waitFor logic. To facilitate >> clearing via Thread.interrupted() I had to introduce a native method >> that is a no-op except on Windows. This seemed the cheapest and least >> intrusive means to achieve this. >> >> Other changes revolve around the fact we used to have an intrinsic for >> Thread.isInterrupted and that is not needed any more. So we strip some >> code out of C1/C2. >> >> The changes in the JVMCI/Graal code are a bit more far reaching as >> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request >> so that they can comment on the JVMCI changes and whether I have gone >> too far or not far enough. There are a bunch of tests for interruption >> in JVMCI that could potentially be deleted if they are only intended >> to test the JVMCI handling of interrupt: >> >> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >> >> >> Testing: >> ?- Tiers 1-3 on all Oracle platforms >> ?- Focused testing on Linux x64: >> ??? - Stress runs of JSR166TestCase >> ??? - Anything that seems to use interrupt(): >> ????? - JDK >> ??????? - java/lang/Thread >> ??????? - java/util/concurrent >> ??????? - jdk/internal/loader/InterruptedClassLoad.java >> ??????? - javax/management >> ??????? - java/nio/file/Files >> ??????? - java/nio/channels >> ??????? - java/net/Socket/Timeouts.java >> ??????? - java/lang/Runtime/shutdown/ >> ??????? - java/lang/ProcessBuilder/Basic.java >> ??????? - com/sun/jdi/ >> ????? - Hotspot >> ??????? - vmTestbase/nsk/monitoring/ >> ??????? - vmTestbase/nsk/jdwp >> ??????? - vmTestbase/nsk/jdb/ >> ??????? - vmTestbase/nsk/jdi/ >> ??????? - vmTestbase/nsk/jvmti/ >> ??????? - runtime/Thread >> ??????? - serviceability/jvmti/ >> ??????? - serviceability/jdwp >> ??????? - serviceability/sa >> >> Thanks, >> David >> ----- > From david.holmes at oracle.com Wed Oct 30 02:05:46 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Oct 2019 12:05:46 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: <228101443.839885.1572385135051.JavaMail.zimbra@u-pem.fr> References: <228101443.839885.1572385135051.JavaMail.zimbra@u-pem.fr> Message-ID: Hi Remi, On 30/10/2019 7:38 am, Remi Forax wrote: > Hi David, > in java.lang.Thread interrupt0 should be renamed to setInterruptEvent, because what it does now There is only an "interrupt event" on Windows. What interrupt0 does is issue all the necessary unparks so that blocked threads will wake up and recheck if they were interrupted. So I don't think a rename is needed. > and I don't really understand the comment in interrupted(), if a thread is interrupted by two other threads calling interrupt(), you will loose an interrupt anyway. Suppose a Thread is checking interrupted() ahead of a blocking operation, it reads the interrupted field and sees that it is false. Then another thread interrupts it, setting the field to true and issuing the unparks. The interrupted() call continues and sets the interrupted field to false, and then returns false so the blocking operation proceeds. Because of the unparks the blocking call returns immediately. The thread then checks again to see if it was interrupted, but the field is false and so it re-parks (treating this as a spurious wakeup). But the thread actually was interrupted and should have thrown InterruptedException. The interrupt has been lost. By only clearing the interrupted field if it was set we avoid this problem. This is the logic the VM code has been implementing for 20 years, so the same logic is needed in the Java code. I added the additional comment to the VM code to make it clearer. Hope that clarifies things. Thanks, David ----- > R?mi > > ----- Mail original ----- >> De: "David Holmes" >> ?: "hotspot-runtime-dev" , "hotspot compiler" >> , "core-libs-dev" , "Doug Simon" >> , "TOM.RODRIGUEZ" , "serviceability-dev" >> , "Roger Riggs" >> Envoy?: Mardi 29 Octobre 2019 08:42:08 >> Objet: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) >> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >> >> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but >> only in small pieces each. There is also a small touch to serviceability >> code. >> >> This change is "simply" moving the "interrupted" field out of the >> osThread and into the java.lang.Thread so that it can be set >> independently of whether the thread is alive (and to make things easier >> for loom in the near future). It is very straightforward: >> >> - old scheme >> - interrupted field is in osThread >> - VM can read/write directly >> - Java code calls into VM to read/write >> >> - new scheme >> - interrupted field is in java.lang.Thread >> - VM has to use javaCalls to read/write "directly" >> - Java code can read/write directly >> >> No changes to any of the semantics regarding the actual interrupt >> mechanism. Special thanks to Patricio for tracking down a bug I had >> introduced in that regard! >> >> Special Note (Hi Roger!): on windows we still need to set/clear the >> _interrupt_event used by the Process.waitFor logic. To facilitate >> clearing via Thread.interrupted() I had to introduce a native method >> that is a no-op except on Windows. This seemed the cheapest and least >> intrusive means to achieve this. >> >> Other changes revolve around the fact we used to have an intrinsic for >> Thread.isInterrupted and that is not needed any more. So we strip some >> code out of C1/C2. >> >> The changes in the JVMCI/Graal code are a bit more far reaching as >> entire classes disappear. I've cc'd Doug and Tom at Vladimir's request >> so that they can comment on the JVMCI changes and whether I have gone >> too far or not far enough. There are a bunch of tests for interruption >> in JVMCI that could potentially be deleted if they are only intended to >> test the JVMCI handling of interrupt: >> >> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >> >> Testing: >> - Tiers 1-3 on all Oracle platforms >> - Focused testing on Linux x64: >> - Stress runs of JSR166TestCase >> - Anything that seems to use interrupt(): >> - JDK >> - java/lang/Thread >> - java/util/concurrent >> - jdk/internal/loader/InterruptedClassLoad.java >> - javax/management >> - java/nio/file/Files >> - java/nio/channels >> - java/net/Socket/Timeouts.java >> - java/lang/Runtime/shutdown/ >> - java/lang/ProcessBuilder/Basic.java >> - com/sun/jdi/ >> - Hotspot >> - vmTestbase/nsk/monitoring/ >> - vmTestbase/nsk/jdwp >> - vmTestbase/nsk/jdb/ >> - vmTestbase/nsk/jdi/ >> - vmTestbase/nsk/jvmti/ >> - runtime/Thread >> - serviceability/jvmti/ >> - serviceability/jdwp >> - serviceability/sa >> >> Thanks, >> David >> ----- From david.holmes at oracle.com Wed Oct 30 04:28:01 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Oct 2019 14:28:01 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: References: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> Message-ID: Hi Doug, Your proposed patch wasn't quite right. I made some adjustments but I'm still having issues with the test, HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see how to make the test execution conditional on the VM config. Updated webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/ Thanks, David ----- On 29/10/2019 7:14 pm, Doug Simon wrote: > > >> On 29 Oct 2019, at 10:12, David Holmes wrote: >> >> Hi Doug, >> >> Thanks for taking a look so quickly! :) >> >> On 29/10/2019 6:55 pm, Doug Simon wrote: >>> Hi David, >>> Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing: >> >> So to be clear I should revert all the Graal file changes I made and just apply the patch below? > > Yes please. > > -Doug > >> >>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>> index 0752a621215..baa2136a6ba 100644 >>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase { >>> public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor"); >>> public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE); >>> public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop"); >>> - public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*"); >>> + public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE); >>> public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int"); >>> public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop"); >>> public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*"); >>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>> index 6b37fff083d..ffc8032d2b0 100644 >>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins { >>> } >>> }); >>> - r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); >>> + if (config.osThreadOffset != Integer.MAX_VALUE) { >>> + r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); >>> + } >>> } >>> public static final String reflectionClass; >>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>> index 1d694fae2a4..8500c4de115 100644 >>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil { >>> @Fold >>> public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) { >>> + assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE; >>> return config.osThreadOffset; >>> } >>> All the other JVMCI changes look good to me. >>> -Doug >>>> On 29 Oct 2019, at 08:42, David Holmes wrote: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) >>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >>>> >>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code. >>>> >>>> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward: >>>> >>>> - old scheme >>>> - interrupted field is in osThread >>>> - VM can read/write directly >>>> - Java code calls into VM to read/write >>>> >>>> - new scheme >>>> - interrupted field is in java.lang.Thread >>>> - VM has to use javaCalls to read/write "directly" >>>> - Java code can read/write directly >>>> >>>> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard! >>>> >>>> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this. >>>> >>>> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2. >>>> >>>> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt: >>>> >>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >>>> >>>> Testing: >>>> - Tiers 1-3 on all Oracle platforms >>>> - Focused testing on Linux x64: >>>> - Stress runs of JSR166TestCase >>>> - Anything that seems to use interrupt(): >>>> - JDK >>>> - java/lang/Thread >>>> - java/util/concurrent >>>> - jdk/internal/loader/InterruptedClassLoad.java >>>> - javax/management >>>> - java/nio/file/Files >>>> - java/nio/channels >>>> - java/net/Socket/Timeouts.java >>>> - java/lang/Runtime/shutdown/ >>>> - java/lang/ProcessBuilder/Basic.java >>>> - com/sun/jdi/ >>>> - Hotspot >>>> - vmTestbase/nsk/monitoring/ >>>> - vmTestbase/nsk/jdwp >>>> - vmTestbase/nsk/jdb/ >>>> - vmTestbase/nsk/jdi/ >>>> - vmTestbase/nsk/jvmti/ >>>> - runtime/Thread >>>> - serviceability/jvmti/ >>>> - serviceability/jdwp >>>> - serviceability/sa >>>> >>>> Thanks, >>>> David >>>> ----- > From david.holmes at oracle.com Wed Oct 30 04:47:22 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Oct 2019 14:47:22 +1000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> Message-ID: Hi Martin, On 29/10/2019 12:06 am, Doerr, Martin wrote: > Hi David and Kim, > > I think it's easier to talk about code. So here's a new webrev: > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.03/ I don't think factoring out CompileBroker::clear_compiler2_object when it is only used once was warranted, but that's call for compiler team to make. Otherwise changes seem fine and I have noted the use of the MutexUnlocker as per your direct email. Thanks, David ----- > @Kim: > Thanks for looking at the handle related parts. It's ok if you don't want to be a reviewer of the whole change. > >> I think it's weird that can_remove() is a predicate with optional side >> effects. I think it would be simpler to have it be a pure predicate, >> and have the one caller with do_it = true perform the updates. That >> should include NULLing out the handle pointer (perhaps debug-only, but >> it doesn't cost much to cleanly maintain the data structure). > Nevertheless, it has the advantage that it enforces the update to be consistent. > A caller could use it without holding the lock or mess it up otherwise. > In addition, I don't what to change that as part of this fix. > >> So far as I can tell, THREAD == NULL here. > This is a very tricky part (not my invention): > EXCEPTION_MARK contains an ExceptionMark constructor call which sets __the_thread__ to Thread::current(). > I don't want to publish my opinion about this ?? > > @David: > Seems like this option is preferred over option 3 (possibly_add_compiler_threads part of webrev.02 and leave the initialization as is). > So when you're ok with it, I'll request a 2nd review from the compiler folks (I should change the subject to contain RFR). > > Thanks, > Martin > > >> -----Original Message----- >> From: David Holmes >> Sent: Montag, 28. Oktober 2019 05:04 >> To: Kim Barrett >> Cc: Doerr, Martin ; Vladimir Kozlov >> (vladimir.kozlov at oracle.com) ; hotspot- >> compiler-dev at openjdk.java.net >> Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread >> >> On 28/10/2019 1:42 pm, Kim Barrett wrote: >>>> On Oct 27, 2019, at 6:04 PM, David Holmes >> wrote: >>>> >>>> On 24/10/2019 12:47 am, Doerr, Martin wrote: >>>>> Hi Kim, >>>>> I didn't like using the OopStorage stuff directly, either. I just have not >> seen how to allocate a global handle and add the oop later. >>>>> Thanks for pointing me to JVMCI::make_global. I was not aware of that. >>>>> So I can imagine 3 ways to implement it: >>>>> 1. Use JNIHandles::destroy_global to release the handles. I just added >> that to >>>>> >> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr >> ev.01/ >>>>> We may want to improve that further by setting the handle pointer to >> NULL and asserting that it is NULL before adding the new one. >>>>> I had been concerned about NULLs in the array, but looks like the >> existing code can deal with that. >>>> >>>> I think it would be cleaner to both destroy the global handle and NULL it in >> the array at the same time. >>>> >>>> This comment >>>> >>>> 325 // Old j.l.Thread object can die here. >>>> >>>> Isn't quite accurate. The j.l.Thread is still referenced via ct->threadObj() so >> can't "die" until that is also cleared during the actual termination process. >>> >>> I think if there is such a thread here that it can't die, because the >>> death predicate (the can_remove stuff) won't see that old thread as >>> the last thread in _compiler2_objects. That's what I meant by this: >>> >>>> On Oct 25, 2019, at 4:05 PM, Kim Barrett >> wrote: >>>> I also think that here: >>>> >>>> 947 jobject thread_handle = JNIHandles::make_global(thread_oop); >>>> 948 _compiler2_objects[i] = thread_handle; >>>> >>>> should assert _compiler2_objects[i] == NULL. Or if that isn't a valid >>>> assertion then I think there are other problems. >>> >>> I think either that comment about an old thread is wrong (and the NULL >>> assertion I suggested is okay), or I think the whole mechanism here >>> has problems. Or at least I was unable to figure out how it could work... >>> >> >> I'm not following sorry. You can't assert NULL unless it's actually set >> to NULL which it presently isn't. But it could be set NULL as Martin >> suggested: >> >> "We may want to improve that further by setting the handle pointer to >> NULL and asserting that it is NULL before adding the new one." >> >> and which I also supported. But that aside once the delete_global has >> been called that JNIHandle no longer references the j.l.Thread that it >> did, at which point it is only reachable via the threadObj() of the >> CompilerThread. >> >> David From david.holmes at oracle.com Wed Oct 30 06:26:41 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Oct 2019 16:26:41 +1000 Subject: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: Message-ID: <8798d327-bfd2-415b-4868-34779517616f@oracle.com> Hi Martin, Sorry I missed the part about the new RFR thread and replied to the old one first :( On 30/10/2019 1:17 am, Doerr, Martin wrote: > Hi, > > after some discussions with David and Kim, I think we have a direction > to go forward. > > The discussion in the bug and on the mailing list is pretty long: > > https://bugs.openjdk.java.net/browse/JDK-8230459 > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-October/035462.html > > To make long story short, I suggest to create new j.l.Thread objects > only for JVMCI threads when (re)starting more threads on demand. > > This avoids such issues with observable thread state transitions etc. > > This is my current proposal: > > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.03/ I don't think factoring out CompileBroker::clear_compiler2_object when it is only used once was warranted, but that's a call for compiler team to make. Otherwise changes seem fine and I have noted the use of the MutexUnlocker as per your direct email. Thanks, David ----- > Please review. > > Best regard, > > Martin > From sgehwolf at redhat.com Wed Oct 30 09:41:26 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Wed, 30 Oct 2019 10:41:26 +0100 Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() || phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no mismatched stores, except on raw memory Message-ID: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com> Hi, Could I please get a review of this 8u only issue? The reason a fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark of the renaissance suite is because the 8u backport of JDK-8140309 was missing this hunk from JDK 9[1]: + (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode + (is_mismatched_access() || st->as_Store()->is_mismatched_access()), I had a closer look and there doesn't seem to be missing anything else. The proposed fix is to amend the assert condition in the appropriate place, which brings 8u in line with JDK 9 code where the failure isn't observed. Bug: https://bugs.openjdk.java.net/browse/JDK-8233023 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/ Testing: 8u tier1 test set with fastdebug build on x86_64 Linux. No new failures. dec-tree benchmark now runs successfully on an 8u fastdebug build. Thoughts? Thanks, Severin [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4bee38ba018c From martin.doerr at sap.com Wed Oct 30 10:18:45 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Oct 2019 10:18:45 +0000 Subject: JDK-8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <3f80fc0b-2388-d4be-3c84-4af516e9635f@oracle.com> <15a92da5-c5ba-ce55-341d-5f60acf14c3a@oracle.com> <2C595A53-202F-4552-96AB-73FF2B922120@oracle.com> <10f415b2-a56b-8e74-ba12-b971db310c8c@oracle.com> <09de4093-bcb2-7b96-b660-bd19abfe3e76@oracle.com> Message-ID: Hi David, > I don't think factoring out CompileBroker::clear_compiler2_object when > it is only used once was warranted, but that's call for compiler team to > make. I did that because _compiler2_objects is private and there's currently no setter available. But let's see what the compiler folks think. > Otherwise changes seem fine and I have noted the use of the > MutexUnlocker as per your direct email. Thanks a lot for reviewing. It was not a trivial one ?? You had noticed an incorrect usage of the CHECK macro. I've created a new bug for that: https://bugs.openjdk.java.net/browse/JDK-8233193 Would be great if you could take a look if that's what you meant and made adaptions if needed. Best regards, Martin > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 30. Oktober 2019 05:47 > To: Doerr, Martin ; Kim Barrett > > Cc: Vladimir Kozlov (vladimir.kozlov at oracle.com) > ; hotspot-compiler-dev at openjdk.java.net; > David Holmes > Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread > > Hi Martin, > > On 29/10/2019 12:06 am, Doerr, Martin wrote: > > Hi David and Kim, > > > > I think it's easier to talk about code. So here's a new webrev: > > > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr > ev.03/ > > I don't think factoring out CompileBroker::clear_compiler2_object when > it is only used once was warranted, but that's call for compiler team to > make. Otherwise changes seem fine and I have noted the use of the > MutexUnlocker as per your direct email. > > Thanks, > David > ----- > > > @Kim: > > Thanks for looking at the handle related parts. It's ok if you don't want to > be a reviewer of the whole change. > > > >> I think it's weird that can_remove() is a predicate with optional side > >> effects. I think it would be simpler to have it be a pure predicate, > >> and have the one caller with do_it = true perform the updates. That > >> should include NULLing out the handle pointer (perhaps debug-only, but > >> it doesn't cost much to cleanly maintain the data structure). > > Nevertheless, it has the advantage that it enforces the update to be > consistent. > > A caller could use it without holding the lock or mess it up otherwise. > > In addition, I don't what to change that as part of this fix. > > > >> So far as I can tell, THREAD == NULL here. > > This is a very tricky part (not my invention): > > EXCEPTION_MARK contains an ExceptionMark constructor call which sets > __the_thread__ to Thread::current(). > > I don't want to publish my opinion about this ?? > > > > @David: > > Seems like this option is preferred over option 3 > (possibly_add_compiler_threads part of webrev.02 and leave the > initialization as is). > > So when you're ok with it, I'll request a 2nd review from the compiler folks > (I should change the subject to contain RFR). > > > > Thanks, > > Martin > > > > > >> -----Original Message----- > >> From: David Holmes > >> Sent: Montag, 28. Oktober 2019 05:04 > >> To: Kim Barrett > >> Cc: Doerr, Martin ; Vladimir Kozlov > >> (vladimir.kozlov at oracle.com) ; hotspot- > >> compiler-dev at openjdk.java.net > >> Subject: Re: JDK-8230459: Test failed to resume JVMCI CompilerThread > >> > >> On 28/10/2019 1:42 pm, Kim Barrett wrote: > >>>> On Oct 27, 2019, at 6:04 PM, David Holmes > > >> wrote: > >>>> > >>>> On 24/10/2019 12:47 am, Doerr, Martin wrote: > >>>>> Hi Kim, > >>>>> I didn't like using the OopStorage stuff directly, either. I just have not > >> seen how to allocate a global handle and add the oop later. > >>>>> Thanks for pointing me to JVMCI::make_global. I was not aware of > that. > >>>>> So I can imagine 3 ways to implement it: > >>>>> 1. Use JNIHandles::destroy_global to release the handles. I just added > >> that to > >>>>> > >> > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr > >> ev.01/ > >>>>> We may want to improve that further by setting the handle pointer to > >> NULL and asserting that it is NULL before adding the new one. > >>>>> I had been concerned about NULLs in the array, but looks like the > >> existing code can deal with that. > >>>> > >>>> I think it would be cleaner to both destroy the global handle and NULL it > in > >> the array at the same time. > >>>> > >>>> This comment > >>>> > >>>> 325 // Old j.l.Thread object can die here. > >>>> > >>>> Isn't quite accurate. The j.l.Thread is still referenced via ct->threadObj() > so > >> can't "die" until that is also cleared during the actual termination process. > >>> > >>> I think if there is such a thread here that it can't die, because the > >>> death predicate (the can_remove stuff) won't see that old thread as > >>> the last thread in _compiler2_objects. That's what I meant by this: > >>> > >>>> On Oct 25, 2019, at 4:05 PM, Kim Barrett > >> wrote: > >>>> I also think that here: > >>>> > >>>> 947 jobject thread_handle = > JNIHandles::make_global(thread_oop); > >>>> 948 _compiler2_objects[i] = thread_handle; > >>>> > >>>> should assert _compiler2_objects[i] == NULL. Or if that isn't a valid > >>>> assertion then I think there are other problems. > >>> > >>> I think either that comment about an old thread is wrong (and the NULL > >>> assertion I suggested is okay), or I think the whole mechanism here > >>> has problems. Or at least I was unable to figure out how it could work... > >>> > >> > >> I'm not following sorry. You can't assert NULL unless it's actually set > >> to NULL which it presently isn't. But it could be set NULL as Martin > >> suggested: > >> > >> "We may want to improve that further by setting the handle pointer to > >> NULL and asserting that it is NULL before adding the new one." > >> > >> and which I also supported. But that aside once the delete_global has > >> been called that JNIHandle no longer references the j.l.Thread that it > >> did, at which point it is only reachable via the threadObj() of the > >> CompilerThread. > >> > >> David From thomas.stuefe at gmail.com Wed Oct 30 10:47:30 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 30 Oct 2019 11:47:30 +0100 Subject: RFR(xs): 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit Message-ID: Hi all, second attempt at a fix (please find first review thread here: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-October/035608.html ) Issue: https://bugs.openjdk.java.net/browse/JDK-8233019 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8233019--c1-intrinsic-for-java.lang.class.isprimitive()-does-32bit-compare/webrev.00/webrev/ In short, C1 intrinsic for jlC::isPrimitive does a compare with the Klass* pointer for the class to find out if its NULL and hence a primitive type. That compare is done using 32bit cmp and so it gives wrong results when the Klass* pointer is aligned to 32bit. In the generator I changed the comparison constant type from intConst(0) to metadataConst(0) and implemented the missing code paths for all CPUs. Since on most architectures we do not seem to have a comparison with a 64bit immediate (at least I could not find one) I kept the change simple and only implemented comparison with NULL for now. I tested the fix in our nightlies (jtreg tier1, jck and others) as well as manually testing it. I did not test on aarch64 and arm though and would be thankful if someone knowledgeable to these platforms could take a look. Thanks to Martin and Lutz for eyeballing the ppc and s390 parts. Thanks, Thomas From martin.doerr at sap.com Wed Oct 30 11:35:25 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Oct 2019 11:35:25 +0000 Subject: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <8798d327-bfd2-415b-4868-34779517616f@oracle.com> References: <8798d327-bfd2-415b-4868-34779517616f@oracle.com> Message-ID: Hi David, > I don't think factoring out CompileBroker::clear_compiler2_object when > it is only used once was warranted, but that's a call for compiler team > to make. Otherwise changes seem fine and I have noted the use of the > MutexUnlocker as per your direct email. I did that because _compiler2_objects is private and there's currently no setter available. Thanks for your review. Best regards, Martin > -----Original Message----- > From: David Holmes > Sent: Mittwoch, 30. Oktober 2019 07:27 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' ; David > Holmes > Subject: Re: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread > > Hi Martin, > > Sorry I missed the part about the new RFR thread and replied to the old > one first :( > > On 30/10/2019 1:17 am, Doerr, Martin wrote: > > Hi, > > > > after some discussions with David and Kim, I think we have a direction > > to go forward. > > > > The discussion in the bug and on the mailing list is pretty long: > > > > https://bugs.openjdk.java.net/browse/JDK-8230459 > > > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- > October/035462.html > > > > To make long story short, I suggest to create new j.l.Thread objects > > only for JVMCI threads when (re)starting more threads on demand. > > > > This avoids such issues with observable thread state transitions etc. > > > > This is my current proposal: > > > > > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr > ev.03/ > > I don't think factoring out CompileBroker::clear_compiler2_object when > it is only used once was warranted, but that's a call for compiler team > to make. Otherwise changes seem fine and I have noted the use of the > MutexUnlocker as per your direct email. > > Thanks, > David > ----- > > > Please review. > > > > Best regard, > > > > Martin > > From doug.simon at oracle.com Wed Oct 30 12:06:37 2019 From: doug.simon at oracle.com (Doug Simon) Date: Wed, 30 Oct 2019 13:06:37 +0100 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: References: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> Message-ID: <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com> > On 30 Oct 2019, at 05:28, David Holmes wrote: > > Hi Doug, > > Your proposed patch wasn't quite right. I made some adjustments but I'm still having issues with the test, HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see how to make the test execution conditional on the VM config. Like this: diff --git a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java index 96e7d979d36..3c928b86961 100644 --- a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java +++ b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java @@ -28,12 +28,13 @@ import java.lang.invoke.ConstantCallSite; import java.lang.invoke.MethodHandles; import java.lang.invoke.MethodType; -import org.graalvm.compiler.nodes.IfNode; -import org.junit.Test; - import org.graalvm.compiler.api.directives.GraalDirectives; import org.graalvm.compiler.api.replacements.MethodSubstitution; +import org.graalvm.compiler.hotspot.GraalHotSpotVMConfig; +import org.graalvm.compiler.hotspot.HotSpotBackend; +import org.graalvm.compiler.nodes.IfNode; import org.graalvm.compiler.replacements.test.MethodSubstitutionTest; +import org.junit.Test; /** * Tests HotSpot specific {@link MethodSubstitution}s. @@ -133,13 +134,18 @@ public class HotSpotMethodSubstitutionTest extends MethodSubstitutionTest { @Test public void testThreadSubstitutions() { + GraalHotSpotVMConfig config = ((HotSpotBackend) getBackend()).getRuntime().getVMConfig(); testGraph("currentThread"); - assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class); - assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class); + if (config.osThreadOffset != Integer.MAX_VALUE) { + assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class); + assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class); + } Thread currentThread = Thread.currentThread(); test("currentThread", currentThread); - test("threadIsInterrupted", currentThread); + if (config.osThreadOffset != Integer.MAX_VALUE) { + test("threadIsInterrupted", currentThread); + } } @SuppressWarnings("all") > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/ > > Thanks, > David > ----- > > > On 29/10/2019 7:14 pm, Doug Simon wrote: >>> On 29 Oct 2019, at 10:12, David Holmes wrote: >>> >>> Hi Doug, >>> >>> Thanks for taking a look so quickly! :) >>> >>> On 29/10/2019 6:55 pm, Doug Simon wrote: >>>> Hi David, >>>> Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing: >>> >>> So to be clear I should revert all the Graal file changes I made and just apply the patch below? >> Yes please. >> -Doug >>> >>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>> index 0752a621215..baa2136a6ba 100644 >>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase { >>>> public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor"); >>>> public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE); >>>> public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop"); >>>> - public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*"); >>>> + public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE); >>>> public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int"); >>>> public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop"); >>>> public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*"); >>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>> index 6b37fff083d..ffc8032d2b0 100644 >>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins { >>>> } >>>> }); >>>> - r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); >>>> + if (config.osThreadOffset != Integer.MAX_VALUE) { >>>> + r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); >>>> + } >>>> } >>>> public static final String reflectionClass; >>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>> index 1d694fae2a4..8500c4de115 100644 >>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil { >>>> @Fold >>>> public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) { >>>> + assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE; >>>> return config.osThreadOffset; >>>> } >>>> All the other JVMCI changes look good to me. >>>> -Doug >>>>> On 29 Oct 2019, at 08:42, David Holmes wrote: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >>>>> >>>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code. >>>>> >>>>> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward: >>>>> >>>>> - old scheme >>>>> - interrupted field is in osThread >>>>> - VM can read/write directly >>>>> - Java code calls into VM to read/write >>>>> >>>>> - new scheme >>>>> - interrupted field is in java.lang.Thread >>>>> - VM has to use javaCalls to read/write "directly" >>>>> - Java code can read/write directly >>>>> >>>>> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard! >>>>> >>>>> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this. >>>>> >>>>> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2. >>>>> >>>>> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt: >>>>> >>>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >>>>> >>>>> Testing: >>>>> - Tiers 1-3 on all Oracle platforms >>>>> - Focused testing on Linux x64: >>>>> - Stress runs of JSR166TestCase >>>>> - Anything that seems to use interrupt(): >>>>> - JDK >>>>> - java/lang/Thread >>>>> - java/util/concurrent >>>>> - jdk/internal/loader/InterruptedClassLoad.java >>>>> - javax/management >>>>> - java/nio/file/Files >>>>> - java/nio/channels >>>>> - java/net/Socket/Timeouts.java >>>>> - java/lang/Runtime/shutdown/ >>>>> - java/lang/ProcessBuilder/Basic.java >>>>> - com/sun/jdi/ >>>>> - Hotspot >>>>> - vmTestbase/nsk/monitoring/ >>>>> - vmTestbase/nsk/jdwp >>>>> - vmTestbase/nsk/jdb/ >>>>> - vmTestbase/nsk/jdi/ >>>>> - vmTestbase/nsk/jvmti/ >>>>> - runtime/Thread >>>>> - serviceability/jvmti/ >>>>> - serviceability/jdwp >>>>> - serviceability/sa >>>>> >>>>> Thanks, >>>>> David >>>>> ----- From martin.doerr at sap.com Wed Oct 30 12:08:42 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Oct 2019 12:08:42 +0000 Subject: RFR(xs): 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: References: Message-ID: Hi Thomas, thank you for finding and fixing this issue. Shared code part and regression test look good to me. But I have a few requests and questions related to the platform code. Arm32: Breaks build. The local variable p needs a scope. Can be fixed by: - case T_METADATA: + case T_METADATA: { // We only need, for now, comparison with NULL for metadata. ? break; + } S390: Using z_cgfi is correct, but there are equivalent instructions with shorter opcode. For comparing to 0, z_ltgr(reg1, reg1) or z_cghi(reg1, 0) may be preferred. But that?s not a big deal. I wonder why you have added includes to some platform files. Isn?t that redundant? "utilities/debug.hpp" comes via shared assembler.hpp. I?d probably choose Unimplemented() instead of ShouldNotReachHere() for non-null cases because it?s not bad in general, it?s just currently not used and therefore not yet implemented. But you can keep that as it is. I?m ok with that, too. Best regards, Martin From: Thomas St?fe Sent: Mittwoch, 30. Oktober 2019 11:48 To: hotspot compiler Cc: Doerr, Martin ; Schmidt, Lutz Subject: RFR(xs): 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit Hi all, second attempt at a fix (please find first review thread here: https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-October/035608.html) Issue: https://bugs.openjdk.java.net/browse/JDK-8233019 webrev: http://cr.openjdk.java.net/~stuefe/webrevs/8233019--c1-intrinsic-for-java.lang.class.isprimitive()-does-32bit-compare/webrev.00/webrev/ In short, C1 intrinsic for jlC::isPrimitive does a compare with the Klass* pointer for the class to find out if its NULL and hence a primitive type. That compare is done using 32bit cmp and so it gives wrong results when the Klass* pointer is aligned to 32bit. In the generator I changed the comparison constant type from intConst(0) to metadataConst(0) and implemented the missing code paths for all CPUs. Since on most architectures we do not seem to have a comparison with a 64bit immediate (at least I could not find one) I kept the change simple and only implemented comparison with NULL for now. I tested the fix in our nightlies (jtreg tier1, jck and others) as well as manually testing it. I did not test on aarch64 and arm though and would be thankful if someone knowledgeable to these platforms could take a look. Thanks to Martin and Lutz for eyeballing the ppc and s390 parts. Thanks, Thomas From david.holmes at oracle.com Wed Oct 30 13:30:36 2019 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Oct 2019 23:30:36 +1000 Subject: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <8798d327-bfd2-415b-4868-34779517616f@oracle.com> Message-ID: On 30/10/2019 9:35 pm, Doerr, Martin wrote: > Hi David, > >> I don't think factoring out CompileBroker::clear_compiler2_object when >> it is only used once was warranted, but that's a call for compiler team >> to make. Otherwise changes seem fine and I have noted the use of the >> MutexUnlocker as per your direct email. > I did that because _compiler2_objects is private and there's currently no setter available. Ah I see - sorry I missed that. Thanks, David > Thanks for your review. > > Best regards, > Martin > > >> -----Original Message----- >> From: David Holmes >> Sent: Mittwoch, 30. Oktober 2019 07:27 >> To: Doerr, Martin ; 'hotspot-compiler- >> dev at openjdk.java.net' ; David >> Holmes >> Subject: Re: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread >> >> Hi Martin, >> >> Sorry I missed the part about the new RFR thread and replied to the old >> one first :( >> >> On 30/10/2019 1:17 am, Doerr, Martin wrote: >>> Hi, >>> >>> after some discussions with David and Kim, I think we have a direction >>> to go forward. >>> >>> The discussion in the bug and on the mailing list is pretty long: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8230459 >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- >> October/035462.html >>> >>> To make long story short, I suggest to create new j.l.Thread objects >>> only for JVMCI threads when (re)starting more threads on demand. >>> >>> This avoids such issues with observable thread state transitions etc. >>> >>> This is my current proposal: >>> >>> >> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr >> ev.03/ >> >> I don't think factoring out CompileBroker::clear_compiler2_object when >> it is only used once was warranted, but that's a call for compiler team >> to make. Otherwise changes seem fine and I have noted the use of the >> MutexUnlocker as per your direct email. >> >> Thanks, >> David >> ----- >> >>> Please review. >>> >>> Best regard, >>> >>> Martin >>> From vladimir.kozlov at oracle.com Wed Oct 30 15:24:07 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Oct 2019 08:24:07 -0700 Subject: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: References: <8798d327-bfd2-415b-4868-34779517616f@oracle.com> Message-ID: <67a55078-d77a-bb45-cb53-428e5f1382a1@oracle.com> Thank you guys for discussing and resolving this issue. The fix looks reasonable to me. I will submit several tiers testing to include Graal testing and let you know results. Thanks, Vladimir On 10/30/19 6:30 AM, David Holmes wrote: > On 30/10/2019 9:35 pm, Doerr, Martin wrote: >> Hi David, >> >>> I don't think factoring out CompileBroker::clear_compiler2_object when >>> it is only used once was warranted, but that's a call for compiler team >>> to make. Otherwise changes seem fine and I have noted the use of the >>> MutexUnlocker as per your direct email. >> I did that because _compiler2_objects is private and there's currently >> no setter available. > > Ah I see - sorry I missed that. > > Thanks, > David > >> Thanks for your review. >> >> Best regards, >> Martin >> >> >>> -----Original Message----- >>> From: David Holmes >>> Sent: Mittwoch, 30. Oktober 2019 07:27 >>> To: Doerr, Martin ; 'hotspot-compiler- >>> dev at openjdk.java.net' ; David >>> Holmes >>> Subject: Re: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread >>> >>> Hi Martin, >>> >>> Sorry I missed the part about the new RFR thread and replied to the old >>> one first :( >>> >>> On 30/10/2019 1:17 am, Doerr, Martin wrote: >>>> Hi, >>>> >>>> after some discussions with David and Kim, I think we have a direction >>>> to go forward. >>>> >>>> The discussion in the bug and on the mailing list is pretty long: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8230459 >>>> >>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- >>> October/035462.html >>>> >>>> To make long story short, I suggest to create new j.l.Thread objects >>>> only for JVMCI threads when (re)starting more threads on demand. >>>> >>>> This avoids such issues with observable thread state transitions etc. >>>> >>>> This is my current proposal: >>>> >>>> >>> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr >>> ev.03/ >>> >>> I don't think factoring out CompileBroker::clear_compiler2_object when >>> it is only used once was warranted, but that's a call for compiler team >>> to make. Otherwise changes seem fine and I have noted the use of the >>> MutexUnlocker as per your direct email. >>> >>> Thanks, >>> David >>> ----- >>> >>>> Please review. >>>> >>>> Best regard, >>>> >>>> Martin >>>> From Alan.Bateman at oracle.com Wed Oct 30 15:33:31 2019 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 30 Oct 2019 15:33:31 +0000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: References: Message-ID: <56094f66-ca3f-8209-0559-62a9412619c2@oracle.com> On 29/10/2019 07:42, David Holmes wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 > CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) > webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ > The implNote has "In the JDK Reference Implementation". I think you can replace that with "In this implementation" so that it is consistent with the other impl notes that we've added in recent releases. In any case, I went through the Thread changes and the call into the VM to clear the event on Windows. Looks okay to me (we'll have re-work to do in Loom of course but that was expected). -Alan From martin.doerr at sap.com Wed Oct 30 15:38:31 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Oct 2019 15:38:31 +0000 Subject: RFR(S): 8233081: C1: PatchingStub for field access copies too much Message-ID: Hi, I'd like to fix an issue in C1's PatchingStub implementation for "access_field_id". We had noticed that the code in the template exceeded the 255 byte limitation when switching on VerifyOops on PPC64. I'd like to improve the situation for all platforms. More detailed bug description: https://bugs.openjdk.java.net/browse/JDK-8233081 I need a function to determine how many bytes are needed for the NativeMovRegMem. x86 has next_instruction_address() which could in theory be used, but I noticed that it's dead code which is no longer correct. Is it ok to remove it? I'd also like to remove the constant instruction_size from NativeMovRegMem because it's not constant. I'd prefer to introduce num_bytes_to_end_of_patch() for the purpose of determining how many bytes to copy for the "access_field_id" PatchingStub. We can factor out the offset computation from offset() and set_offset() and reuse it. This enforces consistency. Webrev: http://cr.openjdk.java.net/~mdoerr/8233081_C1_access_field_patching/webrev.00/ Please review. Best regards, Martin From vladimir.kozlov at oracle.com Wed Oct 30 16:33:03 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 30 Oct 2019 09:33:03 -0700 Subject: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <67a55078-d77a-bb45-cb53-428e5f1382a1@oracle.com> References: <8798d327-bfd2-415b-4868-34779517616f@oracle.com> <67a55078-d77a-bb45-cb53-428e5f1382a1@oracle.com> Message-ID: <04a73643-caa5-a901-2b40-85ff2297afa1@oracle.com> tier1 test compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java failed: # Internal Error (t:\workspace\open\src\hotspot\share\runtime/jniHandles.inline.hpp:91), pid=16072, tid=25988 # assert(handle != 0LL) failed: JNI handle should not be null V [jvm.dll+0x40f2f1] JNIHandles::resolve_non_null+0x31 (jnihandles.inline.hpp:91) V [jvm.dll+0x4a16e8] can_remove+0xc8 (compilebroker.cpp:319) V [jvm.dll+0x4a4a6e] CompileQueue::get+0x12e (compilebroker.cpp:435) V [jvm.dll+0x4a4362] CompileBroker::compiler_thread_loop+0x1b2 (compilebroker.cpp:1818) V [jvm.dll+0xc7af3e] JavaThread::run+0x27e (thread.cpp:1946) I attached hs_err file to bug report. Vladimir On 10/30/19 8:24 AM, Vladimir Kozlov wrote: > Thank you guys for discussing and resolving this issue. The fix looks > reasonable to me. > I will submit several tiers testing to include Graal testing and let you > know results. > > Thanks, > Vladimir > > On 10/30/19 6:30 AM, David Holmes wrote: >> On 30/10/2019 9:35 pm, Doerr, Martin wrote: >>> Hi David, >>> >>>> I don't think factoring out CompileBroker::clear_compiler2_object when >>>> it is only used once was warranted, but that's a call for compiler team >>>> to make. Otherwise changes seem fine and I have noted the use of the >>>> MutexUnlocker as per your direct email. >>> I did that because _compiler2_objects is private and there's >>> currently no setter available. >> >> Ah I see - sorry I missed that. >> >> Thanks, >> David >> >>> Thanks for your review. >>> >>> Best regards, >>> Martin >>> >>> >>>> -----Original Message----- >>>> From: David Holmes >>>> Sent: Mittwoch, 30. Oktober 2019 07:27 >>>> To: Doerr, Martin ; 'hotspot-compiler- >>>> dev at openjdk.java.net' ; David >>>> Holmes >>>> Subject: Re: RFR(M): 8230459: Test failed to resume JVMCI >>>> CompilerThread >>>> >>>> Hi Martin, >>>> >>>> Sorry I missed the part about the new RFR thread and replied to the old >>>> one first :( >>>> >>>> On 30/10/2019 1:17 am, Doerr, Martin wrote: >>>>> Hi, >>>>> >>>>> after some discussions with David and Kim, I think we have a direction >>>>> to go forward. >>>>> >>>>> The discussion in the bug and on the mailing list is pretty long: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8230459 >>>>> >>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- >>>> October/035462.html >>>>> >>>>> To make long story short, I suggest to create new j.l.Thread objects >>>>> only for JVMCI threads when (re)starting more threads on demand. >>>>> >>>>> This avoids such issues with observable thread state transitions etc. >>>>> >>>>> This is my current proposal: >>>>> >>>>> >>>> http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr >>>> ev.03/ >>>> >>>> I don't think factoring out CompileBroker::clear_compiler2_object when >>>> it is only used once was warranted, but that's a call for compiler team >>>> to make. Otherwise changes seem fine and I have noted the use of the >>>> MutexUnlocker as per your direct email. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Please review. >>>>> >>>>> Best regard, >>>>> >>>>> Martin >>>>> From martin.doerr at sap.com Wed Oct 30 17:32:56 2019 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 30 Oct 2019 17:32:56 +0000 Subject: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread In-Reply-To: <04a73643-caa5-a901-2b40-85ff2297afa1@oracle.com> References: <8798d327-bfd2-415b-4868-34779517616f@oracle.com> <67a55078-d77a-bb45-cb53-428e5f1382a1@oracle.com> <04a73643-caa5-a901-2b40-85ff2297afa1@oracle.com> Message-ID: Hi Vladimir, that must have been a good test. The function can_remove(..., false) is used for an heuristic answer without holding CompileThread_lock. In this case, last_compiler can be NULL and we need to use the normal resolve function. Changed that and added comment: http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webrev.04/ Best regards, Martin > -----Original Message----- > From: hotspot-compiler-dev bounces at openjdk.java.net> On Behalf Of Vladimir Kozlov > Sent: Mittwoch, 30. Oktober 2019 17:33 > To: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(M): 8230459: Test failed to resume JVMCI CompilerThread > > tier1 test > compiler/jvmci/events/JvmciNotifyBootstrapFinishedEventTest.java failed: > > # Internal Error > (t:\workspace\open\src\hotspot\share\runtime/jniHandles.inline.hpp:91), > pid=16072, tid=25988 > # assert(handle != 0LL) failed: JNI handle should not be null > > V [jvm.dll+0x40f2f1] JNIHandles::resolve_non_null+0x31 > (jnihandles.inline.hpp:91) > V [jvm.dll+0x4a16e8] can_remove+0xc8 (compilebroker.cpp:319) > V [jvm.dll+0x4a4a6e] CompileQueue::get+0x12e (compilebroker.cpp:435) > V [jvm.dll+0x4a4362] CompileBroker::compiler_thread_loop+0x1b2 > (compilebroker.cpp:1818) > V [jvm.dll+0xc7af3e] JavaThread::run+0x27e (thread.cpp:1946) > > I attached hs_err file to bug report. > > Vladimir > > On 10/30/19 8:24 AM, Vladimir Kozlov wrote: > > Thank you guys for discussing and resolving this issue. The fix looks > > reasonable to me. > > I will submit several tiers testing to include Graal testing and let you > > know results. > > > > Thanks, > > Vladimir > > > > On 10/30/19 6:30 AM, David Holmes wrote: > >> On 30/10/2019 9:35 pm, Doerr, Martin wrote: > >>> Hi David, > >>> > >>>> I don't think factoring out CompileBroker::clear_compiler2_object > when > >>>> it is only used once was warranted, but that's a call for compiler team > >>>> to make. Otherwise changes seem fine and I have noted the use of the > >>>> MutexUnlocker as per your direct email. > >>> I did that because _compiler2_objects is private and there's > >>> currently no setter available. > >> > >> Ah I see - sorry I missed that. > >> > >> Thanks, > >> David > >> > >>> Thanks for your review. > >>> > >>> Best regards, > >>> Martin > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes > >>>> Sent: Mittwoch, 30. Oktober 2019 07:27 > >>>> To: Doerr, Martin ; 'hotspot-compiler- > >>>> dev at openjdk.java.net' ; > David > >>>> Holmes > >>>> Subject: Re: RFR(M): 8230459: Test failed to resume JVMCI > >>>> CompilerThread > >>>> > >>>> Hi Martin, > >>>> > >>>> Sorry I missed the part about the new RFR thread and replied to the old > >>>> one first :( > >>>> > >>>> On 30/10/2019 1:17 am, Doerr, Martin wrote: > >>>>> Hi, > >>>>> > >>>>> after some discussions with David and Kim, I think we have a direction > >>>>> to go forward. > >>>>> > >>>>> The discussion in the bug and on the mailing list is pretty long: > >>>>> > >>>>> https://bugs.openjdk.java.net/browse/JDK-8230459 > >>>>> > >>>>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019- > >>>> October/035462.html > >>>>> > >>>>> To make long story short, I suggest to create new j.l.Thread objects > >>>>> only for JVMCI threads when (re)starting more threads on demand. > >>>>> > >>>>> This avoids such issues with observable thread state transitions etc. > >>>>> > >>>>> This is my current proposal: > >>>>> > >>>>> > >>>> > http://cr.openjdk.java.net/~mdoerr/8230459_JVMCI_thread_objects/webr > >>>> ev.03/ > >>>> > >>>> I don't think factoring out CompileBroker::clear_compiler2_object > when > >>>> it is only used once was warranted, but that's a call for compiler team > >>>> to make. Otherwise changes seem fine and I have noted the use of the > >>>> MutexUnlocker as per your direct email. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>>> Please review. > >>>>> > >>>>> Best regard, > >>>>> > >>>>> Martin > >>>>> From david.holmes at oracle.com Wed Oct 30 23:29:15 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Oct 2019 09:29:15 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: <56094f66-ca3f-8209-0559-62a9412619c2@oracle.com> References: <56094f66-ca3f-8209-0559-62a9412619c2@oracle.com> Message-ID: <9404b5fb-f0a7-3b4e-80d9-ec0530be1d9a@oracle.com> Hi Alan, Thanks for taking a look at this. On 31/10/2019 1:33 am, Alan Bateman wrote: > On 29/10/2019 07:42, David Holmes wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) >> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >> > The implNote has "In the JDK Reference Implementation". I think you can > replace that with "In this implementation" so that it is consistent with > the other impl notes that we've added in recent releases. Joe Darcy specifically requested that terminology in the CSR request as the new way of referring to "this implementation". There are 24 existing uses. > In any case, I went through the Thread changes and the call into the VM > to clear the event on Windows. Looks okay to me (we'll have re-work to > do in Loom of course but that was expected). Thanks again. David > -Alan > > From hohensee at amazon.com Thu Oct 31 00:21:40 2019 From: hohensee at amazon.com (Hohensee, Paul) Date: Thu, 31 Oct 2019 00:21:40 +0000 Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() || phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no mismatched stores, except on raw memory In-Reply-To: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com> References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com> Message-ID: Lgtm. Paul ?On 10/30/19, 2:42 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: Hi, Could I please get a review of this 8u only issue? The reason a fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark of the renaissance suite is because the 8u backport of JDK-8140309 was missing this hunk from JDK 9[1]: + (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode + (is_mismatched_access() || st->as_Store()->is_mismatched_access()), I had a closer look and there doesn't seem to be missing anything else. The proposed fix is to amend the assert condition in the appropriate place, which brings 8u in line with JDK 9 code where the failure isn't observed. Bug: https://bugs.openjdk.java.net/browse/JDK-8233023 webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/ Testing: 8u tier1 test set with fastdebug build on x86_64 Linux. No new failures. dec-tree benchmark now runs successfully on an 8u fastdebug build. Thoughts? Thanks, Severin [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4bee38ba018c From serguei.spitsyn at oracle.com Thu Oct 31 00:36:29 2019 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Wed, 30 Oct 2019 17:36:29 -0700 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: References: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> Message-ID: <3007b1c6-6a9a-bad4-edf5-ce8e5a54ac18@oracle.com> Hi David, The update looks good. Thanks, Serguei On 10/29/19 9:28 PM, David Holmes wrote: > Hi Doug, > > Your proposed patch wasn't quite right. I made some adjustments but > I'm still having issues with the test, > HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see > how to make the test execution conditional on the VM config. > > Updated webrev: > > http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/ > > Thanks, > David > ----- > > > On 29/10/2019 7:14 pm, Doug Simon wrote: >> >> >>> On 29 Oct 2019, at 10:12, David Holmes wrote: >>> >>> Hi Doug, >>> >>> Thanks for taking a look so quickly! :) >>> >>> On 29/10/2019 6:55 pm, Doug Simon wrote: >>>> Hi David, >>>> Since Graal needs to work against multiple JVMCI versions (and VM >>>> versions!), the Graal changes should only disable the intrinsic >>>> when the relevant VM config is missing: >>> >>> So to be clear I should revert all the Graal file changes I made and >>> just apply the patch below? >> >> Yes please. >> >> -Doug >> >>> >>>> diff --git >>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>> >>>> index 0752a621215..baa2136a6ba 100644 >>>> --- >>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>> +++ >>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends >>>> GraalHotSpotVMConfigBase { >>>> ????? public final int javaThreadAnchorOffset = >>>> getFieldOffset("JavaThread::_anchor", Integer.class, >>>> "JavaFrameAnchor"); >>>> ????? public final int javaThreadShouldPostOnExceptionsFlagOffset = >>>> getFieldOffset("JavaThread::_should_post_on_exceptions_flag", >>>> Integer.class, "int", Integer.MIN_VALUE); >>>> ????? public final int threadObjectOffset = >>>> getFieldOffset("JavaThread::_threadObj", Integer.class, "oop"); >>>> -??? public final int osThreadOffset = >>>> getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*"); >>>> +??? public final int osThreadOffset = >>>> getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", >>>> Integer.MAX_VALUE); >>>> ????? public final int threadIsMethodHandleReturnOffset = >>>> getFieldOffset("JavaThread::_is_method_handle_return", >>>> Integer.class, "int"); >>>> ????? public final int threadObjectResultOffset = >>>> getFieldOffset("JavaThread::_vm_result", Integer.class, "oop"); >>>> ????? public final int jvmciCountersThreadOffset = >>>> getFieldOffset("JavaThread::_jvmci_counters", Integer.class, >>>> "jlong*"); >>>> diff --git >>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>> >>>> index 6b37fff083d..ffc8032d2b0 100644 >>>> --- >>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>> +++ >>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins { >>>> ????????????? } >>>> ????????? }); >>>> ? - r.registerMethodSubstitution(ThreadSubstitutions.class, >>>> "isInterrupted", Receiver.class, boolean.class); >>>> +??????? if (config.osThreadOffset != Integer.MAX_VALUE) { >>>> + r.registerMethodSubstitution(ThreadSubstitutions.class, >>>> "isInterrupted", Receiver.class, boolean.class); >>>> +??????? } >>>> ????? } >>>> ??????? public static final String reflectionClass; >>>> diff --git >>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>> >>>> index 1d694fae2a4..8500c4de115 100644 >>>> --- >>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>> +++ >>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil { >>>> ??????? @Fold >>>> ????? public static int osThreadOffset(@InjectedParameter >>>> GraalHotSpotVMConfig config) { >>>> +??????? assert config.instanceKlassInitThreadOffset != >>>> Integer.MAX_VALUE; >>>> ????????? return config.osThreadOffset; >>>> ????? } >>>> ? All the other JVMCI changes look good to me. >>>> -Doug >>>>> On 29 Oct 2019, at 08:42, David Holmes >>>>> wrote: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already >>>>> approved) >>>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >>>>> >>>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, >>>>> but only in small pieces each. There is also a small touch to >>>>> serviceability code. >>>>> >>>>> This change is "simply" moving the "interrupted" field out of the >>>>> osThread and into the java.lang.Thread so that it can be set >>>>> independently of whether the thread is alive (and to make things >>>>> easier for loom in the near future). It is very straightforward: >>>>> >>>>> - old scheme >>>>> ? - interrupted field is in osThread >>>>> ? - VM can read/write directly >>>>> ? - Java code calls into VM to read/write >>>>> >>>>> - new scheme >>>>> ? - interrupted field is in java.lang.Thread >>>>> ? - VM has to use javaCalls to read/write "directly" >>>>> ? - Java code can read/write directly >>>>> >>>>> No changes to any of the semantics regarding the actual interrupt >>>>> mechanism. Special thanks to Patricio for tracking down a bug I >>>>> had introduced in that regard! >>>>> >>>>> Special Note (Hi Roger!): on windows we still need to set/clear >>>>> the _interrupt_event used by the Process.waitFor logic. To >>>>> facilitate clearing via Thread.interrupted() I had to introduce a >>>>> native method that is a no-op except on Windows. This seemed the >>>>> cheapest and least intrusive means to achieve this. >>>>> >>>>> Other changes revolve around the fact we used to have an intrinsic >>>>> for Thread.isInterrupted and that is not needed any more. So we >>>>> strip some code out of C1/C2. >>>>> >>>>> The changes in the JVMCI/Graal code are a bit more far reaching as >>>>> entire classes disappear. I've cc'd Doug and Tom at Vladimir's >>>>> request so that they can comment on the JVMCI changes and whether >>>>> I have gone too far or not far enough. There are a bunch of tests >>>>> for interruption in JVMCI that could potentially be deleted if >>>>> they are only intended to test the JVMCI handling of interrupt: >>>>> >>>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >>>>> >>>>> >>>>> Testing: >>>>> - Tiers 1-3 on all Oracle platforms >>>>> - Focused testing on Linux x64: >>>>> ??? - Stress runs of JSR166TestCase >>>>> ??? - Anything that seems to use interrupt(): >>>>> ????? - JDK >>>>> ??????? - java/lang/Thread >>>>> ??????? - java/util/concurrent >>>>> ??????? - jdk/internal/loader/InterruptedClassLoad.java >>>>> ??????? - javax/management >>>>> ??????? - java/nio/file/Files >>>>> ??????? - java/nio/channels >>>>> ??????? - java/net/Socket/Timeouts.java >>>>> ??????? - java/lang/Runtime/shutdown/ >>>>> ??????? - java/lang/ProcessBuilder/Basic.java >>>>> ??????? - com/sun/jdi/ >>>>> ????? - Hotspot >>>>> ??????? - vmTestbase/nsk/monitoring/ >>>>> ??????? - vmTestbase/nsk/jdwp >>>>> ??????? - vmTestbase/nsk/jdb/ >>>>> ??????? - vmTestbase/nsk/jdi/ >>>>> ??????? - vmTestbase/nsk/jvmti/ >>>>> ??????? - runtime/Thread >>>>> ??????? - serviceability/jvmti/ >>>>> ??????? - serviceability/jdwp >>>>> ??????? - serviceability/sa >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >> From david.holmes at oracle.com Thu Oct 31 01:34:06 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Oct 2019 11:34:06 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: <3007b1c6-6a9a-bad4-edf5-ce8e5a54ac18@oracle.com> References: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> <3007b1c6-6a9a-bad4-edf5-ce8e5a54ac18@oracle.com> Message-ID: <619a83de-1602-9395-47e4-a8e6c6968103@oracle.com> Thanks Serguei! David On 31/10/2019 10:36 am, serguei.spitsyn at oracle.com wrote: > Hi David, > > The update looks good. > > Thanks, > Serguei > > On 10/29/19 9:28 PM, David Holmes wrote: >> Hi Doug, >> >> Your proposed patch wasn't quite right. I made some adjustments but >> I'm still having issues with the test, >> HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see >> how to make the test execution conditional on the VM config. >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/ >> >> Thanks, >> David >> ----- >> >> >> On 29/10/2019 7:14 pm, Doug Simon wrote: >>> >>> >>>> On 29 Oct 2019, at 10:12, David Holmes wrote: >>>> >>>> Hi Doug, >>>> >>>> Thanks for taking a look so quickly! :) >>>> >>>> On 29/10/2019 6:55 pm, Doug Simon wrote: >>>>> Hi David, >>>>> Since Graal needs to work against multiple JVMCI versions (and VM >>>>> versions!), the Graal changes should only disable the intrinsic >>>>> when the relevant VM config is missing: >>>> >>>> So to be clear I should revert all the Graal file changes I made and >>>> just apply the patch below? >>> >>> Yes please. >>> >>> -Doug >>> >>>> >>>>> diff --git >>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>>> >>>>> index 0752a621215..baa2136a6ba 100644 >>>>> --- >>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>>> >>>>> +++ >>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>>> >>>>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends >>>>> GraalHotSpotVMConfigBase { >>>>> ????? public final int javaThreadAnchorOffset = >>>>> getFieldOffset("JavaThread::_anchor", Integer.class, >>>>> "JavaFrameAnchor"); >>>>> ????? public final int javaThreadShouldPostOnExceptionsFlagOffset = >>>>> getFieldOffset("JavaThread::_should_post_on_exceptions_flag", >>>>> Integer.class, "int", Integer.MIN_VALUE); >>>>> ????? public final int threadObjectOffset = >>>>> getFieldOffset("JavaThread::_threadObj", Integer.class, "oop"); >>>>> -??? public final int osThreadOffset = >>>>> getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*"); >>>>> +??? public final int osThreadOffset = >>>>> getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", >>>>> Integer.MAX_VALUE); >>>>> ????? public final int threadIsMethodHandleReturnOffset = >>>>> getFieldOffset("JavaThread::_is_method_handle_return", >>>>> Integer.class, "int"); >>>>> ????? public final int threadObjectResultOffset = >>>>> getFieldOffset("JavaThread::_vm_result", Integer.class, "oop"); >>>>> ????? public final int jvmciCountersThreadOffset = >>>>> getFieldOffset("JavaThread::_jvmci_counters", Integer.class, >>>>> "jlong*"); >>>>> diff --git >>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>>> >>>>> index 6b37fff083d..ffc8032d2b0 100644 >>>>> --- >>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>>> >>>>> +++ >>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>>> >>>>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins { >>>>> ????????????? } >>>>> ????????? }); >>>>> ? - r.registerMethodSubstitution(ThreadSubstitutions.class, >>>>> "isInterrupted", Receiver.class, boolean.class); >>>>> +??????? if (config.osThreadOffset != Integer.MAX_VALUE) { >>>>> + r.registerMethodSubstitution(ThreadSubstitutions.class, >>>>> "isInterrupted", Receiver.class, boolean.class); >>>>> +??????? } >>>>> ????? } >>>>> ??????? public static final String reflectionClass; >>>>> diff --git >>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>>> >>>>> index 1d694fae2a4..8500c4de115 100644 >>>>> --- >>>>> a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>>> >>>>> +++ >>>>> b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>>> >>>>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil { >>>>> ??????? @Fold >>>>> ????? public static int osThreadOffset(@InjectedParameter >>>>> GraalHotSpotVMConfig config) { >>>>> +??????? assert config.instanceKlassInitThreadOffset != >>>>> Integer.MAX_VALUE; >>>>> ????????? return config.osThreadOffset; >>>>> ????? } >>>>> ? All the other JVMCI changes look good to me. >>>>> -Doug >>>>>> On 29 Oct 2019, at 08:42, David Holmes >>>>>> wrote: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already >>>>>> approved) >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >>>>>> >>>>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, >>>>>> but only in small pieces each. There is also a small touch to >>>>>> serviceability code. >>>>>> >>>>>> This change is "simply" moving the "interrupted" field out of the >>>>>> osThread and into the java.lang.Thread so that it can be set >>>>>> independently of whether the thread is alive (and to make things >>>>>> easier for loom in the near future). It is very straightforward: >>>>>> >>>>>> - old scheme >>>>>> ? - interrupted field is in osThread >>>>>> ? - VM can read/write directly >>>>>> ? - Java code calls into VM to read/write >>>>>> >>>>>> - new scheme >>>>>> ? - interrupted field is in java.lang.Thread >>>>>> ? - VM has to use javaCalls to read/write "directly" >>>>>> ? - Java code can read/write directly >>>>>> >>>>>> No changes to any of the semantics regarding the actual interrupt >>>>>> mechanism. Special thanks to Patricio for tracking down a bug I >>>>>> had introduced in that regard! >>>>>> >>>>>> Special Note (Hi Roger!): on windows we still need to set/clear >>>>>> the _interrupt_event used by the Process.waitFor logic. To >>>>>> facilitate clearing via Thread.interrupted() I had to introduce a >>>>>> native method that is a no-op except on Windows. This seemed the >>>>>> cheapest and least intrusive means to achieve this. >>>>>> >>>>>> Other changes revolve around the fact we used to have an intrinsic >>>>>> for Thread.isInterrupted and that is not needed any more. So we >>>>>> strip some code out of C1/C2. >>>>>> >>>>>> The changes in the JVMCI/Graal code are a bit more far reaching as >>>>>> entire classes disappear. I've cc'd Doug and Tom at Vladimir's >>>>>> request so that they can comment on the JVMCI changes and whether >>>>>> I have gone too far or not far enough. There are a bunch of tests >>>>>> for interruption in JVMCI that could potentially be deleted if >>>>>> they are only intended to test the JVMCI handling of interrupt: >>>>>> >>>>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >>>>>> >>>>>> >>>>>> Testing: >>>>>> - Tiers 1-3 on all Oracle platforms >>>>>> - Focused testing on Linux x64: >>>>>> ??? - Stress runs of JSR166TestCase >>>>>> ??? - Anything that seems to use interrupt(): >>>>>> ????? - JDK >>>>>> ??????? - java/lang/Thread >>>>>> ??????? - java/util/concurrent >>>>>> ??????? - jdk/internal/loader/InterruptedClassLoad.java >>>>>> ??????? - javax/management >>>>>> ??????? - java/nio/file/Files >>>>>> ??????? - java/nio/channels >>>>>> ??????? - java/net/Socket/Timeouts.java >>>>>> ??????? - java/lang/Runtime/shutdown/ >>>>>> ??????? - java/lang/ProcessBuilder/Basic.java >>>>>> ??????? - com/sun/jdi/ >>>>>> ????? - Hotspot >>>>>> ??????? - vmTestbase/nsk/monitoring/ >>>>>> ??????? - vmTestbase/nsk/jdwp >>>>>> ??????? - vmTestbase/nsk/jdb/ >>>>>> ??????? - vmTestbase/nsk/jdi/ >>>>>> ??????? - vmTestbase/nsk/jvmti/ >>>>>> ??????? - runtime/Thread >>>>>> ??????? - serviceability/jvmti/ >>>>>> ??????? - serviceability/jdwp >>>>>> ??????? - serviceability/sa >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>> > From david.holmes at oracle.com Thu Oct 31 04:30:16 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Oct 2019 14:30:16 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com> References: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com> Message-ID: <6b4c5a1c-222d-e024-1d84-0475b2a8dade@oracle.com> Hi Doug, On 30/10/2019 10:06 pm, Doug Simon wrote: > > >> On 30 Oct 2019, at 05:28, David Holmes wrote: >> >> Hi Doug, >> >> Your proposed patch wasn't quite right. I made some adjustments but I'm still having issues with the test, HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see how to make the test execution conditional on the VM config. > > Like this: Thanks for that! One alteration below ... > diff --git a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java > index 96e7d979d36..3c928b86961 100644 > --- a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java > +++ b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java > @@ -28,12 +28,13 @@ import java.lang.invoke.ConstantCallSite; > import java.lang.invoke.MethodHandles; > import java.lang.invoke.MethodType; > > -import org.graalvm.compiler.nodes.IfNode; > -import org.junit.Test; > - > import org.graalvm.compiler.api.directives.GraalDirectives; > import org.graalvm.compiler.api.replacements.MethodSubstitution; > +import org.graalvm.compiler.hotspot.GraalHotSpotVMConfig; > +import org.graalvm.compiler.hotspot.HotSpotBackend; > +import org.graalvm.compiler.nodes.IfNode; > import org.graalvm.compiler.replacements.test.MethodSubstitutionTest; > +import org.junit.Test; > > /** > * Tests HotSpot specific {@link MethodSubstitution}s. > @@ -133,13 +134,18 @@ public class HotSpotMethodSubstitutionTest extends MethodSubstitutionTest { > > @Test > public void testThreadSubstitutions() { > + GraalHotSpotVMConfig config = ((HotSpotBackend) getBackend()).getRuntime().getVMConfig(); > testGraph("currentThread"); > - assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class); > - assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class); > + if (config.osThreadOffset != Integer.MAX_VALUE) { s/osThreadOffset/osThreadInterruptedOffset/ This change removes the interrupted field from osThread but not osThread itself. Though as osThread is only used to then access the interrupted field, I could both the same. Here's updated webrev showing that: http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/ All tests under compiler/graalunit now pass. Thanks, David ----- > + assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class); > + assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class); > + } > > Thread currentThread = Thread.currentThread(); > test("currentThread", currentThread); > - test("threadIsInterrupted", currentThread); > + if (config.osThreadOffset != Integer.MAX_VALUE) { > + test("threadIsInterrupted", currentThread); > + } > } > > @SuppressWarnings("all") > >> >> Updated webrev: >> >> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/ >> >> Thanks, >> David >> ----- >> >> >> On 29/10/2019 7:14 pm, Doug Simon wrote: >>>> On 29 Oct 2019, at 10:12, David Holmes wrote: >>>> >>>> Hi Doug, >>>> >>>> Thanks for taking a look so quickly! :) >>>> >>>> On 29/10/2019 6:55 pm, Doug Simon wrote: >>>>> Hi David, >>>>> Since Graal needs to work against multiple JVMCI versions (and VM versions!), the Graal changes should only disable the intrinsic when the relevant VM config is missing: >>>> >>>> So to be clear I should revert all the Graal file changes I made and just apply the patch below? >>> Yes please. >>> -Doug >>>> >>>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>>> index 0752a621215..baa2136a6ba 100644 >>>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java >>>>> @@ -315,7 +315,7 @@ public class GraalHotSpotVMConfig extends GraalHotSpotVMConfigBase { >>>>> public final int javaThreadAnchorOffset = getFieldOffset("JavaThread::_anchor", Integer.class, "JavaFrameAnchor"); >>>>> public final int javaThreadShouldPostOnExceptionsFlagOffset = getFieldOffset("JavaThread::_should_post_on_exceptions_flag", Integer.class, "int", Integer.MIN_VALUE); >>>>> public final int threadObjectOffset = getFieldOffset("JavaThread::_threadObj", Integer.class, "oop"); >>>>> - public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*"); >>>>> + public final int osThreadOffset = getFieldOffset("JavaThread::_osthread", Integer.class, "OSThread*", Integer.MAX_VALUE); >>>>> public final int threadIsMethodHandleReturnOffset = getFieldOffset("JavaThread::_is_method_handle_return", Integer.class, "int"); >>>>> public final int threadObjectResultOffset = getFieldOffset("JavaThread::_vm_result", Integer.class, "oop"); >>>>> public final int jvmciCountersThreadOffset = getFieldOffset("JavaThread::_jvmci_counters", Integer.class, "jlong*"); >>>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>>> index 6b37fff083d..ffc8032d2b0 100644 >>>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/meta/HotSpotGraphBuilderPlugins.java >>>>> @@ -441,7 +441,9 @@ public class HotSpotGraphBuilderPlugins { >>>>> } >>>>> }); >>>>> - r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); >>>>> + if (config.osThreadOffset != Integer.MAX_VALUE) { >>>>> + r.registerMethodSubstitution(ThreadSubstitutions.class, "isInterrupted", Receiver.class, boolean.class); >>>>> + } >>>>> } >>>>> public static final String reflectionClass; >>>>> diff --git a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>>> index 1d694fae2a4..8500c4de115 100644 >>>>> --- a/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>>> +++ b/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/replacements/HotSpotReplacementsUtil.java >>>>> @@ -308,6 +308,7 @@ public class HotSpotReplacementsUtil { >>>>> @Fold >>>>> public static int osThreadOffset(@InjectedParameter GraalHotSpotVMConfig config) { >>>>> + assert config.instanceKlassInitThreadOffset != Integer.MAX_VALUE; >>>>> return config.osThreadOffset; >>>>> } >>>>> All the other JVMCI changes look good to me. >>>>> -Doug >>>>>> On 29 Oct 2019, at 08:42, David Holmes wrote: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8229516 >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8232676 (already approved) >>>>>> webrev: http://cr.openjdk.java.net/~dholmes/8229516/webrev/ >>>>>> >>>>>> This cross-cuts core-libs, hotspot-runtime and the JIT compilers, but only in small pieces each. There is also a small touch to serviceability code. >>>>>> >>>>>> This change is "simply" moving the "interrupted" field out of the osThread and into the java.lang.Thread so that it can be set independently of whether the thread is alive (and to make things easier for loom in the near future). It is very straightforward: >>>>>> >>>>>> - old scheme >>>>>> - interrupted field is in osThread >>>>>> - VM can read/write directly >>>>>> - Java code calls into VM to read/write >>>>>> >>>>>> - new scheme >>>>>> - interrupted field is in java.lang.Thread >>>>>> - VM has to use javaCalls to read/write "directly" >>>>>> - Java code can read/write directly >>>>>> >>>>>> No changes to any of the semantics regarding the actual interrupt mechanism. Special thanks to Patricio for tracking down a bug I had introduced in that regard! >>>>>> >>>>>> Special Note (Hi Roger!): on windows we still need to set/clear the _interrupt_event used by the Process.waitFor logic. To facilitate clearing via Thread.interrupted() I had to introduce a native method that is a no-op except on Windows. This seemed the cheapest and least intrusive means to achieve this. >>>>>> >>>>>> Other changes revolve around the fact we used to have an intrinsic for Thread.isInterrupted and that is not needed any more. So we strip some code out of C1/C2. >>>>>> >>>>>> The changes in the JVMCI/Graal code are a bit more far reaching as entire classes disappear. I've cc'd Doug and Tom at Vladimir's request so that they can comment on the JVMCI changes and whether I have gone too far or not far enough. There are a bunch of tests for interruption in JVMCI that could potentially be deleted if they are only intended to test the JVMCI handling of interrupt: >>>>>> >>>>>> ./jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.jtt/src/org/graalvm/compiler/jtt/threads/Thread_isInterrupted*.java >>>>>> >>>>>> Testing: >>>>>> - Tiers 1-3 on all Oracle platforms >>>>>> - Focused testing on Linux x64: >>>>>> - Stress runs of JSR166TestCase >>>>>> - Anything that seems to use interrupt(): >>>>>> - JDK >>>>>> - java/lang/Thread >>>>>> - java/util/concurrent >>>>>> - jdk/internal/loader/InterruptedClassLoad.java >>>>>> - javax/management >>>>>> - java/nio/file/Files >>>>>> - java/nio/channels >>>>>> - java/net/Socket/Timeouts.java >>>>>> - java/lang/Runtime/shutdown/ >>>>>> - java/lang/ProcessBuilder/Basic.java >>>>>> - com/sun/jdi/ >>>>>> - Hotspot >>>>>> - vmTestbase/nsk/monitoring/ >>>>>> - vmTestbase/nsk/jdwp >>>>>> - vmTestbase/nsk/jdb/ >>>>>> - vmTestbase/nsk/jdi/ >>>>>> - vmTestbase/nsk/jvmti/ >>>>>> - runtime/Thread >>>>>> - serviceability/jvmti/ >>>>>> - serviceability/jdwp >>>>>> - serviceability/sa >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- > From thomas.stuefe at gmail.com Thu Oct 31 07:01:46 2019 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 31 Oct 2019 08:01:46 +0100 Subject: RFR(xs): 8233019: java.lang.Class.isPrimitive() (C1) returns wrong result if Klass* is aligned to 32bit In-Reply-To: References: Message-ID: Hi Martin, thanks for the review! New version: http://cr.openjdk.java.net/~stuefe/webrevs/8233019--c1-intrinsic-for-java.lang.class.isprimitive()-does-32bit-compare/webrev.01/webrev/ pls find remarks inline. On Wed, Oct 30, 2019 at 1:09 PM Doerr, Martin wrote: > Hi Thomas, > > > > thank you for finding and fixing this issue. > > > > Shared code part and regression test look good to me. > > But I have a few requests and questions related to the platform code. > > > > Arm32: > > Breaks build. The local variable p needs a scope. Can be fixed by: > > - case T_METADATA: > > + case T_METADATA: { > > // We only need, for now, comparison with NULL for metadata. > > ? > > break; > > + } > > Ouch. Fixed. Actually, I discarded my coding completely and took over the code from T_OBJECT to keep in line with the rest of the coding here. > > > S390: > > Using z_cgfi is correct, but there are equivalent instructions with > shorter opcode. > > For comparing to 0, z_ltgr(reg1, reg1) or z_cghi(reg1, 0) may be > preferred. But that?s not a big deal. > > > Okay I switched to cghi. ltgr sounds cool but would be difficult to integrate into the shared part since that one does first a move, then a compare. > I wonder why you have added includes to some platform files. Isn?t that > redundant? > > "utilities/debug.hpp" comes via shared assembler.hpp. > Did this because I added asserts and the rule is that every file should include what it needs and not rely on other includes including it (save for umbrella includes like globalDefinitions.hpp). But okay, I removed the added includes again to keep the patch small. > > > I?d probably choose Unimplemented() instead of ShouldNotReachHere() for > non-null cases because it?s not bad in general, it?s just currently not > used and therefore not yet implemented. > > But you can keep that as it is. I?m ok with that, too. > > I rather keep it to keep in line with the rest of the code (see e.g. the default: branches). > > > Best regards, > > Martin > > > Thanks Martin! ..Thomas > > > *From:* Thomas St?fe > *Sent:* Mittwoch, 30. Oktober 2019 11:48 > *To:* hotspot compiler > *Cc:* Doerr, Martin ; Schmidt, Lutz < > lutz.schmidt at sap.com> > *Subject:* RFR(xs): 8233019: java.lang.Class.isPrimitive() (C1) returns > wrong result if Klass* is aligned to 32bit > > > > Hi all, > > > > second attempt at a fix (please find first review thread here: > https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2019-October/035608.html > ) > > > > Issue: https://bugs.openjdk.java.net/browse/JDK-8233019 > > webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/8233019--c1-intrinsic-for-java.lang.class.isprimitive()-does-32bit-compare/webrev.00/webrev/ > > > > In short, C1 intrinsic for jlC::isPrimitive does a compare with the Klass* > pointer for the class to find out if its NULL and hence a primitive type. > That compare is done using 32bit cmp and so it gives wrong results when the > Klass* pointer is aligned to 32bit. > > > > In the generator I changed the comparison constant type from intConst(0) > to metadataConst(0) and implemented the missing code paths for all CPUs. > Since on most architectures we do not seem to have a comparison with a > 64bit immediate (at least I could not find one) I kept the change simple > and only implemented comparison with NULL for now. > > > > I tested the fix in our nightlies (jtreg tier1, jck and others) as well as > manually testing it. > > > > I did not test on aarch64 and arm though and would be thankful if someone > knowledgeable to these platforms could take a look. > > > > Thanks to Martin and Lutz for eyeballing the ppc and s390 parts. > > > > Thanks, Thomas > From doug.simon at oracle.com Thu Oct 31 07:47:54 2019 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 31 Oct 2019 08:47:54 +0100 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: <6b4c5a1c-222d-e024-1d84-0475b2a8dade@oracle.com> References: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com> <6b4c5a1c-222d-e024-1d84-0475b2a8dade@oracle.com> Message-ID: <7E58F19E-5B78-4F96-B328-B9C485CABF86@oracle.com> > On 31 Oct 2019, at 05:30, David Holmes wrote: > > Hi Doug, > > On 30/10/2019 10:06 pm, Doug Simon wrote: >>> On 30 Oct 2019, at 05:28, David Holmes > wrote: >>> >>> Hi Doug, >>> >>> Your proposed patch wasn't quite right. I made some adjustments but I'm still having issues with the test, HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't see how to make the test execution conditional on the VM config. >> Like this: > > Thanks for that! One alteration below ... > >> diff --git a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java >> index 96e7d979d36..3c928b86961 100644 >> --- a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java >> +++ b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java >> @@ -28,12 +28,13 @@ import java.lang.invoke.ConstantCallSite; >> import java.lang.invoke.MethodHandles; >> import java.lang.invoke.MethodType; >> -import org.graalvm.compiler.nodes.IfNode; >> -import org.junit.Test; >> - >> import org.graalvm.compiler.api.directives.GraalDirectives; >> import org.graalvm.compiler.api.replacements.MethodSubstitution; >> +import org.graalvm.compiler.hotspot.GraalHotSpotVMConfig; >> +import org.graalvm.compiler.hotspot.HotSpotBackend; >> +import org.graalvm.compiler.nodes.IfNode; >> import org.graalvm.compiler.replacements.test.MethodSubstitutionTest; >> +import org.junit.Test; >> /** >> * Tests HotSpot specific {@link MethodSubstitution}s. >> @@ -133,13 +134,18 @@ public class HotSpotMethodSubstitutionTest extends MethodSubstitutionTest { >> @Test >> public void testThreadSubstitutions() { >> + GraalHotSpotVMConfig config = ((HotSpotBackend) getBackend()).getRuntime().getVMConfig(); >> testGraph("currentThread"); >> - assertInGraph(testGraph("threadIsInterrupted", "isInterrupted", true), IfNode.class); >> - assertInGraph(testGraph("threadInterrupted", "isInterrupted", true), IfNode.class); >> + if (config.osThreadOffset != Integer.MAX_VALUE) { > > s/osThreadOffset/osThreadInterruptedOffset/ Good catch. Sorry about that. > > This change removes the interrupted field from osThread but not osThread itself. Though as osThread is only used to then access the interrupted field, I could both the same. Here's updated webrev showing that: > > http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/ Looks good. -Doug From david.holmes at oracle.com Thu Oct 31 08:45:00 2019 From: david.holmes at oracle.com (David Holmes) Date: Thu, 31 Oct 2019 18:45:00 +1000 Subject: RFR: 8229516: Thread.isInterrupted() always returns false after thread termination In-Reply-To: <7E58F19E-5B78-4F96-B328-B9C485CABF86@oracle.com> References: <607FF273-D73B-42B2-B76D-52FE6D6159C8@oracle.com> <8d19ddb7-3416-41cc-9ad8-7d33ff437415@oracle.com> <31F9850D-8E3C-4682-B932-29BC53188B90@oracle.com> <6b4c5a1c-222d-e024-1d84-0475b2a8dade@oracle.com> <7E58F19E-5B78-4F96-B328-B9C485CABF86@oracle.com> Message-ID: <57b1a2ad-2361-dfee-0085-2098fefe1d66@oracle.com> Thanks Doug! Appreciate the help getting the Graal bits correct. David On 31/10/2019 5:47 pm, Doug Simon wrote: > > >> On 31 Oct 2019, at 05:30, David Holmes > > wrote: >> >> Hi Doug, >> >> On 30/10/2019 10:06 pm, Doug Simon wrote: >>>> On 30 Oct 2019, at 05:28, David Holmes >>> > wrote: >>>> >>>> Hi Doug, >>>> >>>> Your proposed patch wasn't quite right. I made some adjustments but >>>> I'm still having issues with the test, >>>> HotSpotMethodSubstitutionTest.testThreadSubstitutions, as I don't >>>> see how to make the test execution conditional on the VM config. >>> Like this: >> >> Thanks for that! One alteration below ... >> >>> diff --git >>> a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java >>> b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java >>> index 96e7d979d36..3c928b86961 100644 >>> --- >>> a/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java >>> +++ >>> b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotMethodSubstitutionTest.java >>> @@ -28,12 +28,13 @@ import java.lang.invoke.ConstantCallSite; >>> ?import java.lang.invoke.MethodHandles; >>> ?import java.lang.invoke.MethodType; >>> -import org.graalvm.compiler.nodes.IfNode; >>> -import org.junit.Test; >>> - >>> ?import org.graalvm.compiler.api.directives.GraalDirectives; >>> ?import org.graalvm.compiler.api.replacements.MethodSubstitution; >>> +import org.graalvm.compiler.hotspot.GraalHotSpotVMConfig; >>> +import org.graalvm.compiler.hotspot.HotSpotBackend; >>> +import org.graalvm.compiler.nodes.IfNode; >>> ?import org.graalvm.compiler.replacements.test.MethodSubstitutionTest; >>> +import org.junit.Test; >>> ?/** >>> ??* Tests HotSpot specific {@link MethodSubstitution}s. >>> @@ -133,13 +134,18 @@ public class HotSpotMethodSubstitutionTest >>> extends MethodSubstitutionTest { >>> ?????@Test >>> ?????public void testThreadSubstitutions() { >>> + ???????GraalHotSpotVMConfig config = ((HotSpotBackend) >>> getBackend()).getRuntime().getVMConfig(); >>> ?????????testGraph("currentThread"); >>> - ???????assertInGraph(testGraph("threadIsInterrupted", >>> "isInterrupted", true), IfNode.class); >>> - ???????assertInGraph(testGraph("threadInterrupted", >>> "isInterrupted", true), IfNode.class); >>> + ???????if (config.osThreadOffset != Integer.MAX_VALUE) { >> >> s/osThreadOffset/osThreadInterruptedOffset/ > > Good catch. Sorry about that. >> >> This change removes the interrupted field from osThread but not >> osThread itself. Though as osThread is only used to then access the >> interrupted field, I could both the same. Here's updated webrev >> showing that: >> >> http://cr.openjdk.java.net/~dholmes/8229516/webrev.v2/ > > Looks good. > > -Doug From christoph.goettschkes at microdoc.com Thu Oct 31 09:12:05 2019 From: christoph.goettschkes at microdoc.com (christoph.goettschkes at microdoc.com) Date: Thu, 31 Oct 2019 10:12:05 +0100 Subject: RFR: 8231955: ARM32: Address displacement is 0 for volatile field access because of Unsafe field access. In-Reply-To: <587f6363-bbdc-da12-9e50-82acc5bc5853@oracle.com> References: <20191010143426.BA4B6319F46@aojmv0009> <20191015073212.7FCCA319074@aojmv0009> <587f6363-bbdc-da12-9e50-82acc5bc5853@oracle.com> Message-ID: > I see now that BarrierSetC1::resolve_address() is calling > generate_address(), at least when access isn't patched. So now I'm > thinking that the address passed to > volatile_field_load/volatile_field_store should be correct, and the call > to add_large_constant() isn't necessary. Yes, this is correct. The LIR_Address is created by LIRGenerator::generate_address and has a displacement of 0. I attached a backtrace of the failing assert at the end of this mail. Do you think the patch makes sense and can be pushed? The HotSpot tier1 JTreg tests are passing with this and other patches I am working on applied with a debug VM. -- Christoph #0 0x7636b860 in LIRGenerator::add_large_constant (this=0x641ae2f0, src=0xe500b, c=0, dest=0xe900b) at src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp:166 #1 0x7636f266 in LIRGenerator::volatile_field_load (this=0x641ae2f0, address=0x6429c970, result=0xdd093, info=0x0) at src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp:1326 #2 0x762d9806 in BarrierSetC1::load_at_resolved (this=0x7602b1f0, access=..., result=0xdd093) at src/hotspot/share/gc/shared/c1/barrierSetC1.cpp:183 #3 0x762d929a in BarrierSetC1::load_at (this=0x7602b1f0, access=..., result=0xdd093) at src/hotspot/share/gc/shared/c1/barrierSetC1.cpp:94 #4 0x7635f6cc in LIRGenerator::access_load_at (this=0x641ae2f0, decorators=9127331840, type=T_LONG, base=..., offset=0xd900b, result=0xdd093, patch_info=0x0, load_emit_info=0x0) at src/hotspot/share/c1/c1_LIRGenerator.cpp:1618 #5 0x7636133e in LIRGenerator::do_UnsafeGetObject (this=0x641ae2f0, x=0x6429a0d0) at src/hotspot/share/c1/c1_LIRGenerator.cpp:2173 #6 0x76328bdc in UnsafeGetObject::visit (this=0x6429a0d0, v=0x641ae2f0) at src/hotspot/share/c1/c1_Instruction.hpp:2407 #7 0x7635b2d2 in LIRGenerator::do_root (this=0x641ae2f0, instr=0x6429a0d0) at src/hotspot/share/c1/c1_LIRGenerator.cpp:373 #8 0x7635b1f2 in LIRGenerator::block_do (this=0x641ae2f0, block=0x64299788) at src/hotspot/share/c1/c1_LIRGenerator.cpp:354 #9 0x76337d5a in BlockList::iterate_forward (this=0x6429bf00, closure=0x641ae2f4) at src/hotspot/share/c1/c1_Instruction.cpp:921 #10 0x76332936 in IR::iterate_linear_scan_order (this=0x642994d0, closure=0x641ae2f4) at src/hotspot/share/c1/c1_IR.cpp:1221 #11 0x7630ed10 in Compilation::emit_lir (this=0x641ae5c0) at src/hotspot/share/c1/c1_Compilation.cpp:259 #12 0x7630f2be in Compilation::compile_java_method (this=0x641ae5c0) at src/hotspot/share/c1/c1_Compilation.cpp:398 #13 0x7630f566 in Compilation::compile_method (this=0x641ae5c0) at src/hotspot/share/c1/c1_Compilation.cpp:460 #14 0x7630fabc in Compilation::Compilation (this=0x641ae5c0, compiler=0x760eb610, env=0x641ae848, method=0x63d2edc8, osr_bci=-1, buffer_blob=0x73eb7448, directive=0x760cf858) at src/hotspot/share/c1/c1_Compilation.cpp:583 #15 0x76312d6e in Compiler::compile_method (this=0x760eb610, env=0x641ae848, method=0x63d2edc8, entry_bci=-1, directive=0x760cf858) at src/hotspot/share/c1/c1_Compiler.cpp:247 #16 0x76453704 in CompileBroker::invoke_compiler_on_method (task=0x642cfa50) at src/hotspot/share/compiler/compileBroker.cpp:2115 #17 0x764529ba in CompileBroker::compiler_thread_loop () at src/hotspot/share/compiler/compileBroker.cpp:1800 #18 0x7693548c in compiler_thread_entry (thread=0x6423b400, __the_thread__=0x6423b400) at src/hotspot/share/runtime/thread.cpp:3401 #19 0x769315d4 in JavaThread::thread_main_inner (this=0x6423b400) at src/hotspot/share/runtime/thread.cpp:1917 #20 0x769314ac in JavaThread::run (this=0x6423b400) at src/hotspot/share/runtime/thread.cpp:1900 #21 0x7692e884 in Thread::call_run (this=0x6423b400) at src/hotspot/share/runtime/thread.cpp:398 #22 0x768285ce in thread_native_entry (thread=0x6423b400) at src/hotspot/os/linux/os_linux.cpp:790 #23 0x76f84568 in start_thread() from target:/usr/lib/libpthread.so.0 #24 0x76ef8ac8 in ?? () from target:/usr/lib/libc.so.6 From sgehwolf at redhat.com Thu Oct 31 09:14:50 2019 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 31 Oct 2019 10:14:50 +0100 Subject: [8u] RFR: 8233023: assert(Opcode() == mem->Opcode() || phase->C->get_alias_index(adr_type()) == Compile::AliasIdxRaw) failed: no mismatched stores, except on raw memory In-Reply-To: References: <7a2d50793120bdeb86d0047fd09db18c725328e0.camel@redhat.com> Message-ID: <2c7a6e1a803213f4bfc983f13db596b40f2838b3.camel@redhat.com> On Thu, 2019-10-31 at 00:21 +0000, Hohensee, Paul wrote: > Lgtm. Thanks for the review, Paul! Cheers, Severin > Paul > > ?On 10/30/19, 2:42 AM, "jdk8u-dev on behalf of Severin Gehwolf" wrote: > > Hi, > > Could I please get a review of this 8u only issue? The reason a > fastdebug build of latest OpenJDK 8u asserts for the dec-tree benchmark > of the renaissance suite is because the 8u backport of JDK-8140309 was > missing this hunk from JDK 9[1]: > > + (Opcode() == Op_StoreL && st->Opcode() == Op_StoreI) || // expanded ClearArrayNode > + (is_mismatched_access() || st->as_Store()->is_mismatched_access()), > > I had a closer look and there doesn't seem to be missing anything else. > The proposed fix is to amend the assert condition in the appropriate > place, which brings 8u in line with JDK 9 code where the failure isn't > observed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8233023 > webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8233023/01/webrev/ > > Testing: 8u tier1 test set with fastdebug build on x86_64 Linux. No new > failures. dec-tree benchmark now runs successfully on an 8u fastdebug > build. > > Thoughts? > > Thanks, > Severin > > [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/4bee38ba018c > > > From nils.eliasson at oracle.com Thu Oct 31 16:37:50 2019 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 31 Oct 2019 17:37:50 +0100 Subject: RFR(M): 8232896: ZGC: Enable C2 clone intrinsic Message-ID: <2d509788-35f0-1fed-c305-d98d76583c66@oracle.com> Hi, This patch fixes and enables the clone intrinsic for C2 with ZGC. The main thing added is an implementation of the ZBarrierSetC2::clone_at_expansion method. This method handles clone expansion for regular objects and primitive arrays that hasn't already been reduced by optimizations. (Oop array clones doesn't go through this path.) The code switches on the type of the source to either make a leaf call to a runtime clone for regular objects, or delegate to BarrierSetC2::clone_at_expansion for primitive arrays. Updated micro benchmark shows great gains, especially for small objects that now will be reduced to inlined move-store sequences. Bug: https://bugs.openjdk.java.net/browse/JDK-8232896 Webrev: http://cr.openjdk.java.net/~neliasso/8232896/webrev.02/ Please review, Nils Eliasson From vladimir.kozlov at oracle.com Thu Oct 31 16:52:54 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Oct 2019 09:52:54 -0700 Subject: RFR(M): 8232896: ZGC: Enable C2 clone intrinsic In-Reply-To: <2d509788-35f0-1fed-c305-d98d76583c66@oracle.com> References: <2d509788-35f0-1fed-c305-d98d76583c66@oracle.com> Message-ID: <5DD60259-7AD2-4510-B880-F5EDCFC467B2@oracle.com> Looks good. Thanks Vladimir > On Oct 31, 2019, at 9:37 AM, Nils Eliasson wrote: > > Hi, > > This patch fixes and enables the clone intrinsic for C2 with ZGC. > > The main thing added is an implementation of the ZBarrierSetC2::clone_at_expansion method. This method handles clone expansion for regular objects and primitive arrays that hasn't already been reduced by optimizations. (Oop array clones doesn't go through this path.) > > The code switches on the type of the source to either make a leaf call to a runtime clone for regular objects, or delegate to BarrierSetC2::clone_at_expansion for primitive arrays. > > Updated micro benchmark shows great gains, especially for small objects that now will be reduced to inlined move-store sequences. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8232896 > > Webrev: http://cr.openjdk.java.net/~neliasso/8232896/webrev.02/ > > > Please review, > > Nils Eliasson > From lutz.schmidt at sap.com Thu Oct 31 16:55:03 2019 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 31 Oct 2019 16:55:03 +0000 Subject: RFR(M): 8231460: Performance issue (CodeHeap) with large free blocks In-Reply-To: <254f2bf0-94f8-8e78-b043-f428f2d2a0f1@redhat.com> References: <3DE63BEB-C9F8-429D-8C38-F1531A2E9F0A@sap.com> <37969751-34df-da93-90cc-5746ca4b5a4d@redhat.com> <6a9e3306-ff2b-1ded-c0fc-22af5831e776@redhat.com> <5A263499-D410-4D2A-B257-2F3849BE6D9C@sap.com> <3fce238d-33c8-3ea1-8ba2-b843faca13c2@redhat.com> <604ED3F3-7A81-46A6-AD44-AB838DE018D3@sap.com> <254f2bf0-94f8-8e78-b043-f428f2d2a0f1@redhat.com> Message-ID: <84AF3336-7370-4642-AB04-7015B3AFC4F1@sap.com> Hi Andrew, (and hi to the interested crowd), Please accept my apologies for taking so long to get back. These tests (OverflowCodeCacheTest and StressCodeCacheTest) were causing me quite some headaches. Some layer between me and the test prevents the vm (in particular: the VMThread) from terminating normally. The final output from my time measurements is therefore not generated or thrown away. Adding to that were some test machine unavailabilities and a bug in my measurement code, causing crashes. Anyway, I added some on-the-fly output, printing the timer values after 10k measurement intervals. This reveals some interesting, additional facts about the tests and the CodeHeap management methods. For detailed numbers, refer to the files attached to the bug (https://bugs.openjdk.java.net/browse/JDK-8231460). For even more detail, I can provide the jtr files on request. OverflowCodeCacheTest ===================== This test runs (in my setup) with a 1GB CodeCache. For this test, CodeHeap::mark_segmap_as_used() is THE performance hog. 40% of all calls have to mark more than 16k segment map entries (in the not optimized case). Basically all of these calls convert to len=1 calls with the optimization turned on. Note that during FreeBlock joining, the segment count is forced to 1(one). No wonder the time spent in CodeHeap::mark_segmap_as_used() collapses from >80sec (half of the test runtime) to <100msec. CodeHeap::add_to_freelist() on the other hand, is almost not observable. Average free list length is at two elements, making even linear search really quick. StressCodeCacheTest =================== With a 1GB CodeCache, this test runs into a 12 min timeout, set by our internal test environment. Scaling back to 300MB prevents the test from timing out. For this test, CodeHeap::mark_segmap_as_used() is not a factor. From 200,000 calls, only a few (less than 3%) had to process a block consisting of more than 16 segments. Note that during FreeBlock joining, the segment count is forced to 1(one). Another method is popping up as performance hog instead: CodeHeap::add_to_freelist(). More than 8 out of 40 seconds of test runtime (before optimization) are spent in this method, for just 160,000 calls. The test seems to create a long list of non-contiguous free blocks (around 5,500 on average). This list is linearly scanned to find the insert point for the free block at hand. Suffering as well from the long free block list is CodeHeap::search_freelist(). It uses another 2.7 seconds for 270,000 calls. SPEVjvm2008 suite ================= With respect to the task at hand, this is a well-behaved test suite. Timing shows some before/after difference, but nothing spectacular. The measurements due not provide evidence of a performance bottleneck. There were some minor adjustments to the code. Unused code blocks have been removed as well. I have therefore created a new webrev. You can find it here: http://cr.openjdk.java.net/~lucy/webrevs/8231460.01/ Thanks for investing your time! Lutz On 21.10.19, 15:06, "Andrew Dinn" wrote: Hi Lutz, On 21/10/2019 13:37, Schmidt, Lutz wrote: > I understand what you are interested in. And I was hoping to be able > to provide some (first) numbers by today. Unfortunately, the > measurement code I activated last Friday was buggy and blew most of > the tests I had hoped to run over the weekend. > > I will take your modified test and run it with and without my > optimization. In parallel, I will try to generate some (non-random) > numbers for other tests. > > I'll be back as soon as I have results. Thanks for trying the test and also for deriving some call stats from a real example. I'm keen to see how much your patch improves things. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From dean.long at oracle.com Thu Oct 31 20:03:37 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 31 Oct 2019 13:03:37 -0700 Subject: RFR(XL) 8233273: Update Graal Message-ID: <493515e2-e50c-d514-98f5-c0efad6d3495@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8233273 http://cr.openjdk.java.net/~dlong/8233273/webrev/ This is a Graal update.? Changes since the last update (JDK-8231973) are listed in the bug description. dl From vladimir.kozlov at oracle.com Thu Oct 31 21:27:25 2019 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 31 Oct 2019 14:27:25 -0700 Subject: RFR(XL) 8233273: Update Graal In-Reply-To: <493515e2-e50c-d514-98f5-c0efad6d3495@oracle.com> References: <493515e2-e50c-d514-98f5-c0efad6d3495@oracle.com> Message-ID: <781a2653-0ea8-5088-5019-84c3f728158c@oracle.com> Looks good. Tests results good. Thanks, Vladimir On 10/31/19 1:03 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8233273 > http://cr.openjdk.java.net/~dlong/8233273/webrev/ > > This is a Graal update.? Changes since the last update (JDK-8231973) are listed in the bug description. > > dl > From dean.long at oracle.com Thu Oct 31 23:39:08 2019 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 31 Oct 2019 16:39:08 -0700 Subject: RFR(XL) 8233273: Update Graal In-Reply-To: <781a2653-0ea8-5088-5019-84c3f728158c@oracle.com> References: <493515e2-e50c-d514-98f5-c0efad6d3495@oracle.com> <781a2653-0ea8-5088-5019-84c3f728158c@oracle.com> Message-ID: <005f1702-4fcf-054d-25aa-7ceede6e12cc@oracle.com> Thanks Vladimir. dl On 10/31/19 2:27 PM, Vladimir Kozlov wrote: > Looks good. Tests results good. > > Thanks, > Vladimir > > On 10/31/19 1:03 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8233273 >> http://cr.openjdk.java.net/~dlong/8233273/webrev/ >> >> This is a Graal update.? Changes since the last update (JDK-8231973) >> are listed in the bug description. >> >> dl >>