From vivek.r.deshpande at intel.com Fri Dec 1 00:18:53 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 1 Dec 2017 00:18:53 +0000 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <1e320f59-24a6-0bb8-ff3f-a2c99d47a038@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> <5fd2f8dd-bf78-12ce-3620-0cdd1eb84fc3@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771CEED3@ORSMSX106.amr.corp.intel.com> <1e320f59-24a6-0bb8-ff3f-a2c99d47a038@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771CF0E1@ORSMSX106.amr.corp.intel.com> Hi Vladimir We need no_mask_reg set as true for vector word instructions: pblendw, vphaddw, phaddw. For rest of the instructions we don?t need to remove mask register encoding. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, November 30, 2017 3:44 PM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net Cc: Viswanathan, Sandhya Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. On 11/30/17 2:51 PM, Deshpande, Vivek R wrote: > HI Vladimir > > We are removing the mask register encoding from the scalar instructions as it is not needed. The JIT is not doing any masked scalar operations. Does it affect execution if we don't remove mask register encoding? Thanks, Vladimir > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, November 30, 2017 8:56 AM > To: Deshpande, Vivek R ; > hotspot-compiler-dev at openjdk.java.net > Cc: Viswanathan, Sandhya > Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. > > Thank you, Vivek > > Changes looks good based on your description. > > Please, explain why using mask register in scalar instructions is bad. > > I will start pre-integration testing and let you know results. > > Thanks, > Vladimir > > On 11/30/17 7:28 AM, Deshpande, Vivek R wrote: >> Hi >> >> I have bug fix for 8190494: Different results with UseAVX=3 when calling AVX-512 native function via JNI. >> >> Mask register not being reset after JNI and the scalar floating point >> instructions using the mask register encoding with AVX 512 in the assembler causing this problem. >> >> I have tested it with jtreg on hotspot/compiler and SPECjvm2008 on knights landing and skylake. >> >> Webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ >> >> I have also updated the JBS entry. >> >> https://bugs.openjdk.java.net/browse/JDK-8190494 >> >> Would you please review and sponsor it. >> >> Regards, >> >> Vivek >> From vladimir.kozlov at oracle.com Fri Dec 1 00:35:11 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 16:35:11 -0800 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771CF0E1@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> <5fd2f8dd-bf78-12ce-3620-0cdd1eb84fc3@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771CEED3@ORSMSX106.amr.corp.intel.com> <1e320f59-24a6-0bb8-ff3f-a2c99d47a038@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771CF0E1@ORSMSX106.amr.corp.intel.com> Message-ID: Got it. Thanks, Vladimir On 11/30/17 4:18 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > We need no_mask_reg set as true for vector word instructions: pblendw, vphaddw, phaddw. > For rest of the instructions we don?t need to remove mask register encoding. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, November 30, 2017 3:44 PM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net > Cc: Viswanathan, Sandhya > Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. > > On 11/30/17 2:51 PM, Deshpande, Vivek R wrote: >> HI Vladimir >> >> We are removing the mask register encoding from the scalar instructions as it is not needed. The JIT is not doing any masked scalar operations. > > Does it affect execution if we don't remove mask register encoding? > > Thanks, > Vladimir > >> >> Regards, >> Vivek >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, November 30, 2017 8:56 AM >> To: Deshpande, Vivek R ; >> hotspot-compiler-dev at openjdk.java.net >> Cc: Viswanathan, Sandhya >> Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. >> >> Thank you, Vivek >> >> Changes looks good based on your description. >> >> Please, explain why using mask register in scalar instructions is bad. >> >> I will start pre-integration testing and let you know results. >> >> Thanks, >> Vladimir >> >> On 11/30/17 7:28 AM, Deshpande, Vivek R wrote: >>> Hi >>> >>> I have bug fix for 8190494: Different results with UseAVX=3 when calling AVX-512 native function via JNI. >>> >>> Mask register not being reset after JNI and the scalar floating point >>> instructions using the mask register encoding with AVX 512 in the assembler causing this problem. >>> >>> I have tested it with jtreg on hotspot/compiler and SPECjvm2008 on knights landing and skylake. >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ >>> >>> I have also updated the JBS entry. >>> >>> https://bugs.openjdk.java.net/browse/JDK-8190494 >>> >>> Would you please review and sponsor it. >>> >>> Regards, >>> >>> Vivek >>> From ningsheng.jian at linaro.org Fri Dec 1 01:56:54 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Fri, 1 Dec 2017 09:56:54 +0800 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> <1acbacd7-7967-8da3-2f67-f3babb40f909@redhat.com> Message-ID: Hi, Can anyone please help to push this small change reviewed by aph? Felix is not available these days, and may not help to commit the patch. http://cr.openjdk.java.net/~njian/8191955/webrev.01/ Thanks, Ningsheng On 30 November 2017 at 09:39, Ningsheng Jian wrote: > Thank you Andrew! > > Regards, > Ningsheng > > On 29 November 2017 at 18:17, Andrew Haley wrote: >> On 29/11/17 02:43, Ningsheng Jian wrote: >>> Thanks for the review! Because of the constraint func, with and >>> without the patch it will report an error for -1 input. But since the >>> constraint func is called after get_processor_features, I've updated >>> the patch to leave -1 to be handled by the constraint func. >>> >>> http://cr.openjdk.java.net/~njian/8191955/webrev.01/ >> >> OK. >> >> -- >> Andrew Haley >> Java Platform Lead Engineer >> Red Hat UK Ltd. >> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.kozlov at oracle.com Fri Dec 1 02:24:24 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 18:24:24 -0800 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> Message-ID: <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> I submitted pre-integration testing to make sure the test pass on all our platforms. Thanks, Vladimir On 11/30/17 8:31 AM, Andrew Haley wrote: > On 30/11/17 16:28, Boris Ulasevich wrote: >> Thanks for good points! >> >> Updated webrew (with asserts and renamed test moved to better location): >> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ > > Great, that's good to go. > > I think you have to get someone from Oracle to help because it > includes a new test case. > From dean.long at oracle.com Fri Dec 1 05:28:08 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 30 Nov 2017 21:28:08 -0800 Subject: RFR(XL) 8192814: Update Graal Message-ID: https://bugs.openjdk.java.net/browse/JDK-8192814 http://cr.openjdk.java.net/~dlong/8192814/webrev/ Fixes JDK-8186198 and JDK-8182882.? See the bug for the full list of Graal changes. dl From vladimir.kozlov at oracle.com Fri Dec 1 06:14:47 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 22:14:47 -0800 Subject: RFR(XL) 8192814: Update Graal In-Reply-To: References: Message-ID: <9bd2a475-e50b-8aa9-37c0-e8bd99d6043e@oracle.com> Good. Thanks, Vladimir On 11/30/17 9:28 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8192814 > http://cr.openjdk.java.net/~dlong/8192814/webrev/ > > Fixes JDK-8186198 and JDK-8182882.? See the bug for the full list of Graal changes. > > dl From vladimir.kozlov at oracle.com Fri Dec 1 06:23:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 30 Nov 2017 22:23:37 -0800 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> Message-ID: <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> Testing passed clean. You can push it - we don't use JPRT anymore for pushes. Thanks, Vladimir On 11/30/17 6:24 PM, Vladimir Kozlov wrote: > I submitted pre-integration testing to make sure the test pass on all our platforms. > > Thanks, > Vladimir > > On 11/30/17 8:31 AM, Andrew Haley wrote: >> On 30/11/17 16:28, Boris Ulasevich wrote: >>> Thanks for good points! >>> >>> Updated webrew (with asserts and renamed test moved to better location): >>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >> >> Great, that's good to go. >> >> I think you have to get someone from Oracle to help because it >> includes a new test case. >> From boris.ulasevich at bell-sw.com Fri Dec 1 06:37:39 2017 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 1 Dec 2017 09:37:39 +0300 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> Message-ID: <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> Thank you! Boris Ulasevich 01.12.2017 09:23, Vladimir Kozlov ?????: > Testing passed clean. You can push it - we don't use JPRT anymore for > pushes. > > Thanks, > Vladimir > > On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >> I submitted pre-integration testing to make sure the test pass on all >> our platforms. >> >> Thanks, >> Vladimir >> >> On 11/30/17 8:31 AM, Andrew Haley wrote: >>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>> Thanks for good points! >>>> >>>> Updated webrew (with asserts and renamed test moved to better >>>> location): >>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>> >>> Great, that's good to go. >>> >>> I think you have to get someone from Oracle to help because it >>> includes a new test case. >>> From jamsheed.c.m at oracle.com Fri Dec 1 07:04:34 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Fri, 1 Dec 2017 12:34:34 +0530 Subject: [10] RFR: 8006887: Comment about LIR_OprDesc.value in c1_LIR.hpp is incorrect In-Reply-To: <411d55a3-015d-6854-30d2-daf70092e790@oracle.com> References: <2e327521-c312-c9d8-a7a7-ab410391065a@oracle.com> <4da10d62-c0c0-bc86-ac3f-1135c77a6660@oracle.com> <411d55a3-015d-6854-30d2-daf70092e790@oracle.com> Message-ID: <8bbdcc83-30c5-81fa-bed1-e40098a1da88@oracle.com> Thank you, Dean, Vladimir Best regards, Jamsheed On Thursday 30 November 2017 10:27 PM, Vladimir Kozlov wrote: > Difference (spacing) could be seen here: > > http://cr.openjdk.java.net/~jcm/8006887/webrev.00/open.patch > > Looks good. > > Vladimir > > On 11/30/17 8:50 AM, Vladimir Kozlov wrote: >> Hi Jamsheed >> >> There are no diffs in webrev. >> >> Vladimir >> >> On 11/30/17 8:22 AM, jamsheed wrote: >>> Hi, >>> >>> request for review, >>> >>> webrev: http://cr.openjdk.java.net/~jcm/8006887/webrev.00/ >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8006887 >>> >>> desc: comment correction. >>> >>> Best regards, >>> >>> Jamsheed >>> From vivek.r.deshpande at intel.com Fri Dec 1 07:20:44 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 1 Dec 2017 07:20:44 +0000 Subject: RFR(XS): x86: 8170244: Fix for Update UseAVX after cpu feature detection to use more default mapping Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771CF37E@ORSMSX106.amr.corp.intel.com> Hi I have bug fix for 8170244: Update UseAVX after cpu feature detection to use more default mapping. Webrev: http://cr.openjdk.java.net/~vdeshpande/8170244/webrev.00/ I have also updated the JBS entry. https://bugs.openjdk.java.net/browse/JDK-8170244 Would you please review and sponsor it. Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From goetz.lindenmaier at sap.com Fri Dec 1 07:52:58 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 1 Dec 2017 07:52:58 +0000 Subject: RFR(S): 8192825: PPC64: Missing null check in C1 inline cache check In-Reply-To: <7b820cb2a7b345c7851aa9a74bdb1545@sap.com> References: <7b820cb2a7b345c7851aa9a74bdb1545@sap.com> Message-ID: Hi Martin, thanks for fixing this, looks good. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Donnerstag, 30. November 2017 18:17 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Lindenmaier, Goetz > Subject: RFR(S): 8192825: PPC64: Missing null check in C1 inline cache check > > Hi, > > > > I found a problem on AIX which is cause by a missing null check. > > > > Compiled methods need to perform a null check in the unverified entry. This > is usually done implicitly by loading the Klass*. > > However, implicit null checks may be off on PPC64 (especially on AIX where > the 0 page is readable). > > > > Null checks are especially needed after: > > 8160543: C1: Crash in java.lang.String.indexOf in some java.sql tests > > Summary: C1 must use unverified entry point for unloaded methods. > > > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8192825_PPC64_C1_ic_nullcheck/webr > ev.00/ > > > > Please review. > > > > Best regards, > > Martin > > From rwestrel at redhat.com Fri Dec 1 08:24:48 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 01 Dec 2017 09:24:48 +0100 Subject: RFR(S): 8191950: assertion failed: no insertions allowed Message-ID: http://cr.openjdk.java.net/~roland/8191950/webrev.00/ C2 is trying to incrementally inline a method in a part of the graph that is dead and for which one the projections of the call to inline is also an input to the call. We don't have an inexpensive way to check for unreachable calls when doing incremental inlining so instead I propose we explicitly check for the corner that fails here. No test case as triggering incremental inlining reliably is hard. Roland. From goetz.lindenmaier at sap.com Fri Dec 1 08:27:41 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 1 Dec 2017 08:27:41 +0000 Subject: RFR(XS): 8192818: [s390]: restoring register contents calculates wrong value In-Reply-To: <74C2EC38-9DA2-4B89-AAA9-FE5927FF1CC9@sap.com> References: <74C2EC38-9DA2-4B89-AAA9-FE5927FF1CC9@sap.com> Message-ID: Hi Lutz, thanks for fixing this, looks good! Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Donnerstag, 30. November 2017 17:14 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(XS): 8192818: [s390]: restoring register contents calculates > wrong value > > Dear all, > > > > I would like to request reviews for this s390-only bux fix (one-liner): > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192818 > > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8192818.00/index.html > > > > > Thank you! > > Lutz > > From lutz.schmidt at sap.com Fri Dec 1 08:30:37 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Fri, 1 Dec 2017 08:30:37 +0000 Subject: RFR(XS): 8192818: [s390]: restoring register contents calculates wrong value In-Reply-To: References: <74C2EC38-9DA2-4B89-AAA9-FE5927FF1CC9@sap.com> Message-ID: <47FC36E4-EAE9-4742-9382-D8022E60ED49@sap.com> Thank you, Goetz! Could you please sponsor & push, once we have a second review? Regards, Lutz On 01.12.2017, 09:27, "Lindenmaier, Goetz" wrote: Hi Lutz, thanks for fixing this, looks good! Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Donnerstag, 30. November 2017 17:14 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(XS): 8192818: [s390]: restoring register contents calculates > wrong value > > Dear all, > > > > I would like to request reviews for this s390-only bux fix (one-liner): > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192818 > > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8192818.00/index.html > > > > > Thank you! > > Lutz > > From tobias.hartmann at oracle.com Fri Dec 1 08:45:42 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 1 Dec 2017 09:45:42 +0100 Subject: RFR(S): 8191950: assertion failed: no insertions allowed In-Reply-To: References: Message-ID: <8c9e6244-fa55-903f-8b39-349aeff3815a@oracle.com> Hi Roland, On 01.12.2017 09:24, Roland Westrelin wrote: > C2 is trying to incrementally inline a method in a part of the graph > that is dead and for which one the projections of the call to inline is > also an input to the call. We don't have an inexpensive way to check for > unreachable calls when doing incremental inlining so instead I propose > we explicitly check for the corner that fails here. The "dead loop?" comment is a bit confusing here but I assume the call is part of a loop that became unreachable? (You can remove the newline in 378) Was this introduced by a recent change (because the bug still has the integration_blocker label)? > No test case as triggering incremental inlining reliably is hard. Please add the 'noreg-hard' label to the bug. Thanks, Tobias From rwestrel at redhat.com Fri Dec 1 08:53:06 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 01 Dec 2017 09:53:06 +0100 Subject: RFR(S): 8191950: assertion failed: no insertions allowed In-Reply-To: <8c9e6244-fa55-903f-8b39-349aeff3815a@oracle.com> References: <8c9e6244-fa55-903f-8b39-349aeff3815a@oracle.com> Message-ID: Hi Tobias, Thanks for taking a look at this. > The "dead loop?" comment is a bit confusing here but I assume the call > is part of a loop that became unreachable? Yes. What about: check for unreachable loop? > (You can remove the newline in 378) > > Was this introduced by a recent change (because the bug still has the integration_blocker label)? No, not as far I can tell. Roland. From tobias.hartmann at oracle.com Fri Dec 1 08:57:20 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 1 Dec 2017 09:57:20 +0100 Subject: RFR(S): 8191950: assertion failed: no insertions allowed In-Reply-To: References: <8c9e6244-fa55-903f-8b39-349aeff3815a@oracle.com> Message-ID: Hi Roland, On 01.12.2017 09:53, Roland Westrelin wrote: >> The "dead loop?" comment is a bit confusing here but I assume the call >> is part of a loop that became unreachable? > > Yes. > What about: check for unreachable loop? Yes, that sounds good to me. I can run some pre-integration testing and sponsor the change if you update the webrev. >> Was this introduced by a recent change (because the bug still has the integration_blocker label)? > > No, not as far I can tell. Okay, I'll remove the label. Thanks, Tobias From rwestrel at redhat.com Fri Dec 1 09:13:54 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 01 Dec 2017 10:13:54 +0100 Subject: RFR(S): 8191950: assertion failed: no insertions allowed In-Reply-To: References: <8c9e6244-fa55-903f-8b39-349aeff3815a@oracle.com> Message-ID: > Yes, that sounds good to me. I can run some pre-integration testing > and sponsor the change if you update the webrev. Thanks. Here is the updated webrev: http://cr.openjdk.java.net/~roland/8191950/webrev.01/ Roland. From rwestrel at redhat.com Fri Dec 1 10:22:46 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 01 Dec 2017 11:22:46 +0100 Subject: 8192762: LoopNode::verify_strip_mined() fails with "assert failed: only phis" Message-ID: http://cr.openjdk.java.net/~roland/8192762/webrev.00/ At the end of optimizations, the number of phis for the outer and inner loops of a strip mined loop nest should be the same. That's verified in Compile::final_graph_reshaping(). Compile::final_graph_reshaping() clones the TypeFunc::Parms argument of uncommon calls. If that argument is a Phi of the inner loop, then a new Phi is added and the verification logic breaks. I suppose the argument cloning is so setting the argument is sank in an uncommon path. In that case it doesn't make sense AFAIU to clone the Phi so I propose any Phi be skipped by that code. I didn't manage to write a test case. I could get a method with an uncommon call whose TypeFunc::Parms argument is a Phi but processing order of nodes by Compile::final_graph_reshaping() wouldn't trigger the bug (loop head processed first). Roland. From vladimir.x.ivanov at oracle.com Fri Dec 1 11:03:46 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 14:03:46 +0300 Subject: RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> Message-ID: Hold on, I observed a failure in the newly added test on linux-x64: ----------messages:(4/497)---------- command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server -XX:-TieredCompilation -XX:TypeProfileLevel=020 compiler.profiling.TestTypeProfiling reason: User specified action: run main/othervm -Xbootclasspath/a:. -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server -XX:-TieredCompilation -XX:TypeProfileLevel=020 compiler.profiling.TestTypeProfiling Mode: othervm [/othervm specified] elapsed time (seconds): 21.462 ----------configuration:(0/0)---------- ----------System.out:(0/0)---------- ----------System.err:(13/992)---------- java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should deoptimize for actual type check) at compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:564) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) at java.base/java.lang.Thread.run(Thread.java:844) Best regards, Vladimir Ivanov On 12/1/17 9:37 AM, Boris Ulasevich wrote: > Thank you! > > Boris Ulasevich > > 01.12.2017 09:23, Vladimir Kozlov ?????: >> Testing passed clean. You can push it - we don't use JPRT anymore for >> pushes. >> >> Thanks, >> Vladimir >> >> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>> I submitted pre-integration testing to make sure the test pass on all >>> our platforms. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>> Thanks for good points! >>>>> >>>>> Updated webrew (with asserts and renamed test moved to better >>>>> location): >>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>> >>>> Great, that's good to go. >>>> >>>> I think you have to get someone from Oracle to help because it >>>> includes a new test case. >>>> From dmitry.chuyko at bell-sw.com Fri Dec 1 11:38:45 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 1 Dec 2017 14:38:45 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> Message-ID: <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> There's at least one thing missing in the test, there should be -XX:+UnlockDiagnosticVMOptions in command lines. So the build in the run below was probably fastdebug. After adding that I see the test passing on my x86 and latest sources. Maybe it would make sense not to fail if some deopt doesn't occur. -Dmitry On 12/01/2017 02:03 PM, Vladimir Ivanov wrote: > Hold on, I observed a failure in the newly added test on linux-x64: > > ----------messages:(4/497)---------- > command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI > -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server > -XX:-TieredCompilation -XX:TypeProfileLevel=020 > compiler.profiling.TestTypeProfiling > reason: User specified action: run main/othervm -Xbootclasspath/a:. > -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement > -server -XX:-TieredCompilation -XX:TypeProfileLevel=020 > compiler.profiling.TestTypeProfiling > Mode: othervm [/othervm specified] > elapsed time (seconds): 21.462 > ----------configuration:(0/0)---------- > ----------System.out:(0/0)---------- > ----------System.err:(13/992)---------- > java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should > deoptimize for actual type check) > ????at > compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) > ????at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native > Method) > ????at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > ????at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > ????at java.base/java.lang.reflect.Method.invoke(Method.java:564) > ????at > com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) > ????at java.base/java.lang.Thread.run(Thread.java:844) > > Best regards, > Vladimir Ivanov > > On 12/1/17 9:37 AM, Boris Ulasevich wrote: >> Thank you! >> >> Boris Ulasevich >> >> 01.12.2017 09:23, Vladimir Kozlov ?????: >>> Testing passed clean. You can push it - we don't use JPRT anymore >>> for pushes. >>> >>> Thanks, >>> Vladimir >>> >>> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>>> I submitted pre-integration testing to make sure the test pass on >>>> all our platforms. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>>> Thanks for good points! >>>>>> >>>>>> Updated webrew (with asserts and renamed test moved to better >>>>>> location): >>>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>>>> >>>>> >>>>> Great, that's good to go. >>>>> >>>>> I think you have to get someone from Oracle to help because it >>>>> includes a new test case. >>>>> From doug.simon at oracle.com Fri Dec 1 11:43:26 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 1 Dec 2017 12:43:26 +0100 Subject: Fwd: Missing deopt for MIN_VALUE / -1 case causes crash from unhandled SIGFPE References: <7EF3FDBC-ABFD-4A20-B2AA-A0F308BABBE9@oracle.com> Message-ID: HotSpot devs, Is there some reason HotSpot doesn't (or shouldn't) handle a SIGFPE caused by Integer.MIN_VALUE/-1 explicitly? -Doug > Begin forwarded message: > > From: Doug Simon > Subject: Re: Missing deopt for MIN_VALUE / -1 case causes crash from unhandled SIGFPE > Date: 1 December 2017 at 12:09:55 CET > To: Jackson Davis > Cc: graal developers > > Hi Jackson, > > Awesome catch - thanks! > > The reason we don't check for -1 is probably due to the fact Graal came from Maxine VM which handles a SIGFPE caused by Integer.MIN_VALUE/-1 explicitly: > > https://github.com/dougxc/maxine/blob/master/com.oracle.max.vm.native/substrate/trap.c#L232 > > I'm not sure why HotSpot doesn't do this. > > In any case, we obviously need to handle this properly in Graal and will take your PR as the starting point. > > -Doug > >> On 1 Dec 2017, at 09:17, Jackson Davis wrote: >> >> I should add that this "fix" is based on the idea that letting the idiv >> throw the SIGFPE is, in fact, the desired / expected behavior here. C2 >> handles this case by adding guards. >> >> -Jackson >> >> On Fri, Dec 1, 2017 at 12:04 AM, Jackson Davis wrote: >> >>> One afternoon over Thanksgiving break I hacked together a very basic >>> fuzzer for JVM JITs (https://github.com/jcdavis/kabur/) which much to my >>> surprise actually managed to find an issue in Graal :) >>> This minimal test case reliably crashes the JVM from an unhandled SIGFPE: >>> >>> public class Crasher { >>> public static int crash(int n, int d) { >>> return n/(d|1); >>> } >>> public static void main(String[] args) { >>> for(int i = 0; i < 100000; i++) { >>> crash(i, i+1); >>> } >>> crash(Integer.MIN_VALUE, -1); >>> } >>> } >>> Ran with -XX:+UseJVMCICompiler -XX:-TieredCompilation >>> -XX:-BackgroundCompilation (Tested with local jdk9 and graal master) >>> >>> The source of this issue appears to be that IntegerDivRemNode.canDeoptimize >>> only checks whether or not the denominator can be 0, not whether it can >>> also be -1. Since d|1 is never 0, it doesn't generate the appropriate deopt >>> info, so when MIN_VALUE/-1 causes a SIGFPE, the signal handler doesn't know >>> what to do and dies. Adding the -1 check seems to make this to work as >>> intended (AFAICT). I have a PR for a basic fix here: >>> https://github.com/graalvm/graal/pull/266 >>> >>> Unfortunately this check breaks CountedLoopTest in a non-obvious way, >>> which is where I am out of my depth. It seems the test's CheckGraphPhase >>> introduces a SignedDivNode, however since this runs after >>> FrameStateAssignmentPhase, there is no frame data, so an assert fails in >>> the lowering. This seems to be fundamentally broken regardless of my >>> change, but only started failing here since the denominator has as stamp of >>> (-65536,-1) >>> >>> -Jackson >>> >>> >>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.x.ivanov at oracle.com Fri Dec 1 11:50:40 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 14:50:40 +0300 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771CEEBD@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> <725b89eb-74ac-bfb5-198b-f97d439f72e6@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771CEEBD@ORSMSX106.amr.corp.intel.com> Message-ID: <9a1c28cd-b99a-7245-325d-036d54359e7b@oracle.com> > Thanks for testing the patch. > To be on the safe side, I am preserving the rcx register and don't want to introduce any new bugs. Thinking more about this, I came to the conclusion that I don't fully understand what is the motivation to add the code in MA::restore_cpu_control_state_after_jni(). If there are other instructions left which are affected by the same encoding problem, resetting k1 after JNI call is not sufficient to hide the problem (e.g., any call into the JVM can potentially use k1). Moreover, C2 w/ PostLoopMultiversioning (turned off by default) produces post loops with k1 usage, but doesn't reset it. So, it seems it doesn't fix anything, but makes hitting similar bug less likely. Best regards, Vladimir Ivanov > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Thursday, November 30, 2017 1:29 PM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. > >> http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ > > Thanks, Vivek. I verified that the reported problem goes away with the fix. > > src/hotspot/cpu/x86/macroAssembler_x86.cpp > > + // Reset k1 to 0xffff. > + if (VM_Version::supports_evex()) { > + push(rcx); > + movl(rcx, 0xffff); > + kmovwl(k1, rcx); > + pop(rcx); > + } > > Why do you preserve rcx which is already caller-saved and shouldn't contain anything valuable after a JNI call? > > Best regards, > Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Fri Dec 1 12:37:16 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 15:37:16 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> Message-ID: > There's at least one thing missing in the test, there should be > -XX:+UnlockDiagnosticVMOptions in command lines. So the build in the run > below was probably fastdebug. Yes, it was fastdebug. > After adding that I see the test passing on my x86 and latest sources. > Maybe it would make sense not to fail if some deopt doesn't occur. The problem is related to -Xcomp. (I don't know why, but jtreg doesn't list -Xcomp in the log. It was passed passed as a CLI argument to jtreg.) Best regards, Vladimir Ivanov > On 12/01/2017 02:03 PM, Vladimir Ivanov wrote: >> Hold on, I observed a failure in the newly added test on linux-x64: >> >> ----------messages:(4/497)---------- >> command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI >> -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server >> -XX:-TieredCompilation -XX:TypeProfileLevel=020 >> compiler.profiling.TestTypeProfiling >> reason: User specified action: run main/othervm -Xbootclasspath/a:. >> -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement >> -server -XX:-TieredCompilation -XX:TypeProfileLevel=020 >> compiler.profiling.TestTypeProfiling >> Mode: othervm [/othervm specified] >> elapsed time (seconds): 21.462 >> ----------configuration:(0/0)---------- >> ----------System.out:(0/0)---------- >> ----------System.err:(13/992)---------- >> java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should >> deoptimize for actual type check) >> ????at >> compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) >> ????at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> ????at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> >> ????at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> >> ????at java.base/java.lang.reflect.Method.invoke(Method.java:564) >> ????at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >> >> ????at java.base/java.lang.Thread.run(Thread.java:844) >> >> Best regards, >> Vladimir Ivanov >> >> On 12/1/17 9:37 AM, Boris Ulasevich wrote: >>> Thank you! >>> >>> Boris Ulasevich >>> >>> 01.12.2017 09:23, Vladimir Kozlov ?????: >>>> Testing passed clean. You can push it - we don't use JPRT anymore >>>> for pushes. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>>>> I submitted pre-integration testing to make sure the test pass on >>>>> all our platforms. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>>>> Thanks for good points! >>>>>>> >>>>>>> Updated webrew (with asserts and renamed test moved to better >>>>>>> location): >>>>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>>>>> >>>>>> >>>>>> Great, that's good to go. >>>>>> >>>>>> I think you have to get someone from Oracle to help because it >>>>>> includes a new test case. >>>>>> > From boris.ulasevich at bell-sw.com Fri Dec 1 13:45:49 2017 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Fri, 1 Dec 2017 16:45:49 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> Message-ID: <517af166-2fdd-cdce-ee61-6e1f11d97482@bell-sw.com> Hi Vladimir, Many thanks to you for this finding! I have added vm.compMode=="Xmixed" check and -XX:-BackgroundCompilation option. Now it should work Ok. http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.03/ best regards, Boris 01.12.2017 15:37, Vladimir Ivanov ?????: >> There's at least one thing missing in the test, there should be >> -XX:+UnlockDiagnosticVMOptions in command lines. So the build in the >> run below was probably fastdebug. > > Yes, it was fastdebug. > >> After adding that I see the test passing on my x86 and latest sources. >> Maybe it would make sense not to fail if some deopt doesn't occur. > > The problem is related to -Xcomp. > > (I don't know why, but jtreg doesn't list -Xcomp in the log. It was > passed passed as a CLI argument to jtreg.) Yes, it was confusing > Best regards, > Vladimir Ivanov > >> On 12/01/2017 02:03 PM, Vladimir Ivanov wrote: >>> Hold on, I observed a failure in the newly added test on linux-x64: >>> >>> ----------messages:(4/497)---------- >>> command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI >>> -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server >>> -XX:-TieredCompilation -XX:TypeProfileLevel=020 >>> compiler.profiling.TestTypeProfiling >>> reason: User specified action: run main/othervm -Xbootclasspath/a:. >>> -XX:+WhiteBoxAPI -XX:-BackgroundCompilation >>> -XX:-UseOnStackReplacement -server -XX:-TieredCompilation >>> -XX:TypeProfileLevel=020 compiler.profiling.TestTypeProfiling >>> Mode: othervm [/othervm specified] >>> elapsed time (seconds): 21.462 >>> ----------configuration:(0/0)---------- >>> ----------System.out:(0/0)---------- >>> ----------System.err:(13/992)---------- >>> java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should >>> deoptimize for actual type check) >>> ????at >>> compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) >>> ????at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> >>> ????at >>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> >>> ????at >>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> >>> ????at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>> ????at >>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >>> >>> ????at java.base/java.lang.Thread.run(Thread.java:844) >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> On 12/1/17 9:37 AM, Boris Ulasevich wrote: >>>> Thank you! >>>> >>>> Boris Ulasevich >>>> >>>> 01.12.2017 09:23, Vladimir Kozlov ?????: >>>>> Testing passed clean. You can push it - we don't use JPRT anymore >>>>> for pushes. >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>>>>> I submitted pre-integration testing to make sure the test pass on >>>>>> all our platforms. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>>>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>>>>> Thanks for good points! >>>>>>>> >>>>>>>> Updated webrew (with asserts and renamed test moved to better >>>>>>>> location): >>>>>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>>>>>> >>>>>>> >>>>>>> Great, that's good to go. >>>>>>> >>>>>>> I think you have to get someone from Oracle to help because it >>>>>>> includes a new test case. >>>>>>> >> From vladimir.x.ivanov at oracle.com Fri Dec 1 14:44:53 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 17:44:53 +0300 Subject: RFR (S): 8191129 - AARCH64: Invalid value passed to critical JNI function In-Reply-To: <6902d304-e1bf-5473-3f39-80869de85280@bell-sw.com> References: <2cb34bc7-98da-12b4-11af-0d8886747691@oracle.com> <4130e57a-0369-915d-9c99-05e308b5d4e7@oracle.com> <6902d304-e1bf-5473-3f39-80869de85280@bell-sw.com> Message-ID: <2d8d0227-d44b-52b5-97b6-774d30f6c89d@oracle.com> On 11/30/17 9:22 PM, Dmitry Chuyko wrote: > http://cr.openjdk.java.net/~dchuyko/8191129/webrev.01/ Looks good. Test results are clean. Feel free to push it once you are ready. Best regards, Vladimir Ivanov > I think for tests it then will be better to explicitly exclude aarch64 > until complete feature implementation and to add the flag. > > Flag disabling was changed to UNSUPPORTED_OPTION() which also prints a > warning in case of manual -XX+. > > -Dmitry > > > On 11/29/2017 02:50 PM, Vladimir Ivanov wrote: >> >> >> On 11/29/17 2:16 PM, Vladimir Ivanov wrote: >>> ?? if (CriticalJNINatives) { >>> ???? warning("CriticalJNINatives aren't supported"); >>> ???? FLAG_SET_DEFAULT(CriticalJNINatives, false); >>> ?? } >> >> What I meant is: >> ? if (CriticalJNINatives && !FLAG_IS_DEFAULT(CriticalJNINatives)) { >> ??? warning("CriticalJNINatives aren't supported"); >> ? } >> ? FLAG_SET_DEFAULT(CriticalJNINatives, false); >> >> Sorry for the confusion. >> >> Best regards, >> Vladimir Ivanov > From vladimir.x.ivanov at oracle.com Fri Dec 1 14:46:05 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 17:46:05 +0300 Subject: [aarch64-port-dev ] RFR(S) 8189439: Parameters type profiling is not performed from aarch64 interpreter In-Reply-To: <517af166-2fdd-cdce-ee61-6e1f11d97482@bell-sw.com> References: <712921512033620@web42g.yandex.ru> <8a5956ad-e79b-8d2d-d904-a467f7b7801c@redhat.com> <3a8b5306-64ec-309c-4f73-99a16893c78a@bell-sw.com> <832c755d-7eba-36b3-2d17-ebeb4db9cb35@bell-sw.com> <8250be10-fa35-06e7-6ecc-9422490efb6d@redhat.com> <9c2282da-8efa-2854-3057-28700a239a58@oracle.com> <91fb31ea-82ed-a6dd-2fbf-b21957586e23@oracle.com> <672a1473-2f17-560a-c161-54d3b2427a11@bell-sw.com> <236eb2b2-968c-6c50-9b4f-4059c0c2e8a1@bell-sw.com> <517af166-2fdd-cdce-ee61-6e1f11d97482@bell-sw.com> Message-ID: <9b3b50f0-33f0-13fb-b3db-a356a40f3519@oracle.com> > http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.03/ Looks good. Best regards, Vladimir Ivanov > 01.12.2017 15:37, Vladimir Ivanov ?????: >>> There's at least one thing missing in the test, there should be >>> -XX:+UnlockDiagnosticVMOptions in command lines. So the build in the >>> run below was probably fastdebug. >> >> Yes, it was fastdebug. >> >>> After adding that I see the test passing on my x86 and latest >>> sources. Maybe it would make sense not to fail if some deopt doesn't >>> occur. >> >> The problem is related to -Xcomp. >> >> (I don't know why, but jtreg doesn't list -Xcomp in the log. It was >> passed passed as a CLI argument to jtreg.) > > Yes, it was confusing > >> Best regards, >> Vladimir Ivanov >> >>> On 12/01/2017 02:03 PM, Vladimir Ivanov wrote: >>>> Hold on, I observed a failure in the newly added test on linux-x64: >>>> >>>> ----------messages:(4/497)---------- >>>> command: main -Xbootclasspath/a:. -XX:+WhiteBoxAPI >>>> -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -server >>>> -XX:-TieredCompilation -XX:TypeProfileLevel=020 >>>> compiler.profiling.TestTypeProfiling >>>> reason: User specified action: run main/othervm -Xbootclasspath/a:. >>>> -XX:+WhiteBoxAPI -XX:-BackgroundCompilation >>>> -XX:-UseOnStackReplacement -server -XX:-TieredCompilation >>>> -XX:TypeProfileLevel=020 compiler.profiling.TestTypeProfiling >>>> Mode: othervm [/othervm specified] >>>> elapsed time (seconds): 21.462 >>>> ----------configuration:(0/0)---------- >>>> ----------System.out:(0/0)---------- >>>> ----------System.err:(13/992)---------- >>>> java.lang.RuntimeException: mRetTypeCheck is not deoptimized (should >>>> deoptimize for actual type check) >>>> ????at >>>> compiler.profiling.TestTypeProfiling.main(TestTypeProfiling.java:130) >>>> ????at >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> Method) >>>> ????at >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> >>>> ????at >>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> >>>> ????at java.base/java.lang.reflect.Method.invoke(Method.java:564) >>>> ????at >>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115) >>>> >>>> ????at java.base/java.lang.Thread.run(Thread.java:844) >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> On 12/1/17 9:37 AM, Boris Ulasevich wrote: >>>>> Thank you! >>>>> >>>>> Boris Ulasevich >>>>> >>>>> 01.12.2017 09:23, Vladimir Kozlov ?????: >>>>>> Testing passed clean. You can push it - we don't use JPRT anymore >>>>>> for pushes. >>>>>> >>>>>> Thanks, >>>>>> Vladimir >>>>>> >>>>>> On 11/30/17 6:24 PM, Vladimir Kozlov wrote: >>>>>>> I submitted pre-integration testing to make sure the test pass on >>>>>>> all our platforms. >>>>>>> >>>>>>> Thanks, >>>>>>> Vladimir >>>>>>> >>>>>>> On 11/30/17 8:31 AM, Andrew Haley wrote: >>>>>>>> On 30/11/17 16:28, Boris Ulasevich wrote: >>>>>>>>> Thanks for good points! >>>>>>>>> >>>>>>>>> Updated webrew (with asserts and renamed test moved to better >>>>>>>>> location): >>>>>>>>> http://cr.openjdk.java.net/~dchuyko/boris.ulasevich/8189439/webrev.02/ >>>>>>>>> >>>>>>>> >>>>>>>> Great, that's good to go. >>>>>>>> >>>>>>>> I think you have to get someone from Oracle to help because it >>>>>>>> includes a new test case. >>>>>>>> >>> From martin.doerr at sap.com Fri Dec 1 16:14:35 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 1 Dec 2017 16:14:35 +0000 Subject: RFR(XS): 8192818: [s390]: restoring register contents calculates wrong value In-Reply-To: <47FC36E4-EAE9-4742-9382-D8022E60ED49@sap.com> References: <74C2EC38-9DA2-4B89-AAA9-FE5927FF1CC9@sap.com> <47FC36E4-EAE9-4742-9382-D8022E60ED49@sap.com> Message-ID: Hi Lutz, thanks for the fix. Reviewed and pushed. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz Sent: Freitag, 1. Dezember 2017 09:31 To: Lindenmaier, Goetz ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(XS): 8192818: [s390]: restoring register contents calculates wrong value Thank you, Goetz! Could you please sponsor & push, once we have a second review? Regards, Lutz On 01.12.2017, 09:27, "Lindenmaier, Goetz" wrote: Hi Lutz, thanks for fixing this, looks good! Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Donnerstag, 30. November 2017 17:14 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(XS): 8192818: [s390]: restoring register contents calculates > wrong value > > Dear all, > > > > I would like to request reviews for this s390-only bux fix (one-liner): > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192818 > > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8192818.00/index.html > > > > > Thank you! > > Lutz > > From martin.doerr at sap.com Fri Dec 1 16:15:18 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 1 Dec 2017 16:15:18 +0000 Subject: RFR(S): 8192825: PPC64: Missing null check in C1 inline cache check In-Reply-To: References: <7b820cb2a7b345c7851aa9a74bdb1545@sap.com> Message-ID: <90750f18d1694a83b39646914ea4a8e8@sap.com> Hi G?tz, thanks for the review. Pushed. Best regards, Martin -----Original Message----- From: Lindenmaier, Goetz Sent: Freitag, 1. Dezember 2017 08:53 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: RFR(S): 8192825: PPC64: Missing null check in C1 inline cache check Hi Martin, thanks for fixing this, looks good. Best regards, Goetz. > -----Original Message----- > From: Doerr, Martin > Sent: Donnerstag, 30. November 2017 18:17 > To: 'hotspot-compiler-dev at openjdk.java.net' dev at openjdk.java.net>; Lindenmaier, Goetz > Subject: RFR(S): 8192825: PPC64: Missing null check in C1 inline cache check > > Hi, > > > > I found a problem on AIX which is cause by a missing null check. > > > > Compiled methods need to perform a null check in the unverified entry. This > is usually done implicitly by loading the Klass*. > > However, implicit null checks may be off on PPC64 (especially on AIX where > the 0 page is readable). > > > > Null checks are especially needed after: > > 8160543: C1: Crash in java.lang.String.indexOf in some java.sql tests > > Summary: C1 must use unverified entry point for unloaded methods. > > > > Webrev is here: > > http://cr.openjdk.java.net/~mdoerr/8192825_PPC64_C1_ic_nullcheck/webr > ev.00/ > > > > Please review. > > > > Best regards, > > Martin > > From vladimir.kozlov at oracle.com Fri Dec 1 18:35:10 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 1 Dec 2017 10:35:10 -0800 Subject: RFR(XS): x86: 8170244: Fix for Update UseAVX after cpu feature detection to use more default mapping In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771CF37E@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CF37E@ORSMSX106.amr.corp.intel.com> Message-ID: <5184d00f-eb1a-4d25-5e33-25edd4d745c0@oracle.com> Looks good. I will start testing. Thanks, Vladimir On 11/30/17 11:20 PM, Deshpande, Vivek R wrote: > Hi > > I have bug fix for 8170244: Update UseAVX after cpu feature detection to use more default mapping. > > Webrev: > > http://cr.openjdk.java.net/~vdeshpande/8170244/webrev.00/ > > I have also updated the JBS entry. > > https://bugs.openjdk.java.net/browse/JDK-8170244 > > Would you please review and sponsor it. > > Regards, > > Vivek > From tom.rodriguez at oracle.com Fri Dec 1 18:37:29 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 01 Dec 2017 10:37:29 -0800 Subject: RFR 8191052: [Graal] java/lang/invoke/CallSiteTest.java intermittently fails with "Failed dependency of type call_site_target_value" when running with Graal as JIT In-Reply-To: References: <5A1DDB06.30908@oracle.com> Message-ID: <5A21A169.4040906@oracle.com> Vladimir Kozlov wrote: > On 11/28/17 1:54 PM, Tom Rodriguez wrote: >> http://cr.openjdk.java.net/~never/8191052/webrev >> https://bugs.openjdk.java.net/browse/JDK-8191052 > > Looks good to me. > >> >> This consolidates the logic to validate dependencies before code >> installation. JVMCI was missing logic to treat call_site_target_value >> failures benignly and the code had also diverged over time. Tested >> with Graal and Truffle. mach5 testing is being submitted. > > Please, add mach5 job link to confidential comment in JBS. Done. The results are clean. Do I need more than 1 reviewer? And I just push instead of using jprt? tom > > Thanks, > Vladimir > >> >> >> tom From vladimir.kozlov at oracle.com Fri Dec 1 18:44:17 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 1 Dec 2017 10:44:17 -0800 Subject: RFR 8191052: [Graal] java/lang/invoke/CallSiteTest.java intermittently fails with "Failed dependency of type call_site_target_value" when running with Graal as JIT In-Reply-To: <5A21A169.4040906@oracle.com> References: <5A1DDB06.30908@oracle.com> <5A21A169.4040906@oracle.com> Message-ID: <7ebfae46-f8a5-b5a8-bb09-d2361e99afd5@oracle.com> On 12/1/17 10:37 AM, Tom Rodriguez wrote: > > > Vladimir Kozlov wrote: >> On 11/28/17 1:54 PM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/8191052/webrev >>> https://bugs.openjdk.java.net/browse/JDK-8191052 >> >> Looks good to me. >> >>> >>> This consolidates the logic to validate dependencies before code >>> installation.? JVMCI was missing logic to treat call_site_target_value >>> failures benignly and the code had also diverged over time. Tested >>> with Graal and Truffle.? mach5 testing is being submitted. >> >> Please, add mach5 job link to confidential comment in JBS. > > Done.? The results are clean.? Do I need more than 1 reviewer?? And I just push instead of using jprt? Yes, you need second review since changes are not simple. I will ask Dean or Igor to look. After that just push. No more JPRT. Thanks, Vladimir > > tom > >> >> Thanks, >> Vladimir >> >>> >>> >>> tom From vladimir.kozlov at oracle.com Fri Dec 1 18:56:40 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 1 Dec 2017 10:56:40 -0800 Subject: 8192762: LoopNode::verify_strip_mined() fails with "assert failed: only phis" In-Reply-To: References: Message-ID: <83c2fa6b-8f29-071a-f3f5-54b8e8d3c8e4@oracle.com> Agree. We should not clone Phi - it is not executable node (no benefots from clonning) and it will complicate graph. I will start testing. Thanks, Vladimir On 12/1/17 2:22 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8192762/webrev.00/ > > At the end of optimizations, the number of phis for the outer and inner > loops of a strip mined loop nest should be the same. That's verified in > Compile::final_graph_reshaping(). Compile::final_graph_reshaping() > clones the TypeFunc::Parms argument of uncommon calls. If that argument > is a Phi of the inner loop, then a new Phi is added and the verification > logic breaks. I suppose the argument cloning is so setting the argument > is sank in an uncommon path. In that case it doesn't make sense AFAIU to > clone the Phi so I propose any Phi be skipped by that code. > > I didn't manage to write a test case. I could get a method with an > uncommon call whose TypeFunc::Parms argument is a Phi but processing > order of nodes by Compile::final_graph_reshaping() wouldn't trigger the > bug (loop head processed first). > > Roland. > From vivek.r.deshpande at intel.com Fri Dec 1 19:02:19 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 1 Dec 2017 19:02:19 +0000 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <9a1c28cd-b99a-7245-325d-036d54359e7b@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> <725b89eb-74ac-bfb5-198b-f97d439f72e6@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771CEEBD@ORSMSX106.amr.corp.intel.com> <9a1c28cd-b99a-7245-325d-036d54359e7b@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771CFA98@ORSMSX106.amr.corp.intel.com> Hi Vladimir Our understanding is that the fix is correct, works in all circumstances with the JVM/JIT code as checked in, and is the least disruptive fix.?? Only the JNI has potential to kill K1. No other call into the JVM can modify K1 as the JVM is compiled for SSE2 being the base for 64 bit. The stubs/intrinsics that use mask register all make sure that K1 is restored properly. PostLoopMultiversioning has major issues and is turned off per?https://bugs.openjdk.java.net/browse/JDK-8183390.? Regards, Vivek -----Original Message----- From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] Sent: Friday, December 01, 2017 3:51 AM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. > Thanks for testing the patch. > To be on the safe side, I am preserving the rcx register and don't want to introduce any new bugs. Thinking more about this, I came to the conclusion that I don't fully understand what is the motivation to add the code in MA::restore_cpu_control_state_after_jni(). If there are other instructions left which are affected by the same encoding problem, resetting k1 after JNI call is not sufficient to hide the problem (e.g., any call into the JVM can potentially use k1). Moreover, C2 w/ PostLoopMultiversioning (turned off by default) produces post loops with k1 usage, but doesn't reset it. So, it seems it doesn't fix anything, but makes hitting similar bug less likely. Best regards, Vladimir Ivanov > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Thursday, November 30, 2017 1:29 PM > To: Deshpande, Vivek R ; > hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. > >> http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ > > Thanks, Vivek. I verified that the reported problem goes away with the fix. > > src/hotspot/cpu/x86/macroAssembler_x86.cpp > > + // Reset k1 to 0xffff. > + if (VM_Version::supports_evex()) { > + push(rcx); > + movl(rcx, 0xffff); > + kmovwl(k1, rcx); > + pop(rcx); > + } > > Why do you preserve rcx which is already caller-saved and shouldn't contain anything valuable after a JNI call? > > Best regards, > Vladimir Ivanov > From dean.long at oracle.com Fri Dec 1 19:16:23 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 1 Dec 2017 11:16:23 -0800 Subject: RFR(XL) 8192814: Update Graal In-Reply-To: <9bd2a475-e50b-8aa9-37c0-e8bd99d6043e@oracle.com> References: <9bd2a475-e50b-8aa9-37c0-e8bd99d6043e@oracle.com> Message-ID: <2fc40a88-709b-4f12-8524-8745071dfd0c@oracle.com> Thanks Vladimir. dl On 11/30/17 10:14 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 11/30/17 9:28 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8192814 >> http://cr.openjdk.java.net/~dlong/8192814/webrev/ >> >> Fixes JDK-8186198 and JDK-8182882.? See the bug for the full list of >> Graal changes. >> >> dl From vladimir.x.ivanov at oracle.com Fri Dec 1 19:47:38 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 1 Dec 2017 22:47:38 +0300 Subject: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771CFA98@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771CE8C3@ORSMSX106.amr.corp.intel.com> <725b89eb-74ac-bfb5-198b-f97d439f72e6@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771CEEBD@ORSMSX106.amr.corp.intel.com> <9a1c28cd-b99a-7245-325d-036d54359e7b@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771CFA98@ORSMSX106.amr.corp.intel.com> Message-ID: <29F15185-6C51-4769-BDE7-4CE8E8F958FD@oracle.com> Thanks for the clarifications, Vivek! The fix looks good as it is. I missed that PostLoopMultiversioning is broken. I?m still concerned JVM doesn?t fully comply with system ABI and system libraries JVM relies on (which are out of our control, e.g., libc) can internally utilize AVX-512 thus breaking the JVM. But I consider that more of a theoretical possibility at the moment and I?m fine with addressing that later. Best regards, Vladimir Ivanov > On 1 Dec 2017, at 22:02, Deshpande, Vivek R wrote: > > Hi Vladimir > > Our understanding is that the fix is correct, works in all circumstances with the JVM/JIT code as checked in, and is the least disruptive fix. > Only the JNI has potential to kill K1. No other call into the JVM can modify K1 as the JVM is compiled for SSE2 being the base for 64 bit. > The stubs/intrinsics that use mask register all make sure that K1 is restored properly. > PostLoopMultiversioning has major issues and is turned off per https://bugs.openjdk.java.net/browse/JDK-8183390. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] > Sent: Friday, December 01, 2017 3:51 AM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. > >> Thanks for testing the patch. >> To be on the safe side, I am preserving the rcx register and don't want to introduce any new bugs. > > Thinking more about this, I came to the conclusion that I don't fully understand what is the motivation to add the code in MA::restore_cpu_control_state_after_jni(). > > If there are other instructions left which are affected by the same encoding problem, resetting k1 after JNI call is not sufficient to hide the problem (e.g., any call into the JVM can potentially use k1). > > Moreover, C2 w/ PostLoopMultiversioning (turned off by default) produces post loops with k1 usage, but doesn't reset it. > > So, it seems it doesn't fix anything, but makes hitting similar bug less likely. > > Best regards, > Vladimir Ivanov > >> -----Original Message----- >> From: Vladimir Ivanov [mailto:vladimir.x.ivanov at oracle.com] >> Sent: Thursday, November 30, 2017 1:29 PM >> To: Deshpande, Vivek R ; >> hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S): x86: 8190494: fix for different results with UseAVX=3 when calling AVX-512 native function via JNI. >> >>> http://cr.openjdk.java.net/~vdeshpande/8190494/webrev.00/ >> >> Thanks, Vivek. I verified that the reported problem goes away with the fix. >> >> src/hotspot/cpu/x86/macroAssembler_x86.cpp >> >> + // Reset k1 to 0xffff. >> + if (VM_Version::supports_evex()) { >> + push(rcx); >> + movl(rcx, 0xffff); >> + kmovwl(k1, rcx); >> + pop(rcx); >> + } >> >> Why do you preserve rcx which is already caller-saved and shouldn't contain anything valuable after a JNI call? >> >> Best regards, >> Vladimir Ivanov >> From igor.veresov at oracle.com Fri Dec 1 19:49:55 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 1 Dec 2017 11:49:55 -0800 Subject: RFR 8191052: [Graal] java/lang/invoke/CallSiteTest.java intermittently fails with "Failed dependency of type call_site_target_value" when running with Graal as JIT In-Reply-To: <5A21A169.4040906@oracle.com> References: <5A1DDB06.30908@oracle.com> <5A21A169.4040906@oracle.com> Message-ID: <22805F2A-035A-4835-A185-21FB3991EED8@oracle.com> It looks good to me. igor > On Dec 1, 2017, at 10:37 AM, Tom Rodriguez wrote: > > > > Vladimir Kozlov wrote: >> On 11/28/17 1:54 PM, Tom Rodriguez wrote: >>> http://cr.openjdk.java.net/~never/8191052/webrev >>> https://bugs.openjdk.java.net/browse/JDK-8191052 >> >> Looks good to me. >> >>> >>> This consolidates the logic to validate dependencies before code >>> installation. JVMCI was missing logic to treat call_site_target_value >>> failures benignly and the code had also diverged over time. Tested >>> with Graal and Truffle. mach5 testing is being submitted. >> >> Please, add mach5 job link to confidential comment in JBS. > > Done. The results are clean. Do I need more than 1 reviewer? And I just push instead of using jprt? > > tom > >> >> Thanks, >> Vladimir >> >>> >>> >>> tom From dean.long at oracle.com Fri Dec 1 19:53:11 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 1 Dec 2017 11:53:11 -0800 Subject: RFR 8191052: [Graal] java/lang/invoke/CallSiteTest.java intermittently fails with "Failed dependency of type call_site_target_value" when running with Graal as JIT In-Reply-To: <22805F2A-035A-4835-A185-21FB3991EED8@oracle.com> References: <5A1DDB06.30908@oracle.com> <5A21A169.4040906@oracle.com> <22805F2A-035A-4835-A185-21FB3991EED8@oracle.com> Message-ID: <2c087c05-17a7-6444-2beb-7bd830a880dc@oracle.com> +1 dl On 12/1/17 11:49 AM, Igor Veresov wrote: > It looks good to me. > > igor > >> On Dec 1, 2017, at 10:37 AM, Tom Rodriguez wrote: >> >> >> >> Vladimir Kozlov wrote: >>> On 11/28/17 1:54 PM, Tom Rodriguez wrote: >>>> http://cr.openjdk.java.net/~never/8191052/webrev >>>> https://bugs.openjdk.java.net/browse/JDK-8191052 >>> Looks good to me. >>> >>>> This consolidates the logic to validate dependencies before code >>>> installation. JVMCI was missing logic to treat call_site_target_value >>>> failures benignly and the code had also diverged over time. Tested >>>> with Graal and Truffle. mach5 testing is being submitted. >>> Please, add mach5 job link to confidential comment in JBS. >> Done. The results are clean. Do I need more than 1 reviewer? And I just push instead of using jprt? >> >> tom >> >>> Thanks, >>> Vladimir >>> >>>> >>>> tom From igor.ignatyev at oracle.com Fri Dec 1 20:10:47 2017 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Fri, 1 Dec 2017 12:10:47 -0800 Subject: RFR(XS) : 8191273 : applications/ctw/modules tests fail intermittently Message-ID: http://cr.openjdk.java.net/~iignatyev//8191273/webrev.00 > 6 lines changed: 1 ins; 0 del; 5 mod; Hi all, could you please review this small fix for CTW tests? the tests fail if the line w/ last class id is mixed w/ another line in output. this happens b/c cerr of CTW process is redirected to cout, the fix redirects cerr into a separate file. webrev: http://cr.openjdk.java.net/~iignatyev//8191273/webrev.00 jbs: https://bugs.openjdk.java.net/browse/JDK-8191273 testing: applications/ctw/modules tests Thanks, -- Igor From dean.long at oracle.com Fri Dec 1 20:15:38 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 1 Dec 2017 12:15:38 -0800 Subject: RFR(XS) : 8191273 : applications/ctw/modules tests fail intermittently In-Reply-To: References: Message-ID: Looks reasonable. dl On 12/1/17 12:10 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8191273/webrev.00 >> 6 lines changed: 1 ins; 0 del; 5 mod; > Hi all, > > could you please review this small fix for CTW tests? the tests fail if the line w/ last class id is mixed w/ another line in output. this happens b/c cerr of CTW process is redirected to cout, the fix redirects cerr into a separate file. > > webrev: http://cr.openjdk.java.net/~iignatyev//8191273/webrev.00 > jbs: https://bugs.openjdk.java.net/browse/JDK-8191273 > testing: applications/ctw/modules tests > > Thanks, > -- Igor From vladimir.kozlov at oracle.com Fri Dec 1 21:35:30 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 1 Dec 2017 13:35:30 -0800 Subject: RFR(XS) : 8191273 : applications/ctw/modules tests fail intermittently In-Reply-To: References: Message-ID: <3b9f8cfe-d94d-c4e1-d627-db0d51ea3839@oracle.com> Good. Thanks, Vladimir On 12/1/17 12:10 PM, Igor Ignatyev wrote: > http://cr.openjdk.java.net/~iignatyev//8191273/webrev.00 >> 6 lines changed: 1 ins; 0 del; 5 mod; > > Hi all, > > could you please review this small fix for CTW tests? the tests fail if the line w/ last class id is mixed w/ another line in output. this happens b/c cerr of CTW process is redirected to cout, the fix redirects cerr into a separate file. > > webrev: http://cr.openjdk.java.net/~iignatyev//8191273/webrev.00 > jbs: https://bugs.openjdk.java.net/browse/JDK-8191273 > testing: applications/ctw/modules tests > > Thanks, > -- Igor > From tobias.hartmann at oracle.com Mon Dec 4 08:58:40 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 4 Dec 2017 09:58:40 +0100 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> <1acbacd7-7967-8da3-2f67-f3babb40f909@redhat.com> Message-ID: Hi Ningsheng, I'll take care of pushing the fix directly into jdk/jdk to make sure it goes into JDK 10 (see Jesper's rules [1]). Best regards, Tobias [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029476.html On 01.12.2017 02:56, Ningsheng Jian wrote: > Hi, > > Can anyone please help to push this small change reviewed by aph? > Felix is not available these days, and may not help to commit the > patch. > > http://cr.openjdk.java.net/~njian/8191955/webrev.01/ > > Thanks, > Ningsheng > > On 30 November 2017 at 09:39, Ningsheng Jian wrote: >> Thank you Andrew! >> >> Regards, >> Ningsheng >> >> On 29 November 2017 at 18:17, Andrew Haley wrote: >>> On 29/11/17 02:43, Ningsheng Jian wrote: >>>> Thanks for the review! Because of the constraint func, with and >>>> without the patch it will report an error for -1 input. But since the >>>> constraint func is called after get_processor_features, I've updated >>>> the patch to leave -1 to be handled by the constraint func. >>>> >>>> http://cr.openjdk.java.net/~njian/8191955/webrev.01/ >>> >>> OK. >>> >>> -- >>> Andrew Haley >>> Java Platform Lead Engineer >>> Red Hat UK Ltd. >>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ningsheng.jian at linaro.org Mon Dec 4 09:08:42 2017 From: ningsheng.jian at linaro.org (Ningsheng Jian) Date: Mon, 4 Dec 2017 17:08:42 +0800 Subject: [aarch64-port-dev ] RFR: 8191955: AArch64: incorrect prefetch distance causes an internal error In-Reply-To: References: <7c38b750-a098-d4e9-dc38-620aa8940ee5@redhat.com> <1acbacd7-7967-8da3-2f67-f3babb40f909@redhat.com> Message-ID: Thank you, Tobias! Regards, Ningsheng On 4 December 2017 at 16:58, Tobias Hartmann wrote: > Hi Ningsheng, > > I'll take care of pushing the fix directly into jdk/jdk to make sure it goes into JDK 10 (see Jesper's rules [1]). > > Best regards, > Tobias > > [1] http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029476.html > > On 01.12.2017 02:56, Ningsheng Jian wrote: >> Hi, >> >> Can anyone please help to push this small change reviewed by aph? >> Felix is not available these days, and may not help to commit the >> patch. >> >> http://cr.openjdk.java.net/~njian/8191955/webrev.01/ >> >> Thanks, >> Ningsheng >> >> On 30 November 2017 at 09:39, Ningsheng Jian wrote: >>> Thank you Andrew! >>> >>> Regards, >>> Ningsheng >>> >>> On 29 November 2017 at 18:17, Andrew Haley wrote: >>>> On 29/11/17 02:43, Ningsheng Jian wrote: >>>>> Thanks for the review! Because of the constraint func, with and >>>>> without the patch it will report an error for -1 input. But since the >>>>> constraint func is called after get_processor_features, I've updated >>>>> the patch to leave -1 to be handled by the constraint func. >>>>> >>>>> http://cr.openjdk.java.net/~njian/8191955/webrev.01/ >>>> >>>> OK. >>>> >>>> -- >>>> Andrew Haley >>>> Java Platform Lead Engineer >>>> Red Hat UK Ltd. >>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nils.eliasson at oracle.com Mon Dec 4 12:46:13 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 4 Dec 2017 13:46:13 +0100 Subject: RFR(S): 8192971: [Testbug] LockCompilationTest fails intermittently Message-ID: Hi, This patches makes a intermittently failing test robust. With certain combinations of flags and machines this test sometimes doesn't compile everything in the compile queue in time. A slow/contented Sparc machine with -XX:-TieredCompilation in combination with -XX:CompileThreshold=100 fills up the compilation queue with about 500 compilation requests before the compiler directives are added. I am fixing this by adding the compileonly command to the commandline and remove the directive. bug: https://bugs.openjdk.java.net/browse/JDK-8192971 webrev: http://cr.openjdk.java.net/~neliasso/8192971/webrev.01/ Please review, Nils Eliasson From tobias.hartmann at oracle.com Mon Dec 4 12:56:46 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 4 Dec 2017 13:56:46 +0100 Subject: RFR(S): 8192971: [Testbug] LockCompilationTest fails intermittently In-Reply-To: References: Message-ID: <2b9d0f20-831e-e8f8-ab6c-5102395ffaa4@oracle.com> Hi Nils, looks good to me. Best regards, Tobias On 04.12.2017 13:46, Nils Eliasson wrote: > Hi, > > This patches makes a intermittently failing test robust. > > With certain combinations of flags and machines this test sometimes doesn't compile everything in the compile queue in > time. A slow/contented Sparc machine with -XX:-TieredCompilation in combination with -XX:CompileThreshold=100 fills up > the compilation queue with about 500 compilation requests before the compiler directives are added. > > I am fixing this by adding the compileonly command to the commandline and remove the directive. > > bug: https://bugs.openjdk.java.net/browse/JDK-8192971 > > webrev: http://cr.openjdk.java.net/~neliasso/8192971/webrev.01/ > > Please review, > > Nils Eliasson > From patric.hedlin at oracle.com Mon Dec 4 14:07:33 2017 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Mon, 4 Dec 2017 15:07:33 +0100 Subject: RFR(S): 8191232: compiler/intrinsics/bigInteger/TestMultiplyToLen.java fails with java.lang.Exception: Failed Message-ID: <63a5ab46-9faa-cee1-b2a8-c7710e9a60a6@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-8191232 Webrev: http://cr.openjdk.java.net/~phedlin/tr8191232/ 8191232: compiler/intrinsics/bigInteger/TestMultiplyToLen.java fails with java.lang.Exception: Failed Generating the wrong insn for pointer comparison in intrinsic (on SPARC). Testing: Testing on jdk/hs using jtreg/mach5/hotspot/precheckin-comp. Dedicated test of compiler/intrinsics/bigInteger/TestMultiplyToLen.java on slc09qkr.us.oracle.com Best regards, Patric From nils.eliasson at oracle.com Mon Dec 4 14:14:08 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Mon, 4 Dec 2017 15:14:08 +0100 Subject: RFR(S): 8191232: compiler/intrinsics/bigInteger/TestMultiplyToLen.java fails with java.lang.Exception: Failed In-Reply-To: <63a5ab46-9faa-cee1-b2a8-c7710e9a60a6@oracle.com> References: <63a5ab46-9faa-cee1-b2a8-c7710e9a60a6@oracle.com> Message-ID: Hi Patric, Looks good! Reviewed. // Nils On 2017-12-04 15:07, 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-8191232 > > Webrev: http://cr.openjdk.java.net/~phedlin/tr8191232/ > > > 8191232: compiler/intrinsics/bigInteger/TestMultiplyToLen.java fails > with java.lang.Exception: Failed > > Generating the wrong insn for pointer comparison in intrinsic (on > SPARC). > > Testing: > > Testing on jdk/hs using jtreg/mach5/hotspot/precheckin-comp. > Dedicated test of > compiler/intrinsics/bigInteger/TestMultiplyToLen.java on > slc09qkr.us.oracle.com > > > Best regards, > Patric > From vladimir.kozlov at oracle.com Mon Dec 4 16:23:08 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 4 Dec 2017 08:23:08 -0800 Subject: RFR(S): 8192971: [Testbug] LockCompilationTest fails intermittently In-Reply-To: <2b9d0f20-831e-e8f8-ab6c-5102395ffaa4@oracle.com> References: <2b9d0f20-831e-e8f8-ab6c-5102395ffaa4@oracle.com> Message-ID: <340da46a-137c-78f4-4ffa-c625033b5579@oracle.com> +1 Thanks, Vladimir On 12/4/17 4:56 AM, Tobias Hartmann wrote: > Hi Nils, > > looks good to me. > > Best regards, > Tobias > > On 04.12.2017 13:46, Nils Eliasson wrote: >> Hi, >> >> This patches makes a intermittently failing test robust. >> >> With certain combinations of flags and machines this test sometimes doesn't compile everything in the compile queue in >> time. A slow/contented Sparc machine with -XX:-TieredCompilation in combination with -XX:CompileThreshold=100 fills up >> the compilation queue with about 500 compilation requests before the compiler directives are added. >> >> I am fixing this by adding the compileonly command to the commandline and remove the directive. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8192971 >> >> webrev: http://cr.openjdk.java.net/~neliasso/8192971/webrev.01/ >> >> Please review, >> >> Nils Eliasson >> From vladimir.kozlov at oracle.com Mon Dec 4 16:30:10 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 4 Dec 2017 08:30:10 -0800 Subject: RFR(S): 8191232: compiler/intrinsics/bigInteger/TestMultiplyToLen.java fails with java.lang.Exception: Failed In-Reply-To: References: <63a5ab46-9faa-cee1-b2a8-c7710e9a60a6@oracle.com> Message-ID: <8790f608-5417-2918-5f95-160b6acc5a4e@oracle.com> +1 I think you should push it now to be included into jdk 10. Thanks, Vladimir On 12/4/17 6:14 AM, Nils Eliasson wrote: > Hi Patric, > > Looks good! > > Reviewed. > > // Nils > > > On 2017-12-04 15:07, 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-8191232 >> >> Webrev:? http://cr.openjdk.java.net/~phedlin/tr8191232/ >> >> >> 8191232: compiler/intrinsics/bigInteger/TestMultiplyToLen.java fails >> with java.lang.Exception: Failed >> >> ??? Generating the wrong insn for pointer comparison in intrinsic (on >> SPARC). >> >> Testing: >> >> ??? Testing on jdk/hs using jtreg/mach5/hotspot/precheckin-comp. >> ??? Dedicated test of >> compiler/intrinsics/bigInteger/TestMultiplyToLen.java on >> slc09qkr.us.oracle.com >> >> >> Best regards, >> Patric >> > From rwestrel at redhat.com Mon Dec 4 16:59:54 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 04 Dec 2017 17:59:54 +0100 Subject: 8192762: LoopNode::verify_strip_mined() fails with "assert failed: only phis" In-Reply-To: <83c2fa6b-8f29-071a-f3f5-54b8e8d3c8e4@oracle.com> References: <83c2fa6b-8f29-071a-f3f5-54b8e8d3c8e4@oracle.com> Message-ID: Thanks for the review and for sponsoring. Roland. From dean.long at oracle.com Mon Dec 4 17:44:54 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 4 Dec 2017 09:44:54 -0800 Subject: RFR(XS) 8145579: SimpleThresholdPolicy assumes non-trivial methods to be trivial Message-ID: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8145579 http://cr.openjdk.java.net/~dlong/8145579/webrev/ This change fixes certain non-trivial methods being marked as trivial.? A method should only be marked as trivial if C2 cannot generate better code.? The two cases fixed here are calling intrinsics, and Object., which has a hidden call to register finalizers.? When run with http://cr.openjdk.java.net/~shade/8145579/benchmarks.jar , the test methods now end up compiled at level 4 instead of level 1. dl -------------- next part -------------- An HTML attachment was scrubbed... URL: From razvan.a.lupusoru at intel.com Mon Dec 4 19:19:48 2017 From: razvan.a.lupusoru at intel.com (Lupusoru, Razvan A) Date: Mon, 4 Dec 2017 19:19:48 +0000 Subject: RFR(S) 8192846: Extend cmov vectorization to work for float In-Reply-To: <86784639-2e3c-d5da-3369-8a71bdd74632@oracle.com> References: <48D92A70936F7946BE99F3FF5ECB6461D8DE1631@ORSMSX113.amr.corp.intel.com> <86784639-2e3c-d5da-3369-8a71bdd74632@oracle.com> Message-ID: <48D92A70936F7946BE99F3FF5ECB6461D8DE1E7D@ORSMSX113.amr.corp.intel.com> Hi Vladimir, I removed the "do_vector_loop" check in order to enable the optimization by default - but it seems that was undesirable from your point of view. Thus, we have added a new flag "UseVectorCmov" which is disabled by default but anyone interested in feature can enable it manually. Ideally we can get it in this form into this upcoming release and remove the guard for following release once we check the stability of it more. The path for the updated webrev: http://cr.openjdk.java.net/~vdeshpande/8192846/webrev.01/ Code contributed by Razvan Lupusoru (rlupusoru) Thanks, Razvan -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, November 30, 2017 3:46 PM To: Lupusoru, Razvan A ; hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(S) 8192846: Extend cmov vectorization to work for float Thank you, Razvan I have one question: why you removed _do_vector_loop checks in superword.cpp? Also I think it is late for jdk 10. I will test and push when jdk 10 is forked. Thanks, Vladimir On 11/30/17 1:48 PM, Lupusoru, Razvan A wrote: > Hi all, > > This submission is to the issue noted in JDK-8192846 ?- namely that > vectorized cmov for floats is not supported. > > This patch rectifies the situation so that when scalar Cmov for float > and double is generated (or forced generated by passing > -XX:+UseCMoveUnconditionally), it stands a chance for Vectorization > using existing functionality previously enabled for doubles. The following code pattern will get vectorized with patch above: > > private void cmove_kernel_float(float[] in1, float[] in2, int length, > float[] out) { > > ? for (int i = 0; i < length; i++) { > > ??? out[i] = (in1[i] > in2[i]) ? in1[i] : in2[i]; > > ? } > > } > > Instructions generated for loop are: > > ? vmovdqu 0x10(%rcx,%r10,4),%ymm0 > > ? vmovdqu 0x10(%rdx,%r10,4),%ymm1 > > ? vcmpleps %ymm0,%ymm1,%ymm2 > > ? vblendvps %ymm2,%ymm0,%ymm1,%ymm2 > > ? vmovdqu %ymm2,0x10(%r9,%r10,4) > > The patch is available for review here: > > http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_cmovevf_00/ > > Jtreg testing with compiler tests has successfully passed. Thanks for review! > > --Razvan > From shade at redhat.com Mon Dec 4 20:10:26 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 4 Dec 2017 21:10:26 +0100 Subject: RFR(XS) 8145579: SimpleThresholdPolicy assumes non-trivial methods to be trivial In-Reply-To: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> References: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> Message-ID: <25ab4b1a-0d16-d4ff-b9d3-45de77cc184c@redhat.com> On 12/04/2017 06:44 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8145579 > http://cr.openjdk.java.net/~dlong/8145579/webrev/ > > This change fixes certain non-trivial methods being marked as trivial.? A method should only be > marked as trivial if C2 cannot generate better code.? The two cases fixed here are calling > intrinsics, and Object., which has a hidden call to register finalizers.? I am good with the fix, but my issue is with the essence of that shortcut. We can keep piling on exceptions on top of exceptions to that triviality rule, or we can just dispense with the idea that we can guess what methods are trivial and/or remember to fix it up every time something changes. Is it really worth falling back to C1 for trivial methods? I.e. is C2 compilation for those methods too costly (which would seem counter-intuitive)? Can we remove that triviality check, and see if we run fine without it? Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dean.long at oracle.com Mon Dec 4 21:07:08 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 4 Dec 2017 13:07:08 -0800 Subject: RFR(XS) 8145579: SimpleThresholdPolicy assumes non-trivial methods to be trivial In-Reply-To: <25ab4b1a-0d16-d4ff-b9d3-45de77cc184c@redhat.com> References: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> <25ab4b1a-0d16-d4ff-b9d3-45de77cc184c@redhat.com> Message-ID: <6a6a512f-bcc3-c474-d3e0-4bf96705c953@oracle.com> Hi Aleksey.? Thanks for the review, On 12/4/17 12:10 PM, Aleksey Shipilev wrote: > On 12/04/2017 06:44 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8145579 >> http://cr.openjdk.java.net/~dlong/8145579/webrev/ >> >> This change fixes certain non-trivial methods being marked as trivial.? A method should only be >> marked as trivial if C2 cannot generate better code.? The two cases fixed here are calling >> intrinsics, and Object., which has a hidden call to register finalizers. > I am good with the fix, but my issue is with the essence of that shortcut. We can keep piling on > exceptions on top of exceptions to that triviality rule, or we can just dispense with the idea that > we can guess what methods are trivial and/or remember to fix it up every time something changes. > > Is it really worth falling back to C1 for trivial methods? I.e. is C2 compilation for those methods > too costly (which would seem counter-intuitive)? Can we remove that triviality check, and see if we > run fine without it? I agree, we should take another look at that code.? We have reopened 8076988 to look into that for 11. dl > Thanks, > -Aleksey > > From vladimir.kozlov at oracle.com Mon Dec 4 22:11:57 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 4 Dec 2017 14:11:57 -0800 Subject: RFR(XS) 8145579: SimpleThresholdPolicy assumes non-trivial methods to be trivial In-Reply-To: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> References: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> Message-ID: Good. Thanks, Vladimir On 12/4/17 9:44 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8145579 > http://cr.openjdk.java.net/~dlong/8145579/webrev/ > > This change fixes certain non-trivial methods being marked as trivial. > A method should only be marked as trivial if C2 cannot generate better > code.? The two cases fixed here are calling intrinsics, and > Object., which has a hidden call to register finalizers.? When run > with http://cr.openjdk.java.net/~shade/8145579/benchmarks.jar > , the test > methods now end up compiled at level 4 instead of level 1. > > dl From vladimir.kozlov at oracle.com Mon Dec 4 22:26:37 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 4 Dec 2017 14:26:37 -0800 Subject: RFR(S) 8192846: Extend cmov vectorization to work for float In-Reply-To: <48D92A70936F7946BE99F3FF5ECB6461D8DE1E7D@ORSMSX113.amr.corp.intel.com> References: <48D92A70936F7946BE99F3FF5ECB6461D8DE1631@ORSMSX113.amr.corp.intel.com> <86784639-2e3c-d5da-3369-8a71bdd74632@oracle.com> <48D92A70936F7946BE99F3FF5ECB6461D8DE1E7D@ORSMSX113.amr.corp.intel.com> Message-ID: On 12/4/17 11:19 AM, Lupusoru, Razvan A wrote: > Hi Vladimir, > > I removed the "do_vector_loop" check in order to enable the optimization by default - but it seems that was undesirable from your point of view. It is not desirable for JDK 10 since it is too late. > > Thus, we have added a new flag "UseVectorCmov" which is disabled by default but anyone interested in feature can enable it manually. Ideally we can get it in this form into this upcoming release and remove the guard for following release once we check the stability of it more. Sounds good. Agree. > > The path for the updated webrev: > http://cr.openjdk.java.net/~vdeshpande/8192846/webrev.01/ > Code contributed by Razvan Lupusoru (rlupusoru) I will test it. Thanks, Vladimir > > Thanks, > Razvan > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, November 30, 2017 3:46 PM > To: Lupusoru, Razvan A ; hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S) 8192846: Extend cmov vectorization to work for float > > Thank you, Razvan > > I have one question: why you removed _do_vector_loop checks in superword.cpp? > > Also I think it is late for jdk 10. I will test and push when jdk 10 is forked. > > Thanks, > Vladimir > > On 11/30/17 1:48 PM, Lupusoru, Razvan A wrote: >> Hi all, >> >> This submission is to the issue noted in JDK-8192846 ?- namely that >> vectorized cmov for floats is not supported. >> >> This patch rectifies the situation so that when scalar Cmov for float >> and double is generated (or forced generated by passing >> -XX:+UseCMoveUnconditionally), it stands a chance for Vectorization >> using existing functionality previously enabled for doubles. The following code pattern will get vectorized with patch above: >> >> private void cmove_kernel_float(float[] in1, float[] in2, int length, >> float[] out) { >> >> ? for (int i = 0; i < length; i++) { >> >> ??? out[i] = (in1[i] > in2[i]) ? in1[i] : in2[i]; >> >> ? } >> >> } >> >> Instructions generated for loop are: >> >> ? vmovdqu 0x10(%rcx,%r10,4),%ymm0 >> >> ? vmovdqu 0x10(%rdx,%r10,4),%ymm1 >> >> ? vcmpleps %ymm0,%ymm1,%ymm2 >> >> ? vblendvps %ymm2,%ymm0,%ymm1,%ymm2 >> >> ? vmovdqu %ymm2,0x10(%r9,%r10,4) >> >> The patch is available for review here: >> >> http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_cmovevf_00/ >> >> Jtreg testing with compiler tests has successfully passed. Thanks for review! >> >> --Razvan >> From dean.long at oracle.com Mon Dec 4 23:11:27 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Mon, 4 Dec 2017 15:11:27 -0800 Subject: RFR(XS) 8145579: SimpleThresholdPolicy assumes non-trivial methods to be trivial In-Reply-To: References: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> Message-ID: <23095a9b-4c1f-1758-1e02-4961efd74c50@oracle.com> Thanks Vladimir. dl On 12/4/17 2:11 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 12/4/17 9:44 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8145579 >> http://cr.openjdk.java.net/~dlong/8145579/webrev/ >> >> This change fixes certain non-trivial methods being marked as >> trivial.? A method should only be marked as trivial if C2 cannot >> generate better code.? The two cases fixed here are calling >> intrinsics, and Object., which has a hidden call to register >> finalizers.? When run with >> http://cr.openjdk.java.net/~shade/8145579/benchmarks.jar >> , the >> test methods now end up compiled at level 4 instead of level 1. >> >> dl From tobias.hartmann at oracle.com Tue Dec 5 07:07:09 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 5 Dec 2017 08:07:09 +0100 Subject: RFR(XS) 8145579: SimpleThresholdPolicy assumes non-trivial methods to be trivial In-Reply-To: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> References: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> Message-ID: <7fd675e9-0793-f3a4-c485-14004fc87c3c@oracle.com> Hi Dean, this looks good to me! Thanks, Tobias On 04.12.2017 18:44, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8145579 > http://cr.openjdk.java.net/~dlong/8145579/webrev/ > > This change fixes certain non-trivial methods being marked as trivial.? A method should only be marked as trivial if C2 > cannot generate better code.? The two cases fixed here are calling intrinsics, and Object., which has a hidden > call to register finalizers.? When run with? http://cr.openjdk.java.net/~shade/8145579/benchmarks.jar > , the test methods now end up compiled at level 4 instead of > level 1. > > dl From shade at redhat.com Tue Dec 5 09:25:44 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 Dec 2017 10:25:44 +0100 Subject: RFR(XS) 8145579: SimpleThresholdPolicy assumes non-trivial methods to be trivial In-Reply-To: <6a6a512f-bcc3-c474-d3e0-4bf96705c953@oracle.com> References: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> <25ab4b1a-0d16-d4ff-b9d3-45de77cc184c@redhat.com> <6a6a512f-bcc3-c474-d3e0-4bf96705c953@oracle.com> Message-ID: <5031e189-c11a-2123-52e7-1c626ba77497@redhat.com> On 12/04/2017 10:07 PM, dean.long at oracle.com wrote: > On 12/4/17 12:10 PM, Aleksey Shipilev wrote: >> On 12/04/2017 06:44 PM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8145579 >>> http://cr.openjdk.java.net/~dlong/8145579/webrev/ >>> >>> This change fixes certain non-trivial methods being marked as trivial.? A method should only be >>> marked as trivial if C2 cannot generate better code.? The two cases fixed here are calling >>> intrinsics, and Object., which has a hidden call to register finalizers. >> I am good with the fix, but my issue is with the essence of that shortcut. We can keep piling on >> exceptions on top of exceptions to that triviality rule, or we can just dispense with the idea that >> we can guess what methods are trivial and/or remember to fix it up every time something changes. >> >> Is it really worth falling back to C1 for trivial methods? I.e. is C2 compilation for those methods >> too costly (which would seem counter-intuitive)? Can we remove that triviality check, and see if we >> run fine without it? > > I agree, we should take another look at that code.? We have reopened 8076988 to look into that for 11. Thanks, that makes sense. -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rwestrel at redhat.com Tue Dec 5 13:31:03 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Tue, 05 Dec 2017 14:31:03 +0100 Subject: RFR(S): 8191950: assertion failed: no insertions allowed In-Reply-To: References: <8c9e6244-fa55-903f-8b39-349aeff3815a@oracle.com> Message-ID: Thanks for the review and for pushing it. Roland. From vladimir.kozlov at oracle.com Tue Dec 5 18:02:53 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 5 Dec 2017 10:02:53 -0800 Subject: RFR(S) 8192846: Extend cmov vectorization to work for float In-Reply-To: References: <48D92A70936F7946BE99F3FF5ECB6461D8DE1631@ORSMSX113.amr.corp.intel.com> <86784639-2e3c-d5da-3369-8a71bdd74632@oracle.com> <48D92A70936F7946BE99F3FF5ECB6461D8DE1E7D@ORSMSX113.amr.corp.intel.com> Message-ID: Pushed into jdk/hs with approval of our gatekeeper. Regards, Vladimir On 12/4/17 2:26 PM, Vladimir Kozlov wrote: > On 12/4/17 11:19 AM, Lupusoru, Razvan A wrote: >> Hi Vladimir, >> >> I removed the "do_vector_loop" check in order to enable the >> optimization by default - but it seems that was undesirable from your >> point of view. > > It is not desirable for JDK 10 since it is too late. > >> >> Thus, we have added a new flag "UseVectorCmov" which is disabled by >> default but anyone interested in feature can enable it manually. >> Ideally we can get it in this form into this upcoming release and >> remove the guard for following release once we check the stability of >> it more. > > Sounds good. Agree. > >> >> The path for the updated webrev: >> http://cr.openjdk.java.net/~vdeshpande/8192846/webrev.01/ >> Code contributed by Razvan Lupusoru (rlupusoru) > > I will test it. > > Thanks, > Vladimir > >> >> Thanks, >> Razvan >> >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, November 30, 2017 3:46 PM >> To: Lupusoru, Razvan A ; >> hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S) 8192846: Extend cmov vectorization to work for float >> >> Thank you, Razvan >> >> I have one question: why you removed _do_vector_loop checks in >> superword.cpp? >> >> Also I think it is late for jdk 10. I will test and push when jdk 10 >> is forked. >> >> Thanks, >> Vladimir >> >> On 11/30/17 1:48 PM, Lupusoru, Razvan A wrote: >>> Hi all, >>> >>> This submission is to the issue noted in JDK-8192846 ?- namely that >>> vectorized cmov for floats is not supported. >>> >>> This patch rectifies the situation so that when scalar Cmov for float >>> and double is generated (or forced generated by passing >>> -XX:+UseCMoveUnconditionally), it stands a chance for Vectorization >>> using existing functionality previously enabled for doubles. The >>> following code pattern will get vectorized with patch above: >>> >>> private void cmove_kernel_float(float[] in1, float[] in2, int length, >>> float[] out) { >>> >>> ? ? for (int i = 0; i < length; i++) { >>> >>> ? ??? out[i] = (in1[i] > in2[i]) ? in1[i] : in2[i]; >>> >>> ? ? } >>> >>> } >>> >>> Instructions generated for loop are: >>> >>> ? ? vmovdqu 0x10(%rcx,%r10,4),%ymm0 >>> >>> ? ? vmovdqu 0x10(%rdx,%r10,4),%ymm1 >>> >>> ? ? vcmpleps %ymm0,%ymm1,%ymm2 >>> >>> ? ? vblendvps %ymm2,%ymm0,%ymm1,%ymm2 >>> >>> ? ? vmovdqu %ymm2,0x10(%r9,%r10,4) >>> >>> The patch is available for review here: >>> >>> http://cr.openjdk.java.net/~rlupusoru/jdk_hs/webrev_cmovevf_00/ >>> >>> Jtreg testing with compiler tests has successfully passed. Thanks for >>> review! >>> >>> --Razvan >>> From dean.long at oracle.com Tue Dec 5 18:35:07 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 5 Dec 2017 10:35:07 -0800 Subject: RFR(XS) 8145579: SimpleThresholdPolicy assumes non-trivial methods to be trivial In-Reply-To: <7fd675e9-0793-f3a4-c485-14004fc87c3c@oracle.com> References: <92063a18-867c-8a7f-1a7e-736b23ffce2c@oracle.com> <7fd675e9-0793-f3a4-c485-14004fc87c3c@oracle.com> Message-ID: <83344e82-a60f-17ff-3d73-891b160c8c44@oracle.com> Thanks Tobias! dl On 12/4/17 11:07 PM, Tobias Hartmann wrote: > Hi Dean, > > this looks good to me! > > Thanks, > Tobias > > On 04.12.2017 18:44, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8145579 >> http://cr.openjdk.java.net/~dlong/8145579/webrev/ >> >> This change fixes certain non-trivial methods being marked as trivial.? A method should only be marked as trivial if C2 >> cannot generate better code.? The two cases fixed here are calling intrinsics, and Object., which has a hidden >> call to register finalizers.? When run with? http://cr.openjdk.java.net/~shade/8145579/benchmarks.jar >> , the test methods now end up compiled at level 4 instead of >> level 1. >> >> dl From tom.rodriguez at oracle.com Tue Dec 5 19:50:35 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Tue, 05 Dec 2017 11:50:35 -0800 Subject: RFR 8191052: [Graal] java/lang/invoke/CallSiteTest.java intermittently fails with "Failed dependency of type call_site_target_value" when running with Graal as JIT In-Reply-To: <2c087c05-17a7-6444-2beb-7bd830a880dc@oracle.com> References: <5A1DDB06.30908@oracle.com> <5A21A169.4040906@oracle.com> <22805F2A-035A-4835-A185-21FB3991EED8@oracle.com> <2c087c05-17a7-6444-2beb-7bd830a880dc@oracle.com> Message-ID: <5A26F88B.8060005@oracle.com> Thanks for the reviews. tom dean.long at oracle.com wrote: > +1 > > dl > > > On 12/1/17 11:49 AM, Igor Veresov wrote: >> It looks good to me. >> >> igor >> >>> On Dec 1, 2017, at 10:37 AM, Tom Rodriguez >>> wrote: >>> >>> >>> >>> Vladimir Kozlov wrote: >>>> On 11/28/17 1:54 PM, Tom Rodriguez wrote: >>>>> http://cr.openjdk.java.net/~never/8191052/webrev >>>>> https://bugs.openjdk.java.net/browse/JDK-8191052 >>>> Looks good to me. >>>> >>>>> This consolidates the logic to validate dependencies before code >>>>> installation. JVMCI was missing logic to treat call_site_target_value >>>>> failures benignly and the code had also diverged over time. Tested >>>>> with Graal and Truffle. mach5 testing is being submitted. >>>> Please, add mach5 job link to confidential comment in JBS. >>> Done. The results are clean. Do I need more than 1 reviewer? And I >>> just push instead of using jprt? >>> >>> tom >>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> tom > From dean.long at oracle.com Tue Dec 5 22:12:38 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 5 Dec 2017 14:12:38 -0800 Subject: RFR(S) 8193009: compiler/c2/Test7029152.java crashes with SIGILL in java.lang.StringLatin1.indexOf with -XX:+UseJVMCICompiler Message-ID: https://bugs.openjdk.java.net/browse/JDK-8193009 http://cr.openjdk.java.net/~dlong/8193009/webrev/ I tested all 16 base register combinations to make sure we handle anything Graal might generate. dl From igor.veresov at oracle.com Tue Dec 5 22:17:40 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Tue, 5 Dec 2017 14:17:40 -0800 Subject: RFR(S) 8193009: compiler/c2/Test7029152.java crashes with SIGILL in java.lang.StringLatin1.indexOf with -XX:+UseJVMCICompiler In-Reply-To: References: Message-ID: <81B14453-0E61-491C-92B2-ECB0D716E4ED@oracle.com> Looks good. igor > On Dec 5, 2017, at 2:12 PM, dean.long at oracle.com wrote: > > https://bugs.openjdk.java.net/browse/JDK-8193009 > http://cr.openjdk.java.net/~dlong/8193009/webrev/ > > I tested all 16 base register combinations to make sure we handle anything Graal might generate. > > dl From dean.long at oracle.com Tue Dec 5 22:32:09 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 5 Dec 2017 14:32:09 -0800 Subject: RFR(S) 8193009: compiler/c2/Test7029152.java crashes with SIGILL in java.lang.StringLatin1.indexOf with -XX:+UseJVMCICompiler In-Reply-To: <81B14453-0E61-491C-92B2-ECB0D716E4ED@oracle.com> References: <81B14453-0E61-491C-92B2-ECB0D716E4ED@oracle.com> Message-ID: <06341b35-262b-7e2b-a582-47dfc906a802@oracle.com> Thanks Igor. dl On 12/5/17 2:17 PM, Igor Veresov wrote: > Looks good. > > igor > >> On Dec 5, 2017, at 2:12 PM, dean.long at oracle.com wrote: >> >> https://bugs.openjdk.java.net/browse/JDK-8193009 >> http://cr.openjdk.java.net/~dlong/8193009/webrev/ >> >> I tested all 16 base register combinations to make sure we handle anything Graal might generate. >> >> dl From rwestrel at redhat.com Wed Dec 6 14:06:29 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 06 Dec 2017 15:06:29 +0100 Subject: RFR(XS): 8192908: -XX:+UseCountedLoopSafepoints alone doesn't disable strip mining with G1 Message-ID: http://cr.openjdk.java.net/~roland/8192908/webrev.00/ Running java -XX:+UseCountedLoopSafepoints causes a message to be printed: warning: When counted loop safepoints are enabled, LoopStripMiningIter must be at least 1 (a safepoint every 1 iteration): setting it to 1 But the G1 specific code sets LoopStripMiningIter to 1000. This change makes sure that -XX:+UseCountedLoopSafepoints disables loop strip mining. Roland. From tobias.hartmann at oracle.com Wed Dec 6 14:16:33 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Wed, 6 Dec 2017 15:16:33 +0100 Subject: RFR(XS): 8192908: -XX:+UseCountedLoopSafepoints alone doesn't disable strip mining with G1 In-Reply-To: References: Message-ID: Hi Roland, looks good to me. Best regards, Tobias On 06.12.2017 15:06, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8192908/webrev.00/ > > Running java -XX:+UseCountedLoopSafepoints causes a message to be > printed: > > warning: When counted loop safepoints are enabled, LoopStripMiningIter must be at least 1 (a safepoint every 1 iteration): setting it to 1 > > But the G1 specific code sets LoopStripMiningIter to 1000. This change > makes sure that -XX:+UseCountedLoopSafepoints disables loop strip > mining. > > Roland. > From vladimir.kozlov at oracle.com Wed Dec 6 16:31:39 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 6 Dec 2017 08:31:39 -0800 Subject: RFR(XS): 8192908: -XX:+UseCountedLoopSafepoints alone doesn't disable strip mining with G1 In-Reply-To: References: Message-ID: <28e51ad8-bb3c-0047-3d45-cb9fba132ad1@oracle.com> +1 Thanks, Vladimir PS: Tobias, please, sponsor it. I have meetings. On 12/6/17 6:16 AM, Tobias Hartmann wrote: > Hi Roland, > > looks good to me. > > Best regards, > Tobias > > On 06.12.2017 15:06, Roland Westrelin wrote: >> >> http://cr.openjdk.java.net/~roland/8192908/webrev.00/ >> >> Running java -XX:+UseCountedLoopSafepoints causes a message to be >> printed: >> >> warning: When counted loop safepoints are enabled, LoopStripMiningIter must be at least 1 (a safepoint every 1 iteration): setting it to 1 >> >> But the G1 specific code sets LoopStripMiningIter to 1000. This change >> makes sure that -XX:+UseCountedLoopSafepoints disables loop strip >> mining. >> >> Roland. >> From vladimir.kozlov at oracle.com Thu Dec 7 01:39:59 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 6 Dec 2017 17:39:59 -0800 Subject: RFR(S) 8193009: compiler/c2/Test7029152.java crashes with SIGILL in java.lang.StringLatin1.indexOf with -XX:+UseJVMCICompiler In-Reply-To: References: Message-ID: <34c84b5f-6562-ed4c-8338-88ba5d5005e3@oracle.com> Should we put new check code under #ifdef INCLUDE_JVMCI and if (UseJVMCICompiler)? Stubs code generation happens after flags parsing. Thanks, Vladimir On 12/5/17 2:12 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8193009 > http://cr.openjdk.java.net/~dlong/8193009/webrev/ > > I tested all 16 base register combinations to make sure we handle anything Graal might generate. > > dl From dean.long at oracle.com Thu Dec 7 01:56:43 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 6 Dec 2017 17:56:43 -0800 Subject: RFR(S) 8193009: compiler/c2/Test7029152.java crashes with SIGILL in java.lang.StringLatin1.indexOf with -XX:+UseJVMCICompiler In-Reply-To: <34c84b5f-6562-ed4c-8338-88ba5d5005e3@oracle.com> References: <34c84b5f-6562-ed4c-8338-88ba5d5005e3@oracle.com> Message-ID: On 12/6/17 5:39 PM, Vladimir Kozlov wrote: > Should we put new check code under #ifdef INCLUDE_JVMCI and if > (UseJVMCICompiler)? Stubs code generation happens after flags parsing. > We could, but I don't think it's worth it.? I would rather allow C1 and C2 to emit the same range of encodings as Graal.? I think it would help avoid spills. dl > Thanks, > Vladimir > > On 12/5/17 2:12 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8193009 >> http://cr.openjdk.java.net/~dlong/8193009/webrev/ >> >> I tested all 16 base register combinations to make sure we handle >> anything Graal might generate. >> >> dl From vladimir.kozlov at oracle.com Thu Dec 7 02:19:10 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 6 Dec 2017 18:19:10 -0800 Subject: RFR(S) 8193009: compiler/c2/Test7029152.java crashes with SIGILL in java.lang.StringLatin1.indexOf with -XX:+UseJVMCICompiler In-Reply-To: References: <34c84b5f-6562-ed4c-8338-88ba5d5005e3@oracle.com> Message-ID: <09107e03-2c86-5976-7442-bdd5bb32c142@oracle.com> On 12/6/17 5:56 PM, dean.long at oracle.com wrote: > On 12/6/17 5:39 PM, Vladimir Kozlov wrote: > >> Should we put new check code under #ifdef INCLUDE_JVMCI and if (UseJVMCICompiler)? Stubs code >> generation happens after flags parsing. >> > > We could, but I don't think it's worth it.? I would rather allow C1 and C2 to emit the same range of > encodings as Graal.? I think it would help avoid spills. Okay, it make sense. Please, file follow up RFE for C1 and C2. Thanks, Vladimir > > dl > >> Thanks, >> Vladimir >> >> On 12/5/17 2:12 PM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8193009 >>> http://cr.openjdk.java.net/~dlong/8193009/webrev/ >>> >>> I tested all 16 base register combinations to make sure we handle anything Graal might generate. >>> >>> dl > From dean.long at oracle.com Thu Dec 7 02:25:21 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 6 Dec 2017 18:25:21 -0800 Subject: RFR(S) 8193009: compiler/c2/Test7029152.java crashes with SIGILL in java.lang.StringLatin1.indexOf with -XX:+UseJVMCICompiler In-Reply-To: <09107e03-2c86-5976-7442-bdd5bb32c142@oracle.com> References: <34c84b5f-6562-ed4c-8338-88ba5d5005e3@oracle.com> <09107e03-2c86-5976-7442-bdd5bb32c142@oracle.com> Message-ID: <9e20e099-5ef8-bb53-e464-b89e95665f82@oracle.com> On 12/6/17 6:19 PM, Vladimir Kozlov wrote: > On 12/6/17 5:56 PM, dean.long at oracle.com wrote: >> On 12/6/17 5:39 PM, Vladimir Kozlov wrote: >> >>> Should we put new check code under #ifdef INCLUDE_JVMCI and if >>> (UseJVMCICompiler)? Stubs code generation happens after flags parsing. >>> >> >> We could, but I don't think it's worth it.? I would rather allow C1 >> and C2 to emit the same range of encodings as Graal.? I think it >> would help avoid spills. > > Okay, it make sense. Please, file follow up RFE for C1 and C2. > Thanks Vladimir. dl > Thanks, > Vladimir > >> >> dl >> >>> Thanks, >>> Vladimir >>> >>> On 12/5/17 2:12 PM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8193009 >>>> http://cr.openjdk.java.net/~dlong/8193009/webrev/ >>>> >>>> I tested all 16 base register combinations to make sure we handle >>>> anything Graal might generate. >>>> >>>> dl >> From tobias.hartmann at oracle.com Thu Dec 7 10:51:25 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 7 Dec 2017 11:51:25 +0100 Subject: RFR(XS): 8192908: -XX:+UseCountedLoopSafepoints alone doesn't disable strip mining with G1 In-Reply-To: <28e51ad8-bb3c-0047-3d45-cb9fba132ad1@oracle.com> References: <28e51ad8-bb3c-0047-3d45-cb9fba132ad1@oracle.com> Message-ID: <4c700170-8f5b-ea7d-8128-ac69603c4d60@oracle.com> On 06.12.2017 17:31, Vladimir Kozlov wrote: > PS: Tobias, please, sponsor it. I have meetings. Sure, I'll take care of it. Best regards, Tobias From rkennke at redhat.com Thu Dec 7 17:15:08 2017 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 7 Dec 2017 18:15:08 +0100 Subject: RFR: 8193193: immByteMapBase operand generated for non-CardTable GCs Message-ID: This is aarch64-only. The operand immByteMapBase in aarch64 blindly casts the BarrierSet to CardTableModRefBS and checks if the byte_map_base field points into the heap. This sometimes generates the operand for non-CTMRBS GCs too: ->byte_map_base will resolve some random ptr, and if that happens to be inside the heap, it will generate the operand, causing all sorts of weird trouble. The fix is to check the BS type before casting: http://cr.openjdk.java.net/~rkennke/aarch64-ctmrbs/webrev.00/ Builds+passes relevant tests that have been failing before. Ok to push it? Roman From aph at redhat.com Mon Dec 11 08:54:09 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Dec 2017 08:54:09 +0000 Subject: RFR: 8193193: immByteMapBase operand generated for non-CardTable GCs In-Reply-To: References: Message-ID: <6cb4f3ac-4455-2bde-5d20-7722693ac811@redhat.com> On 07/12/17 17:15, Roman Kennke wrote: > http://cr.openjdk.java.net/~rkennke/aarch64-ctmrbs/webrev.00/ > > Builds+passes relevant tests that have been failing before. > > Ok to push it? Yes, please. PLEASE flag all AArch64 bugs like this in the subject line: RFR: 8193193: AArch64: immByteMapBase operand generated for non-CardTable GCs -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Mon Dec 11 16:04:05 2017 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 11 Dec 2017 17:04:05 +0100 Subject: RFR: 8193193: immByteMapBase operand generated for non-CardTable GCs In-Reply-To: <6cb4f3ac-4455-2bde-5d20-7722693ac811@redhat.com> References: <6cb4f3ac-4455-2bde-5d20-7722693ac811@redhat.com> Message-ID: Am 11.12.2017 um 09:54 schrieb Andrew Haley: > On 07/12/17 17:15, Roman Kennke wrote: >> http://cr.openjdk.java.net/~rkennke/aarch64-ctmrbs/webrev.00/ >> >> Builds+passes relevant tests that have been failing before. >> >> Ok to push it? > > Yes, please. > > PLEASE flag all AArch64 bugs like this in the subject line: > > RFR: 8193193: AArch64: immByteMapBase operand generated for non-CardTable GCs > Ok, will do in future RFRs. And changed this bugs title and commit msg accordingly. I wonder if it might be worth to keep the byte_map_base in a dedicated register? (Shenandoah doesn't use the byte_map_base, but could use it for a similar purpose, e.g. base offset for in-cset-calculation) Roman From aph at redhat.com Mon Dec 11 16:36:19 2017 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 Dec 2017 16:36:19 +0000 Subject: RFR: 8193193: immByteMapBase operand generated for non-CardTable GCs In-Reply-To: References: <6cb4f3ac-4455-2bde-5d20-7722693ac811@redhat.com> Message-ID: <5f7e4ea0-5910-fcfd-7135-1209b939833d@redhat.com> On 11/12/17 16:04, Roman Kennke wrote: > I wonder if it might be worth to keep the byte_map_base in a dedicated > register? No, because we can usually do load_byte_map_base with something like adrp x1, 0x000003ff68410000 i.e. it's a single-clock instruction. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From jamsheed.c.m at oracle.com Tue Dec 12 02:43:47 2017 From: jamsheed.c.m at oracle.com (jamsheed) Date: Tue, 12 Dec 2017 08:13:47 +0530 Subject: RFR: 8152110: Stabilize C2 loop optimizations Message-ID: <534d0b4e-7f79-2b6e-9b59-d594467a79dd@oracle.com> Hi, request for review jbs: https://bugs.openjdk.java.net/browse/JDK-8152110 webrev: http://cr.openjdk.java.net/~jcm/8152110/webrev.00/ the patch make sure that, there is no heavy loop optimizations performed after opaque nodes removal. Only simple loop optimizations like converting single iteration loops to normal code/ removing empty loops are performed after opaque node removal. this change is done based on discussion here [1] mach5/perf report attached in jbs Best regards, Jamsheed [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021353.html http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/021967.html From tobias.hartmann at oracle.com Tue Dec 12 10:24:01 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Dec 2017 11:24:01 +0100 Subject: RFR(XS): 8193363: TestDumpReplay.java fails with product builds Message-ID: <2e602e14-d791-8c16-3558-0f8b482a9982@oracle.com> Hi, please review the following patch that adds a missing -XX:+IgnoreUnrecognizedVMOptions to the test: https://bugs.openjdk.java.net/browse/JDK-8193363 http://cr.openjdk.java.net/~thartmann/8193363/webrev.00/ Thanks, Tobias From vladimir.kozlov at oracle.com Tue Dec 12 17:15:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Dec 2017 09:15:52 -0800 Subject: RFR(XS): 8193363: TestDumpReplay.java fails with product builds In-Reply-To: <2e602e14-d791-8c16-3558-0f8b482a9982@oracle.com> References: <2e602e14-d791-8c16-3558-0f8b482a9982@oracle.com> Message-ID: <939f6f45-4f37-30ad-4a77-22ae5b062054@oracle.com> Good. One review is fine. Thanks, Vladimir On 12/12/17 2:24 AM, Tobias Hartmann wrote: > Hi, > > please review the following patch that adds a missing -XX:+IgnoreUnrecognizedVMOptions to the test: > https://bugs.openjdk.java.net/browse/JDK-8193363 > http://cr.openjdk.java.net/~thartmann/8193363/webrev.00/ > > Thanks, > Tobias > From tobias.hartmann at oracle.com Tue Dec 12 17:28:43 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Dec 2017 18:28:43 +0100 Subject: RFR(XS): 8193363: TestDumpReplay.java fails with product builds In-Reply-To: <939f6f45-4f37-30ad-4a77-22ae5b062054@oracle.com> References: <2e602e14-d791-8c16-3558-0f8b482a9982@oracle.com> <939f6f45-4f37-30ad-4a77-22ae5b062054@oracle.com> Message-ID: <53f66d77-c1d9-ca5f-920f-443db0baf181@oracle.com> Hi Vladimir, On 12.12.2017 18:15, Vladimir Kozlov wrote: > Good. One review is fine. Thanks for the review. Should I push this to jdk/jdk directly? Best regards, Tobias > On 12/12/17 2:24 AM, Tobias Hartmann wrote: >> Hi, >> >> please review the following patch that adds a missing -XX:+IgnoreUnrecognizedVMOptions to the test: >> https://bugs.openjdk.java.net/browse/JDK-8193363 >> http://cr.openjdk.java.net/~thartmann/8193363/webrev.00/ >> >> Thanks, >> Tobias >> From vladimir.kozlov at oracle.com Tue Dec 12 17:59:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Dec 2017 09:59:32 -0800 Subject: RFR(XS): 8193363: TestDumpReplay.java fails with product builds In-Reply-To: <53f66d77-c1d9-ca5f-920f-443db0baf181@oracle.com> References: <2e602e14-d791-8c16-3558-0f8b482a9982@oracle.com> <939f6f45-4f37-30ad-4a77-22ae5b062054@oracle.com> <53f66d77-c1d9-ca5f-920f-443db0baf181@oracle.com> Message-ID: <626a96d9-0bd1-b98a-8f4a-0dc874aac089@oracle.com> You can push into jdk/hs: "FYI, Mark sent out the announcement below around RDP1. I'm happy to highlight that this announcement states that all main JDK repositories (which includes jdk/hs) will enter RDP1 at the same date, December 14th. We have agreed on a process to allow pushes made to the jdk/hs repository all the way up to December 14th to get integrated to the JDK 10 stabilization repository. This gives you another week to fix those last critical P4-P5 bugs." Vladimir On 12/12/17 9:28 AM, Tobias Hartmann wrote: > Hi Vladimir, > > On 12.12.2017 18:15, Vladimir Kozlov wrote: >> Good. One review is fine. > > Thanks for the review. Should I push this to jdk/jdk directly? > > Best regards, > Tobias >> On 12/12/17 2:24 AM, Tobias Hartmann wrote: >>> Hi, >>> >>> please review the following patch that adds a missing -XX:+IgnoreUnrecognizedVMOptions to the test: >>> https://bugs.openjdk.java.net/browse/JDK-8193363 >>> http://cr.openjdk.java.net/~thartmann/8193363/webrev.00/ >>> >>> Thanks, >>> Tobias >>> From tobias.hartmann at oracle.com Tue Dec 12 18:03:28 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Tue, 12 Dec 2017 19:03:28 +0100 Subject: RFR(XS): 8193363: TestDumpReplay.java fails with product builds In-Reply-To: <626a96d9-0bd1-b98a-8f4a-0dc874aac089@oracle.com> References: <2e602e14-d791-8c16-3558-0f8b482a9982@oracle.com> <939f6f45-4f37-30ad-4a77-22ae5b062054@oracle.com> <53f66d77-c1d9-ca5f-920f-443db0baf181@oracle.com> <626a96d9-0bd1-b98a-8f4a-0dc874aac089@oracle.com> Message-ID: On 12.12.2017 18:59, Vladimir Kozlov wrote: > You can push into jdk/hs: > > "FYI, Mark sent out the announcement below around RDP1. I'm happy to highlight that this announcement states that all > main JDK repositories (which includes jdk/hs) will enter RDP1 at the same date, December 14th. > > We have agreed on a process to allow pushes made to the jdk/hs repository all the way up to December 14th to get > integrated to the JDK 10 stabilization repository. This gives you another week to fix those last critical P4-P5 bugs." Thanks, I'll push to jdk/hs then. Best regards, Tobias > On 12/12/17 9:28 AM, Tobias Hartmann wrote: >> Hi Vladimir, >> >> On 12.12.2017 18:15, Vladimir Kozlov wrote: >>> Good. One review is fine. >> >> Thanks for the review. Should I push this to jdk/jdk directly? >> >> Best regards, >> Tobias >>> On 12/12/17 2:24 AM, Tobias Hartmann wrote: >>>> Hi, >>>> >>>> please review the following patch that adds a missing -XX:+IgnoreUnrecognizedVMOptions to the test: >>>> https://bugs.openjdk.java.net/browse/JDK-8193363 >>>> http://cr.openjdk.java.net/~thartmann/8193363/webrev.00/ >>>> >>>> Thanks, >>>> Tobias >>>> From vladimir.x.ivanov at oracle.com Tue Dec 12 19:16:19 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 12 Dec 2017 22:16:19 +0300 Subject: [10] RFR (S): C2: missing strength reduction of Math.pow(x, 2.0D) to x*x Message-ID: <077d9f77-ed58-c971-7899-05968ab40f73@oracle.com> http://cr.openjdk.java.net/~vlivanov/8190869/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8190869 Math.pow() was completely rewritten on 9 and important special case (exponent == 2.0) was missed. It caused severe performance regression (up to 10x) on some numeric code. The fix is two-fold: * add special case in C2 to transform pow(x,2.0) into x*x; * for consistency of results between different execution modes (interpreter, C1, and C2), add special case into generated stub at MacroAssembler::fast_pow(). Some clarifications follow. Testing: * microbenchmark * hs-precheckin-comp, hs-tier1, hs-tier2 (in progress) * test case from 8189172 on consistency of results The fix doesn't cover all possible cases (e.g., when exponent is not a constant during parsing, but becomes such later). I experimented with more elaborate fix, but wasn't satisfied with the results and chose simpler route. I see 2 alternatives: (1) Introduce macro node PowD and either transform it into MulD if exponent == 2.0D or expand it into CallLeafNode. The downside is that PowD should be CallNode and replacing it with a MulD requires some IR tweaking around it. (2) Introduce a runtime check before calling the stub (prototype [1]). If exponent becomes 2.0 later, the check is folded and stub call is removed. The downside is that when exponent doesn't turn into 2.0, the check stays and duplicates the check in the stub. Unfortunately, there's no way to remove it from the stub, because interpreter & C1 relies on it. Otherwise, inconsistent computation results become possible (like JDK-8189172 [2]). So, I decided to go with a simple fix and cover most common case (explicit usage of 2.0 with Math.pow) for now. Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~vlivanov/8190869/webrev.runtime_check [2] https://bugs.openjdk.java.net/browse/JDK-8189172 From vladimir.kozlov at oracle.com Tue Dec 12 22:18:24 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Dec 2017 14:18:24 -0800 Subject: [10] RFR (S): C2: missing strength reduction of Math.pow(x, 2.0D) to x*x In-Reply-To: <077d9f77-ed58-c971-7899-05968ab40f73@oracle.com> References: <077d9f77-ed58-c971-7899-05968ab40f73@oracle.com> Message-ID: I agree with suggested fix. What check we have before 9 and where was it? Why do you need to move value to tmp1? + movdq(tmp1, xmm1); + cmp64(tmp1, ExternalAddress(DOUBLE2)); Thanks, Vladimir On 12/12/17 11:16 AM, Vladimir Ivanov wrote: > http://cr.openjdk.java.net/~vlivanov/8190869/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8190869 > > Math.pow() was completely rewritten on 9 and important special case > (exponent == 2.0) was missed. It caused severe performance regression > (up to 10x) on some numeric code. > > The fix is two-fold: > ? * add special case in C2 to transform pow(x,2.0) into x*x; > ? * for consistency of results between different execution modes > (interpreter, C1, and C2), add special case into generated stub at > MacroAssembler::fast_pow(). > > Some clarifications follow. > > Testing: > ? * microbenchmark > ? * hs-precheckin-comp, hs-tier1, hs-tier2 (in progress) > ? * test case from 8189172 on consistency of results > > The fix doesn't cover all possible cases (e.g., when exponent is not a > constant during parsing, but becomes such later). I experimented with > more elaborate fix, but wasn't satisfied with the results and chose > simpler route. > > I see 2 alternatives: > > (1) Introduce macro node PowD and either transform it into MulD if > exponent == 2.0D or expand it into CallLeafNode. The downside is that > PowD should be CallNode and replacing it with a MulD requires some IR > tweaking around it. > > (2) Introduce a runtime check before calling the stub (prototype [1]). > If exponent becomes 2.0 later, the check is folded and stub call is > removed. The downside is that when exponent doesn't turn into 2.0, the > check stays and duplicates the check in the stub. Unfortunately, there's > no way to remove it from the stub, because interpreter & C1 relies on > it. Otherwise, inconsistent computation results become possible (like > JDK-8189172 [2]). > > So, I decided to go with a simple fix and cover most common case > (explicit usage of 2.0 with Math.pow) for now. > > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~vlivanov/8190869/webrev.runtime_check > [2] https://bugs.openjdk.java.net/browse/JDK-8189172 From daniel.daugherty at oracle.com Wed Dec 13 02:13:04 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Dec 2017 21:13:04 -0500 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build Message-ID: Greetings, I have a 1-liner fix to solve a Solaris slowdebug test-image build problem: ??? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build ??? https://bugs.openjdk.java.net/browse/JDK-8193407 Here is the context diff: $ hg diff diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 -0500 +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 -0500 @@ -113,6 +113,7 @@ ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc ?endif ?ifeq ($(OPENJDK_TARGET_OS), linux) David Holmes suggested the possible fix and I have tested the fix with Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. David is the first (R)eviewer. Since this affects a Compiler team test, it would be good to hear from someone on the Compiler team. Since it is a Makefile change, it would be good to hear from someone on the build-dev at ... alias... Thanks, in advance, for questions, comments, or suggestions. Dan From david.holmes at oracle.com Wed Dec 13 02:16:09 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 13 Dec 2017 12:16:09 +1000 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: References: Message-ID: <12514e92-a045-154c-655f-132a693584c4@oracle.com> Hi Dan, On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: > Greetings, > > I have a 1-liner fix to solve a Solaris slowdebug test-image build > problem: > > ??? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build > ??? https://bugs.openjdk.java.net/browse/JDK-8193407 > > Here is the context diff: > > $ hg diff > diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk > --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 -0500 > +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 -0500 > @@ -113,6 +113,7 @@ > ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc > ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc > ???? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc > +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc > ?endif > > ?ifeq ($(OPENJDK_TARGET_OS), linux) > > > David Holmes suggested the possible fix and I have tested the fix with > Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. Thanks for that! > David is the first (R)eviewer. Since this affects a Compiler team > test, it would be good to hear from someone on the Compiler team. > Since it is a Makefile change, it would be good to hear from someone > on the build-dev at ... alias... I think that is a bit of overkill. I was going to say push this under trivial rules! Aside: I've started a separate email thread on why we need to list -lc explicitly in the makefile. Thanks, David > Thanks, in advance, for questions, comments, or suggestions. > > Dan > From vladimir.kozlov at oracle.com Wed Dec 13 02:24:04 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 12 Dec 2017 18:24:04 -0800 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: <12514e92-a045-154c-655f-132a693584c4@oracle.com> References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> Message-ID: Reviewed. Looks good. Thanks, Vladimir On 12/12/17 6:16 PM, David Holmes wrote: > Hi Dan, > > On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a 1-liner fix to solve a Solaris slowdebug test-image build >> problem: >> >> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >> >> Here is the context diff: >> >> $ hg diff >> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 -0500 >> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 -0500 >> @@ -113,6 +113,7 @@ >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := >> -lc >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >> ??endif >> >> ??ifeq ($(OPENJDK_TARGET_OS), linux) >> >> >> David Holmes suggested the possible fix and I have tested the fix with >> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. > > Thanks for that! > >> David is the first (R)eviewer. Since this affects a Compiler team >> test, it would be good to hear from someone on the Compiler team. >> Since it is a Makefile change, it would be good to hear from someone >> on the build-dev at ... alias... > > I think that is a bit of overkill. I was going to say push this under > trivial rules! > > Aside: I've started a separate email thread on why we need to list -lc > explicitly in the makefile. > > Thanks, > David > >> Thanks, in advance, for questions, comments, or suggestions. >> >> Dan >> From daniel.daugherty at oracle.com Wed Dec 13 02:19:23 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Dec 2017 21:19:23 -0500 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: <12514e92-a045-154c-655f-132a693584c4@oracle.com> References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> Message-ID: <55dffa5e-ba86-ed99-d56d-0e819e56e96e@oracle.com> On 12/12/17 9:16 PM, David Holmes wrote: > Hi Dan, > > On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >> Greetings, >> >> I have a 1-liner fix to solve a Solaris slowdebug test-image build >> problem: >> >> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >> >> Here is the context diff: >> >> $ hg diff >> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 -0500 >> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 -0500 >> @@ -113,6 +113,7 @@ >> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >> ??endif >> >> ??ifeq ($(OPENJDK_TARGET_OS), linux) >> >> >> David Holmes suggested the possible fix and I have tested the fix with >> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. > > Thanks for that! > >> David is the first (R)eviewer. Since this affects a Compiler team >> test, it would be good to hear from someone on the Compiler team. >> Since it is a Makefile change, it would be good to hear from someone >> on the build-dev at ... alias... > > I think that is a bit of overkill. I was going to say push this under > trivial rules! No problem. I'm just trying to be polite... :-) I'll go ahead and push it shortly... I'll wait long enough to clear my email queue and we'll see if anyone else chimes in... :-) > Aside: I've started a separate email thread on why we need to list -lc > explicitly in the makefile. Yup. It would be good to get rid of that if we can... Dan > > Thanks, > David > >> Thanks, in advance, for questions, comments, or suggestions. >> >> Dan >> From daniel.daugherty at oracle.com Wed Dec 13 02:24:46 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 12 Dec 2017 21:24:46 -0500 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> Message-ID: <3e35557e-2535-9dc8-30cd-393d7376526d@oracle.com> Vladimir, Thanks for the review! Dan On 12/12/17 9:24 PM, Vladimir Kozlov wrote: > Reviewed. Looks good. > > Thanks, > Vladimir > > On 12/12/17 6:16 PM, David Holmes wrote: >> Hi Dan, >> >> On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a 1-liner fix to solve a Solaris slowdebug test-image build >>> problem: >>> >>> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >>> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >>> >>> Here is the context diff: >>> >>> $ hg diff >>> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >>> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 >>> -0500 >>> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 >>> -0500 >>> @@ -113,6 +113,7 @@ >>> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc >>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >>> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >>> ??endif >>> >>> ??ifeq ($(OPENJDK_TARGET_OS), linux) >>> >>> >>> David Holmes suggested the possible fix and I have tested the fix with >>> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. >> >> Thanks for that! >> >>> David is the first (R)eviewer. Since this affects a Compiler team >>> test, it would be good to hear from someone on the Compiler team. >>> Since it is a Makefile change, it would be good to hear from someone >>> on the build-dev at ... alias... >> >> I think that is a bit of overkill. I was going to say push this under >> trivial rules! >> >> Aside: I've started a separate email thread on why we need to list >> -lc explicitly in the makefile. >> >> Thanks, >> David >> >>> Thanks, in advance, for questions, comments, or suggestions. >>> >>> Dan >>> From erik.joelsson at oracle.com Wed Dec 13 09:01:26 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 13 Dec 2017 10:01:26 +0100 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: <55dffa5e-ba86-ed99-d56d-0e819e56e96e@oracle.com> References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> <55dffa5e-ba86-ed99-d56d-0e819e56e96e@oracle.com> Message-ID: On 2017-12-13 03:19, Daniel D. Daugherty wrote: > On 12/12/17 9:16 PM, David Holmes wrote: >> Hi Dan, >> >> On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >>> Greetings, >>> >>> I have a 1-liner fix to solve a Solaris slowdebug test-image build >>> problem: >>> >>> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >>> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >>> >>> Here is the context diff: >>> >>> $ hg diff >>> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >>> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 >>> -0500 >>> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 >>> -0500 >>> @@ -113,6 +113,7 @@ >>> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc >>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >>> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >>> ??endif >>> >>> ??ifeq ($(OPENJDK_TARGET_OS), linux) >>> >>> >>> David Holmes suggested the possible fix and I have tested the fix with >>> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. >> >> Thanks for that! >> >>> David is the first (R)eviewer. Since this affects a Compiler team >>> test, it would be good to hear from someone on the Compiler team. >>> Since it is a Makefile change, it would be good to hear from someone >>> on the build-dev at ... alias... >> >> I think that is a bit of overkill. I was going to say push this under >> trivial rules! > > No problem. I'm just trying to be polite... :-) > > I'll go ahead and push it shortly... I'll wait long enough to clear my > email queue and we'll see if anyone else chimes in... :-) > I agree that it's trivial, but appreciate the cross post to build-dev so that we are in the loop. /Erik > >> Aside: I've started a separate email thread on why we need to list >> -lc explicitly in the makefile. > > Yup. It would be good to get rid of that if we can... > > Dan > > >> >> Thanks, >> David >> >>> Thanks, in advance, for questions, comments, or suggestions. >>> >>> Dan >>> > From igor.veresov at oracle.com Wed Dec 13 12:00:00 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 13 Dec 2017 04:00:00 -0800 Subject: RFR(XL) 8193439: Update Graal Message-ID: <7CDA67CA-F2A5-4C6A-9CBD-0CD0D4093F78@oracle.com> Please check the JBS entry for the list of the changsets. JBS: https://bugs.openjdk.java.net/browse/JDK-8193439 Webrev: http://cr.openjdk.java.net/~iveresov/8193439/webrev.00/ Thanks, igor From daniel.daugherty at oracle.com Wed Dec 13 14:01:03 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 13 Dec 2017 09:01:03 -0500 Subject: RFR(XXXS): 8193407: jdk/hs fails Solaris slowdebug test-image build In-Reply-To: References: <12514e92-a045-154c-655f-132a693584c4@oracle.com> <55dffa5e-ba86-ed99-d56d-0e819e56e96e@oracle.com> Message-ID: <65cefd55-caac-f553-520f-e4a22a650229@oracle.com> On 12/13/17 4:01 AM, Erik Joelsson wrote: > On 2017-12-13 03:19, Daniel D. Daugherty wrote: >> On 12/12/17 9:16 PM, David Holmes wrote: >>> Hi Dan, >>> >>> On 13/12/2017 12:13 PM, Daniel D. Daugherty wrote: >>>> Greetings, >>>> >>>> I have a 1-liner fix to solve a Solaris slowdebug test-image build >>>> problem: >>>> >>>> ???? JDK-8193407 jdk/hs fails Solaris slowdebug test-image build >>>> ???? https://bugs.openjdk.java.net/browse/JDK-8193407 >>>> >>>> Here is the context diff: >>>> >>>> $ hg diff >>>> diff -r a576e1b6784d make/test/JtregNativeHotspot.gmk >>>> --- a/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 14:14:06 2017 >>>> -0500 >>>> +++ b/make/test/JtregNativeHotspot.gmk??? Tue Dec 12 21:07:03 2017 >>>> -0500 >>>> @@ -113,6 +113,7 @@ >>>> BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHandshakeTransitionTest := -lc >>>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libHasNoEntryPoint := -lc >>>> ????? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libReturnError := -lc >>>> +??? BUILD_HOTSPOT_JTREG_LIBRARIES_LIBS_libCNLookUp := -lc >>>> ??endif >>>> >>>> ??ifeq ($(OPENJDK_TARGET_OS), linux) >>>> >>>> >>>> David Holmes suggested the possible fix and I have tested the fix with >>>> Solaris X64 'release', 'fastdebug' and 'slowdebug' builds. >>> >>> Thanks for that! >>> >>>> David is the first (R)eviewer. Since this affects a Compiler team >>>> test, it would be good to hear from someone on the Compiler team. >>>> Since it is a Makefile change, it would be good to hear from someone >>>> on the build-dev at ... alias... >>> >>> I think that is a bit of overkill. I was going to say push this >>> under trivial rules! >> >> No problem. I'm just trying to be polite... :-) >> >> I'll go ahead and push it shortly... I'll wait long enough to clear my >> email queue and we'll see if anyone else chimes in... :-) >> > I agree that it's trivial, but appreciate the cross post to build-dev > so that we are in the loop. Thanks for the review! Dan > > /Erik >> >>> Aside: I've started a separate email thread on why we need to list >>> -lc explicitly in the makefile. >> >> Yup. It would be good to get rid of that if we can... >> >> Dan >> >> >>> >>> Thanks, >>> David >>> >>>> Thanks, in advance, for questions, comments, or suggestions. >>>> >>>> Dan >>>> >> > From vladimir.x.ivanov at oracle.com Wed Dec 13 14:58:50 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 13 Dec 2017 17:58:50 +0300 Subject: [10] RFR (S): C2: missing strength reduction of Math.pow(x, 2.0D) to x*x In-Reply-To: References: <077d9f77-ed58-c971-7899-05968ab40f73@oracle.com> Message-ID: <1f305fee-22a6-e902-18dd-b8336e622f88@oracle.com> Thanks for review, Vladimir. > I agree with suggested fix. What check we have before 9 and where was it? It was quite complicated. There were LibraryCallKit::inline_pow() [1] & LibraryCallKit::finish_pow_exp() [2] with a runtime check for 2.0 exponent, multiple PowDs on fast paths, and a call into SharedRuntime::dpow on slow path. PowD had matcher rules [3] which produced x87-based implementation. > Why do you need to move value to tmp1? > > +? movdq(tmp1, xmm1); > +? cmp64(tmp1, ExternalAddress(DOUBLE2)); We want to compare 64-bit values and move the exponent from XMM to GP register. void Assembler::movdq(Register dst, XMMRegister src) { void MacroAssembler::cmp64(Register src1, AddressLiteral src2) { Best regards, Vladimir Ivanov [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/94849fb8ce93#l22.72 [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/94849fb8ce93#l22.16 [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/94849fb8ce93#l13.7 > On 12/12/17 11:16 AM, Vladimir Ivanov wrote: >> http://cr.openjdk.java.net/~vlivanov/8190869/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8190869 >> >> Math.pow() was completely rewritten on 9 and important special case >> (exponent == 2.0) was missed. It caused severe performance regression >> (up to 10x) on some numeric code. >> >> The fix is two-fold: >> ?? * add special case in C2 to transform pow(x,2.0) into x*x; >> ?? * for consistency of results between different execution modes >> (interpreter, C1, and C2), add special case into generated stub at >> MacroAssembler::fast_pow(). >> >> Some clarifications follow. >> >> Testing: >> ?? * microbenchmark >> ?? * hs-precheckin-comp, hs-tier1, hs-tier2 (in progress) >> ?? * test case from 8189172 on consistency of results >> >> The fix doesn't cover all possible cases (e.g., when exponent is not a >> constant during parsing, but becomes such later). I experimented with >> more elaborate fix, but wasn't satisfied with the results and chose >> simpler route. >> >> I see 2 alternatives: >> >> (1) Introduce macro node PowD and either transform it into MulD if >> exponent == 2.0D or expand it into CallLeafNode. The downside is that >> PowD should be CallNode and replacing it with a MulD requires some IR >> tweaking around it. >> >> (2) Introduce a runtime check before calling the stub (prototype [1]). >> If exponent becomes 2.0 later, the check is folded and stub call is >> removed. The downside is that when exponent doesn't turn into 2.0, the >> check stays and duplicates the check in the stub. Unfortunately, there's >> no way to remove it from the stub, because interpreter & C1 relies on >> it. Otherwise, inconsistent computation results become possible (like >> JDK-8189172 [2]). >> >> So, I decided to go with a simple fix and cover most common case >> (explicit usage of 2.0 with Math.pow) for now. >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://cr.openjdk.java.net/~vlivanov/8190869/webrev.runtime_check >> [2] https://bugs.openjdk.java.net/browse/JDK-8189172 From lutz.schmidt at sap.com Wed Dec 13 16:17:25 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Wed, 13 Dec 2017 16:17:25 +0000 Subject: RFR(S): 8193443: [s390]: EncodeISOArray generates wrong vector code Message-ID: Dear all, I would like to request reviews for this s390-only bux fix: Bug: https://bugs.openjdk.java.net/browse/JDK-8193443 Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8193443.00/index.html The condition code setting from vector compare instructions differs slightly from that of scalar instructions. Distinct condition code enum values were introduced, related conditional branch aliases were defined and, of course, the buggy code was fixed. The previously failing jtreg tests now pass. I would very much appreciate if this fix would make it into Java 10. Thank you! Lutz -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Wed Dec 13 16:25:47 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Dec 2017 08:25:47 -0800 Subject: [10] RFR (S): C2: missing strength reduction of Math.pow(x, 2.0D) to x*x In-Reply-To: <1f305fee-22a6-e902-18dd-b8336e622f88@oracle.com> References: <077d9f77-ed58-c971-7899-05968ab40f73@oracle.com> <1f305fee-22a6-e902-18dd-b8336e622f88@oracle.com> Message-ID: On 12/13/17 6:58 AM, Vladimir Ivanov wrote: > Thanks for review, Vladimir. > >> I agree with suggested fix. What check we have before 9 and where was it? > > It was quite complicated. There were LibraryCallKit::inline_pow() [1] & > LibraryCallKit::finish_pow_exp() [2] with a runtime check for 2.0 > exponent, multiple PowDs on fast paths, and a call into > SharedRuntime::dpow on slow path. PowD had matcher rules [3] which > produced x87-based implementation. Okay. > >> Why do you need to move value to tmp1? >> >> +? movdq(tmp1, xmm1); >> +? cmp64(tmp1, ExternalAddress(DOUBLE2)); > > We want to compare 64-bit values and move the exponent from XMM to GP > register. Of cause, you need to use GP register to compare. I thought tmp1 also xmm. Looks good. Thanks, Vladimir > > void Assembler::movdq(Register dst, XMMRegister src) { > void MacroAssembler::cmp64(Register src1, AddressLiteral src2) { > > Best regards, > Vladimir Ivanov > > [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/94849fb8ce93#l22.72 > [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/94849fb8ce93#l22.16 > [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/94849fb8ce93#l13.7 > >> On 12/12/17 11:16 AM, Vladimir Ivanov wrote: >>> http://cr.openjdk.java.net/~vlivanov/8190869/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8190869 >>> >>> Math.pow() was completely rewritten on 9 and important special case >>> (exponent == 2.0) was missed. It caused severe performance regression >>> (up to 10x) on some numeric code. >>> >>> The fix is two-fold: >>> ?? * add special case in C2 to transform pow(x,2.0) into x*x; >>> ?? * for consistency of results between different execution modes >>> (interpreter, C1, and C2), add special case into generated stub at >>> MacroAssembler::fast_pow(). >>> >>> Some clarifications follow. >>> >>> Testing: >>> ?? * microbenchmark >>> ?? * hs-precheckin-comp, hs-tier1, hs-tier2 (in progress) >>> ?? * test case from 8189172 on consistency of results >>> >>> The fix doesn't cover all possible cases (e.g., when exponent is not a >>> constant during parsing, but becomes such later). I experimented with >>> more elaborate fix, but wasn't satisfied with the results and chose >>> simpler route. >>> >>> I see 2 alternatives: >>> >>> (1) Introduce macro node PowD and either transform it into MulD if >>> exponent == 2.0D or expand it into CallLeafNode. The downside is that >>> PowD should be CallNode and replacing it with a MulD requires some IR >>> tweaking around it. >>> >>> (2) Introduce a runtime check before calling the stub (prototype [1]). >>> If exponent becomes 2.0 later, the check is folded and stub call is >>> removed. The downside is that when exponent doesn't turn into 2.0, the >>> check stays and duplicates the check in the stub. Unfortunately, there's >>> no way to remove it from the stub, because interpreter & C1 relies on >>> it. Otherwise, inconsistent computation results become possible (like >>> JDK-8189172 [2]). >>> >>> So, I decided to go with a simple fix and cover most common case >>> (explicit usage of 2.0 with Math.pow) for now. >>> >>> Best regards, >>> Vladimir Ivanov >>> >>> [1] http://cr.openjdk.java.net/~vlivanov/8190869/webrev.runtime_check >>> [2] https://bugs.openjdk.java.net/browse/JDK-8189172 From vladimir.x.ivanov at oracle.com Wed Dec 13 16:28:51 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 13 Dec 2017 19:28:51 +0300 Subject: [10] RFR (S): C2: missing strength reduction of Math.pow(x, 2.0D) to x*x In-Reply-To: References: <077d9f77-ed58-c971-7899-05968ab40f73@oracle.com> <1f305fee-22a6-e902-18dd-b8336e622f88@oracle.com> Message-ID: <26a5b58d-e6f4-005f-c091-d8632781fdeb@oracle.com> Thanks, Vladimir! Best regards, Vladimir Ivanov On 12/13/17 7:25 PM, Vladimir Kozlov wrote: > On 12/13/17 6:58 AM, Vladimir Ivanov wrote: >> Thanks for review, Vladimir. >> >>> I agree with suggested fix. What check we have before 9 and where was >>> it? >> >> It was quite complicated. There were LibraryCallKit::inline_pow() [1] >> & LibraryCallKit::finish_pow_exp() [2] with a runtime check for 2.0 >> exponent, multiple PowDs on fast paths, and a call into >> SharedRuntime::dpow on slow path. PowD had matcher rules [3] which >> produced x87-based implementation. > > Okay. > >> >>> Why do you need to move value to tmp1? >>> >>> +? movdq(tmp1, xmm1); >>> +? cmp64(tmp1, ExternalAddress(DOUBLE2)); >> >> We want to compare 64-bit values and move the exponent from XMM to GP >> register. > > Of cause, you need to use GP register to compare. I thought tmp1 also xmm. > > Looks good. > > Thanks, > Vladimir > >> >> void Assembler::movdq(Register dst, XMMRegister src) { >> void MacroAssembler::cmp64(Register src1, AddressLiteral src2) { >> >> Best regards, >> Vladimir Ivanov >> >> [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/94849fb8ce93#l22.72 >> [2] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/94849fb8ce93#l22.16 >> [3] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/94849fb8ce93#l13.7 >> >>> On 12/12/17 11:16 AM, Vladimir Ivanov wrote: >>>> http://cr.openjdk.java.net/~vlivanov/8190869/webrev.00/ >>>> https://bugs.openjdk.java.net/browse/JDK-8190869 >>>> >>>> Math.pow() was completely rewritten on 9 and important special case >>>> (exponent == 2.0) was missed. It caused severe performance regression >>>> (up to 10x) on some numeric code. >>>> >>>> The fix is two-fold: >>>> ?? * add special case in C2 to transform pow(x,2.0) into x*x; >>>> ?? * for consistency of results between different execution modes >>>> (interpreter, C1, and C2), add special case into generated stub at >>>> MacroAssembler::fast_pow(). >>>> >>>> Some clarifications follow. >>>> >>>> Testing: >>>> ?? * microbenchmark >>>> ?? * hs-precheckin-comp, hs-tier1, hs-tier2 (in progress) >>>> ?? * test case from 8189172 on consistency of results >>>> >>>> The fix doesn't cover all possible cases (e.g., when exponent is not a >>>> constant during parsing, but becomes such later). I experimented with >>>> more elaborate fix, but wasn't satisfied with the results and chose >>>> simpler route. >>>> >>>> I see 2 alternatives: >>>> >>>> (1) Introduce macro node PowD and either transform it into MulD if >>>> exponent == 2.0D or expand it into CallLeafNode. The downside is that >>>> PowD should be CallNode and replacing it with a MulD requires some IR >>>> tweaking around it. >>>> >>>> (2) Introduce a runtime check before calling the stub (prototype [1]). >>>> If exponent becomes 2.0 later, the check is folded and stub call is >>>> removed. The downside is that when exponent doesn't turn into 2.0, the >>>> check stays and duplicates the check in the stub. Unfortunately, >>>> there's >>>> no way to remove it from the stub, because interpreter & C1 relies on >>>> it. Otherwise, inconsistent computation results become possible (like >>>> JDK-8189172 [2]). >>>> >>>> So, I decided to go with a simple fix and cover most common case >>>> (explicit usage of 2.0 with Math.pow) for now. >>>> >>>> Best regards, >>>> Vladimir Ivanov >>>> >>>> [1] http://cr.openjdk.java.net/~vlivanov/8190869/webrev.runtime_check >>>> [2] https://bugs.openjdk.java.net/browse/JDK-8189172 From vladimir.kozlov at oracle.com Wed Dec 13 16:30:30 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Dec 2017 08:30:30 -0800 Subject: RFR(XL) 8193439: Update Graal In-Reply-To: <7CDA67CA-F2A5-4C6A-9CBD-0CD0D4093F78@oracle.com> References: <7CDA67CA-F2A5-4C6A-9CBD-0CD0D4093F78@oracle.com> Message-ID: <2d18d0a3-2b1e-fbe5-f600-56fe1683aa09@oracle.com> New CRC32 files need copyright year update. Otherwise looks good. Did you submit pre-integration testing? Thanks, Vladimir On 12/13/17 4:00 AM, Igor Veresov wrote: > Please check the JBS entry for the list of the changsets. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8193439 > Webrev: http://cr.openjdk.java.net/~iveresov/8193439/webrev.00/ > > Thanks, > igor > From igor.veresov at oracle.com Wed Dec 13 16:56:16 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Wed, 13 Dec 2017 08:56:16 -0800 Subject: RFR(XL) 8193439: Update Graal In-Reply-To: <2d18d0a3-2b1e-fbe5-f600-56fe1683aa09@oracle.com> References: <7CDA67CA-F2A5-4C6A-9CBD-0CD0D4093F78@oracle.com> <2d18d0a3-2b1e-fbe5-f600-56fe1683aa09@oracle.com> Message-ID: Fixed. I?ll file a separate bug to fix the copyright year upstream. The testing is in progress, added a link to the JBS entry. igor > On Dec 13, 2017, at 8:30 AM, Vladimir Kozlov wrote: > > New CRC32 files need copyright year update. Otherwise looks good. > > Did you submit pre-integration testing? > > Thanks, > Vladimir > > On 12/13/17 4:00 AM, Igor Veresov wrote: >> Please check the JBS entry for the list of the changsets. >> JBS: https://bugs.openjdk.java.net/browse/JDK-8193439 >> Webrev: http://cr.openjdk.java.net/~iveresov/8193439/webrev.00/ >> Thanks, >> igor From vladimir.kozlov at oracle.com Wed Dec 13 17:00:16 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Dec 2017 09:00:16 -0800 Subject: RFR(XL) 8193439: Update Graal In-Reply-To: References: <7CDA67CA-F2A5-4C6A-9CBD-0CD0D4093F78@oracle.com> <2d18d0a3-2b1e-fbe5-f600-56fe1683aa09@oracle.com> Message-ID: On 12/13/17 8:56 AM, Igor Veresov wrote: > Fixed. I?ll file a separate bug to fix the copyright year upstream. The testing is in progress, added a link to the JBS entry. Thank you. Vladimir > > igor > >> On Dec 13, 2017, at 8:30 AM, Vladimir Kozlov wrote: >> >> New CRC32 files need copyright year update. Otherwise looks good. >> >> Did you submit pre-integration testing? >> >> Thanks, >> Vladimir >> >> On 12/13/17 4:00 AM, Igor Veresov wrote: >>> Please check the JBS entry for the list of the changsets. >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8193439 >>> Webrev: http://cr.openjdk.java.net/~iveresov/8193439/webrev.00/ >>> Thanks, >>> igor > From vladimir.kozlov at oracle.com Wed Dec 13 17:41:19 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Dec 2017 09:41:19 -0800 Subject: RFR: 8152110: Stabilize C2 loop optimizations In-Reply-To: <534d0b4e-7f79-2b6e-9b59-d594467a79dd@oracle.com> References: <534d0b4e-7f79-2b6e-9b59-d594467a79dd@oracle.com> Message-ID: <711d0451-954d-c775-acb7-72f6217186d4@oracle.com> Thank you, Jamsheed I would like to re-target this to JDK 11. This change may affect code generation and we should be careful now for JDK 10. This problem is not new, we can fix it later. How you determine which loop optimizations should be skipped? The check for unswitching is better to do in policy_unswitching() method? Thanks, Vladimir On 12/11/17 6:43 PM, jamsheed wrote: > Hi, > > request for review > > jbs: https://bugs.openjdk.java.net/browse/JDK-8152110 > > webrev: http://cr.openjdk.java.net/~jcm/8152110/webrev.00/ > > the patch make sure that, there is no heavy loop optimizations performed > after opaque nodes removal. Only simple loop optimizations like > > converting single iteration loops to normal code/ removing empty loops > are performed after opaque node removal. > > this change is done based on discussion here [1] > > > mach5/perf report attached in jbs > > Best regards, > Jamsheed > > > [1] > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-February/021353.html > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-March/021967.html > > From dean.long at oracle.com Wed Dec 13 17:41:54 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Dec 2017 09:41:54 -0800 Subject: RFR(XS) Message-ID: https://bugs.openjdk.java.net/browse/JDK-8193323 http://cr.openjdk.java.net/~dlong/8193323/webrev JVMCI needs to skip redefined methods like C1 and C2. dl From dean.long at oracle.com Wed Dec 13 17:44:05 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Dec 2017 09:44:05 -0800 Subject: RFR(XS) 8193323: Crash in "failed dependencies, but counter didn't change" with enabled UseJVMCICompiler In-Reply-To: References: Message-ID: <5b3fda33-f1f0-b6d5-ec95-dc0fe5bb828f@oracle.com> Sorry, I forgot to fill in the subject line correctly last time. On 12/13/17 9:41 AM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8193323 > http://cr.openjdk.java.net/~dlong/8193323/webrev > > JVMCI needs to skip redefined methods like C1 and C2. > > dl From vladimir.kozlov at oracle.com Wed Dec 13 17:50:47 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Dec 2017 09:50:47 -0800 Subject: RFR(XS) 8193323: Crash in "failed dependencies, but counter didn't change" with enabled UseJVMCICompiler In-Reply-To: <5b3fda33-f1f0-b6d5-ec95-dc0fe5bb828f@oracle.com> References: <5b3fda33-f1f0-b6d5-ec95-dc0fe5bb828f@oracle.com> Message-ID: Looks good. Thanks, Vladimir On 12/13/17 9:44 AM, dean.long at oracle.com wrote: > Sorry, I forgot to fill in the subject line correctly last time. > > > On 12/13/17 9:41 AM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8193323 >> http://cr.openjdk.java.net/~dlong/8193323/webrev >> >> JVMCI needs to skip redefined methods like C1 and C2. >> >> dl > From dean.long at oracle.com Wed Dec 13 18:12:51 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Dec 2017 10:12:51 -0800 Subject: RFR(XS) 8193323: Crash in "failed dependencies, but counter didn't change" with enabled UseJVMCICompiler In-Reply-To: References: <5b3fda33-f1f0-b6d5-ec95-dc0fe5bb828f@oracle.com> Message-ID: I'm seeing some test failures that I need to investigate.? I may need to post an updated webrev. dl On 12/13/17 9:50 AM, Vladimir Kozlov wrote: > Looks good. > > Thanks, > Vladimir > > On 12/13/17 9:44 AM, dean.long at oracle.com wrote: >> Sorry, I forgot to fill in the subject line correctly last time. >> >> >> On 12/13/17 9:41 AM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8193323 >>> http://cr.openjdk.java.net/~dlong/8193323/webrev >>> >>> JVMCI needs to skip redefined methods like C1 and C2. >>> >>> dl >> From dean.long at oracle.com Wed Dec 13 18:47:37 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Dec 2017 10:47:37 -0800 Subject: RFR(XS) 8193323: Crash in "failed dependencies, but counter didn't change" with enabled UseJVMCICompiler In-Reply-To: References: <5b3fda33-f1f0-b6d5-ec95-dc0fe5bb828f@oracle.com> Message-ID: Updated webrev: http://cr.openjdk.java.net/~dlong/8193323/webrev.1/ I fixed the embarrassing typo I introduced: *** jvmciCompilerToVM.cpp??? 2017-12-13 09:18:43.000000000 -0800 --- src/hotspot/share/jvmci/jvmciCompilerToVM.cpp 2017-12-13 10:32:40.996389329 -0800 *************** *** 765,771 **** ??? if (method->is_old()) { ????? return false; ??? } !?? return method->is_not_compilable(CompLevel_full_optimization); ? C2V_END ? C2V_VMENTRY(jboolean, hasNeverInlineDirective,(JNIEnv *, jobject, jobject jvmci_method)) --- 765,771 ---- ??? if (method->is_old()) { ????? return false; ??? } !?? return !method->is_not_compilable(CompLevel_full_optimization); ? C2V_END ? C2V_VMENTRY(jboolean, hasNeverInlineDirective,(JNIEnv *, jobject, jobject jvmci_method)) Originally I had ??? return !method->is_old() && !method->is_not_compilable(CompLevel_full_optimization); but I split the condition so I could add a comment and somehow lost the "!" operator. I started a new batch of tests. dl On 12/13/17 10:12 AM, dean.long at oracle.com wrote: > I'm seeing some test failures that I need to investigate.? I may need > to post an updated webrev. > > dl > > > On 12/13/17 9:50 AM, Vladimir Kozlov wrote: >> Looks good. >> >> Thanks, >> Vladimir >> >> On 12/13/17 9:44 AM, dean.long at oracle.com wrote: >>> Sorry, I forgot to fill in the subject line correctly last time. >>> >>> >>> On 12/13/17 9:41 AM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8193323 >>>> http://cr.openjdk.java.net/~dlong/8193323/webrev >>>> >>>> JVMCI needs to skip redefined methods like C1 and C2. >>>> >>>> dl >>> > From vladimir.kozlov at oracle.com Wed Dec 13 18:49:18 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Dec 2017 10:49:18 -0800 Subject: RFR(XS) 8193323: Crash in "failed dependencies, but counter didn't change" with enabled UseJVMCICompiler In-Reply-To: References: <5b3fda33-f1f0-b6d5-ec95-dc0fe5bb828f@oracle.com> Message-ID: Okay. Vladimir On 12/13/17 10:47 AM, dean.long at oracle.com wrote: > Updated webrev: > > http://cr.openjdk.java.net/~dlong/8193323/webrev.1/ > > > I fixed the embarrassing typo I introduced: > > > *** jvmciCompilerToVM.cpp??? 2017-12-13 09:18:43.000000000 -0800 > --- src/hotspot/share/jvmci/jvmciCompilerToVM.cpp 2017-12-13 > 10:32:40.996389329 -0800 > *************** > *** 765,771 **** > ??? if (method->is_old()) { > ????? return false; > ??? } > !?? return method->is_not_compilable(CompLevel_full_optimization); > ? C2V_END > > ? C2V_VMENTRY(jboolean, hasNeverInlineDirective,(JNIEnv *, jobject, > jobject jvmci_method)) > --- 765,771 ---- > ??? if (method->is_old()) { > ????? return false; > ??? } > !?? return !method->is_not_compilable(CompLevel_full_optimization); > ? C2V_END > > ? C2V_VMENTRY(jboolean, hasNeverInlineDirective,(JNIEnv *, jobject, > jobject jvmci_method)) > > Originally I had > > ??? return !method->is_old() && > !method->is_not_compilable(CompLevel_full_optimization); > > > but I split the condition so I could add a comment and somehow lost the > "!" operator. > > I started a new batch of tests. > > dl > > On 12/13/17 10:12 AM, dean.long at oracle.com wrote: >> I'm seeing some test failures that I need to investigate.? I may need >> to post an updated webrev. >> >> dl >> >> >> On 12/13/17 9:50 AM, Vladimir Kozlov wrote: >>> Looks good. >>> >>> Thanks, >>> Vladimir >>> >>> On 12/13/17 9:44 AM, dean.long at oracle.com wrote: >>>> Sorry, I forgot to fill in the subject line correctly last time. >>>> >>>> >>>> On 12/13/17 9:41 AM, dean.long at oracle.com wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8193323 >>>>> http://cr.openjdk.java.net/~dlong/8193323/webrev >>>>> >>>>> JVMCI needs to skip redefined methods like C1 and C2. >>>>> >>>>> dl >>>> >> > From dean.long at oracle.com Wed Dec 13 18:59:16 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Dec 2017 10:59:16 -0800 Subject: RFR(XS) 8193323: Crash in "failed dependencies, but counter didn't change" with enabled UseJVMCICompiler In-Reply-To: References: <5b3fda33-f1f0-b6d5-ec95-dc0fe5bb828f@oracle.com> Message-ID: Thanks for the review, Vladimir. dl On 12/13/17 10:49 AM, Vladimir Kozlov wrote: > Okay. > > Vladimir > > On 12/13/17 10:47 AM, dean.long at oracle.com wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~dlong/8193323/webrev.1/ >> >> >> I fixed the embarrassing typo I introduced: >> >> >> *** jvmciCompilerToVM.cpp??? 2017-12-13 09:18:43.000000000 -0800 >> --- src/hotspot/share/jvmci/jvmciCompilerToVM.cpp 2017-12-13 >> 10:32:40.996389329 -0800 >> *************** >> *** 765,771 **** >> ???? if (method->is_old()) { >> ?????? return false; >> ???? } >> !?? return method->is_not_compilable(CompLevel_full_optimization); >> ?? C2V_END >> >> ?? C2V_VMENTRY(jboolean, hasNeverInlineDirective,(JNIEnv *, jobject, >> jobject jvmci_method)) >> --- 765,771 ---- >> ???? if (method->is_old()) { >> ?????? return false; >> ???? } >> !?? return !method->is_not_compilable(CompLevel_full_optimization); >> ?? C2V_END >> >> ?? C2V_VMENTRY(jboolean, hasNeverInlineDirective,(JNIEnv *, jobject, >> jobject jvmci_method)) >> >> Originally I had >> >> ???? return !method->is_old() && >> !method->is_not_compilable(CompLevel_full_optimization); >> >> >> but I split the condition so I could add a comment and somehow lost >> the "!" operator. >> >> I started a new batch of tests. >> >> dl >> >> On 12/13/17 10:12 AM, dean.long at oracle.com wrote: >>> I'm seeing some test failures that I need to investigate.? I may >>> need to post an updated webrev. >>> >>> dl >>> >>> >>> On 12/13/17 9:50 AM, Vladimir Kozlov wrote: >>>> Looks good. >>>> >>>> Thanks, >>>> Vladimir >>>> >>>> On 12/13/17 9:44 AM, dean.long at oracle.com wrote: >>>>> Sorry, I forgot to fill in the subject line correctly last time. >>>>> >>>>> >>>>> On 12/13/17 9:41 AM, dean.long at oracle.com wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8193323 >>>>>> http://cr.openjdk.java.net/~dlong/8193323/webrev >>>>>> >>>>>> JVMCI needs to skip redefined methods like C1 and C2. >>>>>> >>>>>> dl >>>>> >>> >> From dean.long at oracle.com Wed Dec 13 20:45:45 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Dec 2017 12:45:45 -0800 Subject: RFR(XS) 8191852: Null pointer dereference in ciKlass::get_Klass of ciKlass.hpp:58 Message-ID: <7601725d-93e0-ce53-f75d-633ab3284d43@oracle.com> https://bugs.openjdk.java.net/browse/JDK-8191852 http://cr.openjdk.java.net/~dlong/8191852/webrev/ Our static analysis tool was complaining about a possible null pointer dereference in ciKlass::get_Klass(), because of this code: 237.??? ? _holder = CURRENT_ENV->get_instance_klass(fd->field_holder()); [...] 240.??? ? Klass* k = _holder->get_Klass(); so I added NULL checks in get_instance_klass and a few other similar functions. dl From vladimir.kozlov at oracle.com Wed Dec 13 21:08:41 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Dec 2017 13:08:41 -0800 Subject: RFR(XS) 8191852: Null pointer dereference in ciKlass::get_Klass of ciKlass.hpp:58 In-Reply-To: <7601725d-93e0-ce53-f75d-633ab3284d43@oracle.com> References: <7601725d-93e0-ce53-f75d-633ab3284d43@oracle.com> Message-ID: On 12/13/17 12:45 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8191852 > http://cr.openjdk.java.net/~dlong/8191852/webrev/ > > Our static analysis tool was complaining about a possible null pointer > dereference in ciKlass::get_Klass(), because of this code: > > 237.??? ? _holder = CURRENT_ENV->get_instance_klass(fd->field_holder()); > [...] > 240.??? ? Klass* k = _holder->get_Klass(); > > so I added NULL checks in get_instance_klass and a few other similar > functions. No, you don't ;) You replaced NULL checks which return NULL with asserts. It is not the same. Are you sure that in all those cases we will not get NULL? Thanks, Vladimir > > dl From dean.long at oracle.com Wed Dec 13 23:09:11 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 13 Dec 2017 15:09:11 -0800 Subject: RFR(XS) 8191852: Null pointer dereference in ciKlass::get_Klass of ciKlass.hpp:58 In-Reply-To: References: <7601725d-93e0-ce53-f75d-633ab3284d43@oracle.com> Message-ID: <3e60610c-5c35-2584-115f-da4117c037ef@oracle.com> On 12/13/17 1:08 PM, Vladimir Kozlov wrote: > On 12/13/17 12:45 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8191852 >> http://cr.openjdk.java.net/~dlong/8191852/webrev/ >> >> Our static analysis tool was complaining about a possible null >> pointer dereference in ciKlass::get_Klass(), because of this code: >> >> 237.??? ? _holder = CURRENT_ENV->get_instance_klass(fd->field_holder()); >> [...] >> 240.??? ? Klass* k = _holder->get_Klass(); >> >> so I added NULL checks in get_instance_klass and a few other similar >> functions. > > No, you don't ;) Yes, you're right.? Sorry about that :-) > You replaced NULL checks which return NULL with asserts. It is not the > same. Are you sure that in all those cases we will not get NULL? It didn't show up in my testing.? But what I could try is to remove the asserts and rerun the static analysis.? Then get_instance_klass() would be: ? ciInstanceKlass* get_instance_klass(Klass* o) { ??? return get_metadata(o)->as_instance_klass(); ? } In the first example above, static analysis would need to verify that fd->field_holder() can never return NULL.? If that sounds reasonable, I'll rerun the static analysis. dl > > Thanks, > Vladimir > >> >> dl From vladimir.kozlov at oracle.com Thu Dec 14 00:20:05 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 13 Dec 2017 16:20:05 -0800 Subject: RFR(XS) 8191852: Null pointer dereference in ciKlass::get_Klass of ciKlass.hpp:58 In-Reply-To: <3e60610c-5c35-2584-115f-da4117c037ef@oracle.com> References: <7601725d-93e0-ce53-f75d-633ab3284d43@oracle.com> <3e60610c-5c35-2584-115f-da4117c037ef@oracle.com> Message-ID: <12681129-02df-59f2-8315-7462d7e92d5d@oracle.com> On 12/13/17 3:09 PM, dean.long at oracle.com wrote: > On 12/13/17 1:08 PM, Vladimir Kozlov wrote: > >> On 12/13/17 12:45 PM, dean.long at oracle.com wrote: >>> https://bugs.openjdk.java.net/browse/JDK-8191852 >>> http://cr.openjdk.java.net/~dlong/8191852/webrev/ >>> >>> Our static analysis tool was complaining about a possible null >>> pointer dereference in ciKlass::get_Klass(), because of this code: >>> >>> 237.??? ? _holder = CURRENT_ENV->get_instance_klass(fd->field_holder()); >>> [...] >>> 240.??? ? Klass* k = _holder->get_Klass(); >>> >>> so I added NULL checks in get_instance_klass and a few other similar >>> functions. >> >> No, you don't ;) > > Yes, you're right.? Sorry about that :-) > >> You replaced NULL checks which return NULL with asserts. It is not the >> same. Are you sure that in all those cases we will not get NULL? > > It didn't show up in my testing.? But what I could try is to remove the > asserts and rerun the static analysis.? Then get_instance_klass() would be: > > ? ciInstanceKlass* get_instance_klass(Klass* o) { > ??? return get_metadata(o)->as_instance_klass(); > ? } > > In the first example above, static analysis would need to verify that > fd->field_holder() can never return NULL.? If that sounds reasonable, > I'll rerun the static analysis. Yes, it is reasonable. Thanks, Vladimir > > dl > >> >> Thanks, >> Vladimir >> >>> >>> dl > From xueming.shen at oracle.com Thu Dec 14 02:05:22 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 13 Dec 2017 18:05:22 -0800 Subject: RFR JDK-8193479: test/hotspot/jtreg/compiler/codegen/Test6896617.java fails after JDK-8184947 In-Reply-To: References: <5A31BF65.8090808@oracle.com> Message-ID: <5A31DC62.60802@oracle.com> David, Martin, webrev has been updated to fix the test directly. http://cr.openjdk.java.net/~sherman/8193479/webrev Assume I would need hotspot guys' help to review and push into hs repo? thanks, Sherman On 12/13/17, 4:52 PM, Martin Buchholz wrote: > It would add more confusion to a something that's already difficult to > understand. It's OK as a temporary measure, but I don't think we want > product code just to enable tests in hotspot. Can the hotspot folks > modify their test, perhaps making this code part of the test? > > On Wed, Dec 13, 2017 at 4:01 PM, Xueming Shen > wrote: > > Hi > > Please help review the change for JDK-8193479 > > issue: https://bugs.openjdk.java.net/browse/JDK-8193479 > > webrev: http://cr.openjdk.java.net/~sherman/8193479/webrev > > > The internal interface ArrayEn/Decoder for ISO8859_1 has been removed > because it is no longer used by StringCoding class, but it appears > it is > being used by hotspot Test6896617.java to verify the SSE instructions > on x86. The proposed change here is to simply restore the internal > interface > ArrayEn/Decoder for ISO8859_1 to avoid blocking hotspot testing > for now. > > thanks, > Sherman > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Thu Dec 14 02:52:17 2017 From: david.holmes at oracle.com (David Holmes) Date: Thu, 14 Dec 2017 12:52:17 +1000 Subject: RFR JDK-8193479: test/hotspot/jtreg/compiler/codegen/Test6896617.java fails after JDK-8184947 In-Reply-To: <5A31DC62.60802@oracle.com> References: <5A31BF65.8090808@oracle.com> <5A31DC62.60802@oracle.com> Message-ID: <0f744ab5-f419-de05-171e-1110ebc886a4@oracle.com> Hi Sherman, On 14/12/2017 12:05 PM, Xueming Shen wrote: > David, Martin, > > webrev has been updated to fix the test directly. > > http://cr.openjdk.java.net/~sherman/8193479/webrev That seems to me to be invalidating the whole point of the test, which was a regression test for 6896617 to check that the optimizations put in place actually get applied. ?? But I'll leave that up to the compiler guys to decide. > Assume I would need hotspot guys' help to review and push into hs repo? You'll need to fix in both jdk/hs and jdk/jdk as the breakage is now in both. Fix one and import to the other. But I still suggest adding the test to ProblemList.txt now so that this isn't broken in JDK 10 fork, then fix the actual test at a more leisurely pace in jdk/hs. But again I'll defer to compiler folk. David > thanks, > Sherman > > > On 12/13/17, 4:52 PM, Martin Buchholz wrote: >> It would add more confusion to a something that's already difficult to >> understand.? It's OK as a temporary measure, but I don't think we want >> product code just to enable tests in hotspot.? Can the hotspot folks >> modify their test, perhaps making this code part of the test? >> >> On Wed, Dec 13, 2017 at 4:01 PM, Xueming Shen > > wrote: >> >> Hi >> >> Please help review the change for JDK-8193479 >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8193479 >> >> webrev: http://cr.openjdk.java.net/~sherman/8193479/webrev >> >> >> The internal interface ArrayEn/Decoder for ISO8859_1 has been removed >> because it is no longer used by StringCoding class, but it appears >> it is >> being used by hotspot Test6896617.java to verify the SSE instructions >> on x86. The proposed change here is to simply restore the internal >> interface >> ArrayEn/Decoder for ISO8859_1 to avoid blocking hotspot testing >> for now. >> >> thanks, >> Sherman >> >> >> > From vivek.r.deshpande at intel.com Thu Dec 14 07:22:58 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 14 Dec 2017 07:22:58 +0000 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> Hi Vladimir I have a fix for the slowdown observed on haswell due to jdk-8178811. The solution selectively generates vzeroupper when AVX2/ AVX512 instructions have been executed and before the transition to SSE code. I tested this fix with the test case given with bug and SPECjbb2015. Could you please review and sponsor the patch? Webrev: http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ I have also updated the bug: https://bugs.openjdk.java.net/browse/JDK-8190934 Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.backman at oracle.com Thu Dec 14 07:30:04 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Thu, 14 Dec 2017 08:30:04 +0100 Subject: RFR (XS): 8191915: JCK tests produce incorrect results with C2 Message-ID: <20171214073004.GA16523@rbackman> Hi, can I please have this change reviewed? Summary is that we had an overflow check for mulitplyExact(long, long) intrinsic that relied on undefined behaviour. clang / llvm started optimizing that so that if a = b * c then a / b must be equal to c and removed half of the overflow check. Changing the multiplication and division to be unsigned. Webrev: http://cr.openjdk.java.net/~rbackman/8191915/ Bug: https://bugs.openjdk.java.net/browse/JDK-8191915 Thanks /R From goetz.lindenmaier at sap.com Thu Dec 14 07:34:36 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Dec 2017 07:34:36 +0000 Subject: RFR(XS) In-Reply-To: References: Message-ID: Hi Dean, this looks as if you negated isCompilable(). Why did you remove the '!' from the return value? The rest is fine. Best regards Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of dean.long at oracle.com > Sent: Mittwoch, 13. Dezember 2017 18:42 > To: hotspot-compiler-dev at openjdk.java.net compiler dev at openjdk.java.net> > Subject: RFR(XS) > > https://bugs.openjdk.java.net/browse/JDK-8193323 > http://cr.openjdk.java.net/~dlong/8193323/webrev > > JVMCI needs to skip redefined methods like C1 and C2. > > dl From tobias.hartmann at oracle.com Thu Dec 14 09:11:48 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Dec 2017 10:11:48 +0100 Subject: RFR (XS): 8191915: JCK tests produce incorrect results with C2 In-Reply-To: <20171214073004.GA16523@rbackman> References: <20171214073004.GA16523@rbackman> Message-ID: <688c9a41-6250-140c-df39-4ec5a6ceff4c@oracle.com> Hi Rickard, I don't understand why casting from signed to unsigned is correct here because if there's an overflow of the signed range, there is not necessarily and overflow of the unsigned range, right? For example, this program: signed long long sv1 = LONG_MAX/2 + 1; signed long long sv2 = 2; signed long long sR = sv1 * sv2; printf("%li\n", sR); unsigned long long uv1 = (unsigned long long) sv1; unsigned long long uv2 = (unsigned long long) sv2; unsigned long long uR = uv1 * uv2; printf("%lu\n", uR); if (uR / uv1 != uv2) { printf("Overflow detected"); } else { printf("No overflow detected"); } Output: -9223372036854775808 9223372036854775808 No overflow detected So there is an overflow of the signed long but the unsigned long does not overflow and thus an overflow is not detected. Do I miss something? Regarding the jtreg test: Please do not use bug numbers as test names but use something more meaningful like TestLongMulOverflow or similar. I would also suggest to move the allocation of the test instance out of the loop and check if 500.000 iterations are really necessary to trigger compilation (you can run with -Xbatch and maybe -XX:-TieredCompilation). Best regards, Tobias On 14.12.2017 08:30, Rickard B?ckman wrote: > Hi, can I please have this change reviewed? > > Summary is that we had an overflow check for mulitplyExact(long, long) > intrinsic that relied on undefined behaviour. clang / llvm started > optimizing that so that if a = b * c then a / b must be equal to c and > removed half of the overflow check. > > Changing the multiplication and division to be unsigned. > > Webrev: http://cr.openjdk.java.net/~rbackman/8191915/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8191915 > > Thanks > /R > From goetz.lindenmaier at sap.com Thu Dec 14 09:30:41 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 14 Dec 2017 09:30:41 +0000 Subject: RFR(S): 8193443: [s390]: EncodeISOArray generates wrong vector code In-Reply-To: References: Message-ID: <93fe6d86121a4e55ab1b3ddd8551e3af@sap.com> Hi Lutz, change looks good. (Had to search a bit to find the essential change :)) If you want to get it into jdk10, you should push this to jdk/jdk today. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Mittwoch, 13. Dezember 2017 17:17 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(S): 8193443: [s390]: EncodeISOArray generates wrong vector > code > > Dear all, > > > > I would like to request reviews for this s390-only bux fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193443 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8193443.00/index.html > > > > The condition code setting from vector compare instructions differs slightly > from that of scalar instructions. Distinct condition code enum values were > introduced, related conditional branch aliases were defined and, of course, > the buggy code was fixed. > > > > The previously failing jtreg tests now pass. > > > > I would very much appreciate if this fix would make it into Java 10. > > > > Thank you! > > Lutz > > From rickard.backman at oracle.com Thu Dec 14 10:54:43 2017 From: rickard.backman at oracle.com (Rickard =?iso-8859-1?Q?B=E4ckman?=) Date: Thu, 14 Dec 2017 11:54:43 +0100 Subject: RFR (XS): 8191915: JCK tests produce incorrect results with C2 In-Reply-To: <688c9a41-6250-140c-df39-4ec5a6ceff4c@oracle.com> References: <20171214073004.GA16523@rbackman> <688c9a41-6250-140c-df39-4ec5a6ceff4c@oracle.com> Message-ID: <20171214105443.GB16523@rbackman> Yes you are right, it doesn't work for all values. Seems to work for negatives though? However casting the result back to signed after doing the multiplication and doing the division with the signed values get us back to getting the overflow check correct and no undefined behaviour as far as I can tell? /R On 12/14, Tobias Hartmann wrote: > Hi Rickard, > > I don't understand why casting from signed to unsigned is correct here because if there's an overflow of the signed > range, there is not necessarily and overflow of the unsigned range, right? > > For example, this program: > > signed long long sv1 = LONG_MAX/2 + 1; > signed long long sv2 = 2; > signed long long sR = sv1 * sv2; > printf("%li\n", sR); > > unsigned long long uv1 = (unsigned long long) sv1; > unsigned long long uv2 = (unsigned long long) sv2; > unsigned long long uR = uv1 * uv2; > printf("%lu\n", uR); > > if (uR / uv1 != uv2) { > printf("Overflow detected"); > } else { > printf("No overflow detected"); > } > > Output: > > -9223372036854775808 > 9223372036854775808 > No overflow detected > > So there is an overflow of the signed long but the unsigned long does not overflow and thus an overflow is not detected. > Do I miss something? > > Regarding the jtreg test: Please do not use bug numbers as test names but use something more meaningful like > TestLongMulOverflow or similar. I would also suggest to move the allocation of the test instance out of the loop and > check if 500.000 iterations are really necessary to trigger compilation (you can run with -Xbatch and maybe > -XX:-TieredCompilation). > > Best regards, > Tobias > > On 14.12.2017 08:30, Rickard B?ckman wrote: > > Hi, can I please have this change reviewed? > > > > Summary is that we had an overflow check for mulitplyExact(long, long) > > intrinsic that relied on undefined behaviour. clang / llvm started > > optimizing that so that if a = b * c then a / b must be equal to c and > > removed half of the overflow check. > > > > Changing the multiplication and division to be unsigned. > > > > Webrev: http://cr.openjdk.java.net/~rbackman/8191915/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191915 > > > > Thanks > > /R > > From martin.doerr at sap.com Thu Dec 14 11:07:19 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 14 Dec 2017 11:07:19 +0000 Subject: RFR(S): 8193443: [s390]: EncodeISOArray generates wrong vector code In-Reply-To: <93fe6d86121a4e55ab1b3ddd8551e3af@sap.com> References: <93fe6d86121a4e55ab1b3ddd8551e3af@sap.com> Message-ID: <497abc5fd56140c7a880c548bc7cef97@sap.com> Hi Lutz, reviewed and pushed to jdk/jdk. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Donnerstag, 14. Dezember 2017 10:31 To: Schmidt, Lutz ; hotspot-compiler-dev at openjdk.java.net Subject: RE: RFR(S): 8193443: [s390]: EncodeISOArray generates wrong vector code Hi Lutz, change looks good. (Had to search a bit to find the essential change :)) If you want to get it into jdk10, you should push this to jdk/jdk today. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Mittwoch, 13. Dezember 2017 17:17 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(S): 8193443: [s390]: EncodeISOArray generates wrong vector > code > > Dear all, > > > > I would like to request reviews for this s390-only bux fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193443 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8193443.00/index.html > > > > The condition code setting from vector compare instructions differs slightly > from that of scalar instructions. Distinct condition code enum values were > introduced, related conditional branch aliases were defined and, of course, > the buggy code was fixed. > > > > The previously failing jtreg tests now pass. > > > > I would very much appreciate if this fix would make it into Java 10. > > > > Thank you! > > Lutz > > From lutz.schmidt at sap.com Thu Dec 14 11:09:10 2017 From: lutz.schmidt at sap.com (Schmidt, Lutz) Date: Thu, 14 Dec 2017 11:09:10 +0000 Subject: RFR(S): 8193443: [s390]: EncodeISOArray generates wrong vector code In-Reply-To: <497abc5fd56140c7a880c548bc7cef97@sap.com> References: <93fe6d86121a4e55ab1b3ddd8551e3af@sap.com> <497abc5fd56140c7a880c548bc7cef97@sap.com> Message-ID: Thank you, Goetz and Martin! That?s what I call ?no unnecessary delay?. Regards, Lutz On 14.12.2017, 12:07, "Doerr, Martin" wrote: Hi Lutz, reviewed and pushed to jdk/jdk. Best regards, Martin -----Original Message----- From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Lindenmaier, Goetz Sent: Donnerstag, 14. Dezember 2017 10:31 To: Schmidt, Lutz ; hotspot-compiler-dev at openjdk.java.net Subject: RE: RFR(S): 8193443: [s390]: EncodeISOArray generates wrong vector code Hi Lutz, change looks good. (Had to search a bit to find the essential change :)) If you want to get it into jdk10, you should push this to jdk/jdk today. Best regards, Goetz. > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Schmidt, Lutz > Sent: Mittwoch, 13. Dezember 2017 17:17 > To: hotspot-compiler-dev at openjdk.java.net > Subject: RFR(S): 8193443: [s390]: EncodeISOArray generates wrong vector > code > > Dear all, > > > > I would like to request reviews for this s390-only bux fix: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8193443 > > Webrev: http://cr.openjdk.java.net/~lucy/webrevs/8193443.00/index.html > > > > The condition code setting from vector compare instructions differs slightly > from that of scalar instructions. Distinct condition code enum values were > introduced, related conditional branch aliases were defined and, of course, > the buggy code was fixed. > > > > The previously failing jtreg tests now pass. > > > > I would very much appreciate if this fix would make it into Java 10. > > > > Thank you! > > Lutz > > From tobias.hartmann at oracle.com Thu Dec 14 11:26:00 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Dec 2017 12:26:00 +0100 Subject: RFR (XS): 8191915: JCK tests produce incorrect results with C2 In-Reply-To: <20171214105443.GB16523@rbackman> References: <20171214073004.GA16523@rbackman> <688c9a41-6250-140c-df39-4ec5a6ceff4c@oracle.com> <20171214105443.GB16523@rbackman> Message-ID: <3597dd75-d290-428c-741f-eb6b1b5e5938@oracle.com> On 14.12.2017 11:54, Rickard B?ckman wrote: > Yes you are right, it doesn't work for all values. Seems to work for > negatives though? I think for negative values this does not work at all. If you set sv1 = -5 in my example code, you get: -10 18446744073709551606 Overflow detected Because we cast a negative value to unsigned. > However casting the result back to signed after doing the multiplication > and doing the division with the signed values get us back to getting the > overflow check correct and no undefined behaviour as far as I can tell? Yes, that seems to work. The best solution would be to use the corresponding compiler build-in functions (for example, __builtin_smulll_overflow for gcc [1]) but I guess not all compilers support that. Best regards, Tobias [1] https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html > On 12/14, Tobias Hartmann wrote: >> Hi Rickard, >> >> I don't understand why casting from signed to unsigned is correct here because if there's an overflow of the signed >> range, there is not necessarily and overflow of the unsigned range, right? >> >> For example, this program: >> >> signed long long sv1 = LONG_MAX/2 + 1; >> signed long long sv2 = 2; >> signed long long sR = sv1 * sv2; >> printf("%li\n", sR); >> >> unsigned long long uv1 = (unsigned long long) sv1; >> unsigned long long uv2 = (unsigned long long) sv2; >> unsigned long long uR = uv1 * uv2; >> printf("%lu\n", uR); >> >> if (uR / uv1 != uv2) { >> printf("Overflow detected"); >> } else { >> printf("No overflow detected"); >> } >> >> Output: >> >> -9223372036854775808 >> 9223372036854775808 >> No overflow detected >> >> So there is an overflow of the signed long but the unsigned long does not overflow and thus an overflow is not detected. >> Do I miss something? >> >> Regarding the jtreg test: Please do not use bug numbers as test names but use something more meaningful like >> TestLongMulOverflow or similar. I would also suggest to move the allocation of the test instance out of the loop and >> check if 500.000 iterations are really necessary to trigger compilation (you can run with -Xbatch and maybe >> -XX:-TieredCompilation). >> >> Best regards, >> Tobias >> >> On 14.12.2017 08:30, Rickard B?ckman wrote: >>> Hi, can I please have this change reviewed? >>> >>> Summary is that we had an overflow check for mulitplyExact(long, long) >>> intrinsic that relied on undefined behaviour. clang / llvm started >>> optimizing that so that if a = b * c then a / b must be equal to c and >>> removed half of the overflow check. >>> >>> Changing the multiplication and division to be unsigned. >>> >>> Webrev: http://cr.openjdk.java.net/~rbackman/8191915/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191915 >>> >>> Thanks >>> /R >>> From nils.eliasson at oracle.com Thu Dec 14 12:00:59 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 14 Dec 2017 13:00:59 +0100 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> Message-ID: <508a6aaa-218a-f658-1cb4-75d65167a89e@oracle.com> Hi Vivek, I have started regular testing of your patch. Hopefully the testing will be complete when Vladimir comes online. Regards, Nils On 2017-12-14 08:22, Deshpande, Vivek R wrote: > > Hi Vladimir > > I have a fix for the slowdown observed on haswell due to jdk-8178811. > > The solution selectively generates vzeroupper when AVX2/ AVX512 > instructions have been executed and before the transition to SSE code. > > I tested this fix with the test case given with bug and SPECjbb2015. > > Could you please review and sponsor the patch? > > Webrev: > > http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ > > > I have also updated the bug: > https://bugs.openjdk.java.net/browse/JDK-8190934 > > > Regards, > > Vivek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From claes.redestad at oracle.com Thu Dec 14 13:50:12 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 14 Dec 2017 14:50:12 +0100 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 In-Reply-To: <508a6aaa-218a-f658-1cb4-75d65167a89e@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> <508a6aaa-218a-f658-1cb4-75d65167a89e@oracle.com> Message-ID: <09bd8e6d-c5b4-1943-50b9-9152b3488bd7@oracle.com> Hi, not a review, but I've verified that this resolves a number of regressions we've seen in various microbenchmarks. Thanks! /Claes On 2017-12-14 13:00, Nils Eliasson wrote: > > Hi Vivek, > > I have started regular testing of your patch. Hopefully the testing > will be complete when Vladimir comes online. > > Regards, > > Nils > > > On 2017-12-14 08:22, Deshpande, Vivek R wrote: >> >> Hi Vladimir >> >> I have a fix for the slowdown observed on haswell due to jdk-8178811. >> >> The solution selectively generates vzeroupper when AVX2/ AVX512 >> instructions have been executed and before the transition to SSE code. >> >> I tested this fix with the test case given with bug and SPECjbb2015. >> >> Could you please review and sponsor the patch? >> >> Webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ >> >> >> I have also updated the bug: >> https://bugs.openjdk.java.net/browse/JDK-8190934 >> >> >> Regards, >> >> Vivek >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rwestrel at redhat.com Thu Dec 14 16:00:10 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 14 Dec 2017 17:00:10 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint Message-ID: http://cr.openjdk.java.net/~roland/8193518/webrev.00/ If a method has several vectorized loops, the logic that keep tracks of Compile::_max_vector_size sets it to the max vector size of the last loop (and not to the max vector size of all loops). Compile::_max_vector_size is then used to mark nmethods that need vector registers to be saved on a safepoint. If the last loop uses small vectors but other loops in the method use large vectors, registers are not saved correctly at a safepoint in one of the other loops and can be corrupted. The test case only fails with Serial GC AFAICT but I saw that failure with G1 running some other applications. Roland. From nils.eliasson at oracle.com Thu Dec 14 16:09:06 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 14 Dec 2017 17:09:06 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: References: Message-ID: Hi Roland, Thanks for finding this bug! You need to initalize _max_vector_size in Compile::init. // Nils On 2017-12-14 17:00, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8193518/webrev.00/ > > If a method has several vectorized loops, the logic that keep tracks of > Compile::_max_vector_size sets it to the max vector size of the last > loop (and not to the max vector size of all > loops). Compile::_max_vector_size is then used to mark nmethods that > need vector registers to be saved on a safepoint. If the last loop uses > small vectors but other loops in the method use large vectors, registers > are not saved correctly at a safepoint in one of the other loops and can > be corrupted. > > The test case only fails with Serial GC AFAICT but I saw that failure > with G1 running some other applications. > > Roland. From rwestrel at redhat.com Thu Dec 14 16:22:11 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 14 Dec 2017 17:22:11 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: References: Message-ID: Hi Nils, Thanks for taking a look at this... > You need to initalize _max_vector_size in Compile::init. ...and verifying something I didn't. There's a: set_max_vector_size(0); in Compile::Init() so it should be all good. Roland. From nils.eliasson at oracle.com Thu Dec 14 16:15:47 2017 From: nils.eliasson at oracle.com (Nils Eliasson) Date: Thu, 14 Dec 2017 08:15:47 -0800 (PST) Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint Message-ID: Sorry, I was fast and wrong. Looks good, Thanks for fixing Roland, //Nils ----- Original Message ----- From: nils.eliasson at oracle.com To: hotspot-compiler-dev at openjdk.java.net Sent: Thursday, December 14, 2017 5:12:39 PM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna Subject: Re: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint Hi Roland, Thanks for finding this bug! You need to initalize _max_vector_size in Compile::init. // Nils On 2017-12-14 17:00, Roland Westrelin wrote: > http://cr.openjdk.java.net/~roland/8193518/webrev.00/ > > If a method has several vectorized loops, the logic that keep tracks of > Compile::_max_vector_size sets it to the max vector size of the last > loop (and not to the max vector size of all > loops). Compile::_max_vector_size is then used to mark nmethods that > need vector registers to be saved on a safepoint. If the last loop uses > small vectors but other loops in the method use large vectors, registers > are not saved correctly at a safepoint in one of the other loops and can > be corrupted. > > The test case only fails with Serial GC AFAICT but I saw that failure > with G1 running some other applications. > > Roland. From tobias.hartmann at oracle.com Thu Dec 14 16:28:29 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Dec 2017 17:28:29 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: References: Message-ID: <3dcf37cf-9f23-08aa-219c-fc5af4fbccfa@oracle.com> Hi Roland, looks good to me too. Best regards, Tobias On 14.12.2017 17:00, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8193518/webrev.00/ > > If a method has several vectorized loops, the logic that keep tracks of > Compile::_max_vector_size sets it to the max vector size of the last > loop (and not to the max vector size of all > loops). Compile::_max_vector_size is then used to mark nmethods that > need vector registers to be saved on a safepoint. If the last loop uses > small vectors but other loops in the method use large vectors, registers > are not saved correctly at a safepoint in one of the other loops and can > be corrupted. > > The test case only fails with Serial GC AFAICT but I saw that failure > with G1 running some other applications. > > Roland. > From vladimir.kozlov at oracle.com Thu Dec 14 16:30:33 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Dec 2017 08:30:33 -0800 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: References: Message-ID: <091589cd-8bd0-c1dc-f8ec-cba95633f420@oracle.com> Nice find. Looks good. Why you changed type to uint? Thanks, Vladimir On 12/14/17 8:00 AM, Roland Westrelin wrote: > > http://cr.openjdk.java.net/~roland/8193518/webrev.00/ > > If a method has several vectorized loops, the logic that keep tracks of > Compile::_max_vector_size sets it to the max vector size of the last > loop (and not to the max vector size of all > loops). Compile::_max_vector_size is then used to mark nmethods that > need vector registers to be saved on a safepoint. If the last loop uses > small vectors but other loops in the method use large vectors, registers > are not saved correctly at a safepoint in one of the other loops and can > be corrupted. > > The test case only fails with Serial GC AFAICT but I saw that failure > with G1 running some other applications. > > Roland. > From rwestrel at redhat.com Thu Dec 14 16:33:36 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 14 Dec 2017 17:33:36 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: <091589cd-8bd0-c1dc-f8ec-cba95633f420@oracle.com> References: <091589cd-8bd0-c1dc-f8ec-cba95633f420@oracle.com> Message-ID: > Nice find. Looks good. Why you changed type to uint? Thanks for the review. gcc complains that the new comparison I added in superword.cpp is signed vs unsigned and it seems natural that _max_vector_size be unsigned. Roland. From rwestrel at redhat.com Thu Dec 14 16:33:52 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Thu, 14 Dec 2017 17:33:52 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: <3dcf37cf-9f23-08aa-219c-fc5af4fbccfa@oracle.com> References: <3dcf37cf-9f23-08aa-219c-fc5af4fbccfa@oracle.com> Message-ID: Thanks for the review, Tobias. Roland. From tobias.hartmann at oracle.com Thu Dec 14 16:41:06 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Thu, 14 Dec 2017 17:41:06 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: References: <091589cd-8bd0-c1dc-f8ec-cba95633f420@oracle.com> Message-ID: On 14.12.2017 17:37, Vladimir Kozlov wrote: > Tobias, please, sponsor it (test and push). Sure, I'll do so. Best regards, Tobias From vladimir.kozlov at oracle.com Thu Dec 14 16:37:26 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Dec 2017 08:37:26 -0800 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: References: <091589cd-8bd0-c1dc-f8ec-cba95633f420@oracle.com> Message-ID: Got it. Thanks. Tobias, please, sponsor it (test and push). Vladimir On 12/14/17 8:33 AM, Roland Westrelin wrote: > >> Nice find. Looks good. Why you changed type to uint? > > Thanks for the review. > > gcc complains that the new comparison I added in superword.cpp is signed > vs unsigned and it seems natural that _max_vector_size be unsigned. > > Roland. > From vladimir.kozlov at oracle.com Thu Dec 14 17:58:53 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Dec 2017 09:58:53 -0800 Subject: RFR JDK-8193479: test/hotspot/jtreg/compiler/codegen/Test6896617.java fails after JDK-8184947 In-Reply-To: <0f744ab5-f419-de05-171e-1110ebc886a4@oracle.com> References: <5A31BF65.8090808@oracle.com> <5A31DC62.60802@oracle.com> <0f744ab5-f419-de05-171e-1110ebc886a4@oracle.com> Message-ID: <055440af-39eb-38e6-bd9f-41102868dbe8@oracle.com> On 12/13/17 6:52 PM, David Holmes wrote: > Hi Sherman, > > On 14/12/2017 12:05 PM, Xueming Shen wrote: >> David, Martin, >> >> webrev has been updated to fix the test directly. >> >> http://cr.openjdk.java.net/~sherman/8193479/webrev > > That seems to me to be invalidating the whole point of the test, which > was a regression test for 6896617 to check that the optimizations put in > place actually get applied. ?? > > But I'll leave that up to the compiler guys to decide. > >> Assume I would need hotspot guys' help to review and push into hs repo? > > You'll need to fix in both jdk/hs and jdk/jdk as the breakage is now in > both. Fix one and import to the other. > > But I still suggest adding the test to ProblemList.txt now so that this > isn't broken in JDK 10 fork, then fix the actual test at a more > leisurely pace in jdk/hs. I agree with David. Lets exclude it for now and fix it later properly without rush. Thanks Vladimir > > But again I'll defer to compiler folk. > > David > >> thanks, >> Sherman >> >> >> On 12/13/17, 4:52 PM, Martin Buchholz wrote: >>> It would add more confusion to a something that's already difficult >>> to understand.? It's OK as a temporary measure, but I don't think we >>> want product code just to enable tests in hotspot.? Can the hotspot >>> folks modify their test, perhaps making this code part of the test? >>> >>> On Wed, Dec 13, 2017 at 4:01 PM, Xueming Shen >>> > wrote: >>> >>> ??? Hi >>> >>> ??? Please help review the change for JDK-8193479 >>> >>> ??? issue: https://bugs.openjdk.java.net/browse/JDK-8193479 >>> ??? >>> ??? webrev: http://cr.openjdk.java.net/~sherman/8193479/webrev >>> ??? >>> >>> ??? The internal interface ArrayEn/Decoder for ISO8859_1 has been >>> removed >>> ??? because it is no longer used by StringCoding class, but it appears >>> ??? it is >>> ??? being used by hotspot Test6896617.java to verify the SSE >>> instructions >>> ??? on x86. The proposed change here is to simply restore the internal >>> ??? interface >>> ??? ArrayEn/Decoder for ISO8859_1 to avoid blocking hotspot testing >>> ??? for now. >>> >>> ??? thanks, >>> ??? Sherman >>> >>> >>> >> From vivek.r.deshpande at intel.com Thu Dec 14 18:19:41 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 14 Dec 2017 18:19:41 +0000 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 In-Reply-To: <09bd8e6d-c5b4-1943-50b9-9152b3488bd7@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> <508a6aaa-218a-f658-1cb4-75d65167a89e@oracle.com> <09bd8e6d-c5b4-1943-50b9-9152b3488bd7@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771E3263@ORSMSX106.amr.corp.intel.com> Thanks Claes for conforming! Also thanks to Nils for starting the testing right away. Regards, Vivek From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Claes Redestad Sent: Thursday, December 14, 2017 5:50 AM To: hotspot-compiler-dev at openjdk.java.net Subject: Re: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 Hi, not a review, but I've verified that this resolves a number of regressions we've seen in various microbenchmarks. Thanks! /Claes On 2017-12-14 13:00, Nils Eliasson wrote: Hi Vivek, I have started regular testing of your patch. Hopefully the testing will be complete when Vladimir comes online. Regards, Nils On 2017-12-14 08:22, Deshpande, Vivek R wrote: Hi Vladimir I have a fix for the slowdown observed on haswell due to jdk-8178811. The solution selectively generates vzeroupper when AVX2/ AVX512 instructions have been executed and before the transition to SSE code. I tested this fix with the test case given with bug and SPECjbb2015. Could you please review and sponsor the patch? Webrev: http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ I have also updated the bug: https://bugs.openjdk.java.net/browse/JDK-8190934 Regards, Vivek -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.kozlov at oracle.com Thu Dec 14 18:32:53 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Dec 2017 10:32:53 -0800 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> Message-ID: <4f61211e-01ef-6cd3-4a2f-e4c32e3f491f@oracle.com> Thank you, Vivek 1. You don't need new INCLUDE_CLEAR_UPPER_AVX. The main issue is UseAVX flag is defined only on x86. You can use #ifdef X86 for that. 2. You don't need next guard +#if INCLUDE_CLEAR_UPPER_AVX + clear_upper_avx(); +#endif if you define empty body in else case (using #ifdef X86): + void clear_upper_avx() { +#ifdef X86 + if (UseAVX >= 2) { + C->set_clear_upper_avx(true); + } +#endif + } 3. Factor next checks into one static method (similar to clear_avx_size()) to avoid next repetitive checks in .ad file: (C->max_vector_size() > 16 || C->clear_upper_avx() == true) 4. remove unrelated change (empty line removed) in macroAssembler_x86.cpp Thanks, Vladimir On 12/13/17 11:22 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have a fix for the slowdown observed on haswell due to jdk-8178811. > > The solution selectively generates vzeroupper when AVX2/ AVX512 > instructions have been executed and before the transition to SSE code. > > I tested this fix with the test case given with bug and SPECjbb2015. > > Could you please review and sponsor the patch? > > Webrev: > > http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ > > I have also updated the bug: > https://bugs.openjdk.java.net/browse/JDK-8190934 > > Regards, > > Vivek > From vladimir.kozlov at oracle.com Thu Dec 14 18:43:32 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Dec 2017 10:43:32 -0800 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 In-Reply-To: <4f61211e-01ef-6cd3-4a2f-e4c32e3f491f@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> <4f61211e-01ef-6cd3-4a2f-e4c32e3f491f@oracle.com> Message-ID: <6e670133-ff57-a83b-4483-fd5a50aba433@oracle.com> Note, my suggesting changes don't affect performance and other testing results. They are still valid because these changes are only refactoring. Thanks, Vladimir On 12/14/17 10:32 AM, Vladimir Kozlov wrote: > Thank you, Vivek > > 1. You don't need new INCLUDE_CLEAR_UPPER_AVX. The main issue is UseAVX > flag is defined only on x86. You can use #ifdef X86 for that. > > 2. You don't need next guard > > +#if INCLUDE_CLEAR_UPPER_AVX > +? clear_upper_avx(); > +#endif > > if you define empty body in else case (using #ifdef X86): > > +? void clear_upper_avx() { > +#ifdef X86 > +??? if (UseAVX >= 2) { > +????? C->set_clear_upper_avx(true); > +??? } > +#endif > +? } > > 3. Factor next checks into one static method (similar to > clear_avx_size()) to avoid next repetitive checks in .ad file: > > (C->max_vector_size() > 16 || C->clear_upper_avx() == true) > > 4. remove unrelated change (empty line removed) in macroAssembler_x86.cpp > > Thanks, > Vladimir > > On 12/13/17 11:22 PM, Deshpande, Vivek R wrote: >> Hi Vladimir >> >> I have a fix for the slowdown observed on haswell due to jdk-8178811. >> >> The solution selectively generates vzeroupper when AVX2/ AVX512 >> instructions have been executed and before the transition to SSE code. >> >> I tested this fix with the test case given with bug and SPECjbb2015. >> >> Could you please review and sponsor the patch? >> >> Webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ >> >> I have also updated the bug: >> https://bugs.openjdk.java.net/browse/JDK-8190934 >> >> Regards, >> >> Vivek >> From xueming.shen at oracle.com Thu Dec 14 20:46:52 2017 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 14 Dec 2017 12:46:52 -0800 Subject: RFR JDK-8193479: test/hotspot/jtreg/compiler/codegen/Test6896617.java fails after JDK-8184947 In-Reply-To: <055440af-39eb-38e6-bd9f-41102868dbe8@oracle.com> References: <5A31BF65.8090808@oracle.com> <5A31DC62.60802@oracle.com> <0f744ab5-f419-de05-171e-1110ebc886a4@oracle.com> <055440af-39eb-38e6-bd9f-41102868dbe8@oracle.com> Message-ID: <5A32E33C.7070904@oracle.com> On 12/14/17, 9:58 AM, Vladimir Kozlov wrote: > On 12/13/17 6:52 PM, David Holmes wrote: >> Hi Sherman, >> >> On 14/12/2017 12:05 PM, Xueming Shen wrote: >>> David, Martin, >>> >>> webrev has been updated to fix the test directly. >>> >>> http://cr.openjdk.java.net/~sherman/8193479/webrev >> >> That seems to me to be invalidating the whole point of the test, >> which was a regression test for 6896617 to check that the >> optimizations put in place actually get applied. ?? >> >> But I'll leave that up to the compiler guys to decide. >> >>> Assume I would need hotspot guys' help to review and push into hs repo? >> >> You'll need to fix in both jdk/hs and jdk/jdk as the breakage is now >> in both. Fix one and import to the other. >> >> But I still suggest adding the test to ProblemList.txt now so that >> this isn't broken in JDK 10 fork, then fix the actual test at a more >> leisurely pace in jdk/hs. > > I agree with David. Lets exclude it for now and fix it later properly > without rush. > > Thanks > Vladimir > Thanks Vladimir, I have a webrev out there. But I will probably have to wait for the new jdk10 repo open next week. Or maybe the hs repo is still open for something like this? and you guys can help get it in directly there? Sherman -------------------------------------------- It appears the consensus is to put this one into the ProblemList and let the hotspot folks to fix the test case. issue: https://bugs.openjdk.java.net/browse/JDK-8193479 webrev: http://cr.openjdk.java.net/~sherman/8193479/webrev The corresponding hotspot/compiler issue filed: JDK-8193549. Thanks, Sherman ---------------------------------------------- From vivek.r.deshpande at intel.com Thu Dec 14 23:02:15 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Thu, 14 Dec 2017 23:02:15 +0000 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 In-Reply-To: <6e670133-ff57-a83b-4483-fd5a50aba433@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> <4f61211e-01ef-6cd3-4a2f-e4c32e3f491f@oracle.com> <6e670133-ff57-a83b-4483-fd5a50aba433@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771E346E@ORSMSX106.amr.corp.intel.com> Hi Vladimir I have updated webrev with your suggested changes. Would you please review it and sponsor the changes. The webrev is here: http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.01/ I have also updated the bug. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, December 14, 2017 10:44 AM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net Cc: Viswanathan, Sandhya Subject: Re: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 Note, my suggesting changes don't affect performance and other testing results. They are still valid because these changes are only refactoring. Thanks, Vladimir On 12/14/17 10:32 AM, Vladimir Kozlov wrote: > Thank you, Vivek > > 1. You don't need new INCLUDE_CLEAR_UPPER_AVX. The main issue is > UseAVX flag is defined only on x86. You can use #ifdef X86 for that. > > 2. You don't need next guard > > +#if INCLUDE_CLEAR_UPPER_AVX > +? clear_upper_avx(); > +#endif > > if you define empty body in else case (using #ifdef X86): > > +? void clear_upper_avx() { > +#ifdef X86 > +??? if (UseAVX >= 2) { > +????? C->set_clear_upper_avx(true); > +??? } > +#endif > +? } > > 3. Factor next checks into one static method (similar to > clear_avx_size()) to avoid next repetitive checks in .ad file: > > (C->max_vector_size() > 16 || C->clear_upper_avx() == true) > > 4. remove unrelated change (empty line removed) in > macroAssembler_x86.cpp > > Thanks, > Vladimir > > On 12/13/17 11:22 PM, Deshpande, Vivek R wrote: >> Hi Vladimir >> >> I have a fix for the slowdown observed on haswell due to jdk-8178811. >> >> The solution selectively generates vzeroupper when AVX2/ AVX512 >> instructions have been executed and before the transition to SSE code. >> >> I tested this fix with the test case given with bug and SPECjbb2015. >> >> Could you please review and sponsor the patch? >> >> Webrev: >> >> http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ >> >> I have also updated the bug: >> https://bugs.openjdk.java.net/browse/JDK-8190934 >> >> Regards, >> >> Vivek >> From vladimir.kozlov at oracle.com Fri Dec 15 00:10:49 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 14 Dec 2017 16:10:49 -0800 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771E346E@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> <4f61211e-01ef-6cd3-4a2f-e4c32e3f491f@oracle.com> <6e670133-ff57-a83b-4483-fd5a50aba433@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771E346E@ORSMSX106.amr.corp.intel.com> Message-ID: <75443ac2-af5e-cb42-4abc-cdc1b3c38135@oracle.com> Lets do one more iteration ;) Pass Compile* C argument to generate_vzeroupper() in .ad file because Compile::current() is expensive call and you have C already in 2 cases. There is one extra space before { in compile.hpp for set_clear_upper_avx(). Please, update, webrev. I will start testing meanwhile. Thanks, Vladimir On 12/14/17 3:02 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have updated webrev with your suggested changes. > Would you please review it and sponsor the changes. > The webrev is here: > http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.01/ > I have also updated the bug. > > Regards, > Vivek > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, December 14, 2017 10:44 AM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net > Cc: Viswanathan, Sandhya > Subject: Re: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 > > Note, my suggesting changes don't affect performance and other testing results. They are still valid because these changes are only refactoring. > > Thanks, > Vladimir > > On 12/14/17 10:32 AM, Vladimir Kozlov wrote: >> Thank you, Vivek >> >> 1. You don't need new INCLUDE_CLEAR_UPPER_AVX. The main issue is >> UseAVX flag is defined only on x86. You can use #ifdef X86 for that. >> >> 2. You don't need next guard >> >> +#if INCLUDE_CLEAR_UPPER_AVX >> +? clear_upper_avx(); >> +#endif >> >> if you define empty body in else case (using #ifdef X86): >> >> +? void clear_upper_avx() { >> +#ifdef X86 >> +??? if (UseAVX >= 2) { >> +????? C->set_clear_upper_avx(true); >> +??? } >> +#endif >> +? } >> >> 3. Factor next checks into one static method (similar to >> clear_avx_size()) to avoid next repetitive checks in .ad file: >> >> (C->max_vector_size() > 16 || C->clear_upper_avx() == true) >> >> 4. remove unrelated change (empty line removed) in >> macroAssembler_x86.cpp >> >> Thanks, >> Vladimir >> >> On 12/13/17 11:22 PM, Deshpande, Vivek R wrote: >>> Hi Vladimir >>> >>> I have a fix for the slowdown observed on haswell due to jdk-8178811. >>> >>> The solution selectively generates vzeroupper when AVX2/ AVX512 >>> instructions have been executed and before the transition to SSE code. >>> >>> I tested this fix with the test case given with bug and SPECjbb2015. >>> >>> Could you please review and sponsor the patch? >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ >>> >>> I have also updated the bug: >>> https://bugs.openjdk.java.net/browse/JDK-8190934 >>> >>> Regards, >>> >>> Vivek >>> From dean.long at oracle.com Fri Dec 15 02:17:49 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 14 Dec 2017 18:17:49 -0800 Subject: RFR(XS) In-Reply-To: References: Message-ID: Thanks Goetz.? Removing the '!' was unintentional. dl On 12/13/17 11:34 PM, Lindenmaier, Goetz wrote: > Hi Dean, > > this looks as if you negated isCompilable(). Why did you remove the '!' from > the return value? The rest is fine. > > Best regards > Goetz. > >> -----Original Message----- >> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- >> bounces at openjdk.java.net] On Behalf Of dean.long at oracle.com >> Sent: Mittwoch, 13. Dezember 2017 18:42 >> To: hotspot-compiler-dev at openjdk.java.net compiler > dev at openjdk.java.net> >> Subject: RFR(XS) >> >> https://bugs.openjdk.java.net/browse/JDK-8193323 >> http://cr.openjdk.java.net/~dlong/8193323/webrev >> >> JVMCI needs to skip redefined methods like C1 and C2. >> >> dl From vivek.r.deshpande at intel.com Fri Dec 15 08:25:55 2017 From: vivek.r.deshpande at intel.com (Deshpande, Vivek R) Date: Fri, 15 Dec 2017 08:25:55 +0000 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 In-Reply-To: <75443ac2-af5e-cb42-4abc-cdc1b3c38135@oracle.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> <4f61211e-01ef-6cd3-4a2f-e4c32e3f491f@oracle.com> <6e670133-ff57-a83b-4483-fd5a50aba433@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771E346E@ORSMSX106.amr.corp.intel.com> <75443ac2-af5e-cb42-4abc-cdc1b3c38135@oracle.com> Message-ID: <53E8E64DB2403849AFD89B7D4DAC8B2A771E37F5@ORSMSX106.amr.corp.intel.com> Hi Vladimir I have updated the patch with your suggested changes. Please find it here: http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.02/ Please let me know what you think of the changes. Regards, Vivek -----Original Message----- From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] Sent: Thursday, December 14, 2017 4:11 PM To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net Cc: Viswanathan, Sandhya Subject: Re: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 Lets do one more iteration ;) Pass Compile* C argument to generate_vzeroupper() in .ad file because Compile::current() is expensive call and you have C already in 2 cases. There is one extra space before { in compile.hpp for set_clear_upper_avx(). Please, update, webrev. I will start testing meanwhile. Thanks, Vladimir On 12/14/17 3:02 PM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have updated webrev with your suggested changes. > Would you please review it and sponsor the changes. > The webrev is here: > http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.01/ > I have also updated the bug. > > Regards, > Vivek > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, December 14, 2017 10:44 AM > To: Deshpande, Vivek R ; > hotspot-compiler-dev at openjdk.java.net > Cc: Viswanathan, Sandhya > Subject: Re: RFR(S): x86:8190934: Regressions on Haswell Xeon due to > JDK-8178811 > > Note, my suggesting changes don't affect performance and other testing results. They are still valid because these changes are only refactoring. > > Thanks, > Vladimir > > On 12/14/17 10:32 AM, Vladimir Kozlov wrote: >> Thank you, Vivek >> >> 1. You don't need new INCLUDE_CLEAR_UPPER_AVX. The main issue is >> UseAVX flag is defined only on x86. You can use #ifdef X86 for that. >> >> 2. You don't need next guard >> >> +#if INCLUDE_CLEAR_UPPER_AVX >> +? clear_upper_avx(); >> +#endif >> >> if you define empty body in else case (using #ifdef X86): >> >> +? void clear_upper_avx() { >> +#ifdef X86 >> +??? if (UseAVX >= 2) { >> +????? C->set_clear_upper_avx(true); >> +??? } >> +#endif >> +? } >> >> 3. Factor next checks into one static method (similar to >> clear_avx_size()) to avoid next repetitive checks in .ad file: >> >> (C->max_vector_size() > 16 || C->clear_upper_avx() == true) >> >> 4. remove unrelated change (empty line removed) in >> macroAssembler_x86.cpp >> >> Thanks, >> Vladimir >> >> On 12/13/17 11:22 PM, Deshpande, Vivek R wrote: >>> Hi Vladimir >>> >>> I have a fix for the slowdown observed on haswell due to jdk-8178811. >>> >>> The solution selectively generates vzeroupper when AVX2/ AVX512 >>> instructions have been executed and before the transition to SSE code. >>> >>> I tested this fix with the test case given with bug and SPECjbb2015. >>> >>> Could you please review and sponsor the patch? >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ >>> >>> I have also updated the bug: >>> https://bugs.openjdk.java.net/browse/JDK-8190934 >>> >>> Regards, >>> >>> Vivek >>> From tobias.hartmann at oracle.com Fri Dec 15 09:15:19 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Dec 2017 10:15:19 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: References: <091589cd-8bd0-c1dc-f8ec-cba95633f420@oracle.com> Message-ID: Hi, The new TestVectorsNotSavedAtSafepoint.java fails on all platforms with "java.lang.OutOfMemoryError: Java heap space". I think this is due to the GarbageProducerThread allocating thousands of Objects: java.lang.OutOfMemoryError: Java heap space at TestVectorsNotSavedAtSafepoint$GarbageProducerThread.run(TestVectorsNotSavedAtSafepoint.java:54) Best regards, Tobias On 14.12.2017 17:41, Tobias Hartmann wrote: > > On 14.12.2017 17:37, Vladimir Kozlov wrote: >> Tobias, please, sponsor it (test and push). > > Sure, I'll do so. > > Best regards, > Tobias > From tobias.hartmann at oracle.com Fri Dec 15 09:48:45 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Dec 2017 10:48:45 +0100 Subject: RFR JDK-8193479: test/hotspot/jtreg/compiler/codegen/Test6896617.java fails after JDK-8184947 In-Reply-To: <5A32E33C.7070904@oracle.com> References: <5A31BF65.8090808@oracle.com> <5A31DC62.60802@oracle.com> <0f744ab5-f419-de05-171e-1110ebc886a4@oracle.com> <055440af-39eb-38e6-bd9f-41102868dbe8@oracle.com> <5A32E33C.7070904@oracle.com> Message-ID: Hi Sherman, On 14.12.2017 21:46, Xueming Shen wrote: > I have a webrev out there. But I will probably have to wait for the > new jdk10 repo open next week. > > Or maybe the hs repo is still open for something like this? and > you guys can help get it in directly there? I would say it's best to wait for the jdk10 repo to open. > It appears the consensus is to put this one into the ProblemList and let the > hotspot folks to fix the test case. > > issue: https://bugs.openjdk.java.net/browse/JDK-8193479 > webrev: http://cr.openjdk.java.net/~sherman/8193479/webrev > > The corresponding hotspot/compiler issue filed: JDK-8193549. The correct way is to create a subtask to quarantine the test. I've created one for you and closed (JDK-8193549) as duplicate: https://bugs.openjdk.java.net/browse/JDK-8193608 Please un-assign 8193479 if you don't plan to fix the test. Thanks, Tobias From rwestrel at redhat.com Fri Dec 15 12:26:09 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Fri, 15 Dec 2017 13:26:09 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: References: <091589cd-8bd0-c1dc-f8ec-cba95633f420@oracle.com> Message-ID: Hi Tobias, > The new TestVectorsNotSavedAtSafepoint.java fails on all platforms with "java.lang.OutOfMemoryError: Java heap space". I > think this is due to the GarbageProducerThread allocating thousands of Objects: > > java.lang.OutOfMemoryError: Java heap space > at TestVectorsNotSavedAtSafepoint$GarbageProducerThread.run(TestVectorsNotSavedAtSafepoint.java:54) Thanks for running the tests. Can you try the new test? http://cr.openjdk.java.net/~roland/8193518/webrev.01/ Roland. From tobias.hartmann at oracle.com Fri Dec 15 12:33:29 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Dec 2017 13:33:29 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: References: <091589cd-8bd0-c1dc-f8ec-cba95633f420@oracle.com> Message-ID: <893b9c7c-5e2b-2d2f-1fa4-328fb604b397@oracle.com> Hi Roland, On 15.12.2017 13:26, Roland Westrelin wrote: > Thanks for running the tests. Can you try the new test? > > http://cr.openjdk.java.net/~roland/8193518/webrev.01/ Thanks, I'll re-run testing. Best regards, Tobias P.S. Please make sure to avoid trailing whitespaces in your patches: src/hotspot/share/opto/superword.cpp:2444: Trailing whitespace From tobias.hartmann at oracle.com Fri Dec 15 15:07:17 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Dec 2017 16:07:17 +0100 Subject: [10] RFR(XS): 8193608: Quarantine test/hotspot/jtreg/compiler/codegen/Test6896617.java until JDK-8193479 is fixed Message-ID: Hi, please review the following change that quarantines a failing test: https://bugs.openjdk.java.net/browse/JDK-8193608 http://cr.openjdk.java.net/~thartmann/8193608/webrev.00/ Thanks, Tobias From tobias.hartmann at oracle.com Fri Dec 15 15:08:49 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Dec 2017 16:08:49 +0100 Subject: RFR JDK-8193479: test/hotspot/jtreg/compiler/codegen/Test6896617.java fails after JDK-8184947 In-Reply-To: References: <5A31BF65.8090808@oracle.com> <5A31DC62.60802@oracle.com> <0f744ab5-f419-de05-171e-1110ebc886a4@oracle.com> <055440af-39eb-38e6-bd9f-41102868dbe8@oracle.com> <5A32E33C.7070904@oracle.com> Message-ID: <33386751-cea5-6b01-f1a6-060d1c298d4c@oracle.com> Hi Sherman, On 15.12.2017 10:48, Tobias Hartmann wrote: > I would say it's best to wait for the jdk10 repo to open. I've checked with Jesper and we can/should quarantine this test right away. I'll take care of it [1]. Best regards, Tobias [1] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-December/027933.html From vladimir.x.ivanov at oracle.com Fri Dec 15 15:49:52 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 15 Dec 2017 18:49:52 +0300 Subject: [10] RFR(XS): 8193608: Quarantine test/hotspot/jtreg/compiler/codegen/Test6896617.java until JDK-8193479 is fixed In-Reply-To: References: Message-ID: Looks good. Best regards, Vladimir Ivanov On 12/15/17 6:07 PM, Tobias Hartmann wrote: > Hi, > > please review the following change that quarantines a failing test: > https://bugs.openjdk.java.net/browse/JDK-8193608 > http://cr.openjdk.java.net/~thartmann/8193608/webrev.00/ > > Thanks, > Tobias > From tobias.hartmann at oracle.com Fri Dec 15 15:50:40 2017 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Fri, 15 Dec 2017 16:50:40 +0100 Subject: [10] RFR(XS): 8193608: Quarantine test/hotspot/jtreg/compiler/codegen/Test6896617.java until JDK-8193479 is fixed In-Reply-To: References: Message-ID: <63ffc151-e31e-87a5-04ff-c4d72a9fbd49@oracle.com> Thanks Vladimir. Best regards, Tobias On 15.12.2017 16:49, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 12/15/17 6:07 PM, Tobias Hartmann wrote: >> Hi, >> >> please review the following change that quarantines a failing test: >> https://bugs.openjdk.java.net/browse/JDK-8193608 >> http://cr.openjdk.java.net/~thartmann/8193608/webrev.00/ >> >> Thanks, >> Tobias >> From vladimir.kozlov at oracle.com Fri Dec 15 17:33:52 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 15 Dec 2017 09:33:52 -0800 Subject: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 In-Reply-To: <53E8E64DB2403849AFD89B7D4DAC8B2A771E37F5@ORSMSX106.amr.corp.intel.com> References: <53E8E64DB2403849AFD89B7D4DAC8B2A771E2D28@ORSMSX106.amr.corp.intel.com> <4f61211e-01ef-6cd3-4a2f-e4c32e3f491f@oracle.com> <6e670133-ff57-a83b-4483-fd5a50aba433@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771E346E@ORSMSX106.amr.corp.intel.com> <75443ac2-af5e-cb42-4abc-cdc1b3c38135@oracle.com> <53E8E64DB2403849AFD89B7D4DAC8B2A771E37F5@ORSMSX106.amr.corp.intel.com> Message-ID: <808fbf11-1a75-b5a8-00d4-04294e28b60a@oracle.com> Good. Testing passed and it is ready for push. But since we forked jdk10 already I need to find procedure where to push. You will get notification. Thanks, Vladimir On 12/15/17 12:25 AM, Deshpande, Vivek R wrote: > Hi Vladimir > > I have updated the patch with your suggested changes. > Please find it here: > http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.02/ > Please let me know what you think of the changes. > > Regards, > Vivek > > -----Original Message----- > From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] > Sent: Thursday, December 14, 2017 4:11 PM > To: Deshpande, Vivek R ; hotspot-compiler-dev at openjdk.java.net > Cc: Viswanathan, Sandhya > Subject: Re: RFR(S): x86:8190934: Regressions on Haswell Xeon due to JDK-8178811 > > Lets do one more iteration ;) > > Pass Compile* C argument to generate_vzeroupper() in .ad file because > Compile::current() is expensive call and you have C already in 2 cases. > > There is one extra space before { in compile.hpp for set_clear_upper_avx(). > > Please, update, webrev. I will start testing meanwhile. > > Thanks, > Vladimir > > On 12/14/17 3:02 PM, Deshpande, Vivek R wrote: >> Hi Vladimir >> >> I have updated webrev with your suggested changes. >> Would you please review it and sponsor the changes. >> The webrev is here: >> http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.01/ >> I have also updated the bug. >> >> Regards, >> Vivek >> -----Original Message----- >> From: Vladimir Kozlov [mailto:vladimir.kozlov at oracle.com] >> Sent: Thursday, December 14, 2017 10:44 AM >> To: Deshpande, Vivek R ; >> hotspot-compiler-dev at openjdk.java.net >> Cc: Viswanathan, Sandhya >> Subject: Re: RFR(S): x86:8190934: Regressions on Haswell Xeon due to >> JDK-8178811 >> >> Note, my suggesting changes don't affect performance and other testing results. They are still valid because these changes are only refactoring. >> >> Thanks, >> Vladimir >> >> On 12/14/17 10:32 AM, Vladimir Kozlov wrote: >>> Thank you, Vivek >>> >>> 1. You don't need new INCLUDE_CLEAR_UPPER_AVX. The main issue is >>> UseAVX flag is defined only on x86. You can use #ifdef X86 for that. >>> >>> 2. You don't need next guard >>> >>> +#if INCLUDE_CLEAR_UPPER_AVX >>> +? clear_upper_avx(); >>> +#endif >>> >>> if you define empty body in else case (using #ifdef X86): >>> >>> +? void clear_upper_avx() { >>> +#ifdef X86 >>> +??? if (UseAVX >= 2) { >>> +????? C->set_clear_upper_avx(true); >>> +??? } >>> +#endif >>> +? } >>> >>> 3. Factor next checks into one static method (similar to >>> clear_avx_size()) to avoid next repetitive checks in .ad file: >>> >>> (C->max_vector_size() > 16 || C->clear_upper_avx() == true) >>> >>> 4. remove unrelated change (empty line removed) in >>> macroAssembler_x86.cpp >>> >>> Thanks, >>> Vladimir >>> >>> On 12/13/17 11:22 PM, Deshpande, Vivek R wrote: >>>> Hi Vladimir >>>> >>>> I have a fix for the slowdown observed on haswell due to jdk-8178811. >>>> >>>> The solution selectively generates vzeroupper when AVX2/ AVX512 >>>> instructions have been executed and before the transition to SSE code. >>>> >>>> I tested this fix with the test case given with bug and SPECjbb2015. >>>> >>>> Could you please review and sponsor the patch? >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~vdeshpande/8190934/webrev.00/ >>>> >>>> I have also updated the bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8190934 >>>> >>>> Regards, >>>> >>>> Vivek >>>> From rwestrel at redhat.com Mon Dec 18 14:40:14 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 18 Dec 2017 15:40:14 +0100 Subject: RFR(M): 8193130: Bad graph when unrolled loop bounds conflicts with range checks Message-ID: http://cr.openjdk.java.net/~roland/8193130/webrev.00/ In the test case: The loop in test1() (inlined from test1_helper()) runs for a small number of iterations but the init value is not constant and profiling tells the compiler it runs for a large number of iterations. First, loop predication moves the range checks out of loop, then pre/main/post loops are created and the main loop is unrolled 16 times. After unrolling the init value of the main loop is known to be <= -11 and the limit is -10 (the main loop is never run). The type of the main loop iv is set to <= -10. The main loop no longer has range checks but it still has the range check CastII and the ConvI2L nodes that enforce that the iv should be >= 0. The CastII/ConvI2L nodes become top and some data paths in the main loop body die. Because there's no test that compare the iv to 0 in the loop body (they are predicates above the pre loop), no control paths die. That leads to a broken graph. The only way to fix this that I found, is to have predicates between the main and pre loops that verify that the init value of the main loop falls into the range allowed by range checks. This is tricky because when predication runs there's no pre/main/post loops yet. The change I propose adds skeleton predicates during loop predicates. They are a copy of predicates on the init value of the loop but use a place holder for the init value (Opaque1 node). They are built using an If->Opaque4->Bool pattern that will make them go away after loop optimizations (the Opaque4 node has a default value it takes after loop opts). When the pre/main/post loops are created, the skeleton predicates are copied above the main loop, the Opaque1 node is replaced by the actual init value for the main loop, the uncommon traps of the predicate are replaced by a Halt nodes. The copies also use Opaque4 nodes that will cause the predicates of the main loop to be removed from the final graph. With this change, when the type of the init value of the main loop is known to be -11, the main loop becomes unreachable and is optimized out. An extra complication is that the same problem exists with iteration splitting: after iteration splitting + unrolling the main loop could become unreachable at runtime and CastII/ConvI2L nodes in the main loop body die. This is fixed here by adding predicates between the main and pre loop that enforce range check constraints similar to what is decribed above for loop predication. Roland. From rwestrel at redhat.com Mon Dec 18 15:00:27 2017 From: rwestrel at redhat.com (Roland Westrelin) Date: Mon, 18 Dec 2017 16:00:27 +0100 Subject: RFR(XS): 8193518: C2: Vector registers sometimes corrupted at safepoint In-Reply-To: <893b9c7c-5e2b-2d2f-1fa4-328fb604b397@oracle.com> References: <091589cd-8bd0-c1dc-f8ec-cba95633f420@oracle.com> <893b9c7c-5e2b-2d2f-1fa4-328fb604b397@oracle.com> Message-ID: Thanks for pushing the fix, Vladimir. Roland. From goetz.lindenmaier at sap.com Thu Dec 21 08:30:19 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Dec 2017 08:30:19 +0000 Subject: RFR(S): 8193927: Optimize scanning code for oops. Message-ID: <0088b075c3824b9189a62f94870ba87d@sap.com> Hi, Some platforms don't emit immediate oops to the code. If so, scans of the code for oops can be skipped. Add flag ImmediateOopsEmitted to each platform specifying the behavior. Only search code for immediate oops if this flag is set. Make sure no oops are emitted to code if the flag is not set. @aarch people: should the flag set to 'false' on aarch/arm? So far it is true, which defaults to the old behavior. Please review this change. I please need a sponsor. http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.01/ Best regards, Goetz From doug.simon at oracle.com Thu Dec 21 12:33:16 2017 From: doug.simon at oracle.com (Doug Simon) Date: Thu, 21 Dec 2017 13:33:16 +0100 Subject: RFR: 8193930: [JVMCI] calling ResolvedTypeType.getClassInitializer on an array type crashes Message-ID: Please review this simple fix for a VM crash when calling ResolvedTypeType.getClassInitializer on an array type. In addition to fixing the code for ResolvedTypeType.getClassInitializer, this patch also makes CompilerToVM.getImplementor more robust in case it is called with a ResolvedjavaType representing a non-interface type. Lastly, there are a few minor comment formatting changes that were made automatically by Eclipse. I'd like to keep them as Eclipse is the preferred tool for developing JVMCI code. https://bugs.openjdk.java.net/browse/JDK-8193930 http://cr.openjdk.java.net/~dnsimon/8193930/ -Doug From volker.simonis at gmail.com Thu Dec 21 13:51:04 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 21 Dec 2017 14:51:04 +0100 Subject: RFR(S): 8193927: Optimize scanning code for oops. In-Reply-To: <0088b075c3824b9189a62f94870ba87d@sap.com> References: <0088b075c3824b9189a62f94870ba87d@sap.com> Message-ID: Hi Goetz, this seems to be a little strange flag for me because it can not be used for really controlling the emission of immediate oops. It only records if a platform can emit immediate oops or not. So wouldn't it be better to either have a flag like "EmitImmediateOops" which really controls the emission of immediate oops. I.e. it could be used to switch the emission of immediate oops off even on platforms which usually do that. Or if that's not reasonable, don't introduce a new flag at all but just declare a platform specific method instead which returns if immediate oops can be emitted on that platform or not. Thanks, Volker On Thu, Dec 21, 2017 at 9:30 AM, Lindenmaier, Goetz wrote: > Hi, > > Some platforms don't emit immediate oops to the code. If so, scans > of the code for oops can be skipped. > > Add flag ImmediateOopsEmitted to each platform specifying the behavior. > Only search code for immediate oops if this flag is set. Make sure no > oops are emitted to code if the flag is not set. > > @aarch people: should the flag set to 'false' on aarch/arm? So far it > is true, which defaults to the old behavior. > > Please review this change. I please need a sponsor. > http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.01/ > > Best regards, > Goetz From shade at redhat.com Thu Dec 21 15:23:18 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 Dec 2017 16:23:18 +0100 Subject: RFR(S): 8193927: Optimize scanning code for oops. In-Reply-To: <0088b075c3824b9189a62f94870ba87d@sap.com> References: <0088b075c3824b9189a62f94870ba87d@sap.com> Message-ID: <4e8a8e4a-ed55-50f9-df95-3dcca09c70fb@redhat.com> On 12/21/2017 09:30 AM, Lindenmaier, Goetz wrote: > Add flag ImmediateOopsEmitted to each platform specifying the behavior. > Only search code for immediate oops if this flag is set. Make sure no > oops are emitted to code if the flag is not set. From the description, it seems to be equivalent to ScavengeRootsInCode=0? diagnostic(intx, ScavengeRootsInCode, 2, \ "0: do not allow scavengable oops in the code cache; " \ "1: allow scavenging from the code cache; " \ "2: emit as many constants as the compiler can see") \ range(0, 2) \ If so, don't we want to reuse that? In fact, IIRC code cache scanning code would even skip registering nmethods for scan in ScavengeRootsInCode=0. Thanks, -Aleksey -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From goetz.lindenmaier at sap.com Thu Dec 21 15:49:23 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Dec 2017 15:49:23 +0000 Subject: RFR(S): 8193927: Optimize scanning code for oops. In-Reply-To: <4e8a8e4a-ed55-50f9-df95-3dcca09c70fb@redhat.com> References: <0088b075c3824b9189a62f94870ba87d@sap.com> <4e8a8e4a-ed55-50f9-df95-3dcca09c70fb@redhat.com> Message-ID: <088e27b65404464aba3c34ae881f5c48@sap.com> Hi Aleksey, If I understand correctly, ScavengeRootsInCode=0 means there are no oops in the nmethod. What I am optimizing is that there are no oops in the code as immediates, there still are some in the constant section of the nmethod. Also, ScavengeRootsInCode is forced to >0 in arguments.cpp, which makes no sense in my case. On ppc/s390 ... you need not do the two walks skipped in nmethod.cpp in any case. Best regards, Goetz. > -----Original Message----- > From: Aleksey Shipilev [mailto:shade at redhat.com] > Sent: Donnerstag, 21. Dezember 2017 16:23 > To: Lindenmaier, Goetz ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(S): 8193927: Optimize scanning code for oops. > > On 12/21/2017 09:30 AM, Lindenmaier, Goetz wrote: > > Add flag ImmediateOopsEmitted to each platform specifying the behavior. > > Only search code for immediate oops if this flag is set. Make sure no > > oops are emitted to code if the flag is not set. > > From the description, it seems to be equivalent to ScavengeRootsInCode=0? > > diagnostic(intx, ScavengeRootsInCode, 2, \ > "0: do not allow scavengable oops in the code cache; " \ > "1: allow scavenging from the code cache; " \ > "2: emit as many constants as the compiler can see") \ > range(0, 2) \ > > If so, don't we want to reuse that? In fact, IIRC code cache scanning code > would even skip > registering nmethods for scan in ScavengeRootsInCode=0. > > Thanks, > -Aleksey From goetz.lindenmaier at sap.com Thu Dec 21 16:18:01 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 21 Dec 2017 16:18:01 +0000 Subject: RFR(S): 8193927: Optimize scanning code for oops. In-Reply-To: References: <0088b075c3824b9189a62f94870ba87d@sap.com> Message-ID: <53c0d07ae086408684250bb3faca1050@sap.com> Hi Volker, you are right, encapsulating it in a function is a better solution: http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.02 Making it switchable would require changes to x86, which is not my scope. Best regards, Goetz. > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Donnerstag, 21. Dezember 2017 14:51 > To: Lindenmaier, Goetz > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: RFR(S): 8193927: Optimize scanning code for oops. > > Hi Goetz, > > this seems to be a little strange flag for me because it can not be > used for really controlling the emission of immediate oops. It only > records if a platform can emit immediate oops or not. > > So wouldn't it be better to either have a flag like > "EmitImmediateOops" which really controls the emission of immediate > oops. I.e. it could be used to switch the emission of immediate oops > off even on platforms which usually do that. Or if that's not > reasonable, don't introduce a new flag at all but just declare a > platform specific method instead which returns if immediate oops can > be emitted on that platform or not. > > Thanks, > Volker > > On Thu, Dec 21, 2017 at 9:30 AM, Lindenmaier, Goetz > wrote: > > Hi, > > > > Some platforms don't emit immediate oops to the code. If so, scans > > of the code for oops can be skipped. > > > > Add flag ImmediateOopsEmitted to each platform specifying the behavior. > > Only search code for immediate oops if this flag is set. Make sure no > > oops are emitted to code if the flag is not set. > > > > @aarch people: should the flag set to 'false' on aarch/arm? So far it > > is true, which defaults to the old behavior. > > > > Please review this change. I please need a sponsor. > > http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.01/ > > > > Best regards, > > Goetz From tom.rodriguez at oracle.com Thu Dec 21 16:31:30 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Thu, 21 Dec 2017 08:31:30 -0800 Subject: RFR 8192004: InspectedFrame.materializeVirtualObjects only updates locals with new objects Message-ID: <5A3BE1E2.6030105@oracle.com> JVMCI adds the ability to introspect on deoptimized frames which requires early materialization of escape analyzed objects. The jvmtiDeferredLocalVariableSet machinery is reused to capture the local updates required for this. The existing code only updates locals, leaving the stack and monitor information with out of date values. This can lead to deadlocks and incorrect execution. The fix is to slightly generalize jvmtiDeferredLocalVariableSet to handle expression stack and monitor slots. Tested with new graal regression test https://github.com/graalvm/graal/blob/7fd37bde8955780a57049964d87a51aa2407d86b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotStackIntrospectionTest.java and previously failing Truffle use cases. I assume the new test case will come across with a normal graal update. The clean mach5 run is in the bug report. http://cr.openjdk.java.net/~never/8192004/webrev https://bugs.openjdk.java.net/browse/JDK-8192004 From volker.simonis at gmail.com Thu Dec 21 16:50:01 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 21 Dec 2017 17:50:01 +0100 Subject: RFR(S): 8193927: Optimize scanning code for oops. In-Reply-To: <53c0d07ae086408684250bb3faca1050@sap.com> References: <0088b075c3824b9189a62f94870ba87d@sap.com> <53c0d07ae086408684250bb3faca1050@sap.com> Message-ID: Hi Goetz, looks good now! Thanks for doing the change. I'm pretty sure you could return 'false' on zero as well as zero doesn't generate any code at all. Regards, Volker On Thu, Dec 21, 2017 at 5:18 PM, Lindenmaier, Goetz wrote: > Hi Volker, > > you are right, encapsulating it in a function is a better solution: > http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.02 > > Making it switchable would require changes to x86, which is > not my scope. > > Best regards, > Goetz. > >> -----Original Message----- >> From: Volker Simonis [mailto:volker.simonis at gmail.com] >> Sent: Donnerstag, 21. Dezember 2017 14:51 >> To: Lindenmaier, Goetz >> Cc: hotspot-compiler-dev at openjdk.java.net >> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops. >> >> Hi Goetz, >> >> this seems to be a little strange flag for me because it can not be >> used for really controlling the emission of immediate oops. It only >> records if a platform can emit immediate oops or not. >> >> So wouldn't it be better to either have a flag like >> "EmitImmediateOops" which really controls the emission of immediate >> oops. I.e. it could be used to switch the emission of immediate oops >> off even on platforms which usually do that. Or if that's not >> reasonable, don't introduce a new flag at all but just declare a >> platform specific method instead which returns if immediate oops can >> be emitted on that platform or not. >> >> Thanks, >> Volker >> >> On Thu, Dec 21, 2017 at 9:30 AM, Lindenmaier, Goetz >> wrote: >> > Hi, >> > >> > Some platforms don't emit immediate oops to the code. If so, scans >> > of the code for oops can be skipped. >> > >> > Add flag ImmediateOopsEmitted to each platform specifying the behavior. >> > Only search code for immediate oops if this flag is set. Make sure no >> > oops are emitted to code if the flag is not set. >> > >> > @aarch people: should the flag set to 'false' on aarch/arm? So far it >> > is true, which defaults to the old behavior. >> > >> > Please review this change. I please need a sponsor. >> > http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.01/ >> > >> > Best regards, >> > Goetz From dean.long at oracle.com Thu Dec 21 18:44:31 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 21 Dec 2017 10:44:31 -0800 Subject: RFR: 8193930: [JVMCI] calling ResolvedTypeType.getClassInitializer on an array type crashes In-Reply-To: References: Message-ID: Instead of ?998 if (klass->is_array_klass()) { 999 return NULL; 1000 } 1001 InstanceKlass* iklass = (InstanceKlass*) klass; how about 998 if (!klass->is_instance_klass()) { 999 return NULL; 1000 } 1001 InstanceKlass* iklass = InstanceKlass::cast(klass); The rest looks good. dl On 12/21/17 4:33 AM, Doug Simon wrote: > Please review this simple fix for a VM crash when calling ResolvedTypeType.getClassInitializer on an array type. > > In addition to fixing the code for ResolvedTypeType.getClassInitializer, this patch also makes CompilerToVM.getImplementor more robust in case it is called with a ResolvedjavaType representing a non-interface type. > > Lastly, there are a few minor comment formatting changes that were made automatically by Eclipse. I'd like to keep them as Eclipse is the preferred tool for developing JVMCI code. > > https://bugs.openjdk.java.net/browse/JDK-8193930 > http://cr.openjdk.java.net/~dnsimon/8193930/ > > -Doug -------------- next part -------------- An HTML attachment was scrubbed... URL: From dean.long at oracle.com Fri Dec 22 01:59:49 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 21 Dec 2017 17:59:49 -0800 Subject: RFR(XS) 8191852: Null pointer dereference in ciKlass::get_Klass of ciKlass.hpp:58 In-Reply-To: <12681129-02df-59f2-8315-7462d7e92d5d@oracle.com> References: <7601725d-93e0-ce53-f75d-633ab3284d43@oracle.com> <3e60610c-5c35-2584-115f-da4117c037ef@oracle.com> <12681129-02df-59f2-8315-7462d7e92d5d@oracle.com> Message-ID: <60d2661b-2c1b-e7a1-ffe9-a068cd4dbe85@oracle.com> New webrev: http://cr.openjdk.java.net/~dlong/8191852/webrev.2 My experiment to simplify get_instance_klass() and friends failed. Parfait failed to identify possible null dereferences, even new ones that I introduced as a test, so went with the minimal fix instead. It only addresses the following error: Error: Null pointer dereference ?? Null pointer dereference [null-pointer-deref] (CWE 476): ????? Read from null pointer ((ciMetadata*)this) ??????? at line 58 of src/hotspot/share/ci/ciKlass.hpp in function 'ciKlass::get_Klass'. ????????? Null pointer introduced at line 207 of src/hotspot/share/ci/ciEnv.hpp in function 'ciEnv::get_instance_klass'. ????????? Constant 'NULL' passed into function ciKlass::get_Klass, argument this, from call at line 240 of src/hotspot/share/ci/ciField.cpp in function 'ciField::initialize_from'. ????????? Function ciEnv::get_instance_klass may return constant 'NULL' at line 207, called at line 237. dl On 12/13/17 4:20 PM, Vladimir Kozlov wrote: > On 12/13/17 3:09 PM, dean.long at oracle.com wrote: >> On 12/13/17 1:08 PM, Vladimir Kozlov wrote: >> >>> On 12/13/17 12:45 PM, dean.long at oracle.com wrote: >>>> https://bugs.openjdk.java.net/browse/JDK-8191852 >>>> http://cr.openjdk.java.net/~dlong/8191852/webrev/ >>>> >>>> Our static analysis tool was complaining about a possible null >>>> pointer dereference in ciKlass::get_Klass(), because of this code: >>>> >>>> 237.??? ? _holder = >>>> CURRENT_ENV->get_instance_klass(fd->field_holder()); >>>> [...] >>>> 240.??? ? Klass* k = _holder->get_Klass(); >>>> >>>> so I added NULL checks in get_instance_klass and a few other >>>> similar functions. >>> >>> No, you don't ;) >> >> Yes, you're right.? Sorry about that :-) >> >>> You replaced NULL checks which return NULL with asserts. It is not >>> the same. Are you sure that in all those cases we will not get NULL? >> >> It didn't show up in my testing.? But what I could try is to remove >> the asserts and rerun the static analysis.? Then get_instance_klass() >> would be: >> >> ?? ciInstanceKlass* get_instance_klass(Klass* o) { >> ???? return get_metadata(o)->as_instance_klass(); >> ?? } >> >> In the first example above, static analysis would need to verify that >> fd->field_holder() can never return NULL.? If that sounds reasonable, >> I'll rerun the static analysis. > > Yes, it is reasonable. > > Thanks, > Vladimir > >> >> dl >> >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> dl >> From dean.long at oracle.com Fri Dec 22 02:52:04 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Thu, 21 Dec 2017 18:52:04 -0800 Subject: RFR(XS) 8191854: Null pointer dereference in methodData.hpp:462 Message-ID: https://bugs.openjdk.java.net/browse/JDK-8191854 http://cr.openjdk.java.net/~dlong/8191854/webrev/ This fixes a possible null pointer dereference here: int count = mdo->bci_to_data(branch_bci)->as_JumpData()->taken(); tty->print_cr("back branch count = %d", count); if bci_to_data() returns NULL. dl From zhongwei.yao at linaro.org Fri Dec 22 08:02:39 2017 From: zhongwei.yao at linaro.org (Zhongwei Yao) Date: Fri, 22 Dec 2017 16:02:39 +0800 Subject: [RFC] ldp/stp peephole optimizations Message-ID: Hi, We are planning to add AArch64 LDP/STP (load/store pair of registers) support in C2 code-gen for better performance. I think the LDP/STP can be used in following cases: A). For register spill/unspill. We've observed many sequential single stack load/store patterns in SPECjbb C2 generated code. B). Besides spilling, LDP is also not generated generally for multiple LoadI/LoadL nodes. Is there any risk (e.g. implicit check?) for combing them together, apart from alignment issue? I think peephole is the best fit for above optimization (gcc/llvm also has such peephole optimization). However, current peephole rules in C2 compiler is very limited and I doubt whether it really takes effect - AArch64 has disabled peephole optimizations. x86 has enabled it, but the instruction sequences to be matched by the rules seems to be very uncommon. To address issue A), since current spill/unspill are handled by common MachSpillCopyNode, I was thinking if we could add peephole rule to match MachSpillCopyNode, but MachSpillCopyNode has no operands (e.g. mem, src, dst) like ordinary instruct defined in aarch64.ad. Even we may extract them (mem, src, dst) like in MachSpillCopyNode::implementation(), and even we can extend current peephole rule grammar, expressing such extraction in peephole's grammar is complex. So I prefer adding following manually defined method peephole() to MachSpillCopyNode: virtual MachNode *peephole(Block *block, int block_index, PhaseRegAlloc *ra_, int &deleted); This makes the patch relative simple. My prototype patch for A) (still some TODOs and hardcodes, but it works fine): http://cr.openjdk.java.net/~zyao/RFC_A/ To address issue B) is somewhat complicated, we need to extend current peephole rule syntax, as I don't think current simple syntax works for any useful peephole optimizations like ldp/stp opt. My extended syntax - at least works for ldp/stp optimizations: ------ peepmatch ( loadI loadI ); peepconstraint (0.mem$base == 1.mem$base, 0.mem$scale == 1.mem$scale, 0.mem$disp - 4 == 1.mem$disp, 0.dst != 1.dst); // new grammar is described below. peepreplace (loadPairI(1.mem 1.mem)) ------ But for loadPairI, it is hard to express in current instruct semantic. Because current instruct in aarch64.ad is defined by a match rule. The match rule is an expression tree and made of Ideal Node. However, LDP instruction doesn't have Ideal Node (say LoadPair) to match. And adding load pair node to arch-independent Ideal node seems strange. My proposed solution is: add a special arch dependent operand like iRegIpair: ------ operand iRegIpair(iRegI reg1, iRegI reg2) %{ constraint(ALLOC_IN_RC(any_reg32)); op_cost(0); format %{ "pair: reg1, reg2"%}; // hard coded format for now. interface(REG_INTER); %} ------ This needs to update ADLC to support iRegIpair operand. Because unlike current operand which has 1 register, iRegIpair has 2. Then use it as loadPairI's operand type like: ------ instruct loadPairI(indOffI mem, iRegIpair dst) %{ match(Set dst mem); //no Ideal Node in match rule. ... %} ------ Then we can use loadPairI in peephole rule's "peepreplace". Since only constraints between operands are supported in peephole rule. But to check whether the adjacent loads are loaded from adjacent memory address, we need to check operand's member, like (0.mem$disp - 4 == 1.mem$disp), My solution is: add new grammar like 0.mem$disp to extract member in operand in ADLC (peep_constraint_parse()). Another issue for peephole optimization is that it only matches adjacent instructions in the same basic block. This leads to many missing matches when loads are not scheduled to adjacent. So I propose to delay peephole phase to the place just before final code emit (the fill_buffer() function). This place is after instruction scheduling. So after instruction scheduling, we could match more adjacent loads. My draft patch to address B) is at: http://cr.openjdk.java.net/~zyao/RFC_B/ What do you think? Welcome any feedback! -- Best regards, Zhongwei From goetz.lindenmaier at sap.com Fri Dec 22 08:20:23 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 22 Dec 2017 08:20:23 +0000 Subject: RFR(S): 8193927: Optimize scanning code for oops. In-Reply-To: References: <0088b075c3824b9189a62f94870ba87d@sap.com> <53c0d07ae086408684250bb3faca1050@sap.com> Message-ID: Hi Volker, > looks good now! Thanks for doing the change. thanks! > I'm pretty sure you could return 'false' on zero as well as zero > doesn't generate any code at all. If there are no nmethods, the returned value of the function is pointless on zero. Best regards, Goetz. > > Regards, > Volker > > > On Thu, Dec 21, 2017 at 5:18 PM, Lindenmaier, Goetz > wrote: > > Hi Volker, > > > > you are right, encapsulating it in a function is a better solution: > > http://cr.openjdk.java.net/~goetz/wr17/8193927-oopsInCode/webrev.02 > > > > Making it switchable would require changes to x86, which is > > not my scope. > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Volker Simonis [mailto:volker.simonis at gmail.com] > >> Sent: Donnerstag, 21. Dezember 2017 14:51 > >> To: Lindenmaier, Goetz > >> Cc: hotspot-compiler-dev at openjdk.java.net > >> Subject: Re: RFR(S): 8193927: Optimize scanning code for oops. > >> > >> Hi Goetz, > >> > >> this seems to be a little strange flag for me because it can not be > >> used for really controlling the emission of immediate oops. It only > >> records if a platform can emit immediate oops or not. > >> > >> So wouldn't it be better to either have a flag like > >> "EmitImmediateOops" which really controls the emission of immediate > >> oops. I.e. it could be used to switch the emission of immediate oops > >> off even on platforms which usually do that. Or if that's not > >> reasonable, don't introduce a new flag at all but just declare a > >> platform specific method instead which returns if immediate oops can > >> be emitted on that platform or not. > >> > >> Thanks, > >> Volker > >> > >> On Thu, Dec 21, 2017 at 9:30 AM, Lindenmaier, Goetz > >> wrote: > >> > Hi, > >> > > >> > Some platforms don't emit immediate oops to the code. If so, scans > >> > of the code for oops can be skipped. > >> > > >> > Add flag ImmediateOopsEmitted to each platform specifying the > behavior. > >> > Only search code for immediate oops if this flag is set. Make sure no > >> > oops are emitted to code if the flag is not set. > >> > > >> > @aarch people: should the flag set to 'false' on aarch/arm? So far it > >> > is true, which defaults to the old behavior. > >> > > >> > Please review this change. I please need a sponsor. > >> > http://cr.openjdk.java.net/~goetz/wr17/8193927- > oopsInCode/webrev.01/ > >> > > >> > Best regards, > >> > Goetz From rahul.v.raghavan at oracle.com Fri Dec 22 09:35:22 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 22 Dec 2017 15:05:22 +0530 Subject: [10] RFR: 8193699: AArch64 Fails to build after 8167372 Message-ID: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> Hi, Request help to review the following fix proposal. - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ Related links - -- https://bugs.openjdk.java.net/browse/JDK-8193699 -- https://bugs.openjdk.java.net/browse/JDK-8167372 ? - 'Add code to check for getting oops while thread is in native' -- https://bugs.openjdk.java.net/browse/JDK-8191227 ? - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / print_on() and LIR_Assembler::jobject2reg()' Found root cause of 8193699 issue, as missing changes for aarch64 in 'macroAssembler_aarch64.cpp', similar to changes done for 8191227 before pushing 8167372 support. So now fixed the issue of unsafe handle resolution in 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. Stuart Monteith confirmed build failure fixed with above proposed changeset and no new issues with testing. Thanks, Rahul -------------- next part -------------- An HTML attachment was scrubbed... URL: From doug.simon at oracle.com Fri Dec 22 10:05:06 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 22 Dec 2017 11:05:06 +0100 Subject: RFR: 8193930: [JVMCI] calling ResolvedTypeType.getClassInitializer on an array type crashes In-Reply-To: References: Message-ID: <5FBBC1E7-8321-41F2-BBBD-A1122AEC950C@oracle.com> > On 21 Dec 2017, at 19:44, dean.long at oracle.com wrote: > > Instead of > > > 998 if (klass->is_array_klass()) { > > 999 return NULL; > 1000 } > 1001 InstanceKlass* iklass = (InstanceKlass*) klass; > how about > > 998 if (!klass->is_instance_klass()) { > 999 return NULL; > 1000 } > 1001 InstanceKlass* iklass = InstanceKlass::cast(klass); Thanks for the suggestion (and review). I've updated the webrev to include it. -Doug > On 12/21/17 4:33 AM, Doug Simon wrote: >> Please review this simple fix for a VM crash when calling ResolvedTypeType.getClassInitializer on an array type. >> >> In addition to fixing the code for ResolvedTypeType.getClassInitializer, this patch also makes CompilerToVM.getImplementor more robust in case it is called with a ResolvedjavaType representing a non-interface type. >> >> Lastly, there are a few minor comment formatting changes that were made automatically by Eclipse. I'd like to keep them as Eclipse is the preferred tool for developing JVMCI code. >> >> >> https://bugs.openjdk.java.net/browse/JDK-8193930 >> http://cr.openjdk.java.net/~dnsimon/8193930/ >> >> >> -Doug >> > From dmitry.chuyko at bell-sw.com Fri Dec 22 11:45:37 2017 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 22 Dec 2017 14:45:37 +0300 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: Message-ID: Hi Zhongwei, I'm not a reviewer. Thank you, it is a great idea to merge loads or stores that are issued sequentially. Can you share some more data on that? Is there a micro-benchmark or some sample program than shows better performance on some hardware? What are the numbers observed? You mention SPECjbb, is it 2005 or 2015? Which configuration? In SPECjbb dou you see most sequential series only related to stack work? -Dmitry On 12/22/2017 11:02 AM, Zhongwei Yao wrote: > Hi, > > We are planning to add AArch64 LDP/STP (load/store pair of registers) > support in C2 code-gen for better performance. I think the LDP/STP can > be used in following cases: > A). For register spill/unspill. We've observed many sequential single > stack load/store patterns in SPECjbb C2 generated code. > B). Besides spilling, LDP is also not generated generally for multiple > LoadI/LoadL nodes. Is there any risk (e.g. implicit check?) for > combing them together, apart from alignment issue? > > I think peephole is the best fit for above optimization (gcc/llvm also > has such peephole optimization). However, current peephole rules in C2 > compiler is very limited and I doubt whether it really takes effect - > AArch64 has disabled peephole optimizations. x86 has enabled it, but > the instruction sequences to be matched by the rules seems to be very > uncommon. > > To address issue A), since current spill/unspill are handled by common > MachSpillCopyNode, I was thinking if we could add peephole rule to > match MachSpillCopyNode, but MachSpillCopyNode has no operands (e.g. > mem, src, dst) like ordinary instruct defined in aarch64.ad. Even we > may extract them (mem, src, dst) like in > MachSpillCopyNode::implementation(), and even we can extend current > peephole rule grammar, expressing such extraction in peephole's > grammar is complex. > So I prefer adding following manually defined method peephole() to > MachSpillCopyNode: > > virtual MachNode *peephole(Block *block, int block_index, > PhaseRegAlloc *ra_, int &deleted); > > This makes the patch relative simple. My prototype patch for A) (still > some TODOs and hardcodes, but it works fine): > http://cr.openjdk.java.net/~zyao/RFC_A/ > > To address issue B) is somewhat complicated, we need to extend current > peephole rule syntax, as I don't think current simple syntax works for > any useful peephole optimizations like ldp/stp opt. > > My extended syntax - at least works for ldp/stp optimizations: > > ------ > peepmatch ( loadI loadI ); > peepconstraint (0.mem$base == 1.mem$base, 0.mem$scale == > 1.mem$scale, 0.mem$disp - 4 == 1.mem$disp, 0.dst != 1.dst); // new > grammar is described below. > peepreplace (loadPairI(1.mem 1.mem)) > ------ > > But for loadPairI, it is hard to express in current instruct semantic. > Because current instruct in aarch64.ad is defined by a match rule. The > match rule is an expression tree and made of Ideal Node. > However, LDP instruction doesn't have Ideal Node (say LoadPair) to > match. And adding load pair node to arch-independent Ideal node seems > strange. > > My proposed solution is: add a special arch dependent operand like iRegIpair: > > ------ > operand iRegIpair(iRegI reg1, iRegI reg2) > %{ > constraint(ALLOC_IN_RC(any_reg32)); > op_cost(0); > format %{ "pair: reg1, reg2"%}; // hard coded format for now. > interface(REG_INTER); > %} > ------ > > This needs to update ADLC to support iRegIpair operand. Because unlike > current operand which has 1 register, iRegIpair has 2. > > Then use it as loadPairI's operand type like: > > ------ > instruct loadPairI(indOffI mem, iRegIpair dst) > %{ > match(Set dst mem); //no Ideal Node in match rule. > ... > > %} > ------ > > Then we can use loadPairI in peephole rule's "peepreplace". > > Since only constraints between operands are supported in peephole > rule. But to check whether the adjacent loads are loaded from adjacent > memory address, we need to check operand's member, like (0.mem$disp - > 4 == 1.mem$disp), My solution is: add new grammar like 0.mem$disp to > extract member in operand in ADLC (peep_constraint_parse()). > > Another issue for peephole optimization is that it only matches > adjacent instructions in the same basic block. This leads to many > missing matches when loads are not scheduled to adjacent. > So I propose to delay peephole phase to the place just before final > code emit (the fill_buffer() function). This place is after > instruction scheduling. So after instruction scheduling, we could > match more adjacent loads. > > My draft patch to address B) is at: > http://cr.openjdk.java.net/~zyao/RFC_B/ > > What do you think? Welcome any feedback! > From stuart.monteith at linaro.org Fri Dec 22 13:41:36 2017 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 22 Dec 2017 13:41:36 +0000 Subject: [10] RFR: 8193699: AArch64 Fails to build after 8167372 In-Reply-To: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> References: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> Message-ID: The code looks OK, AFAICT. Having done a search, your patch appears to cover all the relevant cases. Thanks, Stuart On 22 December 2017 at 09:35, Rahul Raghavan wrote: > Hi, > > Request help to review the following fix proposal. > > - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ > > Related links - > -- https://bugs.openjdk.java.net/browse/JDK-8193699 > -- https://bugs.openjdk.java.net/browse/JDK-8167372 > - 'Add code to check for getting oops while thread is in native' > -- https://bugs.openjdk.java.net/browse/JDK-8191227 > - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / > print_on() and LIR_Assembler::jobject2reg()' > > Found root cause of 8193699 issue, as missing changes for aarch64 in > 'macroAssembler_aarch64.cpp', > similar to changes done for 8191227 before pushing 8167372 support. > So now fixed the issue of unsafe handle resolution in > 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. > Stuart Monteith confirmed build failure fixed with above proposed changeset > and no new issues with testing. > > Thanks, > Rahul > From aph at redhat.com Fri Dec 22 16:02:28 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Dec 2017 16:02:28 +0000 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: Message-ID: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> Hi, On 22/12/17 08:02, Zhongwei Yao wrote: > My draft patch to address B) is at: > http://cr.openjdk.java.net/~zyao/RFC_B/ > > What do you think? Welcome any feedback! I wonder if merging ld/st pairs could be handled by the MacroAssembler. MachSpillCopyNode::peephole looks very complicated. If you handled ldp/stp conversion in MacroAssembler then it'd work everywhere, for any adjacent pair of loads or stores, not just for spills in C2. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Dec 22 16:07:40 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 Dec 2017 16:07:40 +0000 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: Message-ID: On 22/12/17 11:45, Dmitry Chuyko wrote: > Is there a micro-benchmark or some sample program than shows better > performance on some hardware? > What are the numbers observed? It's hard to do that in a meaningful way with a micro-benchmark because the advantages of code size reduction don't apply except with larger programs. However, anything that reduces code size without adversely affecting anything else is worth having. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.x.ivanov at oracle.com Fri Dec 22 16:34:13 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 22 Dec 2017 19:34:13 +0300 Subject: [10] RFR: 8193699: AArch64 Fails to build after 8167372 In-Reply-To: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> References: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> Message-ID: <3baafded-6f14-2c79-8412-5192398331df@oracle.com> Looks good. Best regards, Vladimir Ivanov On 12/22/17 12:35 PM, Rahul Raghavan wrote: > Hi, > > Request help to review the following fix proposal. > > - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ > > Related links - > -- https://bugs.openjdk.java.net/browse/JDK-8193699 > -- https://bugs.openjdk.java.net/browse/JDK-8167372 > ? - 'Add code to check for getting oops while thread is in native' > -- https://bugs.openjdk.java.net/browse/JDK-8191227 > ? - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / > print_on() and LIR_Assembler::jobject2reg()' > > Found root cause of 8193699 issue, as missing changes for aarch64 in > 'macroAssembler_aarch64.cpp', > similar to changes done for 8191227 before pushing 8167372 support. > So now fixed the issue of unsafe handle resolution in > 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. > Stuart Monteith confirmed build failure fixed with above proposed > changeset and no new issues with testing. > > Thanks, > Rahul > From dean.long at oracle.com Fri Dec 22 16:59:31 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 22 Dec 2017 08:59:31 -0800 Subject: RFR: 8193930: [JVMCI] calling ResolvedTypeType.getClassInitializer on an array type crashes In-Reply-To: <5FBBC1E7-8321-41F2-BBBD-A1122AEC950C@oracle.com> References: <5FBBC1E7-8321-41F2-BBBD-A1122AEC950C@oracle.com> Message-ID: <7e14d962-b1cd-ad73-893c-5bf064d228dc@oracle.com> On 12/22/17 2:05 AM, Doug Simon wrote: > >> On 21 Dec 2017, at 19:44, dean.long at oracle.com wrote: >> >> Instead of >> >> >> 998 if (klass->is_array_klass()) { >> >> 999 return NULL; >> 1000 } >> 1001 InstanceKlass* iklass = (InstanceKlass*) klass; >> how about >> >> 998 if (!klass->is_instance_klass()) { >> 999 return NULL; >> 1000 } >> 1001 InstanceKlass* iklass = InstanceKlass::cast(klass); > Thanks for the suggestion (and review). I've updated the webrev to include it. I don't see the use of InstanceKlass::cast() in the update. dl > -Doug > >> On 12/21/17 4:33 AM, Doug Simon wrote: >>> Please review this simple fix for a VM crash when calling ResolvedTypeType.getClassInitializer on an array type. >>> >>> In addition to fixing the code for ResolvedTypeType.getClassInitializer, this patch also makes CompilerToVM.getImplementor more robust in case it is called with a ResolvedjavaType representing a non-interface type. >>> >>> Lastly, there are a few minor comment formatting changes that were made automatically by Eclipse. I'd like to keep them as Eclipse is the preferred tool for developing JVMCI code. >>> >>> >>> https://bugs.openjdk.java.net/browse/JDK-8193930 >>> http://cr.openjdk.java.net/~dnsimon/8193930/ >>> >>> >>> -Doug >>> From tom.rodriguez at oracle.com Fri Dec 22 17:01:35 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 22 Dec 2017 09:01:35 -0800 Subject: RFR: 8193930: [JVMCI] calling ResolvedTypeType.getClassInitializer on an array type crashes In-Reply-To: References: Message-ID: <5A3D3A6F.4000206@oracle.com> Looks good. tom Doug Simon wrote: > Please review this simple fix for a VM crash when calling ResolvedTypeType.getClassInitializer on an array type. > > In addition to fixing the code for ResolvedTypeType.getClassInitializer, this patch also makes CompilerToVM.getImplementor more robust in case it is called with a ResolvedjavaType representing a non-interface type. > > Lastly, there are a few minor comment formatting changes that were made automatically by Eclipse. I'd like to keep them as Eclipse is the preferred tool for developing JVMCI code. > > https://bugs.openjdk.java.net/browse/JDK-8193930 > http://cr.openjdk.java.net/~dnsimon/8193930/ > > -Doug From doug.simon at oracle.com Fri Dec 22 17:30:37 2017 From: doug.simon at oracle.com (Doug Simon) Date: Fri, 22 Dec 2017 18:30:37 +0100 Subject: RFR: 8193930: [JVMCI] calling ResolvedTypeType.getClassInitializer on an array type crashes In-Reply-To: <7e14d962-b1cd-ad73-893c-5bf064d228dc@oracle.com> References: <5FBBC1E7-8321-41F2-BBBD-A1122AEC950C@oracle.com> <7e14d962-b1cd-ad73-893c-5bf064d228dc@oracle.com> Message-ID: <2DF84EC9-4DBF-4502-A80D-93788EC22350@oracle.com> > On 22 Dec 2017, at 17:59, dean.long at oracle.com wrote: > > On 12/22/17 2:05 AM, Doug Simon wrote: > >> >>> On 21 Dec 2017, at 19:44, dean.long at oracle.com wrote: >>> >>> Instead of >>> >>> >>> 998 if (klass->is_array_klass()) { >>> >>> 999 return NULL; >>> 1000 } >>> 1001 InstanceKlass* iklass = (InstanceKlass*) klass; >>> how about >>> >>> 998 if (!klass->is_instance_klass()) { >>> 999 return NULL; >>> 1000 } >>> 1001 InstanceKlass* iklass = InstanceKlass::cast(klass); >> Thanks for the suggestion (and review). I've updated the webrev to include it. > > I don't see the use of InstanceKlass::cast() in the update. Sorry - I missed that was part of the suggested change (in addition to changing the `if` test). While fixing that, I also noticed that I should be using InstanceKlass::cast in getImplementor as well. Please double check that the webrev for jvmciCompilerToVM.cpp now looks right. -Doug > > dl > >> -Doug >> >>> On 12/21/17 4:33 AM, Doug Simon wrote: >>>> Please review this simple fix for a VM crash when calling ResolvedTypeType.getClassInitializer on an array type. >>>> >>>> In addition to fixing the code for ResolvedTypeType.getClassInitializer, this patch also makes CompilerToVM.getImplementor more robust in case it is called with a ResolvedjavaType representing a non-interface type. >>>> >>>> Lastly, there are a few minor comment formatting changes that were made automatically by Eclipse. I'd like to keep them as Eclipse is the preferred tool for developing JVMCI code. >>>> >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8193930 >>>> http://cr.openjdk.java.net/~dnsimon/8193930/ >>>> >>>> >>>> -Doug From rahul.v.raghavan at oracle.com Fri Dec 22 17:55:22 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 22 Dec 2017 23:25:22 +0530 Subject: [10] RFR: 8193699: AArch64 Fails to build after 8167372 In-Reply-To: References: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> Message-ID: <85b644cd-efb1-6306-4316-866c07f770d9@oracle.com> Thank you Stuart. On Friday 22 December 2017 07:11 PM, Stuart Monteith wrote: > The code looks OK, AFAICT. Having done a search, your patch appears to > cover all the relevant cases. > > Thanks, > Stuart > > > On 22 December 2017 at 09:35, Rahul Raghavan > wrote: >> Hi, >> >> Request help to review the following fix proposal. >> >> - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ >> >> Related links - >> -- https://bugs.openjdk.java.net/browse/JDK-8193699 >> -- https://bugs.openjdk.java.net/browse/JDK-8167372 >> - 'Add code to check for getting oops while thread is in native' >> -- https://bugs.openjdk.java.net/browse/JDK-8191227 >> - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / >> print_on() and LIR_Assembler::jobject2reg()' >> >> Found root cause of 8193699 issue, as missing changes for aarch64 in >> 'macroAssembler_aarch64.cpp', >> similar to changes done for 8191227 before pushing 8167372 support. >> So now fixed the issue of unsafe handle resolution in >> 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. >> Stuart Monteith confirmed build failure fixed with above proposed changeset >> and no new issues with testing. >> >> Thanks, >> Rahul >> From rahul.v.raghavan at oracle.com Fri Dec 22 17:56:22 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Fri, 22 Dec 2017 23:26:22 +0530 Subject: [10] RFR: 8193699: AArch64 Fails to build after 8167372 In-Reply-To: <3baafded-6f14-2c79-8412-5192398331df@oracle.com> References: <98d05bd1-dc0a-62ae-6205-2fea93ce7c11@oracle.com> <3baafded-6f14-2c79-8412-5192398331df@oracle.com> Message-ID: <4565ea95-5080-5ff1-2d71-a020db476a1e@oracle.com> Thank you Vladimir. On Friday 22 December 2017 10:04 PM, Vladimir Ivanov wrote: > Looks good. > > Best regards, > Vladimir Ivanov > > On 12/22/17 12:35 PM, Rahul Raghavan wrote: >> Hi, >> >> Request help to review the following fix proposal. >> >> - http://cr.openjdk.java.net/~rraghavan/8193699/webrev.01/ >> >> Related links - >> -- https://bugs.openjdk.java.net/browse/JDK-8193699 >> -- https://bugs.openjdk.java.net/browse/JDK-8167372 >> ?? - 'Add code to check for getting oops while thread is in native' >> -- https://bugs.openjdk.java.net/browse/JDK-8191227 >> ?? - 'Unsafe handle resolution in ConstantOopWriteValue::write_on() / >> print_on() and LIR_Assembler::jobject2reg()' >> >> Found root cause of 8193699 issue, as missing changes for aarch64 in >> 'macroAssembler_aarch64.cpp', >> similar to changes done for 8191227 before pushing 8167372 support. >> So now fixed the issue of unsafe handle resolution in >> 'macroAssembler_aarch64.cpp' with the usage of ThreadInVMfromUnknown. >> Stuart Monteith confirmed build failure fixed with above proposed >> changeset and no new issues with testing. >> >> Thanks, >> Rahul >> From mtraverso at gmail.com Fri Dec 22 17:59:53 2017 From: mtraverso at gmail.com (Martin Traverso) Date: Fri, 22 Dec 2017 17:59:53 +0000 Subject: Reduced performance in Java 9.0.1 (vs 8u152) Message-ID: Hi, We're in the process of migrating and qualifying Presto (http://prestodb.io) to build and run on Java 9. One of the key dependencies is a library of pure-java compression and decompression algorithms ( http://github.com/airlift/aircompressor). In the course of trying to understand the performance characteristics when running on Java 9, we discovered a significant drop in performance for the compression algorithms (up to 10%) when compared to 8u152. Here's a summary of the results and instructions on how to run the benchmarks: https://github.com/martint/aircompressor/tree/perf These are the outputs of JMH's perfasm profiler: Java 8u152: https://github.com/martint/aircompressor/blob/perf/perf-8.txt Java 9.0.1: https://github.com/martint/aircompressor/blob/perf/perf-9.txt The generated assembly looks very different, but as far as I can tell, it's just different decisions of when and which registers to spill. - Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.rodriguez at oracle.com Fri Dec 22 19:08:11 2017 From: tom.rodriguez at oracle.com (Tom Rodriguez) Date: Fri, 22 Dec 2017 11:08:11 -0800 Subject: RFR 8192004: InspectedFrame.materializeVirtualObjects only updates locals with new objects In-Reply-To: <5A3BE1E2.6030105@oracle.com> References: <5A3BE1E2.6030105@oracle.com> Message-ID: <5A3D581B.8080601@oracle.com> Could I get some reviews? This doesn't change the way the logic behaves for the core use of JVMTI. It just extends the encoding so that numbers after the locals are interpreted as expression stack and monitor values. I believe there are existing tests of the JVMTI set locals part and JVMCI is the only only consumer of the monitor and expression stack part. tom Tom Rodriguez wrote: > JVMCI adds the ability to introspect on deoptimized frames which > requires early materialization of escape analyzed objects. The > jvmtiDeferredLocalVariableSet machinery is reused to capture the local > updates required for this. The existing code only updates locals, > leaving the stack and monitor information with out of date values. This > can lead to deadlocks and incorrect execution. The fix is to slightly > generalize jvmtiDeferredLocalVariableSet to handle expression stack and > monitor slots. Tested with new graal regression test > https://github.com/graalvm/graal/blob/7fd37bde8955780a57049964d87a51aa2407d86b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotStackIntrospectionTest.java > and previously failing Truffle use cases. I assume the new test case > will come across with a normal graal update. The clean mach5 run is in > the bug report. > > http://cr.openjdk.java.net/~never/8192004/webrev > https://bugs.openjdk.java.net/browse/JDK-8192004 From vladimir.kozlov at oracle.com Fri Dec 22 20:22:34 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Dec 2017 12:22:34 -0800 Subject: RFR(XS) 8191852: Null pointer dereference in ciKlass::get_Klass of ciKlass.hpp:58 In-Reply-To: <60d2661b-2c1b-e7a1-ffe9-a068cd4dbe85@oracle.com> References: <7601725d-93e0-ce53-f75d-633ab3284d43@oracle.com> <3e60610c-5c35-2584-115f-da4117c037ef@oracle.com> <12681129-02df-59f2-8315-7462d7e92d5d@oracle.com> <60d2661b-2c1b-e7a1-ffe9-a068cd4dbe85@oracle.com> Message-ID: Good. One tiny thing. Can you use 'Klass* ' instead of 'Klass *'?: Klass *field_holder No need for new review. Thanks, Vladimir On 12/21/17 5:59 PM, dean.long at oracle.com wrote: > New webrev: > > http://cr.openjdk.java.net/~dlong/8191852/webrev.2 > > My experiment to simplify get_instance_klass() and friends failed. > Parfait failed to identify possible null dereferences, even new ones > that I introduced as a test, so went with the minimal fix instead. It > only addresses the following error: > > Error: Null pointer dereference > ?? Null pointer dereference [null-pointer-deref] (CWE 476): > ????? Read from null pointer ((ciMetadata*)this) > ??????? at line 58 of src/hotspot/share/ci/ciKlass.hpp in function > 'ciKlass::get_Klass'. > ????????? Null pointer introduced at line 207 of > src/hotspot/share/ci/ciEnv.hpp in function 'ciEnv::get_instance_klass'. > ????????? Constant 'NULL' passed into function ciKlass::get_Klass, > argument this, from call at line 240 of src/hotspot/share/ci/ciField.cpp > in function 'ciField::initialize_from'. > ????????? Function ciEnv::get_instance_klass may return constant 'NULL' > at line 207, called at line 237. > > dl > > > On 12/13/17 4:20 PM, Vladimir Kozlov wrote: >> On 12/13/17 3:09 PM, dean.long at oracle.com wrote: >>> On 12/13/17 1:08 PM, Vladimir Kozlov wrote: >>> >>>> On 12/13/17 12:45 PM, dean.long at oracle.com wrote: >>>>> https://bugs.openjdk.java.net/browse/JDK-8191852 >>>>> http://cr.openjdk.java.net/~dlong/8191852/webrev/ >>>>> >>>>> Our static analysis tool was complaining about a possible null >>>>> pointer dereference in ciKlass::get_Klass(), because of this code: >>>>> >>>>> 237.??? ? _holder = >>>>> CURRENT_ENV->get_instance_klass(fd->field_holder()); >>>>> [...] >>>>> 240.??? ? Klass* k = _holder->get_Klass(); >>>>> >>>>> so I added NULL checks in get_instance_klass and a few other >>>>> similar functions. >>>> >>>> No, you don't ;) >>> >>> Yes, you're right.? Sorry about that :-) >>> >>>> You replaced NULL checks which return NULL with asserts. It is not >>>> the same. Are you sure that in all those cases we will not get NULL? >>> >>> It didn't show up in my testing.? But what I could try is to remove >>> the asserts and rerun the static analysis.? Then get_instance_klass() >>> would be: >>> >>> ?? ciInstanceKlass* get_instance_klass(Klass* o) { >>> ???? return get_metadata(o)->as_instance_klass(); >>> ?? } >>> >>> In the first example above, static analysis would need to verify that >>> fd->field_holder() can never return NULL.? If that sounds reasonable, >>> I'll rerun the static analysis. >> >> Yes, it is reasonable. >> >> Thanks, >> Vladimir >> >>> >>> dl >>> >>>> >>>> Thanks, >>>> Vladimir >>>> >>>>> >>>>> dl >>> > From vladimir.kozlov at oracle.com Fri Dec 22 20:23:29 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Fri, 22 Dec 2017 12:23:29 -0800 Subject: RFR(XS) 8191854: Null pointer dereference in methodData.hpp:462 In-Reply-To: References: Message-ID: Good. Thanks, Vladimir On 12/21/17 6:52 PM, dean.long at oracle.com wrote: > https://bugs.openjdk.java.net/browse/JDK-8191854 > http://cr.openjdk.java.net/~dlong/8191854/webrev/ > > This fixes a possible null pointer dereference here: > > ????????? int count = > mdo->bci_to_data(branch_bci)->as_JumpData()->taken(); > ????????? tty->print_cr("back branch count = %d", count); > > if bci_to_data() returns NULL. > > dl From eric.caspole at oracle.com Fri Dec 22 21:20:36 2017 From: eric.caspole at oracle.com (Eric Caspole) Date: Fri, 22 Dec 2017 16:20:36 -0500 Subject: Reduced performance in Java 9.0.1 (vs 8u152) In-Reply-To: References: Message-ID: Hi Martin, As you may know, JEP 248 made G1 the default collector for 9 where it was ParallelGC earlier: http://openjdk.java.net/jeps/248 I tried your JMH specifying +UseParallelGC by JMH annotations and the performance of 9 seems quite even to 8u131 that I have handy. Maybe you could try this for yourself and see how it goes. Regards, Eric On 12/22/2017 12:59 PM, Martin Traverso wrote: > Hi, > > We're in the process of migrating and qualifying Presto > (http://prestodb.io) to build and run on Java 9. One of the key > dependencies is a library of pure-java compression and decompression > algorithms (http://github.com/airlift/aircompressor). > > In the course of trying to understand the performance characteristics > when running on Java 9, we discovered a significant drop in > performance for the compression algorithms (up to 10%) when compared > to 8u152. > > Here's a summary of the results and instructions on how to run the > benchmarks: https://github.com/martint/aircompressor/tree/perf > > These are the outputs of JMH's perfasm profiler: > > Java 8u152: https://github.com/martint/aircompressor/blob/perf/perf-8.txt > Java 9.0.1: https://github.com/martint/aircompressor/blob/perf/perf-9.txt > > The generated assembly looks very different, but as far as I can tell, > it's just different decisions of when and which registers to spill. > > - Martin From dawid.weiss at gmail.com Fri Dec 22 21:40:48 2017 From: dawid.weiss at gmail.com (Dawid Weiss) Date: Fri, 22 Dec 2017 22:40:48 +0100 Subject: Reduced performance in Java 9.0.1 (vs 8u152) In-Reply-To: References: Message-ID: > I tried your JMH specifying +UseParallelGC by JMH annotations and the > performance of 9 seems quite even to 8u131 that I have handy. Just a note: we have observed a similar effect with a (long) computational process which does some minor GCs and logs GC timings at the end. The results are significantly slower with G1GC on both 8 and 9 (the times below are quite repeatable): JDK, GC, Time 8, g1, 3h 25m 9, g1, 3h 22m 8, par (default), 3h 0m The actual in-GC timings reported are much smaller than the overall absolute difference -- ~2 minutes for both. The process is highly concurrent and heavy on computation, I/O... pretty much every aspect you can think of. To be fair to the G1 -- it acts *much* better on larger heaps and low-memory conditions (the default GC on 8 falls into repeated major collections and effectively stalls the process). Dawid > > Maybe you could try this for yourself and see how it goes. > > Regards, > Eric > > > On 12/22/2017 12:59 PM, Martin Traverso wrote: >> >> Hi, >> >> We're in the process of migrating and qualifying Presto >> (http://prestodb.io) to build and run on Java 9. One of the key dependencies >> is a library of pure-java compression and decompression algorithms >> (http://github.com/airlift/aircompressor). >> >> In the course of trying to understand the performance characteristics when >> running on Java 9, we discovered a significant drop in performance for the >> compression algorithms (up to 10%) when compared to 8u152. >> >> Here's a summary of the results and instructions on how to run the >> benchmarks: https://github.com/martint/aircompressor/tree/perf >> >> These are the outputs of JMH's perfasm profiler: >> >> Java 8u152: https://github.com/martint/aircompressor/blob/perf/perf-8.txt >> Java 9.0.1: https://github.com/martint/aircompressor/blob/perf/perf-9.txt >> >> The generated assembly looks very different, but as far as I can tell, >> it's just different decisions of when and which registers to spill. >> >> - Martin > > From mtraverso at gmail.com Fri Dec 22 22:12:41 2017 From: mtraverso at gmail.com (Martin Traverso) Date: Fri, 22 Dec 2017 14:12:41 -0800 Subject: Reduced performance in Java 9.0.1 (vs 8u152) In-Reply-To: References: Message-ID: Yes, I'm aware of that change. This code is allocation-free, so I wasn't expecting that to be a factor. I'll rerun the benchmarks with that and report back. - Martin > On Dec 22, 2017, at 1:20 PM, Eric Caspole wrote: > > Hi Martin, > > As you may know, JEP 248 made G1 the default collector for 9 where it was ParallelGC earlier: http://openjdk.java.net/jeps/248 > > I tried your JMH specifying +UseParallelGC by JMH annotations and the performance of 9 seems quite even to 8u131 that I have handy. > > Maybe you could try this for yourself and see how it goes. > > Regards, > Eric > >> On 12/22/2017 12:59 PM, Martin Traverso wrote: >> Hi, >> >> We're in the process of migrating and qualifying Presto (http://prestodb.io) to build and run on Java 9. One of the key dependencies is a library of pure-java compression and decompression algorithms (http://github.com/airlift/aircompressor). >> >> In the course of trying to understand the performance characteristics when running on Java 9, we discovered a significant drop in performance for the compression algorithms (up to 10%) when compared to 8u152. >> >> Here's a summary of the results and instructions on how to run the benchmarks: https://github.com/martint/aircompressor/tree/perf >> >> These are the outputs of JMH's perfasm profiler: >> >> Java 8u152: https://github.com/martint/aircompressor/blob/perf/perf-8.txt >> Java 9.0.1: https://github.com/martint/aircompressor/blob/perf/perf-9.txt >> >> The generated assembly looks very different, but as far as I can tell, it's just different decisions of when and which registers to spill. >> >> - Martin > From uschindler at apache.org Fri Dec 22 23:26:55 2017 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 23 Dec 2017 00:26:55 +0100 Subject: Reduced performance in Java 9.0.1 (vs 8u152) In-Reply-To: References: Message-ID: <008301d37b7c$5e377410$1aa65c30$@apache.org> Hi, Allocation free does not mean that it is not affected by G1GC. As G1GC is using more parallelity it also needs to add more checks / barriers into the code that also affects stuff that does not do allocations. So in general, by using G1GC I have seen slowdowns of up to 10% for code only does calculations. This is (by the way) one reason, why Elasticsearch people still recommend to use CMS collector with generally small heap sizes (Elasticsearch - or better said Apache Lucene does most stuff including expensive calculations outside of heap in mmapped files). Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > bounces at openjdk.java.net] On Behalf Of Martin Traverso > Sent: Friday, December 22, 2017 11:13 PM > To: Eric Caspole > Cc: hotspot-compiler-dev at openjdk.java.net > Subject: Re: Reduced performance in Java 9.0.1 (vs 8u152) > > Yes, I'm aware of that change. This code is allocation-free, so I wasn't > expecting that to be a factor. I'll rerun the benchmarks with that and report > back. > > - Martin > > > On Dec 22, 2017, at 1:20 PM, Eric Caspole > wrote: > > > > Hi Martin, > > > > As you may know, JEP 248 made G1 the default collector for 9 where it was > ParallelGC earlier: http://openjdk.java.net/jeps/248 > > > > I tried your JMH specifying +UseParallelGC by JMH annotations and the > performance of 9 seems quite even to 8u131 that I have handy. > > > > Maybe you could try this for yourself and see how it goes. > > > > Regards, > > Eric > > > >> On 12/22/2017 12:59 PM, Martin Traverso wrote: > >> Hi, > >> > >> We're in the process of migrating and qualifying Presto > (http://prestodb.io) to build and run on Java 9. One of the key dependencies > is a library of pure-java compression and decompression algorithms > (http://github.com/airlift/aircompressor). > >> > >> In the course of trying to understand the performance characteristics > when running on Java 9, we discovered a significant drop in performance for > the compression algorithms (up to 10%) when compared to 8u152. > >> > >> Here's a summary of the results and instructions on how to run the > benchmarks: https://github.com/martint/aircompressor/tree/perf > >> > >> These are the outputs of JMH's perfasm profiler: > >> > >> Java 8u152: https://github.com/martint/aircompressor/blob/perf/perf- > 8.txt > >> Java 9.0.1: https://github.com/martint/aircompressor/blob/perf/perf- > 9.txt > >> > >> The generated assembly looks very different, but as far as I can tell, it's > just different decisions of when and which registers to spill. > >> > >> - Martin > > From dean.long at oracle.com Sat Dec 23 01:48:57 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 22 Dec 2017 17:48:57 -0800 Subject: RFR: 8193930: [JVMCI] calling ResolvedTypeType.getClassInitializer on an array type crashes In-Reply-To: <2DF84EC9-4DBF-4502-A80D-93788EC22350@oracle.com> References: <5FBBC1E7-8321-41F2-BBBD-A1122AEC950C@oracle.com> <7e14d962-b1cd-ad73-893c-5bf064d228dc@oracle.com> <2DF84EC9-4DBF-4502-A80D-93788EC22350@oracle.com> Message-ID: <3b02e8ae-d078-eaaf-c35d-3aae4511fb4a@oracle.com> On 12/22/17 9:30 AM, Doug Simon wrote: > >> On 22 Dec 2017, at 17:59, dean.long at oracle.com wrote: >> >> On 12/22/17 2:05 AM, Doug Simon wrote: >> >>>> On 21 Dec 2017, at 19:44, dean.long at oracle.com wrote: >>>> >>>> Instead of >>>> >>>> >>>> 998 if (klass->is_array_klass()) { >>>> >>>> 999 return NULL; >>>> 1000 } >>>> 1001 InstanceKlass* iklass = (InstanceKlass*) klass; >>>> how about >>>> >>>> 998 if (!klass->is_instance_klass()) { >>>> 999 return NULL; >>>> 1000 } >>>> 1001 InstanceKlass* iklass = InstanceKlass::cast(klass); >>> Thanks for the suggestion (and review). I've updated the webrev to include it. >> I don't see the use of InstanceKlass::cast() in the update. > Sorry - I missed that was part of the suggested change (in addition to changing the `if` test). > > While fixing that, I also noticed that I should be using InstanceKlass::cast in getImplementor as well. > > Please double check that the webrev for jvmciCompilerToVM.cpp now looks right. Looks good. dl > -Doug > >> dl >> >>> -Doug >>> >>>> On 12/21/17 4:33 AM, Doug Simon wrote: >>>>> Please review this simple fix for a VM crash when calling ResolvedTypeType.getClassInitializer on an array type. >>>>> >>>>> In addition to fixing the code for ResolvedTypeType.getClassInitializer, this patch also makes CompilerToVM.getImplementor more robust in case it is called with a ResolvedjavaType representing a non-interface type. >>>>> >>>>> Lastly, there are a few minor comment formatting changes that were made automatically by Eclipse. I'd like to keep them as Eclipse is the preferred tool for developing JVMCI code. >>>>> >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8193930 >>>>> http://cr.openjdk.java.net/~dnsimon/8193930/ >>>>> >>>>> >>>>> -Doug From dean.long at oracle.com Sat Dec 23 01:53:02 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 22 Dec 2017 17:53:02 -0800 Subject: RFR(XS) 8191852: Null pointer dereference in ciKlass::get_Klass of ciKlass.hpp:58 In-Reply-To: References: <7601725d-93e0-ce53-f75d-633ab3284d43@oracle.com> <3e60610c-5c35-2584-115f-da4117c037ef@oracle.com> <12681129-02df-59f2-8315-7462d7e92d5d@oracle.com> <60d2661b-2c1b-e7a1-ffe9-a068cd4dbe85@oracle.com> Message-ID: <00482e96-a39f-4ee1-19e6-aa32e83d464e@oracle.com> On 12/22/17 12:22 PM, Vladimir Kozlov wrote: > Good. > > One tiny thing. Can you use 'Klass* ' instead of 'Klass *'?: > > Klass *field_holder > Sure. > No need for new review. > Thanks Vladimir. dl > Thanks, > Vladimir > > On 12/21/17 5:59 PM, dean.long at oracle.com wrote: >> New webrev: >> >> http://cr.openjdk.java.net/~dlong/8191852/webrev.2 >> >> My experiment to simplify get_instance_klass() and friends failed. >> Parfait failed to identify possible null dereferences, even new ones >> that I introduced as a test, so went with the minimal fix instead. It >> only addresses the following error: >> >> Error: Null pointer dereference >> ??? Null pointer dereference [null-pointer-deref] (CWE 476): >> ?????? Read from null pointer ((ciMetadata*)this) >> ???????? at line 58 of src/hotspot/share/ci/ciKlass.hpp in function >> 'ciKlass::get_Klass'. >> ?????????? Null pointer introduced at line 207 of >> src/hotspot/share/ci/ciEnv.hpp in function 'ciEnv::get_instance_klass'. >> ?????????? Constant 'NULL' passed into function ciKlass::get_Klass, >> argument this, from call at line 240 of >> src/hotspot/share/ci/ciField.cpp in function 'ciField::initialize_from'. >> ?????????? Function ciEnv::get_instance_klass may return constant >> 'NULL' at line 207, called at line 237. >> >> dl >> >> >> On 12/13/17 4:20 PM, Vladimir Kozlov wrote: >>> On 12/13/17 3:09 PM, dean.long at oracle.com wrote: >>>> On 12/13/17 1:08 PM, Vladimir Kozlov wrote: >>>> >>>>> On 12/13/17 12:45 PM, dean.long at oracle.com wrote: >>>>>> https://bugs.openjdk.java.net/browse/JDK-8191852 >>>>>> http://cr.openjdk.java.net/~dlong/8191852/webrev/ >>>>>> >>>>>> Our static analysis tool was complaining about a possible null >>>>>> pointer dereference in ciKlass::get_Klass(), because of this code: >>>>>> >>>>>> 237.??? ? _holder = >>>>>> CURRENT_ENV->get_instance_klass(fd->field_holder()); >>>>>> [...] >>>>>> 240.??? ? Klass* k = _holder->get_Klass(); >>>>>> >>>>>> so I added NULL checks in get_instance_klass and a few other >>>>>> similar functions. >>>>> >>>>> No, you don't ;) >>>> >>>> Yes, you're right.? Sorry about that :-) >>>> >>>>> You replaced NULL checks which return NULL with asserts. It is not >>>>> the same. Are you sure that in all those cases we will not get NULL? >>>> >>>> It didn't show up in my testing.? But what I could try is to remove >>>> the asserts and rerun the static analysis.? Then >>>> get_instance_klass() would be: >>>> >>>> ?? ciInstanceKlass* get_instance_klass(Klass* o) { >>>> ???? return get_metadata(o)->as_instance_klass(); >>>> ?? } >>>> >>>> In the first example above, static analysis would need to verify >>>> that fd->field_holder() can never return NULL.? If that sounds >>>> reasonable, I'll rerun the static analysis. >>> >>> Yes, it is reasonable. >>> >>> Thanks, >>> Vladimir >>> >>>> >>>> dl >>>> >>>>> >>>>> Thanks, >>>>> Vladimir >>>>> >>>>>> >>>>>> dl >>>> >> From igor.veresov at oracle.com Sat Dec 23 02:40:37 2017 From: igor.veresov at oracle.com (Igor Veresov) Date: Fri, 22 Dec 2017 18:40:37 -0800 Subject: Reduced performance in Java 9.0.1 (vs 8u152) In-Reply-To: References: Message-ID: <53ADCD6C-6EF3-4FEF-9D02-8D06ABB0EB9A@oracle.com> The barriers are substantially more complicated though. igor > On Dec 22, 2017, at 2:12 PM, Martin Traverso wrote: > > Yes, I'm aware of that change. This code is allocation-free, so I wasn't expecting that to be a factor. I'll rerun the benchmarks with that and report back. > > - Martin > >> On Dec 22, 2017, at 1:20 PM, Eric Caspole wrote: >> >> Hi Martin, >> >> As you may know, JEP 248 made G1 the default collector for 9 where it was ParallelGC earlier: http://openjdk.java.net/jeps/248 >> >> I tried your JMH specifying +UseParallelGC by JMH annotations and the performance of 9 seems quite even to 8u131 that I have handy. >> >> Maybe you could try this for yourself and see how it goes. >> >> Regards, >> Eric >> >>> On 12/22/2017 12:59 PM, Martin Traverso wrote: >>> Hi, >>> >>> We're in the process of migrating and qualifying Presto (http://prestodb.io) to build and run on Java 9. One of the key dependencies is a library of pure-java compression and decompression algorithms (http://github.com/airlift/aircompressor). >>> >>> In the course of trying to understand the performance characteristics when running on Java 9, we discovered a significant drop in performance for the compression algorithms (up to 10%) when compared to 8u152. >>> >>> Here's a summary of the results and instructions on how to run the benchmarks: https://github.com/martint/aircompressor/tree/perf >>> >>> These are the outputs of JMH's perfasm profiler: >>> >>> Java 8u152: https://github.com/martint/aircompressor/blob/perf/perf-8.txt >>> Java 9.0.1: https://github.com/martint/aircompressor/blob/perf/perf-9.txt >>> >>> The generated assembly looks very different, but as far as I can tell, it's just different decisions of when and which registers to spill. >>> >>> - Martin >> From dean.long at oracle.com Sat Dec 23 06:04:16 2017 From: dean.long at oracle.com (dean.long at oracle.com) Date: Fri, 22 Dec 2017 22:04:16 -0800 Subject: RFR(XS) 8191854: Null pointer dereference in methodData.hpp:462 In-Reply-To: References: Message-ID: <35418b8a-fee9-1ffa-cb09-340873888712@oracle.com> Thanks Vladimir. dl On 12/22/17 12:23 PM, Vladimir Kozlov wrote: > Good. > > Thanks, > Vladimir > > On 12/21/17 6:52 PM, dean.long at oracle.com wrote: >> https://bugs.openjdk.java.net/browse/JDK-8191854 >> http://cr.openjdk.java.net/~dlong/8191854/webrev/ >> >> This fixes a possible null pointer dereference here: >> >> ?????????? int count = >> mdo->bci_to_data(branch_bci)->as_JumpData()->taken(); >> ?????????? tty->print_cr("back branch count = %d", count); >> >> if bci_to_data() returns NULL. >> >> dl From mtraverso at gmail.com Sat Dec 23 08:16:59 2017 From: mtraverso at gmail.com (Martin Traverso) Date: Sat, 23 Dec 2017 08:16:59 +0000 Subject: Reduced performance in Java 9.0.1 (vs 8u152) In-Reply-To: <53ADCD6C-6EF3-4FEF-9D02-8D06ABB0EB9A@oracle.com> References: <53ADCD6C-6EF3-4FEF-9D02-8D06ABB0EB9A@oracle.com> Message-ID: I'm not sure I understand why it would need to insert barriers in this code, though. It's effectively a single method that doesn't access any state besides a couple of byte[] that are passed in (no shared state, no object/field references, etc). Other than the safepoint polling on loop backedges, there should be no "external interference". In the generated assembly (https://github.com/martint/aircompressor/blob/perf/perf-9.txt), which instructions correspond to barriers? In any case, I re-ran the benchmarks using G1 on both Java 8 and 9 and the results are very similar to what I observed initially. I updated the page with the outputs of the latest runs, in case you want to take a look: https://github.com/martint/aircompressor/tree/perf Thanks, - Martin On Fri, Dec 22, 2017 at 7:29 PM Igor Veresov wrote: > The barriers are substantially more complicated though. > > igor > > > On Dec 22, 2017, at 2:12 PM, Martin Traverso > wrote: > > > > Yes, I'm aware of that change. This code is allocation-free, so I wasn't > expecting that to be a factor. I'll rerun the benchmarks with that and > report back. > > > > - Martin > > > >> On Dec 22, 2017, at 1:20 PM, Eric Caspole > wrote: > >> > >> Hi Martin, > >> > >> As you may know, JEP 248 made G1 the default collector for 9 where it > was ParallelGC earlier: http://openjdk.java.net/jeps/248 > >> > >> I tried your JMH specifying +UseParallelGC by JMH annotations and the > performance of 9 seems quite even to 8u131 that I have handy. > >> > >> Maybe you could try this for yourself and see how it goes. > >> > >> Regards, > >> Eric > >> > >>> On 12/22/2017 12:59 PM, Martin Traverso wrote: > >>> Hi, > >>> > >>> We're in the process of migrating and qualifying Presto ( > http://prestodb.io) to build and run on Java 9. One of the key > dependencies is a library of pure-java compression and decompression > algorithms (http://github.com/airlift/aircompressor). > >>> > >>> In the course of trying to understand the performance characteristics > when running on Java 9, we discovered a significant drop in performance for > the compression algorithms (up to 10%) when compared to 8u152. > >>> > >>> Here's a summary of the results and instructions on how to run the > benchmarks: https://github.com/martint/aircompressor/tree/perf > >>> > >>> These are the outputs of JMH's perfasm profiler: > >>> > >>> Java 8u152: > https://github.com/martint/aircompressor/blob/perf/perf-8.txt > >>> Java 9.0.1: > https://github.com/martint/aircompressor/blob/perf/perf-9.txt > >>> > >>> The generated assembly looks very different, but as far as I can tell, > it's just different decisions of when and which registers to spill. > >>> > >>> - Martin > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kirk at kodewerk.com Sat Dec 23 10:01:31 2017 From: kirk at kodewerk.com (Kirk Pepperdine) Date: Sat, 23 Dec 2017 11:01:31 +0100 Subject: Reduced performance in Java 9.0.1 (vs 8u152) In-Reply-To: References: Message-ID: <1B4F58FC-3809-412B-90EC-61D2EF1532E2@kodewerk.com> Hi Martin, I?ve setup benchmarks that saturation the CPU creating a zero sum gain condition. Under these conditions you can get some idea of GC overhead by looking at workload throughput times. Under these conditions I?ve found that no matter how you tune G1, the closest you can get to CMS numbers is about 10%. I believe one of the costs is one that you?d experience and that is RSet refinement queue updating. You maybe able to get a handle on this cost by making Eden large enough that your bench doesn?t experience a GC cycle during the run. My guess is this should minimize (hopefully) eliminate RSet refinement costs which may give you an idea on that cost. It?s something that I've not tired myself so might just be a crazy/ridiculous experiment. Kind regards, Kirk > On Dec 22, 2017, at 11:12 PM, Martin Traverso wrote: > > Yes, I'm aware of that change. This code is allocation-free, so I wasn't expecting that to be a factor. I'll rerun the benchmarks with that and report back. > > - Martin > >> On Dec 22, 2017, at 1:20 PM, Eric Caspole wrote: >> >> Hi Martin, >> >> As you may know, JEP 248 made G1 the default collector for 9 where it was ParallelGC earlier: http://openjdk.java.net/jeps/248 >> >> I tried your JMH specifying +UseParallelGC by JMH annotations and the performance of 9 seems quite even to 8u131 that I have handy. >> >> Maybe you could try this for yourself and see how it goes. >> >> Regards, >> Eric >> >>> On 12/22/2017 12:59 PM, Martin Traverso wrote: >>> Hi, >>> >>> We're in the process of migrating and qualifying Presto (http://prestodb.io) to build and run on Java 9. One of the key dependencies is a library of pure-java compression and decompression algorithms (http://github.com/airlift/aircompressor). >>> >>> In the course of trying to understand the performance characteristics when running on Java 9, we discovered a significant drop in performance for the compression algorithms (up to 10%) when compared to 8u152. >>> >>> Here's a summary of the results and instructions on how to run the benchmarks: https://github.com/martint/aircompressor/tree/perf >>> >>> These are the outputs of JMH's perfasm profiler: >>> >>> Java 8u152: https://github.com/martint/aircompressor/blob/perf/perf-8.txt >>> Java 9.0.1: https://github.com/martint/aircompressor/blob/perf/perf-9.txt >>> >>> The generated assembly looks very different, but as far as I can tell, it's just different decisions of when and which registers to spill. >>> >>> - Martin >> From zhongwei.yao at linaro.org Tue Dec 26 04:23:33 2017 From: zhongwei.yao at linaro.org (Zhongwei Yao) Date: Tue, 26 Dec 2017 12:23:33 +0800 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: Message-ID: Hi, Dmitry, Thanks for your feedback! For the performance, I have not noticed any changes in specjbb2015 with my patches. But as Andrew said, it is worth having because of better code size at least. On 22 December 2017 at 19:45, Dmitry Chuyko wrote: > Hi Zhongwei, > > I'm not a reviewer. Thank you, it is a great idea to merge loads or stores > that are issued sequentially. Can you share some more data on that? > > Is there a micro-benchmark or some sample program than shows better > performance on some hardware? > What are the numbers observed? > You mention SPECjbb, is it 2005 or 2015? Which configuration? > In SPECjbb dou you see most sequential series only related to stack work? > > -Dmitry > > > On 12/22/2017 11:02 AM, Zhongwei Yao wrote: >> >> Hi, >> >> We are planning to add AArch64 LDP/STP (load/store pair of registers) >> support in C2 code-gen for better performance. I think the LDP/STP can >> be used in following cases: >> A). For register spill/unspill. We've observed many sequential single >> stack load/store patterns in SPECjbb C2 generated code. >> B). Besides spilling, LDP is also not generated generally for multiple >> LoadI/LoadL nodes. Is there any risk (e.g. implicit check?) for >> combing them together, apart from alignment issue? >> >> I think peephole is the best fit for above optimization (gcc/llvm also >> has such peephole optimization). However, current peephole rules in C2 >> compiler is very limited and I doubt whether it really takes effect - >> AArch64 has disabled peephole optimizations. x86 has enabled it, but >> the instruction sequences to be matched by the rules seems to be very >> uncommon. >> >> To address issue A), since current spill/unspill are handled by common >> MachSpillCopyNode, I was thinking if we could add peephole rule to >> match MachSpillCopyNode, but MachSpillCopyNode has no operands (e.g. >> mem, src, dst) like ordinary instruct defined in aarch64.ad. Even we >> may extract them (mem, src, dst) like in >> MachSpillCopyNode::implementation(), and even we can extend current >> peephole rule grammar, expressing such extraction in peephole's >> grammar is complex. >> So I prefer adding following manually defined method peephole() to >> MachSpillCopyNode: >> >> virtual MachNode *peephole(Block *block, int block_index, >> PhaseRegAlloc *ra_, int &deleted); >> >> This makes the patch relative simple. My prototype patch for A) (still >> some TODOs and hardcodes, but it works fine): >> http://cr.openjdk.java.net/~zyao/RFC_A/ >> >> To address issue B) is somewhat complicated, we need to extend current >> peephole rule syntax, as I don't think current simple syntax works for >> any useful peephole optimizations like ldp/stp opt. >> >> My extended syntax - at least works for ldp/stp optimizations: >> >> ------ >> peepmatch ( loadI loadI ); >> peepconstraint (0.mem$base == 1.mem$base, 0.mem$scale == >> 1.mem$scale, 0.mem$disp - 4 == 1.mem$disp, 0.dst != 1.dst); // new >> grammar is described below. >> peepreplace (loadPairI(1.mem 1.mem)) >> ------ >> >> But for loadPairI, it is hard to express in current instruct semantic. >> Because current instruct in aarch64.ad is defined by a match rule. The >> match rule is an expression tree and made of Ideal Node. >> However, LDP instruction doesn't have Ideal Node (say LoadPair) to >> match. And adding load pair node to arch-independent Ideal node seems >> strange. >> >> My proposed solution is: add a special arch dependent operand like >> iRegIpair: >> >> ------ >> operand iRegIpair(iRegI reg1, iRegI reg2) >> %{ >> constraint(ALLOC_IN_RC(any_reg32)); >> op_cost(0); >> format %{ "pair: reg1, reg2"%}; // hard coded format for now. >> interface(REG_INTER); >> %} >> ------ >> >> This needs to update ADLC to support iRegIpair operand. Because unlike >> current operand which has 1 register, iRegIpair has 2. >> >> Then use it as loadPairI's operand type like: >> >> ------ >> instruct loadPairI(indOffI mem, iRegIpair dst) >> %{ >> match(Set dst mem); //no Ideal Node in match rule. >> ... >> >> %} >> ------ >> >> Then we can use loadPairI in peephole rule's "peepreplace". >> >> Since only constraints between operands are supported in peephole >> rule. But to check whether the adjacent loads are loaded from adjacent >> memory address, we need to check operand's member, like (0.mem$disp - >> 4 == 1.mem$disp), My solution is: add new grammar like 0.mem$disp to >> extract member in operand in ADLC (peep_constraint_parse()). >> >> Another issue for peephole optimization is that it only matches >> adjacent instructions in the same basic block. This leads to many >> missing matches when loads are not scheduled to adjacent. >> So I propose to delay peephole phase to the place just before final >> code emit (the fill_buffer() function). This place is after >> instruction scheduling. So after instruction scheduling, we could >> match more adjacent loads. >> >> My draft patch to address B) is at: >> http://cr.openjdk.java.net/~zyao/RFC_B/ >> >> What do you think? Welcome any feedback! >> > -- Best regards, Zhongwei From zhongwei.yao at linaro.org Tue Dec 26 04:24:42 2017 From: zhongwei.yao at linaro.org (Zhongwei Yao) Date: Tue, 26 Dec 2017 12:24:42 +0800 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> References: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> Message-ID: Hi, Andrew, Thanks for your review! On 23 December 2017 at 00:02, Andrew Haley wrote: > Hi, > > On 22/12/17 08:02, Zhongwei Yao wrote: > >> My draft patch to address B) is at: >> http://cr.openjdk.java.net/~zyao/RFC_B/ >> >> What do you think? Welcome any feedback! > > I wonder if merging ld/st pairs could be handled by the > MacroAssembler. I was also thinking about merging it in assembler. My concern was that assembler usually does not do optimisation. However, I've taken a quick check and I think it should be doable in assembler. For example, we can merge ldr in assembler's ldr instruct definition by checking if the previous instruct meets the constraints. For the previous instruction, we can record it in Instruction_aarch64 class's destructor (if it is ld/st instruction, record it. if not, clear it.). What do you think? If it is OK, I'll work out a prototype for merging ldr in assembler. >MachSpillCopyNode::peephole looks very complicated. > If you handled ldp/stp conversion in MacroAssembler then it'd work > everywhere, for any adjacent pair of loads or stores, not just for > spills in C2. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- Best regards, Zhongwei From aph at redhat.com Tue Dec 26 10:13:48 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 Dec 2017 10:13:48 +0000 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> Message-ID: On 26/12/17 04:24, Zhongwei Yao wrote: > I was also thinking about merging it in assembler. My concern was that > assembler usually does not do optimisation. > > However, I've taken a quick check and I think it should be doable in > assembler. For example, we can merge ldr in assembler's ldr instruct > definition by checking if the previous instruct meets the constraints. > For the previous instruction, we can record it in Instruction_aarch64 > class's destructor (if it is ld/st instruction, record it. if not, > clear it.). > > What do you think? If it is OK, I'll work out a prototype for merging > ldr in assembler. Try doing it in MacroAssembler. MacroAssembler::membar is an example of where we already merge instructions. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From zhongwei.yao at linaro.org Wed Dec 27 04:05:29 2017 From: zhongwei.yao at linaro.org (Zhongwei Yao) Date: Wed, 27 Dec 2017 12:05:29 +0800 Subject: [aarch64-port-dev ] [RFC] ldp/stp peephole optimizations In-Reply-To: References: <84895bf8-f476-3194-1b89-b272611b842c@redhat.com> Message-ID: OK, I'll give a try doing it in MacroAssembler. On 26 December 2017 at 18:13, Andrew Haley wrote: > On 26/12/17 04:24, Zhongwei Yao wrote: >> I was also thinking about merging it in assembler. My concern was that >> assembler usually does not do optimisation. >> >> However, I've taken a quick check and I think it should be doable in >> assembler. For example, we can merge ldr in assembler's ldr instruct >> definition by checking if the previous instruct meets the constraints. >> For the previous instruction, we can record it in Instruction_aarch64 >> class's destructor (if it is ld/st instruction, record it. if not, >> clear it.). >> >> What do you think? If it is OK, I'll work out a prototype for merging >> ldr in assembler. > > Try doing it in MacroAssembler. MacroAssembler::membar is an example of > where we already merge instructions. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 -- Best regards, Zhongwei From hohensee at amazon.com Wed Dec 27 20:20:47 2017 From: hohensee at amazon.com (Hohensee, Paul) Date: Wed, 27 Dec 2017 20:20:47 +0000 Subject: RFR 8192004: InspectedFrame.materializeVirtualObjects only updates locals with new objects In-Reply-To: <5A3D581B.8080601@oracle.com> References: <5A3BE1E2.6030105@oracle.com> <5A3D581B.8080601@oracle.com> Message-ID: In vframe_hp.cpp: In jvmtiDeferredocalVariableSet::update_monitors, the calculation of lock_index int lock_index = val->index() - (method()->max_locals() + method()->max_stack()); looks wrong. If lock_index is supposed to be zero-based, then method()->max_stack() should be subtracted from val->index(), vis int lock_index = val->index() - (method()->max_locals() - method()->max_stack()); A terrifically minor nit, but using ?l? as the induction variable instead of ?i? is a bit odd. ( Otherwise fine. Thanks, Paul On 12/22/17, 11:09 AM, "hotspot-compiler-dev on behalf of Tom Rodriguez" wrote: Could I get some reviews? This doesn't change the way the logic behaves for the core use of JVMTI. It just extends the encoding so that numbers after the locals are interpreted as expression stack and monitor values. I believe there are existing tests of the JVMTI set locals part and JVMCI is the only only consumer of the monitor and expression stack part. tom Tom Rodriguez wrote: > JVMCI adds the ability to introspect on deoptimized frames which > requires early materialization of escape analyzed objects. The > jvmtiDeferredLocalVariableSet machinery is reused to capture the local > updates required for this. The existing code only updates locals, > leaving the stack and monitor information with out of date values. This > can lead to deadlocks and incorrect execution. The fix is to slightly > generalize jvmtiDeferredLocalVariableSet to handle expression stack and > monitor slots. Tested with new graal regression test > https://github.com/graalvm/graal/blob/7fd37bde8955780a57049964d87a51aa2407d86b/compiler/src/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/HotSpotStackIntrospectionTest.java > and previously failing Truffle use cases. I assume the new test case > will come across with a normal graal update. The clean mach5 run is in > the bug report. > > http://cr.openjdk.java.net/~never/8192004/webrev > https://bugs.openjdk.java.net/browse/JDK-8192004 From dmitrij.pochepko at bell-sw.com Thu Dec 28 14:03:35 2017 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 28 Dec 2017 17:03:35 +0300 Subject: RFR(S): 8194256 - AARCH64: SIMD shift instructions are incorrectly encoded Message-ID: Hi all, please review small patch for 8194256 - AARCH64: SIMD shift instructions are incorrectly encoded I've noticed SIMD shift instructions wrong encoding when trying to use it. An intrinsic I was working on, generated incorrect assembly code with wrong shift value. Existing code just copy "shift" bits into instruction bits(immh:immb), however, according to spec, it should be encoded as follows: SIMD type : 8B when immh = 0001 , Q = 0 16B when immh = 0001 , Q = 1 4H when immh = 001x , Q = 0 8H when immh = 001x , Q = 1 2S when immh = 01xx , Q = 0 4S when immh = 01xx , Q = 1 2D when immh = 1xxx , Q = 1 is encoded as follows: for ushr and sshr: (16-UInt(immh:immb)) when immh = 0001 (32-UInt(immh:immb)) when immh = 001x (64-UInt(immh:immb)) when immh = 01xx (128-UInt(immh:immb)) when immh = 1xxx for shl: (UInt(immh:immb)-8) when immh = 0001 (UInt(immh:immb)-16) when immh = 001x (UInt(immh:immb)-32) when immh = 01xx (UInt(immh:immb)-64) when immh = 1xxx So, I've modified respective instruction generation code. webrev: http://cr.openjdk.java.net/~dpochepk/8194256/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8194256 I've checked this patch by generating intrinsic which use these instructions and verified assembly code. Thanks, Dmitrij From aph at redhat.com Fri Dec 29 10:27:20 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 Dec 2017 10:27:20 +0000 Subject: [aarch64-port-dev ] RFR(S): 8194256 - AARCH64: SIMD shift instructions are incorrectly encoded In-Reply-To: References: Message-ID: <42e77930-3021-e274-240c-7819eb3cfc1f@redhat.com> On 28/12/17 14:03, Dmitrij Pochepko wrote: > > webrev: http://cr.openjdk.java.net/~dpochepk/8194256/webrev.01/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8194256 > > > I've checked this patch by generating intrinsic which use these > instructions and verified assembly code. Great catch. (I'll note that this mistake would not have been possible with the integer instructions, which are tested against the GNU assembler's encodings whenever we run a debug build.) The resulting logic is complex and very difficult to understand, but I can see that's not your fault. Hopefully no-one will ever have to look at this code again. OK, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671