From ivan.gerasimov at oracle.com Fri Sep 1 06:59:36 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 31 Aug 2017 23:59:36 -0700 Subject: [8u-dev] Request for Approval to backport: 6977426: sun/tools tests can intermittently fail to find app's Java pid Message-ID: Hello! May I get an approval to backport this test-only fix, which reduces the number of false negatives. The fix applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-6977426 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/beb1329b3c21 Jdk9 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030410.html -- With kind regards, Ivan Gerasimov From sean.coffey at oracle.com Fri Sep 1 09:41:34 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 1 Sep 2017 10:41:34 +0100 Subject: [8u-dev] Request for Approval to backport: 6977426: sun/tools tests can intermittently fail to find app's Java pid In-Reply-To: References: Message-ID: <886f302c-0eff-5293-609f-f8c9c0416efb@oracle.com> Approved. Regards, Sean. On 01/09/17 07:59, Ivan Gerasimov wrote: > Hello! > > May I get an approval to backport this test-only fix, which reduces > the number of false negatives. > > The fix applies cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-6977426 > > Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/beb1329b3c21 > > Jdk9 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2014-December/030410.html > From dmitry.markov at oracle.com Fri Sep 1 14:09:20 2017 From: dmitry.markov at oracle.com (Dmitry Markov) Date: Fri, 1 Sep 2017 15:09:20 +0100 Subject: [8u-dev] Request for approval 8177414: Missing key events on Mac Os Message-ID: Hello, Can I get an approval to port the fix for 8177414 to jdk8u-dev, please? The jdk10 patch applies cleanly. JBS: https://bugs.openjdk.java.net/browse/JDK-8177414 Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-August/012930.html jdk10 changeset: http://hg.openjdk.java.net/jdk10/client/jdk/rev/8c41faaf67ba Thanks, Dmitry From sean.coffey at oracle.com Fri Sep 1 14:34:44 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 1 Sep 2017 15:34:44 +0100 Subject: [8u-dev] Request for approval 8177414: Missing key events on Mac Os In-Reply-To: References: Message-ID: <3ec3494e-160a-94b9-10c1-fcb696733298@oracle.com> Approved. Regards, Sean. On 01/09/17 15:09, Dmitry Markov wrote: > Hello, > > Can I get an approval to port the fix for 8177414 to jdk8u-dev, please? The jdk10 patch applies cleanly. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8177414 > Review thread: http://mail.openjdk.java.net/pipermail/awt-dev/2017-August/012930.html > jdk10 changeset: http://hg.openjdk.java.net/jdk10/client/jdk/rev/8c41faaf67ba > > Thanks, > Dmitry From rob.mckenna at oracle.com Tue Sep 5 15:02:17 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 5 Sep 2017 16:02:17 +0100 Subject: [8u-dev] Request for enhancement backport approval for : 8170157: Enable unlimited cryptographic policy by default in OracleJDK In-Reply-To: References: Message-ID: <20170905150217.GA4927@vimes> Thanks Sean, this has been submitted for approval. -Rob On 18/08/17 02:57, Se?n Coffey wrote: > I'd like to backport the following enhancement to jdk8u-dev : > > JDK-8157561 allowed us to ship the unlimited policy files in the upcoming > 8u152 release. We should now look at enabling unlimited crypto by default. > > https://bugs.openjdk.java.net/browse/JDK-8170157 > > -- > Regards, > Sean. > From ivan.gerasimov at oracle.com Tue Sep 5 21:15:40 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Tue, 5 Sep 2017 14:15:40 -0700 Subject: [8u-dev] Request for approval to backport: 8179086: java.time.temporal.ValueRange has poor hashCode() Message-ID: Hello! Would you please approve backporting this fix to jdk8u-dev? The unshuffled patch applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8179086 Jdk 10 change: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/d017015f402c Jdk 10 review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047271.html Thanks in advance! -- With kind regards, Ivan Gerasimov From david.buck at oracle.com Tue Sep 5 22:27:57 2017 From: david.buck at oracle.com (David Buck) Date: Wed, 6 Sep 2017 07:27:57 +0900 Subject: [8u-dev] Request for approval to backport: 8179086: java.time.temporal.ValueRange has poor hashCode() In-Reply-To: References: Message-ID: <7e18fdc0-069a-8eaa-b96e-1e95ab696a12@oracle.com> approved Cheers, -Buck On 2017/09/06 6:15, Ivan Gerasimov wrote: > Hello! > > Would you please approve backporting this fix to jdk8u-dev? > > The unshuffled patch applies cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179086 > Jdk 10 change: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/d017015f402c > Jdk 10 review: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-April/047271.html > > Thanks in advance! > From kevin.walls at oracle.com Wed Sep 6 11:49:36 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Wed, 6 Sep 2017 12:49:36 +0100 Subject: [8u-dev] Request for approval: 8177026: jvm.dll file version not updated since 8u72 Message-ID: <5460ab06-4bbc-1ecc-97ee-e69826f05cca@oracle.com> Hi, I'd like approval for a small change in a windows-only build/resource file for the hotspot jvm.dll. We have been using stale FileVersion information for a while. The 8u bug is: 8177026: jvm.dll file version not updated since 8u72 https://bugs.openjdk.java.net/browse/JDK-8177026 HS_VER stopped being updated with: https://bugs.openjdk.java.net/browse/JDK-8079410 8079410: Hotspot version to share the same update and build version from JDK ...in which we stop updating hotspot/make/hotspot_version with the new hotspot version numbers at each build, and just use JDK versions (hotspot update and build numbers simply followed the JDK numbers).? However the Windows build uses that state info. The change wanted is a clean backport of a few lines, which are a subset from a bundle of build-related changes in one bug in jdk9. (The 8 bug is marked 9-na because at that point it was not a problem in 9...) The 9 bug is: https://bugs.openjdk.java.net/browse/JDK-8149647 8149647: Incremental enhancements from build-infra In hotspot/src/os/windows/vm/version.rc we should not use HS_VER as that is stale.? We should use JDK_VER. Diff for 8u/hotspot is below, which follows the version.rc change from 8149647. Many thanks Kevin bash-4.2$ cd jdk8u/hotspot bash-4.2$ hg diff diff -r 16939858a716 src/os/windows/vm/version.rc --- a/src/os/windows/vm/version.rc????? Mon Aug 21 11:34:41 2017 -0400 +++ b/src/os/windows/vm/version.rc????? Tue Aug 22 13:03:28 2017 -0700 @@ -36,7 +36,7 @@ ?// ?VS_VERSION_INFO VERSIONINFO - FILEVERSION??? HS_VER + FILEVERSION??? JDK_VER ? PRODUCTVERSION JDK_VER ? FILEFLAGSMASK 0x3fL ?#ifdef _DEBUG @@ -56,7 +56,7 @@ ???????? BEGIN ???????????? VALUE "CompanyName", XSTR(HS_COMPANY) "\0" ???????????? VALUE "FileDescription", XSTR(HS_FILEDESC) "\0" -??????????? VALUE "FileVersion",????? XSTR(HS_DOTVER) "\0" +??????????? VALUE "FileVersion", XSTR(JDK_DOTVER) "\0" ???????????? VALUE "Full Version", XSTR(HS_BUILD_ID) "\0" ??????????? VALUE "InternalName", XSTR(HS_INTERNAL_NAME) "\0" ???????????? VALUE "LegalCopyright", XSTR(HS_COPYRIGHT) "\0" bash-4.2$ From rob.mckenna at oracle.com Wed Sep 6 15:24:42 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 6 Sep 2017 16:24:42 +0100 Subject: [8u Communication] 8u162 Timeline In-Reply-To: <20170906142828.GA5183@vimes> References: <20170906142828.GA5183@vimes> Message-ID: <20170906152442.GD5183@vimes> The JDK 8 Updates master forest has been gathering fixes for 8u162 since RDP2 of 8u152. I'd like to propose the following timeline for that release: * June 2017 [8u-dev forest begins collecting 8u162 fixes] * End Oct 2017 [RampDown 2] * Jan 2018 [GA] This should release in parallel with the 8u161 CPU release and contain all fixes from that CPU. I'll update the Project page with these proposed dates shortly. As always, these dates are preliminary and are subject to change. -Rob From david.buck at oracle.com Thu Sep 7 10:12:09 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 7 Sep 2017 19:12:09 +0900 Subject: [8u-dev] RFA: 8072428: Enable UseLoopCounter ergonomically if on-stack-replacement is enabled Message-ID: Hi! Please approve the backport of this trivial fix to 8u-dev. The JDK 9 patch applies cleanly as-is to the 8u-dev forest. bug report: https://bugs.openjdk.java.net/browse/JDK-8072428 jdk 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ae0634c0652a jdk 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-April/022469.html I have manually tested the fix. Default and hotspot jprt testsets also run and passed. Cheers, -Buck From david.buck at oracle.com Thu Sep 7 11:33:07 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 7 Sep 2017 20:33:07 +0900 Subject: [8u-dev] RFA: 8166742: SIGFPE in C2 Loop IV elimination Message-ID: Hi! Please approve the backport of this trivial fix to 8u-dev. The JDK 9 patch applies cleanly as-is to the 8u-dev forest. bug report: https://bugs.openjdk.java.net/browse/JDK-8166742 jdk 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6214eb051a30 jdk 9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024517.html I have manually tested the fix with the testcase included in the changeset. Default and hotspot jprt testsets also run and passed. Cheers, -Buck From rob.mckenna at oracle.com Thu Sep 7 13:15:00 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 7 Sep 2017 14:15:00 +0100 Subject: [8u-dev] RFA: 8072428: Enable UseLoopCounter ergonomically if on-stack-replacement is enabled In-Reply-To: References: Message-ID: <20170907131500.GA3477@tecra> Approved -Rob On 07/09/17 07:12, David Buck wrote: > Hi! > > Please approve the backport of this trivial fix to 8u-dev. The JDK 9 patch > applies cleanly as-is to the 8u-dev forest. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8072428 > > jdk 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ae0634c0652a > > jdk 9 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-April/022469.html > > I have manually tested the fix. Default and hotspot jprt testsets also run > and passed. > > Cheers, > -Buck From rob.mckenna at oracle.com Thu Sep 7 13:15:23 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 7 Sep 2017 14:15:23 +0100 Subject: [8u-dev] RFA: 8166742: SIGFPE in C2 Loop IV elimination In-Reply-To: References: Message-ID: <20170907131523.GB3477@tecra> Approved -Rob On 07/09/17 08:33, David Buck wrote: > Hi! > > Please approve the backport of this trivial fix to 8u-dev. The JDK 9 patch > applies cleanly as-is to the 8u-dev forest. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8166742 > > jdk 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6214eb051a30 > > jdk 9 review thread: > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-September/024517.html > > I have manually tested the fix with the testcase included in the changeset. > Default and hotspot jprt testsets also run and passed. > > Cheers, > -Buck From david.buck at oracle.com Thu Sep 7 14:02:19 2017 From: david.buck at oracle.com (David Buck) Date: Thu, 7 Sep 2017 23:02:19 +0900 Subject: [8u-dev] RFA: 8023667: SA: ExceptionBlob and other C2 classes not available in client VM Message-ID: <4f797fb2-0cf3-388c-ccc3-a1e21c105731@oracle.com> Hi! Please approve the backport of this trivial serviceability fix to 8u-dev. The JDK 9 patch applies cleanly as-is to the 8u-dev forest. bug report: https://bugs.openjdk.java.net/browse/JDK-8023667 jdk 9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/46eeb3056482 jdk 9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-January/014043.html http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014050.html I have manually tested the fix. Default and hotspot jprt testsets also run and passed. Cheers, -Buck From dalibor.topic at oracle.com Thu Sep 7 14:09:28 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 7 Sep 2017 16:09:28 +0200 Subject: [8u-dev] RFA: 8023667: SA: ExceptionBlob and other C2 classes not available in client VM In-Reply-To: <4f797fb2-0cf3-388c-ccc3-a1e21c105731@oracle.com> References: <4f797fb2-0cf3-388c-ccc3-a1e21c105731@oracle.com> Message-ID: Thanks, Buck - approved. cheers, dalibor topic On 07.09.2017 16:02, David Buck wrote: > Hi! > > Please approve the backport of this trivial serviceability fix to > 8u-dev. The JDK 9 patch applies cleanly as-is to the 8u-dev forest. > > bug report: > https://bugs.openjdk.java.net/browse/JDK-8023667 > > jdk 9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/46eeb3056482 > > jdk 9 review thread: > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-January/014043.html > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-February/014050.html > > > I have manually tested the fix. Default and hotspot jprt testsets also > run and passed. > > Cheers, > -Buck -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From ivan.gerasimov at oracle.com Thu Sep 7 22:02:50 2017 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Thu, 7 Sep 2017 15:02:50 -0700 Subject: [8u-dev] Request for Approval to Backport: 8137255, 8157896 Message-ID: Hello! Would you please approve these two test bug fixes, which are to prevent intermediate timeouts of the test TestDSAGenParameterSpec? The fixes apply cleanly with the exception of the change in ProblemList.txt, which is not needed. Also, the fix for JDK-8157898 (SupportedDSAParamGen.java failed with timeout) that was pushed together with JDK-8157896 is excluded from the backport. Bug: https://bugs.openjdk.java.net/browse/JDK-8157896 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fa50a3c4aac9 Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014060.html Bug: https://bugs.openjdk.java.net/browse/JDK-8137255 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4f8e07921d19 Jdk9 review: http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013987.html -- With kind regards, Ivan Gerasimov From prasanta.sadhukhan at oracle.com Fri Sep 8 06:28:12 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 8 Sep 2017 11:58:12 +0530 Subject: [8u-dev] Request for approval to backport JDK-8182402:Tooltip for Desktop button is in English when non-English locale is set Message-ID: <248d33e2-610b-5b3b-d662-09162ed6d7d0@oracle.com> Hi All, Can I please get an approval to backport the fix for JDK-8182402 to jdk8u-dev? JBS: https://bugs.openjdk.java.net/browse/JDK-8182402 webrev: http://cr.openjdk.java.net/~psadhukhan/8182402/8u/webrev/ 9 Review thread: http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007511.html JDK9 changset:/ /http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/08ec9924fcbf Regards Prasanta From sean.coffey at oracle.com Fri Sep 8 07:28:23 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 8 Sep 2017 08:28:23 +0100 Subject: [8u-dev] Request for Approval to Backport: 8137255, 8157896 In-Reply-To: References: Message-ID: <09c8b611-5fd9-2765-af09-d88ab948cb80@oracle.com> Looks good. Approved. regards, Sean. On 07/09/2017 23:02, Ivan Gerasimov wrote: > Hello! > > Would you please approve these two test bug fixes, which are to > prevent intermediate timeouts of the test TestDSAGenParameterSpec? > > The fixes apply cleanly with the exception of the change in > ProblemList.txt, which is not needed. > > Also, the fix for JDK-8157898 (SupportedDSAParamGen.java failed with > timeout) that was pushed together with JDK-8157896 is excluded from > the backport. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8157896 > Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/fa50a3c4aac9 > Jdk9 review: > http://mail.openjdk.java.net/pipermail/security-dev/2016-June/014060.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8137255 > Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/4f8e07921d19 > Jdk9 review: > http://mail.openjdk.java.net/pipermail/security-dev/2016-May/013987.html > From sean.coffey at oracle.com Fri Sep 8 07:33:19 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 8 Sep 2017 08:33:19 +0100 Subject: [8u-dev] Request for approval to backport JDK-8182402:Tooltip for Desktop button is in English when non-English locale is set In-Reply-To: <248d33e2-610b-5b3b-d662-09162ed6d7d0@oracle.com> References: <248d33e2-610b-5b3b-d662-09162ed6d7d0@oracle.com> Message-ID: Approved - subject to the jdk8u-dev patch being the same as the JDK 9 patch (minus modular path shuffling). Please make clear in future approval requests. regards, Sean. On 08/09/2017 07:28, Prasanta Sadhukhan wrote: > Hi All, > > Can I please get an approval to backport the fix for JDK-8182402 to > jdk8u-dev? > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8182402 > webrev: > http://cr.openjdk.java.net/~psadhukhan/8182402/8u/webrev/ > 9 Review thread: > http://mail.openjdk.java.net/pipermail/swing-dev/2017-June/007511.html > JDK9 changset:/ > /http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/08ec9924fcbf > > Regards > Prasanta From magnus.ihse.bursie at oracle.com Fri Sep 8 09:59:45 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 8 Sep 2017 11:59:45 +0200 Subject: [8u-dev] Request for approval: 8177026: jvm.dll file version not updated since 8u72 In-Reply-To: <5460ab06-4bbc-1ecc-97ee-e69826f05cca@oracle.com> References: <5460ab06-4bbc-1ecc-97ee-e69826f05cca@oracle.com> Message-ID: This looks good to me from a build perspective. /Magnus On 2017-09-06 13:49, Kevin Walls wrote: > Hi, > > I'd like approval for a small change in a windows-only build/resource > file for the hotspot jvm.dll. We have been using stale FileVersion > information for a while. > > The 8u bug is: > > 8177026: jvm.dll file version not updated since 8u72 > https://bugs.openjdk.java.net/browse/JDK-8177026 > > HS_VER stopped being updated with: > https://bugs.openjdk.java.net/browse/JDK-8079410 > 8079410: Hotspot version to share the same update and build version > from JDK > > ...in which we stop updating hotspot/make/hotspot_version with the new > hotspot version numbers at each build, and just use JDK versions > (hotspot update and build numbers simply followed the JDK numbers). > However the Windows build uses that state info. > > > The change wanted is a clean backport of a few lines, which are a > subset from a bundle of build-related changes in one bug in jdk9. (The > 8 bug is marked 9-na because at that point it was not a problem in 9...) > > The 9 bug is: > https://bugs.openjdk.java.net/browse/JDK-8149647 > 8149647: Incremental enhancements from build-infra > > > In hotspot/src/os/windows/vm/version.rc we should not use HS_VER as > that is stale. We should use JDK_VER. > > Diff for 8u/hotspot is below, which follows the version.rc change from > 8149647. > > Many thanks > Kevin > > > bash-4.2$ cd jdk8u/hotspot > bash-4.2$ hg diff > diff -r 16939858a716 src/os/windows/vm/version.rc > --- a/src/os/windows/vm/version.rc Mon Aug 21 11:34:41 2017 -0400 > +++ b/src/os/windows/vm/version.rc Tue Aug 22 13:03:28 2017 -0700 > @@ -36,7 +36,7 @@ > // > > VS_VERSION_INFO VERSIONINFO > - FILEVERSION HS_VER > + FILEVERSION JDK_VER > PRODUCTVERSION JDK_VER > FILEFLAGSMASK 0x3fL > #ifdef _DEBUG > @@ -56,7 +56,7 @@ > BEGIN > VALUE "CompanyName", XSTR(HS_COMPANY) "\0" > VALUE "FileDescription", XSTR(HS_FILEDESC) "\0" > - VALUE "FileVersion", XSTR(HS_DOTVER) "\0" > + VALUE "FileVersion", XSTR(JDK_DOTVER) "\0" > VALUE "Full Version", XSTR(HS_BUILD_ID) "\0" > VALUE "InternalName", XSTR(HS_INTERNAL_NAME) "\0" > VALUE "LegalCopyright", XSTR(HS_COPYRIGHT) "\0" > bash-4.2$ > > From kevin.walls at oracle.com Fri Sep 8 12:33:20 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 8 Sep 2017 13:33:20 +0100 Subject: [8u-dev] Request for approval: 8177026: jvm.dll file version not updated since 8u72 In-Reply-To: References: <5460ab06-4bbc-1ecc-97ee-e69826f05cca@oracle.com> Message-ID: <17c88063-83e8-9476-7905-70841f2c794d@oracle.com> Thanks Magnus! On 08/09/2017 10:59, Magnus Ihse Bursie wrote: > This looks good to me from a build perspective. > > /Magnus > > On 2017-09-06 13:49, Kevin Walls wrote: >> Hi, >> >> I'd like approval for a small change in a windows-only build/resource >> file for the hotspot jvm.dll. We have been using stale FileVersion >> information for a while. >> >> The 8u bug is: >> >> 8177026: jvm.dll file version not updated since 8u72 >> https://bugs.openjdk.java.net/browse/JDK-8177026 >> >> HS_VER stopped being updated with: >> https://bugs.openjdk.java.net/browse/JDK-8079410 >> 8079410: Hotspot version to share the same update and build version >> from JDK >> >> ...in which we stop updating hotspot/make/hotspot_version with the >> new hotspot version numbers at each build, and just use JDK versions >> (hotspot update and build numbers simply followed the JDK numbers).? >> However the Windows build uses that state info. >> >> >> The change wanted is a clean backport of a few lines, which are a >> subset from a bundle of build-related changes in one bug in jdk9. >> (The 8 bug is marked 9-na because at that point it was not a problem >> in 9...) >> >> The 9 bug is: >> https://bugs.openjdk.java.net/browse/JDK-8149647 >> 8149647: Incremental enhancements from build-infra >> >> >> In hotspot/src/os/windows/vm/version.rc we should not use HS_VER as >> that is stale.? We should use JDK_VER. >> >> Diff for 8u/hotspot is below, which follows the version.rc change >> from 8149647. >> >> Many thanks >> Kevin >> >> >> bash-4.2$ cd jdk8u/hotspot >> bash-4.2$ hg diff >> diff -r 16939858a716 src/os/windows/vm/version.rc >> --- a/src/os/windows/vm/version.rc????? Mon Aug 21 11:34:41 2017 -0400 >> +++ b/src/os/windows/vm/version.rc????? Tue Aug 22 13:03:28 2017 -0700 >> @@ -36,7 +36,7 @@ >> ?// >> >> ?VS_VERSION_INFO VERSIONINFO >> - FILEVERSION??? HS_VER >> + FILEVERSION??? JDK_VER >> ? PRODUCTVERSION JDK_VER >> ? FILEFLAGSMASK 0x3fL >> ?#ifdef _DEBUG >> @@ -56,7 +56,7 @@ >> ???????? BEGIN >> ???????????? VALUE "CompanyName", XSTR(HS_COMPANY) "\0" >> ???????????? VALUE "FileDescription", XSTR(HS_FILEDESC) "\0" >> -??????????? VALUE "FileVersion",????? XSTR(HS_DOTVER) "\0" >> +??????????? VALUE "FileVersion", XSTR(JDK_DOTVER) "\0" >> ???????????? VALUE "Full Version", XSTR(HS_BUILD_ID) "\0" >> ??????????? VALUE "InternalName", XSTR(HS_INTERNAL_NAME) "\0" >> ???????????? VALUE "LegalCopyright", XSTR(HS_COPYRIGHT) "\0" >> bash-4.2$ >> >> > From rob.mckenna at oracle.com Fri Sep 8 14:51:07 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 8 Sep 2017 15:51:07 +0100 Subject: [8u-dev] Request for approval: 8177026: jvm.dll file version not updated since 8u72 In-Reply-To: <17c88063-83e8-9476-7905-70841f2c794d@oracle.com> References: <5460ab06-4bbc-1ecc-97ee-e69826f05cca@oracle.com> <17c88063-83e8-9476-7905-70841f2c794d@oracle.com> Message-ID: <20170908145107.GA3907@vimes> Approved -Rob On 08/09/17 01:33, Kevin Walls wrote: > Thanks Magnus! > > > > On 08/09/2017 10:59, Magnus Ihse Bursie wrote: > >This looks good to me from a build perspective. > > > >/Magnus > > > >On 2017-09-06 13:49, Kevin Walls wrote: > >>Hi, > >> > >>I'd like approval for a small change in a windows-only build/resource > >>file for the hotspot jvm.dll. We have been using stale FileVersion > >>information for a while. > >> > >>The 8u bug is: > >> > >>8177026: jvm.dll file version not updated since 8u72 > >>https://bugs.openjdk.java.net/browse/JDK-8177026 > >> > >>HS_VER stopped being updated with: > >>https://bugs.openjdk.java.net/browse/JDK-8079410 > >>8079410: Hotspot version to share the same update and build version from > >>JDK > >> > >>...in which we stop updating hotspot/make/hotspot_version with the new > >>hotspot version numbers at each build, and just use JDK versions > >>(hotspot update and build numbers simply followed the JDK numbers).? > >>However the Windows build uses that state info. > >> > >> > >>The change wanted is a clean backport of a few lines, which are a subset > >>from a bundle of build-related changes in one bug in jdk9. (The 8 bug is > >>marked 9-na because at that point it was not a problem in 9...) > >> > >>The 9 bug is: > >>https://bugs.openjdk.java.net/browse/JDK-8149647 > >>8149647: Incremental enhancements from build-infra > >> > >> > >>In hotspot/src/os/windows/vm/version.rc we should not use HS_VER as that > >>is stale.? We should use JDK_VER. > >> > >>Diff for 8u/hotspot is below, which follows the version.rc change from > >>8149647. > >> > >>Many thanks > >>Kevin > >> > >> > >>bash-4.2$ cd jdk8u/hotspot > >>bash-4.2$ hg diff > >>diff -r 16939858a716 src/os/windows/vm/version.rc > >>--- a/src/os/windows/vm/version.rc????? Mon Aug 21 11:34:41 2017 -0400 > >>+++ b/src/os/windows/vm/version.rc????? Tue Aug 22 13:03:28 2017 -0700 > >>@@ -36,7 +36,7 @@ > >>?// > >> > >>?VS_VERSION_INFO VERSIONINFO > >>- FILEVERSION??? HS_VER > >>+ FILEVERSION??? JDK_VER > >>? PRODUCTVERSION JDK_VER > >>? FILEFLAGSMASK 0x3fL > >>?#ifdef _DEBUG > >>@@ -56,7 +56,7 @@ > >>???????? BEGIN > >>???????????? VALUE "CompanyName", XSTR(HS_COMPANY) "\0" > >>???????????? VALUE "FileDescription", XSTR(HS_FILEDESC) "\0" > >>-??????????? VALUE "FileVersion",????? XSTR(HS_DOTVER) "\0" > >>+??????????? VALUE "FileVersion", XSTR(JDK_DOTVER) "\0" > >>???????????? VALUE "Full Version", XSTR(HS_BUILD_ID) "\0" > >>??????????? VALUE "InternalName", XSTR(HS_INTERNAL_NAME) "\0" > >>???????????? VALUE "LegalCopyright", XSTR(HS_COPYRIGHT) "\0" > >>bash-4.2$ > >> > >> > > > From kevin.walls at oracle.com Fri Sep 8 15:24:04 2017 From: kevin.walls at oracle.com (Kevin Walls) Date: Fri, 8 Sep 2017 16:24:04 +0100 Subject: [8u-dev] Request for approval: 8177026: jvm.dll file version not updated since 8u72 In-Reply-To: <20170908145107.GA3907@vimes> References: <5460ab06-4bbc-1ecc-97ee-e69826f05cca@oracle.com> <17c88063-83e8-9476-7905-70841f2c794d@oracle.com> <20170908145107.GA3907@vimes> Message-ID: Thanks Rob! On 08/09/2017 15:51, Rob McKenna wrote: > Approved > > -Rob > > On 08/09/17 01:33, Kevin Walls wrote: >> Thanks Magnus! >> >> >> >> On 08/09/2017 10:59, Magnus Ihse Bursie wrote: >>> This looks good to me from a build perspective. >>> >>> /Magnus >>> >>> On 2017-09-06 13:49, Kevin Walls wrote: >>>> Hi, >>>> >>>> I'd like approval for a small change in a windows-only build/resource >>>> file for the hotspot jvm.dll. We have been using stale FileVersion >>>> information for a while. >>>> >>>> The 8u bug is: >>>> >>>> 8177026: jvm.dll file version not updated since 8u72 >>>> https://bugs.openjdk.java.net/browse/JDK-8177026 >>>> >>>> HS_VER stopped being updated with: >>>> https://bugs.openjdk.java.net/browse/JDK-8079410 >>>> 8079410: Hotspot version to share the same update and build version from >>>> JDK >>>> >>>> ...in which we stop updating hotspot/make/hotspot_version with the new >>>> hotspot version numbers at each build, and just use JDK versions >>>> (hotspot update and build numbers simply followed the JDK numbers). >>>> However the Windows build uses that state info. >>>> >>>> >>>> The change wanted is a clean backport of a few lines, which are a subset >>> >from a bundle of build-related changes in one bug in jdk9. (The 8 bug is >>>> marked 9-na because at that point it was not a problem in 9...) >>>> >>>> The 9 bug is: >>>> https://bugs.openjdk.java.net/browse/JDK-8149647 >>>> 8149647: Incremental enhancements from build-infra >>>> >>>> >>>> In hotspot/src/os/windows/vm/version.rc we should not use HS_VER as that >>>> is stale.? We should use JDK_VER. >>>> >>>> Diff for 8u/hotspot is below, which follows the version.rc change from >>>> 8149647. >>>> >>>> Many thanks >>>> Kevin >>>> >>>> >>>> bash-4.2$ cd jdk8u/hotspot >>>> bash-4.2$ hg diff >>>> diff -r 16939858a716 src/os/windows/vm/version.rc >>>> --- a/src/os/windows/vm/version.rc????? Mon Aug 21 11:34:41 2017 -0400 >>>> +++ b/src/os/windows/vm/version.rc????? Tue Aug 22 13:03:28 2017 -0700 >>>> @@ -36,7 +36,7 @@ >>>> ?// >>>> >>>> ?VS_VERSION_INFO VERSIONINFO >>>> - FILEVERSION??? HS_VER >>>> + FILEVERSION??? JDK_VER >>>> ? PRODUCTVERSION JDK_VER >>>> ? FILEFLAGSMASK 0x3fL >>>> ?#ifdef _DEBUG >>>> @@ -56,7 +56,7 @@ >>>> ???????? BEGIN >>>> ???????????? VALUE "CompanyName", XSTR(HS_COMPANY) "\0" >>>> ???????????? VALUE "FileDescription", XSTR(HS_FILEDESC) "\0" >>>> -??????????? VALUE "FileVersion",????? XSTR(HS_DOTVER) "\0" >>>> +??????????? VALUE "FileVersion", XSTR(JDK_DOTVER) "\0" >>>> ???????????? VALUE "Full Version", XSTR(HS_BUILD_ID) "\0" >>>> ??????????? VALUE "InternalName", XSTR(HS_INTERNAL_NAME) "\0" >>>> ???????????? VALUE "LegalCopyright", XSTR(HS_COPYRIGHT) "\0" >>>> bash-4.2$ >>>> >>>> From tim.yu at nokia-sbell.com Tue Sep 19 08:50:01 2017 From: tim.yu at nokia-sbell.com (Yu, Tim (NSB - CN/Chengdu)) Date: Tue, 19 Sep 2017 08:50:01 +0000 Subject: OpenJDK OOM issue - Message-ID: Hi OpenJDK dev group We meet one issue that the VM failed to initialize. The error log is as below. We checked both memory usage and thread number. They do not hit the limit. So could you please help to confirm why "java.lang.OutOfMemoryError: unable to create new native thread" error occurs? Many thanks. " on Sep 18 11:05:04 EEST 2017 2 or first INFO log missing: Error occurred during initialization of VM java.lang.OutOfMemoryError: unable to create new native thread Error occurred during initialization of VM java.lang.OutOfMemoryError: unable to create new native thread 1. Memory Usage MemFree: 898332 kB >From below core file generated during OMM, it can be seen about 900M physical memory available during that time. 2 Thread number sh-4.1$ ps -eLf|wc -l 5326 sh-4.1$ ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 43497 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 43497 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Br, Tim From aph at redhat.com Tue Sep 19 10:44:27 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Sep 2017 11:44:27 +0100 Subject: OpenJDK OOM issue - In-Reply-To: References: Message-ID: On 19/09/17 09:50, Yu, Tim (NSB - CN/Chengdu) wrote: > We meet one issue that the VM failed to initialize. The error log is as below. We checked both memory usage and thread number. They do not hit the limit. So could you please help to confirm why "java.lang.OutOfMemoryError: unable to create new native thread" error occurs? Many thanks. Hard to say. If I had something I could reproduce and debug, I could tell you the answer in a few minutes. Otherwise it's going to be hard. strace might help. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Tue Sep 19 10:46:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 19 Sep 2017 20:46:08 +1000 Subject: OpenJDK OOM issue - In-Reply-To: References: Message-ID: <8f7f43fd-fbee-fd54-21ab-d43e24e8a694@oracle.com> Hi Tim, On 19/09/2017 6:50 PM, Yu, Tim (NSB - CN/Chengdu) wrote: > Hi OpenJDK dev group This is better discussed on hotspot-dev, so redirecting there. > We meet one issue that the VM failed to initialize. The error log is as below. We checked both memory usage and thread number. They do not hit the limit. So could you please help to confirm why "java.lang.OutOfMemoryError: unable to create new native thread" error occurs? Many thanks. Unfortunately there is no way to tell. As you indicate there appears to be enough memory, and there appear to be enough threads/processes available for creation. Does this happen regularly or was this a one-of failure? You really need to see the exact state of the machine at the time this happened. David > " > on Sep 18 11:05:04 EEST 2017 2 or first INFO log missing: Error occurred during initialization of VM > java.lang.OutOfMemoryError: unable to create new native thread > Error occurred during initialization of VM > java.lang.OutOfMemoryError: unable to create new native thread > > 1. Memory Usage > MemFree: 898332 kB > From below core file generated during OMM, it can be seen about 900M physical memory available during that time. > > > 2 Thread number > > sh-4.1$ ps -eLf|wc -l > 5326 > > > sh-4.1$ ulimit -a > core file size (blocks, -c) 0 > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 43497 > max locked memory (kbytes, -l) 64 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 10240 > cpu time (seconds, -t) unlimited > max user processes (-u) 43497 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > Br, > Tim > > > > From poonam.bajaj at oracle.com Tue Sep 19 13:08:57 2017 From: poonam.bajaj at oracle.com (Poonam Parhar) Date: Tue, 19 Sep 2017 06:08:57 -0700 (PDT) Subject: OpenJDK OOM issue - In-Reply-To: <8f7f43fd-fbee-fd54-21ab-d43e24e8a694@oracle.com> References: <8f7f43fd-fbee-fd54-21ab-d43e24e8a694@oracle.com> Message-ID: Hello Tim, With CompressedOops enabled (which is enabled by default with 64-bit JVM), the Java heap may get placed in the lower virtual address space leaving very little space for the native heap allocations, and that can cause these kinds of failures even when there is lot of native memory available. Please read details here: https://blogs.oracle.com/poonam/running-on-a-64bit-platform-and-still-running-out-of-memory You can check the output collected with -XX:+PrintGCDetails that would show where your Java Heap is being based at. Thanks, Poonam > -----Original Message----- > From: David Holmes > Sent: Tuesday, September 19, 2017 3:46 AM > To: Yu, Tim (NSB - CN/Chengdu) > Cc: jdk8-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net; hotspot-dev > developers; Shen, David (NSB - CN/Chengdu) > Subject: Re: OpenJDK OOM issue - > > Hi Tim, > > On 19/09/2017 6:50 PM, Yu, Tim (NSB - CN/Chengdu) wrote: > > Hi OpenJDK dev group > > This is better discussed on hotspot-dev, so redirecting there. > > > We meet one issue that the VM failed to initialize. The error log is > as below. We checked both memory usage and thread number. They do not > hit the limit. So could you please help to confirm why > "java.lang.OutOfMemoryError: unable to create new native thread" error > occurs? Many thanks. > > Unfortunately there is no way to tell. As you indicate there appears to > be enough memory, and there appear to be enough threads/processes > available for creation. > > Does this happen regularly or was this a one-of failure? You really > need to see the exact state of the machine at the time this happened. > > David > > > " > > on Sep 18 11:05:04 EEST 2017 2 or first INFO log missing: Error > > occurred during initialization of VM > > java.lang.OutOfMemoryError: unable to create new native thread Error > > occurred during initialization of VM > > java.lang.OutOfMemoryError: unable to create new native thread > > > > 1. Memory Usage > > MemFree: 898332 kB > > From below core file generated during OMM, it can be seen about 900M > physical memory available during that time. > > > > > > 2 Thread number > > > > sh-4.1$ ps -eLf|wc -l > > 5326 > > > > > > sh-4.1$ ulimit -a > > core file size (blocks, -c) 0 > > data seg size (kbytes, -d) unlimited > > scheduling priority (-e) 0 > > file size (blocks, -f) unlimited > > pending signals (-i) 43497 > > max locked memory (kbytes, -l) 64 > > max memory size (kbytes, -m) unlimited > > open files (-n) 1024 > > pipe size (512 bytes, -p) 8 > > POSIX message queues (bytes, -q) 819200 > > real-time priority (-r) 0 > > stack size (kbytes, -s) 10240 > > cpu time (seconds, -t) unlimited > > max user processes (-u) 43497 > > virtual memory (kbytes, -v) unlimited > > file locks (-x) unlimited > > > > Br, > > Tim > > > > > > > > From aph at redhat.com Tue Sep 19 13:13:10 2017 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 Sep 2017 14:13:10 +0100 Subject: OpenJDK OOM issue - In-Reply-To: References: Message-ID: <99906d91-dea4-dd5f-2d35-f50f9f5264de@redhat.com> On 19/09/17 09:50, Yu, Tim (NSB - CN/Chengdu) wrote: > Hi OpenJDK dev group > > We meet one issue that the VM failed to initialize. The error log is as below. We checked both memory usage and thread number. They do not hit the limit. So could you please help to confirm why "java.lang.OutOfMemoryError: unable to create new native thread" error occurs? Many thanks. What OS is this? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From tim.yu at nokia-sbell.com Wed Sep 20 08:44:23 2017 From: tim.yu at nokia-sbell.com (Yu, Tim (NSB - CN/Chengdu)) Date: Wed, 20 Sep 2017 08:44:23 +0000 Subject: OpenJDK OOM issue - In-Reply-To: <99906d91-dea4-dd5f-2d35-f50f9f5264de@redhat.com> References: <99906d91-dea4-dd5f-2d35-f50f9f5264de@redhat.com> Message-ID: Hi All Thank you all for the quick response. The environment information is listed as below, could you please help to further check? 1. What OS is this? # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.9 (Santiago) # uname -a Linux cloudyvm16 2.6.32-696.6.3.el6.x86_64 #1 SMP Fri Jun 30 13:24:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux 2.GC log is listed as below. The heap information cannot be printed out in gc-2017_09_20-09_21_15.log when OOM happens. In gc-2017_09_20-09_21_17.log, you can see the heap begins with 0x0000000787380000 and it should be not the first 4G virtual memory address. -rw-r--r-- 1 19477 Sep 20 09:21 hs_err_pid12678.log -rw-r--r-- 1 570 Sep 20 09:21 gc-2017_09_20-09_21_15.log -rw-r--r-- 1 17741 Sep 20 09:21 hs_err_pid12706.log -rw-r--r-- 1 1297 Sep 20 09:21 gc-2017_09_20-09_21_17.log -rw-r--r-- 1 1722 Sep 20 09:21 gc-2017_09_20-09_21_18.log -rw-r--r-- 1 1297 Sep 20 09:21 gc-2017_09_20-09_21_19.log -rw-r--r-- 1 1297 Sep 20 09:21 gc-2017_09_20-09_21_20.log 3. This issue happens occasionally but frequently. We periodically launch a JAVA program to use JMX to monitor service status of another JAVA service. Br, Tim -----Original Message----- From: Andrew Haley [mailto:aph at redhat.com] Sent: Tuesday, September 19, 2017 9:13 PM To: Yu, Tim (NSB - CN/Chengdu) ; jdk8-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net Cc: Shen, David (NSB - CN/Chengdu) Subject: Re: OpenJDK OOM issue - On 19/09/17 09:50, Yu, Tim (NSB - CN/Chengdu) wrote: > Hi OpenJDK dev group > > We meet one issue that the VM failed to initialize. The error log is as below. We checked both memory usage and thread number. They do not hit the limit. So could you please help to confirm why "java.lang.OutOfMemoryError: unable to create new native thread" error occurs? Many thanks. What OS is this? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From david.holmes at oracle.com Wed Sep 20 11:43:02 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 20 Sep 2017 21:43:02 +1000 Subject: OpenJDK OOM issue - In-Reply-To: References: <99906d91-dea4-dd5f-2d35-f50f9f5264de@redhat.com> Message-ID: Tim, Please note attachments get stripped from the mailing lists. All - please drop the jdk8-dev and jdk8u-dev mailing lists from this and leave it just on hotspot-dev. I've tried to bcc those lists. Thank you. David On 20/09/2017 6:44 PM, Yu, Tim (NSB - CN/Chengdu) wrote: > Hi All > > Thank you all for the quick response. > The environment information is listed as below, could you please help to further check? > > 1. What OS is this? > # cat /etc/redhat-release > Red Hat Enterprise Linux Server release 6.9 (Santiago) > # uname -a > Linux cloudyvm16 2.6.32-696.6.3.el6.x86_64 #1 SMP Fri Jun 30 13:24:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux > > 2.GC log is listed as below. The heap information cannot be printed out in gc-2017_09_20-09_21_15.log when OOM happens. In gc-2017_09_20-09_21_17.log, you can see the heap begins with 0x0000000787380000 and it should be not the first 4G virtual memory address. > -rw-r--r-- 1 19477 Sep 20 09:21 hs_err_pid12678.log > -rw-r--r-- 1 570 Sep 20 09:21 gc-2017_09_20-09_21_15.log > -rw-r--r-- 1 17741 Sep 20 09:21 hs_err_pid12706.log > -rw-r--r-- 1 1297 Sep 20 09:21 gc-2017_09_20-09_21_17.log > -rw-r--r-- 1 1722 Sep 20 09:21 gc-2017_09_20-09_21_18.log > -rw-r--r-- 1 1297 Sep 20 09:21 gc-2017_09_20-09_21_19.log > -rw-r--r-- 1 1297 Sep 20 09:21 gc-2017_09_20-09_21_20.log > > 3. This issue happens occasionally but frequently. We periodically launch a JAVA program to use JMX to monitor service status of another JAVA service. > > Br, > Tim > > > > > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, September 19, 2017 9:13 PM > To: Yu, Tim (NSB - CN/Chengdu) ; jdk8-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Cc: Shen, David (NSB - CN/Chengdu) > Subject: Re: OpenJDK OOM issue - > > On 19/09/17 09:50, Yu, Tim (NSB - CN/Chengdu) wrote: >> Hi OpenJDK dev group >> >> We meet one issue that the VM failed to initialize. The error log is as below. We checked both memory usage and thread number. They do not hit the limit. So could you please help to confirm why "java.lang.OutOfMemoryError: unable to create new native thread" error occurs? Many thanks. > > What OS is this? > From zgu at redhat.com Wed Sep 20 12:10:50 2017 From: zgu at redhat.com (Zhengyu Gu) Date: Wed, 20 Sep 2017 08:10:50 -0400 Subject: OpenJDK OOM issue - In-Reply-To: References: <99906d91-dea4-dd5f-2d35-f50f9f5264de@redhat.com> Message-ID: Hi Tim, Could you upload hs_err_pid###.log files? Thanks, -Zhengyu On 09/20/2017 04:44 AM, Yu, Tim (NSB - CN/Chengdu) wrote: > Hi All > > Thank you all for the quick response. > The environment information is listed as below, could you please help to further check? > > 1. What OS is this? > # cat /etc/redhat-release > Red Hat Enterprise Linux Server release 6.9 (Santiago) > # uname -a > Linux cloudyvm16 2.6.32-696.6.3.el6.x86_64 #1 SMP Fri Jun 30 13:24:18 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux > > 2.GC log is listed as below. The heap information cannot be printed out in gc-2017_09_20-09_21_15.log when OOM happens. In gc-2017_09_20-09_21_17.log, you can see the heap begins with 0x0000000787380000 and it should be not the first 4G virtual memory address. > -rw-r--r-- 1 19477 Sep 20 09:21 hs_err_pid12678.log > -rw-r--r-- 1 570 Sep 20 09:21 gc-2017_09_20-09_21_15.log > -rw-r--r-- 1 17741 Sep 20 09:21 hs_err_pid12706.log > -rw-r--r-- 1 1297 Sep 20 09:21 gc-2017_09_20-09_21_17.log > -rw-r--r-- 1 1722 Sep 20 09:21 gc-2017_09_20-09_21_18.log > -rw-r--r-- 1 1297 Sep 20 09:21 gc-2017_09_20-09_21_19.log > -rw-r--r-- 1 1297 Sep 20 09:21 gc-2017_09_20-09_21_20.log > > 3. This issue happens occasionally but frequently. We periodically launch a JAVA program to use JMX to monitor service status of another JAVA service. > > Br, > Tim > > > > > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, September 19, 2017 9:13 PM > To: Yu, Tim (NSB - CN/Chengdu) ; jdk8-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net > Cc: Shen, David (NSB - CN/Chengdu) > Subject: Re: OpenJDK OOM issue - > > On 19/09/17 09:50, Yu, Tim (NSB - CN/Chengdu) wrote: >> Hi OpenJDK dev group >> >> We meet one issue that the VM failed to initialize. The error log is as below. We checked both memory usage and thread number. They do not hit the limit. So could you please help to confirm why "java.lang.OutOfMemoryError: unable to create new native thread" error occurs? Many thanks. > > What OS is this? > From sean.coffey at oracle.com Thu Sep 21 07:43:57 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 21 Sep 2017 08:43:57 +0100 Subject: Result: New JDK 8 Updates Committer: Ramanand Patil Message-ID: Voting for Ramanand Patil [1] is now closed. Yes: 10 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. regards, Sean. [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2017-August/006870.html From shafi.s.ahmad at oracle.com Fri Sep 22 10:48:59 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Fri, 22 Sep 2017 03:48:59 -0700 (PDT) Subject: [8u] RFA for backport of dependent bugs JDK-8134103 and JDK-6988950 to jdk8u Message-ID: <4f1f9797-d647-4eb5-ab5a-2f289df28342@default> Hi, May I get the approval of clean backport of dependent bugs 1. JDK-8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface 2. JDK-6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) to jdk8u. jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-6988950 jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a579414719c5 jdk9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015840.html jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8134103 jdk10 changeset: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/5e8b28011dd0 jdk10 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-March/021052.html Test: Run jprt -testset hotspot and -testset core Regards, Shafi From shafi.s.ahmad at oracle.com Fri Sep 22 10:49:05 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Fri, 22 Sep 2017 03:49:05 -0700 (PDT) Subject: RFA for backport of JDK-8046778: Better error messages when starting JMX agent via attach or jcmd to jdk8u Message-ID: Hi, May I get the approval of clean backport of ' JDK-8046778: Better error messages when starting JMX agent via attach or jcmd ?to jdk8u-dev. jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8046778 jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/881c1fcf342a jdk9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-June/015021.html Test: Run jprt -testset core Regards, Shafi From volker.simonis at gmail.com Fri Sep 22 12:52:21 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Sep 2017 14:52:21 +0200 Subject: [8u-dev] RFA: 8132374: AIX: fix value of os.version property Message-ID: Hi, can I please get an approval for down-porting "8132374: AIX: fix value of os.version property" from jdk9 to 8u-dev? JBS: https://bugs.openjdk.java.net/browse/JDK-8132374 Review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/thread.html#34630 jdk9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/64b2be1b304c webrev: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/ The change applies cleanly to the 8u-dev/jdk repo modulo the usual directory shuffling. I had to leave out the associated regression test (test/java/lang/System/OsVersionTest.java) because it would require changes to the test infrastructure which aren't available in jdk8u-dev. But I don't think that's a big issue as the test was trivial and the change only affects AIX anyway. Thank you and best regards, Volker From david.buck at oracle.com Fri Sep 22 15:41:54 2017 From: david.buck at oracle.com (David Buck) Date: Sat, 23 Sep 2017 00:41:54 +0900 Subject: RFA for backport of JDK-8046778: Better error messages when starting JMX agent via attach or jcmd to jdk8u In-Reply-To: References: Message-ID: <3925f558-d4d5-1b36-65ce-e4c025e48bae@oracle.com> approved for backport to 8u-dev Cheers, -Buck On 2017/09/22 19:49, Shafi Ahmad wrote: > Hi, > > May I get the approval of clean backport of ' JDK-8046778: Better error messages when starting JMX agent via attach or jcmd ?to jdk8u-dev. > > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8046778 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/881c1fcf342a > jdk9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-June/015021.html > > Test: Run jprt -testset core > > Regards, > Shafi > From sean.coffey at oracle.com Fri Sep 22 15:47:55 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Fri, 22 Sep 2017 16:47:55 +0100 Subject: [8u-dev] RFA: 8132374: AIX: fix value of os.version property In-Reply-To: References: Message-ID: Looks fine Volker. Thanks for managing that port. Approved. Regards, Sean. On 22/09/17 13:52, Volker Simonis wrote: > Hi, > > can I please get an approval for down-porting "8132374: AIX: fix value > of os.version property" from jdk9 to 8u-dev? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8132374 > Review: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/thread.html#34630 > jdk9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/64b2be1b304c > webrev: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/ > > The change applies cleanly to the 8u-dev/jdk repo modulo the usual > directory shuffling. > > I had to leave out the associated regression test > (test/java/lang/System/OsVersionTest.java) because it would require > changes to the test infrastructure which aren't available in > jdk8u-dev. But I don't think that's a big issue as the test was > trivial and the change only affects AIX anyway. > > Thank you and best regards, > Volker From david.buck at oracle.com Fri Sep 22 15:54:00 2017 From: david.buck at oracle.com (David Buck) Date: Sat, 23 Sep 2017 00:54:00 +0900 Subject: [8u] RFA for backport of dependent bugs JDK-8134103 and JDK-6988950 to jdk8u In-Reply-To: <4f1f9797-d647-4eb5-ab5a-2f289df28342@default> References: <4f1f9797-d647-4eb5-ab5a-2f289df28342@default> Message-ID: approved for backport to 8u-dev Cheers, -Buck On 2017/09/22 19:48, Shafi Ahmad wrote: > Hi, > > May I get the approval of clean backport of dependent bugs > 1. JDK-8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an interface > 2. JDK-6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) > to jdk8u. > > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-6988950 > jdk9 changeset: http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a579414719c5 > jdk9 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-November/015840.html > > jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8134103 > jdk10 changeset: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/5e8b28011dd0 > jdk10 review thread: http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-March/021052.html > > Test: Run jprt -testset hotspot and -testset core > > Regards, > Shafi > From volker.simonis at gmail.com Fri Sep 22 16:36:01 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 22 Sep 2017 18:36:01 +0200 Subject: [8u-dev] RFA: 8132374: AIX: fix value of os.version property In-Reply-To: References: Message-ID: Hi Sean, thanks for the quick approval. Here's a link to the 8u webrev which I forgot to include in my initial mail: http://cr.openjdk.java.net/~simonis/webrevs/2017/8132374.8u/ It merely illustrates what I had written before :) I'll push this to 8u-dev then... Regards, Volker On Fri, Sep 22, 2017 at 5:47 PM, Se?n Coffey wrote: > Looks fine Volker. Thanks for managing that port. > > Approved. > > Regards, > Sean. > > > On 22/09/17 13:52, Volker Simonis wrote: >> >> Hi, >> >> can I please get an approval for down-porting "8132374: AIX: fix value >> of os.version property" from jdk9 to 8u-dev? >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8132374 >> Review: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-July/thread.html#34630 >> jdk9: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/64b2be1b304c >> webrev: http://cr.openjdk.java.net/~simonis/webrevs/2015/8132374/ >> >> The change applies cleanly to the 8u-dev/jdk repo modulo the usual >> directory shuffling. >> >> I had to leave out the associated regression test >> (test/java/lang/System/OsVersionTest.java) because it would require >> changes to the test infrastructure which aren't available in >> jdk8u-dev. But I don't think that's a big issue as the test was >> trivial and the change only affects AIX anyway. >> >> Thank you and best regards, >> Volker > > From gustavo.scalet at eldorado.org.br Mon Sep 25 14:02:55 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 25 Sep 2017 14:02:55 +0000 Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Message-ID: <49dadbf6eaea4823926340bc51d56cea@serv031.corp.eldorado.org.br> Hi, Previously I faced some issues when backporting intrinsics to JDK8[1] but after some help, manage to make it work. Despite following those rules related to CCallingConvention and Int -> Long conversion, I still face issues not previously noticed on JDK9 when running SpecJVM2008's crypto.rsa bechmark. [release build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00003fffa0cc6f84, pid=3698, tid=0x00003fff7a34f1a0 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-gut_2017_04_12_09_19-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-ppc64 compressed oops) # Problematic frame: # V [libjvm.so+0x446f84] ConnectionGraph::process_call_arguments(CallNode*)+0x1c4 [slowdebug build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/type.cpp:596 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/gut/jdk8u-dev/hotspot/src/share/vm/opto/type.cpp:596), pid=6793, tid=0x00003fff5847f1a0 # assert(eq(dual_dual)) failed: xdual(xdual()) should be identity Any hints? I see the issue is when calling the last line of this code on runtime.cpp: const TypeFunc* OptoRuntime::montgomeryMultiply_Type() { // create input type (domain) int num_args = 7; int argcnt = num_args; const Type** fields = TypeTuple::fields(argcnt); int argp = TypeFunc::Parms; fields[argp++] = TypePtr::NOTNULL; // a fields[argp++] = TypePtr::NOTNULL; // b fields[argp++] = TypePtr::NOTNULL; // n if (CCallingConventionRequiresIntsAsLongs) { argcnt += 1; // additional placeholders fields[argp++] = TypeLong::LONG; // len fields[argp++] = TypeLong::HALF; // placeholder } else { fields[argp++] = TypeInt::INT; // len } fields[argp++] = TypeLong::LONG; // inv fields[argp++] = Type::HALF; fields[argp++] = TypePtr::NOTNULL; // result assert(argp == TypeFunc::Parms+argcnt, "correct decoding"); const TypeTuple* domain = TypeTuple::make(TypeFunc::Parms+argcnt, fields); Thanks References: [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-April/002970.html -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: sexta-feira, 15 de setembro de 2017 04:39 To: Gustavo Serra Scalet Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics (off-list) Hi Gustavo, you can request backport by sending a [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic to jdk8u-dev at openjdk.java.net But first of all, you need to check if the change applies to 8u and run tests. The following information is needed in the email: Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020534.html Statement: Change applies cleanly or describe which changes were necessary You should also mention that it belongs to 8u102 backport of https://bugs.openjdk.java.net/browse/JDK-8150152 Once it's approved, you can ask a jdk8u reviewer or committer (which I'm not) to push it. Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Donnerstag, 14. September 2017 21:00 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics Hi Martin, Short question about the Montgomery backport to JDK8: > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 > > 14:15:31 2017). The reported performance speedup was calculated by > > > running the following test (TestSquareToLen.java): > > Seems like JDK-8145913 has not been backported, yet. Sorry for not > checking this earlier. So if you want to make RSA really fast, it > should be so much better to backport that one. But I can still sponsor > this change as it may be used elsewhere. Do we have a bug ID for the Montgomery backport to JDK8 so I can track it? If not, should I request that backport or request this intrinsic to be backported (once it's inside of JDK10)? I'm interested in this kind of performance gain. Thanks > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Dienstag, 29. August 2017 22:37 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > Hi Martin, > > New changes: > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ > > Check comments below, please. > > > -----Original Message----- > > From: Doerr, Martin > > > > 1. Sign extending offset and len > > Right, sign and zero extending is equivalent for offset and len > > because they are guaranteed to be >=0 (by checks in Java). But you > > can only rely on bit 32 (IBM notation) to be 0. Bit 0-31 may contain > garbage. > > rldicl was incorrect. My mistake, sorry for that. Correct would be > > rldic which also clears the least significant bits. > > len should also get fixed e.g. by replacing cmpdi by extsw_ in muladd. > > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to > need further changes as it's being cleared with clrldi, which is the > same as rldic with no shift. Therefore it's treated appropriately as > requested for "offset" parameter. Do you agree? > > > 2. Using 8 byte instructions for int The code which feeds stdu is > > endianess specific. Doesn't work on all > > PPC64 platforms. > > You are right. The way I'm building the 64 bits of the register > depends on which kind of endianness it is run. For now it works only > on little endian so I'm adding a switch (just like I did for SHA) to > make it available only on little endian systems. > > > 3.Regarding Andrew's point: Superseded by Montgomery? > > The Montgomery change got backported to jdk8u (JDK-8150152 in 8u102). > > I'd expect the performance improvement of these intrinsics to be > > irrelevant for crypto.rsa. Did you measure with an older jdk8 release? > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 > 2017). The reported performance speedup was calculated by running the > following test (TestSquareToLen.java): > import java.math.BigInteger; > > public class TestSquareToLen { > > public static void main(String args[]) throws Exception { > > int n = 10000000; > if (args.length >=1) { > n = Integer.parseInt(args[0]); > } > > BigInteger b1 = new > BigInteger("3489398092355735908635051498208250392000229831187732085999 > 36 > 7395594183801021468843071391756049207873137016631559837931214754926092 > 22 > 3780292110207609223272184808289336630057735969423726808520641030118116 > 51 > 6440180488338234823908199478965242076358579845520899779963131131540166 > 68 718795349783157384006672542605760392289645528307"); > BigInteger b2 = BigInteger.valueOf(0); > BigInteger check = BigInteger.valueOf(1); > for (int i = 0; i < n; i++) { > b2 = b1.multiply(b1); > if (i == 0) > // Didn't JIT yet. Comparing against interpreted mode > check = b2; > } > if (b2.compareTo(check) == 0) > System.out.println("Check ok!"); > else > System.out.println("Check failed!"); > } > } > > > I got these results on JDK8 on my POWER8 machine: > $ ./javac TestSquareToLen.java > $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 15148.009557 task-clock (msec) # 1.053 CPUs > utilized ( +- 0.48% ) > 2,425 context-switches # 0.160 K/sec > ( +- 5.84% ) > 356 cpu-migrations # 0.023 K/sec > ( +- 3.01% ) > 5,153 page-faults # 0.340 K/sec > ( +- 5.22% ) > 54,536,889,909 cycles # 3.600 GHz > ( +- 0.56% ) (66.68%) > 239,554,105 stalled-cycles-frontend # 0.44% frontend > cycles idle ( +- 4.87% ) (49.90%) > 27,683,316,001 stalled-cycles-backend # 50.76% backend > cycles idle ( +- 0.56% ) (50.17%) > 102,020,229,733 instructions # 1.87 insn per > cycle > # 0.27 stalled > cycles per insn ( +- 0.14% ) (66.94%) > 7,706,072,218 branches # 508.718 M/sec > ( +- 0.23% ) (50.20%) > 456,051,162 branch-misses # 5.92% of all > branches ( +- 0.09% ) (50.07%) > > 14.390840733 seconds time elapsed ( +- 0.09% ) > > $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 11368.141410 task-clock (msec) # 1.045 CPUs > utilized ( +- 0.64% ) > 1,964 context-switches # 0.173 K/sec > ( +- 8.93% ) > 338 cpu-migrations # 0.030 K/sec > ( +- 7.65% ) > 5,627 page-faults # 0.495 K/sec > ( +- 6.15% ) > 41,100,168,967 cycles # 3.615 GHz > ( +- 0.50% ) (66.36%) > 309,052,316 stalled-cycles-frontend # 0.75% frontend > cycles idle ( +- 2.84% ) (49.89%) > 14,188,581,685 stalled-cycles-backend # 34.52% backend > cycles idle ( +- 0.99% ) (50.34%) > 77,846,029,829 instructions # 1.89 insn per > cycle > # 0.18 stalled > cycles per insn ( +- 0.29% ) (66.96%) > 8,435,216,989 branches # 742.005 M/sec > ( +- 0.28% ) (50.17%) > 339,903,936 branch-misses # 4.03% of all > branches ( +- 0.27% ) (49.90%) > > 10.882357546 seconds time elapsed ( +- 0.24% ) > > > (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s (+- > 0.53%) on JDK10) > > I may run for SpecJVM2008's crypto.rsa if you are interested. > > Thank you once again for reviewing this. > > Best regards, > Gustavo > > > (I think the change is still acceptable as the intrinsics could be > > used elsewhere and the implementation also exists on other > > platforms.) > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Mittwoch, 16. August 2017 18:50 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > Hi Martin, > > > > Thanks for dedicated review. It took me a while to be able to work > > on this but I hope to have your points solved. Please check below > > the review as well as my comments quoting your email: > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > > > -----Original Message----- > > > First of all, C2 does not perform sign extend when calling stubs. > > > The int parms need to get zero/sign extended. (Could even be done > > > without extra instructions by replacing sldi -> rldicl, cmpdi -> > > > extsw_ in some > > > cases.) > > > > Does it make a difference on my case? > > > > I guess you are talking about mulAdd preparation code. The only > > aspect I found about him is to force the cast from 32 bits -> 64 > > bits by cleaning higher bits. Offset is a signed integer but it > > can't be > negative anyway. > > > > So I changed from: > > sldi (R5_ARG3, R5_ARG3, 2); > > > > to: > > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > > > > macroAssembler_ppc.cpp: > > > - Indentation should be 2 spaces. > > > > Done > > > > > > > stubGenerator_ppc:cpp: > > > - or_, addi_ should get replaced by orr, addi when CR0 result is > > > not needed. > > > > Done > > > > > - Where is lplw initialized? > > > > It should be initialized with 0, I missed that... > > > > > - I believe that the updating load/store instructions e.g. lwzu > > > don't perform well on some processors. At least using stwu 2 times > > > in the loop doesn't make sense. > > > > You are right. I could manipulate the bits differently and ended up > > with a single stdu in the loop. Neat! Although I could not reduce > > the total number of instructions. > > > > > - Note: It should be possible to use 8 byte instead of 4 byte > > > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > > > requesting to change that because I guess it would make the code > > > very complicated, especially when supporting both endianess > versions. > > > > Yes, that would require a new analysis on this code. May we consider > > it next? As you said, I prefer having an initial version that looks > > as simple as the original java code. > > > > > - The squareToLen stub implementation is very close the Java > > > implementation. So it'd be interesting to understand what C2 > > > doesn't do as well as the hand written assembly code. Do you know > > > that? (Not absolutely necessary for accepting this change as long > > > as the stub is measurably faster.) > > > > I don't know either. Basically I chose doing it because I noticed > > some performance gain on SpecJVM2008 when analyzing X64. Then, > > taking a closer look, I didn't notice any AVX or some special > > instructions on > > X64 so I decided to try it on ppc64 by using some basic assembly. > > > > Thanks > > > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Donnerstag, 10. August 2017 19:22 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? By > > > implementing these intrinsics I noticed a small improvement with > > > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, > > > only when backporting to JDK8 an improvement was noticed. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > > > Motivation for this implementation: > > > https://twitter.com/ijuma/status/698309312498835457 > > > > > > Best regards, > > > Gustavo Serra Scalet From shafi.s.ahmad at oracle.com Mon Sep 25 15:16:00 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 25 Sep 2017 08:16:00 -0700 (PDT) Subject: RFA for backport of JDK-8046778: Better error messages when starting JMX agent via attach or jcmd to jdk8u In-Reply-To: <3925f558-d4d5-1b36-65ce-e4c025e48bae@oracle.com> References: <3925f558-d4d5-1b36-65ce-e4c025e48bae@oracle.com> Message-ID: <350bf4b4-ea09-4fac-be90-93a49d77e79e@default> Thank you Buck. Regards, Shafi > -----Original Message----- > From: David Buck > Sent: Friday, September 22, 2017 9:12 PM > To: Shafi Ahmad ; jdk8u-dev at openjdk.java.net > Subject: Re: RFA for backport of JDK-8046778: Better error messages when > starting JMX agent via attach or jcmd to jdk8u > > approved for backport to 8u-dev > > Cheers, > -Buck > > On 2017/09/22 19:49, Shafi Ahmad wrote: > > Hi, > > > > May I get the approval of clean backport of ' JDK-8046778: Better error > messages when starting JMX agent via attach or jcmd ?to jdk8u-dev. > > > > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-8046778 > > jdk9 changeset: > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/881c1fcf342a > > jdk9 review thread: http://mail.openjdk.java.net/pipermail/serviceability- > dev/2014-June/015021.html > > > > Test: Run jprt -testset core > > > > Regards, > > Shafi > > From shafi.s.ahmad at oracle.com Mon Sep 25 15:16:13 2017 From: shafi.s.ahmad at oracle.com (Shafi Ahmad) Date: Mon, 25 Sep 2017 08:16:13 -0700 (PDT) Subject: [8u] RFA for backport of dependent bugs JDK-8134103 and JDK-6988950 to jdk8u In-Reply-To: References: <4f1f9797-d647-4eb5-ab5a-2f289df28342@default> Message-ID: <2be8db23-3dca-497b-9cbe-517624ff4de9@default> Thank you Buck. Regards, Shafi > -----Original Message----- > From: David Buck > Sent: Friday, September 22, 2017 9:24 PM > To: Shafi Ahmad ; jdk8u-dev at openjdk.java.net > Subject: Re: [8u] RFA for backport of dependent bugs JDK-8134103 and JDK- > 6988950 to jdk8u > > approved for backport to 8u-dev > > Cheers, > -Buck > > On 2017/09/22 19:48, Shafi Ahmad wrote: > > Hi, > > > > May I get the approval of clean backport of dependent bugs > > 1. JDK-8134103: JVMTI_ERROR_WRONG_PHASE(112): on checking for an > interface > > 2. JDK-6988950: JDWP exit error JVMTI_ERROR_WRONG_PHASE(112) to > > jdk8u. > > > > jdk9 bug: https://bugs.openjdk.java.net/browse/JDK-6988950 > > jdk9 changeset: > > http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a579414719c5 > > jdk9 review thread: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2014-Novembe > > r/015840.html > > > > jdk10 bug: https://bugs.openjdk.java.net/browse/JDK-8134103 > > jdk10 changeset: > > http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/5e8b28011dd0 > > jdk10 review thread: > > http://mail.openjdk.java.net/pipermail/serviceability-dev/2017-March/0 > > 21052.html > > > > Test: Run jprt -testset hotspot and -testset core > > > > Regards, > > Shafi > > From martin.doerr at sap.com Mon Sep 25 16:54:36 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 25 Sep 2017 16:54:36 +0000 Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) In-Reply-To: <49dadbf6eaea4823926340bc51d56cea@serv031.corp.eldorado.org.br> References: <49dadbf6eaea4823926340bc51d56cea@serv031.corp.eldorado.org.br> Message-ID: Hi Gustavo, Did you also change library_call? Should be something like (example for multiplyToLen): Node* call = NULL; if (CCallingConventionRequiresIntsAsLongs) { Node* xlen_I2L = ConvI2L(xlen); Node* ylen_I2L = ConvI2L(ylen); Node* zlen_I2L = ConvI2L(zlen); call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen_I2L XTOP, y_start, ylen_I2L XTOP, z_start, zlen_I2L XTOP); } else { call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen, y_start, ylen, z_start, zlen); } Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Montag, 25. September 2017 16:03 To: Doerr, Martin Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Hi, Previously I faced some issues when backporting intrinsics to JDK8[1] but after some help, manage to make it work. Despite following those rules related to CCallingConvention and Int -> Long conversion, I still face issues not previously noticed on JDK9 when running SpecJVM2008's crypto.rsa bechmark. [release build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00003fffa0cc6f84, pid=3698, tid=0x00003fff7a34f1a0 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-gut_2017_04_12_09_19-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-ppc64 compressed oops) # Problematic frame: # V [libjvm.so+0x446f84] ConnectionGraph::process_call_arguments(CallNode*)+0x1c4 [slowdebug build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/type.cpp:596 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/gut/jdk8u-dev/hotspot/src/share/vm/opto/type.cpp:596), pid=6793, tid=0x00003fff5847f1a0 # assert(eq(dual_dual)) failed: xdual(xdual()) should be identity Any hints? I see the issue is when calling the last line of this code on runtime.cpp: const TypeFunc* OptoRuntime::montgomeryMultiply_Type() { // create input type (domain) int num_args = 7; int argcnt = num_args; const Type** fields = TypeTuple::fields(argcnt); int argp = TypeFunc::Parms; fields[argp++] = TypePtr::NOTNULL; // a fields[argp++] = TypePtr::NOTNULL; // b fields[argp++] = TypePtr::NOTNULL; // n if (CCallingConventionRequiresIntsAsLongs) { argcnt += 1; // additional placeholders fields[argp++] = TypeLong::LONG; // len fields[argp++] = TypeLong::HALF; // placeholder } else { fields[argp++] = TypeInt::INT; // len } fields[argp++] = TypeLong::LONG; // inv fields[argp++] = Type::HALF; fields[argp++] = TypePtr::NOTNULL; // result assert(argp == TypeFunc::Parms+argcnt, "correct decoding"); const TypeTuple* domain = TypeTuple::make(TypeFunc::Parms+argcnt, fields); Thanks References: [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-April/002970.html -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: sexta-feira, 15 de setembro de 2017 04:39 To: Gustavo Serra Scalet Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics (off-list) Hi Gustavo, you can request backport by sending a [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic to jdk8u-dev at openjdk.java.net But first of all, you need to check if the change applies to 8u and run tests. The following information is needed in the email: Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020534.html Statement: Change applies cleanly or describe which changes were necessary You should also mention that it belongs to 8u102 backport of https://bugs.openjdk.java.net/browse/JDK-8150152 Once it's approved, you can ask a jdk8u reviewer or committer (which I'm not) to push it. Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Donnerstag, 14. September 2017 21:00 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics Hi Martin, Short question about the Montgomery backport to JDK8: > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 > > 14:15:31 2017). The reported performance speedup was calculated by > > > running the following test (TestSquareToLen.java): > > Seems like JDK-8145913 has not been backported, yet. Sorry for not > checking this earlier. So if you want to make RSA really fast, it > should be so much better to backport that one. But I can still sponsor > this change as it may be used elsewhere. Do we have a bug ID for the Montgomery backport to JDK8 so I can track it? If not, should I request that backport or request this intrinsic to be backported (once it's inside of JDK10)? I'm interested in this kind of performance gain. Thanks > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Dienstag, 29. August 2017 22:37 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > Hi Martin, > > New changes: > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ > > Check comments below, please. > > > -----Original Message----- > > From: Doerr, Martin > > > > 1. Sign extending offset and len > > Right, sign and zero extending is equivalent for offset and len > > because they are guaranteed to be >=0 (by checks in Java). But you > > can only rely on bit 32 (IBM notation) to be 0. Bit 0-31 may contain > garbage. > > rldicl was incorrect. My mistake, sorry for that. Correct would be > > rldic which also clears the least significant bits. > > len should also get fixed e.g. by replacing cmpdi by extsw_ in muladd. > > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to > need further changes as it's being cleared with clrldi, which is the > same as rldic with no shift. Therefore it's treated appropriately as > requested for "offset" parameter. Do you agree? > > > 2. Using 8 byte instructions for int The code which feeds stdu is > > endianess specific. Doesn't work on all > > PPC64 platforms. > > You are right. The way I'm building the 64 bits of the register > depends on which kind of endianness it is run. For now it works only > on little endian so I'm adding a switch (just like I did for SHA) to > make it available only on little endian systems. > > > 3.Regarding Andrew's point: Superseded by Montgomery? > > The Montgomery change got backported to jdk8u (JDK-8150152 in 8u102). > > I'd expect the performance improvement of these intrinsics to be > > irrelevant for crypto.rsa. Did you measure with an older jdk8 release? > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 > 2017). The reported performance speedup was calculated by running the > following test (TestSquareToLen.java): > import java.math.BigInteger; > > public class TestSquareToLen { > > public static void main(String args[]) throws Exception { > > int n = 10000000; > if (args.length >=1) { > n = Integer.parseInt(args[0]); > } > > BigInteger b1 = new > BigInteger("3489398092355735908635051498208250392000229831187732085999 > 36 > 7395594183801021468843071391756049207873137016631559837931214754926092 > 22 > 3780292110207609223272184808289336630057735969423726808520641030118116 > 51 > 6440180488338234823908199478965242076358579845520899779963131131540166 > 68 718795349783157384006672542605760392289645528307"); > BigInteger b2 = BigInteger.valueOf(0); > BigInteger check = BigInteger.valueOf(1); > for (int i = 0; i < n; i++) { > b2 = b1.multiply(b1); > if (i == 0) > // Didn't JIT yet. Comparing against interpreted mode > check = b2; > } > if (b2.compareTo(check) == 0) > System.out.println("Check ok!"); > else > System.out.println("Check failed!"); > } > } > > > I got these results on JDK8 on my POWER8 machine: > $ ./javac TestSquareToLen.java > $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 15148.009557 task-clock (msec) # 1.053 CPUs > utilized ( +- 0.48% ) > 2,425 context-switches # 0.160 K/sec > ( +- 5.84% ) > 356 cpu-migrations # 0.023 K/sec > ( +- 3.01% ) > 5,153 page-faults # 0.340 K/sec > ( +- 5.22% ) > 54,536,889,909 cycles # 3.600 GHz > ( +- 0.56% ) (66.68%) > 239,554,105 stalled-cycles-frontend # 0.44% frontend > cycles idle ( +- 4.87% ) (49.90%) > 27,683,316,001 stalled-cycles-backend # 50.76% backend > cycles idle ( +- 0.56% ) (50.17%) > 102,020,229,733 instructions # 1.87 insn per > cycle > # 0.27 stalled > cycles per insn ( +- 0.14% ) (66.94%) > 7,706,072,218 branches # 508.718 M/sec > ( +- 0.23% ) (50.20%) > 456,051,162 branch-misses # 5.92% of all > branches ( +- 0.09% ) (50.07%) > > 14.390840733 seconds time elapsed ( +- 0.09% ) > > $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 11368.141410 task-clock (msec) # 1.045 CPUs > utilized ( +- 0.64% ) > 1,964 context-switches # 0.173 K/sec > ( +- 8.93% ) > 338 cpu-migrations # 0.030 K/sec > ( +- 7.65% ) > 5,627 page-faults # 0.495 K/sec > ( +- 6.15% ) > 41,100,168,967 cycles # 3.615 GHz > ( +- 0.50% ) (66.36%) > 309,052,316 stalled-cycles-frontend # 0.75% frontend > cycles idle ( +- 2.84% ) (49.89%) > 14,188,581,685 stalled-cycles-backend # 34.52% backend > cycles idle ( +- 0.99% ) (50.34%) > 77,846,029,829 instructions # 1.89 insn per > cycle > # 0.18 stalled > cycles per insn ( +- 0.29% ) (66.96%) > 8,435,216,989 branches # 742.005 M/sec > ( +- 0.28% ) (50.17%) > 339,903,936 branch-misses # 4.03% of all > branches ( +- 0.27% ) (49.90%) > > 10.882357546 seconds time elapsed ( +- 0.24% ) > > > (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s (+- > 0.53%) on JDK10) > > I may run for SpecJVM2008's crypto.rsa if you are interested. > > Thank you once again for reviewing this. > > Best regards, > Gustavo > > > (I think the change is still acceptable as the intrinsics could be > > used elsewhere and the implementation also exists on other > > platforms.) > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Mittwoch, 16. August 2017 18:50 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > Hi Martin, > > > > Thanks for dedicated review. It took me a while to be able to work > > on this but I hope to have your points solved. Please check below > > the review as well as my comments quoting your email: > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > > > -----Original Message----- > > > First of all, C2 does not perform sign extend when calling stubs. > > > The int parms need to get zero/sign extended. (Could even be done > > > without extra instructions by replacing sldi -> rldicl, cmpdi -> > > > extsw_ in some > > > cases.) > > > > Does it make a difference on my case? > > > > I guess you are talking about mulAdd preparation code. The only > > aspect I found about him is to force the cast from 32 bits -> 64 > > bits by cleaning higher bits. Offset is a signed integer but it > > can't be > negative anyway. > > > > So I changed from: > > sldi (R5_ARG3, R5_ARG3, 2); > > > > to: > > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > > > > macroAssembler_ppc.cpp: > > > - Indentation should be 2 spaces. > > > > Done > > > > > > > stubGenerator_ppc:cpp: > > > - or_, addi_ should get replaced by orr, addi when CR0 result is > > > not needed. > > > > Done > > > > > - Where is lplw initialized? > > > > It should be initialized with 0, I missed that... > > > > > - I believe that the updating load/store instructions e.g. lwzu > > > don't perform well on some processors. At least using stwu 2 times > > > in the loop doesn't make sense. > > > > You are right. I could manipulate the bits differently and ended up > > with a single stdu in the loop. Neat! Although I could not reduce > > the total number of instructions. > > > > > - Note: It should be possible to use 8 byte instead of 4 byte > > > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > > > requesting to change that because I guess it would make the code > > > very complicated, especially when supporting both endianess > versions. > > > > Yes, that would require a new analysis on this code. May we consider > > it next? As you said, I prefer having an initial version that looks > > as simple as the original java code. > > > > > - The squareToLen stub implementation is very close the Java > > > implementation. So it'd be interesting to understand what C2 > > > doesn't do as well as the hand written assembly code. Do you know > > > that? (Not absolutely necessary for accepting this change as long > > > as the stub is measurably faster.) > > > > I don't know either. Basically I chose doing it because I noticed > > some performance gain on SpecJVM2008 when analyzing X64. Then, > > taking a closer look, I didn't notice any AVX or some special > > instructions on > > X64 so I decided to try it on ppc64 by using some basic assembly. > > > > Thanks > > > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Donnerstag, 10. August 2017 19:22 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? By > > > implementing these intrinsics I noticed a small improvement with > > > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, > > > only when backporting to JDK8 an improvement was noticed. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > > > Motivation for this implementation: > > > https://twitter.com/ijuma/status/698309312498835457 > > > > > > Best regards, > > > Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Mon Sep 25 18:55:01 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 25 Sep 2017 18:55:01 +0000 Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) In-Reply-To: References: <49dadbf6eaea4823926340bc51d56cea@serv031.corp.eldorado.org.br> Message-ID: Yup: Node* call = NULL; if (CCallingConventionRequiresIntsAsLongs) { Node* len_I2L = ConvI2L(len); call = make_runtime_call(RC_LEAF, OptoRuntime::montgomeryMultiply_Type(), stubAddr, stubName, TypePtr::BOTTOM, a_start, b_start, n_start, len_I2L XTOP, inv, top(), m_start); } else { call = make_runtime_call(RC_LEAF, OptoRuntime::montgomeryMultiply_Type(), stubAddr, stubName, TypePtr::BOTTOM, a_start, b_start, n_start, len, inv, top(), m_start); } set_result(m); Any other thing I may be missing? -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: segunda-feira, 25 de setembro de 2017 13:55 To: Gustavo Serra Scalet Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RE: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Hi Gustavo, Did you also change library_call? Should be something like (example for multiplyToLen): Node* call = NULL; if (CCallingConventionRequiresIntsAsLongs) { Node* xlen_I2L = ConvI2L(xlen); Node* ylen_I2L = ConvI2L(ylen); Node* zlen_I2L = ConvI2L(zlen); call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen_I2L XTOP, y_start, ylen_I2L XTOP, z_start, zlen_I2L XTOP); } else { call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen, y_start, ylen, z_start, zlen); } Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Montag, 25. September 2017 16:03 To: Doerr, Martin Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Hi, Previously I faced some issues when backporting intrinsics to JDK8[1] but after some help, manage to make it work. Despite following those rules related to CCallingConvention and Int -> Long conversion, I still face issues not previously noticed on JDK9 when running SpecJVM2008's crypto.rsa bechmark. [release build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00003fffa0cc6f84, pid=3698, tid=0x00003fff7a34f1a0 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-gut_2017_04_12_09_19-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-ppc64 compressed oops) # Problematic frame: # V [libjvm.so+0x446f84] ConnectionGraph::process_call_arguments(CallNode*)+0x1c4 [slowdebug build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/type.cpp:596 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/gut/jdk8u-dev/hotspot/src/share/vm/opto/type.cpp:596), pid=6793, tid=0x00003fff5847f1a0 # assert(eq(dual_dual)) failed: xdual(xdual()) should be identity Any hints? I see the issue is when calling the last line of this code on runtime.cpp: const TypeFunc* OptoRuntime::montgomeryMultiply_Type() { // create input type (domain) int num_args = 7; int argcnt = num_args; const Type** fields = TypeTuple::fields(argcnt); int argp = TypeFunc::Parms; fields[argp++] = TypePtr::NOTNULL; // a fields[argp++] = TypePtr::NOTNULL; // b fields[argp++] = TypePtr::NOTNULL; // n if (CCallingConventionRequiresIntsAsLongs) { argcnt += 1; // additional placeholders fields[argp++] = TypeLong::LONG; // len fields[argp++] = TypeLong::HALF; // placeholder } else { fields[argp++] = TypeInt::INT; // len } fields[argp++] = TypeLong::LONG; // inv fields[argp++] = Type::HALF; fields[argp++] = TypePtr::NOTNULL; // result assert(argp == TypeFunc::Parms+argcnt, "correct decoding"); const TypeTuple* domain = TypeTuple::make(TypeFunc::Parms+argcnt, fields); Thanks References: [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-April/002970.html -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: sexta-feira, 15 de setembro de 2017 04:39 To: Gustavo Serra Scalet Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics (off-list) Hi Gustavo, you can request backport by sending a [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic to jdk8u-dev at openjdk.java.net But first of all, you need to check if the change applies to 8u and run tests. The following information is needed in the email: Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020534.html Statement: Change applies cleanly or describe which changes were necessary You should also mention that it belongs to 8u102 backport of https://bugs.openjdk.java.net/browse/JDK-8150152 Once it's approved, you can ask a jdk8u reviewer or committer (which I'm not) to push it. Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Donnerstag, 14. September 2017 21:00 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics Hi Martin, Short question about the Montgomery backport to JDK8: > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 > > 14:15:31 2017). The reported performance speedup was calculated by > > > running the following test (TestSquareToLen.java): > > Seems like JDK-8145913 has not been backported, yet. Sorry for not > checking this earlier. So if you want to make RSA really fast, it > should be so much better to backport that one. But I can still sponsor > this change as it may be used elsewhere. Do we have a bug ID for the Montgomery backport to JDK8 so I can track it? If not, should I request that backport or request this intrinsic to be backported (once it's inside of JDK10)? I'm interested in this kind of performance gain. Thanks > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Dienstag, 29. August 2017 22:37 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > Hi Martin, > > New changes: > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ > > Check comments below, please. > > > -----Original Message----- > > From: Doerr, Martin > > > > 1. Sign extending offset and len > > Right, sign and zero extending is equivalent for offset and len > > because they are guaranteed to be >=0 (by checks in Java). But you > > can only rely on bit 32 (IBM notation) to be 0. Bit 0-31 may contain > garbage. > > rldicl was incorrect. My mistake, sorry for that. Correct would be > > rldic which also clears the least significant bits. > > len should also get fixed e.g. by replacing cmpdi by extsw_ in muladd. > > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to > need further changes as it's being cleared with clrldi, which is the > same as rldic with no shift. Therefore it's treated appropriately as > requested for "offset" parameter. Do you agree? > > > 2. Using 8 byte instructions for int The code which feeds stdu is > > endianess specific. Doesn't work on all > > PPC64 platforms. > > You are right. The way I'm building the 64 bits of the register > depends on which kind of endianness it is run. For now it works only > on little endian so I'm adding a switch (just like I did for SHA) to > make it available only on little endian systems. > > > 3.Regarding Andrew's point: Superseded by Montgomery? > > The Montgomery change got backported to jdk8u (JDK-8150152 in 8u102). > > I'd expect the performance improvement of these intrinsics to be > > irrelevant for crypto.rsa. Did you measure with an older jdk8 release? > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 > 2017). The reported performance speedup was calculated by running the > following test (TestSquareToLen.java): > import java.math.BigInteger; > > public class TestSquareToLen { > > public static void main(String args[]) throws Exception { > > int n = 10000000; > if (args.length >=1) { > n = Integer.parseInt(args[0]); > } > > BigInteger b1 = new > BigInteger("3489398092355735908635051498208250392000229831187732085999 > 36 > 7395594183801021468843071391756049207873137016631559837931214754926092 > 22 > 3780292110207609223272184808289336630057735969423726808520641030118116 > 51 > 6440180488338234823908199478965242076358579845520899779963131131540166 > 68 718795349783157384006672542605760392289645528307"); > BigInteger b2 = BigInteger.valueOf(0); > BigInteger check = BigInteger.valueOf(1); > for (int i = 0; i < n; i++) { > b2 = b1.multiply(b1); > if (i == 0) > // Didn't JIT yet. Comparing against interpreted mode > check = b2; > } > if (b2.compareTo(check) == 0) > System.out.println("Check ok!"); > else > System.out.println("Check failed!"); > } > } > > > I got these results on JDK8 on my POWER8 machine: > $ ./javac TestSquareToLen.java > $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 15148.009557 task-clock (msec) # 1.053 CPUs > utilized ( +- 0.48% ) > 2,425 context-switches # 0.160 K/sec > ( +- 5.84% ) > 356 cpu-migrations # 0.023 K/sec > ( +- 3.01% ) > 5,153 page-faults # 0.340 K/sec > ( +- 5.22% ) > 54,536,889,909 cycles # 3.600 GHz > ( +- 0.56% ) (66.68%) > 239,554,105 stalled-cycles-frontend # 0.44% frontend > cycles idle ( +- 4.87% ) (49.90%) > 27,683,316,001 stalled-cycles-backend # 50.76% backend > cycles idle ( +- 0.56% ) (50.17%) > 102,020,229,733 instructions # 1.87 insn per > cycle > # 0.27 stalled > cycles per insn ( +- 0.14% ) (66.94%) > 7,706,072,218 branches # 508.718 M/sec > ( +- 0.23% ) (50.20%) > 456,051,162 branch-misses # 5.92% of all > branches ( +- 0.09% ) (50.07%) > > 14.390840733 seconds time elapsed ( +- 0.09% ) > > $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 11368.141410 task-clock (msec) # 1.045 CPUs > utilized ( +- 0.64% ) > 1,964 context-switches # 0.173 K/sec > ( +- 8.93% ) > 338 cpu-migrations # 0.030 K/sec > ( +- 7.65% ) > 5,627 page-faults # 0.495 K/sec > ( +- 6.15% ) > 41,100,168,967 cycles # 3.615 GHz > ( +- 0.50% ) (66.36%) > 309,052,316 stalled-cycles-frontend # 0.75% frontend > cycles idle ( +- 2.84% ) (49.89%) > 14,188,581,685 stalled-cycles-backend # 34.52% backend > cycles idle ( +- 0.99% ) (50.34%) > 77,846,029,829 instructions # 1.89 insn per > cycle > # 0.18 stalled > cycles per insn ( +- 0.29% ) (66.96%) > 8,435,216,989 branches # 742.005 M/sec > ( +- 0.28% ) (50.17%) > 339,903,936 branch-misses # 4.03% of all > branches ( +- 0.27% ) (49.90%) > > 10.882357546 seconds time elapsed ( +- 0.24% ) > > > (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s (+- > 0.53%) on JDK10) > > I may run for SpecJVM2008's crypto.rsa if you are interested. > > Thank you once again for reviewing this. > > Best regards, > Gustavo > > > (I think the change is still acceptable as the intrinsics could be > > used elsewhere and the implementation also exists on other > > platforms.) > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Mittwoch, 16. August 2017 18:50 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > Hi Martin, > > > > Thanks for dedicated review. It took me a while to be able to work > > on this but I hope to have your points solved. Please check below > > the review as well as my comments quoting your email: > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > > > -----Original Message----- > > > First of all, C2 does not perform sign extend when calling stubs. > > > The int parms need to get zero/sign extended. (Could even be done > > > without extra instructions by replacing sldi -> rldicl, cmpdi -> > > > extsw_ in some > > > cases.) > > > > Does it make a difference on my case? > > > > I guess you are talking about mulAdd preparation code. The only > > aspect I found about him is to force the cast from 32 bits -> 64 > > bits by cleaning higher bits. Offset is a signed integer but it > > can't be > negative anyway. > > > > So I changed from: > > sldi (R5_ARG3, R5_ARG3, 2); > > > > to: > > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > > > > macroAssembler_ppc.cpp: > > > - Indentation should be 2 spaces. > > > > Done > > > > > > > stubGenerator_ppc:cpp: > > > - or_, addi_ should get replaced by orr, addi when CR0 result is > > > not needed. > > > > Done > > > > > - Where is lplw initialized? > > > > It should be initialized with 0, I missed that... > > > > > - I believe that the updating load/store instructions e.g. lwzu > > > don't perform well on some processors. At least using stwu 2 times > > > in the loop doesn't make sense. > > > > You are right. I could manipulate the bits differently and ended up > > with a single stdu in the loop. Neat! Although I could not reduce > > the total number of instructions. > > > > > - Note: It should be possible to use 8 byte instead of 4 byte > > > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > > > requesting to change that because I guess it would make the code > > > very complicated, especially when supporting both endianess > versions. > > > > Yes, that would require a new analysis on this code. May we consider > > it next? As you said, I prefer having an initial version that looks > > as simple as the original java code. > > > > > - The squareToLen stub implementation is very close the Java > > > implementation. So it'd be interesting to understand what C2 > > > doesn't do as well as the hand written assembly code. Do you know > > > that? (Not absolutely necessary for accepting this change as long > > > as the stub is measurably faster.) > > > > I don't know either. Basically I chose doing it because I noticed > > some performance gain on SpecJVM2008 when analyzing X64. Then, > > taking a closer look, I didn't notice any AVX or some special > > instructions on > > X64 so I decided to try it on ppc64 by using some basic assembly. > > > > Thanks > > > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Donnerstag, 10. August 2017 19:22 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? By > > > implementing these intrinsics I noticed a small improvement with > > > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, > > > only when backporting to JDK8 an improvement was noticed. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > > > Motivation for this implementation: > > > https://twitter.com/ijuma/status/698309312498835457 > > > > > > Best regards, > > > Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Mon Sep 25 19:12:02 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Mon, 25 Sep 2017 19:12:02 +0000 Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) In-Reply-To: References: <49dadbf6eaea4823926340bc51d56cea@serv031.corp.eldorado.org.br> Message-ID: <761ab8e6512c4b5ea043131a4f0882ae@serv031.corp.eldorado.org.br> In order words, despite the proper JDK9 commit[1] I added these changes due to CCallingConventionRequiresIntsAsLongs: https://gist.github.com/anonymous/b3a8782aac9d56615d6e15db834335b4 References: [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: segunda-feira, 25 de setembro de 2017 15:55 To: Doerr, Martin Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RE: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Yup: Node* call = NULL; if (CCallingConventionRequiresIntsAsLongs) { Node* len_I2L = ConvI2L(len); call = make_runtime_call(RC_LEAF, OptoRuntime::montgomeryMultiply_Type(), stubAddr, stubName, TypePtr::BOTTOM, a_start, b_start, n_start, len_I2L XTOP, inv, top(), m_start); } else { call = make_runtime_call(RC_LEAF, OptoRuntime::montgomeryMultiply_Type(), stubAddr, stubName, TypePtr::BOTTOM, a_start, b_start, n_start, len, inv, top(), m_start); } set_result(m); Any other thing I may be missing? -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: segunda-feira, 25 de setembro de 2017 13:55 To: Gustavo Serra Scalet Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RE: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Hi Gustavo, Did you also change library_call? Should be something like (example for multiplyToLen): Node* call = NULL; if (CCallingConventionRequiresIntsAsLongs) { Node* xlen_I2L = ConvI2L(xlen); Node* ylen_I2L = ConvI2L(ylen); Node* zlen_I2L = ConvI2L(zlen); call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen_I2L XTOP, y_start, ylen_I2L XTOP, z_start, zlen_I2L XTOP); } else { call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen, y_start, ylen, z_start, zlen); } Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Montag, 25. September 2017 16:03 To: Doerr, Martin Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Hi, Previously I faced some issues when backporting intrinsics to JDK8[1] but after some help, manage to make it work. Despite following those rules related to CCallingConvention and Int -> Long conversion, I still face issues not previously noticed on JDK9 when running SpecJVM2008's crypto.rsa bechmark. [release build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00003fffa0cc6f84, pid=3698, tid=0x00003fff7a34f1a0 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-gut_2017_04_12_09_19-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-ppc64 compressed oops) # Problematic frame: # V [libjvm.so+0x446f84] ConnectionGraph::process_call_arguments(CallNode*)+0x1c4 [slowdebug build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/type.cpp:596 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/gut/jdk8u-dev/hotspot/src/share/vm/opto/type.cpp:596), pid=6793, tid=0x00003fff5847f1a0 # assert(eq(dual_dual)) failed: xdual(xdual()) should be identity Any hints? I see the issue is when calling the last line of this code on runtime.cpp: const TypeFunc* OptoRuntime::montgomeryMultiply_Type() { // create input type (domain) int num_args = 7; int argcnt = num_args; const Type** fields = TypeTuple::fields(argcnt); int argp = TypeFunc::Parms; fields[argp++] = TypePtr::NOTNULL; // a fields[argp++] = TypePtr::NOTNULL; // b fields[argp++] = TypePtr::NOTNULL; // n if (CCallingConventionRequiresIntsAsLongs) { argcnt += 1; // additional placeholders fields[argp++] = TypeLong::LONG; // len fields[argp++] = TypeLong::HALF; // placeholder } else { fields[argp++] = TypeInt::INT; // len } fields[argp++] = TypeLong::LONG; // inv fields[argp++] = Type::HALF; fields[argp++] = TypePtr::NOTNULL; // result assert(argp == TypeFunc::Parms+argcnt, "correct decoding"); const TypeTuple* domain = TypeTuple::make(TypeFunc::Parms+argcnt, fields); Thanks References: [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-April/002970.html -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: sexta-feira, 15 de setembro de 2017 04:39 To: Gustavo Serra Scalet Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics (off-list) Hi Gustavo, you can request backport by sending a [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic to jdk8u-dev at openjdk.java.net But first of all, you need to check if the change applies to 8u and run tests. The following information is needed in the email: Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020534.html Statement: Change applies cleanly or describe which changes were necessary You should also mention that it belongs to 8u102 backport of https://bugs.openjdk.java.net/browse/JDK-8150152 Once it's approved, you can ask a jdk8u reviewer or committer (which I'm not) to push it. Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Donnerstag, 14. September 2017 21:00 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics Hi Martin, Short question about the Montgomery backport to JDK8: > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 > > 14:15:31 2017). The reported performance speedup was calculated by > > > running the following test (TestSquareToLen.java): > > Seems like JDK-8145913 has not been backported, yet. Sorry for not > checking this earlier. So if you want to make RSA really fast, it > should be so much better to backport that one. But I can still sponsor > this change as it may be used elsewhere. Do we have a bug ID for the Montgomery backport to JDK8 so I can track it? If not, should I request that backport or request this intrinsic to be backported (once it's inside of JDK10)? I'm interested in this kind of performance gain. Thanks > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Dienstag, 29. August 2017 22:37 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > Hi Martin, > > New changes: > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ > > Check comments below, please. > > > -----Original Message----- > > From: Doerr, Martin > > > > 1. Sign extending offset and len > > Right, sign and zero extending is equivalent for offset and len > > because they are guaranteed to be >=0 (by checks in Java). But you > > can only rely on bit 32 (IBM notation) to be 0. Bit 0-31 may contain > garbage. > > rldicl was incorrect. My mistake, sorry for that. Correct would be > > rldic which also clears the least significant bits. > > len should also get fixed e.g. by replacing cmpdi by extsw_ in muladd. > > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to > need further changes as it's being cleared with clrldi, which is the > same as rldic with no shift. Therefore it's treated appropriately as > requested for "offset" parameter. Do you agree? > > > 2. Using 8 byte instructions for int The code which feeds stdu is > > endianess specific. Doesn't work on all > > PPC64 platforms. > > You are right. The way I'm building the 64 bits of the register > depends on which kind of endianness it is run. For now it works only > on little endian so I'm adding a switch (just like I did for SHA) to > make it available only on little endian systems. > > > 3.Regarding Andrew's point: Superseded by Montgomery? > > The Montgomery change got backported to jdk8u (JDK-8150152 in 8u102). > > I'd expect the performance improvement of these intrinsics to be > > irrelevant for crypto.rsa. Did you measure with an older jdk8 release? > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 > 2017). The reported performance speedup was calculated by running the > following test (TestSquareToLen.java): > import java.math.BigInteger; > > public class TestSquareToLen { > > public static void main(String args[]) throws Exception { > > int n = 10000000; > if (args.length >=1) { > n = Integer.parseInt(args[0]); > } > > BigInteger b1 = new > BigInteger("3489398092355735908635051498208250392000229831187732085999 > 36 > 7395594183801021468843071391756049207873137016631559837931214754926092 > 22 > 3780292110207609223272184808289336630057735969423726808520641030118116 > 51 > 6440180488338234823908199478965242076358579845520899779963131131540166 > 68 718795349783157384006672542605760392289645528307"); > BigInteger b2 = BigInteger.valueOf(0); > BigInteger check = BigInteger.valueOf(1); > for (int i = 0; i < n; i++) { > b2 = b1.multiply(b1); > if (i == 0) > // Didn't JIT yet. Comparing against interpreted mode > check = b2; > } > if (b2.compareTo(check) == 0) > System.out.println("Check ok!"); > else > System.out.println("Check failed!"); > } > } > > > I got these results on JDK8 on my POWER8 machine: > $ ./javac TestSquareToLen.java > $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 15148.009557 task-clock (msec) # 1.053 CPUs > utilized ( +- 0.48% ) > 2,425 context-switches # 0.160 K/sec > ( +- 5.84% ) > 356 cpu-migrations # 0.023 K/sec > ( +- 3.01% ) > 5,153 page-faults # 0.340 K/sec > ( +- 5.22% ) > 54,536,889,909 cycles # 3.600 GHz > ( +- 0.56% ) (66.68%) > 239,554,105 stalled-cycles-frontend # 0.44% frontend > cycles idle ( +- 4.87% ) (49.90%) > 27,683,316,001 stalled-cycles-backend # 50.76% backend > cycles idle ( +- 0.56% ) (50.17%) > 102,020,229,733 instructions # 1.87 insn per > cycle > # 0.27 stalled > cycles per insn ( +- 0.14% ) (66.94%) > 7,706,072,218 branches # 508.718 M/sec > ( +- 0.23% ) (50.20%) > 456,051,162 branch-misses # 5.92% of all > branches ( +- 0.09% ) (50.07%) > > 14.390840733 seconds time elapsed ( +- 0.09% ) > > $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 11368.141410 task-clock (msec) # 1.045 CPUs > utilized ( +- 0.64% ) > 1,964 context-switches # 0.173 K/sec > ( +- 8.93% ) > 338 cpu-migrations # 0.030 K/sec > ( +- 7.65% ) > 5,627 page-faults # 0.495 K/sec > ( +- 6.15% ) > 41,100,168,967 cycles # 3.615 GHz > ( +- 0.50% ) (66.36%) > 309,052,316 stalled-cycles-frontend # 0.75% frontend > cycles idle ( +- 2.84% ) (49.89%) > 14,188,581,685 stalled-cycles-backend # 34.52% backend > cycles idle ( +- 0.99% ) (50.34%) > 77,846,029,829 instructions # 1.89 insn per > cycle > # 0.18 stalled > cycles per insn ( +- 0.29% ) (66.96%) > 8,435,216,989 branches # 742.005 M/sec > ( +- 0.28% ) (50.17%) > 339,903,936 branch-misses # 4.03% of all > branches ( +- 0.27% ) (49.90%) > > 10.882357546 seconds time elapsed ( +- 0.24% ) > > > (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s (+- > 0.53%) on JDK10) > > I may run for SpecJVM2008's crypto.rsa if you are interested. > > Thank you once again for reviewing this. > > Best regards, > Gustavo > > > (I think the change is still acceptable as the intrinsics could be > > used elsewhere and the implementation also exists on other > > platforms.) > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Mittwoch, 16. August 2017 18:50 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > Hi Martin, > > > > Thanks for dedicated review. It took me a while to be able to work > > on this but I hope to have your points solved. Please check below > > the review as well as my comments quoting your email: > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > > > -----Original Message----- > > > First of all, C2 does not perform sign extend when calling stubs. > > > The int parms need to get zero/sign extended. (Could even be done > > > without extra instructions by replacing sldi -> rldicl, cmpdi -> > > > extsw_ in some > > > cases.) > > > > Does it make a difference on my case? > > > > I guess you are talking about mulAdd preparation code. The only > > aspect I found about him is to force the cast from 32 bits -> 64 > > bits by cleaning higher bits. Offset is a signed integer but it > > can't be > negative anyway. > > > > So I changed from: > > sldi (R5_ARG3, R5_ARG3, 2); > > > > to: > > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > > > > macroAssembler_ppc.cpp: > > > - Indentation should be 2 spaces. > > > > Done > > > > > > > stubGenerator_ppc:cpp: > > > - or_, addi_ should get replaced by orr, addi when CR0 result is > > > not needed. > > > > Done > > > > > - Where is lplw initialized? > > > > It should be initialized with 0, I missed that... > > > > > - I believe that the updating load/store instructions e.g. lwzu > > > don't perform well on some processors. At least using stwu 2 times > > > in the loop doesn't make sense. > > > > You are right. I could manipulate the bits differently and ended up > > with a single stdu in the loop. Neat! Although I could not reduce > > the total number of instructions. > > > > > - Note: It should be possible to use 8 byte instead of 4 byte > > > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > > > requesting to change that because I guess it would make the code > > > very complicated, especially when supporting both endianess > versions. > > > > Yes, that would require a new analysis on this code. May we consider > > it next? As you said, I prefer having an initial version that looks > > as simple as the original java code. > > > > > - The squareToLen stub implementation is very close the Java > > > implementation. So it'd be interesting to understand what C2 > > > doesn't do as well as the hand written assembly code. Do you know > > > that? (Not absolutely necessary for accepting this change as long > > > as the stub is measurably faster.) > > > > I don't know either. Basically I chose doing it because I noticed > > some performance gain on SpecJVM2008 when analyzing X64. Then, > > taking a closer look, I didn't notice any AVX or some special > > instructions on > > X64 so I decided to try it on ppc64 by using some basic assembly. > > > > Thanks > > > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Donnerstag, 10. August 2017 19:22 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? By > > > implementing these intrinsics I noticed a small improvement with > > > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, > > > only when backporting to JDK8 an improvement was noticed. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > > > Motivation for this implementation: > > > https://twitter.com/ijuma/status/698309312498835457 > > > > > > Best regards, > > > Gustavo Serra Scalet From martin.doerr at sap.com Tue Sep 26 09:37:16 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Tue, 26 Sep 2017 09:37:16 +0000 Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) In-Reply-To: <761ab8e6512c4b5ea043131a4f0882ae@serv031.corp.eldorado.org.br> References: <49dadbf6eaea4823926340bc51d56cea@serv031.corp.eldorado.org.br> <761ab8e6512c4b5ea043131a4f0882ae@serv031.corp.eldorado.org.br> Message-ID: Hi, did you feed the right argcnt into: const Type** fields = TypeTuple::fields(argcnt); ? If this is not the problem, I guess you'll have to debug. Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Montag, 25. September 2017 21:12 To: Doerr, Martin Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RE: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) In order words, despite the proper JDK9 commit[1] I added these changes due to CCallingConventionRequiresIntsAsLongs: https://gist.github.com/anonymous/b3a8782aac9d56615d6e15db834335b4 References: [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d -----Original Message----- From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet Sent: segunda-feira, 25 de setembro de 2017 15:55 To: Doerr, Martin Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RE: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Yup: Node* call = NULL; if (CCallingConventionRequiresIntsAsLongs) { Node* len_I2L = ConvI2L(len); call = make_runtime_call(RC_LEAF, OptoRuntime::montgomeryMultiply_Type(), stubAddr, stubName, TypePtr::BOTTOM, a_start, b_start, n_start, len_I2L XTOP, inv, top(), m_start); } else { call = make_runtime_call(RC_LEAF, OptoRuntime::montgomeryMultiply_Type(), stubAddr, stubName, TypePtr::BOTTOM, a_start, b_start, n_start, len, inv, top(), m_start); } set_result(m); Any other thing I may be missing? -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: segunda-feira, 25 de setembro de 2017 13:55 To: Gustavo Serra Scalet Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: RE: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Hi Gustavo, Did you also change library_call? Should be something like (example for multiplyToLen): Node* call = NULL; if (CCallingConventionRequiresIntsAsLongs) { Node* xlen_I2L = ConvI2L(xlen); Node* ylen_I2L = ConvI2L(ylen); Node* zlen_I2L = ConvI2L(zlen); call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen_I2L XTOP, y_start, ylen_I2L XTOP, z_start, zlen_I2L XTOP); } else { call = make_runtime_call(RC_LEAF|RC_NO_FP, OptoRuntime::multiplyToLen_Type(), stubAddr, stubName, TypePtr::BOTTOM, x_start, xlen, y_start, ylen, z_start, zlen); } Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Montag, 25. September 2017 16:03 To: Doerr, Martin Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) Hi, Previously I faced some issues when backporting intrinsics to JDK8[1] but after some help, manage to make it work. Despite following those rules related to CCallingConvention and Int -> Long conversion, I still face issues not previously noticed on JDK9 when running SpecJVM2008's crypto.rsa bechmark. [release build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00003fffa0cc6f84, pid=3698, tid=0x00003fff7a34f1a0 # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-gut_2017_04_12_09_19-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-ppc64 compressed oops) # Problematic frame: # V [libjvm.so+0x446f84] ConnectionGraph::process_call_arguments(CallNode*)+0x1c4 [slowdebug build]: Benchmark: crypto.rsa Run mode: timed run Test type: multi Threads: 24 Warmup: 120s Iterations: 1 Run length: 240s # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/type.cpp:596 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/home/gut/jdk8u-dev/hotspot/src/share/vm/opto/type.cpp:596), pid=6793, tid=0x00003fff5847f1a0 # assert(eq(dual_dual)) failed: xdual(xdual()) should be identity Any hints? I see the issue is when calling the last line of this code on runtime.cpp: const TypeFunc* OptoRuntime::montgomeryMultiply_Type() { // create input type (domain) int num_args = 7; int argcnt = num_args; const Type** fields = TypeTuple::fields(argcnt); int argp = TypeFunc::Parms; fields[argp++] = TypePtr::NOTNULL; // a fields[argp++] = TypePtr::NOTNULL; // b fields[argp++] = TypePtr::NOTNULL; // n if (CCallingConventionRequiresIntsAsLongs) { argcnt += 1; // additional placeholders fields[argp++] = TypeLong::LONG; // len fields[argp++] = TypeLong::HALF; // placeholder } else { fields[argp++] = TypeInt::INT; // len } fields[argp++] = TypeLong::LONG; // inv fields[argp++] = Type::HALF; fields[argp++] = TypePtr::NOTNULL; // result assert(argp == TypeFunc::Parms+argcnt, "correct decoding"); const TypeTuple* domain = TypeTuple::make(TypeFunc::Parms+argcnt, fields); Thanks References: [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017-April/002970.html -----Original Message----- From: Doerr, Martin [mailto:martin.doerr at sap.com] Sent: sexta-feira, 15 de setembro de 2017 04:39 To: Gustavo Serra Scalet Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics (off-list) Hi Gustavo, you can request backport by sending a [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic to jdk8u-dev at openjdk.java.net But first of all, you need to check if the change applies to 8u and run tests. The following information is needed in the email: Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020534.html Statement: Change applies cleanly or describe which changes were necessary You should also mention that it belongs to 8u102 backport of https://bugs.openjdk.java.net/browse/JDK-8150152 Once it's approved, you can ask a jdk8u reviewer or committer (which I'm not) to push it. Best regards, Martin -----Original Message----- From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] Sent: Donnerstag, 14. September 2017 21:00 To: Doerr, Martin ; 'hotspot-compiler-dev at openjdk.java.net' Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and SquareToLen intrinsics Hi Martin, Short question about the Montgomery backport to JDK8: > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 > > 14:15:31 2017). The reported performance speedup was calculated by > > > running the following test (TestSquareToLen.java): > > Seems like JDK-8145913 has not been backported, yet. Sorry for not > checking this earlier. So if you want to make RSA really fast, it > should be so much better to backport that one. But I can still sponsor > this change as it may be used elsewhere. Do we have a bug ID for the Montgomery backport to JDK8 so I can track it? If not, should I request that backport or request this intrinsic to be backported (once it's inside of JDK10)? I'm interested in this kind of performance gain. Thanks > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Dienstag, 29. August 2017 22:37 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > Hi Martin, > > New changes: > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ > > Check comments below, please. > > > -----Original Message----- > > From: Doerr, Martin > > > > 1. Sign extending offset and len > > Right, sign and zero extending is equivalent for offset and len > > because they are guaranteed to be >=0 (by checks in Java). But you > > can only rely on bit 32 (IBM notation) to be 0. Bit 0-31 may contain > garbage. > > rldicl was incorrect. My mistake, sorry for that. Correct would be > > rldic which also clears the least significant bits. > > len should also get fixed e.g. by replacing cmpdi by extsw_ in muladd. > > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to > need further changes as it's being cleared with clrldi, which is the > same as rldic with no shift. Therefore it's treated appropriately as > requested for "offset" parameter. Do you agree? > > > 2. Using 8 byte instructions for int The code which feeds stdu is > > endianess specific. Doesn't work on all > > PPC64 platforms. > > You are right. The way I'm building the 64 bits of the register > depends on which kind of endianness it is run. For now it works only > on little endian so I'm adding a switch (just like I did for SHA) to > make it available only on little endian systems. > > > 3.Regarding Andrew's point: Superseded by Montgomery? > > The Montgomery change got backported to jdk8u (JDK-8150152 in 8u102). > > I'd expect the performance improvement of these intrinsics to be > > irrelevant for crypto.rsa. Did you measure with an older jdk8 release? > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 > 2017). The reported performance speedup was calculated by running the > following test (TestSquareToLen.java): > import java.math.BigInteger; > > public class TestSquareToLen { > > public static void main(String args[]) throws Exception { > > int n = 10000000; > if (args.length >=1) { > n = Integer.parseInt(args[0]); > } > > BigInteger b1 = new > BigInteger("3489398092355735908635051498208250392000229831187732085999 > 36 > 7395594183801021468843071391756049207873137016631559837931214754926092 > 22 > 3780292110207609223272184808289336630057735969423726808520641030118116 > 51 > 6440180488338234823908199478965242076358579845520899779963131131540166 > 68 718795349783157384006672542605760392289645528307"); > BigInteger b2 = BigInteger.valueOf(0); > BigInteger check = BigInteger.valueOf(1); > for (int i = 0; i < n; i++) { > b2 = b1.multiply(b1); > if (i == 0) > // Didn't JIT yet. Comparing against interpreted mode > check = b2; > } > if (b2.compareTo(check) == 0) > System.out.println("Check ok!"); > else > System.out.println("Check failed!"); > } > } > > > I got these results on JDK8 on my POWER8 machine: > $ ./javac TestSquareToLen.java > $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:- > UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 15148.009557 task-clock (msec) # 1.053 CPUs > utilized ( +- 0.48% ) > 2,425 context-switches # 0.160 K/sec > ( +- 5.84% ) > 356 cpu-migrations # 0.023 K/sec > ( +- 3.01% ) > 5,153 page-faults # 0.340 K/sec > ( +- 5.22% ) > 54,536,889,909 cycles # 3.600 GHz > ( +- 0.56% ) (66.68%) > 239,554,105 stalled-cycles-frontend # 0.44% frontend > cycles idle ( +- 4.87% ) (49.90%) > 27,683,316,001 stalled-cycles-backend # 50.76% backend > cycles idle ( +- 0.56% ) (50.17%) > 102,020,229,733 instructions # 1.87 insn per > cycle > # 0.27 stalled > cycles per insn ( +- 0.14% ) (66.94%) > 7,706,072,218 branches # 508.718 M/sec > ( +- 0.23% ) (50.20%) > 456,051,162 branch-misses # 5.92% of all > branches ( +- 0.09% ) (50.07%) > > 14.390840733 seconds time elapsed ( +- 0.09% ) > > $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! > Check ok! > Check ok! > Check ok! > Check ok! > > Performance counter stats for './java -XX:+UseMulAddIntrinsic - > XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > 11368.141410 task-clock (msec) # 1.045 CPUs > utilized ( +- 0.64% ) > 1,964 context-switches # 0.173 K/sec > ( +- 8.93% ) > 338 cpu-migrations # 0.030 K/sec > ( +- 7.65% ) > 5,627 page-faults # 0.495 K/sec > ( +- 6.15% ) > 41,100,168,967 cycles # 3.615 GHz > ( +- 0.50% ) (66.36%) > 309,052,316 stalled-cycles-frontend # 0.75% frontend > cycles idle ( +- 2.84% ) (49.89%) > 14,188,581,685 stalled-cycles-backend # 34.52% backend > cycles idle ( +- 0.99% ) (50.34%) > 77,846,029,829 instructions # 1.89 insn per > cycle > # 0.18 stalled > cycles per insn ( +- 0.29% ) (66.96%) > 8,435,216,989 branches # 742.005 M/sec > ( +- 0.28% ) (50.17%) > 339,903,936 branch-misses # 4.03% of all > branches ( +- 0.27% ) (49.90%) > > 10.882357546 seconds time elapsed ( +- 0.24% ) > > > (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s (+- > 0.53%) on JDK10) > > I may run for SpecJVM2008's crypto.rsa if you are interested. > > Thank you once again for reviewing this. > > Best regards, > Gustavo > > > (I think the change is still acceptable as the intrinsics could be > > used elsewhere and the implementation also exists on other > > platforms.) > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Mittwoch, 16. August 2017 18:50 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > Hi Martin, > > > > Thanks for dedicated review. It took me a while to be able to work > > on this but I hope to have your points solved. Please check below > > the review as well as my comments quoting your email: > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > > > -----Original Message----- > > > First of all, C2 does not perform sign extend when calling stubs. > > > The int parms need to get zero/sign extended. (Could even be done > > > without extra instructions by replacing sldi -> rldicl, cmpdi -> > > > extsw_ in some > > > cases.) > > > > Does it make a difference on my case? > > > > I guess you are talking about mulAdd preparation code. The only > > aspect I found about him is to force the cast from 32 bits -> 64 > > bits by cleaning higher bits. Offset is a signed integer but it > > can't be > negative anyway. > > > > So I changed from: > > sldi (R5_ARG3, R5_ARG3, 2); > > > > to: > > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > > > > macroAssembler_ppc.cpp: > > > - Indentation should be 2 spaces. > > > > Done > > > > > > > stubGenerator_ppc:cpp: > > > - or_, addi_ should get replaced by orr, addi when CR0 result is > > > not needed. > > > > Done > > > > > - Where is lplw initialized? > > > > It should be initialized with 0, I missed that... > > > > > - I believe that the updating load/store instructions e.g. lwzu > > > don't perform well on some processors. At least using stwu 2 times > > > in the loop doesn't make sense. > > > > You are right. I could manipulate the bits differently and ended up > > with a single stdu in the loop. Neat! Although I could not reduce > > the total number of instructions. > > > > > - Note: It should be possible to use 8 byte instead of 4 byte > > > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > > > requesting to change that because I guess it would make the code > > > very complicated, especially when supporting both endianess > versions. > > > > Yes, that would require a new analysis on this code. May we consider > > it next? As you said, I prefer having an initial version that looks > > as simple as the original java code. > > > > > - The squareToLen stub implementation is very close the Java > > > implementation. So it'd be interesting to understand what C2 > > > doesn't do as well as the hand written assembly code. Do you know > > > that? (Not absolutely necessary for accepting this change as long > > > as the stub is measurably faster.) > > > > I don't know either. Basically I chose doing it because I noticed > > some performance gain on SpecJVM2008 when analyzing X64. Then, > > taking a closer look, I didn't notice any AVX or some special > > instructions on > > X64 so I decided to try it on ppc64 by using some basic assembly. > > > > Thanks > > > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: Donnerstag, 10. August 2017 19:22 > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > dev at openjdk.java.net> > > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > > > > > > > -----Original Message----- > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > > To: ppc-aix-port-dev at openjdk.java.net > > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > Hi, > > > > > > Could you please review this specific PPC64 change to hotspot? By > > > implementing these intrinsics I noticed a small improvement with > > > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, > > > only when backporting to JDK8 an improvement was noticed. > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > > > Motivation for this implementation: > > > https://twitter.com/ijuma/status/698309312498835457 > > > > > > Best regards, > > > Gustavo Serra Scalet From gustavo.scalet at eldorado.org.br Tue Sep 26 13:06:28 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Tue, 26 Sep 2017 13:06:28 +0000 Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) In-Reply-To: References: <49dadbf6eaea4823926340bc51d56cea@serv031.corp.eldorado.org.br> <761ab8e6512c4b5ea043131a4f0882ae@serv031.corp.eldorado.org.br> Message-ID: > -----Original Message----- > From: Doerr, Martin > Hi, > > did you feed the right argcnt into: > const Type** fields = TypeTuple::fields(argcnt); ? Yes, that looks ok. > If this is not the problem, I guess you'll have to debug. Alright. I'll post the results for reference. > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 25. September 2017 21:12 > To: Doerr, Martin > Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RE: "xdual(xdual()) should be identity" error when backporting > Montgomery multiplication to JDK8 (PPC64le) > > In order words, despite the proper JDK9 commit[1] I added these changes > due to CCallingConventionRequiresIntsAsLongs: > https://gist.github.com/anonymous/b3a8782aac9d56615d6e15db834335b4 > > References: > [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d > > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: segunda-feira, 25 de setembro de 2017 15:55 > To: Doerr, Martin > Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RE: "xdual(xdual()) should be identity" error when backporting > Montgomery multiplication to JDK8 (PPC64le) > > Yup: > Node* call = NULL; > if (CCallingConventionRequiresIntsAsLongs) { > Node* len_I2L = ConvI2L(len); > call = make_runtime_call(RC_LEAF, > OptoRuntime::montgomeryMultiply_Type(), > stubAddr, stubName, TypePtr::BOTTOM, > a_start, b_start, n_start, len_I2L XTOP, inv, > top(), m_start); } else { > call = make_runtime_call(RC_LEAF, > OptoRuntime::montgomeryMultiply_Type(), > stubAddr, stubName, TypePtr::BOTTOM, > a_start, b_start, n_start, len, inv, top(), > m_start); > } > set_result(m); > > > Any other thing I may be missing? > > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: segunda-feira, 25 de setembro de 2017 13:55 > To: Gustavo Serra Scalet > Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RE: "xdual(xdual()) should be identity" error when backporting > Montgomery multiplication to JDK8 (PPC64le) > > Hi Gustavo, > > Did you also change library_call? > Should be something like (example for multiplyToLen): > > Node* call = NULL; > if (CCallingConventionRequiresIntsAsLongs) { > Node* xlen_I2L = ConvI2L(xlen); > Node* ylen_I2L = ConvI2L(ylen); > Node* zlen_I2L = ConvI2L(zlen); > call = make_runtime_call(RC_LEAF|RC_NO_FP, > OptoRuntime::multiplyToLen_Type(), > stubAddr, stubName, TypePtr::BOTTOM, > x_start, xlen_I2L XTOP, y_start, > ylen_I2L XTOP, z_start, zlen_I2L XTOP); > } > else { > call = make_runtime_call(RC_LEAF|RC_NO_FP, > OptoRuntime::multiplyToLen_Type(), > stubAddr, stubName, TypePtr::BOTTOM, > x_start, xlen, y_start, ylen, > z_start, zlen); > } > > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Montag, 25. September 2017 16:03 > To: Doerr, Martin > Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: "xdual(xdual()) should be identity" error when backporting > Montgomery multiplication to JDK8 (PPC64le) > > Hi, > > Previously I faced some issues when backporting intrinsics to JDK8[1] > but after some help, manage to make it work. > > Despite following those rules related to CCallingConvention and Int -> > Long conversion, I still face issues not previously noticed on JDK9 when > running SpecJVM2008's crypto.rsa bechmark. > > [release build]: > Benchmark: crypto.rsa > Run mode: timed run > Test type: multi > Threads: 24 > Warmup: 120s > Iterations: 1 > Run length: 240s > # > # A fatal error has been detected by the Java Runtime Environment: > # > # SIGSEGV (0xb) at pc=0x00003fffa0cc6f84, pid=3698, > tid=0x00003fff7a34f1a0 # # JRE version: OpenJDK Runtime Environment > (8.0) (build 1.8.0-internal-gut_2017_04_12_09_19-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-ppc64 > compressed oops) # Problematic frame: > # V [libjvm.so+0x446f84] > ConnectionGraph::process_call_arguments(CallNode*)+0x1c4 > > > [slowdebug build]: > Benchmark: crypto.rsa > Run mode: timed run > Test type: multi > Threads: 24 > Warmup: 120s > Iterations: 1 > Run length: 240s > # To suppress the following error report, specify this argument # after > -XX: or in .hotspotrc: SuppressErrorAt=/type.cpp:596 # # A fatal error > has been detected by the Java Runtime Environment: > # > # Internal Error (/home/gut/jdk8u- > dev/hotspot/src/share/vm/opto/type.cpp:596), pid=6793, > tid=0x00003fff5847f1a0 # assert(eq(dual_dual)) failed: xdual(xdual()) > should be identity > > > > Any hints? I see the issue is when calling the last line of this code on > runtime.cpp: > const TypeFunc* OptoRuntime::montgomeryMultiply_Type() { > // create input type (domain) > int num_args = 7; > int argcnt = num_args; > const Type** fields = TypeTuple::fields(argcnt); > int argp = TypeFunc::Parms; > fields[argp++] = TypePtr::NOTNULL; // a > fields[argp++] = TypePtr::NOTNULL; // b > fields[argp++] = TypePtr::NOTNULL; // n > if (CCallingConventionRequiresIntsAsLongs) { > argcnt += 1; // additional placeholders > fields[argp++] = TypeLong::LONG; // len > fields[argp++] = TypeLong::HALF; // placeholder > } else { > fields[argp++] = TypeInt::INT; // len > } > fields[argp++] = TypeLong::LONG; // inv > fields[argp++] = Type::HALF; > fields[argp++] = TypePtr::NOTNULL; // result > assert(argp == TypeFunc::Parms+argcnt, "correct decoding"); > const TypeTuple* domain = TypeTuple::make(TypeFunc::Parms+argcnt, > fields); > > > > Thanks > > References: > [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017- > April/002970.html > > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: sexta-feira, 15 de setembro de 2017 04:39 > To: Gustavo Serra Scalet > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics (off-list) > > Hi Gustavo, > > you can request backport by sending a > [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery > multiply intrinsic to jdk8u-dev at openjdk.java.net > > But first of all, you need to check if the change applies to 8u and run > tests. > > The following information is needed in the email: > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 > Jdk9 change: > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d > Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot- > compiler-dev/2015-December/020534.html > Statement: Change applies cleanly or describe which changes were > necessary You should also mention that it belongs to 8u102 backport of > https://bugs.openjdk.java.net/browse/JDK-8150152 > > Once it's approved, you can ask a jdk8u reviewer or committer (which I'm > not) to push it. > > Best regards, > Martin > > > -----Original Message----- > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > Sent: Donnerstag, 14. September 2017 21:00 > To: Doerr, Martin ; 'hotspot-compiler- > dev at openjdk.java.net' > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > SquareToLen intrinsics > > Hi Martin, > > Short question about the Montgomery backport to JDK8: > > > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 > > > 14:15:31 2017). The reported performance speedup was calculated by > > > > running the following test (TestSquareToLen.java): > > > > Seems like JDK-8145913 has not been backported, yet. Sorry for not > > checking this earlier. So if you want to make RSA really fast, it > > should be so much better to backport that one. But I can still sponsor > > this change as it may be used elsewhere. > > Do we have a bug ID for the Montgomery backport to JDK8 so I can track > it? If not, should I request that backport or request this intrinsic to > be backported (once it's inside of JDK10)? I'm interested in this kind > of performance gain. > > Thanks > > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Dienstag, 29. August 2017 22:37 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > Hi Martin, > > > > New changes: > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ > > > > Check comments below, please. > > > > > -----Original Message----- > > > From: Doerr, Martin > > > > > > 1. Sign extending offset and len > > > Right, sign and zero extending is equivalent for offset and len > > > because they are guaranteed to be >=0 (by checks in Java). But you > > > can only rely on bit 32 (IBM notation) to be 0. Bit 0-31 may contain > > garbage. > > > rldicl was incorrect. My mistake, sorry for that. Correct would be > > > rldic which also clears the least significant bits. > > > len should also get fixed e.g. by replacing cmpdi by extsw_ in > muladd. > > > > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem to > > need further changes as it's being cleared with clrldi, which is the > > same as rldic with no shift. Therefore it's treated appropriately as > > requested for "offset" parameter. Do you agree? > > > > > 2. Using 8 byte instructions for int The code which feeds stdu is > > > endianess specific. Doesn't work on all > > > PPC64 platforms. > > > > You are right. The way I'm building the 64 bits of the register > > depends on which kind of endianness it is run. For now it works only > > on little endian so I'm adding a switch (just like I did for SHA) to > > make it available only on little endian systems. > > > > > 3.Regarding Andrew's point: Superseded by Montgomery? > > > The Montgomery change got backported to jdk8u (JDK-8150152 in > 8u102). > > > I'd expect the performance improvement of these intrinsics to be > > > irrelevant for crypto.rsa. Did you measure with an older jdk8 > release? > > > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 14:15:31 > > 2017). The reported performance speedup was calculated by running the > > following test (TestSquareToLen.java): > > import java.math.BigInteger; > > > > public class TestSquareToLen { > > > > public static void main(String args[]) throws Exception { > > > > int n = 10000000; > > if (args.length >=1) { > > n = Integer.parseInt(args[0]); > > } > > > > BigInteger b1 = new > > BigInteger("3489398092355735908635051498208250392000229831187732085999 > > 36 > > 7395594183801021468843071391756049207873137016631559837931214754926092 > > 22 > > 3780292110207609223272184808289336630057735969423726808520641030118116 > > 51 > > 6440180488338234823908199478965242076358579845520899779963131131540166 > > 68 718795349783157384006672542605760392289645528307"); > > BigInteger b2 = BigInteger.valueOf(0); > > BigInteger check = BigInteger.valueOf(1); > > for (int i = 0; i < n; i++) { > > b2 = b1.multiply(b1); > > if (i == 0) > > // Didn't JIT yet. Comparing against interpreted mode > > check = b2; > > } > > if (b2.compareTo(check) == 0) > > System.out.println("Check ok!"); > > else > > System.out.println("Check failed!"); > > } > > } > > > > > > I got these results on JDK8 on my POWER8 machine: > > $ ./javac TestSquareToLen.java > > $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:- > > UseSquareToLenIntrinsic TestSquareToLen Check ok! > > Check ok! > > Check ok! > > Check ok! > > Check ok! > > > > Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:- > > UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > > > 15148.009557 task-clock (msec) # 1.053 CPUs > > utilized ( +- 0.48% ) > > 2,425 context-switches # 0.160 K/sec > > ( +- 5.84% ) > > 356 cpu-migrations # 0.023 K/sec > > ( +- 3.01% ) > > 5,153 page-faults # 0.340 K/sec > > ( +- 5.22% ) > > 54,536,889,909 cycles # 3.600 GHz > > ( +- 0.56% ) (66.68%) > > 239,554,105 stalled-cycles-frontend # 0.44% frontend > > cycles idle ( +- 4.87% ) (49.90%) > > 27,683,316,001 stalled-cycles-backend # 50.76% backend > > cycles idle ( +- 0.56% ) (50.17%) > > 102,020,229,733 instructions # 1.87 insn per > > cycle > > # 0.27 stalled > > cycles per insn ( +- 0.14% ) (66.94%) > > 7,706,072,218 branches # 508.718 M/sec > > ( +- 0.23% ) (50.20%) > > 456,051,162 branch-misses # 5.92% of all > > branches ( +- 0.09% ) (50.07%) > > > > 14.390840733 seconds time elapsed ( +- 0.09% ) > > > > $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic - > > XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! > > Check ok! > > Check ok! > > Check ok! > > Check ok! > > > > Performance counter stats for './java -XX:+UseMulAddIntrinsic - > > XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > > > 11368.141410 task-clock (msec) # 1.045 CPUs > > utilized ( +- 0.64% ) > > 1,964 context-switches # 0.173 K/sec > > ( +- 8.93% ) > > 338 cpu-migrations # 0.030 K/sec > > ( +- 7.65% ) > > 5,627 page-faults # 0.495 K/sec > > ( +- 6.15% ) > > 41,100,168,967 cycles # 3.615 GHz > > ( +- 0.50% ) (66.36%) > > 309,052,316 stalled-cycles-frontend # 0.75% frontend > > cycles idle ( +- 2.84% ) (49.89%) > > 14,188,581,685 stalled-cycles-backend # 34.52% backend > > cycles idle ( +- 0.99% ) (50.34%) > > 77,846,029,829 instructions # 1.89 insn per > > cycle > > # 0.18 stalled > > cycles per insn ( +- 0.29% ) (66.96%) > > 8,435,216,989 branches # 742.005 M/sec > > ( +- 0.28% ) (50.17%) > > 339,903,936 branch-misses # 4.03% of all > > branches ( +- 0.27% ) (49.90%) > > > > 10.882357546 seconds time elapsed ( +- 0.24% ) > > > > > > (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s (+- > > 0.53%) on JDK10) > > > > I may run for SpecJVM2008's crypto.rsa if you are interested. > > > > Thank you once again for reviewing this. > > > > Best regards, > > Gustavo > > > > > (I think the change is still acceptable as the intrinsics could be > > > used elsewhere and the implementation also exists on other > > > platforms.) > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Mittwoch, 16. August 2017 18:50 > > > To: Doerr, Martin ; 'hotspot-compiler- > > > dev at openjdk.java.net' > > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > Hi Martin, > > > > > > Thanks for dedicated review. It took me a while to be able to work > > > on this but I hope to have your points solved. Please check below > > > the review as well as my comments quoting your email: > > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > > > > > -----Original Message----- > > > > First of all, C2 does not perform sign extend when calling stubs. > > > > The int parms need to get zero/sign extended. (Could even be done > > > > without extra instructions by replacing sldi -> rldicl, cmpdi -> > > > > extsw_ in some > > > > cases.) > > > > > > Does it make a difference on my case? > > > > > > I guess you are talking about mulAdd preparation code. The only > > > aspect I found about him is to force the cast from 32 bits -> 64 > > > bits by cleaning higher bits. Offset is a signed integer but it > > > can't be > > negative anyway. > > > > > > So I changed from: > > > sldi (R5_ARG3, R5_ARG3, 2); > > > > > > to: > > > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > > > > > > > macroAssembler_ppc.cpp: > > > > - Indentation should be 2 spaces. > > > > > > Done > > > > > > > > > > stubGenerator_ppc:cpp: > > > > - or_, addi_ should get replaced by orr, addi when CR0 result is > > > > not needed. > > > > > > Done > > > > > > > - Where is lplw initialized? > > > > > > It should be initialized with 0, I missed that... > > > > > > > - I believe that the updating load/store instructions e.g. lwzu > > > > don't perform well on some processors. At least using stwu 2 times > > > > in the loop doesn't make sense. > > > > > > You are right. I could manipulate the bits differently and ended up > > > with a single stdu in the loop. Neat! Although I could not reduce > > > the total number of instructions. > > > > > > > - Note: It should be possible to use 8 byte instead of 4 byte > > > > instructions: MacroAssembler::multiply64, addc, adde. But I'm not > > > > requesting to change that because I guess it would make the code > > > > very complicated, especially when supporting both endianess > > versions. > > > > > > Yes, that would require a new analysis on this code. May we consider > > > it next? As you said, I prefer having an initial version that looks > > > as simple as the original java code. > > > > > > > - The squareToLen stub implementation is very close the Java > > > > implementation. So it'd be interesting to understand what C2 > > > > doesn't do as well as the hand written assembly code. Do you know > > > > that? (Not absolutely necessary for accepting this change as long > > > > as the stub is measurably faster.) > > > > > > I don't know either. Basically I chose doing it because I noticed > > > some performance gain on SpecJVM2008 when analyzing X64. Then, > > > taking a closer look, I didn't notice any AVX or some special > > > instructions on > > > X64 so I decided to try it on ppc64 by using some basic assembly. > > > > > > Thanks > > > > > > > > > > > Best regards, > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > Sent: Donnerstag, 10. August 2017 19:22 > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > dev at openjdk.java.net> > > > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > > SquareToLen intrinsics > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > > SquareToLen intrinsics > > > > > > > > Hi, > > > > > > > > Could you please review this specific PPC64 change to hotspot? By > > > > implementing these intrinsics I noticed a small improvement with > > > > microbenchmarks analysis. On SpecJVM2008's crypto.rsa benchmark, > > > > only when backporting to JDK8 an improvement was noticed. > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > > > > > Motivation for this implementation: > > > > https://twitter.com/ijuma/status/698309312498835457 > > > > > > > > Best regards, > > > > Gustavo Serra Scalet From rob.mckenna at oracle.com Tue Sep 26 18:33:15 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 26 Sep 2017 19:33:15 +0100 Subject: No subject Message-ID: <20170926183315.GE3997@vimes> Hi folks, Looking for approval for this clean backport: https://bugs.openjdk.java.net/browse/JDK-8184328 http://hg.openjdk.java.net/jdk10/master/rev/dc9b1da1314b http://mail.openjdk.java.net/pipermail/net-dev/2017-September/010925.html -Rob From rob.mckenna at oracle.com Tue Sep 26 18:38:15 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 26 Sep 2017 19:38:15 +0100 Subject: [8u-dev] Request for approval for 8184328: JDK 8u131 socketRead0 hang at SSL read In-Reply-To: <20170926183315.GE3997@vimes> References: <20170926183315.GE3997@vimes> Message-ID: <20170926183815.GF3997@vimes> Now with added subject goodness. -Rob On 26/09/17 07:33, Rob McKenna wrote: > Hi folks, > > Looking for approval for this clean backport: > > https://bugs.openjdk.java.net/browse/JDK-8184328 > http://hg.openjdk.java.net/jdk10/master/rev/dc9b1da1314b > http://mail.openjdk.java.net/pipermail/net-dev/2017-September/010925.html > > -Rob > From sean.coffey at oracle.com Tue Sep 26 18:44:23 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 26 Sep 2017 19:44:23 +0100 Subject: [8u-dev] Request for approval for 8184328: JDK 8u131 socketRead0 hang at SSL read In-Reply-To: <20170926183815.GF3997@vimes> References: <20170926183315.GE3997@vimes> <20170926183815.GF3997@vimes> Message-ID: Approved. regards, Sean. On 26/09/2017 19:38, Rob McKenna wrote: > Now with added subject goodness. > > -Rob > > On 26/09/17 07:33, Rob McKenna wrote: >> Hi folks, >> >> Looking for approval for this clean backport: >> >> https://bugs.openjdk.java.net/browse/JDK-8184328 >> http://hg.openjdk.java.net/jdk10/master/rev/dc9b1da1314b >> http://mail.openjdk.java.net/pipermail/net-dev/2017-September/010925.html >> >> -Rob >> From rob.mckenna at oracle.com Tue Sep 26 18:46:53 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Tue, 26 Sep 2017 19:46:53 +0100 Subject: [8u-dev] Request for enhancement backport approval for : 8170157: Enable unlimited cryptographic policy by default in OracleJDK In-Reply-To: <20170905150217.GA4927@vimes> References: <20170905150217.GA4927@vimes> Message-ID: <20170926184653.GG3997@vimes> This enhancement has been approved. -Rob On 05/09/17 04:02, Rob McKenna wrote: > Thanks Sean, this has been submitted for approval. > > -Rob > > On 18/08/17 02:57, Se?n Coffey wrote: > > I'd like to backport the following enhancement to jdk8u-dev : > > > > JDK-8157561 allowed us to ship the unlimited policy files in the upcoming > > 8u152 release. We should now look at enabling unlimited crypto by default. > > > > https://bugs.openjdk.java.net/browse/JDK-8170157 > > > > -- > > Regards, > > Sean. > > From gustavo.scalet at eldorado.org.br Wed Sep 27 14:10:15 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Wed, 27 Sep 2017 14:10:15 +0000 Subject: "xdual(xdual()) should be identity" error when backporting Montgomery multiplication to JDK8 (PPC64le) In-Reply-To: References: <49dadbf6eaea4823926340bc51d56cea@serv031.corp.eldorado.org.br> <761ab8e6512c4b5ea043131a4f0882ae@serv031.corp.eldorado.org.br> Message-ID: <1253d53c8845452a9caf6a843d87fe57@serv031.corp.eldorado.org.br> Hi, Martin helped me on this one: https://gist.github.com/anonymous/b3a8782aac9d56615d6e15db834335b4#file-montgomery-diff-L76 I was incrementing argcnt after it was being used on: const Type** fields = TypeTuple::fields(argcnt); So the check: assert(argp == TypeFunc::Parms+argcnt, "correct decoding"); was valid but the fields array was not! Now it is working. I'll send the backport for review soon. > -----Original Message----- > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > Sent: ter?a-feira, 26 de setembro de 2017 10:06 > To: Doerr, Martin > Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > Subject: RE: "xdual(xdual()) should be identity" error when backporting > Montgomery multiplication to JDK8 (PPC64le) > > > > > -----Original Message----- > > From: Doerr, Martin > > > Hi, > > > > did you feed the right argcnt into: > > const Type** fields = TypeTuple::fields(argcnt); ? > > Yes, that looks ok. > > > If this is not the problem, I guess you'll have to debug. > > Alright. I'll post the results for reference. > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Montag, 25. September 2017 21:12 > > To: Doerr, Martin > > Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > Subject: RE: "xdual(xdual()) should be identity" error when > > backporting Montgomery multiplication to JDK8 (PPC64le) > > > > In order words, despite the proper JDK9 commit[1] I added these > > changes due to CCallingConventionRequiresIntsAsLongs: > > https://gist.github.com/anonymous/b3a8782aac9d56615d6e15db834335b4 > > > > References: > > [1] http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d > > > > -----Original Message----- > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > Sent: segunda-feira, 25 de setembro de 2017 15:55 > > To: Doerr, Martin > > Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > Subject: RE: "xdual(xdual()) should be identity" error when > > backporting Montgomery multiplication to JDK8 (PPC64le) > > > > Yup: > > Node* call = NULL; > > if (CCallingConventionRequiresIntsAsLongs) { > > Node* len_I2L = ConvI2L(len); > > call = make_runtime_call(RC_LEAF, > > OptoRuntime::montgomeryMultiply_Type(), > > stubAddr, stubName, TypePtr::BOTTOM, > > a_start, b_start, n_start, len_I2L XTOP, > inv, > > top(), m_start); } else { > > call = make_runtime_call(RC_LEAF, > > OptoRuntime::montgomeryMultiply_Type(), > > stubAddr, stubName, TypePtr::BOTTOM, > > a_start, b_start, n_start, len, inv, top(), > > m_start); > > } > > set_result(m); > > > > > > Any other thing I may be missing? > > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: segunda-feira, 25 de setembro de 2017 13:55 > > To: Gustavo Serra Scalet > > Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > Subject: RE: "xdual(xdual()) should be identity" error when > > backporting Montgomery multiplication to JDK8 (PPC64le) > > > > Hi Gustavo, > > > > Did you also change library_call? > > Should be something like (example for multiplyToLen): > > > > Node* call = NULL; > > if (CCallingConventionRequiresIntsAsLongs) { > > Node* xlen_I2L = ConvI2L(xlen); > > Node* ylen_I2L = ConvI2L(ylen); > > Node* zlen_I2L = ConvI2L(zlen); > > call = make_runtime_call(RC_LEAF|RC_NO_FP, > > OptoRuntime::multiplyToLen_Type(), > > stubAddr, stubName, TypePtr::BOTTOM, > > x_start, xlen_I2L XTOP, y_start, > > ylen_I2L XTOP, z_start, zlen_I2L XTOP); > > } > > else { > > call = make_runtime_call(RC_LEAF|RC_NO_FP, > > OptoRuntime::multiplyToLen_Type(), > > stubAddr, stubName, TypePtr::BOTTOM, > > x_start, xlen, y_start, ylen, > > z_start, zlen); > > } > > > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Montag, 25. September 2017 16:03 > > To: Doerr, Martin > > Cc: jdk8u-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net > > Subject: "xdual(xdual()) should be identity" error when backporting > > Montgomery multiplication to JDK8 (PPC64le) > > > > Hi, > > > > Previously I faced some issues when backporting intrinsics to JDK8[1] > > but after some help, manage to make it work. > > > > Despite following those rules related to CCallingConvention and Int -> > > Long conversion, I still face issues not previously noticed on JDK9 > > when running SpecJVM2008's crypto.rsa bechmark. > > > > [release build]: > > Benchmark: crypto.rsa > > Run mode: timed run > > Test type: multi > > Threads: 24 > > Warmup: 120s > > Iterations: 1 > > Run length: 240s > > # > > # A fatal error has been detected by the Java Runtime Environment: > > # > > # SIGSEGV (0xb) at pc=0x00003fffa0cc6f84, pid=3698, > > tid=0x00003fff7a34f1a0 # # JRE version: OpenJDK Runtime Environment > > (8.0) (build 1.8.0-internal-gut_2017_04_12_09_19-b00) > > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-ppc64 > > compressed oops) # Problematic frame: > > # V [libjvm.so+0x446f84] > > ConnectionGraph::process_call_arguments(CallNode*)+0x1c4 > > > > > > [slowdebug build]: > > Benchmark: crypto.rsa > > Run mode: timed run > > Test type: multi > > Threads: 24 > > Warmup: 120s > > Iterations: 1 > > Run length: 240s > > # To suppress the following error report, specify this argument # > > after > > -XX: or in .hotspotrc: SuppressErrorAt=/type.cpp:596 # # A fatal > > error has been detected by the Java Runtime Environment: > > # > > # Internal Error (/home/gut/jdk8u- > > dev/hotspot/src/share/vm/opto/type.cpp:596), pid=6793, > > tid=0x00003fff5847f1a0 # assert(eq(dual_dual)) failed: xdual(xdual()) > > should be identity > > > > > > > > Any hints? I see the issue is when calling the last line of this code > > on > > runtime.cpp: > > const TypeFunc* OptoRuntime::montgomeryMultiply_Type() { > > // create input type (domain) > > int num_args = 7; > > int argcnt = num_args; > > const Type** fields = TypeTuple::fields(argcnt); > > int argp = TypeFunc::Parms; > > fields[argp++] = TypePtr::NOTNULL; // a > > fields[argp++] = TypePtr::NOTNULL; // b > > fields[argp++] = TypePtr::NOTNULL; // n > > if (CCallingConventionRequiresIntsAsLongs) { > > argcnt += 1; // additional placeholders > > fields[argp++] = TypeLong::LONG; // len > > fields[argp++] = TypeLong::HALF; // placeholder > > } else { > > fields[argp++] = TypeInt::INT; // len > > } > > fields[argp++] = TypeLong::LONG; // inv > > fields[argp++] = Type::HALF; > > fields[argp++] = TypePtr::NOTNULL; // result > > assert(argp == TypeFunc::Parms+argcnt, "correct decoding"); > > const TypeTuple* domain = TypeTuple::make(TypeFunc::Parms+argcnt, > > fields); > > > > > > > > Thanks > > > > References: > > [1] http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/2017- > > April/002970.html > > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: sexta-feira, 15 de setembro de 2017 04:39 > > To: Gustavo Serra Scalet > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics (off-list) > > > > Hi Gustavo, > > > > you can request backport by sending a > > [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery > > multiply intrinsic to jdk8u-dev at openjdk.java.net > > > > But first of all, you need to check if the change applies to 8u and > > run tests. > > > > The following information is needed in the email: > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 > > Jdk9 change: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d > > Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot- > > compiler-dev/2015-December/020534.html > > Statement: Change applies cleanly or describe which changes were > > necessary You should also mention that it belongs to 8u102 backport of > > https://bugs.openjdk.java.net/browse/JDK-8150152 > > > > Once it's approved, you can ask a jdk8u reviewer or committer (which > > I'm > > not) to push it. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > Sent: Donnerstag, 14. September 2017 21:00 > > To: Doerr, Martin ; 'hotspot-compiler- > > dev at openjdk.java.net' > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > SquareToLen intrinsics > > > > Hi Martin, > > > > Short question about the Montgomery backport to JDK8: > > > > > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 > > > > 14:15:31 2017). The reported performance speedup was calculated by > > > > > running the following test (TestSquareToLen.java): > > > > > > Seems like JDK-8145913 has not been backported, yet. Sorry for not > > > checking this earlier. So if you want to make RSA really fast, it > > > should be so much better to backport that one. But I can still > > > sponsor this change as it may be used elsewhere. > > > > Do we have a bug ID for the Montgomery backport to JDK8 so I can track > > it? If not, should I request that backport or request this intrinsic > > to be backported (once it's inside of JDK10)? I'm interested in this > > kind of performance gain. > > > > Thanks > > > > > > > > Best regards, > > > Martin > > > > > > > > > -----Original Message----- > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > Sent: Dienstag, 29. August 2017 22:37 > > > To: Doerr, Martin ; 'hotspot-compiler- > > > dev at openjdk.java.net' > > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > SquareToLen intrinsics > > > > > > Hi Martin, > > > > > > New changes: > > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.02/ > > > > > > Check comments below, please. > > > > > > > -----Original Message----- > > > > From: Doerr, Martin > > > > > > > > 1. Sign extending offset and len > > > > Right, sign and zero extending is equivalent for offset and len > > > > because they are guaranteed to be >=0 (by checks in Java). But you > > > > can only rely on bit 32 (IBM notation) to be 0. Bit 0-31 may > > > > contain > > > garbage. > > > > rldicl was incorrect. My mistake, sorry for that. Correct would be > > > > rldic which also clears the least significant bits. > > > > len should also get fixed e.g. by replacing cmpdi by extsw_ in > > muladd. > > > > > > The s/rldicl/rldic/ was fixed for "offset", but "len" doesn't seem > > > to need further changes as it's being cleared with clrldi, which is > > > the same as rldic with no shift. Therefore it's treated > > > appropriately as requested for "offset" parameter. Do you agree? > > > > > > > 2. Using 8 byte instructions for int The code which feeds stdu is > > > > endianess specific. Doesn't work on all > > > > PPC64 platforms. > > > > > > You are right. The way I'm building the 64 bits of the register > > > depends on which kind of endianness it is run. For now it works only > > > on little endian so I'm adding a switch (just like I did for SHA) to > > > make it available only on little endian systems. > > > > > > > 3.Regarding Andrew's point: Superseded by Montgomery? > > > > The Montgomery change got backported to jdk8u (JDK-8150152 in > > 8u102). > > > > I'd expect the performance improvement of these intrinsics to be > > > > irrelevant for crypto.rsa. Did you measure with an older jdk8 > > release? > > > > > > No, I used the jdk8u152-b01 (State of repository at Thu Apr 6 > > > 14:15:31 2017). The reported performance speedup was calculated by > > > running the following test (TestSquareToLen.java): > > > import java.math.BigInteger; > > > > > > public class TestSquareToLen { > > > > > > public static void main(String args[]) throws Exception { > > > > > > int n = 10000000; > > > if (args.length >=1) { > > > n = Integer.parseInt(args[0]); > > > } > > > > > > BigInteger b1 = new > > > BigInteger("34893980923557359086350514982082503920002298311877320859 > > > 99 > > > 36 > > > 73955941838010214688430713917560492078731370166315598379312147549260 > > > 92 > > > 22 > > > 37802921102076092232721848082893366300577359694237268085206410301181 > > > 16 > > > 51 > > > 64401804883382348239081994789652420763585798455208997799631311315401 > > > 66 > > > 68 718795349783157384006672542605760392289645528307"); > > > BigInteger b2 = BigInteger.valueOf(0); > > > BigInteger check = BigInteger.valueOf(1); > > > for (int i = 0; i < n; i++) { > > > b2 = b1.multiply(b1); > > > if (i == 0) > > > // Didn't JIT yet. Comparing against interpreted mode > > > check = b2; > > > } > > > if (b2.compareTo(check) == 0) > > > System.out.println("Check ok!"); > > > else > > > System.out.println("Check failed!"); > > > } > > > } > > > > > > > > > I got these results on JDK8 on my POWER8 machine: > > > $ ./javac TestSquareToLen.java > > > $ sudo perf stat -r 5 ./java -XX:-UseMulAddIntrinsic -XX:- > > > UseSquareToLenIntrinsic TestSquareToLen Check ok! > > > Check ok! > > > Check ok! > > > Check ok! > > > Check ok! > > > > > > Performance counter stats for './java -XX:-UseMulAddIntrinsic -XX:- > > > UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > > > > > 15148.009557 task-clock (msec) # 1.053 CPUs > > > utilized ( +- 0.48% ) > > > 2,425 context-switches # 0.160 K/sec > > > ( +- 5.84% ) > > > 356 cpu-migrations # 0.023 K/sec > > > ( +- 3.01% ) > > > 5,153 page-faults # 0.340 K/sec > > > ( +- 5.22% ) > > > 54,536,889,909 cycles # 3.600 GHz > > > ( +- 0.56% ) (66.68%) > > > 239,554,105 stalled-cycles-frontend # 0.44% > frontend > > > cycles idle ( +- 4.87% ) (49.90%) > > > 27,683,316,001 stalled-cycles-backend # 50.76% backend > > > cycles idle ( +- 0.56% ) (50.17%) > > > 102,020,229,733 instructions # 1.87 insn > per > > > cycle > > > # 0.27 stalled > > > cycles per insn ( +- 0.14% ) (66.94%) > > > 7,706,072,218 branches # 508.718 M/sec > > > ( +- 0.23% ) (50.20%) > > > 456,051,162 branch-misses # 5.92% of all > > > branches ( +- 0.09% ) (50.07%) > > > > > > 14.390840733 seconds time elapsed ( +- 0.09% ) > > > > > > $ sudo perf stat -r 5 ./java -XX:+UseMulAddIntrinsic - > > > XX:+UseSquareToLenIntrinsic TestSquareToLen Check ok! > > > Check ok! > > > Check ok! > > > Check ok! > > > Check ok! > > > > > > Performance counter stats for './java -XX:+UseMulAddIntrinsic - > > > XX:+UseSquareToLenIntrinsic TestSquareToLen' (5 runs): > > > > > > 11368.141410 task-clock (msec) # 1.045 CPUs > > > utilized ( +- 0.64% ) > > > 1,964 context-switches # 0.173 K/sec > > > ( +- 8.93% ) > > > 338 cpu-migrations # 0.030 K/sec > > > ( +- 7.65% ) > > > 5,627 page-faults # 0.495 K/sec > > > ( +- 6.15% ) > > > 41,100,168,967 cycles # 3.615 GHz > > > ( +- 0.50% ) (66.36%) > > > 309,052,316 stalled-cycles-frontend # 0.75% > frontend > > > cycles idle ( +- 2.84% ) (49.89%) > > > 14,188,581,685 stalled-cycles-backend # 34.52% backend > > > cycles idle ( +- 0.99% ) (50.34%) > > > 77,846,029,829 instructions # 1.89 insn > per > > > cycle > > > # 0.18 stalled > > > cycles per insn ( +- 0.29% ) (66.96%) > > > 8,435,216,989 branches # 742.005 M/sec > > > ( +- 0.28% ) (50.17%) > > > 339,903,936 branch-misses # 4.03% of all > > > branches ( +- 0.27% ) (49.90%) > > > > > > 10.882357546 seconds time elapsed ( +- 0.24% ) > > > > > > > > > (out of curiosity, these numbers are 15.19s (+- 0.32%) and 13.42s > > > (+- > > > 0.53%) on JDK10) > > > > > > I may run for SpecJVM2008's crypto.rsa if you are interested. > > > > > > Thank you once again for reviewing this. > > > > > > Best regards, > > > Gustavo > > > > > > > (I think the change is still acceptable as the intrinsics could be > > > > used elsewhere and the implementation also exists on other > > > > platforms.) > > > > > > > > Best regards, > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > From: Gustavo Serra Scalet [mailto:gustavo.scalet at eldorado.org.br] > > > > Sent: Mittwoch, 16. August 2017 18:50 > > > > To: Doerr, Martin ; 'hotspot-compiler- > > > > dev at openjdk.java.net' > > > > Subject: RE: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > > SquareToLen intrinsics > > > > > > > > Hi Martin, > > > > > > > > Thanks for dedicated review. It took me a while to be able to work > > > > on this but I hope to have your points solved. Please check below > > > > the review as well as my comments quoting your email: > > > > https://gut.github.io/openjdk/webrev/JDK-8185976/webrev.01/ > > > > > > > > > -----Original Message----- > > > > > First of all, C2 does not perform sign extend when calling > stubs. > > > > > The int parms need to get zero/sign extended. (Could even be > > > > > done without extra instructions by replacing sldi -> rldicl, > > > > > cmpdi -> extsw_ in some > > > > > cases.) > > > > > > > > Does it make a difference on my case? > > > > > > > > I guess you are talking about mulAdd preparation code. The only > > > > aspect I found about him is to force the cast from 32 bits -> 64 > > > > bits by cleaning higher bits. Offset is a signed integer but it > > > > can't be > > > negative anyway. > > > > > > > > So I changed from: > > > > sldi (R5_ARG3, R5_ARG3, 2); > > > > > > > > to: > > > > rldicl (R5_ARG3, R5_ARG3, 2, 32); // always positive > > > > > > > > > > > > > macroAssembler_ppc.cpp: > > > > > - Indentation should be 2 spaces. > > > > > > > > Done > > > > > > > > > > > > > stubGenerator_ppc:cpp: > > > > > - or_, addi_ should get replaced by orr, addi when CR0 result is > > > > > not needed. > > > > > > > > Done > > > > > > > > > - Where is lplw initialized? > > > > > > > > It should be initialized with 0, I missed that... > > > > > > > > > - I believe that the updating load/store instructions e.g. lwzu > > > > > don't perform well on some processors. At least using stwu 2 > > > > > times in the loop doesn't make sense. > > > > > > > > You are right. I could manipulate the bits differently and ended > > > > up with a single stdu in the loop. Neat! Although I could not > > > > reduce the total number of instructions. > > > > > > > > > - Note: It should be possible to use 8 byte instead of 4 byte > > > > > instructions: MacroAssembler::multiply64, addc, adde. But I'm > > > > > not requesting to change that because I guess it would make the > > > > > code very complicated, especially when supporting both endianess > > > versions. > > > > > > > > Yes, that would require a new analysis on this code. May we > > > > consider it next? As you said, I prefer having an initial version > > > > that looks as simple as the original java code. > > > > > > > > > - The squareToLen stub implementation is very close the Java > > > > > implementation. So it'd be interesting to understand what C2 > > > > > doesn't do as well as the hand written assembly code. Do you > > > > > know that? (Not absolutely necessary for accepting this change > > > > > as long as the stub is measurably faster.) > > > > > > > > I don't know either. Basically I chose doing it because I noticed > > > > some performance gain on SpecJVM2008 when analyzing X64. Then, > > > > taking a closer look, I didn't notice any AVX or some special > > > > instructions on > > > > X64 so I decided to try it on ppc64 by using some basic assembly. > > > > > > > > Thanks > > > > > > > > > > > > > > Best regards, > > > > > Martin > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: hotspot-compiler-dev [mailto:hotspot-compiler-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: Donnerstag, 10. August 2017 19:22 > > > > > To: 'hotspot-compiler-dev at openjdk.java.net' > > > > dev at openjdk.java.net> > > > > > Subject: FW: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > > > SquareToLen intrinsics > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: ppc-aix-port-dev [mailto:ppc-aix-port-dev- > > > > > bounces at openjdk.java.net] On Behalf Of Gustavo Serra Scalet > > > > > Sent: ter?a-feira, 8 de agosto de 2017 17:19 > > > > > To: ppc-aix-port-dev at openjdk.java.net > > > > > Subject: [10] RFR(M): 8185976: PPC64: Implement MulAdd and > > > > > SquareToLen intrinsics > > > > > > > > > > Hi, > > > > > > > > > > Could you please review this specific PPC64 change to hotspot? > > > > > By implementing these intrinsics I noticed a small improvement > > > > > with microbenchmarks analysis. On SpecJVM2008's crypto.rsa > > > > > benchmark, only when backporting to JDK8 an improvement was > noticed. > > > > > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8185976 > > > > > Webrev: https://gut.github.io/openjdk/webrev/JDK-8185976/webrev/ > > > > > > > > > > Motivation for this implementation: > > > > > https://twitter.com/ijuma/status/698309312498835457 > > > > > > > > > > Best regards, > > > > > Gustavo Serra Scalet From sean.coffey at oracle.com Wed Sep 27 14:42:49 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Wed, 27 Sep 2017 15:42:49 +0100 Subject: [jdk8u-dev] Request for approval : 8170157, 8170245: Enable unlimited cryptographic policy by default in OracleJDK Message-ID: Looking to push both these fixes to jdk8u-dev: https://bugs.openjdk.java.net/browse/JDK-8170157 https://bugs.openjdk.java.net/browse/JDK-8170245 Review was carried out at : http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016237.html final webrev : http://cr.openjdk.java.net/~coffeys/webrev.8170157.8u.02/webrev/ This enhancement backport has already been approved. regards, Sean. From gustavo.scalet at eldorado.org.br Wed Sep 27 14:55:08 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Wed, 27 Sep 2017 14:55:08 +0000 Subject: [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic Message-ID: Hi, Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020534.html Unfortunately the Jdk9 change doesn't apply cleanly. Below the are reasons for the adaptations: 1) This stub call uses integer type on a 64 bits register so a conversion to long was additionally needed. 2) Avoid changing the ppc.ad file as some interfaces were not existing. My changes are available on: https://gut.github.io/openjdk/webrev/JDK-8145913/webrev/index.html This change also belongs to 8u102 backport of https://bugs.openjdk.java.net/browse/JDK-8150152 Thanks to this change, SpecJVM2008's crypto.rsa benchmark had a speedup of 3.1 on ppc64le! Gustavo Serra Scalet From rob.mckenna at oracle.com Wed Sep 27 15:19:57 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 27 Sep 2017 16:19:57 +0100 Subject: [jdk8u-dev] Request for approval : 8170157, 8170245: Enable unlimited cryptographic policy by default in OracleJDK In-Reply-To: References: Message-ID: <20170927151957.GB6441@vimes> Approved! Nice work. -Rob On 27/09/17 03:42, Se?n Coffey wrote: > Looking to push both these fixes to jdk8u-dev: > > https://bugs.openjdk.java.net/browse/JDK-8170157 > https://bugs.openjdk.java.net/browse/JDK-8170245 > > Review was carried out at : > > http://mail.openjdk.java.net/pipermail/security-dev/2017-August/016237.html > > final webrev : > http://cr.openjdk.java.net/~coffeys/webrev.8170157.8u.02/webrev/ > > This enhancement backport has already been approved. > > regards, > Sean. > From rob.mckenna at oracle.com Wed Sep 27 15:22:36 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 27 Sep 2017 16:22:36 +0100 Subject: [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic In-Reply-To: References: Message-ID: <20170927152236.GC6441@vimes> Hi Gustavo, Since the code has changed this requires a codereview for the 8 specific code. (ideally from someone with ppc knowledge) Approved subject to obtaining this review. -Rob On 27/09/17 02:55, Gustavo Serra Scalet wrote: > Hi, > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 > Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d > Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020534.html > > Unfortunately the Jdk9 change doesn't apply cleanly. Below the are reasons for the adaptations: > > 1) This stub call uses integer type on a 64 bits register so a conversion to long was additionally needed. > 2) Avoid changing the ppc.ad file as some interfaces were not existing. > > My changes are available on: https://gut.github.io/openjdk/webrev/JDK-8145913/webrev/index.html > > This change also belongs to 8u102 backport of https://bugs.openjdk.java.net/browse/JDK-8150152 > > > Thanks to this change, SpecJVM2008's crypto.rsa benchmark had a speedup of 3.1 on ppc64le! > > Gustavo Serra Scalet > From martin.doerr at sap.com Wed Sep 27 15:36:34 2017 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 27 Sep 2017 15:36:34 +0000 Subject: [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic In-Reply-To: <20170927152236.GC6441@vimes> References: <20170927152236.GC6441@vimes> Message-ID: <8f85be8893c14c6f8e106250a93e84b0@sap.com> Hi Rob, I have reviewed it as the author of the original change, but not as official backport reviewer (I'm only jdk9+10 reviewer). Adding the int to long conversion is needed in 8u and looks correct to me. It makes sense to leave the ad file alone. The jdk9 change contains some additional stuff in it which should not be part of the backport. Best regards, Martin -----Original Message----- From: Rob McKenna [mailto:rob.mckenna at oracle.com] Sent: Mittwoch, 27. September 2017 17:23 To: Gustavo Serra Scalet Cc: jdk8u-dev at openjdk.java.net; Doerr, Martin Subject: Re: [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic Hi Gustavo, Since the code has changed this requires a codereview for the 8 specific code. (ideally from someone with ppc knowledge) Approved subject to obtaining this review. -Rob On 27/09/17 02:55, Gustavo Serra Scalet wrote: > Hi, > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 > Jdk9 change: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d > Jdk9 review thread: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-December/020534.html > > Unfortunately the Jdk9 change doesn't apply cleanly. Below the are reasons for the adaptations: > > 1) This stub call uses integer type on a 64 bits register so a conversion to long was additionally needed. > 2) Avoid changing the ppc.ad file as some interfaces were not existing. > > My changes are available on: https://gut.github.io/openjdk/webrev/JDK-8145913/webrev/index.html > > This change also belongs to 8u102 backport of https://bugs.openjdk.java.net/browse/JDK-8150152 > > > Thanks to this change, SpecJVM2008's crypto.rsa benchmark had a speedup of 3.1 on ppc64le! > > Gustavo Serra Scalet > From aleksej.efimov at oracle.com Wed Sep 27 21:28:28 2017 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 27 Sep 2017 22:28:28 +0100 Subject: [8u-dev][JAXB] Request for review and approval: 8159240: XSOM parser incorrectly processes type names with whitespaces Message-ID: <008ef343-c8f7-bb3d-8c51-5acec3e77a72@oracle.com> Hi, Can I, please, ask for review and approval of JDK-8159240 backport to JDK8? This bug was resolved in JDK9 as part of JAXWS-RI sync changeset (JDK-8164479) therefore separate review for the partially backported changes is needed: http://cr.openjdk.java.net/~aefimov/8159240/8/00/ File changes partially backported to JDK8 from JDK9 sync changeset: ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l37.1 ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l38.1 ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l39.1 ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l40.1 ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l41.1 ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l42.1 ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l43.1 ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l44.1 ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l45.1 Testing: ??? New regression test and all jaxb/ws related JCK/JTREG tests shows no failures. JBS bug: ??? https://bugs.openjdk.java.net/browse/JDK-8159240 JAXWS-RI sync bug: ??? https://bugs.openjdk.java.net/browse/JDK-8164479 JDK9 JAXWS-RI sync changeset: ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052 JDK9 JAXWS-RI sync review threads: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043724.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/043920.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044513.html JAXWS-RI changes for XSOM parser: https://github.com/javaee/jaxb-v2/commit/cc9c09a71d739989d1e250d9db8c1e011215abfd#diff-796464168dc0014203b00c9728d41de8 With Best Regards, Aleksei From mbrandy at linux.vnet.ibm.com Wed Sep 27 21:33:29 2017 From: mbrandy at linux.vnet.ibm.com (Matthew Brandyberry) Date: Wed, 27 Sep 2017 16:33:29 -0500 Subject: [8u] RFA for backport of 8181810: PPC64: Leverage extrdi for bitfield extract Message-ID: Hi,// // Please approve the backport of JDK-8181810 fix to jdk8u. The JDK10 change applies cleanly. Bug: https://bugs.openjdk.java.net/browse/JDK-8181810 Changeset: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/f025cf2a4a78 Review Thread: http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-June/027247.html Thanks, Matt From rob.mckenna at oracle.com Thu Sep 28 13:58:43 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 28 Sep 2017 14:58:43 +0100 Subject: [8u] RFA for backport of 8181810: PPC64: Leverage extrdi for bitfield extract In-Reply-To: References: Message-ID: <20170928135843.GA3741@vimes> Approved. Please add an appropriate noreg label to the bug. -Rob On 27/09/17 04:33, Matthew Brandyberry wrote: > Hi,// > // > Please approve the backport of JDK-8181810 fix to jdk8u. > > The JDK10 change applies cleanly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8181810 > Changeset: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/f025cf2a4a78 > Review Thread: > http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-June/027247.html > > Thanks, > Matt > From hannes.wallnoefer at oracle.com Thu Sep 28 16:32:18 2017 From: hannes.wallnoefer at oracle.com (=?utf-8?Q?Hannes_Walln=C3=B6fer?=) Date: Thu, 28 Sep 2017 18:32:18 +0200 Subject: [8u-dev] Request for approval: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks Message-ID: <92F20664-9868-4021-A554-357143C6999F@oracle.com> Please approve the backport of JDK-8184893 to jdk8u-dev: Bug: https://bugs.openjdk.java.net/browse/JDK-8184893 Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-July/006981.html JDK 10 webrev: http://cr.openjdk.java.net/~hannesw/8184893/webrev/ The patch applies cleanly to 8u-dev after path reshuffling. Thanks, Hannes From james.laskey at oracle.com Thu Sep 28 16:33:43 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Thu, 28 Sep 2017 13:33:43 -0300 Subject: [8u-dev] Request for approval: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks In-Reply-To: <92F20664-9868-4021-A554-357143C6999F@oracle.com> References: <92F20664-9868-4021-A554-357143C6999F@oracle.com> Message-ID: <3788BAD5-27BD-49D9-AEA4-834B213DE666@oracle.com> +1 > On Sep 28, 2017, at 1:32 PM, Hannes Walln?fer wrote: > > Please approve the backport of JDK-8184893 to jdk8u-dev: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184893 > Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-July/006981.html > JDK 10 webrev: http://cr.openjdk.java.net/~hannesw/8184893/webrev/ > > The patch applies cleanly to 8u-dev after path reshuffling. > > Thanks, > Hannes > From sean.coffey at oracle.com Thu Sep 28 17:02:35 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 28 Sep 2017 18:02:35 +0100 Subject: [8u-dev][JAXB] Request for review and approval: 8159240: XSOM parser incorrectly processes type names with whitespaces In-Reply-To: <008ef343-c8f7-bb3d-8c51-5acec3e77a72@oracle.com> References: <008ef343-c8f7-bb3d-8c51-5acec3e77a72@oracle.com> Message-ID: This looks fine Aleksei.? Approved for jdk8u-dev. The JDK-8159240 record is currently closed as a duplicate. I'd suggest you reopen that master record for your 8u-dev port and mark it 9-na. regards, Sean. On 27/09/2017 22:28, Aleks Efimov wrote: > Hi, > > Can I, please, ask for review and approval of JDK-8159240 backport to > JDK8? This bug was resolved in JDK9 as part of JAXWS-RI sync changeset > (JDK-8164479) therefore separate review for the partially backported > changes is needed: http://cr.openjdk.java.net/~aefimov/8159240/8/00/ > > File changes partially backported to JDK8 from JDK9 sync changeset: > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l37.1 > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l38.1 > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l39.1 > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l40.1 > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l41.1 > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l42.1 > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l43.1 > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l44.1 > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052#l45.1 > > Testing: > ??? New regression test and all jaxb/ws related JCK/JTREG tests shows > no failures. > > JBS bug: > ??? https://bugs.openjdk.java.net/browse/JDK-8159240 > > JAXWS-RI sync bug: > ??? https://bugs.openjdk.java.net/browse/JDK-8164479 > > JDK9 JAXWS-RI sync changeset: > ??? http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/26c9b9c51052 > > JDK9 JAXWS-RI sync review threads: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043724.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-October/043920.html > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-November/044513.html > > > JAXWS-RI changes for XSOM parser: > https://github.com/javaee/jaxb-v2/commit/cc9c09a71d739989d1e250d9db8c1e011215abfd#diff-796464168dc0014203b00c9728d41de8 > > > With Best Regards, > Aleksei > From sean.coffey at oracle.com Thu Sep 28 17:03:13 2017 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Thu, 28 Sep 2017 18:03:13 +0100 Subject: [8u-dev] Request for approval: 8184893: jdk8u152 b06 : issues with nashorn when running kraken benchmarks In-Reply-To: <92F20664-9868-4021-A554-357143C6999F@oracle.com> References: <92F20664-9868-4021-A554-357143C6999F@oracle.com> Message-ID: <20744c01-ec08-2cad-d2c5-e5c3c972014b@oracle.com> Approved for jdk8u-dev. regards, Sean. On 28/09/2017 17:32, Hannes Walln?fer wrote: > Please approve the backport of JDK-8184893 to jdk8u-dev: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8184893 > Review thread: http://mail.openjdk.java.net/pipermail/nashorn-dev/2017-July/006981.html > JDK 10 webrev: http://cr.openjdk.java.net/~hannesw/8184893/webrev/ > > The patch applies cleanly to 8u-dev after path reshuffling. > > Thanks, > Hannes > From gromero at linux.vnet.ibm.com Thu Sep 28 17:39:59 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Thu, 28 Sep 2017 14:39:59 -0300 Subject: [8u] RFA for backport of 8181810: PPC64: Leverage extrdi for bitfield extract In-Reply-To: <20170928135843.GA3741@vimes> References: <20170928135843.GA3741@vimes> Message-ID: <59CD33EF.6070002@linux.vnet.ibm.com> Hello Rob, On 28-09-2017 10:58, Rob McKenna wrote: > Approved. Please add an appropriate noreg label to the bug. I've add the 'noreg' label accordingly. Could somebody sponsor that change and push it please? Thanks and best regards, Gustavo > > -Rob > > On 27/09/17 04:33, Matthew Brandyberry wrote: >> Hi,// >> // >> Please approve the backport of JDK-8181810 fix to jdk8u. >> >> The JDK10 change applies cleanly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8181810 >> Changeset: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/f025cf2a4a78 >> Review Thread: >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-June/027247.html >> >> Thanks, >> Matt >> > From gromero at linux.vnet.ibm.com Fri Sep 29 15:21:31 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 29 Sep 2017 12:21:31 -0300 Subject: [8u] RFA for backport of 8181810: PPC64: Leverage extrdi for bitfield extract In-Reply-To: <59CD33EF.6070002@linux.vnet.ibm.com> References: <20170928135843.GA3741@vimes> <59CD33EF.6070002@linux.vnet.ibm.com> Message-ID: <59CE64FB.7090103@linux.vnet.ibm.com> Hi, On 28-09-2017 14:39, Gustavo Romero wrote: > Hello Rob, > > On 28-09-2017 10:58, Rob McKenna wrote: >> Approved. Please add an appropriate noreg label to the bug. > > I've add the 'noreg' label accordingly. > > Could somebody sponsor that change and push it please? I forgot to mention that it's a PPC64 only change. Let me know if anything else is missing. Thank you and best regards, Gustavo > > Thanks and best regards, > Gustavo > >> >> -Rob >> >> On 27/09/17 04:33, Matthew Brandyberry wrote: >>> Hi,// >>> // >>> Please approve the backport of JDK-8181810 fix to jdk8u. >>> >>> The JDK10 change applies cleanly. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8181810 >>> Changeset: http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/f025cf2a4a78 >>> Review Thread: >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-June/027247.html >>> >>> Thanks, >>> Matt >>> >> > From gustavo.scalet at eldorado.org.br Fri Sep 29 17:24:29 2017 From: gustavo.scalet at eldorado.org.br (Gustavo Serra Scalet) Date: Fri, 29 Sep 2017 17:24:29 +0000 Subject: [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic In-Reply-To: <8f85be8893c14c6f8e106250a93e84b0@sap.com> References: <20170927152236.GC6441@vimes> <8f85be8893c14c6f8e106250a93e84b0@sap.com> Message-ID: Hi Rob, Could I help with anything else? Do you need more ppc reviewers or something like that or should I just wait for now? Thanks > -----Original Message----- > From: Doerr, Martin [mailto:martin.doerr at sap.com] > Sent: quarta-feira, 27 de setembro de 2017 12:37 > To: Rob McKenna ; Gustavo Serra Scalet > > Cc: jdk8u-dev at openjdk.java.net > Subject: RE: [8u-dev] Request for backport approval: 8145913: PPC64: add > Montgomery multiply intrinsic > > Hi Rob, > > I have reviewed it as the author of the original change, but not as > official backport reviewer (I'm only jdk9+10 reviewer). > > Adding the int to long conversion is needed in 8u and looks correct to > me. > It makes sense to leave the ad file alone. The jdk9 change contains some > additional stuff in it which should not be part of the backport. > > Best regards, > Martin > > > -----Original Message----- > From: Rob McKenna [mailto:rob.mckenna at oracle.com] > Sent: Mittwoch, 27. September 2017 17:23 > To: Gustavo Serra Scalet > Cc: jdk8u-dev at openjdk.java.net; Doerr, Martin > Subject: Re: [8u-dev] Request for backport approval: 8145913: PPC64: add > Montgomery multiply intrinsic > > Hi Gustavo, > > Since the code has changed this requires a codereview for the 8 specific > code. (ideally from someone with ppc knowledge) > > Approved subject to obtaining this review. > > -Rob > > On 27/09/17 02:55, Gustavo Serra Scalet wrote: > > Hi, > > > > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 > > Jdk9 change: > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d > > Jdk9 review thread: > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-Decem > > ber/020534.html > > > > Unfortunately the Jdk9 change doesn't apply cleanly. Below the are > reasons for the adaptations: > > > > 1) This stub call uses integer type on a 64 bits register so a > conversion to long was additionally needed. > > 2) Avoid changing the ppc.ad file as some interfaces were not > existing. > > > > My changes are available on: > > https://gut.github.io/openjdk/webrev/JDK-8145913/webrev/index.html > > > > This change also belongs to 8u102 backport of > > https://bugs.openjdk.java.net/browse/JDK-8150152 > > > > > > Thanks to this change, SpecJVM2008's crypto.rsa benchmark had a > speedup of 3.1 on ppc64le! > > > > Gustavo Serra Scalet > > From rob.mckenna at oracle.com Fri Sep 29 17:38:07 2017 From: rob.mckenna at oracle.com (Rob McKenna) Date: Fri, 29 Sep 2017 18:38:07 +0100 Subject: [8u-dev] Request for backport approval: 8145913: PPC64: add Montgomery multiply intrinsic In-Reply-To: References: <20170927152236.GC6441@vimes> <8f85be8893c14c6f8e106250a93e84b0@sap.com> Message-ID: <20170929173807.GA2854@vimes> Hi Gustavo, I'm happy with Martins review. Thanks, -Rob On 29/09/17 05:24, Gustavo Serra Scalet wrote: > Hi Rob, > > Could I help with anything else? Do you need more ppc reviewers or something like that or should I just wait for now? > > Thanks > > > -----Original Message----- > > From: Doerr, Martin [mailto:martin.doerr at sap.com] > > Sent: quarta-feira, 27 de setembro de 2017 12:37 > > To: Rob McKenna ; Gustavo Serra Scalet > > > > Cc: jdk8u-dev at openjdk.java.net > > Subject: RE: [8u-dev] Request for backport approval: 8145913: PPC64: add > > Montgomery multiply intrinsic > > > > Hi Rob, > > > > I have reviewed it as the author of the original change, but not as > > official backport reviewer (I'm only jdk9+10 reviewer). > > > > Adding the int to long conversion is needed in 8u and looks correct to > > me. > > It makes sense to leave the ad file alone. The jdk9 change contains some > > additional stuff in it which should not be part of the backport. > > > > Best regards, > > Martin > > > > > > -----Original Message----- > > From: Rob McKenna [mailto:rob.mckenna at oracle.com] > > Sent: Mittwoch, 27. September 2017 17:23 > > To: Gustavo Serra Scalet > > Cc: jdk8u-dev at openjdk.java.net; Doerr, Martin > > Subject: Re: [8u-dev] Request for backport approval: 8145913: PPC64: add > > Montgomery multiply intrinsic > > > > Hi Gustavo, > > > > Since the code has changed this requires a codereview for the 8 specific > > code. (ideally from someone with ppc knowledge) > > > > Approved subject to obtaining this review. > > > > -Rob > > > > On 27/09/17 02:55, Gustavo Serra Scalet wrote: > > > Hi, > > > > > > > > > Original Bug: https://bugs.openjdk.java.net/browse/JDK-8145913 > > > Jdk9 change: > > > http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/ce0dacc26f3d > > > Jdk9 review thread: > > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2015-Decem > > > ber/020534.html > > > > > > Unfortunately the Jdk9 change doesn't apply cleanly. Below the are > > reasons for the adaptations: > > > > > > 1) This stub call uses integer type on a 64 bits register so a > > conversion to long was additionally needed. > > > 2) Avoid changing the ppc.ad file as some interfaces were not > > existing. > > > > > > My changes are available on: > > > https://gut.github.io/openjdk/webrev/JDK-8145913/webrev/index.html > > > > > > This change also belongs to 8u102 backport of > > > https://bugs.openjdk.java.net/browse/JDK-8150152 > > > > > > > > > Thanks to this change, SpecJVM2008's crypto.rsa benchmark had a > > speedup of 3.1 on ppc64le! > > > > > > Gustavo Serra Scalet > > > From gromero at linux.vnet.ibm.com Fri Sep 29 21:40:41 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 29 Sep 2017 18:40:41 -0300 Subject: [8u] RFA for backport of 8168318: PPC64: Use cmpldi instead of li/cmpld Message-ID: <59CEBDD9.7090305@linux.vnet.ibm.com> Hi, Could the following backport be approved please? It's a PPC64-only change and applies cleanly. An improvement of ~1% was observed on some Neo4j benchmarks. The original author, Igor, was from Eldorado organization which has already signed the OCA [1] accordingly. Bug : https://bugs.openjdk.java.net/browse/JDK-8168318 Changeset : http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/622d3fe587f2 Review thread : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024771.html Thank you and best regards, Gustavo [1] http://www.oracle.com/technetwork/community/oca-486395.html "Instituto de Pesquisas Eldorado - OpenJDK" From gromero at linux.vnet.ibm.com Fri Sep 29 22:03:49 2017 From: gromero at linux.vnet.ibm.com (Gustavo Romero) Date: Fri, 29 Sep 2017 19:03:49 -0300 Subject: [8u] RFA for backport of 8170328: PPC64: Use andis instead of lis/and Message-ID: <59CEC345.4070705@linux.vnet.ibm.com> Hi, Could the following backport be approved please? It's a PPC64-only change and it applies cleanly. The original author, Igor, was from Eldorado organization which has already signed the OCA [1] accordingly. Bug : https://bugs.openjdk.java.net/browse/JDK-8170328 Changeset : http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3866c59ee901 Review thread : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-November/024997.html Thank you and best regards, Gustavo [1] http://www.oracle.com/technetwork/community/oca-486395.html "Instituto de Pesquisas Eldorado - OpenJDK" From david.buck at oracle.com Fri Sep 29 22:37:54 2017 From: david.buck at oracle.com (David Buck) Date: Fri, 29 Sep 2017 15:37:54 -0700 Subject: [8u] RFA for backport of 8168318: PPC64: Use cmpldi instead of li/cmpld In-Reply-To: <59CEBDD9.7090305@linux.vnet.ibm.com> References: <59CEBDD9.7090305@linux.vnet.ibm.com> Message-ID: <4f1b4d73-38fb-9b32-8d29-aad4a427ecdb@oracle.com> Hi Gustavo! As this would be a backport of an enhancement, you will need to file a separate enhancement backport request first. Please see rule 3 [0] for details. Cheers, -Buck [0] http://openjdk.java.net/projects/jdk8u/groundrules.html On 2017/09/29 14:40, Gustavo Romero wrote: > Hi, > > Could the following backport be approved please? > > It's a PPC64-only change and applies cleanly. > > An improvement of ~1% was observed on some Neo4j benchmarks. > > The original author, Igor, was from Eldorado organization which has already > signed the OCA [1] accordingly. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8168318 > Changeset : http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/622d3fe587f2 > Review thread : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-October/024771.html > > Thank you and best regards, > Gustavo > > [1] http://www.oracle.com/technetwork/community/oca-486395.html "Instituto de Pesquisas Eldorado - OpenJDK" > From david.buck at oracle.com Fri Sep 29 22:38:05 2017 From: david.buck at oracle.com (David Buck) Date: Fri, 29 Sep 2017 15:38:05 -0700 Subject: [8u] RFA for backport of 8170328: PPC64: Use andis instead of lis/and In-Reply-To: <59CEC345.4070705@linux.vnet.ibm.com> References: <59CEC345.4070705@linux.vnet.ibm.com> Message-ID: <7bc7522a-6360-3d1f-96ae-99c93938416d@oracle.com> Hi Gustavo! As this would be a backport of an enhancement, you will need to file a separate enhancement backport request first. Please see rule 3 [0] for details. Cheers, -Buck [0] http://openjdk.java.net/projects/jdk8u/groundrules.html On 2017/09/29 15:03, Gustavo Romero wrote: > Hi, > > Could the following backport be approved please? > > It's a PPC64-only change and it applies cleanly. > > The original author, Igor, was from Eldorado organization which has already > signed the OCA [1] accordingly. > > Bug : https://bugs.openjdk.java.net/browse/JDK-8170328 > Changeset : http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/3866c59ee901 > Review thread : http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2016-November/024997.html > > Thank you and best regards, > Gustavo > > [1] http://www.oracle.com/technetwork/community/oca-486395.html "Instituto de Pesquisas Eldorado - OpenJDK" >