From dms at samersoff.net Mon Sep 3 07:46:41 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 3 Sep 2018 10:46:41 +0300 Subject: [aarch64-port-dev ] AARCH64 support for lworld Message-ID: Hello Everybody, I started implementation of AARCH64 support for lworld. I'm on very early stage so any advices are highly appreciated. Should I file a CR for this task somewhere? What is correct way to do it? -Dmitry -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From tobias.hartmann at oracle.com Mon Sep 3 08:33:58 2018 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 3 Sep 2018 10:33:58 +0200 Subject: [aarch64-port-dev ] AARCH64 support for lworld In-Reply-To: References: Message-ID: <9b2ee9ae-6643-5cf7-00a2-c5a94a03a9f6@oracle.com> Hi Dmitry, we use the "repo-valhalla" affects and fix version for value type related bugs/enhancements, so it would make sense if you create an enhancement in this category and also add the label "lworld". Great that you plan to port this work to Aarch64! Some background information from the JIT side: The current implementation should be platform independent except for the calling convention changes. These are: 1) Pass value types as fields (-XX:+ValueTypePassFieldsAsArgs) 2) Return value types as fields (-XX:+ValueTypeReturnedAsFields) 3) Special entry point for nullable value types (JDK-8209134) 1) and 2) are currently disabled and need to be reworked for value types. I plan to work on this in the near future but you can safely ignore these for now (you will most likely get some build failures due to interface changes though that you need to fix). 3) was added just recently with (JDK-8209134) and should be straight forward to port. Here is a webrev of all the hotspot changes we did: http://cr.openjdk.java.net/~thartmann/valhalla/hs_changes/ Unfortunately, it's very outdated but I will hopefully find some time to update it soon. Best regards, Tobias On 03.09.2018 09:46, Dmitry Samersoff wrote: > Hello Everybody, > > I started implementation of AARCH64 support for lworld. > > I'm on very early stage so any advices are highly appreciated. > > Should I file a CR for this task somewhere? What is correct way to do it? > > -Dmitry > > From dms at samersoff.net Mon Sep 3 15:29:12 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Mon, 3 Sep 2018 18:29:12 +0300 Subject: [aarch64-port-dev ] AARCH64 support for lworld In-Reply-To: <9b2ee9ae-6643-5cf7-00a2-c5a94a03a9f6@oracle.com> References: <9b2ee9ae-6643-5cf7-00a2-c5a94a03a9f6@oracle.com> Message-ID: <598672dc-f614-66db-c4da-ad19da316b8b@samersoff.net> Tobias, Thank you! Created RFE: JDK-8210322 [lworld] Support aarch64 architecture -Dmitry On 03.09.2018 11:33, Tobias Hartmann wrote: > Hi Dmitry, > > we use the "repo-valhalla" affects and fix version for value type related bugs/enhancements, so it > would make sense if you create an enhancement in this category and also add the label "lworld". > > Great that you plan to port this work to Aarch64! > > Some background information from the JIT side: The current implementation should be platform > independent except for the calling convention changes. These are: > 1) Pass value types as fields (-XX:+ValueTypePassFieldsAsArgs) > 2) Return value types as fields (-XX:+ValueTypeReturnedAsFields) > 3) Special entry point for nullable value types (JDK-8209134) > > 1) and 2) are currently disabled and need to be reworked for value types. I plan to work on this in > the near future but you can safely ignore these for now (you will most likely get some build > failures due to interface changes though that you need to fix). 3) was added just recently with > (JDK-8209134) and should be straight forward to port. > > Here is a webrev of all the hotspot changes we did: > http://cr.openjdk.java.net/~thartmann/valhalla/hs_changes/ > > Unfortunately, it's very outdated but I will hopefully find some time to update it soon. > > Best regards, > Tobias > > On 03.09.2018 09:46, Dmitry Samersoff wrote: >> Hello Everybody, >> >> I started implementation of AARCH64 support for lworld. >> >> I'm on very early stage so any advices are highly appreciated. >> >> Should I file a CR for this task somewhere? What is correct way to do it? >> >> -Dmitry >> >> -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From Derek.White at cavium.com Tue Sep 4 17:13:41 2018 From: Derek.White at cavium.com (White, Derek) Date: Tue, 4 Sep 2018 17:13:41 +0000 Subject: [aarch64-port-dev ] FW: Which build platforms are supported for jdk11 and upcoming jdk12? In-Reply-To: <66da090a-fef0-7c35-0611-d1ad70facee3@oracle.com> References: <8f012af95ecf4aff99b332b4034c02c7@sap.com> <66da090a-fef0-7c35-0611-d1ad70facee3@oracle.com> Message-ID: Does anyone (most likely "Any Andrew") want to take a stab at updating this for aarch64? I'm not sure of the supported OS/compiler versions to list, and I definitely can't edit the page. - Derek -----Original Message----- From: build-dev [mailto:build-dev-bounces at openjdk.java.net] On Behalf Of Erik Joelsson Sent: Friday, August 31, 2018 12:17 PM To: Lindenmaier, Goetz ; build-dev (build-dev at openjdk.java.net) ; Magnus Ihse Bursie (magnus.ihse.bursie at oracle.com) Subject: Re: Which build platforms are supported for jdk11 and upcoming jdk12? External Email Hello, On 2018-08-31 00:38, Lindenmaier, Goetz wrote: > Hi, > > https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms > is quite outdated, listing only jdk9. > Is there a different site now listing this information? No, we are just bad at keeping it up to date. Oracle's platforms for 11 are: Linux x64 GCC 7.3, building on OEL7 but still an OEL6 sysroot. Solaris sparcv9, building on Solaris 11.2 with studio 12.4. (planning to go to 12.6 and Solaris 11.3 in JDK 12) Macosx, building on 10.13.5, Xcode 9.4. Windows, building on Server 2012, Visual Studio 2017 15.5.5. I should update the site. /Erik > (I'll also update our information on this site.) > > Because of https://bugs.openjdk.java.net/browse/JDK-8210194 > we think about updating our compilers used for jdk12. > > Best regards, > Goetz. From aph at redhat.com Tue Sep 4 18:33:12 2018 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Sep 2018 19:33:12 +0100 Subject: [aarch64-port-dev ] FW: Which build platforms are supported for jdk11 and upcoming jdk12? In-Reply-To: References: <8f012af95ecf4aff99b332b4034c02c7@sap.com> <66da090a-fef0-7c35-0611-d1ad70facee3@oracle.com> Message-ID: On 09/04/2018 06:13 PM, White, Derek wrote: > Does anyone (most likely "Any Andrew") want to take a stab at updating this for aarch64? All of 'em, really, except bleeding-edge GCC sometimes reveals latent problems in HotSpot. Any version of RHEL's system compiler will be fine: we know that because we test and TCK on RHEL. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From mikael.vidstedt at oracle.com Tue Sep 4 19:36:23 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Sep 2018 12:36:23 -0700 Subject: [aarch64-port-dev ] RFR(S): 8210381: Obsolete EmitSync Message-ID: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ * Background (from bug) The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. Cheers, Mikael From vladimir.kozlov at oracle.com Tue Sep 4 19:53:15 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 4 Sep 2018 12:53:15 -0700 Subject: [aarch64-port-dev ] RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Message-ID: <7eead06f-88da-9482-ada2-9916157652a3@oracle.com> Looks good. What testing you did? Thanks, Vladimir On 9/4/18 12:36 PM, Mikael Vidstedt wrote: > > Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ > > * Background (from bug) > > The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. > > In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Tue Sep 4 20:04:33 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Sep 2018 13:04:33 -0700 Subject: [aarch64-port-dev ] RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <7eead06f-88da-9482-ada2-9916157652a3@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7eead06f-88da-9482-ada2-9916157652a3@oracle.com> Message-ID: <21603636-33D2-4E30-89BB-36B7FD5FE1BD@oracle.com> My tier1 build & test job passed. I?ll also try to spend a few minutes seeing if I can verify that the resulting code actually ends up being the same. Cheers, Mikael > On Sep 4, 2018, at 12:53 PM, Vladimir Kozlov wrote: > > Looks good. > > What testing you did? > > Thanks, > Vladimir > > On 9/4/18 12:36 PM, Mikael Vidstedt wrote: >> Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ >> * Background (from bug) >> The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. >> In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >> Cheers, >> Mikael From daniel.daugherty at oracle.com Tue Sep 4 20:40:10 2018 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 4 Sep 2018 16:40:10 -0400 Subject: [aarch64-port-dev ] RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Message-ID: <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> On 9/4/18 3:36 PM, Mikael Vidstedt wrote: > Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ src/hotspot/cpu/aarch64/aarch64.ad ??? No comments. src/hotspot/cpu/ppc/macroAssembler_ppc.cpp ??? No comments. src/hotspot/cpu/s390/macroAssembler_s390.cpp ??? No comments. src/hotspot/cpu/sparc/macroAssembler_sparc.cpp ??? No comments. src/hotspot/cpu/x86/macroAssembler_x86.cpp ??? No comments. src/hotspot/share/runtime/arguments.cpp ??? No comments. src/hotspot/share/runtime/globals.hpp ??? No comments. General comments: ? - The 'if (EmitSync & 0x01) {' checks are how we disable the ??? use of compiled code for monitors. We use -XX:EmitSync=1 ??? to diagnose things when we wonder if the compiled monitor ??? code is broken. ? - The 'if (EmitSync & 4)' checks are how we disable the use ??? of compiled code for unlocking of monitors; we still use ??? compiled code for locking of monitors. We use -XX:EmitSync=4 ??? to diagnose things when we wonder if the compiled monitor ??? unlock code is broken. ? - BTW, I think s390 is using (EmitSync & 0x01) differently ??? than other platforms. No, I didn't try to figure out exactly ??? how s390 was using that option. This looks like a clean obsoletion of the '-XX:EmitSync=' option so thumbs up from that POV. Use of '-XX:EmitSync=1' for diagnostic purposes is probably limited to a handful of people including me. Use of the '-XX:EmitSync=4' is probably even more rare; I can't remember using it myself. So while I have used the '-XX:EmitSync=' option to debug Java monitor stuff, it has been a long time time... Dan > > * Background (from bug) > > The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. > > In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. > > Cheers, > Mikael > > From mikael.vidstedt at oracle.com Wed Sep 5 01:37:35 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Tue, 4 Sep 2018 18:37:35 -0700 Subject: [aarch64-port-dev ] RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> Message-ID: <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> Dan/Vladimir, thanks for the reviews. FWIW, in addition to the build&test job I also did some manual work to compare the disassembly of the resulting libjvm; the C++ compiler seems to agree with my ?manual? dead code elimination (yay!). Cheers, Mikael > On Sep 4, 2018, at 1:40 PM, Daniel D. Daugherty wrote: > > On 9/4/18 3:36 PM, Mikael Vidstedt wrote: >> Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 >> Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ > > src/hotspot/cpu/aarch64/aarch64.ad > No comments. > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > No comments. > > src/hotspot/cpu/s390/macroAssembler_s390.cpp > No comments. > > src/hotspot/cpu/sparc/macroAssembler_sparc.cpp > No comments. > > src/hotspot/cpu/x86/macroAssembler_x86.cpp > No comments. > > src/hotspot/share/runtime/arguments.cpp > No comments. > > src/hotspot/share/runtime/globals.hpp > No comments. > > > General comments: > > - The 'if (EmitSync & 0x01) {' checks are how we disable the > use of compiled code for monitors. We use -XX:EmitSync=1 > to diagnose things when we wonder if the compiled monitor > code is broken. > - The 'if (EmitSync & 4)' checks are how we disable the use > of compiled code for unlocking of monitors; we still use > compiled code for locking of monitors. We use -XX:EmitSync=4 > to diagnose things when we wonder if the compiled monitor > unlock code is broken. > - BTW, I think s390 is using (EmitSync & 0x01) differently > than other platforms. No, I didn't try to figure out exactly > how s390 was using that option. > > This looks like a clean obsoletion of the '-XX:EmitSync=' > option so thumbs up from that POV. > > Use of '-XX:EmitSync=1' for diagnostic purposes is probably > limited to a handful of people including me. Use of the > '-XX:EmitSync=4' is probably even more rare; I can't remember > using it myself. So while I have used the '-XX:EmitSync=' > option to debug Java monitor stuff, it has been a long time > time... > > Dan > >> >> * Background (from bug) >> >> The experimental EmitSync flag can in theory be used to select which implementation of the synchronization primitives to use. The flag was convenient when the various implementations were compared a long time ago. >> >> In practice the only implementation that is used and tested today is the default one. The EmitSync flag no longer serves the purpose it used to, and is "Unsafe, Unstable" (the documentation of the flag says so explicitly). It should be obsoleted and later removed. >> >> Cheers, >> Mikael >> >> > From shade at redhat.com Wed Sep 5 16:08:04 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 5 Sep 2018 18:08:04 +0200 Subject: [aarch64-port-dev ] RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> Message-ID: <9af8d2ed-966c-e5a1-f859-712d02e9ba26@redhat.com> On 09/04/2018 09:36 PM, Mikael Vidstedt wrote: > > Please review this change which obsoletes the EmitSync flag. In particular, I could use some help from ppc, aarch64, and s390 maintainers to verify that the change actually builds and (still) works. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > Webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/webrev/ Looks okay and safe to me. FWIW: - Cross-build x86_64 -> aarch64 builds fastdebug fine. Runs HelloWorld fine. - Cross-build x86_64 -> armhf builds fastdebug fine. Runs HelloWorld fine. - Zero x86_64 builds fastdebug fine. - Minimal x86_64 builds fastdebug fine. -Aleksey From aph at redhat.com Thu Sep 6 13:18:22 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 6 Sep 2018 14:18:22 +0100 Subject: [aarch64-port-dev ] 8210461: AArch64: Math.cos intrinsic gives incorrect results Message-ID: <9a7b2740-fb91-ffde-fa91-6451a999d848@redhat.com> Please confirm this bug: Range reduction for trig functions on AArch64 is broken. The smallest broken case is Math.cos(1647100) which should return 0.7833030468809974 but returns -0.2745634094819721. The problem is that __kernel_rem_pio2 is supposed to reduce its argument to the range [-pi/4, pi/4], pi/4 ~ 0.785398164 but it does not: it returns 1.8489319595787654, which is outside the range of the polynomial cosine approximation. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Thu Sep 6 13:21:08 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 6 Sep 2018 16:21:08 +0300 Subject: [aarch64-port-dev ] 8210461: AArch64: Math.cos intrinsic gives incorrect results In-Reply-To: <9a7b2740-fb91-ffde-fa91-6451a999d848@redhat.com> References: <9a7b2740-fb91-ffde-fa91-6451a999d848@redhat.com> Message-ID: Looking into it On 06/09/18 16:18, Andrew Haley wrote: > Please confirm this bug: > > Range reduction for trig functions on AArch64 is broken. The smallest > broken case is > > Math.cos(1647100) > > which should return 0.7833030468809974 but returns > -0.2745634094819721. > > The problem is that __kernel_rem_pio2 is supposed to reduce its > argument to the range [-pi/4, pi/4], pi/4 ~ 0.785398164 but it does > not: it returns 1.8489319595787654, which is outside the range of the > polynomial cosine approximation. > From mohbeyinfo at gmail.com Thu Sep 6 20:23:19 2018 From: mohbeyinfo at gmail.com (Mohammed Bey Ahmed Khernache) Date: Thu, 6 Sep 2018 22:23:19 +0200 Subject: [aarch64-port-dev ] How to install jdk on aarch64 arm architecture Message-ID: Hello, I am looking forward to setting up *jdk *on my board (Snapdragon 810) which is equipped by Android OS (version 5.0.2). The architecture is: aarch64 Any little help is welcome. Thank you in advance. Best regards From mikael.vidstedt at oracle.com Fri Sep 7 01:12:42 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 6 Sep 2018 18:12:42 -0700 Subject: [aarch64-port-dev ] RFR(S): 8210381: Obsolete EmitSync In-Reply-To: References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> Message-ID: <7BCE4F55-4A3D-4BA4-B3B3-4ADA1E1233FD@oracle.com> Thanks a lot for all the reviews and for the help verifying the change across the platforms! Cheers, Mikael > On Sep 5, 2018, at 11:56 PM, Baesken, Matthias wrote: > > Hello, small update from my side - builds were fine with the patch included on our ppc64(le) / s390x platforms . > I did not notice any test failures related to the patch . > > > Best regards, Matthias > > >> -----Original Message----- >> From: Baesken, Matthias >> Sent: Mittwoch, 5. September 2018 13:09 >> To: 'Mikael Vidstedt' ; >> daniel.daugherty at oracle.com; Doerr, Martin >> Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; >> HotSpot Open Source Developers ; >> aarch64-port-dev at openjdk.java.net >> Subject: RE: RFR(S): 8210381: Obsolete EmitSync >> >> Hello , I had a short look at the ppc / s390x changes , looks OK . >> To be on the safe side I put it into our build/test queue, so we see results >> for ppc64(le) / s390x as well tomorrow . >> >> Best regards, Matthias >> >>> -----Original Message----- >>> From: ppc-aix-port-dev >> On >>> Behalf Of Mikael Vidstedt >>> Sent: Mittwoch, 5. September 2018 03:38 >>> To: daniel.daugherty at oracle.com >>> Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port- >> dev at openjdk.java.net; >>> HotSpot Open Source Developers ; >>> aarch64-port-dev at openjdk.java.net >>> Subject: Re: RFR(S): 8210381: Obsolete EmitSync >>> >>> >>> Dan/Vladimir, thanks for the reviews. >>> >>> FWIW, in addition to the build&test job I also did some manual work to >>> compare the disassembly of the resulting libjvm; the C++ compiler seems >> to >>> agree with my ?manual? dead code elimination (yay!). >>> >>> Cheers, >>> Mikael > From aph at redhat.com Fri Sep 7 08:27:54 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Sep 2018 09:27:54 +0100 Subject: [aarch64-port-dev ] How to install jdk on aarch64 arm architecture In-Reply-To: References: Message-ID: On 09/06/2018 09:23 PM, Mohammed Bey Ahmed Khernache wrote: > I am looking forward to setting up *jdk *on my board (Snapdragon 810) which > is equipped by Android OS (version 5.0.2). The architecture is: aarch64 I'm sorry, we've never ported OpenJDK to Android OS. I don't imagine it would be terribly difficult, but I've never done anything with Android OS. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Sep 7 12:58:59 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 7 Sep 2018 13:58:59 +0100 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> Message-ID: Hi Dmitrij On 22/08/18 11:04, Andrew Dinn wrote: > Thank you for the revised webrev and new test results. I am now working > through them. I will post comments as soon as I have given the new code > a full read and assessed the new results. I am afraid that may take a > day or two, for which delay advance apologies. This review has taken a great deal longer than expected. I am sorry but that is because the documentation for the code you have submitted is still seriously inadequate and I have had to put a lot of work into revising it before I can fully review the code. I am still finishing off that last task but I wanted to start providing you with some feedback and also to enlist your help in checking that my revisions are correct. I plan to provide feedback in 3 stages to match the 3 steps in the review that I am doing as follows: 1) Correct the original 'algorithm' you started from 2) Correct the 'modified algorithm' that is meant to describe the behaviour of your code 3) Propose any necessary corrections/improvements to the generated code So, let's start with step 1. The 'original' algorithm located in file macroAssembler_aarch64_pow.cpp is really just a fragment of C code with a few missing elements (e.g. the origin of values P1, P2, ... is not explained, hugeX, tiny are not defined). Although this code as the virtue that it is known to be correct (or at least has been verified by long use and the eyes of experts in numerical computation) it still fails to provide important information about what the 'algorithm' is supposed to do. That information is critical for anyone coming to it fresh to be able understand what is happening. The first omission is several pieces of background mathematics that are neither explained in the code nor referenced. The mathematics includes the formulae on which the algorithm is based and the numerical approximation to these formulae that is employed to define the algorithm. This is needed to explain /how/ and /why/ a) the two different computations of log2(x) and b) the computation of exp(x) are performed as they are and to justify that the results are valid. The second omission is detailed descriptions of what most of the more complex individual steps in the algorithm do. Many of the logic, floating point and branching operations which compute intermediate results are extremely opaque. This is particularly so for the steps which manipulate bit patterns in the long representation of the fp values being used. However, some of the straight fp arithmetic is also highly problematic. The other thing I think needs to be made clearer is the relationship between the various special case return points in the code and the special case rules they relate to. This is not so critical for the original algorithm because the C code at least has a regular and standardised control flow. However, labelling the exit paths is still useful here and will be much more useful if used both here and in the modified algorithm (and we'll come to that later). I have rewritten the algorithm to achieve what I think is needed to patch these omissions. The redraft of this part of the code is available here: http://cr.openjdk.java.net/~adinn/8189107/original_algorithm.txt I assume you are familiar with the relevant mathematics and how it has been used to derive the algorithm. If so then I would like you to review this rewrite and ensure that there are nor mathematical errors in it. I would also like you to check that the explanatory comments for of the individual steps in the algorithm do not contain any errors. If you are not familiar with the mathematics then please let me know. I need to know whether this has been reviewed bu someone competent to do so. n.b. one little detail you might easily miss. I removed lg2, lg2_h and lg2_l from the first table of constants as neither log(x) algorithm needs them (it relies on ivln2). I renamed the entries in the second table from LG2, etc to /ln2/, etc and change the name accordingly at point of use. The computation of exp(x) actually does need ln2. One of the code changes is to remove these redundant entries from your table pow_coeff1. Ok, as for the next 2 steps will post a follow-up to deal with them once I have completed my review. That will include a heavily revised version of your 'modified algorithm' (which is still in progress) plus suggestions for changes to the code that I have found along the way. Just as a preliminary I'll summarize what is wrong below. Note that I have not yet found any errors in how the generated code implements the mathematics but I am still not happy with it because it is extremely unclear. Correcting the 'modified algorithm' is a necessary, critical step to improvimg the clarity of the code. So, in overview, what is wrong with your 'modified algorithm'. Well, the thing that is immediately obvious is that it is /not/ actually the algorithm you have employed. It is simply a mangled version of the C code you started from that bears only a tenuous relation to the code structure it is supposed to summarize. Now, I'm happy for you to use C to model the generated code if possible and, in fact, am in the process of writing a proper algorithm that looks as much like C code as possible /but/ also actually describes what your generated code does. The problem is that what you have written is not only /not/ C it is also i) incoherent, ii) retains elements from the original code that don't exist at all in the generated code and iii) omits important elements of the generated code. So, firstly, let's deal with the problem as it relates to control flow. Your 'modified algorithm' includes various tags mentioning the word 'label' suggesting that some transfer of control is to be effected. However, these are tacked onto statement blocks connected via 'if (cond)' tests or 'else' keywords that are meant to imply some alternative control flow. Essentially, your generated code relies on gotos which do not fit a standard if/else flow model and you have tried to bodge some sort of goto model on top of the original valid, gotoless C control flow with no clear definition of how that is meant to work. Honestly, if your generated code uses a goto control flow then your C algorithm is going to have to do the same in order to clearly summarize what the code actually does. The second major problem is one I pointed out in my earlier note, i.e. that the data values described in the 'modified algorithm' do not correctly match the ones operated on in your generated code. Your algorithm lists many redundant values used in the original algorithm (e.g. ix, iy, ax, yisint) even though your code doesn't ever explicitly construct most of those values (n.b. this but not just limited to the 32 bit half-word quantities). Instead the code frequently pulls the relevant value, as needed, out of other data that it does construct and holds in registers -- sometimes across control branches. At other times it performs an equivalent operation on a different, related data value. Your response to my request was to add comments which labelled some of these on-the-fly created values or alternative values with the original names but that ignores the fact that the names and the values referenced in the comments do not actually match. Contrariwise, a lot of the values the code does actually operate on are not mentioned in the algorithm. Indeed, it is worse than that because they are not coherently identified even in the generated code. Data items stored in registers are referred to using the utterly redundant symbolic aliases tmp0, tmp2, etc for registers r0, r1 etc. What is worse the same meaningless symbolic names get reused for completely different data items. For example, at one point tmp2 identifies the exponent of y stored in r2 and later it identifies the absolute value of y also stored in r2, overwriting the exponent. Your algorithm really ought to mention values like exp_y or ay (or even |y|) for these cases and the code should correspondingly define exp_y and ay as an alias for register r2. These meaningful names should then be used when loading the constructed value into a register and at every subsequent point of use where that constructed value is valid. This is not all that is wrong with the 'modified algorithm' but it is enough to make it not just useless but worse than useless. What you have written provides a hand-wave towards what the code does that fails to summarize it with any accuracy or clarity and equally fails to clarify the difference between it and the C code you started from. That only makes the whole picture less clear not more so. As I said, I will provide a better version of the 'modified algorithm' in a follow-up and then discuss possible code changes. Please review the linked file above while I prepare that. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitrij.pochepko at bell-sw.com Fri Sep 7 13:40:23 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 7 Sep 2018 16:40:23 +0300 Subject: [aarch64-port-dev ] RFR(S): 8210461 - AArch64: Math.cos intrinsic gives incorrect results Message-ID: Hi, please review small fix for 8210461 - AArch64: Math.cos intrinsic gives incorrect results Large argument reduction code has a bug in one of code branches. C-code: of affected place: iq[jz] = (int)(z-two24B*fw); with bug it was calculated as iq[jz] = (int)(z+two24B*fw);? // by fmadd instruction Fix is to change it into fmsub instruction for correct calculation. I also re-parsed most of code in search of same errors. Seems like no other issues found. This bug wasn't caught by jtreg and jck tests, so I added separate small test for such case. webrev: http://cr.openjdk.java.net/~dpochepk/8210461/webrev.01/ CR: https://bugs.openjdk.java.net/browse/JDK-8210461 Testing: I tested this patch via new and old tests. All passed. I also ran this new test on x86. This patch should be pushed into jdk12 and backported into jdk11. Thanks, Dmitrij From aph at redhat.com Fri Sep 7 13:52:06 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Sep 2018 14:52:06 +0100 Subject: [aarch64-port-dev ] RFR(S): 8210461 - AArch64: Math.cos intrinsic gives incorrect results In-Reply-To: References: Message-ID: On 09/07/2018 02:40 PM, Dmitrij Pochepko wrote: > C-code: of affected place: > > iq[jz] = (int)(z-two24B*fw); > > with bug it was calculated as iq[jz] = (int)(z+two24B*fw);? // by fmadd > instruction > > Fix is to change it into fmsub instruction for correct calculation. Am I right to think that this code branch has never been tested? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Fri Sep 7 14:03:18 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 7 Sep 2018 17:03:18 +0300 Subject: [aarch64-port-dev ] RFR(S): 8210461 - AArch64: Math.cos intrinsic gives incorrect results In-Reply-To: References: Message-ID: <4ef01df1-0c2f-78ca-f2e5-f10b78247140@bell-sw.com> I remember debugging this branch while running JCK tests. Haven't checked precisely, but probably fw was? 0 on those cases, so, z - two24B*fw and z + tmp24B*fw. It would explain such behavior. On 07/09/18 16:52, Andrew Haley wrote: > On 09/07/2018 02:40 PM, Dmitrij Pochepko wrote: >> C-code: of affected place: >> >> iq[jz] = (int)(z-two24B*fw); >> >> with bug it was calculated as iq[jz] = (int)(z+two24B*fw);? // by fmadd >> instruction >> >> Fix is to change it into fmsub instruction for correct calculation. > Am I right to think that this code branch has never been tested? > From aph at redhat.com Fri Sep 7 15:26:36 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 7 Sep 2018 16:26:36 +0100 Subject: [aarch64-port-dev ] RFR(S): 8210461 - AArch64: Math.cos intrinsic gives incorrect results In-Reply-To: <4ef01df1-0c2f-78ca-f2e5-f10b78247140@bell-sw.com> References: <4ef01df1-0c2f-78ca-f2e5-f10b78247140@bell-sw.com> Message-ID: <5ebc307e-e1ce-06e8-d42c-36206685c679@redhat.com> On 09/07/2018 03:03 PM, Dmitrij Pochepko wrote: > I remember debugging this branch while running JCK tests. > > Haven't checked precisely, but probably fw was 0 on those cases, so, z > - two24B*fw and z + tmp24B*fw. It would explain such behavior. I see. I wrote some simple code to stress test argument reduction, and it immediately failed. The range reduction code is so horribly complicated that the *first thing* to have done should have been to stress test it, and evidently that was not done. The code, as it stands, is so complicated and tangled that it is almost impossible for anybody to debug and analyse. Its documentation is inadequate, for the same reasons that Andrew Dinn explained with respect to pow(). I can't have any confidence that there aren't more lurking bugs, and this method is too important to risk breakage. It needs some major reworking. In hindsight, I should not have accepted it. It's too late to get this fixed in the JDK 11 release, so it's going to go out broken on AArch64. I'll disable the intrinsic in JDK devel and tell the distro packagers to do patch their packages. Then we can rewrite this intrinsic with a view of fixing its maintainability and documentation, and perhaps including it in JDK 12. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Fri Sep 7 16:42:41 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 7 Sep 2018 19:42:41 +0300 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> Message-ID: Hi Andrew, Thank you again for looking into it in such details. It will take me some time to review your draft with comments related to original code. Looking forward to work on improving the code and algorithm description after that. Small note though: since you're adding documentation to original code, it probably would make sense to update it in original location as well at src/hotspot/share/runtime/sharedRuntimeTrans.cpp Thanks, Dmitrij On 07/09/18 15:58, Andrew Dinn wrote: > Hi Dmitrij > > On 22/08/18 11:04, Andrew Dinn wrote: >> Thank you for the revised webrev and new test results. I am now working >> through them. I will post comments as soon as I have given the new code >> a full read and assessed the new results. I am afraid that may take a >> day or two, for which delay advance apologies. > This review has taken a great deal longer than expected. I am sorry but > that is because the documentation for the code you have submitted is > still seriously inadequate and I have had to put a lot of work into > revising it before I can fully review the code. > > I am still finishing off that last task but I wanted to start providing > you with some feedback and also to enlist your help in checking that my > revisions are correct. I plan to provide feedback in 3 stages to match > the 3 steps in the review that I am doing as follows: > > 1) Correct the original 'algorithm' you started from > > 2) Correct the 'modified algorithm' that is meant to describe the > behaviour of your code > > 3) Propose any necessary corrections/improvements to the generated code > > So, let's start with step 1. > > The 'original' algorithm located in file macroAssembler_aarch64_pow.cpp > is really just a fragment of C code with a few missing elements (e.g. > the origin of values P1, P2, ... is not explained, hugeX, tiny are not > defined). Although this code as the virtue that it is known to be > correct (or at least has been verified by long use and the eyes of > experts in numerical computation) it still fails to provide important > information about what the 'algorithm' is supposed to do. That > information is critical for anyone coming to it fresh to be able > understand what is happening. > > The first omission is several pieces of background mathematics that are > neither explained in the code nor referenced. The mathematics includes > the formulae on which the algorithm is based and the numerical > approximation to these formulae that is employed to define the > algorithm. This is needed to explain /how/ and /why/ a) the two > different computations of log2(x) and b) the computation of exp(x) are > performed as they are and to justify that the results are valid. > > The second omission is detailed descriptions of what most of the more > complex individual steps in the algorithm do. Many of the logic, > floating point and branching operations which compute intermediate > results are extremely opaque. This is particularly so for the steps > which manipulate bit patterns in the long representation of the fp > values being used. However, some of the straight fp arithmetic is also > highly problematic. > > The other thing I think needs to be made clearer is the relationship > between the various special case return points in the code and the > special case rules they relate to. This is not so critical for the > original algorithm because the C code at least has a regular and > standardised control flow. However, labelling the exit paths is still > useful here and will be much more useful if used both here and in the > modified algorithm (and we'll come to that later). > > I have rewritten the algorithm to achieve what I think is needed to > patch these omissions. The redraft of this part of the code is available > here: > > http://cr.openjdk.java.net/~adinn/8189107/original_algorithm.txt > > I assume you are familiar with the relevant mathematics and how it has > been used to derive the algorithm. If so then I would like you to review > this rewrite and ensure that there are nor mathematical errors in it. I > would also like you to check that the explanatory comments for of the > individual steps in the algorithm do not contain any errors. > > If you are not familiar with the mathematics then please let me know. I > need to know whether this has been reviewed bu someone competent to do so. > > n.b. one little detail you might easily miss. I removed lg2, lg2_h and > lg2_l from the first table of constants as neither log(x) algorithm > needs them (it relies on ivln2). I renamed the entries in the second > table from LG2, etc to /ln2/, etc and change the name accordingly at > point of use. The computation of exp(x) actually does need ln2. One of > the code changes is to remove these redundant entries from your table > pow_coeff1. > > Ok, as for the next 2 steps will post a follow-up to deal with them once > I have completed my review. That will include a heavily revised version > of your 'modified algorithm' (which is still in progress) plus > suggestions for changes to the code that I have found along the way. > Just as a preliminary I'll summarize what is wrong below. > > Note that I have not yet found any errors in how the generated code > implements the mathematics but I am still not happy with it because it > is extremely unclear. Correcting the 'modified algorithm' is a > necessary, critical step to improvimg the clarity of the code. > > So, in overview, what is wrong with your 'modified algorithm'. Well, the > thing that is immediately obvious is that it is /not/ actually the > algorithm you have employed. It is simply a mangled version of the C > code you started from that bears only a tenuous relation to the code > structure it is supposed to summarize. Now, I'm happy for you to use C > to model the generated code if possible and, in fact, am in the process > of writing a proper algorithm that looks as much like C code as possible > /but/ also actually describes what your generated code does. The problem > is that what you have written is not only /not/ C it is also i) > incoherent, ii) retains elements from the original code that don't exist > at all in the generated code and iii) omits important elements of the > generated code. > > So, firstly, let's deal with the problem as it relates to control flow. > Your 'modified algorithm' includes various tags mentioning the word > 'label' suggesting that some transfer of control is to be effected. > However, these are tacked onto statement blocks connected via 'if > (cond)' tests or 'else' keywords that are meant to imply some > alternative control flow. Essentially, your generated code relies on > gotos which do not fit a standard if/else flow model and you have tried > to bodge some sort of goto model on top of the original valid, gotoless > C control flow with no clear definition of how that is meant to work. > Honestly, if your generated code uses a goto control flow then your C > algorithm is going to have to do the same in order to clearly summarize > what the code actually does. > > The second major problem is one I pointed out in my earlier note, i.e. > that the data values described in the 'modified algorithm' do not > correctly match the ones operated on in your generated code. Your > algorithm lists many redundant values used in the original algorithm > (e.g. ix, iy, ax, yisint) even though your code doesn't ever explicitly > construct most of those values (n.b. this but not just limited to the 32 > bit half-word quantities). Instead the code frequently pulls the > relevant value, as needed, out of other data that it does construct and > holds in registers -- sometimes across control branches. At other times > it performs an equivalent operation on a different, related data value. > Your response to my request was to add comments which labelled some of > these on-the-fly created values or alternative values with the original > names but that ignores the fact that the names and the values referenced > in the comments do not actually match. > > Contrariwise, a lot of the values the code does actually operate on are > not mentioned in the algorithm. Indeed, it is worse than that because > they are not coherently identified even in the generated code. Data > items stored in registers are referred to using the utterly redundant > symbolic aliases tmp0, tmp2, etc for registers r0, r1 etc. What is worse > the same meaningless symbolic names get reused for completely different > data items. > > For example, at one point tmp2 identifies the exponent of y stored in r2 > and later it identifies the absolute value of y also stored in r2, > overwriting the exponent. Your algorithm really ought to mention values > like exp_y or ay (or even |y|) for these cases and the code should > correspondingly define exp_y and ay as an alias for register r2. These > meaningful names should then be used when loading the constructed value > into a register and at every subsequent point of use where that > constructed value is valid. > > This is not all that is wrong with the 'modified algorithm' but it is > enough to make it not just useless but worse than useless. What you have > written provides a hand-wave towards what the code does that fails to > summarize it with any accuracy or clarity and equally fails to clarify > the difference between it and the C code you started from. That only > makes the whole picture less clear not more so. > > As I said, I will provide a better version of the 'modified algorithm' > in a follow-up and then discuss possible code changes. Please review the > linked file above while I prepare that. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From dmitrij.pochepko at bell-sw.com Fri Sep 7 16:45:36 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Fri, 7 Sep 2018 19:45:36 +0300 Subject: [aarch64-port-dev ] RFR(S): 8210461 - AArch64: Math.cos intrinsic gives incorrect results In-Reply-To: <5ebc307e-e1ce-06e8-d42c-36206685c679@redhat.com> References: <4ef01df1-0c2f-78ca-f2e5-f10b78247140@bell-sw.com> <5ebc307e-e1ce-06e8-d42c-36206685c679@redhat.com> Message-ID: Hi Andrew, Ok. I'm really sorry to have introduced such a bug and I agree that the best strategy is to disable the intrinsic temporarily for sin and cos. I aim to work with Andrew Dinn on pow to calibrate and enhance documentation and algorithm there first. Then I'll get back to sin/cos and revise it in a same manner. Meanwhile, do we have to abandon this particular patch? It still resolve this particular problem and it would be a waste to re-debug and fix this problem later. Thanks, Dmitrij On 07/09/18 18:26, Andrew Haley wrote: > On 09/07/2018 03:03 PM, Dmitrij Pochepko wrote: >> I remember debugging this branch while running JCK tests. >> >> Haven't checked precisely, but probably fw was 0 on those cases, so, z >> - two24B*fw and z + tmp24B*fw. It would explain such behavior. > I see. > > I wrote some simple code to stress test argument reduction, and it > immediately failed. The range reduction code is so horribly > complicated that the *first thing* to have done should have been to > stress test it, and evidently that was not done. > > The code, as it stands, is so complicated and tangled that it is > almost impossible for anybody to debug and analyse. Its documentation > is inadequate, for the same reasons that Andrew Dinn explained with > respect to pow(). I can't have any confidence that there aren't more > lurking bugs, and this method is too important to risk breakage. It > needs some major reworking. In hindsight, I should not have accepted > it. > > It's too late to get this fixed in the JDK 11 release, so it's going > to go out broken on AArch64. I'll disable the intrinsic in JDK devel > and tell the distro packagers to do patch their packages. Then we can > rewrite this intrinsic with a view of fixing its maintainability and > documentation, and perhaps including it in JDK 12. > From aph at redhat.com Sat Sep 8 09:14:07 2018 From: aph at redhat.com (Andrew Haley) Date: Sat, 8 Sep 2018 10:14:07 +0100 Subject: [aarch64-port-dev ] RFR(S): 8210461 - AArch64: Math.cos intrinsic gives incorrect results In-Reply-To: References: <4ef01df1-0c2f-78ca-f2e5-f10b78247140@bell-sw.com> <5ebc307e-e1ce-06e8-d42c-36206685c679@redhat.com> Message-ID: <7e4549e8-232e-c329-b92e-a368f3b7b7ba@redhat.com> On 09/07/2018 05:45 PM, Dmitrij Pochepko wrote: > Meanwhile, do we have to abandon this particular patch? It still resolve > this particular problem and it would be a waste to re-debug and fix this > problem later. No, we don't have to abandon this patch. Please push it to JDK head, thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Sun Sep 9 08:08:12 2018 From: adinn at redhat.com (Andrew Dinn) Date: Sun, 9 Sep 2018 09:08:12 +0100 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> Message-ID: Hi Dmitrij On 07/09/18 17:42, Dmitrij Pochepko wrote: > Thank you again for looking into it in such details. It will take me > some time to review your draft with comments related to original code. > Looking forward to work on improving the code and algorithm description > after that. You are welcome. However, thanks are not needed. This is simply what I am required to do as a reviewer. > Small note though: since you're adding documentation to original code, > it probably would make sense to update it in original location as well > at src/hotspot/share/runtime/sharedRuntimeTrans.cpp I agree that it would be better if comments in that shared code were also updated. However, I recommend we pursue that task as a follow-up once we have fixed the intrinsic. Also, it's important to note that the omission in the above file are, to a degree, mitigated by the /slightly/ more complete documentation in file src/java.base/share/classes/java/lang/FdLibm.java. Comments in the methods for computing log(x) and exp(x) in the latter file include some of same details of the maths/algorithms that I described (I only found these comments after deriving the relevant maths myself :-). So, we might consider upgrading the comments in the Java source and adding a cross-reference to that file from the C source. The code itself is almost identical so one commented version should work for both. I'd still like my comments to remain in your generator code. This is the most complex implementation version and has the greatest divergence from the original. So, it will be the focus of any nasty bugs that arise. Having an explanation of the maths and algorithm right there in the generator source is going to ensure whoever has to fix any such bug is best prepared to do so. Also, it will pin down the version of the shared code from which the generator was derived. The shared code ought not to be updated without changing the generator code but keeping the C template in with the generator is safer. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From rkennke at redhat.com Mon Sep 10 15:11:27 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 10 Sep 2018 17:11:27 +0200 Subject: [aarch64-port-dev ] Field too big for insn issue with Shenandoah Message-ID: <5d48fccf-1b34-a704-24cb-cd67553bb121@redhat.com> Hello AArch64-devs, In current Shenandoah repo I am looking at an issue that seems to be an upstream aarch64 bug. I hope you can help me a little bit. When building with Shenandoah and trying to run anything with C1, I am getting this: # Internal Error (/home/rkennke/src/shenandoah-jdk/src/hotspot/cpu/aarch64/assembler_aarch64.hpp:251), pid=20187, tid=20319 # guarantee(chk == -1 || chk == 0) failed: Field too big for insn # The relevant stacktrace is: https://paste.fedoraproject.org/paste/83wUZafXsQT2~646LSM6TA The failure happens because: 1. The float constant doesn't qualify for immediate operand 2. the assembler writes the constant into code, and emits an InternalAddress to it 3. That address is too far away from the PC, generating too large offset (393108) and thus trips the assert above. This only happens when running with Shenandoah. I suspect that the extra barriers that we emit with Shenandoah make the code too big and the PC too far away from the constants, but I am not sure. Does anybody have an idea why that happens and how to possibly fix it? You can try it by checking out: http://hg.openjdk.java.net/shenandoah/jdk/ Build fastdebug and run: CONF=fastdebug LOG=info LANG=C make run-test TEST=tier1_gc_shenandoah Thanks, Roman From aph at redhat.com Mon Sep 10 18:03:39 2018 From: aph at redhat.com (Andrew Haley) Date: Mon, 10 Sep 2018 19:03:39 +0100 Subject: [aarch64-port-dev ] Field too big for insn issue with Shenandoah In-Reply-To: <5d48fccf-1b34-a704-24cb-cd67553bb121@redhat.com> References: <5d48fccf-1b34-a704-24cb-cd67553bb121@redhat.com> Message-ID: <50bfb4ee-bdf4-3a09-0fd5-59f0533b7503@redhat.com> On 09/10/2018 04:11 PM, Roman Kennke wrote: > This only happens when running with Shenandoah. I suspect that the extra > barriers that we emit with Shenandoah make the code too big and the PC > too far away from the constants, but I am not sure. Nice catch! I always knew that this was a theoretical possibility, but I never could find a way to trigger it. > Does anybody have an idea why that happens and how to possibly fix it? I'll have a look. It's going to be very awkward if loads can't reach the constant pool. The load offset is 19 bits, shifted by 2, so that's +/- a megabyte. I don't really believe that any method will generate a megabyte of code, so I suspect that there may be some other reason. Perhaps enabling debug mode just generates too much checking code. Which test was running? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Mon Sep 10 18:11:40 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 10 Sep 2018 20:11:40 +0200 Subject: [aarch64-port-dev ] Field too big for insn issue with Shenandoah In-Reply-To: <50bfb4ee-bdf4-3a09-0fd5-59f0533b7503@redhat.com> References: <5d48fccf-1b34-a704-24cb-cd67553bb121@redhat.com> <50bfb4ee-bdf4-3a09-0fd5-59f0533b7503@redhat.com> Message-ID: <2c69337a-835c-933e-c615-ed694b7c3443@redhat.com> Am 10.09.2018 um 20:03 schrieb Andrew Haley: > On 09/10/2018 04:11 PM, Roman Kennke wrote: >> This only happens when running with Shenandoah. I suspect that the extra >> barriers that we emit with Shenandoah make the code too big and the PC >> too far away from the constants, but I am not sure. > > Nice catch! I always knew that this was a theoretical possibility, but > I never could find a way to trigger it. > >> Does anybody have an idea why that happens and how to possibly fix it? > > I'll have a look. It's going to be very awkward if loads can't reach the > constant pool. The load offset is 19 bits, shifted by 2, so that's +/- a > megabyte. I don't really believe that any method will generate a megabyte > of code, so I suspect that there may be some other reason. Perhaps enabling > debug mode just generates too much checking code. > > Which test was running? > It was happening with basically any program running under fastdebug + C1 + Shenandoah. It occured because we tripled NMethodSizeLimit when running with Shenandoah to make space for extra code for barriers. And we 'fixed' it by leaving that flag alone: http://hg.openjdk.java.net/shenandoah/jdk/rev/5d035e4eb822 You might want to crank up that flag to trigger the bug (if it is one) in upstream (no Shenandoah). A proper fix might be to enforce an upper bound for that flag that ensures offsets from code can always reach the constants. Thanks, Roman From adinn at redhat.com Tue Sep 11 09:06:35 2018 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 11 Sep 2018 10:06:35 +0100 Subject: [aarch64-port-dev ] RFR: 8210578: AArch64: Invalid encoding for fmlsvs instruction Message-ID: <80d98039-c412-b638-c764-0794da1ba26f@redhat.com> Can I please have a review for this trivial patch to correct the encoding for fmlsvs. JIRA Issue: https://bugs.openjdk.java.net/browse/JDK-8210578 Patch: diff -r bbc7157ad9c5 src/hotspot/cpu/aarch64/assembler_aarch64.hpp --- a/src/hotspot/cpu/aarch64/assembler_aarch64.hpp Tue Sep 11 09:14:36 2018 +0200 +++ b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp Tue Sep 11 09:42:41 2018 +0100 @@ -2356,7 +2356,7 @@ // FMLA/FMLS - Vector - Scalar INSN(fmlavs, 0, 0b0001); - INSN(fmlsvs, 0, 0b0001); + INSN(fmlsvs, 0, 0b0101); // FMULX - Vector - Scalar INSN(fmulxvs, 1, 0b1001); The corrected bit identifies the sub_op which distinguishes a fused add multiply vector by scalar (fmlavs) and add from a fused multiply vector by scalar and subtract (fmlsvs). Testing: It appears that this instruction has never been exercised (by contrast, fmlavs has -- by the power intrinsic I am currently reviewing). All I have done to check this patch is ensure I can rebuild the JVM (there isn't really any opportunity to test it until it is needed in an intrinsic). Can I assume this is trivial enough to be pushed without running a submit job? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Pengfei.Li at arm.com Tue Sep 11 10:41:02 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 11 Sep 2018 10:41:02 +0000 Subject: [aarch64-port-dev ] AArch64: Why should we use rscratch1 instead of the temp register passed in? Message-ID: Hi, I'm currently working on adding the missing div/rem by power-of-2 optimization in C1 AArch64 backend. JBS: https://bugs.openjdk.java.net/browse/JDK-8210413 I see 5 years ago, Roman added a TODO comment [1] at http://hg.openjdk.java.net/jdk/jdk/file/bbc7157ad9c5/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp#l1035 saying > TODO: For some reason, using the Rscratch that gets passed in is > not possible because the register allocator does not see the tmp reg > as used, and assigns it the same register as Rdividend. We use rscratch1 > instead. So I was wondering why register allocator also assigns the temp register to the dividend. Is there any special handling for LIR_Op3 in C1 linear scan? I appreciate your help. -- Thanks, Pengfei [1] http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/3aafc60e8f34#l2.7 From rkennke at redhat.com Tue Sep 11 10:52:13 2018 From: rkennke at redhat.com (Roman Kennke) Date: Tue, 11 Sep 2018 12:52:13 +0200 Subject: [aarch64-port-dev ] AArch64: Why should we use rscratch1 instead of the temp register passed in? In-Reply-To: References: Message-ID: <30796959-052a-fb3d-033e-7cd6ebc3d0d5@redhat.com> > Hi, > > I'm currently working on adding the missing div/rem by power-of-2 optimization in C1 AArch64 backend. JBS: https://bugs.openjdk.java.net/browse/JDK-8210413 > > I see 5 years ago, Roman added a TODO comment [1] at http://hg.openjdk.java.net/jdk/jdk/file/bbc7157ad9c5/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp#l1035 saying >> TODO: For some reason, using the Rscratch that gets passed in is >> not possible because the register allocator does not see the tmp reg >> as used, and assigns it the same register as Rdividend. We use rscratch1 >> instead. > > So I was wondering why register allocator also assigns the temp register to the dividend. Is there any special handling for LIR_Op3 in C1 linear scan? > I appreciate your help. Hmm, I am not sure. Here: http://hg.openjdk.java.net/jdk/jdk/file/bbc7157ad9c5/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp#l1035 .. the opr3 is marked as 'temp' (if it's assigned a valid value) which means it should be live for the lifetime of the instruction, but not before or after it. Maybe that comment is obsolete? Have you tried to use opr3/Rscratch ? Roman From Pengfei.Li at arm.com Wed Sep 12 01:00:25 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Wed, 12 Sep 2018 01:00:25 +0000 Subject: [aarch64-port-dev ] AArch64: Why should we use rscratch1 instead of the temp register passed in? In-Reply-To: <30796959-052a-fb3d-033e-7cd6ebc3d0d5@redhat.com> References: <30796959-052a-fb3d-033e-7cd6ebc3d0d5@redhat.com> Message-ID: Hi Roman, > .. the opr3 is marked as 'temp' (if it's assigned a valid value) which means it > should be live for the lifetime of the instruction, but not before or after it. > Maybe that comment is obsolete? Have you tried to use opr3/Rscratch ? Thanks for your reply. I've tried to use Rscratch and assertion failed at http://hg.openjdk.java.net/jdk/jdk/file/bbc7157ad9c5/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#l1774. RA assigns the same register (rscratch) to Rdividend just as your comment said. So that comment is not obsolete. -- Thanks, Pengfei From dean.long at oracle.com Wed Sep 12 03:30:47 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 11 Sep 2018 20:30:47 -0700 Subject: [aarch64-port-dev ] AArch64: Why should we use rscratch1 instead of the temp register passed in? In-Reply-To: References: <30796959-052a-fb3d-033e-7cd6ebc3d0d5@redhat.com> Message-ID: Isn't this the same problem LIR_Assembler::emit_typecheck_helper() is solving with this code: *if* (obj ==k_RInfo ) { k_RInfo =dst ; }*else* *if* (obj ==klass_RInfo ) { klass_RInfo =dst ; } *if* (k->is_loaded () && !UseCompressedClassPointers ) { select_different_registers (obj ,dst ,k_RInfo ,klass_RInfo ); (though the if-else and the select_different_registers appear to me to be doing the same thing here.) There's an input operand that isn't live after this instruction, so its register can be reused by the result or one of the temps. If it's a temp, find out which one and use the result register instead. dl On 9/11/18 6:00 PM, Pengfei Li (Arm Technology China) wrote: > Hi Roman, > >> .. the opr3 is marked as 'temp' (if it's assigned a valid value) which means it >> should be live for the lifetime of the instruction, but not before or after it. >> Maybe that comment is obsolete? Have you tried to use opr3/Rscratch ? > > Thanks for your reply. > > I've tried to use Rscratch and assertion failed at http://hg.openjdk.java.net/jdk/jdk/file/bbc7157ad9c5/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#l1774. > RA assigns the same register (rscratch) to Rdividend just as your comment said. So that comment is not obsolete. > > -- > Thanks, > Pengfei From dean.long at oracle.com Wed Sep 12 03:35:26 2018 From: dean.long at oracle.com (dean.long at oracle.com) Date: Tue, 11 Sep 2018 20:35:26 -0700 Subject: [aarch64-port-dev ] AArch64: Why should we use rscratch1 instead of the temp register passed in? In-Reply-To: References: <30796959-052a-fb3d-033e-7cd6ebc3d0d5@redhat.com> Message-ID: Oops, I don't know what happened to the formatting.? You can find LIR_Assembler::emit_typecheck_helper() here: http://hg.openjdk.java.net/jdk/jdk/file/bbc7157ad9c5/src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp#l1325 dl On 9/11/18 8:30 PM, dean.long at oracle.com wrote: > Isn't this the same problem LIR_Assembler::emit_typecheck_helper() is > solving with this code: > > ? > > (though the if-else and the select_different_registers appear to me to > be doing the same thing here.) > > There's an input operand that isn't live after this instruction, so > its register can be reused by the result or one of the temps. If it's > a temp, find out which one and use the result register instead. > > dl > > > On 9/11/18 6:00 PM, Pengfei Li (Arm Technology China) wrote: >> Hi Roman, >> >>> .. the opr3 is marked as 'temp' (if it's assigned a valid value) >>> which means it >>> should be live for the lifetime of the instruction, but not before >>> or after it. >>> Maybe that comment is obsolete? Have you tried to use opr3/Rscratch ? >> >> Thanks for your reply. >> >> I've tried to use Rscratch and assertion failed at >> http://hg.openjdk.java.net/jdk/jdk/file/bbc7157ad9c5/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#l1774. >> RA assigns the same register (rscratch) to Rdividend just as your >> comment said. So that comment is not obsolete. >> >> -- >> Thanks, >> Pengfei > From rwestrel at redhat.com Wed Sep 12 07:56:58 2018 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 12 Sep 2018 09:56:58 +0200 Subject: [aarch64-port-dev ] RFR: 8210578: AArch64: Invalid encoding for fmlsvs instruction In-Reply-To: <80d98039-c412-b638-c764-0794da1ba26f@redhat.com> References: <80d98039-c412-b638-c764-0794da1ba26f@redhat.com> Message-ID: Patch looks good to me. Roland. From adinn at redhat.com Wed Sep 12 08:07:39 2018 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 12 Sep 2018 09:07:39 +0100 Subject: [aarch64-port-dev ] RFR: 8210578: AArch64: Invalid encoding for fmlsvs instruction In-Reply-To: References: <80d98039-c412-b638-c764-0794da1ba26f@redhat.com> Message-ID: On 12/09/18 08:56, Roland Westrelin wrote: > > Patch looks good to me. Thanks for the review Roland. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From Pengfei.Li at arm.com Thu Sep 13 09:04:36 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 13 Sep 2018 09:04:36 +0000 Subject: [aarch64-port-dev ] RFR(S): 8210413: AArch64: Optimize div/rem by constant in C1 Message-ID: Hi, Could you please help review this optimization in C1 AArch64? Currently, there are 2 LIR_Assembler::arithmetic_idiv() methods in c1_LIRAssembler_aarch64.cpp. One is left unimplemented, the other checks whether the divisor is a power-of-2 constant but does nothing optimized then. In this patch, I combined these 2 methods and added 2 below optimizations for integer div/rem. 1) Remove the div-by-zero check if the divisor is known to be a non-zero constant. 2) Use cheaper instructions instead of "sdiv" to do div/rem by a power-of-2 constant (including 1, 2, 4, 8, 16, ...) JBS: https://bugs.openjdk.java.net/browse/JDK-8210413 webrev: http://cr.openjdk.java.net/~njian/8210413/webrev.00/ As Roman Kennke's original code comment said, using the temp register passed into arithmetic_idiv() is problematic. So I also use the rscratch1 directly for intermediate result in div/rem calculations. You could refer thread http://mail.openjdk.java.net/pipermail/aarch64-port-dev/2018-September/006315.html for this issue. I've run jtreg full test with this patch and JVM option "-XX:TieredStopAtLevel=1" on an AArch64 server and no new issues found. -- Thanks, Pengfei From aph at redhat.com Thu Sep 13 11:05:52 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Sep 2018 12:05:52 +0100 Subject: [aarch64-port-dev ] RFR(S): 8210413: AArch64: Optimize div/rem by constant in C1 In-Reply-To: References: Message-ID: <9645c210-3d87-52fa-8051-54dc60629866@redhat.com> Hi, On 09/13/2018 10:04 AM, Pengfei Li (Arm Technology China) wrote: > Could you please help review this optimization in C1 AArch64? > JBS: https://bugs.openjdk.java.net/browse/JDK-8210413 > webrev: http://cr.openjdk.java.net/~njian/8210413/webrev.00/ It looks fine, but it's really odd that this is only implemented for ints and not longs. Can you do longs too? -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitrij.pochepko at bell-sw.com Thu Sep 13 14:35:53 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 13 Sep 2018 17:35:53 +0300 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> Message-ID: <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> Hi, I found 3 items to fix in your comments in http://cr.openjdk.java.net/~adinn/8189107/original_algorithm.txt 1) //?????????? [1, sqrt(3/2)), [sqrt(3/2), sqrt(3)/2), [sqrt(3)/2, 2) //????? i.e. [1, ~1.225],??? [~1.225,??? ~1.732),??? [~1.732, 2) this one should be: [1, sqrt(3/2)), [sqrt(3/2), sqrt(3)), [sqrt(3), 2) i.e. [1, ~1.225],??? [~1.225,??? ~1.732),??? [~1.732,??? 2) 2) "4) Filter out overflows (z > 1023) or underflows (z < -1077)" should be: "4) Filter out overflows (z > 1023) or underflows (z < -1076)" 3) "5) Let |z| = n + r where n is int, 0 <= n < 10, and 0 <= r < 1" should be: "5) Let |z| = n + r where n is int, 0 <= n < 1076, and 0 <= r < 1" Other comments seems fine Thanks, Dmitrij On 07/09/18 15:58, Andrew Dinn wrote: > > I have rewritten the algorithm to achieve what I think is needed to > patch these omissions. The redraft of this part of the code is available > here: > > http://cr.openjdk.java.net/~adinn/8189107/original_algorithm.txt > > From mikael.vidstedt at oracle.com Thu Sep 13 23:03:15 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Sep 2018 16:03:15 -0700 Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label variables Message-ID: Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! bug: https://bugs.openjdk.java.net/browse/JDK-8210676 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ * Background (from bug) [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. * About the change I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. * Testing tier1 build&test passes. Cheers, Mikael From vladimir.kozlov at oracle.com Thu Sep 13 23:16:25 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Thu, 13 Sep 2018 16:16:25 -0700 Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: Looks good to me. Thanks, Vladimir On 9/13/18 4:03 PM, Mikael Vidstedt wrote: > > Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! > > bug: https://bugs.openjdk.java.net/browse/JDK-8210676 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ > > * Background (from bug) > > [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. > > * About the change > > I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. > > * Testing > > tier1 build&test passes. > > Cheers, > Mikael > From david.holmes at oracle.com Fri Sep 14 01:17:21 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Sep 2018 11:17:21 +1000 Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: Looks good - though the proof is in the building of course. The debug-only use of notDouble in src/hotspot/cpu/x86/templateTable_x86.cpp seems somewhat odd. Thanks, David On 14/09/2018 9:03 AM, Mikael Vidstedt wrote: > > Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! > > bug: https://bugs.openjdk.java.net/browse/JDK-8210676 > webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ > > * Background (from bug) > > [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. > > * About the change > > I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. > > * Testing > > tier1 build&test passes. > > Cheers, > Mikael > From mikael.vidstedt at oracle.com Fri Sep 14 01:22:20 2018 From: mikael.vidstedt at oracle.com (Mikael Vidstedt) Date: Thu, 13 Sep 2018 18:22:20 -0700 Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: <6D50BF19-4A15-432F-A0EF-FC777113F88E@oracle.com> > On Sep 13, 2018, at 6:17 PM, David Holmes wrote: > > Looks good - though the proof is in the building of course. > > The debug-only use of notDouble in src/hotspot/cpu/x86/templateTable_x86.cpp seems somewhat odd. Would you prefer to see it declared next to the other labels, but guarded with ASSERT? Cheers, Mikael > > Thanks, > David > > On 14/09/2018 9:03 AM, Mikael Vidstedt wrote: >> Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! >> bug: https://bugs.openjdk.java.net/browse/JDK-8210676 >> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ >> * Background (from bug) >> [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. >> * About the change >> I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. >> * Testing >> tier1 build&test passes. >> Cheers, >> Mikael From david.holmes at oracle.com Fri Sep 14 01:38:57 2018 From: david.holmes at oracle.com (David Holmes) Date: Fri, 14 Sep 2018 11:38:57 +1000 Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label variables In-Reply-To: <6D50BF19-4A15-432F-A0EF-FC777113F88E@oracle.com> References: <6D50BF19-4A15-432F-A0EF-FC777113F88E@oracle.com> Message-ID: <4e46fa33-188f-999b-1711-faed4b137f8b@oracle.com> On 14/09/2018 11:22 AM, Mikael Vidstedt wrote: > >> On Sep 13, 2018, at 6:17 PM, David Holmes wrote: >> >> Looks good - though the proof is in the building of course. >> >> The debug-only use of notDouble in src/hotspot/cpu/x86/templateTable_x86.cpp seems somewhat odd. > > Would you prefer to see it declared next to the other labels, but guarded with ASSERT? No what you have is fine. I'm just curious about why the double case is only examined in a non-product build ?? David > Cheers, > Mikael > >> >> Thanks, >> David >> >> On 14/09/2018 9:03 AM, Mikael Vidstedt wrote: >>> Please review this change which removes a bunch of unused Label variables. Would appreciate some help from aarch64/ppc/s390x folks to verify it! >>> bug: https://bugs.openjdk.java.net/browse/JDK-8210676 >>> webrev: http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ >>> * Background (from bug) >>> [~dholmes] noticed during the code review of JDK-8210381 that the "Label Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused labels like it should be removed. >>> * About the change >>> I have *not* tried to find and remove *all* unused Label variables, because that turns out to be much harder than it might seem. I may or may not follow up on this work to remove additional unused Label variables later, but before that I?m investigating removal of other unused variables in general. Meanwhile I like to think that this is a reasonable cleanup anyway. >>> * Testing >>> tier1 build&test passes. >>> Cheers, >>> Mikael > From Ningsheng.Jian at arm.com Fri Sep 14 04:19:10 2018 From: Ningsheng.Jian at arm.com (Ningsheng Jian (Arm Technology China)) Date: Fri, 14 Sep 2018 04:19:10 +0000 Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: Hi Mikael, AArch64 and Arm parts looks good and I have also verified the build. Thanks, Ningsheng > -----Original Message----- > From: aarch64-port-dev On > Behalf Of Mikael Vidstedt > Sent: Friday, September 14, 2018 7:03 AM > To: HotSpot Open Source Developers > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; > aarch64-port-dev at openjdk.java.net > Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label > variables > > > Please review this change which removes a bunch of unused Label variables. > Would appreciate some help from aarch64/ppc/s390x folks to verify it! > > bug: https://bugs.openjdk.java.net/browse/JDK-8210676 > webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8210676/webrev.03/open/webrev/ > > * Background (from bug) > > [~dholmes] noticed during the code review of JDK-8210381 that the "Label > Egress" variable in macroAssembler_sparc.cpp was unused. It and other unused > labels like it should be removed. > > * About the change > > I have *not* tried to find and remove *all* unused Label variables, because that > turns out to be much harder than it might seem. I may or may not follow up on > this work to remove additional unused Label variables later, but before that I?m > investigating removal of other unused variables in general. Meanwhile I like to > think that this is a reasonable cleanup anyway. > > * Testing > > tier1 build&test passes. > > Cheers, > Mikael From aph at redhat.com Fri Sep 14 08:59:35 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 Sep 2018 09:59:35 +0100 Subject: [aarch64-port-dev ] RFR(S): 8210676: Remove some unused Label variables In-Reply-To: References: Message-ID: <45d6dcb7-d1df-62c5-0662-a921350b21de@redhat.com> On 09/14/2018 05:19 AM, Ningsheng Jian (Arm Technology China) wrote: > AArch64 and Arm parts looks good and I have also verified the build. Yep. That's a nice cleanup. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Sep 14 09:34:34 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 Sep 2018 10:34:34 +0100 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> Message-ID: <169c83ec-3e2f-a001-22c0-08528b3f189f@redhat.com> On 09/07/2018 01:58 PM, Andrew Dinn wrote: > I have rewritten the algorithm to achieve what I think is needed to > patch these omissions. The redraft of this part of the code is available > here: > > http://cr.openjdk.java.net/~adinn/8189107/original_algorithm.txt I know that you're very good at using punctuation, capitalization, and grammar in written text. However, for some reason you omit these in comments. In this case, it would be much easier to read your comments if they were recast as sentences in grammatical English. Sure, some of them could be simply noun phrases. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Sep 14 09:59:38 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 14 Sep 2018 10:59:38 +0100 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> Message-ID: <26281e69-0354-9abe-1ffc-36c10fd93d68@redhat.com> Hi Dmitrij, On 13/09/18 15:35, Dmitrij Pochepko wrote: > I found 3 items to fix in your comments in > http://cr.openjdk.java.net/~adinn/8189107/original_algorithm.txt > > 1) > > //?????????? [1, sqrt(3/2)), [sqrt(3/2), sqrt(3)/2), [sqrt(3)/2, 2) > //????? i.e. [1, ~1.225],??? [~1.225,??? ~1.732),??? [~1.732, 2) > > this one should be: > > [1, sqrt(3/2)), [sqrt(3/2), sqrt(3)), [sqrt(3), 2) > i.e. [1, ~1.225],??? [~1.225,??? ~1.732),??? [~1.732,??? 2) > > > 2) > > "4) Filter out overflows (z > 1023) or underflows (z < -1077)" > > should be: > > "4) Filter out overflows (z > 1023) or underflows (z < -1076)" > > 3) "5) Let |z| = n + r where n is int, 0 <= n < 10, and 0 <= r < 1" > > should be: > > "5) Let |z| = n + r where n is int, 0 <= n < 1076, and 0 <= r < 1" > > Other comments seems fine Thank you for the corrections. I will update the file on cr.openjdk.java.net accordingly. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Fri Sep 14 13:06:41 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 14 Sep 2018 14:06:41 +0100 Subject: [aarch64-port-dev ] Field too big for insn issue with Shenandoah In-Reply-To: <2c69337a-835c-933e-c615-ed694b7c3443@redhat.com> References: <5d48fccf-1b34-a704-24cb-cd67553bb121@redhat.com> <50bfb4ee-bdf4-3a09-0fd5-59f0533b7503@redhat.com> <2c69337a-835c-933e-c615-ed694b7c3443@redhat.com> Message-ID: <50a97c51-ce17-61ee-f3b9-1e6927ed2d57@redhat.com> On 09/10/2018 07:11 PM, Roman Kennke wrote: > Am 10.09.2018 um 20:03 schrieb Andrew Haley: >> On 09/10/2018 04:11 PM, Roman Kennke wrote: >>> This only happens when running with Shenandoah. I suspect that the extra >>> barriers that we emit with Shenandoah make the code too big and the PC >>> too far away from the constants, but I am not sure. >> >> Nice catch! I always knew that this was a theoretical possibility, but >> I never could find a way to trigger it. >> >>> Does anybody have an idea why that happens and how to possibly fix it? >> >> I'll have a look. It's going to be very awkward if loads can't reach the >> constant pool. The load offset is 19 bits, shifted by 2, so that's +/- a >> megabyte. I don't really believe that any method will generate a megabyte >> of code, so I suspect that there may be some other reason. Perhaps enabling >> debug mode just generates too much checking code. >> >> Which test was running? >> > > It was happening with basically any program running under fastdebug + C1 > + Shenandoah. It occured because we tripled NMethodSizeLimit when > running with Shenandoah to make space for extra code for barriers. And > we 'fixed' it by leaving that flag alone: > > http://hg.openjdk.java.net/shenandoah/jdk/rev/5d035e4eb822 > > You might want to crank up that flag to trigger the bug (if it is one) > in upstream (no Shenandoah). A proper fix might be to enforce an upper > bound for that flag that ensures offsets from code can always reach the > constants. Mmm. I'm surprised that even multiplying NMethodSizeLimit by 3 blows up the 1Mb limit. I don't know how that can happen. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Sep 14 15:29:47 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 14 Sep 2018 16:29:47 +0100 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> Message-ID: <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> On 13/09/18 15:35, Dmitrij Pochepko wrote: > Other comments seems fine I am glad to hear that you did not find any errors in my analysis. However, I also need to ask you to answer a question that was implicit in my earlier note. I said: "I assume you are familiar with the relevant mathematics and how it has been used to derive the algorithm. If so then I would like you to review this rewrite and ensure that there are nor mathematical errors in it. I would also like you to check that the explanatory comments for of the individual steps in the algorithm do not contain any errors. If you are not familiar with the mathematics then please let me know. I need to know whether this has been reviewed by someone competent to do so." As you didn't respond to this I will have to ask you explicitly this time. Do you have a background in mathematics and numerical analysis that means you understand how the original algorithm has been arrived at? equally, how your algorithm may legitimately vary from that original? I'll break this down into several steps: Do you understand the (elementary) theory that explains how the various polynomial expansions I described in my comments converge to the original log and exp functions? Do you understand the theory that explains how partial polynomial sums (Remez polynomials) can be used used to approximate these polynomial expansions within specified ranges? Do you know how the coefficients of these Remez polynomial can be derived to any necessary accuracy? Do you understand how the computation of the values of those Remez polynomials must proceed in order to guarantee accuracy in the computed result in the presence of rounding errors? Can you provide a mathematical proof that the variations you have introduced into the computational process (specifially the move from Horner form to Estrin form) will not introduce rounding errors? I certainly cannot lay claim to a /thorough/ understanding of most, if not all, those topics. If you also cannot then I think we need to bring in someone who does. In particular, it is the last point that matters most of all here as this is where you have /chosen/ to make your algorithm diverge from the code you inherited. As regards the rest of the background maths, we do at least know that the other aspects of the algorithm -- in its original manifestation -- have been checked by numerical experts. Hence, if we ensure that your algorithm implements /equivalent/ steps then it ought to inherit the same guarantees of correctness. So, the only task as far as most of the code is concerned is to iron out any errors you might inadvertently have introduced. I have several nits to pick in that regard that which I will be posting shortly. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From rkennke at redhat.com Mon Sep 17 10:58:51 2018 From: rkennke at redhat.com (Roman Kennke) Date: Mon, 17 Sep 2018 12:58:51 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2018-09-17 Message-ID: <57d55193-e132-ebb4-dd0e-71eaa2686f94@redhat.com> Please review the following proposed changes: This integrates changes from shenandoah/jdk8u into aarch64-port/jdk8u-shenandoah repository, reaching back to May 2018. It's bugfixes, improvements and new features that have been originally done in Shenandoah dev repo, and then backported to Shenandoah JDK8u repo and tested there for a while too. List of changes: http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-09-17/jdk8u-shenandoah-integration-2018-09-17.txt Webrev showing only shared-changes: http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-09-17/webrev.00.shared/ Full webrev: http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-09-17/webrev.00/ Most of the shared changes are actually reverts of previously Shenandoah-specific changes. (If webrevs are not there yet, try again later. It's currently syncing with my local copy, and it's fairly huge). Thanks, Roman From shade at redhat.com Mon Sep 17 11:29:10 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Sep 2018 13:29:10 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2018-09-17 In-Reply-To: <57d55193-e132-ebb4-dd0e-71eaa2686f94@redhat.com> References: <57d55193-e132-ebb4-dd0e-71eaa2686f94@redhat.com> Message-ID: On 09/17/2018 12:58 PM, Roman Kennke wrote: > This integrates changes from shenandoah/jdk8u into > aarch64-port/jdk8u-shenandoah repository, reaching back to May 2018. > It's bugfixes, improvements and new features that have been originally > done in Shenandoah dev repo, and then backported to Shenandoah JDK8u > repo and tested there for a while too. Also, our adopters are running sh/jdk8u without problems for a while now. Time to put this into RPMs. > List of changes: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-09-17/jdk8u-shenandoah-integration-2018-09-17.txt Oh, so much good stuff is missing in current aarch64-port/jdk8u-shenandoah! > Webrev showing only shared-changes: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-09-17/webrev.00.shared/ This looks good to me. > Full webrev: > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-09-17/webrev.00/ Shenandoah integration parts look good for me too. Thanks, -Aleksey From vladimir.kozlov at oracle.com Mon Sep 17 17:00:45 2018 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Mon, 17 Sep 2018 10:00:45 -0700 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: CCing to build-dev and aarch64-port. I looked through changes and they seem fine. Thanks, Vladimir On 9/17/18 9:20 AM, Bob Vandette wrote: > Please review the changes related to JEP 340 which remove the second 64-bit ARM port > from the JDK. > > http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. > I?ve run specJVM98 on the three 32-bit ARM VMs. > > I also verified that Linux x64 builds. > > Bob. > > From erik.joelsson at oracle.com Mon Sep 17 17:25:59 2018 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 17 Sep 2018 10:25:59 -0700 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: <1c9699c5-ca62-2637-fe8e-2d9f1413047f@oracle.com> Build changes look ok. /Erik On 2018-09-17 10:00, Vladimir Kozlov wrote: > CCing to build-dev and aarch64-port. > > I looked through changes and they seem fine. > > Thanks, > Vladimir > > On 9/17/18 9:20 AM, Bob Vandette wrote: >> Please review the changes related to JEP 340 which remove the second >> 64-bit ARM port >> from the JDK. >> >> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >> >> I?ve testing building the remaining 32 and 64 bit ARM ports including >> the minimal, client and server VMs. >> I?ve run specJVM98 on the three 32-bit ARM VMs. >> >> I also verified that Linux x64 builds. >> >> Bob. >> >> From shade at redhat.com Mon Sep 17 17:49:52 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Sep 2018 19:49:52 +0200 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: > On 9/17/18 9:20 AM, Bob Vandette wrote: >> Please review the changes related to JEP 340 which remove the second >> 64-bit ARM port from the JDK.>> >> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 I read through the webrev, and it seems to be the clean removal. It also feels very satisfying to drop 15 KLOC of ifdef-ed code. Minor nits: *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", which cab be just "#ifdef ASSERT" now *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if defined(__ABI_HARD__)" *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below seems to apply to AArch64 only. Yet, only the first line of the comment is removed. I think we should instead convert that comment into "TODO:" mentioning this might be revised after AArch64 removal? 992 void branch_if_negative_32(Register r, Label& L) { 993 // Note about branch_if_negative_32() / branch_if_any_negative_32() implementation for AArch64: 994 // tbnz is not used instead of tst & b.mi because destination may be out of tbnz range (+-32KB) 995 // since these methods are used in LIR_Assembler::emit_arraycopy() to jump to stub entry. 996 tst_32(r, r); 997 b(L, mi); 998 } *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205, L1435..1436 can be merged together: 1203 // Generate the inner loop for shifted forward array copy (unaligned copy). 1204 // It can be used when bytes_per_count < wordSize, i.e. 1205 // byte/short copy 1434 // Generate the inner loop for shifted backward array copy (unaligned copy). 1435 // It can be used when bytes_per_count < wordSize, i.e. 1436 // byte/short copy *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed incorrectly around L3363? - // R4 (AArch64) / SP[0] (32-bit ARM) - element count (32-bit int) + // R4 - element count (32-bit int) *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, "R4"/"R5" comments are missing: - const Register Rsig_handler = AARCH64_ONLY(R21) NOT_AARCH64(Rtmp_save0 /* R4 */); - const Register Rnative_code = AARCH64_ONLY(R22) NOT_AARCH64(Rtmp_save1 /* R5 */); + const Register Rsig_handler = Rtmp_save0; + const Register Rnative_code = Rtmp_save1; Thanks, -Aleksey From bob.vandette at oracle.com Mon Sep 17 18:15:10 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Mon, 17 Sep 2018 14:15:10 -0400 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: <1C1771D3-07BF-45A5-AE5A-578BE9392CAE@oracle.com> Thanks for the detailed review Aleksey. I took care of these. Bob. > On Sep 17, 2018, at 1:49 PM, Aleksey Shipilev wrote: > > On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: >> On 9/17/18 9:20 AM, Bob Vandette wrote: >>> Please review the changes related to JEP 340 which remove the second >>> 64-bit ARM port from the JDK.>> >>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I read through the webrev, and it seems to be the clean removal. It also feels > very satisfying to drop 15 KLOC of ifdef-ed code. > > Minor nits: > > *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and > src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", which cab > be just "#ifdef ASSERT" now > > *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if > defined(__ABI_HARD__)" > > *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below seems to > apply to AArch64 only. Yet, only the first line of the comment is removed. I > think we should instead convert that comment into "TODO:" mentioning this might > be revised after AArch64 removal? > > 992 void branch_if_negative_32(Register r, Label& L) { > 993 // Note about branch_if_negative_32() / branch_if_any_negative_32() > implementation for AArch64: > 994 // tbnz is not used instead of tst & b.mi because destination may be > out of tbnz range (+-32KB) > 995 // since these methods are used in LIR_Assembler::emit_arraycopy() to > jump to stub entry. > 996 tst_32(r, r); > 997 b(L, mi); > 998 } > > *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205, L1435..1436 > can be merged together: > > 1203 // Generate the inner loop for shifted forward array copy (unaligned copy). > 1204 // It can be used when bytes_per_count < wordSize, i.e. > 1205 // byte/short copy > > 1434 // Generate the inner loop for shifted backward array copy (unaligned copy). > 1435 // It can be used when bytes_per_count < wordSize, i.e. > 1436 // byte/short copy > > > *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed > incorrectly around L3363? > > - // R4 (AArch64) / SP[0] (32-bit ARM) - element count (32-bit int) > + // R4 - element count (32-bit int) > > > *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, "R4"/"R5" > comments are missing: > > - const Register Rsig_handler = AARCH64_ONLY(R21) NOT_AARCH64(Rtmp_save0 /* > R4 */); > - const Register Rnative_code = AARCH64_ONLY(R22) NOT_AARCH64(Rtmp_save1 /* > R5 */); > + const Register Rsig_handler = Rtmp_save0; > + const Register Rnative_code = Rtmp_save1; > > Thanks, > -Aleksey > From david.holmes at oracle.com Tue Sep 18 02:53:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Tue, 18 Sep 2018 12:53:19 +1000 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: Hi Bob, On 18/09/2018 2:20 AM, Bob Vandette wrote: > Please review the changes related to JEP 340 which remove the second 64-bit ARM port > from the JDK. > > http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. > I?ve run specJVM98 on the three 32-bit ARM VMs. Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. Cheers, David > I also verified that Linux x64 builds. > > Bob. > > From Pengfei.Li at arm.com Tue Sep 18 07:40:53 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Tue, 18 Sep 2018 07:40:53 +0000 Subject: [aarch64-port-dev ] RFR(S): 8210413: AArch64: Optimize div/rem by constant in C1 In-Reply-To: <9645c210-3d87-52fa-8051-54dc60629866@redhat.com> References: <9645c210-3d87-52fa-8051-54dc60629866@redhat.com> Message-ID: Hi Andrew, Thanks for your reminder. I'm adding this for longs and testing it. I will send out a new webrev later. -- Thanks, Pengfei > -----Original Message----- > > Hi, > > On 09/13/2018 10:04 AM, Pengfei Li (Arm Technology China) wrote: > > > Could you please help review this optimization in C1 AArch64? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210413 > > webrev: http://cr.openjdk.java.net/~njian/8210413/webrev.00/ > > It looks fine, but it's really odd that this is only implemented for ints and not > longs. Can you do longs too? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From bob.vandette at oracle.com Tue Sep 18 13:17:46 2018 From: bob.vandette at oracle.com (Bob Vandette) Date: Tue, 18 Sep 2018 09:17:46 -0400 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> I only did some basic testing of the hard-float abi. Bell SW has offered to do more extensive testing as part of this JEP. I have no way of knowing if any of the other profiles are being used but I would think it?s worth keeping them in the event that someone wants to try to build/test these other configurations. The goal of this JEP is to eliminate the arm64 port and not cause any other changes in behavior. Bob. > On Sep 17, 2018, at 10:53 PM, David Holmes wrote: > > Hi Bob, > > On 18/09/2018 2:20 AM, Bob Vandette wrote: >> Please review the changes related to JEP 340 which remove the second 64-bit ARM port >> from the JDK. >> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >> I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. >> I?ve run specJVM98 on the three 32-bit ARM VMs. > > Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. > > Cheers, > David > >> I also verified that Linux x64 builds. >> Bob. From matthias.baesken at sap.com Wed Sep 5 11:08:48 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Wed, 5 Sep 2018 11:08:48 +0000 Subject: [aarch64-port-dev ] RFR(S): 8210381: Obsolete EmitSync In-Reply-To: <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> Message-ID: Hello , I had a short look at the ppc / s390x changes , looks OK . To be on the safe side I put it into our build/test queue, so we see results for ppc64(le) / s390x as well tomorrow . Best regards, Matthias > -----Original Message----- > From: ppc-aix-port-dev On > Behalf Of Mikael Vidstedt > Sent: Mittwoch, 5. September 2018 03:38 > To: daniel.daugherty at oracle.com > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; > HotSpot Open Source Developers ; > aarch64-port-dev at openjdk.java.net > Subject: Re: RFR(S): 8210381: Obsolete EmitSync > > > Dan/Vladimir, thanks for the reviews. > > FWIW, in addition to the build&test job I also did some manual work to > compare the disassembly of the resulting libjvm; the C++ compiler seems to > agree with my ?manual? dead code elimination (yay!). > > Cheers, > Mikael > > > On Sep 4, 2018, at 1:40 PM, Daniel D. Daugherty > wrote: > > > > On 9/4/18 3:36 PM, Mikael Vidstedt wrote: > >> Please review this change which obsoletes the EmitSync flag. In particular, > I could use some help from ppc, aarch64, and s390 maintainers to verify that > the change actually builds and (still) works. > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8210381 > > >> Webrev: > http://cr.openjdk.java.net/~mikael/webrevs/8210381/webrev.00/open/we > brev/ > ebrev/> > > > > src/hotspot/cpu/aarch64/aarch64.ad > > No comments. > > > > src/hotspot/cpu/ppc/macroAssembler_ppc.cpp > > No comments. > > > > src/hotspot/cpu/s390/macroAssembler_s390.cpp > > No comments. > > > > src/hotspot/cpu/sparc/macroAssembler_sparc.cpp > > No comments. > > > > src/hotspot/cpu/x86/macroAssembler_x86.cpp > > No comments. > > > > src/hotspot/share/runtime/arguments.cpp > > No comments. > > > > src/hotspot/share/runtime/globals.hpp > > No comments. > > > > > > General comments: > > > > - The 'if (EmitSync & 0x01) {' checks are how we disable the > > use of compiled code for monitors. We use -XX:EmitSync=1 > > to diagnose things when we wonder if the compiled monitor > > code is broken. > > - The 'if (EmitSync & 4)' checks are how we disable the use > > of compiled code for unlocking of monitors; we still use > > compiled code for locking of monitors. We use -XX:EmitSync=4 > > to diagnose things when we wonder if the compiled monitor > > unlock code is broken. > > - BTW, I think s390 is using (EmitSync & 0x01) differently > > than other platforms. No, I didn't try to figure out exactly > > how s390 was using that option. > > > > This looks like a clean obsoletion of the '-XX:EmitSync=' > > option so thumbs up from that POV. > > > > Use of '-XX:EmitSync=1' for diagnostic purposes is probably > > limited to a handful of people including me. Use of the > > '-XX:EmitSync=4' is probably even more rare; I can't remember > > using it myself. So while I have used the '-XX:EmitSync=' > > option to debug Java monitor stuff, it has been a long time > > time... > > > > Dan > > > >> > >> * Background (from bug) > >> > >> The experimental EmitSync flag can in theory be used to select which > implementation of the synchronization primitives to use. The flag was > convenient when the various implementations were compared a long time > ago. > >> > >> In practice the only implementation that is used and tested today is the > default one. The EmitSync flag no longer serves the purpose it used to, and is > "Unsafe, Unstable" (the documentation of the flag says so explicitly). It > should be obsoleted and later removed. > >> > >> Cheers, > >> Mikael > >> > >> > > From matthias.baesken at sap.com Thu Sep 6 06:56:01 2018 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Thu, 6 Sep 2018 06:56:01 +0000 Subject: [aarch64-port-dev ] RFR(S): 8210381: Obsolete EmitSync In-Reply-To: References: <2EC504F2-8F6C-4005-B87F-8F8D78B15C1B@oracle.com> <7a041851-cdb8-9857-7fa3-1b23381478ac@oracle.com> <3CB21532-32F5-4453-9E80-57A586B5A8C1@oracle.com> Message-ID: Hello, small update from my side - builds were fine with the patch included on our ppc64(le) / s390x platforms . I did not notice any test failures related to the patch . Best regards, Matthias > -----Original Message----- > From: Baesken, Matthias > Sent: Mittwoch, 5. September 2018 13:09 > To: 'Mikael Vidstedt' ; > daniel.daugherty at oracle.com; Doerr, Martin > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; > HotSpot Open Source Developers ; > aarch64-port-dev at openjdk.java.net > Subject: RE: RFR(S): 8210381: Obsolete EmitSync > > Hello , I had a short look at the ppc / s390x changes , looks OK . > To be on the safe side I put it into our build/test queue, so we see results > for ppc64(le) / s390x as well tomorrow . > > Best regards, Matthias > > > -----Original Message----- > > From: ppc-aix-port-dev > On > > Behalf Of Mikael Vidstedt > > Sent: Mittwoch, 5. September 2018 03:38 > > To: daniel.daugherty at oracle.com > > Cc: s390x-port-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net; > > HotSpot Open Source Developers ; > > aarch64-port-dev at openjdk.java.net > > Subject: Re: RFR(S): 8210381: Obsolete EmitSync > > > > > > Dan/Vladimir, thanks for the reviews. > > > > FWIW, in addition to the build&test job I also did some manual work to > > compare the disassembly of the resulting libjvm; the C++ compiler seems > to > > agree with my ?manual? dead code elimination (yay!). > > > > Cheers, > > Mikael From simon at cjnash.com Tue Sep 18 17:14:20 2018 From: simon at cjnash.com (Simon Nash) Date: Tue, 18 Sep 2018 18:14:20 +0100 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> Message-ID: <5BA1326C.7040708@cjnash.com> On 18/09/2018 14:17, Bob Vandette wrote: > I only did some basic testing of the hard-float abi. Bell SW has offered to do more extensive testing > as part of this JEP. > > I have no way of knowing if any of the other profiles are being used but I would think it?s > worth keeping them in the event that someone wants to try to build/test these other configurations. > I am using the abi profiles arm-vfp-hflt and arm-sflt. So far I have only built jdk9u with these profiles. It would be a serious problem for me if these profiles don't continue to work on later JDK versions. Simon > The goal of this JEP is to eliminate the arm64 port and not cause any other changes in behavior. > > Bob. > > >> On Sep 17, 2018, at 10:53 PM, David Holmes wrote: >> >> Hi Bob, >> >> On 18/09/2018 2:20 AM, Bob Vandette wrote: >>> Please review the changes related to JEP 340 which remove the second 64-bit ARM port >>> from the JDK. >>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>> I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. >>> I?ve run specJVM98 on the three 32-bit ARM VMs. >> Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. >> >> Cheers, >> David >> >>> I also verified that Linux x64 builds. >>> Bob. > > From boris.ulasevich at bell-sw.com Wed Sep 19 10:30:03 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Wed, 19 Sep 2018 13:30:03 +0300 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> Message-ID: <990eb025-8705-8633-abd7-0e87a3dc6d33@bell-sw.com> Hi Bob, Thank you for this job! I have started testing. Will come back with results next week :) The changes is Ok for me. Please see some minor comments below. regards, Boris On 17.09.2018 20:49, Aleksey Shipilev wrote: > On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: >> On 9/17/18 9:20 AM, Bob Vandette wrote: >>> Please review the changes related to JEP 340 which remove the second >>> 64-bit ARM port from the JDK.>> >>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 > > I read through the webrev, and it seems to be the clean removal. It also feels > very satisfying to drop 15 KLOC of ifdef-ed code. > > Minor nits: > > *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and > src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", which cab > be just "#ifdef ASSERT" now > > *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if > defined(__ABI_HARD__)" > > *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below seems to > apply to AArch64 only. Yes, the note looks like AArch64 specific comment, but I think it is valid for arm32 too. So the change is Ok for me. > Yet, only the first line of the comment is removed. I > think we should instead convert that comment into "TODO:" mentioning this might > be revised after AArch64 removal? > > 992 void branch_if_negative_32(Register r, Label& L) { > 993 // Note about branch_if_negative_32() / branch_if_any_negative_32() > implementation for AArch64: > 994 // tbnz is not used instead of tst & b.mi because destination may be > out of tbnz range (+-32KB) > 995 // since these methods are used in LIR_Assembler::emit_arraycopy() to > jump to stub entry. > 996 tst_32(r, r); > 997 b(L, mi); > 998 } > > *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205, L1435..1436 > can be merged together: > > 1203 // Generate the inner loop for shifted forward array copy (unaligned copy). > 1204 // It can be used when bytes_per_count < wordSize, i.e. > 1205 // byte/short copy > > 1434 // Generate the inner loop for shifted backward array copy (unaligned copy). > 1435 // It can be used when bytes_per_count < wordSize, i.e. > 1436 // byte/short copy > > > *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed > incorrectly around L3363? I believe both (L3188 and L3363) comments should mention SP[0] (not R4) as an input parameter now. > - // R4 (AArch64) / SP[0] (32-bit ARM) - element count (32-bit int) > + // R4 - element count (32-bit int) > > > *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, "R4"/"R5" > comments are missing: > > - const Register Rsig_handler = AARCH64_ONLY(R21) NOT_AARCH64(Rtmp_save0 /* > R4 */); > - const Register Rnative_code = AARCH64_ONLY(R22) NOT_AARCH64(Rtmp_save1 /* > R5 */); > + const Register Rsig_handler = Rtmp_save0; > + const Register Rnative_code = Rtmp_save1; > > Thanks, > -Aleksey > From gnu.andrew at redhat.com Wed Sep 19 16:55:08 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 19 Sep 2018 17:55:08 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2018-09-17 In-Reply-To: References: <57d55193-e132-ebb4-dd0e-71eaa2686f94@redhat.com> Message-ID: On Mon, 17 Sep 2018 at 12:30, Aleksey Shipilev wrote: > > On 09/17/2018 12:58 PM, Roman Kennke wrote: > > This integrates changes from shenandoah/jdk8u into > > aarch64-port/jdk8u-shenandoah repository, reaching back to May 2018. > > It's bugfixes, improvements and new features that have been originally > > done in Shenandoah dev repo, and then backported to Shenandoah JDK8u > > repo and tested there for a while too. > > Also, our adopters are running sh/jdk8u without problems for a while now. Time > to put this into RPMs. > > > List of changes: > > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-09-17/jdk8u-shenandoah-integration-2018-09-17.txt > > Oh, so much good stuff is missing in current aarch64-port/jdk8u-shenandoah! > > > Webrev showing only shared-changes: > > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-09-17/webrev.00.shared/ > > This looks good to me. > > > Full webrev: > > http://cr.openjdk.java.net/~rkennke/jdk8u-shenandoah-integration-2018-09-17/webrev.00/ > > Shenandoah integration parts look good for me too. > > Thanks, > -Aleksey > The changes look ok to me too. Is there a reason to maintain both shenandoah/jdk8u and aarch64-port/shenandoah-jdk8u, now that Shenandoah development has moved to an OpenJDK 12 base? -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Wed Sep 19 17:03:10 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 19 Sep 2018 19:03:10 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2018-09-17 In-Reply-To: References: <57d55193-e132-ebb4-dd0e-71eaa2686f94@redhat.com> Message-ID: <14f3fe9f-3ec1-451c-dc04-31ee0ef55c08@redhat.com> On 09/19/2018 06:55 PM, Andrew Hughes wrote: > The changes look ok to me too. Is there a reason to maintain both shenandoah/jdk8u and > aarch64-port/shenandoah-jdk8u, now that Shenandoah development has moved to an OpenJDK 12 base? We treat shenandoah/jdk8u as "let's push backports there and see what happens" repository: we build and test nightlies there, and sometimes our adopters find obvious bugs there that we don't want to expose to anybody else, and/or there are adopter-requested features/fixes that might degrade something else. Integration repository like aarch64-port/shenandoah-jdk8u has the stuff we know works fine. It is then open for larger testing and packaging. I think it makes more sense for 8u, because the GC interface is rather intrusive in 8u, and there is elevated risk for breakages for non-Shenandoah code. So, having the additional gateway where 8u integrations are reviewed is a plus. In 11+, almost all of Shenandoah code is isolated, and has much less risk to regress anything else. In other words, shenandoah/jdk8u is like jdk8u/dev, and aarch64-port/shenandoah-jdk8u is like jdk8u/jdk8u :) What we need to do for this to work better is to get shenandoah/jdk8u -> aarch64-port/shenandoah-jdk8u on a more frequent basis, so reviews stay trivial, and so that whatever problems found in RPMs are fixed quickly. Thanks, -Aleksey From david.holmes at oracle.com Wed Sep 19 06:44:12 2018 From: david.holmes at oracle.com (David Holmes) Date: Wed, 19 Sep 2018 16:44:12 +1000 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> Message-ID: Hi Bob, On 18/09/2018 11:17 PM, Bob Vandette wrote: > I only did some basic testing of the hard-float abi. Bell SW has offered to do more extensive testing > as part of this JEP. > > I have no way of knowing if any of the other profiles are being used but I would think it?s > worth keeping them in the event that someone wants to try to build/test these other configurations. > > The goal of this JEP is to eliminate the arm64 port and not cause any other changes in behavior. Sorry I was under the mistaken impression that all of the Oracle ARM port was being removed, but it is only the 64-bit part. That said it would concern me greatly if people are still building for anything older than ARMv7 with MP support! The work I'm doing to always act as-if MP is not only potentially inefficient on a uniprocessor, but for ARM variants without MP support, potentially it won't even run if instructions don't exist. I need to look into this further. Thanks, David > Bob. > > >> On Sep 17, 2018, at 10:53 PM, David Holmes wrote: >> >> Hi Bob, >> >> On 18/09/2018 2:20 AM, Bob Vandette wrote: >>> Please review the changes related to JEP 340 which remove the second 64-bit ARM port >>> from the JDK. >>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>> I?ve testing building the remaining 32 and 64 bit ARM ports including the minimal, client and server VMs. >>> I?ve run specJVM98 on the three 32-bit ARM VMs. >> >> Did you test all the ARM related abi-profiles? It seems to me they were only for Oracle's ARM32 port and may have never been used otherwise. I would have expected all that stuff to be removed. >> >> Cheers, >> David >> >>> I also verified that Linux x64 builds. >>> Bob. > From Pengfei.Li at arm.com Thu Sep 20 04:15:28 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 20 Sep 2018 04:15:28 +0000 Subject: [aarch64-port-dev ] RFR(S): 8210413: AArch64: Optimize div/rem by constant in C1 In-Reply-To: <9645c210-3d87-52fa-8051-54dc60629866@redhat.com> References: <9645c210-3d87-52fa-8051-54dc60629866@redhat.com> Message-ID: Hi Andrew, Please find below new patch that added the same optimization for longs as well as ints and also fixed an issue. http://cr.openjdk.java.net/~yzhang/8210413/webrev.01/ Could you help look at it again? -- Thanks, Pengfei > -----Original Message----- > > Hi, > > On 09/13/2018 10:04 AM, Pengfei Li (Arm Technology China) wrote: > > > Could you please help review this optimization in C1 AArch64? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8210413 > > webrev: http://cr.openjdk.java.net/~njian/8210413/webrev.00/ > > It looks fine, but it's really odd that this is only implemented for ints and not > longs. Can you do longs too? > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From roman at kennke.org Thu Sep 20 09:23:01 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 20 Sep 2018 09:23:01 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 146 new changesets Message-ID: <201809200923.w8K9N2LX000255@aojmv0008.oracle.com> Changeset: 44f93403550d Author: zgu Date: 2018-05-18 12:47 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/44f93403550d [Backport] Shenandoah string deduplication ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.inline.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupThread.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupThread.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_specialized_oop_closures.hpp ! src/share/vm/runtime/safepoint.cpp + test/gc/shenandoah/ShenandoahStrDedupStress.java + test/gc/shenandoah/TestShenandoahStrDedup.java Changeset: e6dc99cf0689 Author: shade Date: 2018-05-22 11:55 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e6dc99cf0689 Fix build failure: signedness mismatch in assert Contributed-by: Michal Vala ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp Changeset: ba2e5ced6246 Author: shade Date: 2018-05-15 09:43 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ba2e5ced6246 [backport] Incorrect label for static heuristics ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp Changeset: e32e47644aeb Author: shade Date: 2018-05-16 08:44 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e32e47644aeb [backport] Rename "cancel_concgc" to "cancel_gc" ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: f6f0463ceb59 Author: shade Date: 2018-05-16 12:33 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f6f0463ceb59 [backport] Verifier should dump raw memory around the problematic oops ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp Changeset: ba6e199a5ad0 Author: rkennke Date: 2018-05-17 14:26 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ba6e199a5ad0 [backport] Move heuristics from ShCollectorPolicy to ShHeap ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: de3d6050869f Author: shade Date: 2018-05-18 15:05 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/de3d6050869f [backport] Rework GC degradation on allocation failure ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/TEST.groups - test/gc/shenandoah/TestAllocLargeObjOOM.java - test/gc/shenandoah/TestAllocSmallObjOOM.java + test/gc/shenandoah/oom/TestAllocLargeObj.java + test/gc/shenandoah/oom/TestAllocLargerThanHeap.java + test/gc/shenandoah/oom/TestAllocSmallObj.java + test/gc/shenandoah/oom/TestThreadFailure.java Changeset: bb4300be39b8 Author: shade Date: 2018-05-18 16:23 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bb4300be39b8 [backport] Rework ClassUnloading* flags handling ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/runtime/arguments.cpp + test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/oom/TestThreadFailure.java + test/gc/shenandoah/options/TestClassUnloadingArguments.java Changeset: 6d58836434e1 Author: shade Date: 2018-05-22 10:39 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6d58836434e1 [backport] Check heap stability in C1 WBs ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp Changeset: 23c392b92047 Author: shade Date: 2018-05-23 12:30 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/23c392b92047 [backport] ClassUnloadingWithConcurrentMark should be opt-in with Shenandoah ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/options/TestClassUnloadingArguments.java Changeset: 3a80d0657805 Author: shade Date: 2018-05-30 18:40 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3a80d0657805 [backport] More verbose profiling for phase 4 in mark-compact ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: e890f70967e8 Author: shade Date: 2018-05-30 18:40 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e890f70967e8 [backport] Full GC always comes with liveness data ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 70caf9fd9e2e Author: shade Date: 2018-05-30 18:40 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/70caf9fd9e2e [backport] Recycle the regions only once ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: 186a1ec2ccfa Author: shade Date: 2018-05-30 18:40 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/186a1ec2ccfa [backport] Rename and move ShenandoahPrepareForMarkClosure ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: a8762d05922f Author: shade Date: 2018-05-31 12:29 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a8762d05922f [backport] Reclaim immediate garbage after mark-compact marking ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: c4a8dca64977 Author: shade Date: 2018-05-31 12:29 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c4a8dca64977 [backport] Shortcut regions that are known not to be alive ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: e3958d8666e1 Author: shade Date: 2018-05-31 12:29 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e3958d8666e1 [backport] Refactor and improve ShenandoahCodeRoots strategies ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 09236470632f Author: shade Date: 2018-05-31 12:29 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/09236470632f [backport] Default to ShenandoahCodeRootsStyle = 2 ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 66b9abd46320 Author: shade Date: 2018-06-04 12:51 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/66b9abd46320 Fix MacOS/Clang build failure ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: 524af70d122a Author: zgu Date: 2018-05-31 20:16 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/524af70d122a [backport] Fixed SA due to code refactoring and merging ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeap.java ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp Changeset: 3792fbac2c2f Author: zgu Date: 2018-06-01 15:18 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3792fbac2c2f [backport] Rearrange Shenandoah tests into 3 tiers ! test/TEST.groups Changeset: 0d5966ebdc69 Author: zgu Date: 2018-06-01 19:18 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0d5966ebdc69 [backport] Fix TestFullGCALot test failure ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp Changeset: b7403df4bcac Author: shade Date: 2018-06-04 12:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b7403df4bcac [backport] Resettable iterators to avoid dealing with copying/assignment compilation differences ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp Changeset: 54261fe77809 Author: rkennke Date: 2018-06-05 13:01 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/54261fe77809 [backport] Disable UseFastJNIAccessors for Shenandoah ! src/share/vm/runtime/arguments.cpp Changeset: a42f44a4d241 Author: zgu Date: 2018-06-05 14:55 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a42f44a4d241 [backport] Should cleanup previous/bad versions of redefined classes during full gc ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 67f4331357cf Author: zgu Date: 2018-06-05 19:29 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/67f4331357cf [backport] Including metaspace info when reporting heap info ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 538dd45f2012 Author: shade Date: 2018-06-11 13:54 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/538dd45f2012 [backport] Adaptive CSet selection selects excessively when memory is tight ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp Changeset: 480be328acda Author: shade Date: 2018-06-11 16:08 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/480be328acda [backport] Parallel +AlwaysPreTouch should run with max workers ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: aa57ebb64b85 Author: shade Date: 2018-06-12 17:16 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/aa57ebb64b85 [backport] Fix TestCommonGCLoads test ! test/gc/shenandoah/compiler/TestCommonGCLoads.java Changeset: 360f38ff60c0 Author: zgu Date: 2018-06-12 16:48 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/360f38ff60c0 [backport] Added logging for the number of workers used for GC cycles ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp Changeset: c3d5cb228132 Author: zgu Date: 2018-06-07 16:04 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c3d5cb228132 [backport] C1 shenandoah_wb expects obj in a register ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_LIRGenerator.hpp Changeset: b4e8f6b73f0c Author: rkennke Date: 2018-06-11 12:56 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b4e8f6b73f0c [backport] Some trivial-ish cleanups ! src/cpu/aarch64/vm/c1_MacroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/macroAssembler_aarch64.hpp ! src/cpu/x86/vm/c1_MacroAssembler_x86.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp Changeset: c7439bb8df07 Author: rkennke Date: 2018-06-11 13:57 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c7439bb8df07 [backport] Replace ShBarrierSet* casts with accessor ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp Changeset: 3b015c5e7a5e Author: shade Date: 2018-06-12 17:37 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3b015c5e7a5e [backport] Perform gc-state checks with LoadB to fit C2 matchers ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 037a851f18f0 Author: shade Date: 2018-06-13 12:52 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/037a851f18f0 [backport] Move (Java)Thread::_gc_state to lower offset to optimize barrier fast-path encoding ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 5b5a97b9eb9c Author: zgu Date: 2018-06-13 12:15 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5b5a97b9eb9c [backport] SH::make_(tlabs)_parsable() should work correctly with/without TLABs ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPrinter.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: dc08ab7cee20 Author: zgu Date: 2018-06-15 09:30 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dc08ab7cee20 [backport] Removed racy assertion ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp Changeset: a40c76605ac3 Author: shade Date: 2018-06-15 15:39 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a40c76605ac3 [backport] AlwaysPreTouch fails with non-default ConcGCThreads ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.cpp ! test/gc/shenandoah/options/AlwaysPreTouch.java Changeset: 50356a470d91 Author: shade Date: 2018-06-18 15:39 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/50356a470d91 [backport] Improve scheduling and interleaving of SATB processing in mark loop ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp Changeset: 169ff39d687e Author: shade Date: 2018-06-18 17:03 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/169ff39d687e [backport] Apply ShenandoahEvacOOMScope only for evac-taking paths in ShenandoahBarrierSet ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp Changeset: 7fd7f29c9f06 Author: shade Date: 2018-06-18 18:31 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7fd7f29c9f06 [backport] Replace risky SBS::need_update_refs_barrier with straightforward check ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: f1e9bb02d59f Author: shade Date: 2018-06-19 10:45 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f1e9bb02d59f [backport] Pre-filter oops before enqueing them in SBS slowpaths ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp Changeset: b51c5aff5f1e Author: shade Date: 2018-06-19 17:37 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b51c5aff5f1e [backport] SATB buffer filtering/compaction hides unmarked objects until final-mark ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 2c7235dd26f3 Author: rkennke Date: 2018-06-19 19:18 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2c7235dd26f3 [backport] Process remaining SATB buffers in final mark/traverse loop instead of separate phase ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp Changeset: 018fa42427ba Author: shade Date: 2018-06-20 13:23 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/018fa42427ba [backport] Skip RESOLVE in SATBBufferClosure if no forwarded objects are in heap ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp Changeset: a3879dd57cb1 Author: zgu Date: 2018-06-20 09:45 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a3879dd57cb1 [backport] VSC++ requires space(s) in between two string literals ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPrinter.cpp Changeset: 3f66460ad71a Author: shade Date: 2018-06-20 16:05 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3f66460ad71a [backport] Missing Shenandoah entry in GCNameHelper::to_string Contributed-by: Joshua Matsuoka ! src/share/vm/gc_interface/gcName.hpp Changeset: 171cc0828283 Author: shade Date: 2018-06-26 15:49 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/171cc0828283 [backport] CollectedHeap::max_tlab_size is measured in words ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: a566db9dd9b5 Author: shade Date: 2018-06-26 18:43 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a566db9dd9b5 [backport] Make in-cset checks use signed bytes to match C2 better ! src/share/vm/opto/shenandoahSupport.cpp Changeset: eeea08644036 Author: rkennke Date: 2018-06-26 20:37 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/eeea08644036 [backport] Constify ShHeapRegionSet and ShCollectionSet ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.inline.hpp Changeset: c3816ebfd969 Author: shade Date: 2018-07-03 08:48 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c3816ebfd969 [backport] Application pacing precision fixes ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.inline.hpp Changeset: ab4d0196f368 Author: shade Date: 2018-07-03 09:46 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ab4d0196f368 [backport] Adaptive CSet selection overshoots max-CSet ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp Changeset: 8553165378af Author: shade Date: 2018-07-03 19:05 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8553165378af [backport] StringInternCleanup times out ! test/gc/shenandoah/acceptance/StringInternCleanup.java Changeset: 55e7e748873a Author: zgu Date: 2018-07-03 14:43 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/55e7e748873a [backport] Wrap worker id in thread local worker session ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 72b4e300e8bc Author: shade Date: 2018-07-05 08:33 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/72b4e300e8bc [backport] Non-cancellable mark loops should have sensible stride ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: 1f826c5d8e2e Author: shade Date: 2018-07-05 10:57 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1f826c5d8e2e [backport] Forceful SATB buffer flushes should be time-periodic, not traffic-dependent ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/satbQueue.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 8473633aec65 Author: shade Date: 2018-07-05 19:55 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8473633aec65 [backport] Verify global and local gc-state status ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: db70e82d399a Author: shade Date: 2018-07-05 19:59 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/db70e82d399a [backport] Full GC should not always update references ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: cf665841d51d Author: rkennke Date: 2018-07-06 18:07 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cf665841d51d [backport] Remove safe_equals() ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp ! src/share/vm/memory/barrierSet.cpp ! src/share/vm/memory/barrierSet.hpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/referenceProcessor.hpp ! src/share/vm/oops/oop.hpp Changeset: 26d76e140903 Author: shade Date: 2018-07-06 19:11 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/26d76e140903 [backport] Concurrent uncommit should be recorded as GC event ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: 097a90534f10 Author: shade Date: 2018-07-06 19:22 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/097a90534f10 [backport] Uncommit should relinquish the heap lock regularly ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 733b4a5b6491 Author: shade Date: 2018-07-09 10:35 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/733b4a5b6491 [backport] Cleanup UseShenandoahOWST blocks ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: 12e1a25a9e25 Author: rkennke Date: 2018-07-09 20:21 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/12e1a25a9e25 [backport] Micro-optimize AArch64 assembly write-barriers ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp Changeset: d05b9181b6ab Author: rkennke Date: 2018-07-10 11:01 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d05b9181b6ab [backport] Remove C2 write-barrier from .ad files ! src/cpu/aarch64/vm/aarch64.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/opto/compile.cpp Changeset: 16c076a34521 Author: shade Date: 2018-07-10 11:05 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/16c076a34521 [backport] Assembler write barriers should consistently check for forwarded objects ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp ! src/cpu/aarch64/vm/shenandoahBarrierSet_aarch64.cpp ! src/cpu/x86/vm/macroAssembler_x86.cpp ! src/cpu/x86/vm/shenandoahBarrierSet_x86.cpp Changeset: ac8cd7b870ea Author: shade Date: 2018-07-11 09:43 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ac8cd7b870ea [backport] Exponential backoff with pacing ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: 026d01a4784e Author: shade Date: 2018-07-11 10:23 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/026d01a4784e [backport] More detailed pacing histogram ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: 3ed1de9f791f Author: shade Date: 2018-07-11 12:34 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3ed1de9f791f [backport] Proper units for allocation failure messages ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp Changeset: ca91928ba89a Author: zgu Date: 2018-07-12 11:19 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ca91928ba89a [backport] Add task termination and enhanced task queue state tracking + weakrefs ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 6c446082ccf2 Author: shade Date: 2018-07-13 08:47 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6c446082ccf2 [backport] Report actual free size in non-verbose FreeSet status ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp Changeset: c636d593d3d6 Author: shade Date: 2018-07-13 08:47 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c636d593d3d6 [backport] Pacer for evacuation should print "Avail" to capture discounting ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: 42c421089763 Author: shade Date: 2018-07-13 08:47 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/42c421089763 [backport] Refactor allocation path to accept ShenandoahAllocRequest tuple ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: d8aaa7e89f47 Author: shade Date: 2018-07-13 08:48 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d8aaa7e89f47 [backport] Elastic TLABs support for Shenandoah ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp + test/gc/shenandoah/TestElasticTLAB.java Changeset: 6b0e058ada63 Author: shade Date: 2018-07-13 08:48 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6b0e058ada63 [backport] Pacer should account actual size for elastic TLABs ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp Changeset: 20e837221fb8 Author: shade Date: 2018-07-13 10:09 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/20e837221fb8 [backport] Heap region count selection should only consider max heap size ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp Changeset: d46c965e0919 Author: rkennke Date: 2018-07-13 13:52 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d46c965e0919 [backport] Fix CAS-obj predicates and add expected-null-versions for cmpxchg-narrow-oop ! src/cpu/x86/vm/x86_64.ad Changeset: eefe7b148097 Author: shade Date: 2018-07-13 16:08 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/eefe7b148097 [backport] Hook up GCLABs to Elastic LAB support ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: c575da409459 Author: shade Date: 2018-07-13 17:08 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c575da409459 [backport] Allocation tracker should really report bytes ! src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.cpp Changeset: 1e3ae645749b Author: shade Date: 2018-07-13 21:14 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1e3ae645749b [backport] Complete liveness for recently allocated regions outside the allocation path ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: ffc1873f9489 Author: shade Date: 2018-07-16 13:21 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ffc1873f9489 [backport] GCLAB slowpath allocations should fit the object into GCLAB ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 2fc6dd34fa6d Author: roland Date: 2018-07-12 15:42 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2fc6dd34fa6d [backport] Fix aarch64 CAS predicates ! src/cpu/aarch64/vm/aarch64.ad Changeset: c338a0e3432b Author: zgu Date: 2018-07-16 11:57 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c338a0e3432b [backport] Print task queue statistics at the end of GC cycle ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: f5483650400b Author: shade Date: 2018-07-18 11:42 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f5483650400b Fix x86_32 build ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: 7e8c811c3fec Author: shade Date: 2018-07-17 18:29 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7e8c811c3fec [backport] Trace and report total allocation latency and sizes ! src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.cpp ! src/share/vm/utilities/numberSeq.cpp ! src/share/vm/utilities/numberSeq.hpp Changeset: 5ae1fac8b863 Author: shade Date: 2018-07-17 18:29 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5ae1fac8b863 [backport] -XX:-UseTLAB should disable GCLABs too ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: ff24d8e34ad3 Author: zgu Date: 2018-07-17 15:37 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ff24d8e34ad3 [backport] Refactoring ShenandoahStrDedupStress test to reduce test time ! test/gc/shenandoah/ShenandoahStrDedupStress.java Changeset: dcabf4c48b75 Author: shade Date: 2018-07-18 19:49 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dcabf4c48b75 [backport] Traversal should resize TLABs ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 13fb189d3d24 Author: rkennke Date: 2018-07-19 11:00 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/13fb189d3d24 [backport] Refactor to group marking bitmap and TAMS structure in one class ShenandoahMarkingContext ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPrinter.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: a9634f29b253 Author: rkennke Date: 2018-07-19 11:11 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a9634f29b253 [backport] Refactor alive-closures to deal better with new marking contexts ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: b1ab2c8bb5a7 Author: rkennke Date: 2018-07-19 11:18 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b1ab2c8bb5a7 [backport] Avoid indirection to next-mark-context ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.hpp Changeset: 92a6733b016a Author: shade Date: 2018-07-19 12:19 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/92a6733b016a [backport] TLAB sizing policy should converge faster with Shenandoah ! src/share/vm/runtime/arguments.cpp Changeset: 7d6b0f4e488a Author: zgu Date: 2018-07-20 06:40 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7d6b0f4e488a [backport] Move periodic GC decision making to GC heuristics base class ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: fab1d35f28c6 Author: shade Date: 2018-07-26 12:06 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fab1d35f28c6 [backport] Handle missing ShenandoahWriteBarrierRB case ! src/share/vm/opto/shenandoahSupport.cpp Changeset: 97fe84cfe336 Author: zgu Date: 2018-07-27 13:18 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/97fe84cfe336 [backport] Move Shenandoah stress tests to tier3 ! test/TEST.groups Changeset: 83f5a5c452ae Author: shade Date: 2018-07-31 14:24 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/83f5a5c452ae [backport] Refactor gc+init logging ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: 3363ab74ca91 Author: shade Date: 2018-08-01 16:05 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3363ab74ca91 [backport] Check and ensure that Shenandoah-enabled compilations succeed * * * [backport] Filter out not compilable methods to avoid false assertion ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/runtime/arguments.cpp Changeset: e99521a71df5 Author: shade Date: 2018-08-02 19:45 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e99521a71df5 [backport] Purge support for ShenandoahConcurrentEvacCodeRoots and ShenandoahBarriersForConst ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/opto/addnode.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/shenandoahSupport.cpp ! src/share/vm/opto/shenandoahSupport.hpp ! src/share/vm/runtime/arguments.cpp Changeset: 8040e3b751af Author: zgu Date: 2018-08-03 20:05 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8040e3b751af [backport] Fix TestGCThreadGroups test ! test/gc/shenandoah/TestGCThreadGroups.java Changeset: 4eff0bd87f73 Author: shade Date: 2018-08-06 16:49 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4eff0bd87f73 [backport] Explicit GC should actually uncommit the heap ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp Changeset: 8952977d08a7 Author: shade Date: 2018-08-13 12:49 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8952977d08a7 [backport] Fix Minimal and Zero builds ! src/share/vm/compiler/compileBroker.cpp ! src/share/vm/runtime/arguments.cpp Changeset: d305c31da9f5 Author: shade Date: 2018-08-15 09:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d305c31da9f5 Move JNI Weak References workaround to Shenandoah-specific root processor ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/memory/referenceProcessor.cpp ! test/gc/shenandoah/jni/TestJNIGlobalRefs.sh Changeset: 30ac9ae812bf Author: rkennke Date: 2018-08-10 18:54 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/30ac9ae812bf [backport] Split write barrier paths for mutator and GC workers ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp Changeset: 26552ed3792c Author: roland Date: 2018-08-13 17:55 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/26552ed3792c [backport] clean up obsolete c2 code - barriers are never added on constant oops - write barriers are always expanded to IR ! src/share/vm/opto/callGenerator.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/stringopts.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp Changeset: 2990ea4a56ad Author: shade Date: 2018-08-14 09:53 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2990ea4a56ad [backport] WB slowpath should assist with evacuation of adjacent objects ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 84579da2e30e Author: shade Date: 2018-08-14 18:35 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/84579da2e30e [backport] Report heap region stats in proper units ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp Changeset: b77b958899f3 Author: zgu Date: 2018-08-14 20:24 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b77b958899f3 [backport] Shenandoah changes to allow enabling -Wreorder ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkGroup.cpp Changeset: 5f95913d80e6 Author: shade Date: 2018-08-14 10:47 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5f95913d80e6 [backport] Convert magic value to ShenandoahPacingSurcharge ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: e80b99e2c947 Author: zgu Date: 2018-08-17 08:20 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e80b99e2c947 [backport] Trivial enhancement to avoid costly deletion array element ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp Changeset: 9acabeeec666 Author: shade Date: 2018-08-23 11:22 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9acabeeec666 [backport] Shenandoah/PPC barrier stubs ! make/excludeSrc.make + src/cpu/ppc/vm/shenandoahBarrierSet_ppc.cpp Changeset: 16b654667f9f Author: shade Date: 2018-08-23 11:33 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/16b654667f9f Cleanup undeclared methods in barrier stubs ! src/cpu/sparc/vm/shenandoahBarrierSet_sparc.cpp ! src/cpu/zero/vm/shenandoahBarrierSet_zero.cpp Changeset: 410667acba92 Author: shade Date: 2018-08-23 18:28 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/410667acba92 Disable evac assist by default until bugfixes arrive ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 22655cbc0569 Author: shade Date: 2018-08-21 19:35 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/22655cbc0569 [backport] Comprehensible GC trigger logging ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! test/gc/shenandoah/TestPeriodicGC.java Changeset: f43806fb055a Author: shade Date: 2018-08-22 11:24 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f43806fb055a [backport] Fix ShHeap::notify_alloc usages: it accepts words, not bytes ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 41eb4e2dbbf7 Author: shade Date: 2018-08-22 12:32 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/41eb4e2dbbf7 [backport] Adaptive/Traversal heuristics rewrite for allocation rate ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 5900fc6d8b63 Author: shade Date: 2018-08-23 10:42 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5900fc6d8b63 [backport] Remove ShHeuristics::print_threshold ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: b90bef764aa8 Author: shade Date: 2018-08-23 10:59 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b90bef764aa8 [backport] Avoid using uintx in ShenandoahHeapRegion ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp Changeset: 95a43f78892b Author: shade Date: 2018-08-23 21:21 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/95a43f78892b [backport] shenandoah_assert_correct should check object/forwardee klasses ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp Changeset: 7f1734fa208d Author: shade Date: 2018-08-23 21:22 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7f1734fa208d [backport] Evac assist should touch marked objects only ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: d24d73c582fc Author: zgu Date: 2018-08-27 09:55 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d24d73c582fc [backport] GC trace messages have to be immortal ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 0d4e05e1bc08 Author: zgu Date: 2018-08-27 12:51 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0d4e05e1bc08 [backport] Wiring GC events to JFR + Restore heap occupancy in GC logs after JFR changes ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp Changeset: d03e75c53066 Author: shade Date: 2018-08-27 18:57 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d03e75c53066 [backport] Remove obsolete/unused logging usages ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: 9c478fef5c94 Author: shade Date: 2018-08-27 18:57 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9c478fef5c94 [backport] Replace custom asserts with shenandoah_assert_* ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp Changeset: d074aee6ab0b Author: zgu Date: 2018-08-28 07:58 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d074aee6ab0b [backport] Wiring heap and metaspace info to JFR ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: 77f07e1c777f Author: shade Date: 2018-08-29 10:09 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/77f07e1c777f [backport] Out-of-cycle Degenerated GC should process references and unload classes ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 5ffa756eea1d Author: shade Date: 2018-08-31 10:14 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5ffa756eea1d [backport] Off-by-one error in degen progress calculation ! src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.cpp Changeset: de2efdd8c4fb Author: shade Date: 2018-08-31 16:40 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/de2efdd8c4fb [backport] Only Java and GC worker threads should get GCLABs ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/runtime/thread.hpp Changeset: 8ac668a22cd7 Author: shade Date: 2018-09-01 12:26 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8ac668a22cd7 [backport] Move ParallelCodeIterator to ShenandoahCodeRoots ! src/share/vm/code/codeCache.cpp ! src/share/vm/code/codeCache.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp Changeset: e910700b2abb Author: shade Date: 2018-09-01 17:09 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e910700b2abb [backport] Evac reserve: make sure GC has untouchable space to move the objects into ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 3c4ff3051dcf Author: shade Date: 2018-09-01 17:09 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3c4ff3051dcf [backport] Refactor FreeSet logging: support evac-reserve, denser printouts ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp Changeset: 553b1f593e4f Author: shade Date: 2018-09-03 11:27 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/553b1f593e4f [backport] Enable ShenandoahEvacReserveOverflow by default ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 71d6f06ea07b Author: zgu Date: 2018-09-04 20:50 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/71d6f06ea07b JDK8u: Silence compilation warnings on implicit type conversion ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp Changeset: 784733f7010a Author: shade Date: 2018-09-08 12:21 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/784733f7010a [backport] Allocation path should not touch GC barriers for metadata ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp Changeset: d1c0985fae9b Author: shade Date: 2018-09-03 20:24 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d1c0985fae9b [backport] Soft refs should be purged reliably on allocation failure, or with compact heuristics ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 748086632b1d Author: shade Date: 2018-09-04 12:01 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/748086632b1d [backport] shenandoah_assert_correct should verify classes before claiming _safe_oop ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp Changeset: 072c85b879f9 Author: shade Date: 2018-09-04 12:08 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/072c85b879f9 [backport] Tests should use -XX:+ShenandoahVerify in some OOM-evac configurations ! test/gc/shenandoah/acceptance/AllocHumongousFragment.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java Changeset: 2acd10816d9b Author: shade Date: 2018-09-04 12:08 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2acd10816d9b [backport] Degenerated evacuation ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp Changeset: 65c14af937df Author: shade Date: 2018-09-04 17:11 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/65c14af937df [backport] Soft-refs policy needs reliable heap usage data after the GC cycle ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 1d075673f63b Author: shade Date: 2018-09-05 10:20 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1d075673f63b [backport] Unreachable assert in ShenandoahCodeRoots::acquire_lock ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp Changeset: 39e270bcdaec Author: shade Date: 2018-09-05 10:20 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/39e270bcdaec [backport] Prune undefined and unused methods ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: 10a7c86c547b Author: shade Date: 2018-09-06 12:44 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/10a7c86c547b [backport] Passive heuristics should enter degen GC, not full GC ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp ! test/gc/shenandoah/CriticalNativeArgs.sh ! test/gc/shenandoah/CriticalNativeStress.sh ! test/gc/shenandoah/LotsOfCycles.java ! test/gc/shenandoah/PinnedGarbage.sh ! test/gc/shenandoah/ShenandoahStrDedupStress.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestShenandoahStrDedup.java ! test/gc/shenandoah/acceptance/AllocHumongousFragment.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/SieveObjects.java ! test/gc/shenandoah/acceptance/StringInternCleanup.java ! test/gc/shenandoah/acceptance/VerifyJCStressTest.java ! test/gc/shenandoah/mxbeans/ChurnNotifications.java ! test/gc/shenandoah/mxbeans/PauseNotifications.java Changeset: 8ec6975cf6e0 Author: shade Date: 2018-09-06 12:44 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8ec6975cf6e0 [backport] Reshuffle tests: verify STW GC is working first, then verify under aggressive, then the rest ! test/gc/shenandoah/CriticalNativeArgs.sh ! test/gc/shenandoah/CriticalNativeStress.sh ! test/gc/shenandoah/LotsOfCycles.java ! test/gc/shenandoah/PinnedGarbage.sh ! test/gc/shenandoah/TestShenandoahStrDedup.java ! test/gc/shenandoah/acceptance/AllocHumongousFragment.java ! test/gc/shenandoah/acceptance/AllocIntArrays.java ! test/gc/shenandoah/acceptance/AllocObjectArrays.java ! test/gc/shenandoah/acceptance/AllocObjects.java ! test/gc/shenandoah/acceptance/HeapUncommit.java ! test/gc/shenandoah/acceptance/RetainObjects.java ! test/gc/shenandoah/acceptance/SieveObjects.java ! test/gc/shenandoah/acceptance/StringInternCleanup.java ! test/gc/shenandoah/mxbeans/ChurnNotifications.java ! test/gc/shenandoah/mxbeans/PauseNotifications.java Changeset: e29928837975 Author: shade Date: 2018-09-06 13:25 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e29928837975 [backport] TestHeapDump runs much faster with small heap ! test/gc/shenandoah/jvmti/TestHeapDump.sh Changeset: 0729a56f09bc Author: zgu Date: 2018-09-07 12:56 -0400 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0729a56f09bc [backport] Cleanup: remove unused root processor's sub tasks ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: 90082964ebbf Author: shade Date: 2018-09-08 16:53 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/90082964ebbf [backport] EvilSyncBug test is too slow ! test/gc/shenandoah/EvilSyncBug.java Changeset: 199b82c9b89e Author: shade Date: 2018-09-10 12:38 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/199b82c9b89e [backport] Purge partial heuristics and connection matrix infrastructure ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: dba8871f90b6 Author: shade Date: 2018-09-10 17:56 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dba8871f90b6 [backport] Remove NMethodSizeLimit adjustment for Shenandoah ! src/share/vm/runtime/arguments.cpp From roman at kennke.org Thu Sep 20 09:40:25 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 20 Sep 2018 09:40:25 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset bb1f024c5025 Message-ID: <201809200940.w8K9ePaB006640@aojmv0008.oracle.com> Changeset: 3785fc91e325 Author: rkennke Date: 2018-09-20 11:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/3785fc91e325 Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset bb1f024c5025 ! .hgtags From roman at kennke.org Thu Sep 20 09:40:22 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 20 Sep 2018 09:40:22 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 5a336d0329c7 Message-ID: <201809200940.w8K9eMQc006504@aojmv0008.oracle.com> Changeset: 465f1a149e91 Author: rkennke Date: 2018-09-20 11:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/465f1a149e91 Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 5a336d0329c7 ! .hgtags From roman at kennke.org Thu Sep 20 09:40:24 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 20 Sep 2018 09:40:24 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 7d6409b7ef69 Message-ID: <201809200940.w8K9eOVE006604@aojmv0008.oracle.com> Changeset: 79f802c16d2d Author: rkennke Date: 2018-09-20 11:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/79f802c16d2d Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 7d6409b7ef69 ! .hgtags From roman at kennke.org Thu Sep 20 09:40:26 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 20 Sep 2018 09:40:26 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 9a88ca177804 Message-ID: <201809200940.w8K9eQA3006723@aojmv0008.oracle.com> Changeset: c68865c20c47 Author: rkennke Date: 2018-09-20 11:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/c68865c20c47 Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 9a88ca177804 ! .hgtags From roman at kennke.org Thu Sep 20 09:40:27 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 20 Sep 2018 09:40:27 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 34e403b57b17 Message-ID: <201809200940.w8K9eSVU006776@aojmv0008.oracle.com> Changeset: e3c6e09b6571 Author: rkennke Date: 2018-09-20 11:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/e3c6e09b6571 Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 34e403b57b17 ! .hgtags From roman at kennke.org Thu Sep 20 09:40:29 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 20 Sep 2018 09:40:29 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset dba8871f90b6 Message-ID: <201809200940.w8K9eUQ2006917@aojmv0008.oracle.com> Changeset: d9f40dc95411 Author: rkennke Date: 2018-09-20 11:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d9f40dc95411 Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset dba8871f90b6 ! .hgtags From roman at kennke.org Thu Sep 20 09:40:31 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 20 Sep 2018 09:40:31 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 1dadd03443c5 Message-ID: <201809200940.w8K9eVwj006949@aojmv0008.oracle.com> Changeset: afa3430ceb4a Author: rkennke Date: 2018-09-20 11:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/afa3430ceb4a Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 1dadd03443c5 ! .hgtags From roman at kennke.org Thu Sep 20 09:40:32 2018 From: roman at kennke.org (roman at kennke.org) Date: Thu, 20 Sep 2018 09:40:32 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 6fdff55d120d Message-ID: <201809200940.w8K9eWbL006955@aojmv0008.oracle.com> Changeset: 513d3f8a2b9c Author: rkennke Date: 2018-09-20 11:41 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/513d3f8a2b9c Added tag aarch64-shenandoah-jdk8u181-b15-shenandoah-merge-2018-09-19 for changeset 6fdff55d120d ! .hgtags From simon at cjnash.com Thu Sep 20 11:48:48 2018 From: simon at cjnash.com (Simon Nash) Date: Thu, 20 Sep 2018 12:48:48 +0100 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> Message-ID: <5BA38920.8020203@cjnash.com> On 19/09/2018 07:44, David Holmes wrote: > Hi Bob, > > On 18/09/2018 11:17 PM, Bob Vandette wrote: >> I only did some basic testing of the hard-float abi. Bell SW has >> offered to do more extensive testing >> as part of this JEP. >> >> I have no way of knowing if any of the other profiles are being used >> but I would think it?s >> worth keeping them in the event that someone wants to try to >> build/test these other configurations. >> >> The goal of this JEP is to eliminate the arm64 port and not cause any >> other changes in behavior. > > Sorry I was under the mistaken impression that all of the Oracle ARM > port was being removed, but it is only the 64-bit part. > > That said it would concern me greatly if people are still building for > anything older than ARMv7 with MP support! The work I'm doing to always > act as-if MP is not only potentially inefficient on a uniprocessor, but > for ARM variants without MP support, potentially it won't even run if > instructions don't exist. I need to look into this further. > > Thanks, > David > David, My build for arm-sflt needs to run on ARMv5 uniprocessor maschines and my build for arm-vfp-hflt needs to run on ARMv7 uniprocessor machines. Is the work you are doing that could cause problems with this included in JDK11 or just JDK12? Simon >> Bob. >> >> >>> On Sep 17, 2018, at 10:53 PM, David Holmes >>> wrote: >>> >>> Hi Bob, >>> >>> On 18/09/2018 2:20 AM, Bob Vandette wrote: >>>> Please review the changes related to JEP 340 which remove the second >>>> 64-bit ARM port >>>> from the JDK. >>>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>>> I?ve testing building the remaining 32 and 64 bit ARM ports >>>> including the minimal, client and server VMs. >>>> I?ve run specJVM98 on the three 32-bit ARM VMs. >>> >>> Did you test all the ARM related abi-profiles? It seems to me they >>> were only for Oracle's ARM32 port and may have never been used >>> otherwise. I would have expected all that stuff to be removed. >>> >>> Cheers, >>> David >>> >>>> I also verified that Linux x64 builds. >>>> Bob. >> > From shade at redhat.com Thu Sep 20 12:50:10 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Sep 2018 14:50:10 +0200 Subject: [aarch64-port-dev ] RFR: Fix code differences against shenandoah/jdk8u Message-ID: http://cr.openjdk.java.net/~shade/shenandoah/aarch64-sync-1/webrev.01/ After recent push to aarch64-port/shenandoah-8u, I diff'ed the hotspot repositories, and these are the differences between out development shenandoah/jdk8u and aarch64-port/shenandoah-8u. After applying this patch, there are no differences anymore. History: *) src/share/vm/opto/library_call.cpp: this is whitespace difference that was left over after Shenandoah barriers addition. Upstream does not have these newlines. *) src/share/vm/opto/phaseX.cpp: webrev would show "if (m_op == Op_CmpI)" block was moved, but int fact it is Shenandoah-specific "if (m->is_ShenandoahBarrier())" block swapped places -- the webrev tool minimized the change showing the smaller block as diff. It is probably an innocuous difference, but difference nevertheless. The block was misplaced by earlier merge here: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/diff/21088d271abb/src/share/vm/opto/phaseX.cpp *) src/share/vm/prims/jni.cpp: this seems to be the confusion between multiple merges. The barrier story around JNI accesses is complicated, and I am not sure sh/jdk gets it correctly. Still, it is better to sync up the two, so fixes from sh/jdk8u proliferate in due course. Testing: tier3_gc_shenandoah {release|fastdebug} Thanks, -Aleksey From rkennke at redhat.com Thu Sep 20 13:45:33 2018 From: rkennke at redhat.com (Roman Kennke) Date: Thu, 20 Sep 2018 15:45:33 +0200 Subject: [aarch64-port-dev ] RFR: Fix code differences against shenandoah/jdk8u In-Reply-To: References: Message-ID: <0c8cbf95-2ca9-9af9-8082-622e12f35b87@redhat.com> Am 20.09.2018 um 14:50 schrieb Aleksey Shipilev: > http://cr.openjdk.java.net/~shade/shenandoah/aarch64-sync-1/webrev.01/ > > After recent push to aarch64-port/shenandoah-8u, I diff'ed the hotspot repositories, and these are > the differences between out development shenandoah/jdk8u and aarch64-port/shenandoah-8u. After > applying this patch, there are no differences anymore. > > History: > > *) src/share/vm/opto/library_call.cpp: this is whitespace difference that was left over after > Shenandoah barriers addition. Upstream does not have these newlines. > > *) src/share/vm/opto/phaseX.cpp: webrev would show "if (m_op == Op_CmpI)" block was moved, but int > fact it is Shenandoah-specific "if (m->is_ShenandoahBarrier())" block swapped places -- the webrev > tool minimized the change showing the smaller block as diff. It is probably an innocuous difference, > but difference nevertheless. The block was misplaced by earlier merge here: > > http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/diff/21088d271abb/src/share/vm/opto/phaseX.cpp > > *) src/share/vm/prims/jni.cpp: this seems to be the confusion between multiple merges. The barrier > story around JNI accesses is complicated, and I am not sure sh/jdk gets it correctly. Still, it is > better to sync up the two, so fixes from sh/jdk8u proliferate in due course. > > Testing: tier3_gc_shenandoah {release|fastdebug} > > Thanks, > -Aleksey > Looks good. Roman From shade at redhat.com Thu Sep 20 14:11:32 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Sep 2018 16:11:32 +0200 Subject: [aarch64-port-dev ] RFR: Fix code differences against shenandoah/jdk8u In-Reply-To: <0c8cbf95-2ca9-9af9-8082-622e12f35b87@redhat.com> References: <0c8cbf95-2ca9-9af9-8082-622e12f35b87@redhat.com> Message-ID: On 09/20/2018 03:45 PM, Roman Kennke wrote: > Am 20.09.2018 um 14:50 schrieb Aleksey Shipilev: >> http://cr.openjdk.java.net/~shade/shenandoah/aarch64-sync-1/webrev.01/ >> > Looks good. Thanks. I'd like Andrew Hughes to ack this too :) -Aleksey From dmitrij.pochepko at bell-sw.com Thu Sep 20 17:27:28 2018 From: dmitrij.pochepko at bell-sw.com (Dmitrij Pochepko) Date: Thu, 20 Sep 2018 20:27:28 +0300 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> Message-ID: <2aff2d56-4126-5fdb-ece5-68324f974f8c@bell-sw.com> On 14/09/18 18:29, Andrew Dinn wrote: > On 13/09/18 15:35, Dmitrij Pochepko wrote: >> Other comments seems fine > I am glad to hear that you did not find any errors in my analysis. > However, I also need to ask you to answer a question that was implicit > in my earlier note. I said: > > "I assume you are familiar with the relevant mathematics and how it has > been used to derive the algorithm. If so then I would like you to review > this rewrite and ensure that there are nor mathematical errors in it. I > would also like you to check that the explanatory comments for of the > individual steps in the algorithm do not contain any errors. > > If you are not familiar with the mathematics then please let me know. I > need to know whether this has been reviewed by someone competent to do so." > > As you didn't respond to this I will have to ask you explicitly this > time. Do you have a background in mathematics and numerical analysis > that means you understand how the original algorithm has been arrived > at? equally, how your algorithm may legitimately vary from that original? ?Yes, I do have relevant background in mathematics. And yes to the questions below but for the latest. That said, it's always good to have another pair of eyes looking at the review. To be honest, I had to refresh my memory regarding Remez polynomials. > > I'll break this down into several steps: > > Do you understand the (elementary) theory that explains how the various > polynomial expansions I described in my comments converge to the > original log and exp functions? > > Do you understand the theory that explains how partial polynomial sums > (Remez polynomials) can be used used to approximate these polynomial > expansions within specified ranges? > > Do you know how the coefficients of these Remez polynomial can be > derived to any necessary accuracy? > > Do you understand how the computation of the values of those Remez > polynomials must proceed in order to guarantee accuracy in the computed > result in the presence of rounding errors? > > Can you provide a mathematical proof that the variations you have > introduced into the computational process (specifially the move from > Horner form to Estrin form) will not introduce rounding errors? I have formal verification for some arguments ranges that I considered the most problematic, but the complete proof is too complicated. Looking at the situation from reviewer side I understand why it'll be safer and easier to maintain to have assembly version duplicate the original fdlibm code and because of that I suggest to revert questionable places to original schemas as the performance improvement is not that big. new webrev with polynomial calculations changed back to original schema. Also changed scalbn implementation to be the same as original: http://cr.openjdk.java.net/~dpochepk/8189107/webrev.03/ As expected, it's about 2% slower. Thanks, Dmitrij > > I certainly cannot lay claim to a /thorough/ understanding of most, if > not all, those topics. If you also cannot then I think we need to bring > in someone who does. In particular, it is the last point that matters > most of all here as this is where you have /chosen/ to make your > algorithm diverge from the code you inherited. > > As regards the rest of the background maths, we do at least know that > the other aspects of the algorithm -- in its original manifestation -- > have been checked by numerical experts. Hence, if we ensure that your > algorithm implements /equivalent/ steps then it ought to inherit the > same guarantees of correctness. So, the only task as far as most of the > code is concerned is to iron out any errors you might inadvertently have > introduced. I have several nits to pick in that regard that which I will > be posting shortly. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Thu Sep 20 17:34:14 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Sep 2018 18:34:14 +0100 Subject: [aarch64-port-dev ] Math.log intrinsic gives incorrect results Message-ID: <8cb4c4c6-2b86-fbae-318b-dedaa5f41b28@redhat.com> FYI: https://bugs.openjdk.java.net/browse/JDK-8210858 -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Sep 20 17:58:34 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Sep 2018 18:58:34 +0100 Subject: [aarch64-port-dev ] RFR(S): 8210413: AArch64: Optimize div/rem by constant in C1 In-Reply-To: References: <9645c210-3d87-52fa-8051-54dc60629866@redhat.com> Message-ID: <9d454f5b-475b-5713-7155-c6946f378c3e@redhat.com> On 09/20/2018 05:15 AM, Pengfei Li (Arm Technology China) wrote: > Please find below new patch that added the same optimization for longs as well as ints and also fixed an issue. > http://cr.openjdk.java.net/~yzhang/8210413/webrev.01/ > > Could you help look at it again? That's fine. I'm not exactly delighted by the amount of duplicated code for long and int, but it's very hard to avoid in this case. The patch is good for JDK/JDK. -- 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 Fri Sep 21 02:34:19 2018 From: david.holmes at oracle.com (David Holmes) Date: Thu, 20 Sep 2018 22:34:19 -0400 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <5BA38920.8020203@cjnash.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <6C784061-6256-4D40-BFB3-CA1ABB7F29EB@oracle.com> <5BA38920.8020203@cjnash.com> Message-ID: Hi Simon, On 20/09/2018 7:48 AM, Simon Nash wrote: > On 19/09/2018 07:44, David Holmes wrote: >> Hi Bob, >> >> On 18/09/2018 11:17 PM, Bob Vandette wrote: >>> I only did some basic testing of the hard-float abi.? Bell SW has >>> offered to do more extensive testing >>> as part of this JEP. >>> >>> I have no way of knowing if any of the other profiles are being used >>> but I would think it?s >>> worth keeping them in the event that someone wants to try to >>> build/test these other configurations. >>> >>> The goal of this JEP is to eliminate the arm64 port and not cause any >>> other changes in behavior. >> >> Sorry I was under the mistaken impression that all of the Oracle ARM >> port was being removed, but it is only the 64-bit part. >> >> That said it would concern me greatly if people are still building for >> anything older than ARMv7 with MP support! The work I'm doing to >> always act as-if MP is not only potentially inefficient on a >> uniprocessor, but for ARM variants without MP support, potentially it >> won't even run if instructions don't exist. I need to look into this >> further. >> >> Thanks, >> David >> > David, > My build for arm-sflt needs to run on ARMv5 uniprocessor maschines and > my build for arm-vfp-hflt needs to run on ARMv7 uniprocessor machines. > Is the work you are doing that could cause problems with this included > in JDK11 or just JDK12? This is for JDK 12. Of course the intent is to not cause problems for anyone. The changes aim at simplifying the code whilst marginally improving performance in the common case of a multi-processor system, at the expense of potentially decreasing performance for uniprocessors. Though as has been pointed out in my review thread, the existing use of AssumeMP (default true) will be causing the same performance changes and for spinlocks my changes will improve things for uniprocessors. My area of concern is where instructions issued for the MP case may not be valid on specific architectures. For example pldw is only available on ARMv7 with multi-processor extensions. I need to be sure, for example, only supported DMB/DSB variants are issued on ARMv5. Thanks, David > Simon > >>> Bob. >>> >>> >>>> On Sep 17, 2018, at 10:53 PM, David Holmes >>>> wrote: >>>> >>>> Hi Bob, >>>> >>>> On 18/09/2018 2:20 AM, Bob Vandette wrote: >>>>> Please review the changes related to JEP 340 which remove the >>>>> second 64-bit ARM port >>>>> from the JDK. >>>>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>>>> I?ve testing building the remaining 32 and 64 bit ARM ports >>>>> including the minimal, client and server VMs. >>>>> I?ve run specJVM98 on the three 32-bit ARM VMs. >>>> >>>> Did you test all the ARM related abi-profiles? It seems to me they >>>> were only for Oracle's ARM32 port and may have never been used >>>> otherwise. I would have expected all that stuff to be removed. >>>> >>>> Cheers, >>>> David >>>> >>>>> I also verified that Linux x64 builds. >>>>> Bob. >>> >> > From Pengfei.Li at arm.com Fri Sep 21 06:53:05 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Fri, 21 Sep 2018 06:53:05 +0000 Subject: [aarch64-port-dev ] RFR(S): 8210413: AArch64: Optimize div/rem by constant in C1 In-Reply-To: <9d454f5b-475b-5713-7155-c6946f378c3e@redhat.com> References: <9645c210-3d87-52fa-8051-54dc60629866@redhat.com> <9d454f5b-475b-5713-7155-c6946f378c3e@redhat.com> Message-ID: Thanks for your code review. Could you help push this patch? -- Thanks, Pengfei > -----Original Message----- > > On 09/20/2018 05:15 AM, Pengfei Li (Arm Technology China) wrote: > > Please find below new patch that added the same optimization for longs as > well as ints and also fixed an issue. > > http://cr.openjdk.java.net/~yzhang/8210413/webrev.01/ > > > > Could you help look at it again? > > That's fine. I'm not exactly delighted by the amount of duplicated code for > long and int, but it's very hard to avoid in this case. > The patch is good for JDK/JDK. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Sep 21 08:55:32 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 21 Sep 2018 09:55:32 +0100 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <2aff2d56-4126-5fdb-ece5-68324f974f8c@bell-sw.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> <2aff2d56-4126-5fdb-ece5-68324f974f8c@bell-sw.com> Message-ID: <7ca0112f-76f9-538d-f263-8199cbd380ab@redhat.com> On 20/09/18 18:27, Dmitrij Pochepko wrote: > On 14/09/18 18:29, Andrew Dinn wrote: > ?Yes, I do have relevant background in mathematics. And yes to the > questions below but for the latest. That said, it's always good to have > another pair of eyes looking at the review. To be honest, I had to > refresh my memory regarding Remez polynomials. Thank you for the confirmation. . . . >> Can you provide a mathematical proof that the variations you have >> introduced into the computational process (specifially the move from >> Horner form to Estrin form) will not introduce rounding errors? > I have formal verification for some arguments ranges that I considered > the most problematic, but the complete proof is too complicated. Looking > at the situation from reviewer side I understand why it'll be safer and > easier to maintain to have assembly version duplicate the original > fdlibm code and because of that I suggest to revert questionable places > to original schemas as the performance improvement is not that big. Ok, use of Horner form was one of the things I was going to ask you to restore. I did actually ask Joe Darcy about the use of Estrin form. If he can provide an argument that it is ok to employ it then we can think about reinstating the vector computation as an upgrade at a later date. I am not surprised its removal makes only a small difference, given how little of the computation it represents. > new webrev with polynomial calculations changed back to original schema. > Also changed scalbn implementation to be the same as original: > http://cr.openjdk.java.net/~dpochepk/8189107/webrev.03/ So, I guess that means you have now actually tested the underflow case? The previous scalbn implementation was one of two places in which the code was seriously broken. In consequence, all computations meant to generate underflowing results were not computed correctly. One of the things wrong in the previous scalbn implementation was the use of cmp rather than cmpw, an error which I see you have now fixed (there were 3 further mistakes in this section of the code). Your rewrite of the case handling looks complex and unnecessarily slow to me. I'll suggest a better fix in a review I am currently writing up. The other place where there was an error was in the Y_IS_HUGE branch. The vector maths code expects to load the first 4 table values in a permuted order (i.e. it assumes they are 0.25, -1/ln2, -0.333333, 0.5) but the corresponding constants in _pow_coef1 have not been permuted. Because of this all computations where 2^31 < y < 2^64 were not computed correctly. This error appears still to be present in the latest version of the code. So, I assume you have also never tested that range of values? For example, try x = 1.0000000001, y = (double)0x1_1000_0000L and compare the result with that obtained from the StrictMath routine. I did explicitly ask you to ensure that all paths through the code were tested in an earlier posting. Once I had read through and understood the code it took me about 2 minutes to produce a test program that exercised each of these 2 broken paths (and about 1/2 hour in gdb to detect and fix each problem). I'm very under-impressed that you did not bother to produce such tests as part of your test regime. These errors are not bizarre or unexpected corner cases. They are paths that can be expected to be taken during normal computations. Testing the code requires at the very least driving the code through such paths with suitable inputs and then ensuring the results are valid so you should really have looked for and found these bugs. Of course, testing also requires identifying and checking bizarre or unexpected corner cases. However, while it might be understandable if some of those latter cases were missed there is really no excuse for not checking the known, expected paths with at least some inputs. It's extremely unhelpful to those who have to maintain this code when a contributor takes the job of testing this lightly. Nor is such behaviour going to encourage anyone to accept further contributions. You can expect a full review of the code some time today (it will be based on the previous version so you will have to make allowance for the changes you have made in the latest version). There are only a few things I would like you to tweak in the sequence of generated instructions. However, you will need to do a lot of rework to make the generator code more systematic and more readable. That includes 1) introducing some block structure and local declarations to the generator code and 2) adopting a more coherent allocation of values to registers which reflects the naming and local usage of variables in the original algorithm. To simplify that task I will provide a revised algorithm that which faithfully reflects the structure of your generated code and clarifies its relation to the original. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Fri Sep 21 09:31:28 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Sep 2018 10:31:28 +0100 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <7ca0112f-76f9-538d-f263-8199cbd380ab@redhat.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> <2aff2d56-4126-5fdb-ece5-68324f974f8c@bell-sw.com> <7ca0112f-76f9-538d-f263-8199cbd380ab@redhat.com> Message-ID: On 09/21/2018 09:55 AM, Andrew Dinn wrote: > Ok, use of Horner form was one of the things I was going to ask you to > restore. I did actually ask Joe Darcy about the use of Estrin form. If > he can provide an argument that it is ok to employ it then we can think > about reinstating the vector computation as an upgrade at a later date. > I am not surprised its removal makes only a small difference, given how > little of the computation it represents. I've run the crlibm difficult rounding tests on the patch, with no regressions, so I'm pretty happy about using the Estrin form. Of course it's possible that there will be problems elsewhere, but it's not likely IMO. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From andrey.petushkov at gmail.com Fri Sep 21 11:02:26 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Fri, 21 Sep 2018 14:02:26 +0300 Subject: [aarch64-port-dev ] hotspot jtreg runtime/BoolReturn/JNIBooleanTest.java failure Message-ID: <493129BB-4BD9-4762-A2FE-E51B322EA6E5@gmail.com> Hi guys, Just wanted to ask whether you want this fixed in jdk11. Apparently now raw value of jboolean (i.e. u8) returned by JNI method fed into java code, where it?s treated in different way. (value != 0 vs bit0 != 0) Not sure if it is considered to be belonging to BBB domain or just a mere possibility of application developers to shoot themselves into foot. I?d fix it with proper value conversion at http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#l1925 If you?d like I can prepare a patch (although I assume unless it?s BBB-type thing it?s probably too late for jdk11) Regards, Andrey From aph at redhat.com Fri Sep 21 13:33:04 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Sep 2018 14:33:04 +0100 Subject: [aarch64-port-dev ] hotspot jtreg runtime/BoolReturn/JNIBooleanTest.java failure In-Reply-To: <493129BB-4BD9-4762-A2FE-E51B322EA6E5@gmail.com> References: <493129BB-4BD9-4762-A2FE-E51B322EA6E5@gmail.com> Message-ID: <742bbaa7-9648-a0d8-b176-926233dc87a0@redhat.com> On 09/21/2018 12:02 PM, Andrey Petushkov wrote: > Just wanted to ask whether you want this fixed in jdk11. Apparently > now raw value of jboolean (i.e. u8) returned by JNI method fed into > java code, where it?s treated in different way. (value != 0 vs bit0 > != 0) Not sure if it is considered to be belonging to BBB domain or > just a mere possibility of application developers to shoot > themselves into foot. I?d fix it with proper value conversion at > http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#l1925 > > If you?d like I can prepare a patch (although I assume unless it?s > BBB-type thing it?s probably too late for jdk11) It's been a bug for a long time. I guess the best fix is to define c2bool the same as x86 and use it in TemplateInterpreterGenerator::generate_result_handler_for and SharedRuntime::generate_native_wrapper. Mind you, that behaviour is very odd: ignore all but the bottom 8 bits of the result register and set the return value, i.e.: return (byte)result != 0 ? 1 : 0 I guess it makes sense, given that jbool is defined to be an unsigned 8-bit integer type. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Sep 21 13:55:22 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Sep 2018 14:55:22 +0100 Subject: [aarch64-port-dev ] hotspot jtreg runtime/BoolReturn/JNIBooleanTest.java failure In-Reply-To: <742bbaa7-9648-a0d8-b176-926233dc87a0@redhat.com> References: <493129BB-4BD9-4762-A2FE-E51B322EA6E5@gmail.com> <742bbaa7-9648-a0d8-b176-926233dc87a0@redhat.com> Message-ID: <3b3e8827-2354-bfb2-85eb-7894940c5d3a@redhat.com> Here's the bug in Java's runtime which provoked this error: JNIEXPORT jboolean JNICALL Java_java_io_Console_echo(JNIEnv *env, jclass cls, jboolean on) { struct termios tio; jboolean old; int tty = fileno(stdin); if (tcgetattr(tty, &tio) == -1) { JNU_ThrowIOExceptionWithLastError(env, "tcgetattr failed"); return !on; } old = (tio.c_lflag & ECHO); if (on) { tio.c_lflag |= ECHO; } else { tio.c_lflag &= ~ECHO; } if (tcsetattr(tty, TCSANOW, &tio) == -1) { JNU_ThrowIOExceptionWithLastError(env, "tcsetattr failed"); } return old; } It's super-hard to see the bug because you could (and I did) naively assume that jboolean behaves like boolean (or C++ bool) but it doesn't. It should be: old = (tio.c_lflag & ECHO) != 0; which is why, I guess, the author wrapped the expression in parentheses. But note that if we simply fix this in HotSpot, it's only right by accident: ECHO just happens to be 0000010, so we know the result of (tio.c_lflag & ECHO) will fit in a jboolean, but that's just an accident. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Fri Sep 21 15:01:57 2018 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 21 Sep 2018 16:01:57 +0100 Subject: [aarch64-port-dev ] RFR: 8189107 - AARCH64: create intrinsic for pow In-Reply-To: <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> References: <40f2697c-1dee-e605-4402-3e43ad8b6019@redhat.com> <44f5259c-d40e-30e0-272b-140fe6fbc950@redhat.com> <02da7309-9a70-ea30-fafc-d1d85cfae328@bell-sw.com> <47c4307d-eca1-5270-7e2c-83a31686ef91@redhat.com> Message-ID: <1b770596-8da2-74be-bad2-832bf4a6622a@redhat.com> Hi Dmitrij, As promised here is the review (after sig) based on webrev.02. The review first describes the problems I have identified. It then continues with recommendations for (extensive) rework. Since it is based on webrev.02 you will have to make some allowance for the changes you introduced in your webrev.03 I have revised you webrev to include fixes for the two errors I identified and a new version is available here http://cr.openjdk.java.net/~adinn/8189107/webrev.03/ The webrev includes my recommended fix for to the scalbn code in macroAssembler_pow.cpp and a correction to the declaration of table _pow_coef1 in stubRoutines_aarch64.cpp. I explain these changes below. I have also uploaded a commented version of the original algorithm and a revised algorithm based on your code here http://cr.openjdk.java.net/~adinn/8189107/original_algorithm.txt http://cr.openjdk.java.net/~adinn/8189107/revised_algorithm.txt You have seen the original algorithm modulo a few tweaks that emerged in creating the revised version. The revised algorithm /faithfully/ models your webrev.02 code (with a couple of notable exceptions that relate to problems described below). That faithful modelling of the code includes retaining the order of computation of all values. In particular, it models early computation of some data that you appear to have introduced in order to pipeline certain operations. At the same time, the algorithm also introduces a much more coherent control structure (inserting 'if then else' in place of GOTO everywhere it is possible) and a nested /block structure/ (none of this required reordering btw). It profits from this to introduce block local declarations which scope the values computed and used at successive steps. As far as possible the revised algorithm employs the same naming convention as the original algorithm (I'll explain more on that in the detailed feedback below). Why does this matter? Well, once the errors get fixed, by far the biggest remaining problems with the existing code are 1) its unclear control structure and 2) its incoherent allocation of data to registers. The intention of providing block structure and block local use of variables in the revised algorithm is to enable introduction of similar block structuring and block local declarations for registers and branch labels in the generator code. In particular, that will allow the generator code to be rewritten to use symbolic names for registers consistently throughout the function. So, a small number of register mappings for variables that are global to the algorithm will need to be be retained at the start of the function. However, they will use meaningful names like x, exp_mask, one_d, result etc instead of the completely meaningless aliases, tm1, tmp2 etc, that you provided. Similarly, some of the label declarations (mostly for exit cases) will need to be retained at the top level. However, most register mappings will be for variables that are local to a block. So, they will need to be declared at the start of that block making it clear where they are used and where they are no longer in use. Similarly most label declarations will be only need to be declared at the start of the immediately enclosing block that generates the code identified by the label. This will ensure declarations are close to their point of use and are not in scope after they become redundant (or at least not for very long). Register mappings for variables declared in an outer block that are live across nested blocks will then be able to be used consistently in those inner blocks while clearly identifying precisely what values are being generated, used or updated. The same applies for label declarations. They can be used as branch targets in nested blocks but will not be visible in outer scopes or sibling scopes. Where possible the revised algorithm employs the same naming convention as the original algorithm for the values it operates on -- with one important modification. A suffix convention has been adopted to clarify some ambiguities present in the original. For example, this allows us to distinguish the double value x from its long bits representation x_r, its 32 bit high word x_h or its 32 bit positive high word ix_h. The algorithm also employs block local declarations to scope intermediate values, employing names starting with 'tmp'. These are often introduced in small, local blocks, allowing the same names tmp1, tmp2 etc to be reused without ambiguity. So, I hope it is clear how you can use this algorithm to rewrite the generator code to be much more readable and maintainable -- that being the ultimate goal here. I'm not willing to let the code be committed without this restructuring taking place. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander Problems -------- 1) Error in Y_IS_HUGE case The vector maths that computes the polynomial for this case expects to load the first 6 coefficients in table _pow_coef1 in the permuted order (0.25, -ivln2, -0.333333333333, 0.5, ivln2_l, ivln2_h). However, the table declaration in stubRoutines_aarch64.cpp declares them in the order (-0.333333333333, 0.25, 0.5, -ivln2, ivln2_l, ivln2_h). 2) scalbn implementation is wrong The original code was using this algorithm 1 if (0 >= (j_h >> 20)) 2 tmp1 = n' - 1023 // bias n as an exponent 3 tmp2 = (tmp1 & 0x3ff) << 52 // install as high bits 4 two_n_d = LONG_TO_DOUBLE(tmp2) 5 z = z * two_n_d // rescale 6 b(CHECK_RESULT_NEGATION); The problems are: line 1: as you spotted the test was wrongly implemented using cmp not cmpw (j_h is computed using an int add so sign extending as a long fails to retain the overflow bit). line 2: n is the unbiased exponent -- rebiasing it requires adding 1023, not subtracting it line 3: when we hit underflow the unbiased exponent is in the range [-1024, -1075]. So, after correcting the sub to an add the exponent in tmp1 will be negative (that is precisely the case the if test looks for). Installing the top 12 bits exponent of this negative value into the high bits of a double gives a float with unbiased exponent in range [970, 1023] i.e. a very high positive power of 2 rather than a very low negative one. The result is by by about 300 orders of magnitude! line 6: As you spotted, the multiply here updates the register storing z rather than installing the result in v0 I explain all this not to point out why it is wrong but to show how your original version can be salvaged with a few small changes. Basically we want to multiply z by 2^n to get the result where n lies between -1023 and -1075. Depending on the values of z and n the result will be either a subnormal double or +0. So, the simplest solution is to do the multiply in two stages. Here is a revised algorithm: if (0 >= (j_h >> 20)) { double two_n_r // power of 2 as long bits mapped to r2 long biased_n // n' - 1023 mapped to r2 double two_n_d // used to rescale z to underflow value // mapped to v17 // split the rescale into two steps: 2^-512 then the rest n = n + 512 two_n_r = 0x1ff << 52 // high bits for 2^-512 two_n_d = LONG_TO_DOUBLE(two_n_r) z' = z' * two_n_d biased_n = n + 1023 // bias remainder -- will now be positive! two_n_r = (biased_n & 0x3ff) << 52 // high bits for 2^n two_n_d = LONG_TO_DOUBLE(two_n_r) result = z' * two_n_d } else { ... The code for this is: cmpw(zr, tmp10, ASR, 20); br(LT, NO_SCALBN); // n = tmp1 // rescale first by 2^-512 and then by the rest addw(tmp1, tmp1, 512); // n -> n + 512 movz(tmp2, 0x1FF0, 48); fmovd(v17, tmp2); // 2^-512 fmuld(v18, v18, v17); // z = z * 2^-512 addw(tmp2, tmp1, 1023); // biased exponent ubfm(tmp2, tmp2, 12, 10); fmovd(v17, tmp2); // 2^n fmuld(v0, v18, v17); // result = z * 2^n b(CHECK_RESULT_NEGATION); bind(NO_SCALBN); . . . I think this is simpler than your alternative. I checked it on several test cases and it agrees with the existing StrictMath code. 3) Use of Estrin form in place of Horner form I would prefer not to use this without a proof that the re-ordered computation does not introduce rounding errors. I doubt that it will and I suspect that even if it did the error will be very small, certainly small enough that the leeway between what is expected of StrictMath.pow and what is allowed for in Math.pow will not cause anyone's expectations to be challenged. However, even so I'd prefer not to surprise users. Anyway, if Andrew Haley really wants this to be adopted then I'll accept his override and you can leave it in Estrin form. 4) Repetition of code in K_IS_0/K_IS_1 branches In the Y_IS_NOT_HUGE block 15/17 instructions are generated in the if and else branches for k == 0 and k == 1, implementing what is almost exactly the same computation. The two generated sequences differ very slightly. In the k == 1 case dp_h and dp_l need to be folded into the computation to subtract ln2(1.5) from the result while in the k == 0 case dp_h and dp_l are both 0.0 and can be ignored. The most important difference is the need to load dp_l/dp_h from the coefficient table in one branch while the other merely moves forward the cursor which points at the table. The other differences consist of two extra operations in the k == 1 branch, an extra fmlavs and an extra faddd, which fold in the dp_l and dp_h values. An alternative would be to use common code for the computation which always perform the extra fmlavs and faddd. The revised algorithm describes precisely this alternative. To make it work the k = 0 branch needs to install 0.0 in the registers used for dp_h and dp_k (not necessarily by loading from the table). This shortens the branches, relocating 15 common instructions after the branch As far as code clarity is concerned it is easier to understand and maintain if the common code is generated only once. As for performance, I believe this trade off of a few more cycles against code size is also a better choice. Shaving instructions may give a small improvement in a benchmark, especially if the benchmark repeatedly runs with values that exercise only one of the paths. However, in real use the extra code size from the duplicated code is likely to push more code out of cache. Since this is main path code that is actually quite likely to happen. So, I would like to see the duplication removed unless you can make a really strong case for keeping it. If you can provide such a reason then an explanation why the duplication is required needs to be provided in the revised algorithm and the code and the algorithm need sot be updated to specify both paths. 4) Repetition of odd/even tests in exit cases. The original algorithm takes the hit of computing the even/odd/fraction status of y inline, i.e. in the main path, during special case checks. That happens even if the result is not used later. You have chosen to do it at the relevant exits, resulting in more repeated code. These cases will likely be a rare path so the issue of extra code size is not going to be very important relative to the saved cycles. However, the replication of inline code is a maintenance issue. It would be better to use a separate function to generate the common code that computes the test values (lowest non-zero bit idx and exponent of y) avoiding any need to read, check and fix the generator code in different places. Please update the code accordingly. 5) Test code You need to include a test as part of this patch which checks the outputs are correct for a few selected inputs that exercise the underflow and Y_IS_HUGE branches. I adapted the existing Math tests to include these extra checks: public static int testUnderflow() { int failures = 0; failures += testPowCase(1.5E-2D, 170D, 8.6201344461973E-311D); failures += testPowCase(1.55E-2D, 171.3D, 1.00883443217485E-310D); // failures += testPowCase(150D, 141.6D, 1.3630829399139085E308); return failures; } public static int testHugeY() { int failures = 0; long yl = 0x1_1000_0000L; failures += testPowCase(1.0000000001, (double)yl, 1.5782873649891997D); failures += testPowCase(1.0000000001, (double)yl + 0.3, 1.5782873650365483D); return failures; You don't have to add this to the existing math test suite. A simple standalone test which checks that the StrictMath and Math outputs agree on these inputs is all that is needed. Rework ------ 1) Please check that the revised algorithm I have provided accurately reflects the computations performed by your code. That will require changing the code to deal with the error cases 1, 2, 4 and 5 above. If you stick with the Estrin form in case 3 then ensure the algorithm is correct. If you stick with Horner form then update the algorithm so it is consistent. The algorithm currently details all mappings of variable to registers. That is provided as a heuristic which i) allowed me to track usages when writing up the algorithm and ii) will allow you to analyze the current register mappings and rationalize them. Once you have a more coherent strategy for allocating variables to registers details of the mapping can and should be removed. As mentioned, the algorithm uses a suffix notation to distinguish different values where there is some scope for ambiguity. The suffices are used as follows 1) '_d' double values (mapped to d registers) 2) '_hd' and '_ld' hi/lo double pairs used to retain accuracy (mapped to independent d registers) 3) '_d2' double vectors (mapped to 2d v registers) 4) '_r' long values that represent the long version of a double value (mapped to general x registers) 5) '_h' int values that represent the high word of a double value (mapped to general w registers) In many unambiguous cases a suffix is omitted e.g. x, y, k, n. 2) Sort out inconsistent mappings and unnecessary remappings One of the problems I faced in writing up the algorithm is that some of your register use appears to be inconsistent -- the same 'logical' variable is mapped to different registers at different points in the code. In some cases, this reflects different use of the same name for different quantities calculated at different stages in the algorithm (for example, z is used to name both log2(x) and then reused later for the fractional part of log2(x)). Most of those reuses are actually catered for by declaring the var in one block and then redeclaring it in a different sibling block. If this block structure is replicated in the code then it will enable z to be mapped differently for each different scope. However, that's not the preferred outcome. It would make the code easier to follow if every variable named in the algorithm was always mapped to the same register unless there was a clear need to relocate it. There are also cases where a remapping is performed (without any discernible reason) within the same scope or within nested scopes! For example, after the sign of x_r has been noted (and, possibly, it's sign bit removed) the resulting absolute value of x_r is moved from r0 to r1 (using an explicit mov). There doesn't seem to be any need to do this. Likewise, in the COMPUTE_POW_PROCEED block the value for z stored in v0 is reassigned to v18 in the same block! I have flagged these remappings with a !!! comment and avoided the ambiguity that arises by adding a ' to the remapped value (x_r', z') and using it thereafter. This ensures that uses of the different versions of the value located in different registers can be distinguished. An example of remapping in nested scope is provided by p_hd and p_ld. At the outermost scope these values are mapped to v5 and b6. However, in the K_IS_SET block they are stored in v17 and v16 (values for v and u, local to the same block, are placed in v5 and v6 so there is no reason why the outer scope mapping could not have been retained). I'd like to see a much more obvious and obviously consistent plan adopted for mappings before the code is committed. 3) Insert my original and revised algorithms into your code in place of the current ones. 4) Change the code to introduce local blocks as per the revised algorithm This should mostly be a simple matter of introducing braces into the code at strategic locations (although please re-indent). 5) Change the code to use symbolic names for register arguments and declare those names as Register or FloatRegister in the appropriate local scope The main point of employing consistent, logical names for values defined in the algorithm is to allow registers employed in the code to be identified using meaningful names rather than using r0, r1, v0, v1, tmp1, tmp2 etc. So, for example at the top level of the routine you need to declare register mappings for the function global variables and then use them in all the generated instructions e.g. the code should look like // double x // input arg // double y // input arg FloatRegister x = v0; FloatRegister y = v1; // long y_r // y as long bits Register y_r = rscratch2 // long x_r // x as long bits Register x_r = r0 // double one_d // 1.0d FloatRegister one_d = v2 . . . // y_r = DOUBLE_TO_LONG(y) fmovd(y_r, y); // x_r = DOUBLE_TO_LONG(x) fmovd(x_r, x) . . . Similarly, in nested blocks you need to introduce block local names for registers and then use them in the code. For example in the SUBNORMAL_HANDLED block bind(SUBNORMAL_HANDLED); // block introduced to scope vars/labels in this region { Label K_IS_SET; // int ix_h // |x| with exponent rescaled so 1 =< ix < Register ix_h = r2; // int k // range 0 or 1 for poly expansion Register k = r7 // block introduced to scope vars/labels in this subregion { // int x_h // high word of x Register x_h = r2 //int mant_x_h // mantissa bits of high word of Register mant_x_h = r10 . . . // x_h = (x_r' >> 32) lsr(x_h, x_r, 32); // mant_x_h = (x_r >> 32) & 0x000FFFFF ubfx(mant_x_h, x_r, 32, 20); // i.e. top 20 fractions bits of x . . . } bind(K_IS_SET); . . . You should be able to hang the code directly off the algorithm as shown above, making it clear that it matches the revised algorithm and allowing meaningful comparison with the original. If you have changed the code in your latest revisions then please update the algorithm accordingly to ensure they continue to correspond with each other. From andrey.petushkov at gmail.com Fri Sep 21 15:48:22 2018 From: andrey.petushkov at gmail.com (Andrey Petushkov) Date: Fri, 21 Sep 2018 18:48:22 +0300 Subject: [aarch64-port-dev ] hotspot jtreg runtime/BoolReturn/JNIBooleanTest.java failure In-Reply-To: <742bbaa7-9648-a0d8-b176-926233dc87a0@redhat.com> References: <493129BB-4BD9-4762-A2FE-E51B322EA6E5@gmail.com> <742bbaa7-9648-a0d8-b176-926233dc87a0@redhat.com> Message-ID: <8F912037-78F0-4F3C-B79F-5DC1F67F85E5@gmail.com> Something like this: http://cr.openjdk.java.net/~apetushkov/jnibooleantest/webrev/ jtreg is good now, both no-arg and Xint Regards, Andrey > On 21 Sep 2018, at 16:33, Andrew Haley wrote: > > On 09/21/2018 12:02 PM, Andrey Petushkov wrote: > >> Just wanted to ask whether you want this fixed in jdk11. Apparently >> now raw value of jboolean (i.e. u8) returned by JNI method fed into >> java code, where it?s treated in different way. (value != 0 vs bit0 >> != 0) Not sure if it is considered to be belonging to BBB domain or >> just a mere possibility of application developers to shoot >> themselves into foot. I?d fix it with proper value conversion at >> http://hg.openjdk.java.net/jdk/jdk11/file/1ddf9a99e4ad/src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp#l1925 >> >> If you?d like I can prepare a patch (although I assume unless it?s >> BBB-type thing it?s probably too late for jdk11) > > It's been a bug for a long time. I guess the best fix is to define > c2bool the same as x86 and use it in > TemplateInterpreterGenerator::generate_result_handler_for and > SharedRuntime::generate_native_wrapper. > > Mind you, that behaviour is very odd: ignore all but the bottom 8 bits > of the result register and set the return value, i.e.: > > return (byte)result != 0 ? 1 : 0 > > I guess it makes sense, given that jbool is defined to be an unsigned > 8-bit integer type. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Sep 21 16:23:36 2018 From: aph at redhat.com (Andrew Haley) Date: Fri, 21 Sep 2018 17:23:36 +0100 Subject: [aarch64-port-dev ] hotspot jtreg runtime/BoolReturn/JNIBooleanTest.java failure In-Reply-To: <8F912037-78F0-4F3C-B79F-5DC1F67F85E5@gmail.com> References: <493129BB-4BD9-4762-A2FE-E51B322EA6E5@gmail.com> <742bbaa7-9648-a0d8-b176-926233dc87a0@redhat.com> <8F912037-78F0-4F3C-B79F-5DC1F67F85E5@gmail.com> Message-ID: <085b91dc-5aa7-11b2-0e34-e27e35b49ea0@redhat.com> On 09/21/2018 04:48 PM, Andrey Petushkov wrote: > Something like this: > http://cr.openjdk.java.net/~apetushkov/jnibooleantest/webrev/ > > jtreg is good now, both no-arg and Xint > Yeah, that looks perfect. I guess I should try to get this in next week. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From gnu.andrew at redhat.com Fri Sep 21 17:29:03 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 21 Sep 2018 18:29:03 +0100 Subject: [aarch64-port-dev ] RFR: Fix code differences against shenandoah/jdk8u In-Reply-To: References: <0c8cbf95-2ca9-9af9-8082-622e12f35b87@redhat.com> Message-ID: On Thu, 20 Sep 2018 at 15:13, Aleksey Shipilev wrote: > > On 09/20/2018 03:45 PM, Roman Kennke wrote: > > Am 20.09.2018 um 14:50 schrieb Aleksey Shipilev: > >> http://cr.openjdk.java.net/~shade/shenandoah/aarch64-sync-1/webrev.01/ > >> > > Looks good. > > Thanks. I'd like Andrew Hughes to ack this too :) > > -Aleksey > +1. I was actually going to ask whether there were any differences between the two as part of the other thread, so good to see this resolved. -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Fri Sep 21 17:32:05 2018 From: shade at redhat.com (shade at redhat.com) Date: Fri, 21 Sep 2018 17:32:05 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: Fix code differences against shenandoah/jdk8u Message-ID: <201809211732.w8LHW5Do000497@aojmv0008.oracle.com> Changeset: 67c63384e5e9 Author: shade Date: 2018-09-20 14:40 +0200 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/67c63384e5e9 Fix code differences against shenandoah/jdk8u ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/prims/jni.cpp From gnu.andrew at redhat.com Fri Sep 21 17:32:37 2018 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 21 Sep 2018 18:32:37 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8u -> aarch64-port/jdk8u-shenandoah 2018-09-17 In-Reply-To: <14f3fe9f-3ec1-451c-dc04-31ee0ef55c08@redhat.com> References: <57d55193-e132-ebb4-dd0e-71eaa2686f94@redhat.com> <14f3fe9f-3ec1-451c-dc04-31ee0ef55c08@redhat.com> Message-ID: On Wed, 19 Sep 2018 at 18:03, Aleksey Shipilev wrote: > > On 09/19/2018 06:55 PM, Andrew Hughes wrote: > > The changes look ok to me too. Is there a reason to maintain both shenandoah/jdk8u and > > aarch64-port/shenandoah-jdk8u, now that Shenandoah development has moved to an OpenJDK 12 base? > > We treat shenandoah/jdk8u as "let's push backports there and see what happens" repository: we build > and test nightlies there, and sometimes our adopters find obvious bugs there that we don't want to > expose to anybody else, and/or there are adopter-requested features/fixes that might degrade > something else. > > Integration repository like aarch64-port/shenandoah-jdk8u has the stuff we know works fine. It is > then open for larger testing and packaging. I think it makes more sense for 8u, because the GC > interface is rather intrusive in 8u, and there is elevated risk for breakages for non-Shenandoah > code. So, having the additional gateway where 8u integrations are reviewed is a plus. In 11+, almost > all of Shenandoah code is isolated, and has much less risk to regress anything else. > > In other words, shenandoah/jdk8u is like jdk8u/dev, and aarch64-port/shenandoah-jdk8u is like > jdk8u/jdk8u :) What we need to do for this to work better is to get shenandoah/jdk8u -> > aarch64-port/shenandoah-jdk8u on a more frequent basis, so reviews stay trivial, and so that > whatever problems found in RPMs are fixed quickly. > > Thanks, > -Aleksey > > Ok. It's the Shenandoah team doing the merge work so I don't have a strong opinion either way. I would like to see more frequent merges and ideally, much closer to the beginning of the CPU cycle than this (so more early August than late September in the case of the October update). Eyeballing something as big as this one is pretty unwieldy and I only considered the shared changes. Thanks, -- Andrew :) Senior Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Web Site: http://fuseyism.com Twitter: https://twitter.com/gnu_andrew_java PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From rkennke at redhat.com Fri Sep 21 18:26:13 2018 From: rkennke at redhat.com (Roman Kennke) Date: Fri, 21 Sep 2018 20:26:13 +0200 Subject: [aarch64-port-dev ] RFR: Fix code differences against shenandoah/jdk8u In-Reply-To: References: <0c8cbf95-2ca9-9af9-8082-622e12f35b87@redhat.com> Message-ID: Am 21.09.2018 um 19:29 schrieb Andrew Hughes: > On Thu, 20 Sep 2018 at 15:13, Aleksey Shipilev wrote: >> >> On 09/20/2018 03:45 PM, Roman Kennke wrote: >>> Am 20.09.2018 um 14:50 schrieb Aleksey Shipilev: >>>> http://cr.openjdk.java.net/~shade/shenandoah/aarch64-sync-1/webrev.01/ >>>> >>> Looks good. >> >> Thanks. I'd like Andrew Hughes to ack this too :) >> >> -Aleksey >> > > +1. > > I was actually going to ask whether there were any differences between > the two as part of the other thread, so good to see this resolved. > Want me to re-direct the patch to the updated changeset? Roman From boris.ulasevich at bell-sw.com Sun Sep 23 15:45:17 2018 From: boris.ulasevich at bell-sw.com (Boris Ulasevich) Date: Sun, 23 Sep 2018 18:45:17 +0300 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: <990eb025-8705-8633-abd7-0e87a3dc6d33@bell-sw.com> References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <990eb025-8705-8633-abd7-0e87a3dc6d33@bell-sw.com> Message-ID: Hi Bob, I checked your changes with jtreg and jck. I see no new fails introduced by this change. regards, Boris On 19.09.2018 13:30, Boris Ulasevich wrote: > Hi Bob, > > Thank you for this job! > I have started testing. Will come back with results next week :) > The changes is Ok for me. Please see some minor comments below. > > regards, > Boris > > On 17.09.2018 20:49, Aleksey Shipilev wrote: >> On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: >>> On 9/17/18 9:20 AM, Bob Vandette wrote: >>>> Please review the changes related to JEP 340 which remove the second >>>> 64-bit ARM port from the JDK.>> >>>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >> >> I read through the webrev, and it seems to be the clean removal. It >> also feels >> very satisfying to drop 15 KLOC of ifdef-ed code. >> >> Minor nits: >> >> ? *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and >> src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if defined(ASSERT)", >> which cab >> be just "#ifdef ASSERT" now >> >> ? *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if >> defined(__ABI_HARD__)" >> >> ? *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment below >> seems to >> apply to AArch64 only. > > Yes, the note looks like AArch64 specific comment, but I think it is > valid for arm32 too. So the change is Ok for me. > >> Yet, only the first line of the comment is removed. I >> think we should instead convert that comment into "TODO:" mentioning >> this might >> be revised after AArch64 removal? >> >> ? 992?? void branch_if_negative_32(Register r, Label& L) { >> ? 993???? // Note about branch_if_negative_32() / >> branch_if_any_negative_32() >> implementation for AArch64: >> ? 994???? // tbnz is not used instead of tst & b.mi because >> destination may be >> out of tbnz range (+-32KB) >> ? 995???? // since these methods are used in >> LIR_Assembler::emit_arraycopy() to >> jump to stub entry. >> ? 996???? tst_32(r, r); >> ? 997???? b(L, mi); >> ? 998?? } >> >> ? *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines L1204..1205, >> L1435..1436 >> can be merged together: >> >> 1203?? // Generate the inner loop for shifted forward array copy >> (unaligned copy). >> 1204?? // It can be used when bytes_per_count < wordSize, i.e. >> 1205?? //? byte/short copy >> >> 1434?? // Generate the inner loop for shifted backward array copy >> (unaligned copy). >> 1435?? // It can be used when bytes_per_count < wordSize, i.e. >> 1436?? //? byte/short copy >> >> >> ? *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed >> incorrectly around L3363? > > I believe both (L3188 and L3363) comments should mention SP[0] (not R4) > as an input parameter now. > >> ?? - //??? R4 (AArch64) / SP[0] (32-bit ARM) -? element count (32-bit >> int) >> ?? + //??? R4??? -? element count (32-bit int) >> >> >> ? *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, >> "R4"/"R5" >> comments are missing: >> >> ?? - const Register Rsig_handler??? = AARCH64_ONLY(R21) >> NOT_AARCH64(Rtmp_save0 /* >> R4 */); >> ?? - const Register Rnative_code??? = AARCH64_ONLY(R22) >> NOT_AARCH64(Rtmp_save1 /* >> R5 */); >> ?? + const Register Rsig_handler??? = Rtmp_save0; >> ?? + const Register Rnative_code??? = Rtmp_save1; >> >> Thanks, >> -Aleksey >> From aleksei.voitylov at bell-sw.com Mon Sep 24 17:02:34 2018 From: aleksei.voitylov at bell-sw.com (Aleksei Voitylov) Date: Mon, 24 Sep 2018 20:02:34 +0300 Subject: [aarch64-port-dev ] RFR: 8209093 - JEP 340: One AArch64 Port, Not Two In-Reply-To: References: <285AC12C-3A77-41FB-A756-ED15354B61FE@oracle.com> <990eb025-8705-8633-abd7-0e87a3dc6d33@bell-sw.com> Message-ID: <02709fdc-5924-1ed5-0654-068434320698@bell-sw.com> Bob, Thank you for doing this. In the meanwhile, some of my fixes were pushed that invalidated your diff, for which I apologize. Here is an updated version of your patch which applies cleanly: http://cr.openjdk.java.net/~avoitylov/webrev.8209093.02/ -Aleksei On 23/09/2018 18:45, Boris Ulasevich wrote: > Hi Bob, > > ? I checked your changes with jtreg and jck. I see no new fails > introduced by this change. > > regards, > Boris > > On 19.09.2018 13:30, Boris Ulasevich wrote: >> Hi Bob, >> >> Thank you for this job! >> I have started testing. Will come back with results next week :) >> The changes is Ok for me. Please see some minor comments below. >> >> regards, >> Boris >> >> On 17.09.2018 20:49, Aleksey Shipilev wrote: >>> On 09/17/2018 07:00 PM, Vladimir Kozlov wrote: >>>> On 9/17/18 9:20 AM, Bob Vandette wrote: >>>>> Please review the changes related to JEP 340 which remove the second >>>>> 64-bit ARM port from the JDK.>> >>>>> http://cr.openjdk.java.net/~bobv/8209093/webrev.01 >>> >>> I read through the webrev, and it seems to be the clean removal. It >>> also feels >>> very satisfying to drop 15 KLOC of ifdef-ed code. >>> >>> Minor nits: >>> >>> ? *) In src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp and >>> src/hotspot/cpu/arm/interp_masm_arm.cpp we have "#if >>> defined(ASSERT)", which cab >>> be just "#ifdef ASSERT" now >>> >>> ? *) Ditto in src/hotspot/cpu/arm/jniFastGetField_arm.cpp we have "#if >>> defined(__ABI_HARD__)" >>> >>> ? *) In src/hotspot/cpu/arm/macroAssembler_arm.hpp, the comment >>> below seems to >>> apply to AArch64 only. >> >> Yes, the note looks like AArch64 specific comment, but I think it is >> valid for arm32 too. So the change is Ok for me. >> >>> Yet, only the first line of the comment is removed. I >>> think we should instead convert that comment into "TODO:" mentioning >>> this might >>> be revised after AArch64 removal? >>> >>> ? 992?? void branch_if_negative_32(Register r, Label& L) { >>> ? 993???? // Note about branch_if_negative_32() / >>> branch_if_any_negative_32() >>> implementation for AArch64: >>> ? 994???? // tbnz is not used instead of tst & b.mi because >>> destination may be >>> out of tbnz range (+-32KB) >>> ? 995???? // since these methods are used in >>> LIR_Assembler::emit_arraycopy() to >>> jump to stub entry. >>> ? 996???? tst_32(r, r); >>> ? 997???? b(L, mi); >>> ? 998?? } >>> >>> ? *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, lines >>> L1204..1205, L1435..1436 >>> can be merged together: >>> >>> 1203?? // Generate the inner loop for shifted forward array copy >>> (unaligned copy). >>> 1204?? // It can be used when bytes_per_count < wordSize, i.e. >>> 1205?? //? byte/short copy >>> >>> 1434?? // Generate the inner loop for shifted backward array copy >>> (unaligned copy). >>> 1435?? // It can be used when bytes_per_count < wordSize, i.e. >>> 1436?? //? byte/short copy >>> >>> >>> ? *) In src/hotspot/cpu/arm/stubGenerator_arm.cpp, the comment changed >>> incorrectly around L3363? >> >> I believe both (L3188 and L3363) comments should mention SP[0] (not >> R4) as an input parameter now. >> >>> ?? - //??? R4 (AArch64) / SP[0] (32-bit ARM) -? element count >>> (32-bit int) >>> ?? + //??? R4??? -? element count (32-bit int) >>> >>> >>> ? *) In src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp, >>> "R4"/"R5" >>> comments are missing: >>> >>> ?? - const Register Rsig_handler??? = AARCH64_ONLY(R21) >>> NOT_AARCH64(Rtmp_save0 /* >>> R4 */); >>> ?? - const Register Rnative_code??? = AARCH64_ONLY(R22) >>> NOT_AARCH64(Rtmp_save1 /* >>> R5 */); >>> ?? + const Register Rsig_handler??? = Rtmp_save0; >>> ?? + const Register Rnative_code??? = Rtmp_save1; >>> >>> Thanks, >>> -Aleksey >>> From felix.yang at huawei.com Wed Sep 26 03:01:51 2018 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 26 Sep 2018 03:01:51 +0000 Subject: [aarch64-port-dev ] RFR(S): 8210413: AArch64: Optimize div/rem by constant in C1 In-Reply-To: References: <9645c210-3d87-52fa-8051-54dc60629866@redhat.com> <9d454f5b-475b-5713-7155-c6946f378c3e@redhat.com> Message-ID: Just eyeballed the changes, looks good. Pushed: http://hg.openjdk.java.net/jdk/jdk/rev/e1368526699d Thanks, Felix > > Thanks for your code review. Could you help push this patch? > > -- > Thanks, > Pengfei > > > > -----Original Message----- > > > > On 09/20/2018 05:15 AM, Pengfei Li (Arm Technology China) wrote: > > > Please find below new patch that added the same optimization for longs as > > well as ints and also fixed an issue. > > > http://cr.openjdk.java.net/~yzhang/8210413/webrev.01/ > > > > > > Could you help look at it again? > > > > That's fine. I'm not exactly delighted by the amount of duplicated code for > > long and int, but it's very hard to avoid in this case. > > The patch is good for JDK/JDK. > > > > -- > > Andrew Haley > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From stuart.monteith at linaro.org Wed Sep 26 17:39:53 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Wed, 26 Sep 2018 18:39:53 +0100 Subject: [aarch64-port-dev ] OpenJDK on AArch64 Fireside chat Message-ID: Hello, It is has been a while since there has been a "Fireside chat" for those of us working on AArch64. To accommodate those on the West coast of the USA and Europe, I suggest 15:00 UTC, which is 8am in PDT, 4pm in UK, 6pm in Europe. Please let me know what day will suit you and whether the time is acceptable. Thanks, Stuart From Derek.White at cavium.com Wed Sep 26 21:13:02 2018 From: Derek.White at cavium.com (White, Derek) Date: Wed, 26 Sep 2018 21:13:02 +0000 Subject: [aarch64-port-dev ] OpenJDK on AArch64 Fireside chat In-Reply-To: References: Message-ID: Sounds good to me. Any day except Thursday is fine at that time... - Derek > -----Original Message----- > From: aarch64-port-dev On > Behalf Of Stuart Monteith > Sent: Wednesday, September 26, 2018 1:40 PM > To: aarch64-port-dev at openjdk.java.net > Subject: [aarch64-port-dev ] OpenJDK on AArch64 Fireside chat > > External Email > > Hello, > It is has been a while since there has been a "Fireside chat" for those of > us working on AArch64. To accommodate those on the West coast of the > USA and Europe, I suggest 15:00 UTC, which is 8am in PDT, 4pm in UK, 6pm > in Europe. > > Please let me know what day will suit you and whether the time is > acceptable. > > Thanks, > Stuart From Pengfei.Li at arm.com Thu Sep 27 07:10:34 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 27 Sep 2018 07:10:34 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 Message-ID: Hi, The commit "8211029: Have a common set of enabled warnings for all native libraries" breaks AArch64 build. We have several code warnings in AArch64 C1 and template table. And options "-Werror=c++11-compat" and "-Werror=switch" are turned on by this commit. Error log can be found at JBS: https://bugs.openjdk.java.net/browse/JDK-8211207 Please help review this patch that fixed these warnings in AArch64 backend. webrev: http://cr.openjdk.java.net/~njian/8211207/webrev.00/ -- Thanks, Pengfei From shade at redhat.com Thu Sep 27 07:22:00 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Sep 2018 09:22:00 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: References: Message-ID: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> On 09/27/2018 09:10 AM, Pengfei Li (Arm Technology China) wrote: > Please help review this patch that fixed these warnings in AArch64 backend. > webrev: http://cr.openjdk.java.net/~njian/8211207/webrev.00/ Please break the line after "default:" to match the style in c1_LIRGenerator_aarch64.cpp here: 795 default: break; 796 } 797 } 798 default: break; 799 } Otherwise looks good and trivial. Thanks, -Aleksey From Pengfei.Li at arm.com Thu Sep 27 08:08:20 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 27 Sep 2018 08:08:20 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> Message-ID: Hi Aleksey, Thanks for your review. Please see new patch at http://cr.openjdk.java.net/~njian/8211207/webrev.01/ I've added line breaks after "default:" and restored a missing break in switch-case. Could you help push this new patch if no other issues? -- Thanks, Pengfei > -----Original Message----- > > On 09/27/2018 09:10 AM, Pengfei Li (Arm Technology China) wrote: > > Please help review this patch that fixed these warnings in AArch64 backend. > > webrev: http://cr.openjdk.java.net/~njian/8211207/webrev.00/ > > Please break the line after "default:" to match the style in > c1_LIRGenerator_aarch64.cpp here: > > 795 default: break; > 796 } > 797 } > 798 default: break; > 799 } > > Otherwise looks good and trivial. > > Thanks, > -Aleksey From aph at redhat.com Thu Sep 27 08:21:16 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 27 Sep 2018 09:21:16 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> Message-ID: <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> On 09/27/2018 08:22 AM, Aleksey Shipilev wrote: > Otherwise looks good and trivial. No, it is neither good nor trivial:some of those should be ShouldNotReachHere(). I'll post a webrev later. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Sep 27 08:30:57 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Sep 2018 10:30:57 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> Message-ID: <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> On 09/27/2018 10:21 AM, Andrew Haley wrote: > On 09/27/2018 08:22 AM, Aleksey Shipilev wrote: >> Otherwise looks good and trivial. > > No, it is neither good nor trivial:some of those should be ShouldNotReachHere(). > I'll post a webrev later. Okay, let's see it. I was mostly concerned with having the same control flow as before, did I miss some change that is actually non-trivial? On the second read, this change in c1_LIRAssembler_aarch64.cpp looks suspicious, as it elevates ShouldNotReachHere to default case, rather than letting default thing fall-through? break; + default: ShouldNotReachHere(); } -Aleksey From Pengfei.Li at arm.com Thu Sep 27 08:42:48 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Thu, 27 Sep 2018 08:42:48 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> Message-ID: I'm happy to hear Andrew Haley will post a better fix. You can discard my change. -- Thanks, Pengfei > -----Original Message----- > > On 09/27/2018 10:21 AM, Andrew Haley wrote: > > On 09/27/2018 08:22 AM, Aleksey Shipilev wrote: > >> Otherwise looks good and trivial. > > > > No, it is neither good nor trivial:some of those should be > ShouldNotReachHere(). > > I'll post a webrev later. > > Okay, let's see it. > > I was mostly concerned with having the same control flow as before, did I > miss some change that is actually non-trivial? On the second read, this > change in c1_LIRAssembler_aarch64.cpp looks suspicious, as it elevates > ShouldNotReachHere to default case, rather than letting default thing fall- > through? > > break; > + default: > ShouldNotReachHere(); > } > > > -Aleksey > From aph at redhat.com Thu Sep 27 08:53:11 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 27 Sep 2018 09:53:11 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> Message-ID: <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> On 09/27/2018 09:30 AM, Aleksey Shipilev wrote: > On 09/27/2018 10:21 AM, Andrew Haley wrote: >> On 09/27/2018 08:22 AM, Aleksey Shipilev wrote: >>> Otherwise looks good and trivial. >> >> No, it is neither good nor trivial:some of those should be ShouldNotReachHere(). >> I'll post a webrev later. > > Okay, let's see it. > > I was mostly concerned with having the same control flow as before, > did I miss some change that is actually non-trivial? That's not my point: we should not put break statements in places we don't expect to reach. It's misleading for the reader. Code changes to "shut up" the compiler have do be done with great care and knowledge of what the code does. > On the second read, this change in c1_LIRAssembler_aarch64.cpp looks > suspicious, as it elevates ShouldNotReachHere to default case, > rather than letting default thing fall-through? > > break; > + default: > ShouldNotReachHere(); > } I think that one is actually OK. http://cr.openjdk.java.net/~aph/8211207/ follows the pattern of the x86 port. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Thu Sep 27 09:06:21 2018 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Sep 2018 11:06:21 +0200 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> Message-ID: On 09/27/2018 10:53 AM, Andrew Haley wrote: > On 09/27/2018 09:30 AM, Aleksey Shipilev wrote: >> I was mostly concerned with having the same control flow as before, >> did I miss some change that is actually non-trivial? > > That's not my point: we should not put break statements in places we > don't expect to reach. It's misleading for the reader. Code changes > to "shut up" the compiler have do be done with great care and > knowledge of what the code does. Okay, fair point. >> On the second read, this change in c1_LIRAssembler_aarch64.cpp looks >> suspicious, as it elevates ShouldNotReachHere to default case, >> rather than letting default thing fall-through? >> >> break; >> + default: >> ShouldNotReachHere(); >> } > > I think that one is actually OK. > > http://cr.openjdk.java.net/~aph/8211207/ Looks good! -Aleksey From adinn at redhat.com Thu Sep 27 09:27:37 2018 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 27 Sep 2018 10:27:37 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> Message-ID: <8f27c2d5-d4ef-2a59-9044-38329b1287da@redhat.com> On 27/09/18 09:53, Andrew Haley wrote: > http://cr.openjdk.java.net/~aph/8211207/ > > follows the pattern of the x86 port. Yes, looks good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Thu Sep 27 10:07:12 2018 From: aph at redhat.com (Andrew Haley) Date: Thu, 27 Sep 2018 11:07:12 +0100 Subject: [aarch64-port-dev ] OpenJDK on AArch64 Fireside chat In-Reply-To: References: Message-ID: On 09/26/2018 10:13 PM, White, Derek wrote: > Sounds good to me. Any day except Thursday is fine at that time... Tomorrow (Friday) is good. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dms at samersoff.net Thu Sep 27 10:14:28 2018 From: dms at samersoff.net (Dmitry Samersoff) Date: Thu, 27 Sep 2018 13:14:28 +0300 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> Message-ID: <68b52c1a-63c0-9966-2627-db4de08e7c46@samersoff.net> Andrew, My $0.2 It might be better to refactor switch(tag) in c1_LIRGenerator_aarch64.cpp to usual case/break form, rather than have multiple returns. i.e. switch (tag) { 583 case floatTag: // fall trough 584 case doubleTag: do_ArithmeticOp_FPU(x); break; 585 case longTag: do_ArithmeticOp_Long(x); break; 586 case intTag: do_ArithmeticOp_Int(x); break; 587 default: ShouldNotReachHere(); 588 } return; -Dmitry On 27.09.2018 11:53, Andrew Haley wrote: > On 09/27/2018 09:30 AM, Aleksey Shipilev wrote: >> On 09/27/2018 10:21 AM, Andrew Haley wrote: >>> On 09/27/2018 08:22 AM, Aleksey Shipilev wrote: >>>> Otherwise looks good and trivial. >>> >>> No, it is neither good nor trivial:some of those should be ShouldNotReachHere(). >>> I'll post a webrev later. >> >> Okay, let's see it. >> >> I was mostly concerned with having the same control flow as before, >> did I miss some change that is actually non-trivial? > > That's not my point: we should not put break statements in places we > don't expect to reach. It's misleading for the reader. Code changes > to "shut up" the compiler have do be done with great care and > knowledge of what the code does. > >> On the second read, this change in c1_LIRAssembler_aarch64.cpp looks >> suspicious, as it elevates ShouldNotReachHere to default case, >> rather than letting default thing fall-through? >> >> break; >> + default: >> ShouldNotReachHere(); >> } > > I think that one is actually OK. > > http://cr.openjdk.java.net/~aph/8211207/ > > follows the pattern of the x86 port. > -- Dmitry Samersoff http://devnull.samersoff.net * There will come soft rains ... From stuart.monteith at linaro.org Fri Sep 28 09:29:03 2018 From: stuart.monteith at linaro.org (Stuart Monteith) Date: Fri, 28 Sep 2018 10:29:03 +0100 Subject: [aarch64-port-dev ] OpenJDK on AArch64 Fireside chat In-Reply-To: References: Message-ID: Ok, we have a couple of takers, so let's say 15:00 UTC, 4pm BST, 8am PDT, 18:00 Moscow time today. You can join at the following URL: https://bluejeans.com/880637328 With the passcode "3116". It can be joined by phone with the meeting ID "880 637 328" and the same passcode at the following number: http://bluejeans.com/numbers Please avoid the toll free numbers. BR, Stuart On 26/09/18 18:39, Stuart Monteith wrote: > Hello, > It is has been a while since there has been a "Fireside chat" for those > of us working on AArch64. To accommodate those on the West coast of the > USA and Europe, I suggest 15:00 UTC, which is 8am in PDT, 4pm in UK, 6pm > in Europe. > > Please let me know what day will suit you and whether the time is > acceptable. > > Thanks, > Stuart > From felix.yang at huawei.com Sat Sep 29 07:31:27 2018 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Sat, 29 Sep 2018 07:31:27 +0000 Subject: [aarch64-port-dev ] RFR: Backport patch for 8207838 to aarch64/jdk8u Message-ID: Hi, I see the same issue (8207838) for aarch64/jdk8u repo, and I am trying to backport this patch: ---------------------------------------------------------------- 8207838: AArch64: Float registers incorrectly restored in JNI call Summary: fix the order in which float registers are restored in restore_args for aarch64 Reviewed-by: aph Contributed-by: guoge1 at huawei.com --------------------------------------------------------------- The original jdk11 patch, which is merged more than a month ago: http://hg.openjdk.java.net/jdk/jdk11/rev/3b3685479784 The backport patch with some adaptations for the test case: http://cr.openjdk.java.net/~fyang/8207838-backport/webrev.00/ Tested with Jtreg hotspot & langtools with an aarch64 server build. OK to backport? Thanks for your help, Felix From aph at redhat.com Sat Sep 29 08:22:47 2018 From: aph at redhat.com (Andrew Haley) Date: Sat, 29 Sep 2018 09:22:47 +0100 Subject: [aarch64-port-dev ] RFR: Backport patch for 8207838 to aarch64/jdk8u In-Reply-To: References: Message-ID: <85fea53b-d724-d334-78f0-c9ca644f1427@redhat.com> On 09/29/2018 08:31 AM, Yangfei (Felix) wrote: > The backport patch with some adaptations for the test case: > http://cr.openjdk.java.net/~fyang/8207838-backport/webrev.00/ > > Tested with Jtreg hotspot & langtools with an aarch64 server build. > OK to backport? That looks good to me. Thanks. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Sat Sep 29 08:41:07 2018 From: aph at redhat.com (Andrew Haley) Date: Sat, 29 Sep 2018 09:41:07 +0100 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: <68b52c1a-63c0-9966-2627-db4de08e7c46@samersoff.net> References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> <68b52c1a-63c0-9966-2627-db4de08e7c46@samersoff.net> Message-ID: Hi, On 09/27/2018 11:14 AM, Dmitry Samersoff wrote: > My $0.2 > > It might be better to refactor > switch(tag) in c1_LIRGenerator_aarch64.cpp > to usual case/break form, rather than have multiple returns. > > i.e. > > switch (tag) { > 583 case floatTag: // fall trough > 584 case doubleTag: > do_ArithmeticOp_FPU(x); > break; > 585 case longTag: > do_ArithmeticOp_Long(x); > break; > 586 case intTag: > do_ArithmeticOp_Int(x); > break; > 587 default: > ShouldNotReachHere(); > 588 } > > return; It would, but we follow x86 as much as we can, which makes porting changes from there much easier. This recently helped with the "Better Byte Behaviour" and "Better Interface Invocations" fixes, where the aarch64 patch required relatively little work beyond translating the x86 instructions into their obvious equivalents. So, we prefer consistency over style where this makes maintenance easier. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From Pengfei.Li at arm.com Sat Sep 29 10:01:46 2018 From: Pengfei.Li at arm.com (Pengfei Li (Arm Technology China)) Date: Sat, 29 Sep 2018 10:01:46 +0000 Subject: [aarch64-port-dev ] RFR(XS): 8211207: AArch64: Fix build failure after JDK-8211029 In-Reply-To: References: <9febfd05-3032-0205-1eb5-13bbd74ebbe3@redhat.com> <206c7bc7-6c6f-0049-6559-c712e88a3c14@redhat.com> <6cea2c34-546a-6998-cdb3-49f8e99ce5ed@redhat.com> <24b83fcc-3058-3e13-43e4-c5efd720899d@redhat.com> <68b52c1a-63c0-9966-2627-db4de08e7c46@samersoff.net> Message-ID: Hi, Anyone can help push Andrew Haley's fix ASAP since current master cannot build? http://cr.openjdk.java.net/~aph/8211207/ -- Thanks, Pengfei > -----Original Message----- > > Hi, > > On 09/27/2018 11:14 AM, Dmitry Samersoff wrote: > > > My $0.2 > > > > It might be better to refactor > > switch(tag) in c1_LIRGenerator_aarch64.cpp to usual case/break form, > > rather than have multiple returns. > > > > i.e. > > > > switch (tag) { > > 583 case floatTag: // fall trough > > 584 case doubleTag: > > do_ArithmeticOp_FPU(x); > > break; > > 585 case longTag: > > do_ArithmeticOp_Long(x); > > break; > > 586 case intTag: > > do_ArithmeticOp_Int(x); > > break; > > 587 default: > > ShouldNotReachHere(); > > 588 } > > > > return; > > It would, but we follow x86 as much as we can, which makes porting changes > from there much easier. This recently helped with the "Better Byte > Behaviour" and "Better Interface Invocations" fixes, where the > aarch64 patch required relatively little work beyond translating the > x86 instructions into their obvious equivalents. > > So, we prefer consistency over style where this makes maintenance easier. > > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at linaro.org Sat Sep 29 13:12:30 2018 From: felix.yang at linaro.org (felix.yang at linaro.org) Date: Sat, 29 Sep 2018 13:12:30 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u/hotspot: 8207838: AArch64: Float registers incorrectly restored in JNI call Message-ID: <201809291312.w8TDCUDW011261@aojmv0008.oracle.com> Changeset: f046cf1847b8 Author: fyang Date: 2018-09-28 08:48 +0800 URL: http://hg.openjdk.java.net/aarch64-port/jdk8u/hotspot/rev/f046cf1847b8 8207838: AArch64: Float registers incorrectly restored in JNI call Summary: fix the order in which float registers are restored in restore_args for aarch64 Reviewed-by: aph Contributed-by: guoge1 at huawei.com ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp + test/compiler/floatingpoint/8165673/TestFloatJNIArgs.java + test/compiler/floatingpoint/8165673/TestFloatJNIArgs.sh + test/compiler/floatingpoint/8165673/libTestFloatJNIArgs.c + test/compiler/floatingpoint/8207838/TestFloatSyncJNIArgs.java + test/compiler/floatingpoint/8207838/TestFloatSyncJNIArgs.sh + test/compiler/floatingpoint/8207838/libTestFloatSyncJNIArgs.c - test/compiler/floatingpoint/TestFloatJNIArgs.java - test/compiler/floatingpoint/TestFloatJNIArgs.sh - test/compiler/floatingpoint/libTestFloatJNIArgs.c