From felix.yang at huawei.com Mon Aug 3 01:18:30 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 3 Aug 2020 01:18:30 +0000 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Friday, July 31, 2020 11:56 PM > To: Yangfei (Felix) ; hotspot-runtime- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic > > On 7/31/20 10:57 AM, Yangfei (Felix) wrote: > > Since this will not be enabled when the hardware feature is missing, do > you think we need any more changes? > > I do. I do not want the accelerator intrinsic to be auto-enabled until it has > been tested on hardware. OK. I simply comment out the following code changes in vm_version_aarch64.cpp: 393 if (UseSHA && (auxv & HWCAP_SHA512)) { 394 // Do not auto-enable UseSHA512Intrinsics until it has been fully tested on hardware 395 // if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { 396 // FLAG_SET_DEFAULT(UseSHA512Intrinsics, true); 397 // } 398 } else if (UseSHA512Intrinsics) { Once this has been fully tested on real hardware, it will be easy to auto-enable. New webrev: http://cr.openjdk.java.net/~fyang/8165404/webrev.01/ Thanks, Felix From felix.yang at huawei.com Mon Aug 3 01:25:16 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 3 Aug 2020 01:25:16 +0000 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8161072: AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure In-Reply-To: <1f636988-a1f7-03d8-f405-4cb52dc86346@redhat.com> References: <1f636988-a1f7-03d8-f405-4cb52dc86346@redhat.com> Message-ID: Hi Andrew, > -----Original Message----- > From: Andrew Dinn [mailto:adinn at redhat.com] > Sent: Friday, July 31, 2020 8:46 PM > To: Yangfei (Felix) ; aarch64-port- > dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] 8u-aarch64: Backport 8161072: AArch64: > jtreg compiler/uncommontrap/TestDeoptOOM failure > > Hi felix, > > On 31/07/2020 10:49, Yangfei (Felix) wrote: > > Hi Andrew, > > > > Thanks for the reply :-) > > . . . > > >> I'm not sure if you are asking for a review or permission from a > >> maintainer. If the patch applied cleanly (it looks like it does) then you > don't need a review. > >> If not then count this as a review. > > > > Yes, I am asking for a review from an aarch64-port reviewer. > > Ok, so it's reviewed ;-) Thanks for reviewing this. > >> You will need to update the bug with a fix request comment and tag to > >> get permission from a maintainer. > > > > I assume that's the process for jdk8u mainline, right? > > But aarch64-port has not yet in jdk8u upstream, and this a 8u-aarch64 > specific issue. > > So as usual, I decided to send the patch here on this mailing list for > reviewing. > > Anything I missed? > Doh! Sorry for forgetting the correct protocol -- I need to spend less time on > Graal and more on OpenJDK :-D Have fun! ;-) > This is ok to push. Will do the push. Felix From david.holmes at oracle.com Mon Aug 3 04:15:42 2020 From: david.holmes at oracle.com (David Holmes) Date: Mon, 3 Aug 2020 14:15:42 +1000 Subject: [aarch64-port-dev ] RFR(XXS) 8250824: AArch64: follow up for JDK-8248414 In-Reply-To: References: Message-ID: <11193d92-3a27-e1ae-d5fa-b814183f3085@oracle.com> Hi Bernhard, On 30/07/2020 10:59 pm, Bernhard Urban-Forster wrote: > Hi all, > > the original change [1] missed to update an assert. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8250824 > Webrev: http://cr.openjdk.java.net/~burban/8250824/ Looks good and trivial. I will sponsor for you. David ----- > > Thank you, > -Bernhard > > > [1] https://hg.openjdk.java.net/jdk/jdk/rev/d352e5db468c > From beurba at microsoft.com Mon Aug 3 07:53:11 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 3 Aug 2020 07:53:11 +0000 Subject: [aarch64-port-dev ] RFR(XXS) 8250824: AArch64: follow up for JDK-8248414 In-Reply-To: <11193d92-3a27-e1ae-d5fa-b814183f3085@oracle.com> References: , <11193d92-3a27-e1ae-d5fa-b814183f3085@oracle.com> Message-ID: Thank you David! -Bernhard ________________________________________ From: David Holmes Sent: Monday, August 3, 2020 06:15 To: Bernhard Urban-Forster; hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: RFR(XXS) 8250824: AArch64: follow up for JDK-8248414 Hi Bernhard, On 30/07/2020 10:59 pm, Bernhard Urban-Forster wrote: > Hi all, > > the original change [1] missed to update an assert. > > JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250824&data=02%7C01%7Cbeurba%40microsoft.com%7C0e8fd92583174c80daee08d83763eb77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320249581093986&sdata=7%2BasxpoTHgssuQ2%2BKsWbPOHJXToT2rD4YZSBIVwHiVQ%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8250824%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C0e8fd92583174c80daee08d83763eb77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320249581093986&sdata=gYwzMY7aYc4cNqCCgMZ0gn060rLtpRR5n1CI4V9I7F0%3D&reserved=0 Looks good and trivial. I will sponsor for you. David ----- > > Thank you, > -Bernhard > > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Frev%2Fd352e5db468c&data=02%7C01%7Cbeurba%40microsoft.com%7C0e8fd92583174c80daee08d83763eb77%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637320249581103985&sdata=dncJ0%2BZUwMFk243t6H2QrSAg%2FBFGlgJwRSCn75Ghfck%3D&reserved=0 > From felix.yang at huawei.com Mon Aug 3 12:43:48 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 3 Aug 2020 12:43:48 +0000 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 Message-ID: Hi, This 8u-aarch64 backport has been discussed and approved by aph before in: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-June/007463.html Bug: https://bugs.openjdk.java.net/browse/JDK-8171537 Original jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a3bd5804b4be Original review thread: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2016-December/004036.html This bug is still reproducible with the following test (copied from test/hotspot/jtreg/compiler/c1/Test6849574.java in jdk9+): $ cat Test6849574.java import java.util.concurrent.atomic.AtomicReferenceArray; public class Test6849574 extends Thread { public static void main(String[] args) { AtomicReferenceArray a = new AtomicReferenceArray(10000); for (int i = 0; i < 100000; i++) { a.getAndSet(9999, new Object()); if (i > 99990) System.gc(); } } } $ java -XX:TieredStopAtLevel=1 -XX:MaxInlineSize=50 Test6849574 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (assembler_aarch64.hpp:237), pid=2965, tid=0x0000fffebc4dd1e0 # guarantee(val < (1U << nbits)) failed: Field too big for insn # # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-yangfei_2020_08_03_20_20-b00) # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-aarch64 compressed oops) # Core dump written. Default location: /home/yangfei/test/core or core.2965 ...... 8u-aarch64 backport is simpile: diff -r e385349cb315 src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp --- a/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Fri Jul 08 17:11:37 2016 +0100 +++ b/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Mon Aug 03 20:36:04 2020 +0800 @@ -3145,7 +3145,7 @@ } void LIR_Assembler::atomic_op(LIR_Code code, LIR_Opr src, LIR_Opr data, LIR_Opr dest, LIR_Opr tmp_op) { - Address addr = as_Address(src->as_address_ptr(), noreg); + Address addr = as_Address(src->as_address_ptr()); BasicType type = src->type(); bool is_oop = type == T_OBJECT || type == T_ARRAY; Performed full jtreg test with aarch64 release build. Please take another look. Thanks, Felix From gnu.andrew at redhat.com Mon Aug 3 17:12:50 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 3 Aug 2020 18:12:50 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b01 Upstream Sync Message-ID: <20200803171250.GA263856@stopbrexit> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/root/merge.changeset Changes in aarch64-shenandoah-jdk8u272-b01: - JDK-8006205: [TESTBUG] NEED_TEST: please JTREGIFY test/compiler/7177917/Test7177917.java - JDK-8031625: javadoc problems referencing inner class constructors - JDK-8035493: JVMTI PopFrame capability must instruct compilers not to prune locals - JDK-8036088: Replace strtok() with its safe equivalent strtok_s() in DefaultProxySelector.c - JDK-8039082: [TEST_BUG] Test java/awt/dnd/BadSerializationTest/BadSerializationTest.java fails - JDK-8075774: Small readability and performance improvements for zipfs - JDK-8132206: move ScanTest.java into OpenJDK - JDK-8132376: Add @requires os.family to the client tests with access to internal OS-specific API - JDK-8132745: minor cleanup of java/util/Scanner/ScanTest.java - JDK-8137087: [TEST_BUG] Cygwin failure of java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh - JDK-8145808: java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java hangs on Win. 8 - JDK-8151788: NullPointerException from ntlm.Client.type3 - JDK-8151834: Test SmallPrimeExponentP.java times out intermittently - JDK-8153430: jdk regression test MletParserLocaleTest, ParserInfiniteLoopTest reduce default timeout - JDK-8153583: Make OutputAnalyzer.reportDiagnosticSummary public - JDK-8156169: Some sound tests rarely hangs because of incorrect synchronization - JDK-8165936: Potential Heap buffer overflow when seaching timezone info files - JDK-8166148: Fix for JDK-8165936 broke solaris builds - JDK-8167300: Scheduling failures during gcm should be fatal - JDK-8167615: Opensource unit/regression tests for JavaSound - JDK-8172012: [TEST_BUG] delays needed in javax/swing/JTree/4633594/bug4633594.java - JDK-8177628: Opensource unit/regression tests for ImageIO - JDK-8183341: Better cleanup for javax/imageio/AllowSearch.java - JDK-8183351: Better cleanup for jdk/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh - JDK-8193137: Nashorn crashes when given an empty script file - JDK-8194298: Add support for per Socket configuration of TCP keepalive - JDK-8198004: javax/swing/JFileChooser/6868611/bug6868611.java throws error - JDK-8200313: java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails - JDK-8203481: Incorrect constraint for unextended_sp in frame:safe_for_sender - JDK-8210147: adjust some WSAGetLastError usages in windows network coding - JDK-8211714: Need to update vm_version.cpp to recognise VS2017 minor versions - JDK-8214862: assert(proj != __null) at compile.cpp:3251 - JDK-8217606: LdapContext#reconnect always opens a new connection - JDK-8217647: JFR: recordings on 32-bit systems unreadable - JDK-8226697: Several tests which need the @key headful keyword are missing it. - JDK-8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow - JDK-8230303: JDB hangs when running monitor command - JDK-8230711: ConnectionGraph::unique_java_object(Node* N) return NULL if n is not in the CG - JDK-8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing - JDK-8234617: C1: Incorrect result of field load due to missing narrowing conversion - JDK-8235243: handle VS2017 15.9 and VS2019 in abstract_vm_version - JDK-8235325: build failure on Linux after 8235243 - JDK-8235687: Contents/MacOS/libjli.dylib cannot be a symlink - JDK-8237951: CTW: C2 compilation fails with "malformed control flow" - JDK-8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary - JDK-8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD - JDK-8239819: XToolkit: Misread of screen information memory - JDK-8240295: hs_err elapsed time in seconds is not accurate enough - JDK-8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one - JDK-8242498: Invalid "sun.awt.TimedWindowEvent" object leads to JVM crash - JDK-8243489: Thread CPU Load event may contain wrong data for CPU time under certain conditions - JDK-8244818: Java2D Queue Flusher crash while moving application window to external monitor - JDK-8246310: Clean commented-out code about ModuleEntry andPackageEntry in JFR - JDK-8246384: Enable JFR by default on supported architectures for October 2020 release - JDK-8248643: Remove extra leading space in JDK-8240295 8u backport - JDK-8249610: Make sun.security.krb5.Config.getBooleanObject(String... keys) method public Main issues of note: src/share/vm/opto/node.{c,h}pp already had find_out_with, introduced upstream in 8u272-b01 by JDK-8237951, so the local duplicate was removed to minimise the diff with 8u272. diffstat for root b/.hgtags | 2 + b/common/autoconf/generated-configure.sh | 40 +++++++++++++------------------ b/common/autoconf/jdk-options.m4 | 24 ++++++++++++------ 3 files changed, 36 insertions(+), 30 deletions(-) diffstat for corba b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jaxp b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for jaxws b/.hgtags | 2 ++ 1 file changed, 2 insertions(+) diffstat for langtools b/.hgtags | 2 b/src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java | 5 - b/src/share/classes/com/sun/tools/javadoc/SeeTagImpl.java | 5 - b/test/com/sun/javadoc/testConstructors/TestConstructors.java | 31 +++++++++- b/test/com/sun/javadoc/testConstructors/pkg1/Outer.java | 13 +++- 5 files changed, 49 insertions(+), 7 deletions(-) diffstat for nashorn b/.hgtags | 2 + b/src/jdk/nashorn/tools/Shell.java | 2 - b/test/script/nosecurity/JDK-8193137.js | 62 ++++++++++++++++++++++++++++++++ 3 files changed, 65 insertions(+), 1 deletion(-) diffstat for jdk a/test/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java | 75 b/.hgtags | 2 b/make/Bundles.gmk | 8 b/make/mapfiles/libnet/mapfile-vers | 7 b/src/macosx/bin/java_md_macosx.c | 22 b/src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m | 1 b/src/share/classes/com/sun/jndi/ldap/LdapCtx.java | 5 b/src/share/classes/com/sun/media/sound/AbstractDataLine.java | 9 b/src/share/classes/com/sun/media/sound/AbstractLine.java | 4 b/src/share/classes/com/sun/media/sound/AbstractMidiDevice.java | 8 b/src/share/classes/com/sun/media/sound/MidiInDevice.java | 4 b/src/share/classes/com/sun/media/sound/RealTimeSequencer.java | 6 b/src/share/classes/com/sun/security/ntlm/NTLM.java | 2 b/src/share/classes/com/sun/tools/example/debug/tty/TTY.java | 3 b/src/share/classes/javax/sound/midi/Sequence.java | 12 b/src/share/classes/jdk/net/ExtendedSocketOptions.java | 64 b/src/share/classes/jdk/net/Sockets.java | 6 b/src/share/classes/sun/net/ExtendedOptionsHelper.java | 54 b/src/share/classes/sun/net/ExtendedOptionsImpl.java | 8 b/src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java | 4 b/src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java | 4 b/src/share/classes/sun/nio/ch/Net.java | 44 b/src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java | 2 b/src/share/classes/sun/nio/ch/SocketChannelImpl.java | 4 b/src/share/classes/sun/security/krb5/Config.java | 5 b/src/share/classes/sun/security/krb5/KrbAsReqBuilder.java | 93 b/src/share/classes/sun/security/krb5/KrbKdcRep.java | 18 b/src/share/classes/sun/security/validator/PKIXValidator.java | 14 b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java | 13 b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java | 12 b/src/share/lib/security/java.security-aix | 15 b/src/share/lib/security/java.security-linux | 15 b/src/share/lib/security/java.security-macosx | 15 b/src/share/lib/security/java.security-solaris | 15 b/src/share/lib/security/java.security-windows | 15 b/src/solaris/back/linker_md.c | 24 b/src/solaris/classes/java/net/PlainSocketImpl.java | 62 b/src/solaris/classes/sun/awt/X11/XIconWindow.java | 25 b/src/solaris/classes/sun/awt/X11/XToolkit.java | 9 b/src/solaris/native/java/net/ExtendedOptionsImpl.c | 188 + b/src/solaris/native/java/util/TimeZone_md.c | 9 b/src/solaris/native/sun/xawt/XToolkit.c | 9 b/src/windows/back/linker_md.c | 24 b/src/windows/native/java/net/ExtendedOptionsImpl.c | 78 b/src/windows/native/java/net/Inet4AddressImpl.c | 2 b/src/windows/native/java/net/Inet6AddressImpl.c | 2 b/src/windows/native/java/net/SocketInputStream.c | 3 b/src/windows/native/sun/net/spi/DefaultProxySelector.c | 7 b/src/windows/native/sun/windows/awt_Window.cpp | 31 b/test/ProblemList.txt | 7 b/test/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java | 7 b/test/com/sun/java/swing/plaf/gtk/4928019/bug4928019.java | 1 b/test/com/sun/java/swing/plaf/gtk/Test6635110.java | 1 b/test/com/sun/java/swing/plaf/gtk/Test6963870.java | 1 b/test/com/sun/jndi/ldap/LdapCtx/Reconnect.java | 117 b/test/com/sun/jndi/ldap/lib/BaseLdapServer.java | 275 + b/test/com/sun/jndi/ldap/lib/LdapMessage.java | 228 + b/test/java/awt/EmbeddedFrame/DisplayChangedTest/DisplayChangedTest.java | 96 b/test/java/awt/EmbeddedFrame/EmbeddedFrameGrabTest/EmbeddedFrameGrabTest.java | 123 b/test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java | 11 b/test/java/awt/Gtk/GtkVersionTest/GtkVersionTest.java | 9 b/test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java | 1 b/test/java/awt/SplashScreen/FullscreenAfterSplash/FullScreenAfterSplash.java | 1 b/test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh | 10 b/test/java/awt/dnd/BadSerializationTest/BadSerializationTest.java | 168 + b/test/java/net/SocketOption/TcpKeepAliveTest.java | 119 b/test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java | 17 b/test/java/nio/channels/AsynchronousSocketChannel/Basic.java | 25 b/test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java | 18 b/test/java/nio/channels/SocketChannel/SocketOptionTests.java | 29 b/test/java/util/Scanner/ScanTest.java | 1502 ++++++++++ b/test/java/util/Scanner/input.txt | 438 ++ b/test/javax/imageio/AllowSearch.java | 88 b/test/javax/imageio/AppContextTest.java | 140 b/test/javax/imageio/AppletResourceTest.html | 40 b/test/javax/imageio/AppletResourceTest.java | 439 ++ b/test/javax/imageio/GetNumImages.java | 96 b/test/javax/imageio/GetReaderWriterInfo.java | 113 b/test/javax/imageio/IIOImageConstructor.java | 46 b/test/javax/imageio/ITSDataType.java | 79 b/test/javax/imageio/ImageIOGetImageReaders.java | 46 b/test/javax/imageio/ImageIOWriteFile.java | 78 b/test/javax/imageio/ImageIOWriteNull.java | 45 b/test/javax/imageio/ImageReadParamPasses.java | 101 b/test/javax/imageio/ImageReaderGetDestination.java | 132 b/test/javax/imageio/ImageReaderReadAll.java | 120 b/test/javax/imageio/ImageStreamFromRAF.java | 67 b/test/javax/imageio/ImageTypeSpecifierBitsPerBand.java | 60 b/test/javax/imageio/ImageTypeSpecifierTest.java | 310 ++ b/test/javax/imageio/ImageWriteParamMisc.java | 105 b/test/javax/imageio/NullInputOutput.java | 73 b/test/javax/imageio/PNGSpiStreamMetadata.java | 66 b/test/javax/imageio/PNGSuffixes.java | 42 b/test/javax/imageio/ReadBitsTest.java | 90 b/test/javax/imageio/SetOutput.java | 54 b/test/javax/imageio/WriteNullImageTest.java | 89 b/test/javax/imageio/event/WriteProgressListenerTest.java | 154 + b/test/javax/imageio/plugins/bmp/BMPCompressionTest.java | 432 ++ b/test/javax/imageio/plugins/bmp/BMPPluginTest.java | 241 + b/test/javax/imageio/plugins/bmp/BMPWriteParamTest.java | 175 + b/test/javax/imageio/plugins/bmp/BmpBigDestinationTest.java | 106 b/test/javax/imageio/plugins/bmp/BmpDefaultImageMetadataTest.java | 151 + b/test/javax/imageio/plugins/bmp/CompressionModeTest.java | 96 b/test/javax/imageio/plugins/bmp/EmbeddedFormatTest.java | 147 b/test/javax/imageio/plugins/bmp/EmptyInputBmpMetadataTest.java | 62 b/test/javax/imageio/plugins/bmp/NoExtraBytesTest.java | 301 ++ b/test/javax/imageio/plugins/bmp/RLECompressionTest.java | 159 + b/test/javax/imageio/plugins/bmp/ReaderListenersTest.java | 257 + b/test/javax/imageio/plugins/bmp/RleEncodingTest.java | 223 + b/test/javax/imageio/plugins/bmp/TestCompressionBI_BITFIELDS.java | 181 + b/test/javax/imageio/plugins/bmp/Write3ByteBgrTest.java | 228 + b/test/javax/imageio/plugins/bmp/WriteProgressListenerTest.java | 176 + b/test/javax/imageio/plugins/bmp/WritingColorChangeTest.java | 194 + b/test/javax/imageio/plugins/gif/AnimationTest.java | 168 + b/test/javax/imageio/plugins/gif/DisableCompressionTest.java | 100 b/test/javax/imageio/plugins/gif/EndWriteSequenceTest.java | 90 b/test/javax/imageio/plugins/gif/IndexingTest.java | 134 b/test/javax/imageio/plugins/gif/LogicalScreenDimensionTest.java | 107 b/test/javax/imageio/plugins/gif/OddPaletteTest.java | 123 b/test/javax/imageio/plugins/gif/PrepareWriteSequenceTest.java | 60 b/test/javax/imageio/plugins/gif/RGBAnimationTest.java | 199 + b/test/javax/imageio/plugins/gif/RGBImageTest.java | 116 b/test/javax/imageio/plugins/gif/StreamMetadataTest.java | 78 b/test/javax/imageio/plugins/gif/TransparencyTest.java | 145 b/test/javax/imageio/plugins/gif/UshortOutOfMemoryTest.java | 77 b/test/javax/imageio/plugins/gif/WriteMetadataTest.java | 81 b/test/javax/imageio/plugins/gif/WriterResetTest.java | 79 b/test/javax/imageio/plugins/gif/WriterReuseTest.java | 157 + b/test/javax/imageio/plugins/jpeg/ByteBinaryTest.java | 93 b/test/javax/imageio/plugins/jpeg/CanEncodeIndexed.java | 55 b/test/javax/imageio/plugins/jpeg/CompressionBug.java | 120 b/test/javax/imageio/plugins/jpeg/CompressionVals.java | 47 b/test/javax/imageio/plugins/jpeg/CrashAfterDispose.java | 135 b/test/javax/imageio/plugins/jpeg/DestTypeTest.java | 157 + b/test/javax/imageio/plugins/jpeg/JPEGsNotAcceleratedTest.java | 365 ++ b/test/javax/imageio/plugins/jpeg/MergeTreeTest.java | 71 b/test/javax/imageio/plugins/jpeg/RasterWithMinXTest.java | 111 b/test/javax/imageio/plugins/jpeg/ResetOutOfMemory.java | 45 b/test/javax/imageio/plugins/jpeg/UshortGrayTest.java | 92 b/test/javax/imageio/plugins/png/CanEncodeShort.java | 66 b/test/javax/imageio/plugins/png/ImageCompare.java | 62 b/test/javax/imageio/plugins/png/PngPremultAlphaTest.java | 131 b/test/javax/imageio/plugins/png/ShortPaletteTest.java | 83 b/test/javax/imageio/plugins/png/WriteProgressive.java | 83 b/test/javax/imageio/plugins/wbmp/EmptyInputWbmpMetadataTest.java | 61 b/test/javax/imageio/plugins/wbmp/GetImageTypesTest.java | 68 b/test/javax/imageio/plugins/wbmp/ValidWbmpTest.java | 93 b/test/javax/imageio/plugins/wbmp/WBMPPluginTest.java | 230 + b/test/javax/imageio/plugins/wbmp/WbmpBigDestinationTest.java | 106 b/test/javax/imageio/plugins/wbmp/WbmpDefaultImageMetadataTest.java | 152 + b/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh | 280 + b/test/javax/imageio/spi/AppletContextTest/DummyReaderPluginSpi.java | 82 b/test/javax/imageio/spi/AppletContextTest/IIOPluginTest.java | 62 b/test/javax/imageio/spi/CreateMemoryCacheOutputStream.java | 52 b/test/javax/imageio/spi/DeregisterAllSpiTest.java | 158 + b/test/javax/imageio/spi/DeregisterOrderedSpiTest.java | 65 b/test/javax/imageio/spi/OrderingTest.java | 70 b/test/javax/imageio/spi/PluginSpiTest.java | 91 b/test/javax/imageio/spi/RegisterPluginTwiceTest.java | 160 + b/test/javax/imageio/spi/SpiTest.java | 390 ++ b/test/javax/imageio/spi/SpiVersionNumbers.java | 60 b/test/javax/imageio/stream/BitPadding.java | 58 b/test/javax/imageio/stream/DeleteOnExitTest.java | 75 b/test/javax/imageio/stream/DeleteOnExitTest.sh | 69 b/test/javax/imageio/stream/FileCacheImageInputStreamNullTest.java | 49 b/test/javax/imageio/stream/FlushBefore.java | 64 b/test/javax/imageio/stream/MemoryCacheImageOutputStreamTest.java | 115 b/test/javax/imageio/stream/ReadBytesIIOByteBuffer.java | 56 b/test/javax/imageio/stream/ReadFullyTest.java | 146 b/test/javax/imageio/stream/ReadUnsignedIntTest.java | 62 b/test/javax/imageio/stream/StreamFlush.java | 108 b/test/javax/imageio/stream/WriteBitsTest.java | 110 b/test/javax/management/loading/ParserInfiniteLoopTest.java | 6 b/test/javax/sound/midi/Devices/ClosedReceiver.java | 184 + b/test/javax/sound/midi/Devices/IOLoop.java | 404 ++ b/test/javax/sound/midi/Devices/MidiDeviceGetReceivers.java | 187 + b/test/javax/sound/midi/Devices/MidiIO.java | 92 b/test/javax/sound/midi/Devices/MidiOutGetMicrosecondPositionBug.java | 135 b/test/javax/sound/midi/Devices/OpenClose.java | 611 ++++ b/test/javax/sound/midi/Devices/ReceiverTransmitterAvailable.java | 113 b/test/javax/sound/midi/Devices/Reopen.java | 135 b/test/javax/sound/midi/File/SMFCp037.java | 60 b/test/javax/sound/midi/File/SMFParserBreak.java | 109 b/test/javax/sound/midi/File/WriteRealTimeMessageNPE.java | 74 b/test/javax/sound/midi/MetaMessage/MetaMessageClone.java | 76 b/test/javax/sound/midi/MidiSystem/6411624/Test6411624.java | 384 ++ b/test/javax/sound/midi/MidiSystem/6411624/bug6411624.java | 244 + b/test/javax/sound/midi/MidiSystem/DefaultDevices.java | 226 + b/test/javax/sound/midi/MidiSystem/DefaultProperties.java | 164 + b/test/javax/sound/midi/MidiSystem/GetSequencer.java | 128 b/test/javax/sound/midi/MidiSystem/MidiFileTypeUniqueness.java | 51 b/test/javax/sound/midi/MidiSystem/ProviderCacheing.java | 65 b/test/javax/sound/midi/MidiSystem/testdata/lib/conf/sound.properties | 27 b/test/javax/sound/midi/Sequence/GetMicrosecondLength.java | 151 + b/test/javax/sound/midi/Sequence/MidiSMPTE.java | 85 b/test/javax/sound/midi/Sequence/SMPTEDuration.java | 94 b/test/javax/sound/midi/Sequencer/LoopIAE.java | 113 b/test/javax/sound/midi/Sequencer/Looping.java | 315 ++ b/test/javax/sound/midi/Sequencer/MetaCallback.java | 133 b/test/javax/sound/midi/Sequencer/Recording.java | 213 + b/test/javax/sound/midi/Sequencer/SeqRecordDoesNotCopy.java | 117 b/test/javax/sound/midi/Sequencer/SeqRecordsRealTimeEvents.java | 121 b/test/javax/sound/midi/Sequencer/SeqStartRecording.java | 52 b/test/javax/sound/midi/Sequencer/SequencerCacheValues.java | 106 b/test/javax/sound/midi/Sequencer/SequencerSetMuteSolo.java | 170 + b/test/javax/sound/midi/Sequencer/SequencerState.java | 272 + b/test/javax/sound/midi/Sequencer/SetTickPosition.java | 139 b/test/javax/sound/midi/Sequencer/TickLength.java | 211 + b/test/javax/sound/midi/ShortMessage/FastShortMessage.java | 71 b/test/javax/sound/midi/ShortMessage/FastShortMessage2.java | 75 b/test/javax/sound/midi/Soundbanks/ExtraCharInSoundbank.java | 123 b/test/javax/sound/midi/Soundbanks/GetSoundBankIOException.java | 85 b/test/javax/sound/midi/Synthesizer/AsynchronousMidiChannel.java | 147 b/test/javax/sound/midi/Synthesizer/Receiver/bug6186488.java | 89 b/test/javax/sound/midi/Synthesizer/SynthesizerGetLatency.java | 77 b/test/javax/sound/midi/Synthesizer/bug4685396.java | 218 + b/test/javax/sound/midi/Track/TrackAddSameTick.java | 97 b/test/javax/sound/midi/Track/bug6416024.java | 127 b/test/javax/sound/midi/Transmitter/bug6415669.java | 118 b/test/javax/sound/sampled/AudioFileFormat/AudioFileFormatToString.java | 235 + b/test/javax/sound/sampled/AudioFileFormat/Properties.java | 144 b/test/javax/sound/sampled/AudioFileFormat/TypeEquals.java | 44 b/test/javax/sound/sampled/AudioFormat/AudioFormatBitSize.java | 44 b/test/javax/sound/sampled/AudioFormat/EncodingEquals.java | 44 b/test/javax/sound/sampled/AudioFormat/Properties.java | 115 b/test/javax/sound/sampled/AudioInputStream/AISReadFraction.java | 237 + b/test/javax/sound/sampled/AudioInputStream/bug6188860.java | 94 b/test/javax/sound/sampled/AudioSystem/AudioFileTypes/AudioFileTypeUniqueness.java | 52 b/test/javax/sound/sampled/AudioSystem/AudioFileTypes/ShowAudioFileTypes.java | 48 b/test/javax/sound/sampled/AudioSystem/DefaultMixers.java | 198 + b/test/javax/sound/sampled/AudioSystem/DefaultProperties.java | 164 + b/test/javax/sound/sampled/AudioSystem/ProviderCacheing.java | 64 b/test/javax/sound/sampled/AudioSystem/testdata/lib/conf/sound.properties | 27 b/test/javax/sound/sampled/Clip/ClipCloseLoss.java | 163 + b/test/javax/sound/sampled/Clip/ClipFlushCrash.java | 226 + b/test/javax/sound/sampled/Clip/Drain/ClipDrain.java | 126 b/test/javax/sound/sampled/Clip/Duration/ClipDuration.java | 131 b/test/javax/sound/sampled/Clip/Endpoint/ClipSetEndPoint.java | 115 b/test/javax/sound/sampled/Clip/IsRunningHang.java | 117 b/test/javax/sound/sampled/Clip/Open/ClipOpenBug.java | 81 b/test/javax/sound/sampled/Clip/bug5070081.java | 107 b/test/javax/sound/sampled/Clip/bug6251460.java | 138 b/test/javax/sound/sampled/Controls/CompoundControl/ToString.java | 98 b/test/javax/sound/sampled/Controls/FloatControl/FloatControlBug.java | 134 b/test/javax/sound/sampled/DataLine/DataLineInfoNegBufferSize.java | 135 b/test/javax/sound/sampled/DataLine/LineDefFormat.java | 172 + b/test/javax/sound/sampled/DataLine/LongFramePosition.java | 70 b/test/javax/sound/sampled/DirectAudio/TickAtEndOfPlay.java | 97 b/test/javax/sound/sampled/DirectAudio/bug6372428.java | 381 ++ b/test/javax/sound/sampled/FileTypeExtension/FileTypeExtensionTest.java | 62 b/test/javax/sound/sampled/LineEvent/LineInfoNPE.java | 177 + b/test/javax/sound/sampled/Lines/16and32KHz/Has16and32KHz.java | 113 b/test/javax/sound/sampled/Lines/BufferSizeCheck.java | 91 b/test/javax/sound/sampled/Lines/ChangingBuffer.java | 165 + b/test/javax/sound/sampled/Lines/ClickInPlay/ClickInPlay.java | 147 b/test/javax/sound/sampled/Lines/ClickInPlay/Test4218609.java | 380 ++ b/test/javax/sound/sampled/Lines/ClipOpenException.java | 148 b/test/javax/sound/sampled/Lines/FrameSize/FrameSizeTest.java | 70 b/test/javax/sound/sampled/Lines/GetLine.java | 99 b/test/javax/sound/sampled/Lines/SDLwrite.java | 271 + b/test/javax/sound/sampled/Lines/SourceDataLineDefaultBufferSizeCrash.java | 248 + b/test/javax/sound/sampled/Lines/StopStart.java | 282 + b/test/javax/sound/sampled/LinuxBlock/PlaySine.java | 269 + b/test/javax/sound/sampled/LinuxCrash/ClipLinuxCrash.java | 163 + b/test/javax/sound/sampled/LinuxCrash/ClipLinuxCrash2.java | 188 + b/test/javax/sound/sampled/LinuxCrash/SDLLinuxCrash.java | 317 ++ b/test/javax/sound/sampled/Mixers/BogusMixers.java | 71 b/test/javax/sound/sampled/Mixers/BothEndiansAndSigns.java | 136 b/test/javax/sound/sampled/Mixers/DirectSoundRepeatingBuffer/DirectSoundRepeatingBuffer.java | 156 + b/test/javax/sound/sampled/Mixers/DirectSoundRepeatingBuffer/Test4997635.java | 381 ++ b/test/javax/sound/sampled/Mixers/DirectSoundUnderrunSilence/DirectSoundUnderrunSilence.java | 161 + b/test/javax/sound/sampled/Mixers/DirectSoundUnderrunSilence/Test5032020.java | 380 ++ b/test/javax/sound/sampled/Mixers/DisabledAssertionCrash.java | 90 b/test/javax/sound/sampled/Mixers/NoSimpleInputDevice.java | 70 b/test/javax/sound/sampled/Mixers/PhantomMixers.java | 91 b/test/javax/sound/sampled/Mixers/PlugHwMonoAnd8bitAvailable.java | 163 + b/test/javax/sound/sampled/Mixers/UnexpectedIAE.java | 66 b/test/javax/sound/sampled/Recording/TargetDataLineFlush.java | 204 + b/test/javax/sound/sampled/spi/AudioFileReader/AIFFCp037.java | 127 b/test/javax/sound/sampled/spi/AudioFileReader/AIFFLargeHeader.java | 109 b/test/javax/sound/sampled/spi/AudioFileReader/Aiff12bit.java | 78 b/test/javax/sound/sampled/spi/AudioFileReader/AuNotSpecified.java | 61 b/test/javax/sound/sampled/spi/AudioFileReader/AuZeroLength.java | 98 b/test/javax/sound/sampled/spi/AudioFileReader/OpenWaveFile.java | 125 b/test/javax/sound/sampled/spi/AudioFileWriter/AUwithULAW.java | 66 b/test/javax/sound/sampled/spi/AudioFileWriter/AiffSampleRate.java | 96 b/test/javax/sound/sampled/spi/AudioFileWriter/RIFFHeader.java | 83 b/test/javax/sound/sampled/spi/AudioFileWriter/WaveBigEndian.java | 98 b/test/javax/sound/sampled/spi/AudioFileWriter/WriteAuUnspecifiedLength.java | 47 b/test/javax/sound/sampled/spi/FormatConversionProvider/AlawUlaw.java | 205 + b/test/javax/swing/JFileChooser/6868611/bug6868611.java | 85 b/test/javax/swing/JTree/4633594/JTreeFocusTest.java | 232 + b/test/jdk/tools/launcher/JliLaunchTest.java | 73 b/test/jdk/tools/launcher/JliLaunchTest.sh | 33 b/test/jdk/tools/launcher/exeJliLaunchTest.c | 44 b/test/lib/jdk/test/lib/Platform.java | 15 b/test/sun/net/www/protocol/http/NULLTargetInfoTest.java | 57 b/test/sun/security/krb5/auto/ReferralsTest.java | 40 b/test/sun/security/mscapi/SmallPrimeExponentP.java | 68 299 files changed, 34050 insertions(+), 333 deletions(-) diffstat for hotspot b/.hgtags | 2 b/src/share/vm/c1/c1_GraphBuilder.cpp | 23 + b/src/share/vm/c1/c1_Instruction.cpp | 2 b/src/share/vm/c1/c1_ValueStack.cpp | 2 b/src/share/vm/c1/c1_ValueStack.hpp | 2 b/src/share/vm/ci/ciEnv.cpp | 43 ++- b/src/share/vm/ci/ciEnv.hpp | 4 b/src/share/vm/ci/ciMethod.cpp | 2 b/src/share/vm/jfr/jni/jfrJavaSupport.cpp | 4 b/src/share/vm/jfr/metadata/metadata.xml | 24 - b/src/share/vm/jfr/periodic/jfrThreadCPULoadEvent.cpp | 5 b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp | 16 - b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointWriter.hpp | 14 - b/src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp | 2 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.cpp | 83 ------ b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.hpp | 7 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp | 2 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp | 12 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp | 4 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp | 6 b/src/share/vm/jfr/recorder/repository/jfrChunkState.cpp | 10 b/src/share/vm/jfr/recorder/repository/jfrChunkState.hpp | 21 - b/src/share/vm/jfr/recorder/repository/jfrChunkWriter.cpp | 17 - b/src/share/vm/jfr/recorder/repository/jfrChunkWriter.hpp | 10 b/src/share/vm/jfr/recorder/repository/jfrEmergencyDump.cpp | 7 b/src/share/vm/jfr/recorder/repository/jfrRepository.cpp | 30 +- b/src/share/vm/jfr/recorder/repository/jfrRepository.hpp | 2 b/src/share/vm/jfr/recorder/service/jfrRecorderService.cpp | 24 - b/src/share/vm/jfr/writers/jfrEventWriterHost.inline.hpp | 2 b/src/share/vm/jfr/writers/jfrPosition.hpp | 4 b/src/share/vm/jfr/writers/jfrPosition.inline.hpp | 4 b/src/share/vm/jfr/writers/jfrStreamWriterHost.hpp | 8 b/src/share/vm/jfr/writers/jfrStreamWriterHost.inline.hpp | 10 b/src/share/vm/jfr/writers/jfrWriterHost.hpp | 10 b/src/share/vm/jfr/writers/jfrWriterHost.inline.hpp | 23 - b/src/share/vm/opto/c2compiler.cpp | 2 b/src/share/vm/opto/callnode.cpp | 8 b/src/share/vm/opto/callnode.hpp | 2 b/src/share/vm/opto/compile.cpp | 27 + b/src/share/vm/opto/compile.hpp | 1 b/src/share/vm/opto/escape.cpp | 5 b/src/share/vm/opto/graphKit.cpp | 2 b/src/share/vm/opto/node.cpp | 25 + b/src/share/vm/opto/node.hpp | 5 b/src/share/vm/opto/phaseX.cpp | 27 - b/src/share/vm/runtime/os.cpp | 7 b/src/share/vm/runtime/vm_version.cpp | 16 + b/test/compiler/7177917/Test7177917.java | 8 b/test/compiler/conversions/Conversion.jasm | 130 +++++++++ b/test/compiler/conversions/TestPrimitiveConversions.java | 60 ++++ b/test/compiler/inlining/StringConcatInfiniteLoop.java | 54 +++ b/test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java | 14 - b/test/vmTestbase/nsk/jdb/monitor/monitor002/monitor002.java | 136 ++++++++++ b/test/vmTestbase/nsk/jdb/monitor/monitor002/monitor002a.java | 52 +++ 54 files changed, 706 insertions(+), 316 deletions(-) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le, aarch32 (Zero) & aarch64. Present in Fedora rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1578325 Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From Monica.Beckwith at microsoft.com Mon Aug 3 22:29:50 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Mon, 3 Aug 2020 22:29:50 +0000 Subject: [aarch64-port-dev ] RFR(S) 8248660: AArch64: JDK-Windows: Make _clear_cache and _nop portable Message-ID: Hi all, could I please get a review for the following webrev? I had previously sent this out for feedback and Kim had provided feedback on the usual way to handle such changes: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-July/009272.html I have made the needful changes and ran them through JTREG for linux-aarch64, windows-aarch64, windows-x86-64, and linux-x86-64. Webrev: http://cr.openjdk.java.net/~mbeckwit/8248660/webrev.01/ JBS: https://bugs.openjdk.java.net/browse/JDK-8248660 I wanted to highlight a small change that I made: - For void __builtin___clear_cache (void *begin, void *end); the `begin` is inclusive, and `end` is exclusive [1]. - Hence for icache_linux_aarch64.hpp?s invalidate_word(), I changed the end to `addr + 4` which previously was `addr + 3`. So it now reads: __builtin___clear_cache((char *)addr, (char *)(addr + 4)); Although there is forced instruction alignment on Arm64, I still felt I should correct the "victimless crime" (as one of our kernel experts puts it. ??) Regards, -Monica [1]: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html From luhenry at microsoft.com Tue Aug 4 04:23:11 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Tue, 4 Aug 2020 04:23:11 +0000 Subject: [aarch64-port-dev ] RFR[XXS] 8248672: utilities: Introduce DEPRECATED macro for GCC and MSVC In-Reply-To: References: <5e301790-8bfe-0ced-b5e2-8a9c76ae33de@oracle.com> <1259c3fd-b69c-6d81-0427-cb769f00bca5@redhat.com> , <116277BD-EA21-49AA-8DE1-DBC06ED43C43@oracle.com> Message-ID: Hello, A quick follow up on that change. Webrev: http://cr.openjdk.java.net/~luhenry/8248672/webrev.01/8248672.patch Thank you, Ludovic From shade at redhat.com Tue Aug 4 08:13:59 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Aug 2020 10:13:59 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b01 Upstream Sync In-Reply-To: <20200803171250.GA263856@stopbrexit> References: <20200803171250.GA263856@stopbrexit> Message-ID: <05f4fb9e-b06c-1a7b-551d-3e0d57565b29@redhat.com> On 8/3/20 7:12 PM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/jaxws/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/jdk/merge.changeset Ooof. Lots of new tests. Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/hotspot/merge.changeset Looks good. The node.{c|h}pp merge looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/langtools/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/nashorn/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/root/merge.changeset Looks good. > Ok to push? Yes. -- Thanks, -Aleksey From adinn at redhat.com Tue Aug 4 08:26:24 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Aug 2020 09:26:24 +0100 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 In-Reply-To: References: Message-ID: <579670ed-eb7c-abec-063f-e3f9768baa25@redhat.com> Hi Felix, Sure, it's ok to push this now. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 03/08/2020 13:43, Yangfei (Felix) wrote: > Hi, > > This 8u-aarch64 backport has been discussed and approved by aph before in: > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2019-June/007463.html > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171537 > Original jdk9 patch: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a3bd5804b4be > Original review thread: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2016-December/004036.html > > This bug is still reproducible with the following test (copied from test/hotspot/jtreg/compiler/c1/Test6849574.java in jdk9+): > > $ cat Test6849574.java > import java.util.concurrent.atomic.AtomicReferenceArray; > > public class Test6849574 extends Thread { > > public static void main(String[] args) { > AtomicReferenceArray a = new AtomicReferenceArray(10000); > for (int i = 0; i < 100000; i++) { > a.getAndSet(9999, new Object()); > if (i > 99990) System.gc(); > } > } > } > > $ java -XX:TieredStopAtLevel=1 -XX:MaxInlineSize=50 Test6849574 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error (assembler_aarch64.hpp:237), pid=2965, tid=0x0000fffebc4dd1e0 > # guarantee(val < (1U << nbits)) failed: Field too big for insn > # > # JRE version: OpenJDK Runtime Environment (8.0) (build 1.8.0-internal-yangfei_2020_08_03_20_20-b00) > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00 mixed mode linux-aarch64 compressed oops) > # Core dump written. Default location: /home/yangfei/test/core or core.2965 > ...... > > 8u-aarch64 backport is simpile: > diff -r e385349cb315 src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp > --- a/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Fri Jul 08 17:11:37 2016 +0100 > +++ b/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp Mon Aug 03 20:36:04 2020 +0800 > @@ -3145,7 +3145,7 @@ > } > > void LIR_Assembler::atomic_op(LIR_Code code, LIR_Opr src, LIR_Opr data, LIR_Opr dest, LIR_Opr tmp_op) { > - Address addr = as_Address(src->as_address_ptr(), noreg); > + Address addr = as_Address(src->as_address_ptr()); > BasicType type = src->type(); > bool is_oop = type == T_OBJECT || type == T_ARRAY; > > Performed full jtreg test with aarch64 release build. Please take another look. > > Thanks, > Felix > From aph at redhat.com Tue Aug 4 10:26:59 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Aug 2020 11:26:59 +0100 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> Message-ID: <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> On 8/3/20 2:18 AM, Yangfei (Felix) wrote: > OK. I simply comment out the following code changes in vm_version_aarch64.cpp: > > 393 if (UseSHA && (auxv & HWCAP_SHA512)) { > 394 // Do not auto-enable UseSHA512Intrinsics until it has been fully tested on hardware > 395 // if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > 396 // FLAG_SET_DEFAULT(UseSHA512Intrinsics, true); > 397 // } > 398 } else if (UseSHA512Intrinsics) { > > Once this has been fully tested on real hardware, it will be easy to auto-enable. > > New webrev: http://cr.openjdk.java.net/~fyang/8165404/webrev.01/ Looks good, thanks. My apologies, there is another thing I should have mentioned: please add test cases for the new instructions to aarch64-asmtest.py and regenerate the code between // BEGIN Generated code -- do not edit // Generated by aarch64-asmtest.py and // END Generated code -- do not edit I'm trying to be more strict about making sure all of the instructions get tested. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 4 10:42:32 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Aug 2020 11:42:32 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Monica Beckwith Message-ID: I hereby nominate Monica Beckwith to Loom Committer. Monica Beckwith leads the team at Microsoft working on the AArch64 port to Windows. They have already pushed some excellent patches to OpenJDK. Only current aarch64-port Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. Votes are due by 12:00 GMT August 18, 2020. For Lazy Consensus voting instructions, see [2]. Thank you! [1] http://openjdk.java.net/census#aarch64-port [2] http://openjdk.java.net/projects/#committer-vote -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 4 10:44:28 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Aug 2020 11:44:28 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Ludovic Henry Message-ID: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> I hereby nominate Ludovic Henry to aarch64-port Committer. Ludovic Henry is a member of the team at Microsoft working on the AArch64 port to Windows. They have already pushed some excellent patches to OpenJDK. Only current aarch64-port Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. Votes are due by 12:00 GMT August 18, 2020. For Lazy Consensus voting instructions, see [2]. Thank you! [1] http://openjdk.java.net/census#aarch64-port [2] http://openjdk.java.net/projects/#committer-vote -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 4 10:45:15 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Aug 2020 11:45:15 +0100 Subject: [aarch64-port-dev ] CORRECTED: CFV: New aarch64-port Committer: Monica Beckwith Message-ID: <1bf72a32-53b4-adb3-f4a3-c1f96ea6cb05@redhat.com> I hereby nominate Monica Beckwith to aarch64-port Committer. Monica Beckwith leads the team at Microsoft working on the AArch64 port to Windows. They have already pushed some excellent patches to OpenJDK. Only current aarch64-port Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. Votes are due by 12:00 GMT August 18, 2020. For Lazy Consensus voting instructions, see [2]. Thank you! [1] http://openjdk.java.net/census#aarch64-port [2] http://openjdk.java.net/projects/#committer-vote -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 4 10:46:28 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 4 Aug 2020 11:46:28 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Bernhard Urban-Forster Message-ID: I hereby nominate Bernhard Urban-Forster to aarch64-port Committer. Bernhard Urban-Forster is a member of the team at Microsoft working on the AArch64 port to Windows. They have already pushed some excellent patches to OpenJDK. Only current aarch64-port Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. Votes are due by 12:00 GMT August 18, 2020. For Lazy Consensus voting instructions, see [2]. Thank you! [1] http://openjdk.java.net/census#aarch64-port [2] http://openjdk.java.net/projects/#committer-vote -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Tue Aug 4 11:03:32 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Aug 2020 12:03:32 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Ludovic Henry In-Reply-To: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> References: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> Message-ID: <3eb76381-eeca-1b82-efa3-85287f61ad29@redhat.com> Vote: yes On 04/08/2020 11:44, Andrew Haley wrote: > I hereby nominate Ludovic Henry to aarch64-port Committer. > > Ludovic Henry is a member of the team at Microsoft working on the > AArch64 port to Windows. They have already pushed some excellent > patches to OpenJDK. > > Only current aarch64-port Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > Votes are due by 12:00 GMT August 18, 2020. > > For Lazy Consensus voting instructions, see [2]. > > Thank you! > > [1] http://openjdk.java.net/census#aarch64-port > [2] http://openjdk.java.net/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Tue Aug 4 11:03:40 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Aug 2020 12:03:40 +0100 Subject: [aarch64-port-dev ] CORRECTED: CFV: New aarch64-port Committer: Monica Beckwith In-Reply-To: <1bf72a32-53b4-adb3-f4a3-c1f96ea6cb05@redhat.com> References: <1bf72a32-53b4-adb3-f4a3-c1f96ea6cb05@redhat.com> Message-ID: Vote: yes On 04/08/2020 11:45, Andrew Haley wrote: > I hereby nominate Monica Beckwith to aarch64-port Committer. > > Monica Beckwith leads the team at Microsoft working on the AArch64 > port to Windows. They have already pushed some excellent patches to > OpenJDK. > > Only current aarch64-port Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > Votes are due by 12:00 GMT August 18, 2020. > > For Lazy Consensus voting instructions, see [2]. > > Thank you! > > [1] http://openjdk.java.net/census#aarch64-port > [2] http://openjdk.java.net/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Tue Aug 4 11:03:50 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 4 Aug 2020 12:03:50 +0100 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Bernhard Urban-Forster In-Reply-To: References: Message-ID: <6e13f6af-22d4-ce87-6a0b-c8dc17398c96@redhat.com> Vote: yes On 04/08/2020 11:46, Andrew Haley wrote: > I hereby nominate Bernhard Urban-Forster to aarch64-port Committer. > > Bernhard Urban-Forster is a member of the team at Microsoft working on > the AArch64 port to Windows. They have already pushed some excellent > patches to OpenJDK. > > Only current aarch64-port Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > Votes are due by 12:00 GMT August 18, 2020. > > For Lazy Consensus voting instructions, see [2]. > > Thank you! > > [1] http://openjdk.java.net/census#aarch64-port > [2] http://openjdk.java.net/projects/#committer-vote > -- regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From shade at redhat.com Tue Aug 4 11:07:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Aug 2020 13:07:12 +0200 Subject: [aarch64-port-dev ] CORRECTED: CFV: New aarch64-port Committer: Monica Beckwith In-Reply-To: <1bf72a32-53b4-adb3-f4a3-c1f96ea6cb05@redhat.com> References: <1bf72a32-53b4-adb3-f4a3-c1f96ea6cb05@redhat.com> Message-ID: <362aa57b-13e1-744f-9478-2f0748e5673f@redhat.com> Vote: yes On 8/4/20 12:45 PM, Andrew Haley wrote: > I hereby nominate Monica Beckwith to aarch64-port Committer. -- Thanks, -Aleksey From shade at redhat.com Tue Aug 4 11:07:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Aug 2020 13:07:23 +0200 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Ludovic Henry In-Reply-To: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> References: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> Message-ID: <42bd91fe-a71e-27b3-cca6-2fc0affc85b0@redhat.com> Vote: yes On 8/4/20 12:44 PM, Andrew Haley wrote: > I hereby nominate Ludovic Henry to aarch64-port Committer. -- Thanks, -Aleksey From shade at redhat.com Tue Aug 4 11:07:36 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 4 Aug 2020 13:07:36 +0200 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Bernhard Urban-Forster In-Reply-To: References: Message-ID: Vote: yes On 8/4/20 12:46 PM, Andrew Haley wrote: > I hereby nominate Bernhard Urban-Forster to aarch64-port Committer. -- Thanks, -Aleksey From zhaixiang at loongson.cn Tue Aug 4 11:56:08 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Tue, 4 Aug 2020 19:56:08 +0800 Subject: [aarch64-port-dev ] Could not find all X11 headers when cross compile jdk8u-aarch64 Message-ID: <1163c3b6-9623-92c5-0713-fe0002601944@loongson.cn> Hi, When cross compile jdk8u-aarch64: sh configure \ --with-sys-root=/chroots/aarch64_rootfs \ --openjdk-target=aarch64-linux-gnu \ --with-debug-level=fastdebug It thrown such error: checking for X... libraries /chroots/aarch64_rootfs/usr/lib64, headers /chroots/aarch64_rootfs/usr/include checking whether -R must be followed by a space... neither works checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking for X11/extensions/shape.h... no configure: error: Could not find all X11 headers (shape.h Xrender.h XTest.h Intrinsic.h). You might be able to fix this by running 'sudo apt-get install libX11-dev libxext-dev libxrender-dev libxtst-dev libxt-dev'. --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- But there are X11 headers, for example: /chroots/aarch64_rootfs/usr/include/X11/extensions/shape.h Workaround: diff -r 3d495dd0314f common/autoconf/libraries.m4 --- a/common/autoconf/libraries.m4 Thu Aug 23 01:55:22 2018 +0100 +++ b/common/autoconf/libraries.m4 Tue Aug 04 19:53:30 2020 +0800 @@ -155,7 +155,7 @@ # Need to include Xlib.h and Xutil.h to avoid "present but cannot be compiled" warnings on Solaris 10 AC_CHECK_HEADERS([X11/extensions/shape.h X11/extensions/Xrender.h X11/extensions/XTest.h X11/Intrinsic.h], [X11_A_OK=yes], - [X11_A_OK=no; break], + [X11_A_OK=yes], [ # include # include Thanks, Leslie Zhai From Monica.Beckwith at microsoft.com Tue Aug 4 16:03:48 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Tue, 4 Aug 2020 16:03:48 +0000 Subject: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC In-Reply-To: References: <3523bae9-7c30-0d77-643a-ca9fc38b4704@arm.com> Message-ID: I have incorporated your comments and added the 'reviewed-by' information. JBS: https://bugs.openjdk.java.net/browse/JDK-8248663 Webrev: http://cr.openjdk.java.net/~mbeckwit/8248663/webrev.01/ Thanks again. -Monica -----Original Message----- From: aarch64-port-dev On Behalf Of Monica Beckwith Sent: Friday, July 24, 2020 12:01 PM To: Stuart Monteith ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC Hi both, thanks. The comments are put in place as I was hoping that down the line, if someone plans to revert the changes, then they have a context that MSVC is going to have issues again. But I do see Stuart's point: to a new reader, the comment by itself may seem strange. -Monica -----Original Message----- From: aarch64-port-dev On Behalf Of Stuart Monteith Sent: Friday, July 24, 2020 10:52 AM To: aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC Hello, I don't think "// `DIFFERENCE` is an MSVC macro" is a useful comment, as DIFFERENCE has been removed. It makes sense in context. I like the "mvn" comment, as that does help. Thanks, Stuart On 24/07/2020 16:26, Derek White wrote: > Hi Monica, > > Looks good! > > Style comment - I'm not sure if the comments about MSVC in c2_MacroAssembler_aarch64.cpp and macroAssembler_aarch64.hpp are strictly necessary, but I don't have a strong opinion. > > - Derek > > -----Original Message----- > From: aarch64-port-dev On > Behalf Of Monica Beckwith > Sent: Friday, July 24, 2020 11:10 AM > To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > > Cc: openjdk-aarch64 > Subject: [EXT] Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: > AArch64: Avoid existing macros/keywords of MSVC > > External Email > > ---------------------------------------------------------------------- > Hello all - could I please get feedback on the following changes? > > Copying clean links here again: > JBS: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__bugs.openjdk.java.net > _browse_JDK-2D8248663%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtfQ%26r%3D > gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9nlZWYqA0 > RgBcfPqzSx1Pz12OUdX6TQc%26s%3D-1BKo7dfMxAqI0c80NeOgXxY4Kig4HV6N_342REu > HTc%26e%3D&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C907a0f > d42b2d4b0b7e0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C637312027651961479&sdata=trv1jqoIr7HIWJV7ZCjyppC5a9%2FTldLemsNHj > ztpDHM%3D&reserved=0 > Webrev: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__cr.openjdk.java.net_- > 7Embeckwit_8248663_webrev.00_%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtf > Q%26r%3DgW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9 > nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc%26s%3DFDH2O5mbnaWupPL9AiRQqpDl1glFLtf1 > vP02BQvfmXM%26e%3D&data=02%7C01%7Cmonica.beckwith%40microsoft.com% > 7C907a0fd42b2d4b0b7e0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47% > 7C1%7C0%7C637312027651961479&sdata=koVux%2FcolGpd4FCHL%2FUmYcJEzol > g3huK7ulwLBgxlwc%3D&reserved=0 > > Thanks, > Monica > > > -----Original Message----- > From: Monica Beckwith > Sent: Thursday, July 16, 2020 2:40 PM > To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > > Cc: openjdk-aarch64 > Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing > macros/keywords of MSVC > > These changes are concerning specific macro names or keywords used by MSVC. E.g. `mvn,` `DIFFERENCE` and `far.` We are proposing to change those in the shared code. > > JBS: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.prote > ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Fbugs.openjdk.java.net-2 > 52Fbrowse-252FJDK-2D8248663-26amp-3Bdata-3D02-257C01-257CMonica.Beckwi > th-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9d-257C72f988bf > 86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976662-26amp-3Bsd > ata-3DjGxT7lMPEEg7iJPgoflgEByvHnuZEof-252BBqPrGfQhulg-253D-26amp-3Bres > erved-3D0%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtfQ%26r%3DgW0hANMfJfyE > LYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9nlZWYqA0RgBcfPqzSx1P > z12OUdX6TQc%26s%3D6CkQlp-iwC2nuFgVxfwZjp0Kf9x-WqzQG-ksCF6H3eo%26e%3D&a > mp;data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C907a0fd42b2d4b0b7e > 0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373120276 > 51961479&sdata=VBONdqiyV6b7U%2Bqeami9xMgoP7u0qZHyX75AgHknXPA%3D&am > p;reserved=0 > Webrev: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.prote > ction.outlook.com_-3Furl-3Dhttps-3A-252F-252Fcr.openjdk.java.net-252F- > 7Embeckwit-252F8248663-252Fwebrev.00-252F-26amp-3Bdata-3D02-257C01-257 > CMonica.Beckwith-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9 > d-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976 > 662-26amp-3Bsdata-3D28VwNHmLsoJcJRJ1OjBNH154-252BRB4QADUJHGz2Eh5M-252B > k-253D-26amp-3Breserved-3D0%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtfQ% > 26r%3DgW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9nl > ZWYqA0RgBcfPqzSx1Pz12OUdX6TQc%26s%3DFIrIXam-q51NnhIUlid_07RYh5O2xdtG6M > Hz_uSxCro%26e%3D&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C > 907a0fd42b2d4b0b7e0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47%7C > 1%7C0%7C637312027651961479&sdata=Zg1MKDVEMMjsfeC5LXf6EI7d37Gg1f%2B > zYzaPXYAdhDM%3D&reserved=0 > > Thanks, > Monica > From vladimir.kozlov at oracle.com Tue Aug 4 17:29:13 2020 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Tue, 4 Aug 2020 10:29:13 -0700 Subject: [aarch64-port-dev ] RFR[XXS] 8248672: utilities: Introduce DEPRECATED macro for GCC and MSVC In-Reply-To: References: <5e301790-8bfe-0ced-b5e2-8a9c76ae33de@oracle.com> <1259c3fd-b69c-6d81-0427-cb769f00bca5@redhat.com> <116277BD-EA21-49AA-8DE1-DBC06ED43C43@oracle.com> Message-ID: Good. Vladimir K On 8/3/20 9:23 PM, Ludovic Henry wrote: > Hello, > > A quick follow up on that change. > > Webrev: http://cr.openjdk.java.net/~luhenry/8248672/webrev.01/8248672.patch > > Thank you, > Ludovic > From derekw at marvell.com Tue Aug 4 19:41:39 2020 From: derekw at marvell.com (Derek White) Date: Tue, 4 Aug 2020 19:41:39 +0000 Subject: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC In-Reply-To: References: <3523bae9-7c30-0d77-643a-ca9fc38b4704@arm.com> Message-ID: Looks good to me! -----Original Message----- From: aarch64-port-dev On Behalf Of Monica Beckwith Sent: Tuesday, August 4, 2020 12:04 PM To: Monica Beckwith ; Stuart Monteith ; aarch64-port-dev at openjdk.java.net Subject: [EXT] Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC External Email ---------------------------------------------------------------------- I have incorporated your comments and added the 'reviewed-by' information. JBS: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8248663&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=uB6tOAbHkzy_1rd_01j5dBADE-1lSlMJOz__BC-mmRw&s=IMo-ICFJUvQ2jI4kbejshIbA4W0fIEj2x2pKQLnWwP4&e= Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Embeckwit_8248663_webrev.01_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=uB6tOAbHkzy_1rd_01j5dBADE-1lSlMJOz__BC-mmRw&s=UjDK1dnOT1PMXK26CAeOfU7cK0Ej6eKTcOwZgrK5g4U&e= Thanks again. -Monica -----Original Message----- From: aarch64-port-dev On Behalf Of Monica Beckwith Sent: Friday, July 24, 2020 12:01 PM To: Stuart Monteith ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC Hi both, thanks. The comments are put in place as I was hoping that down the line, if someone plans to revert the changes, then they have a context that MSVC is going to have issues again. But I do see Stuart's point: to a new reader, the comment by itself may seem strange. -Monica -----Original Message----- From: aarch64-port-dev On Behalf Of Stuart Monteith Sent: Friday, July 24, 2020 10:52 AM To: aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC Hello, I don't think "// `DIFFERENCE` is an MSVC macro" is a useful comment, as DIFFERENCE has been removed. It makes sense in context. I like the "mvn" comment, as that does help. Thanks, Stuart On 24/07/2020 16:26, Derek White wrote: > Hi Monica, > > Looks good! > > Style comment - I'm not sure if the comments about MSVC in c2_MacroAssembler_aarch64.cpp and macroAssembler_aarch64.hpp are strictly necessary, but I don't have a strong opinion. > > - Derek > > -----Original Message----- > From: aarch64-port-dev On > Behalf Of Monica Beckwith > Sent: Friday, July 24, 2020 11:10 AM > To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > > Cc: openjdk-aarch64 > Subject: [EXT] Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: > AArch64: Avoid existing macros/keywords of MSVC > > External Email > > ---------------------------------------------------------------------- > Hello all - could I please get feedback on the following changes? > > Copying clean links here again: > JBS: > https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.p > rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furld&d=DwIGaQ&c=nKj > Wec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=uB > 6tOAbHkzy_1rd_01j5dBADE-1lSlMJOz__BC-mmRw&s=uW7I8hTNYFXMAU4Z0U21Vrlu4O > KfV0bP5ZBUpw5oIYk&e= > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__bugs.openjdk.java.net > _browse_JDK-2D8248663%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtfQ%26r%3D > gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9nlZWYqA0 > RgBcfPqzSx1Pz12OUdX6TQc%26s%3D-1BKo7dfMxAqI0c80NeOgXxY4Kig4HV6N_342REu > HTc%26e%3D&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C907a0f > d42b2d4b0b7e0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C637312027651961479&sdata=trv1jqoIr7HIWJV7ZCjyppC5a9%2FTldLemsNHj > ztpDHM%3D&reserved=0 > Webrev: > https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.p > rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furld&d=DwIGaQ&c=nKj > Wec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=uB > 6tOAbHkzy_1rd_01j5dBADE-1lSlMJOz__BC-mmRw&s=uW7I8hTNYFXMAU4Z0U21Vrlu4O > KfV0bP5ZBUpw5oIYk&e= > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__cr.openjdk.java.net_- > 7Embeckwit_8248663_webrev.00_%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtf > Q%26r%3DgW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9 > nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc%26s%3DFDH2O5mbnaWupPL9AiRQqpDl1glFLtf1 > vP02BQvfmXM%26e%3D&data=02%7C01%7Cmonica.beckwith%40microsoft.com% > 7C907a0fd42b2d4b0b7e0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47% > 7C1%7C0%7C637312027651961479&sdata=koVux%2FcolGpd4FCHL%2FUmYcJEzol > g3huK7ulwLBgxlwc%3D&reserved=0 > > Thanks, > Monica > > > -----Original Message----- > From: Monica Beckwith > Sent: Thursday, July 16, 2020 2:40 PM > To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > > Cc: openjdk-aarch64 > Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing > macros/keywords of MSVC > > These changes are concerning specific macro names or keywords used by MSVC. E.g. `mvn,` `DIFFERENCE` and `far.` We are proposing to change those in the shared code. > > JBS: > https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.p > rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furld&d=DwIGaQ&c=nKj > Wec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=uB > 6tOAbHkzy_1rd_01j5dBADE-1lSlMJOz__BC-mmRw&s=uW7I8hTNYFXMAU4Z0U21Vrlu4O > KfV0bP5ZBUpw5oIYk&e= > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.prote > ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Fbugs.openjdk.java.net-2 > 52Fbrowse-252FJDK-2D8248663-26amp-3Bdata-3D02-257C01-257CMonica.Beckwi > th-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9d-257C72f988bf > 86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976662-26amp-3Bsd > ata-3DjGxT7lMPEEg7iJPgoflgEByvHnuZEof-252BBqPrGfQhulg-253D-26amp-3Bres > erved-3D0%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtfQ%26r%3DgW0hANMfJfyE > LYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9nlZWYqA0RgBcfPqzSx1P > z12OUdX6TQc%26s%3D6CkQlp-iwC2nuFgVxfwZjp0Kf9x-WqzQG-ksCF6H3eo%26e%3D&a > mp;data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C907a0fd42b2d4b0b7e > 0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373120276 > 51961479&sdata=VBONdqiyV6b7U%2Bqeami9xMgoP7u0qZHyX75AgHknXPA%3D&am > p;reserved=0 > Webrev: > https://urldefense.proofpoint.com/v2/url?u=https-3A__nam06.safelinks.p > rotection.outlook.com_-3Furl-3Dhttps-253A-252F-252Furld&d=DwIGaQ&c=nKj > Wec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=uB > 6tOAbHkzy_1rd_01j5dBADE-1lSlMJOz__BC-mmRw&s=uW7I8hTNYFXMAU4Z0U21Vrlu4O > KfV0bP5ZBUpw5oIYk&e= > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.prote > ction.outlook.com_-3Furl-3Dhttps-3A-252F-252Fcr.openjdk.java.net-252F- > 7Embeckwit-252F8248663-252Fwebrev.00-252F-26amp-3Bdata-3D02-257C01-257 > CMonica.Beckwith-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9 > d-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976 > 662-26amp-3Bsdata-3D28VwNHmLsoJcJRJ1OjBNH154-252BRB4QADUJHGz2Eh5M-252B > k-253D-26amp-3Breserved-3D0%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtfQ% > 26r%3DgW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9nl > ZWYqA0RgBcfPqzSx1Pz12OUdX6TQc%26s%3DFIrIXam-q51NnhIUlid_07RYh5O2xdtG6M > Hz_uSxCro%26e%3D&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C > 907a0fd42b2d4b0b7e0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47%7C > 1%7C0%7C637312027651961479&sdata=Zg1MKDVEMMjsfeC5LXf6EI7d37Gg1f%2B > zYzaPXYAdhDM%3D&reserved=0 > > Thanks, > Monica > From Stuart.Monteith at arm.com Tue Aug 4 22:38:04 2020 From: Stuart.Monteith at arm.com (Stuart Monteith) Date: Tue, 4 Aug 2020 22:38:04 +0000 Subject: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC In-Reply-To: References: <3523bae9-7c30-0d77-643a-ca9fc38b4704@arm.com> , Message-ID: Looks good to me also, thanks. ________________________________ From: Monica Beckwith Sent: 04 August 2020 17:03 To: Monica Beckwith ; Stuart Monteith ; aarch64-port-dev at openjdk.java.net Subject: RE: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC I have incorporated your comments and added the 'reviewed-by' information. JBS: https://bugs.openjdk.java.net/browse/JDK-8248663 Webrev: http://cr.openjdk.java.net/~mbeckwit/8248663/webrev.01/ Thanks again. -Monica -----Original Message----- From: aarch64-port-dev On Behalf Of Monica Beckwith Sent: Friday, July 24, 2020 12:01 PM To: Stuart Monteith ; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC Hi both, thanks. The comments are put in place as I was hoping that down the line, if someone plans to revert the changes, then they have a context that MSVC is going to have issues again. But I do see Stuart's point: to a new reader, the comment by itself may seem strange. -Monica -----Original Message----- From: aarch64-port-dev On Behalf Of Stuart Monteith Sent: Friday, July 24, 2020 10:52 AM To: aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: AArch64: Avoid existing macros/keywords of MSVC Hello, I don't think "// `DIFFERENCE` is an MSVC macro" is a useful comment, as DIFFERENCE has been removed. It makes sense in context. I like the "mvn" comment, as that does help. Thanks, Stuart On 24/07/2020 16:26, Derek White wrote: > Hi Monica, > > Looks good! > > Style comment - I'm not sure if the comments about MSVC in c2_MacroAssembler_aarch64.cpp and macroAssembler_aarch64.hpp are strictly necessary, but I don't have a strong opinion. > > - Derek > > -----Original Message----- > From: aarch64-port-dev On > Behalf Of Monica Beckwith > Sent: Friday, July 24, 2020 11:10 AM > To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > > Cc: openjdk-aarch64 > Subject: [EXT] Re: [aarch64-port-dev ] RFR/Feedback(S) 8248663: > AArch64: Avoid existing macros/keywords of MSVC > > External Email > > ---------------------------------------------------------------------- > Hello all - could I please get feedback on the following changes? > > Copying clean links here again: > JBS: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__bugs.openjdk.java.net > _browse_JDK-2D8248663%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtfQ%26r%3D > gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9nlZWYqA0 > RgBcfPqzSx1Pz12OUdX6TQc%26s%3D-1BKo7dfMxAqI0c80NeOgXxY4Kig4HV6N_342REu > HTc%26e%3D&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C907a0f > d42b2d4b0b7e0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% > 7C637312027651961479&sdata=trv1jqoIr7HIWJV7ZCjyppC5a9%2FTldLemsNHj > ztpDHM%3D&reserved=0 > Webrev: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__cr.openjdk.java.net_- > 7Embeckwit_8248663_webrev.00_%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtf > Q%26r%3DgW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9 > nlZWYqA0RgBcfPqzSx1Pz12OUdX6TQc%26s%3DFDH2O5mbnaWupPL9AiRQqpDl1glFLtf1 > vP02BQvfmXM%26e%3D&data=02%7C01%7Cmonica.beckwith%40microsoft.com% > 7C907a0fd42b2d4b0b7e0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47% > 7C1%7C0%7C637312027651961479&sdata=koVux%2FcolGpd4FCHL%2FUmYcJEzol > g3huK7ulwLBgxlwc%3D&reserved=0 > > Thanks, > Monica > > > -----Original Message----- > From: Monica Beckwith > Sent: Thursday, July 16, 2020 2:40 PM > To: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > > Cc: openjdk-aarch64 > Subject: RFR/Feedback(S) 8248663: AArch64: Avoid existing > macros/keywords of MSVC > > These changes are concerning specific macro names or keywords used by MSVC. E.g. `mvn,` `DIFFERENCE` and `far.` We are proposing to change those in the shared code. > > JBS: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.prote > ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Fbugs.openjdk.java.net-2 > 52Fbrowse-252FJDK-2D8248663-26amp-3Bdata-3D02-257C01-257CMonica.Beckwi > th-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9d-257C72f988bf > 86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976662-26amp-3Bsd > ata-3DjGxT7lMPEEg7iJPgoflgEByvHnuZEof-252BBqPrGfQhulg-253D-26amp-3Bres > erved-3D0%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtfQ%26r%3DgW0hANMfJfyE > LYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9nlZWYqA0RgBcfPqzSx1P > z12OUdX6TQc%26s%3D6CkQlp-iwC2nuFgVxfwZjp0Kf9x-WqzQG-ksCF6H3eo%26e%3D&a > mp;data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C907a0fd42b2d4b0b7e > 0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6373120276 > 51961479&sdata=VBONdqiyV6b7U%2Bqeami9xMgoP7u0qZHyX75AgHknXPA%3D&am > p;reserved=0 > Webrev: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam06.safelinks.prote > ction.outlook.com_-3Furl-3Dhttps-3A-252F-252Fcr.openjdk.java.net-252F- > 7Embeckwit-252F8248663-252Fwebrev.00-252F-26amp-3Bdata-3D02-257C01-257 > CMonica.Beckwith-2540microsoft.com-257C35f78927e915431fbf4d08d829bfff9 > d-257C72f988bf86f141af91ab2d7cd011db47-257C1-257C0-257C637305251886976 > 662-26amp-3Bsdata-3D28VwNHmLsoJcJRJ1OjBNH154-252BRB4QADUJHGz2Eh5M-252B > k-253D-26amp-3Breserved-3D0%26d%3DDwIFAg%26c%3DnKjWec2b6R0mOyPaz7xtfQ% > 26r%3DgW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk%26m%3DVRH-lUr10_r9nl > ZWYqA0RgBcfPqzSx1Pz12OUdX6TQc%26s%3DFIrIXam-q51NnhIUlid_07RYh5O2xdtG6M > Hz_uSxCro%26e%3D&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C > 907a0fd42b2d4b0b7e0808d82fe99ab4%7C72f988bf86f141af91ab2d7cd011db47%7C > 1%7C0%7C637312027651961479&sdata=Zg1MKDVEMMjsfeC5LXf6EI7d37Gg1f%2B > zYzaPXYAdhDM%3D&reserved=0 > > Thanks, > Monica > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From felix.yang at huawei.com Wed Aug 5 00:59:39 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 5 Aug 2020 00:59:39 +0000 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 In-Reply-To: <579670ed-eb7c-abec-063f-e3f9768baa25@redhat.com> References: <579670ed-eb7c-abec-063f-e3f9768baa25@redhat.com> Message-ID: Hi Andrew, > -----Original Message----- > From: Andrew Dinn [mailto:adinn at redhat.com] > Sent: Tuesday, August 4, 2020 4:26 PM > To: Yangfei (Felix) ; aarch64-port- > dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] 8u-aarch64: Backport 8171537: aarch64: > compiler/c1/Test6849574.java generates guarantee failure in C1 > > Hi Felix, > > Sure, it's ok to push this now. Thanks for looking at this. Pushed as: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f4a4edf250cc Felix From felix.yang at huawei.com Wed Aug 5 01:09:28 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 5 Aug 2020 01:09:28 +0000 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Ludovic Henry In-Reply-To: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> References: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> Message-ID: Vote: yes > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev-retn at openjdk.java.net] > On Behalf Of Andrew Haley > Sent: Tuesday, August 4, 2020 6:44 PM > To: aarch64-port-dev at openjdk.java.net > Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Ludovic > Henry > > I hereby nominate Ludovic Henry to aarch64-port Committer. > > Ludovic Henry is a member of the team at Microsoft working on the > AArch64 port to Windows. They have already pushed some excellent patches > to OpenJDK. > > Only current aarch64-port Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > Votes are due by 12:00 GMT August 18, 2020. > > For Lazy Consensus voting instructions, see [2]. > > Thank you! > > [1] http://openjdk.java.net/census#aarch64-port > [2] http://openjdk.java.net/projects/#committer-vote > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Wed Aug 5 01:10:06 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 5 Aug 2020 01:10:06 +0000 Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Bernhard Urban-Forster In-Reply-To: References: Message-ID: Vote: yes > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev-retn at openjdk.java.net] > On Behalf Of Andrew Haley > Sent: Tuesday, August 4, 2020 6:46 PM > To: aarch64-port-dev at openjdk.java.net > Subject: [aarch64-port-dev ] CFV: New aarch64-port Committer: Bernhard > Urban-Forster > > I hereby nominate Bernhard Urban-Forster to aarch64-port Committer. > > Bernhard Urban-Forster is a member of the team at Microsoft working on > the AArch64 port to Windows. They have already pushed some excellent > patches to OpenJDK. > > Only current aarch64-port Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > Votes are due by 12:00 GMT August 18, 2020. > > For Lazy Consensus voting instructions, see [2]. > > Thank you! > > [1] http://openjdk.java.net/census#aarch64-port > [2] http://openjdk.java.net/projects/#committer-vote > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Wed Aug 5 01:10:22 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 5 Aug 2020 01:10:22 +0000 Subject: [aarch64-port-dev ] CORRECTED: CFV: New aarch64-port Committer: Monica Beckwith In-Reply-To: <1bf72a32-53b4-adb3-f4a3-c1f96ea6cb05@redhat.com> References: <1bf72a32-53b4-adb3-f4a3-c1f96ea6cb05@redhat.com> Message-ID: Vote: yes > -----Original Message----- > From: aarch64-port-dev [mailto:aarch64-port-dev-retn at openjdk.java.net] > On Behalf Of Andrew Haley > Sent: Tuesday, August 4, 2020 6:45 PM > To: aarch64-port-dev at openjdk.java.net > Subject: [aarch64-port-dev ] CORRECTED: CFV: New aarch64-port Committer: > Monica Beckwith > > I hereby nominate Monica Beckwith to aarch64-port Committer. > > Monica Beckwith leads the team at Microsoft working on the AArch64 port to > Windows. They have already pushed some excellent patches to OpenJDK. > > Only current aarch64-port Committers [1] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing list. > > Votes are due by 12:00 GMT August 18, 2020. > > For Lazy Consensus voting instructions, see [2]. > > Thank you! > > [1] http://openjdk.java.net/census#aarch64-port > [2] http://openjdk.java.net/projects/#committer-vote > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Wed Aug 5 02:09:35 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Wed, 05 Aug 2020 10:09:35 +0800 Subject: [aarch64-port-dev ] Could not find all X11 headers when cross compile jdk8u-aarch64 In-Reply-To: <1163c3b6-9623-92c5-0713-fe0002601944@loongson.cn> References: <1163c3b6-9623-92c5-0713-fe0002601944@loongson.cn> Message-ID: <857dudkfmo.fsf@nicgas01-pc.shanghai.arm.com> On 08/04/20 19:56 pm, Leslie Zhai wrote: > checking for X11/extensions/shape.h... no > configure: error: Could not find all X11 headers (shape.h Xrender.h > XTest.h Intrinsic.h). You might be able to fix this by running 'sudo > apt-get install libX11-dev libxext-dev libxrender-dev libxtst-dev > libxt-dev'. > > --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- > > But there are X11 headers, for example: > /chroots/aarch64_rootfs/usr/include/X11/extensions/shape.h > > Workaround: Try looking in the config.log file: that will show the failing gcc command line and contents of conftest.c that it used to test. -- Thanks, Nick From zhaixiang at loongson.cn Wed Aug 5 03:03:29 2020 From: zhaixiang at loongson.cn (Leslie Zhai) Date: Wed, 5 Aug 2020 11:03:29 +0800 Subject: [aarch64-port-dev ] Could not find all X11 headers when cross compile jdk8u-aarch64 In-Reply-To: <857dudkfmo.fsf@nicgas01-pc.shanghai.arm.com> References: <1163c3b6-9623-92c5-0713-fe0002601944@loongson.cn> <857dudkfmo.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <2c591152-0571-b644-a0cd-134141fdb732@loongson.cn> Hi Nick, Thanks for your advice! I fixed the X11 headers issue via config.log. Thanks, Leslie Zhai ? 2020?08?05? 10:09, Nick Gasson ??: > On 08/04/20 19:56 pm, Leslie Zhai wrote: >> checking for X11/extensions/shape.h... no >> configure: error: Could not find all X11 headers (shape.h Xrender.h >> XTest.h Intrinsic.h). You might be able to fix this by running 'sudo >> apt-get install libX11-dev libxext-dev libxrender-dev libxtst-dev >> libxt-dev'. >> >> --8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--8<-- >> >> But there are X11 headers, for example: >> /chroots/aarch64_rootfs/usr/include/X11/extensions/shape.h >> >> Workaround: > Try looking in the config.log file: that will show the failing gcc > command line and contents of conftest.c that it used to test. > > -- > Thanks, > Nick From aph at redhat.com Wed Aug 5 09:15:08 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 5 Aug 2020 10:15:08 +0100 Subject: [aarch64-port-dev ] RFR(S) 8248660: AArch64: JDK-Windows: Make _clear_cache and _nop portable In-Reply-To: References: Message-ID: <107e0d1b-38cf-f70f-b69e-c50c21cbd340@redhat.com> On 8/3/20 11:29 PM, Monica Beckwith wrote: > Hi all, could I please get a review for the following webrev? I had previously sent this out for feedback and Kim had provided feedback on the usual way to handle such changes: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-July/009272.html > > I have made the needful changes and ran them through JTREG for linux-aarch64, windows-aarch64, windows-x86-64, and linux-x86-64. > > Webrev: http://cr.openjdk.java.net/~mbeckwit/8248660/webrev.01/ > JBS: https://bugs.openjdk.java.net/browse/JDK-8248660 > > I wanted to highlight a small change that I made: > > - For void __builtin___clear_cache (void *begin, void *end); the `begin` is inclusive, and `end` is exclusive [1]. > - Hence for icache_linux_aarch64.hpp?s invalidate_word(), I changed the end to `addr + 4` which previously was `addr + 3`. So it now reads: > __builtin___clear_cache((char *)addr, (char *)(addr + 4)); > > Although there is forced instruction alignment on Arm64, I still felt I should correct the "victimless crime" (as one of our kernel experts puts it. ??) This is shared code, and I don't know if it works on every target: --- a/src/hotspot/share/utilities/globalDefinitions_gcc.hpp +++ b/src/hotspot/share/utilities/globalDefinitions_gcc.hpp @@ -164,4 +164,7 @@ // #define ATTRIBUTE_ALIGNED(x) __attribute__((aligned(x))) +// __nop needs volatile so that compiler doesn't optimize it away +#define NOP() asm volatile ("nop"); + #endif // SHARE_UTILITIES_GLOBALDEFINITIONS_GCC_HPP I suggest you do this in one of the AArch64 headers instead: #ifdef GCC #define NOP() asm volatile ("nop"); #else MSVC etc. Otherwise OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Wed Aug 5 15:21:09 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 5 Aug 2020 15:21:09 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 4166 Failure Message-ID: <91064569.3242.1596640870007@localhost> OpenJDK AArch64 jdk/jdk build status is Failure Build details - https://ci.linaro.org/jenkins/job/jdkX-ci-build/4166/ Changes - sgehwolf: c075a286cc7df767cce28e8057d6ec5051786490 - make/autoconf/basic_tools.m4 - make/autoconf/configure - make/autoconf/util.m4 - make/autoconf/util_windows.m4 --"8248158: Configure fails with autoconf not found even though it's installed Reviewed-by: erikj, ihse, stooke Contributed-by: Galder Zamarreno " coleenp: 78e36b769c462b9b9eb9f84169be4ab4f248863c - src/hotspot/share/gc/shared/oopStorageSet.hpp - src/hotspot/share/gc/shared/weakProcessorPhases.cpp - src/hotspot/share/gc/shared/weakProcessorPhases.hpp - src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp - src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp - src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp - src/hotspot/share/gc/z/zRootsIterator.cpp - src/hotspot/share/gc/z/zRootsIterator.hpp - src/hotspot/share/jfr/jfr.cpp - src/hotspot/share/jfr/jfr.hpp - src/hotspot/share/jfr/leakprofiler/leakProfiler.cpp - src/hotspot/share/jfr/leakprofiler/leakProfiler.hpp - src/hotspot/share/jfr/leakprofiler/sampling/objectSample.cpp - src/hotspot/share/jfr/leakprofiler/sampling/objectSample.hpp - src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.cpp - src/hotspot/share/jfr/leakprofiler/sampling/objectSampler.hpp - src/hotspot/share/jfr/recorder/jfrRecorder.cpp - src/hotspot/share/jfr/recorder/jfrRecorder.hpp - src/hotspot/share/oops/weakHandle.hpp --"8235573: Move JFR ObjectSample oop into OopStorage Reviewed-by: mgronlun, dholmes, kbarrett " Build output - Compiling 16 files for java.management.rmi Compiling 219 files for java.security.jgss Compiling 2781 files for java.desktop Compiling 56 files for java.sql.rowset Compiling 83 files for jdk.jlink Compiling 31 files for jdk.management.agent Compiling 95 files for jdk.jshell Compiling 30 files for jdk.security.auth Compiling 16 files for jdk.security.jgss Compiling 1644 files for jdk.internal.vm.compiler Compiling 107 files for jdk.aot Compiling 69 files for COMPILE_CREATE_SYMBOLS Creating ct.sym classes Compiling 3 files for jdk.internal.vm.compiler.management Compiling 1 files for java.se Updating support/src.zip Compiling 18 files for jdk.accessibility Compiling 3 files for jdk.editpad Compiling 944 files for jdk.hotspot.agent Compiling 47 files for jdk.incubator.jpackage Compiling 64 files for jdk.jconsole Compiling 8 files for jdk.unsupported.desktop In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp:29:0, from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp:28, from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp:27: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp:236:3: error: 'EventGCPhaseParallel' does not name a type EventGCPhaseParallel _event; ^ In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp:29:0, from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp:28, from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp:27: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp:236:3: error: 'EventGCPhaseParallel' does not name a type EventGCPhaseParallel _event; ^ cc1plus: error: unrecognized command line option '-Wno-shift-negative-value' [-Werror] cc1plus: error: unrecognized command line option '-Wno-cast-function-type' [-Werror] cc1plus: error: unrecognized command line option '-Wno-misleading-indentation' [-Werror] cc1plus: error: unrecognized command line option '-Wno-implicit-fallthrough' [-Werror] cc1plus: error: unrecognized command line option '-Wno-int-in-bool-context' [-Werror] cc1plus: all warnings being treated as errors lib/CompileJvm.gmk:141: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahAdaptiveHeuristics.o' failed make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahAdaptiveHeuristics.o] Error 1 make[3]: *** Waiting for unfinished jobs.... cc1plus: error: unrecognized command line option '-Wno-shift-negative-value' [-Werror] cc1plus: error: unrecognized command line option '-Wno-cast-function-type' [-Werror] cc1plus: error: unrecognized command line option '-Wno-misleading-indentation' [-Werror] cc1plus: error: unrecognized command line option '-Wno-implicit-fallthrough' [-Werror] cc1plus: error: unrecognized command line option '-Wno-int-in-bool-context' [-Werror] cc1plus: all warnings being treated as errors lib/CompileJvm.gmk:141: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahAggressiveHeuristics.o' failed make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahAggressiveHeuristics.o] Error 1 make/Main.gmk:259: recipe for target 'hotspot-server-libs' failed make[2]: *** [hotspot-server-libs] Error 1 ERROR: Build failed for target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_objs_shenandoahAdaptiveHeuristics.o: In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp:29:0, from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp:28, from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp:27: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp:236:3: error: 'EventGCPhaseParallel' does not name a type EventGCPhaseParallel _event; ^ cc1plus: error: unrecognized command line option '-Wno-shift-negative-value' [-Werror] cc1plus: error: unrecognized command line option '-Wno-cast-function-type' [-Werror] cc1plus: error: unrecognized command line option '-Wno-misleading-indentation' [-Werror] cc1plus: error: unrecognized command line option '-Wno-implicit-fallthrough' [-Werror] cc1plus: error: unrecognized command line option '-Wno-int-in-bool-context' [-Werror] cc1plus: all warnings being treated as errors * For target hotspot_variant-server_libjvm_objs_shenandoahAggressiveHeuristics.o: In file included from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp:29:0, from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp:28, from /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp:27: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp:236:3: error: 'EventGCPhaseParallel' does not name a type EventGCPhaseParallel _event; ^ cc1plus: error: unrecognized command line option '-Wno-shift-negative-value' [-Werror] cc1plus: error: unrecognized command line option '-Wno-cast-function-type' [-Werror] cc1plus: error: unrecognized command line option '-Wno-misleading-indentation' [-Werror] cc1plus: error: unrecognized command line option '-Wno-implicit-fallthrough' [-Werror] cc1plus: error: unrecognized command line option '-Wno-int-in-bool-context' [-Werror] cc1plus: all warnings being treated as errors * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs. === End of repeated output === === Make failed targets repeated here === lib/CompileJvm.gmk:141: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahAdaptiveHeuristics.o' failed lib/CompileJvm.gmk:141: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahAggressiveHeuristics.o' failed make/Main.gmk:259: recipe for target 'hotspot-server-libs' failed === End of repeated output === Hint: Try searching the build log for the name of the first failed target. Hint: See doc/building.html#troubleshooting for assistance. /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:310: recipe for target 'main' failed make[1]: *** [main] Error 1 /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed make: *** [images] Error 2 From felix.yang at huawei.com Thu Aug 6 01:13:44 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 6 Aug 2020 01:13:44 +0000 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, August 4, 2020 6:27 PM > To: Yangfei (Felix) ; hotspot-runtime- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic > > On 8/3/20 2:18 AM, Yangfei (Felix) wrote: > > OK. I simply comment out the following code changes in > vm_version_aarch64.cpp: > > > > 393 if (UseSHA && (auxv & HWCAP_SHA512)) { > > 394 // Do not auto-enable UseSHA512Intrinsics until it has been fully > tested on hardware > > 395 // if (FLAG_IS_DEFAULT(UseSHA512Intrinsics)) { > > 396 // FLAG_SET_DEFAULT(UseSHA512Intrinsics, true); > > 397 // } > > 398 } else if (UseSHA512Intrinsics) { > > > > Once this has been fully tested on real hardware, it will be easy to auto- > enable. > > > > New webrev: http://cr.openjdk.java.net/~fyang/8165404/webrev.01/ > > Looks good, thanks. Thanks for reviewing this. > My apologies, there is another thing I should have mentioned: please add > test cases for the new instructions to aarch64-asmtest.py and regenerate the > code between > > // BEGIN Generated code -- do not edit > // Generated by aarch64-asmtest.py > > and > > // END Generated code -- do not edit > > I'm trying to be more strict about making sure all of the instructions get > tested. Sure. I have added tests for sha512 crypto instructions in this script and regenerated the code. Tier1-3 tested with an aarch64 fastdebug build on my aarch64 linux host to cover this part. Updated webrev: http://cr.openjdk.java.net/~fyang/8165404/webrev.02/ Is it OK? Felix From felix.yang at huawei.com Thu Aug 6 01:41:12 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Thu, 6 Aug 2020 01:41:12 +0000 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8221658: aarch64: add necessary predicate for ubfx patterns Message-ID: Hi, Original Bug: https://bugs.openjdk.java.net/browse/JDK-8221658 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/0fa2903fb272 This bug can still be reproduced with 8u aarch64 release build with test: https://bugs.openjdk.java.net/secure/attachment/81950/fuzz-test.tar.bz2 Webrev for 8u-aarch64: http://cr.openjdk.java.net/~fyang/8221658-8u/webrev.00/ Code changes to pattern ubfizL in the original patch is not necessary as it is not there in 8u aarch64. Performed full jtreg test with 8u aarch64 release build. OK to backport? Thanks, Felix From gnu.andrew at redhat.com Thu Aug 6 05:49:53 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 6 Aug 2020 06:49:53 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b01 Upstream Sync In-Reply-To: <05f4fb9e-b06c-1a7b-551d-3e0d57565b29@redhat.com> References: <20200803171250.GA263856@stopbrexit> <05f4fb9e-b06c-1a7b-551d-3e0d57565b29@redhat.com> Message-ID: <20200806054953.GC472692@stopbrexit> On 10:13 Tue 04 Aug , Aleksey Shipilev wrote: > On 8/3/20 7:12 PM, Andrew Hughes wrote: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/corba/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/jaxp/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/jaxws/merge.changeset > > Looks trivially good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b01/jdk/merge.changeset > > Ooof. Lots of new tests. Looks good. Yes... I guess it's good for a stable release that most of the backports are test backports, but I can't help wondering if this low hanging fruit is being done in preference to higher priority, but more complicated bug fixes. snip... > > Ok to push? > Yes. -- Thanks, -Aleksey Thanks. Pushed -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Aug 6 05:47:58 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 06 Aug 2020 05:47:58 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 9 new changesets Message-ID: <202008060547.0765lwK4028808@aojmv0008.oracle.com> Changeset: f21321e94793 Author: andrew Date: 2020-07-27 17:00 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/f21321e94793 Added tag jdk8u265-ga for changeset 6cc620acc684 ! .hgtags Changeset: 7dea4754bd99 Author: andrew Date: 2020-06-03 01:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/7dea4754bd99 8246384: Enable JFR by default on supported architectures for October 2020 release Reviewed-by: aph, neugens ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 8054f6ed5d43 Author: andrew Date: 2020-06-03 01:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/8054f6ed5d43 Added tag jdk8u272-b00 for changeset ecb485e1572c ! .hgtags Changeset: ba2f9cd8b063 Author: andrew Date: 2020-06-09 06:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/ba2f9cd8b063 Merge ! .hgtags Changeset: a8da94d779b3 Author: andrew Date: 2020-06-29 21:30 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/a8da94d779b3 Merge ! .hgtags Changeset: c75ad083817f Author: andrew Date: 2020-07-24 13:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/c75ad083817f Merge ! .hgtags Changeset: 1bda51d3d528 Author: andrew Date: 2020-07-29 05:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/1bda51d3d528 Merge ! .hgtags Changeset: 4f46636c0c80 Author: andrew Date: 2020-08-01 03:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/4f46636c0c80 Merge jdk8u272-b01 ! .hgtags ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 3965f77fe2d4 Author: andrew Date: 2020-08-01 03:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/3965f77fe2d4 Added tag aarch64-shenandoah-jdk8u272-b01 for changeset 4f46636c0c80 ! .hgtags From gnu.andrew at redhat.com Thu Aug 6 05:48:17 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 06 Aug 2020 05:48:17 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 8 new changesets Message-ID: <202008060548.0765mHLP029140@aojmv0008.oracle.com> Changeset: 71c82e3d14cf Author: andrew Date: 2020-07-27 17:00 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/71c82e3d14cf Added tag jdk8u265-ga for changeset 3147b24fc8b0 ! .hgtags Changeset: 4734f141ae0d Author: andrew Date: 2020-06-03 01:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/4734f141ae0d Added tag jdk8u272-b00 for changeset 976e73cfac41 ! .hgtags Changeset: 34a9be453c73 Author: andrew Date: 2020-06-09 06:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/34a9be453c73 Merge ! .hgtags Changeset: 80af267d6aa9 Author: andrew Date: 2020-06-29 21:30 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/80af267d6aa9 Merge ! .hgtags Changeset: bf1b7696bc62 Author: andrew Date: 2020-07-24 13:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/bf1b7696bc62 Merge ! .hgtags Changeset: 1bc3598fbad0 Author: andrew Date: 2020-07-29 05:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/1bc3598fbad0 Merge ! .hgtags Changeset: 2208000d3d2e Author: andrew Date: 2020-08-01 03:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/2208000d3d2e Merge jdk8u272-b01 ! .hgtags Changeset: cb243a0d0f19 Author: andrew Date: 2020-08-01 03:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/cb243a0d0f19 Added tag aarch64-shenandoah-jdk8u272-b01 for changeset 2208000d3d2e ! .hgtags From gnu.andrew at redhat.com Thu Aug 6 05:48:57 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 06 Aug 2020 05:48:57 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 46 new changesets Message-ID: <202008060548.0765mwwf029634@aojmv0008.oracle.com> Changeset: c60436725ce4 Author: andrew Date: 2020-07-27 17:00 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c60436725ce4 Added tag jdk8u265-ga for changeset 9204e03217f7 ! .hgtags Changeset: d5b5e17d92c1 Author: andrew Date: 2020-06-03 01:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d5b5e17d92c1 Added tag jdk8u272-b00 for changeset 4789a6a01301 ! .hgtags Changeset: d6d7043c8396 Author: andrew Date: 2020-06-09 06:24 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d6d7043c8396 Merge ! .hgtags Changeset: ca808481f63e Author: smarks Date: 2015-07-29 15:21 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ca808481f63e 8132206: move ScanTest.java into OpenJDK Reviewed-by: psandoz, sherman + test/java/util/Scanner/ScanTest.java + test/java/util/Scanner/input.txt Changeset: c8987a0ad95d Author: smarks Date: 2015-07-30 22:21 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c8987a0ad95d 8132745: minor cleanup of java/util/Scanner/ScanTest.java Reviewed-by: darcy, sherman ! test/java/util/Scanner/ScanTest.java Changeset: a20d3b459721 Author: igerasim Date: 2014-03-13 07:24 +0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/a20d3b459721 8036088: Replace strtok() with its safe equivalent strtok_s() in DefaultProxySelector.c Reviewed-by: chegar ! src/windows/native/sun/net/spi/DefaultProxySelector.c Changeset: 308435351e73 Author: serb Date: 2020-04-08 02:53 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/308435351e73 8239819: XToolkit: Misread of screen information memory Reviewed-by: prr ! src/solaris/classes/sun/awt/X11/XIconWindow.java ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/solaris/native/sun/xawt/XToolkit.c Changeset: 0a6aba57af9a Author: vtewari Date: 2016-07-15 14:06 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/0a6aba57af9a 8151788: NullPointerException from ntlm.Client.type3 Reviewed-by: chegar, prappo, weijun ! src/share/classes/com/sun/security/ntlm/NTLM.java + test/sun/net/www/protocol/http/NULLTargetInfoTest.java Changeset: 858321c03257 Author: martin Date: 2015-03-10 14:23 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/858321c03257 8075774: Small readability and performance improvements for zipfs Reviewed-by: sherman, alanb ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipConstants.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java Changeset: 9ba0e6797d21 Author: andrew Date: 2020-06-17 15:59 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/9ba0e6797d21 Merge Changeset: a485b9589708 Author: afarley Date: 2020-06-17 19:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/a485b9589708 8229378: jdwp library loader in linker_md.c quietly truncates on buffer overflow Summary: Check buffer overflow when the jdwp agent full dll name is built Reviewed-by: cjplummer, sspitsyn, andrew ! src/solaris/back/linker_md.c ! src/windows/back/linker_md.c Changeset: 6e0c3bc4b1cc Author: akasko Date: 2015-09-01 11:03 +0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/6e0c3bc4b1cc 8132376: Add @requires os.family to the client tests with access to internal OS-specific API Reviewed-by: yan, alexsch, andrew, zgu Contributed-by: Renjith Alexander ! test/com/apple/eawt/DefaultMenuBar/DefaultMenuBarTest.java + test/java/awt/EmbeddedFrame/DisplayChangedTest/DisplayChangedTest.java + test/java/awt/EmbeddedFrame/EmbeddedFrameGrabTest/EmbeddedFrameGrabTest.java ! test/java/awt/Mouse/EnterExitEvents/FullscreenEnterEventTest.java ! test/java/awt/SplashScreen/FullscreenAfterSplash/FullScreenAfterSplash.java Changeset: f24756eda3d6 Author: serb Date: 2020-06-16 09:46 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f24756eda3d6 8167615: Opensource unit/regression tests for JavaSound Reviewed-by: amenkov ! test/ProblemList.txt + test/javax/sound/midi/Devices/ClosedReceiver.java + test/javax/sound/midi/Devices/IOLoop.java + test/javax/sound/midi/Devices/MidiDeviceGetReceivers.java + test/javax/sound/midi/Devices/MidiIO.java + test/javax/sound/midi/Devices/MidiOutGetMicrosecondPositionBug.java + test/javax/sound/midi/Devices/OpenClose.java + test/javax/sound/midi/Devices/ReceiverTransmitterAvailable.java + test/javax/sound/midi/Devices/Reopen.java + test/javax/sound/midi/File/SMFCp037.java + test/javax/sound/midi/File/SMFParserBreak.java + test/javax/sound/midi/File/WriteRealTimeMessageNPE.java + test/javax/sound/midi/MetaMessage/MetaMessageClone.java + test/javax/sound/midi/MidiSystem/6411624/Test6411624.java + test/javax/sound/midi/MidiSystem/6411624/bug6411624.java + test/javax/sound/midi/MidiSystem/DefaultDevices.java + test/javax/sound/midi/MidiSystem/DefaultProperties.java + test/javax/sound/midi/MidiSystem/GetSequencer.java + test/javax/sound/midi/MidiSystem/MidiFileTypeUniqueness.java + test/javax/sound/midi/MidiSystem/ProviderCacheing.java + test/javax/sound/midi/MidiSystem/testdata/lib/conf/sound.properties + test/javax/sound/midi/Sequence/GetMicrosecondLength.java + test/javax/sound/midi/Sequence/MidiSMPTE.java + test/javax/sound/midi/Sequence/SMPTEDuration.java + test/javax/sound/midi/Sequencer/LoopIAE.java + test/javax/sound/midi/Sequencer/Looping.java + test/javax/sound/midi/Sequencer/MetaCallback.java + test/javax/sound/midi/Sequencer/Recording.java + test/javax/sound/midi/Sequencer/SeqRecordDoesNotCopy.java + test/javax/sound/midi/Sequencer/SeqRecordsRealTimeEvents.java + test/javax/sound/midi/Sequencer/SeqStartRecording.java + test/javax/sound/midi/Sequencer/SequencerCacheValues.java + test/javax/sound/midi/Sequencer/SequencerSetMuteSolo.java + test/javax/sound/midi/Sequencer/SequencerState.java + test/javax/sound/midi/Sequencer/SetTickPosition.java + test/javax/sound/midi/Sequencer/TickLength.java + test/javax/sound/midi/ShortMessage/FastShortMessage.java + test/javax/sound/midi/ShortMessage/FastShortMessage2.java + test/javax/sound/midi/Soundbanks/ExtraCharInSoundbank.java + test/javax/sound/midi/Soundbanks/GetSoundBankIOException.java + test/javax/sound/midi/Synthesizer/AsynchronousMidiChannel.java + test/javax/sound/midi/Synthesizer/Receiver/bug6186488.java + test/javax/sound/midi/Synthesizer/SynthesizerGetLatency.java + test/javax/sound/midi/Synthesizer/bug4685396.java + test/javax/sound/midi/Track/TrackAddSameTick.java + test/javax/sound/midi/Track/bug6416024.java + test/javax/sound/midi/Transmitter/bug6415669.java + test/javax/sound/sampled/AudioFileFormat/AudioFileFormatToString.java + test/javax/sound/sampled/AudioFileFormat/Properties.java + test/javax/sound/sampled/AudioFileFormat/TypeEquals.java + test/javax/sound/sampled/AudioFormat/AudioFormatBitSize.java + test/javax/sound/sampled/AudioFormat/EncodingEquals.java + test/javax/sound/sampled/AudioFormat/Properties.java + test/javax/sound/sampled/AudioInputStream/AISReadFraction.java + test/javax/sound/sampled/AudioInputStream/bug6188860.java + test/javax/sound/sampled/AudioSystem/AudioFileTypes/AudioFileTypeUniqueness.java + test/javax/sound/sampled/AudioSystem/AudioFileTypes/ShowAudioFileTypes.java + test/javax/sound/sampled/AudioSystem/DefaultMixers.java + test/javax/sound/sampled/AudioSystem/DefaultProperties.java + test/javax/sound/sampled/AudioSystem/ProviderCacheing.java + test/javax/sound/sampled/AudioSystem/testdata/lib/conf/sound.properties + test/javax/sound/sampled/Clip/ClipCloseLoss.java + test/javax/sound/sampled/Clip/ClipFlushCrash.java + test/javax/sound/sampled/Clip/Drain/ClipDrain.java + test/javax/sound/sampled/Clip/Duration/ClipDuration.java + test/javax/sound/sampled/Clip/Endpoint/ClipSetEndPoint.java + test/javax/sound/sampled/Clip/Open/ClipOpenBug.java + test/javax/sound/sampled/Clip/bug5070081.java + test/javax/sound/sampled/Clip/bug6251460.java + test/javax/sound/sampled/Controls/CompoundControl/ToString.java + test/javax/sound/sampled/Controls/FloatControl/FloatControlBug.java + test/javax/sound/sampled/DataLine/DataLineInfoNegBufferSize.java + test/javax/sound/sampled/DataLine/LineDefFormat.java + test/javax/sound/sampled/DataLine/LongFramePosition.java + test/javax/sound/sampled/DirectAudio/TickAtEndOfPlay.java + test/javax/sound/sampled/DirectAudio/bug6372428.java + test/javax/sound/sampled/FileTypeExtension/FileTypeExtensionTest.java + test/javax/sound/sampled/LineEvent/LineInfoNPE.java + test/javax/sound/sampled/Lines/16and32KHz/Has16and32KHz.java + test/javax/sound/sampled/Lines/BufferSizeCheck.java + test/javax/sound/sampled/Lines/ChangingBuffer.java + test/javax/sound/sampled/Lines/ClickInPlay/ClickInPlay.java + test/javax/sound/sampled/Lines/ClickInPlay/Test4218609.java + test/javax/sound/sampled/Lines/ClipOpenException.java + test/javax/sound/sampled/Lines/FrameSize/FrameSizeTest.java + test/javax/sound/sampled/Lines/GetLine.java + test/javax/sound/sampled/Lines/SDLwrite.java + test/javax/sound/sampled/Lines/SourceDataLineDefaultBufferSizeCrash.java + test/javax/sound/sampled/Lines/StopStart.java + test/javax/sound/sampled/LinuxBlock/PlaySine.java + test/javax/sound/sampled/LinuxCrash/ClipLinuxCrash.java + test/javax/sound/sampled/LinuxCrash/ClipLinuxCrash2.java + test/javax/sound/sampled/LinuxCrash/SDLLinuxCrash.java + test/javax/sound/sampled/Mixers/BogusMixers.java + test/javax/sound/sampled/Mixers/BothEndiansAndSigns.java + test/javax/sound/sampled/Mixers/DirectSoundRepeatingBuffer/DirectSoundRepeatingBuffer.java + test/javax/sound/sampled/Mixers/DirectSoundRepeatingBuffer/Test4997635.java + test/javax/sound/sampled/Mixers/DirectSoundUnderrunSilence/DirectSoundUnderrunSilence.java + test/javax/sound/sampled/Mixers/DirectSoundUnderrunSilence/Test5032020.java + test/javax/sound/sampled/Mixers/DisabledAssertionCrash.java + test/javax/sound/sampled/Mixers/NoSimpleInputDevice.java + test/javax/sound/sampled/Mixers/PhantomMixers.java + test/javax/sound/sampled/Mixers/PlugHwMonoAnd8bitAvailable.java + test/javax/sound/sampled/Mixers/UnexpectedIAE.java + test/javax/sound/sampled/Recording/TargetDataLineFlush.java + test/javax/sound/sampled/spi/AudioFileReader/AIFFCp037.java + test/javax/sound/sampled/spi/AudioFileReader/AIFFLargeHeader.java + test/javax/sound/sampled/spi/AudioFileReader/Aiff12bit.java + test/javax/sound/sampled/spi/AudioFileReader/AuNotSpecified.java + test/javax/sound/sampled/spi/AudioFileReader/AuZeroLength.java + test/javax/sound/sampled/spi/AudioFileReader/OpenWaveFile.java + test/javax/sound/sampled/spi/AudioFileWriter/AUwithULAW.java + test/javax/sound/sampled/spi/AudioFileWriter/AiffSampleRate.java + test/javax/sound/sampled/spi/AudioFileWriter/RIFFHeader.java + test/javax/sound/sampled/spi/AudioFileWriter/WaveBigEndian.java + test/javax/sound/sampled/spi/AudioFileWriter/WriteAuUnspecifiedLength.java + test/javax/sound/sampled/spi/FormatConversionProvider/AlawUlaw.java Changeset: f1e3ae7aa829 Author: mbaesken Date: 2020-06-22 13:36 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f1e3ae7aa829 8210147: adjust some WSAGetLastError usages in windows network coding Reviewed-by: clanger, stuefe ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/java/net/SocketInputStream.c Changeset: 4371aa83bd74 Author: aghaisas Date: 2020-06-22 17:34 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/4371aa83bd74 8137087: [TEST_BUG] Cygwin failure of java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh Reviewed-by: yan, arapte Contributed-by: rahul.d.singh at oracle.com ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh Changeset: 4d0e0d140969 Author: alitvinov Date: 2020-04-20 19:25 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/4d0e0d140969 8242498: Invalid "sun.awt.TimedWindowEvent" object leads to JVM crash Reviewed-by: prr, serb ! src/windows/native/sun/windows/awt_Window.cpp Changeset: c6dec7c38c41 Author: serb Date: 2017-05-22 19:54 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c6dec7c38c41 8177628: Opensource unit/regression tests for ImageIO Reviewed-by: prr, pnarayanan + test/javax/imageio/AllowSearch.java + test/javax/imageio/AppContextTest.java + test/javax/imageio/AppletResourceTest.html + test/javax/imageio/AppletResourceTest.java + test/javax/imageio/GetNumImages.java + test/javax/imageio/GetReaderWriterInfo.java + test/javax/imageio/IIOImageConstructor.java + test/javax/imageio/ITSDataType.java + test/javax/imageio/ImageIOGetImageReaders.java + test/javax/imageio/ImageIOWriteFile.java + test/javax/imageio/ImageIOWriteNull.java + test/javax/imageio/ImageReadParamPasses.java + test/javax/imageio/ImageReaderGetDestination.java + test/javax/imageio/ImageReaderReadAll.java + test/javax/imageio/ImageStreamFromRAF.java + test/javax/imageio/ImageTypeSpecifierBitsPerBand.java + test/javax/imageio/ImageTypeSpecifierTest.java + test/javax/imageio/ImageWriteParamMisc.java + test/javax/imageio/NullInputOutput.java + test/javax/imageio/PNGSpiStreamMetadata.java + test/javax/imageio/PNGSuffixes.java + test/javax/imageio/ReadBitsTest.java + test/javax/imageio/SetOutput.java + test/javax/imageio/WriteNullImageTest.java + test/javax/imageio/event/WriteProgressListenerTest.java + test/javax/imageio/plugins/bmp/BMPCompressionTest.java + test/javax/imageio/plugins/bmp/BMPPluginTest.java + test/javax/imageio/plugins/bmp/BMPWriteParamTest.java + test/javax/imageio/plugins/bmp/BmpBigDestinationTest.java + test/javax/imageio/plugins/bmp/BmpDefaultImageMetadataTest.java + test/javax/imageio/plugins/bmp/CompressionModeTest.java + test/javax/imageio/plugins/bmp/EmbeddedFormatTest.java + test/javax/imageio/plugins/bmp/EmptyInputBmpMetadataTest.java + test/javax/imageio/plugins/bmp/NoExtraBytesTest.java + test/javax/imageio/plugins/bmp/RLECompressionTest.java + test/javax/imageio/plugins/bmp/ReaderListenersTest.java + test/javax/imageio/plugins/bmp/RleEncodingTest.java + test/javax/imageio/plugins/bmp/TestCompressionBI_BITFIELDS.java + test/javax/imageio/plugins/bmp/Write3ByteBgrTest.java + test/javax/imageio/plugins/bmp/WriteProgressListenerTest.java + test/javax/imageio/plugins/bmp/WritingColorChangeTest.java + test/javax/imageio/plugins/gif/AnimationTest.java + test/javax/imageio/plugins/gif/DisableCompressionTest.java + test/javax/imageio/plugins/gif/EndWriteSequenceTest.java + test/javax/imageio/plugins/gif/IndexingTest.java + test/javax/imageio/plugins/gif/LogicalScreenDimensionTest.java + test/javax/imageio/plugins/gif/OddPaletteTest.java + test/javax/imageio/plugins/gif/PrepareWriteSequenceTest.java + test/javax/imageio/plugins/gif/RGBAnimationTest.java + test/javax/imageio/plugins/gif/RGBImageTest.java + test/javax/imageio/plugins/gif/StreamMetadataTest.java + test/javax/imageio/plugins/gif/TransparencyTest.java + test/javax/imageio/plugins/gif/UshortOutOfMemoryTest.java + test/javax/imageio/plugins/gif/WriteMetadataTest.java + test/javax/imageio/plugins/gif/WriterResetTest.java + test/javax/imageio/plugins/gif/WriterReuseTest.java + test/javax/imageio/plugins/jpeg/ByteBinaryTest.java + test/javax/imageio/plugins/jpeg/CanEncodeIndexed.java + test/javax/imageio/plugins/jpeg/CompressionBug.java + test/javax/imageio/plugins/jpeg/CompressionVals.java + test/javax/imageio/plugins/jpeg/CrashAfterDispose.java + test/javax/imageio/plugins/jpeg/DestTypeTest.java + test/javax/imageio/plugins/jpeg/JPEGsNotAcceleratedTest.java + test/javax/imageio/plugins/jpeg/MergeTreeTest.java + test/javax/imageio/plugins/jpeg/RasterWithMinXTest.java + test/javax/imageio/plugins/jpeg/ResetOutOfMemory.java + test/javax/imageio/plugins/jpeg/UshortGrayTest.java + test/javax/imageio/plugins/png/CanEncodeShort.java + test/javax/imageio/plugins/png/ImageCompare.java + test/javax/imageio/plugins/png/PngPremultAlphaTest.java + test/javax/imageio/plugins/png/ShortPaletteTest.java + test/javax/imageio/plugins/png/WriteProgressive.java + test/javax/imageio/plugins/wbmp/EmptyInputWbmpMetadataTest.java + test/javax/imageio/plugins/wbmp/GetImageTypesTest.java + test/javax/imageio/plugins/wbmp/ValidWbmpTest.java + test/javax/imageio/plugins/wbmp/WBMPPluginTest.java + test/javax/imageio/plugins/wbmp/WbmpBigDestinationTest.java + test/javax/imageio/plugins/wbmp/WbmpDefaultImageMetadataTest.java + test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh + test/javax/imageio/spi/AppletContextTest/DummyReaderPluginSpi.java + test/javax/imageio/spi/AppletContextTest/IIOPluginTest.java + test/javax/imageio/spi/CreateMemoryCacheOutputStream.java + test/javax/imageio/spi/DeregisterAllSpiTest.java + test/javax/imageio/spi/DeregisterOrderedSpiTest.java + test/javax/imageio/spi/OrderingTest.java + test/javax/imageio/spi/PluginSpiTest.java + test/javax/imageio/spi/RegisterPluginTwiceTest.java + test/javax/imageio/spi/SpiTest.java + test/javax/imageio/spi/SpiVersionNumbers.java + test/javax/imageio/stream/BitPadding.java + test/javax/imageio/stream/DeleteOnExitTest.java + test/javax/imageio/stream/DeleteOnExitTest.sh + test/javax/imageio/stream/FileCacheImageInputStreamNullTest.java + test/javax/imageio/stream/FlushBefore.java + test/javax/imageio/stream/MemoryCacheImageOutputStreamTest.java + test/javax/imageio/stream/ReadBytesIIOByteBuffer.java + test/javax/imageio/stream/ReadFullyTest.java + test/javax/imageio/stream/ReadUnsignedIntTest.java + test/javax/imageio/stream/StreamFlush.java + test/javax/imageio/stream/WriteBitsTest.java Changeset: ab10d0c37c35 Author: aghaisas Date: 2017-07-24 11:54 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ab10d0c37c35 8183341: Better cleanup for javax/imageio/AllowSearch.java Reviewed-by: prr, jdv, pnarayanan Contributed-by: shashidhara.veerabhadraiah at oracle.com ! test/javax/imageio/AllowSearch.java Changeset: 7ad3f115fb0c Author: serb Date: 2016-05-18 20:40 +0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/7ad3f115fb0c 8156169: Some sound tests rarely hangs because of incorrect synchronization Reviewed-by: prr, amenkov ! src/share/classes/com/sun/media/sound/AbstractDataLine.java ! src/share/classes/com/sun/media/sound/AbstractLine.java ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/share/classes/com/sun/media/sound/MidiInDevice.java ! src/share/classes/com/sun/media/sound/RealTimeSequencer.java ! src/share/classes/javax/sound/midi/Sequence.java + test/javax/sound/sampled/Clip/IsRunningHang.java Changeset: 8227975a4b16 Author: andrew Date: 2020-06-29 21:30 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/8227975a4b16 Merge ! .hgtags - make/data/cacerts/addtrustclass1ca - make/data/cacerts/keynectisrootca Changeset: 89a822057fe5 Author: prr Date: 2015-12-24 09:07 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/89a822057fe5 8145808: java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java hangs on Win. 8 Reviewed-by: serb, flar ! test/java/awt/Graphics2D/MTGraphicsAccessTest/MTGraphicsAccessTest.java Changeset: 678016ab3219 Author: psadhukhan Date: 2017-01-18 11:35 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/678016ab3219 8172012: [TEST_BUG] delays needed in javax/swing/JTree/4633594/bug4633594.java Reviewed-by: yan, serb + test/javax/swing/JTree/4633594/JTreeFocusTest.java Changeset: 2666d08d66ee Author: prr Date: 2017-08-31 13:09 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2666d08d66ee 8183351: Better cleanup for jdk/test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh Reviewed-by: serb ! test/javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh Changeset: 5649e19e552e Author: jdv Date: 2018-02-23 12:30 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/5649e19e552e 8198004: javax/swing/JFileChooser/6868611/bug6868611.java throws error Reviewed-by: serb, ssadetsky, kaddepalli ! test/javax/swing/JFileChooser/6868611/bug6868611.java Changeset: f14054bf7742 Author: prr Date: 2018-04-20 09:44 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f14054bf7742 8200313: java/awt/Gtk/GtkVersionTest/GtkVersionTest.java fails Reviewed-by: serb, kaddepalli ! test/java/awt/Gtk/GtkVersionTest/GtkVersionTest.java Changeset: f15b3ddc5024 Author: erikj Date: 2019-12-12 19:35 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/f15b3ddc5024 8235687: Contents/MacOS/libjli.dylib cannot be a symlink Reviewed-by: tbell ! make/Bundles.gmk Changeset: db9fc4b93cfe Author: erikj Date: 2019-12-12 19:35 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/db9fc4b93cfe 8238225: Issues reported after replacing symlink at Contents/MacOS/libjli.dylib with binary Reviewed-by: clanger, alanb, ihse ! src/macosx/bin/java_md_macosx.c + test/jdk/tools/launcher/JliLaunchTest.java + test/jdk/tools/launcher/JliLaunchTest.sh + test/jdk/tools/launcher/exeJliLaunchTest.c ! test/lib/jdk/test/lib/Platform.java Changeset: fc6f591fbd8a Author: prr Date: 2019-06-24 17:31 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/fc6f591fbd8a 8226697: Several tests which need the @key headful keyword are missing it. Reviewed-by: serb, sgehwolf, andrew ! test/com/sun/java/swing/plaf/gtk/4928019/bug4928019.java ! test/com/sun/java/swing/plaf/gtk/Test6635110.java ! test/com/sun/java/swing/plaf/gtk/Test6963870.java Changeset: 4a34bd2f8057 Author: zgu Date: 2020-07-16 15:21 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/4a34bd2f8057 8249610: Make sun.security.krb5.Config.getBooleanObject(String... keys) method public Reviewed-by: andrew ! src/share/classes/sun/security/krb5/Config.java Changeset: 0955cfdaee9e Author: rsunderbabu Date: 2020-03-06 10:27 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/0955cfdaee9e 8153430: jdk regression test MletParserLocaleTest, ParserInfiniteLoopTest reduce default timeout Summary: Removed timeout=5 from the tests so that default timeout is used Reviewed-by: cjplummer Contributed-by: ramkumar.sunderbabu at oracle.com ! test/javax/management/loading/ParserInfiniteLoopTest.java Changeset: df1a10f8e36a Author: prappo Date: 2019-08-14 11:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/df1a10f8e36a 8217606: LdapContext#reconnect always opens a new connection Reviewed-by: lancea, vtewari, rriggs Contributed-by: Chris Yin ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java + test/com/sun/jndi/ldap/LdapCtx/Reconnect.java + test/com/sun/jndi/ldap/lib/BaseLdapServer.java + test/com/sun/jndi/ldap/lib/LdapMessage.java Changeset: 90d5e3b5b19b Author: serb Date: 2018-08-24 16:29 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/90d5e3b5b19b 8039082: [TEST_BUG] Test java/awt/dnd/BadSerializationTest/BadSerializationTest.java fails Reviewed-by: prr - test/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/java/awt/dnd/BadSerializaionTest/badAction - test/java/awt/dnd/BadSerializaionTest/good - test/java/awt/dnd/BadSerializaionTest/noEvents - test/java/awt/dnd/BadSerializaionTest/nullComponent - test/java/awt/dnd/BadSerializaionTest/nullDragSource - test/java/awt/dnd/BadSerializaionTest/nullOrigin + test/java/awt/dnd/BadSerializationTest/BadSerializationTest.java + test/java/awt/dnd/BadSerializationTest/badAction + test/java/awt/dnd/BadSerializationTest/good + test/java/awt/dnd/BadSerializationTest/noEvents + test/java/awt/dnd/BadSerializationTest/nullComponent + test/java/awt/dnd/BadSerializationTest/nullDragSource + test/java/awt/dnd/BadSerializationTest/nullOrigin Changeset: 52e77a298786 Author: rhalade Date: 2016-04-14 14:42 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/52e77a298786 8151834: Test SmallPrimeExponentP.java times out intermittently Reviewed-by: weijun, andrew ! test/sun/security/mscapi/SmallPrimeExponentP.java Changeset: 6913155d9281 Author: andrew Date: 2020-07-24 13:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/6913155d9281 Merge ! .hgtags Changeset: 5414b80b28cb Author: prr Date: 2020-06-22 13:37 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/5414b80b28cb 8244818: Java2D Queue Flusher crash while moving application window to external monitor Reviewed-by: serb, jdv, kcr ! src/macosx/native/sun/java2d/opengl/CGLSurfaceData.m Changeset: 971263b8cd56 Author: mbalao Date: 2020-03-28 19:41 -0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/971263b8cd56 8239385: KerberosTicket client name refers wrongly to sAMAccountName in AD Reviewed-by: weijun ! src/share/classes/sun/security/krb5/Config.java ! src/share/classes/sun/security/krb5/KrbAsReqBuilder.java ! src/share/classes/sun/security/krb5/KrbKdcRep.java ! test/sun/security/krb5/auto/ReferralsTest.java Changeset: d1cbe37a41a6 Author: stuefe Date: 2016-09-13 11:38 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d1cbe37a41a6 8165936: Potential Heap buffer overflow when seaching timezone info files Summary: readdir_r called with too small buffer Reviewed-by: clanger, rriggs, okutsu, naoto ! src/solaris/native/java/util/TimeZone_md.c Changeset: 12c817241a11 Author: rriggs Date: 2016-09-15 16:05 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/12c817241a11 8166148: Fix for JDK-8165936 broke solaris builds Reviewed-by: naoto ! src/solaris/native/java/util/TimeZone_md.c Changeset: 7b148fbba788 Author: andrew Date: 2020-07-24 13:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/7b148fbba788 Merge Changeset: 4eca7c32a9c8 Author: andrew Date: 2020-07-24 16:59 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/4eca7c32a9c8 8249677: Regression in 8u after JDK-8237117: Better ForkJoinPool behavior Summary: Avoid altering the behaviour of the protected ForkJoinWorkerThread(ForkJoinPool) constructor Reviewed-by: andrew, mbalao Contributed-by: Anton Kozlov ! src/share/classes/java/util/concurrent/ForkJoinPool.java ! src/share/classes/java/util/concurrent/ForkJoinWorkerThread.java + test/java/util/concurrent/forkjoin/AccessControlContext.java + test/java/util/concurrent/forkjoin/AccessControlContext.policy Changeset: 3c1716a44d94 Author: sgehwolf Date: 2020-06-24 11:22 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3c1716a44d94 8194298: Add support for per Socket configuration of TCP keepalive Reviewed-by: vtewari, aph ! make/mapfiles/libnet/mapfile-vers ! src/share/classes/jdk/net/ExtendedSocketOptions.java ! src/share/classes/jdk/net/Sockets.java + src/share/classes/sun/net/ExtendedOptionsHelper.java ! src/share/classes/sun/net/ExtendedOptionsImpl.java ! src/share/classes/sun/nio/ch/AsynchronousServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/AsynchronousSocketChannelImpl.java ! src/share/classes/sun/nio/ch/Net.java ! src/share/classes/sun/nio/ch/ServerSocketChannelImpl.java ! src/share/classes/sun/nio/ch/SocketChannelImpl.java ! src/solaris/classes/java/net/PlainSocketImpl.java ! src/solaris/native/java/net/ExtendedOptionsImpl.c ! src/windows/native/java/net/ExtendedOptionsImpl.c + test/java/net/SocketOption/TcpKeepAliveTest.java ! test/java/nio/channels/AsynchronousServerSocketChannel/Basic.java ! test/java/nio/channels/AsynchronousSocketChannel/Basic.java ! test/java/nio/channels/ServerSocketChannel/SocketOptionTests.java ! test/java/nio/channels/SocketChannel/SocketOptionTests.java Changeset: 160797b3c05b Author: andrew Date: 2020-07-29 05:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/160797b3c05b Merge ! .hgtags Changeset: 1affb3bb2b3c Author: mbalao Date: 2020-04-02 18:18 -0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1affb3bb2b3c 8241888: Mirror jdk.security.allowNonCaAnchor system property with a security one Reviewed-by: mullan, andrew ! src/share/classes/sun/security/validator/PKIXValidator.java ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows Changeset: 2f117c583973 Author: igerasim Date: 2019-09-10 09:08 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2f117c583973 8230303: JDB hangs when running monitor command Reviewed-by: sspitsyn ! src/share/classes/com/sun/tools/example/debug/tty/TTY.java Changeset: 039b7fa799bb Author: andrew Date: 2020-08-01 03:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/039b7fa799bb Merge jdk8u272-b01 ! .hgtags ! make/Bundles.gmk ! src/share/classes/com/sun/jndi/ldap/LdapCtx.java ! src/share/classes/com/sun/media/sound/AbstractMidiDevice.java ! src/share/classes/sun/security/krb5/Config.java ! src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java ! src/share/lib/security/java.security-aix ! src/share/lib/security/java.security-linux ! src/share/lib/security/java.security-macosx ! src/share/lib/security/java.security-solaris ! src/share/lib/security/java.security-windows ! src/solaris/classes/sun/awt/X11/XToolkit.java ! src/windows/native/java/net/Inet4AddressImpl.c ! src/windows/native/java/net/Inet6AddressImpl.c ! src/windows/native/sun/windows/awt_Window.cpp ! test/ProblemList.txt ! test/java/awt/appletviewer/IOExceptionIfEncodedURLTest/IOExceptionIfEncodedURLTest.sh - test/java/awt/dnd/BadSerializaionTest/BadSerializationTest.java - test/java/awt/dnd/BadSerializaionTest/badAction - test/java/awt/dnd/BadSerializaionTest/good - test/java/awt/dnd/BadSerializaionTest/noEvents - test/java/awt/dnd/BadSerializaionTest/nullComponent - test/java/awt/dnd/BadSerializaionTest/nullDragSource - test/java/awt/dnd/BadSerializaionTest/nullOrigin Changeset: 6079bfd60d84 Author: andrew Date: 2020-08-01 03:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/6079bfd60d84 Added tag aarch64-shenandoah-jdk8u272-b01 for changeset 039b7fa799bb ! .hgtags From gnu.andrew at redhat.com Thu Aug 6 05:51:03 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 06 Aug 2020 05:51:03 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 27 new changesets Message-ID: <202008060551.0765p3mg000954@aojmv0008.oracle.com> Changeset: ab3ff63f7cd5 Author: andrew Date: 2020-07-27 17:00 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ab3ff63f7cd5 Added tag jdk8u265-ga for changeset 3bd5ac4488a3 ! .hgtags Changeset: 610401238989 Author: andrew Date: 2020-06-03 01:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/610401238989 Added tag jdk8u272-b00 for changeset f7691a80458c ! .hgtags Changeset: 45c8de52649c Author: ddong Date: 2020-06-02 14:29 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/45c8de52649c 8246310: Clean commented-out code about ModuleEntry andPackageEntry in JFR Reviewed-by: adinn ! src/share/vm/jfr/jni/jfrJavaSupport.cpp ! src/share/vm/jfr/metadata/metadata.xml ! src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.hpp ! src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp ! src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp ! src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp ! src/share/vm/jfr/recorder/repository/jfrEmergencyDump.cpp ! src/share/vm/jfr/writers/jfrWriterHost.hpp ! src/share/vm/jfr/writers/jfrWriterHost.inline.hpp Changeset: eddd586d1a4c Author: mgronlun Date: 2014-02-22 10:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/eddd586d1a4c 8035493: JVMTI PopFrame capability must instruct compilers not to prune locals Reviewed-by: kvn, sla, coleenp, sspitsyn ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/c1/c1_ValueStack.cpp ! src/share/vm/c1/c1_ValueStack.hpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/graphKit.cpp Changeset: 423fa1fba08e Author: andrew Date: 2020-06-09 06:24 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/423fa1fba08e Merge ! .hgtags Changeset: 26d1803768c7 Author: jbachorik Date: 2020-06-11 12:17 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/26d1803768c7 8233197: Invert JvmtiExport::post_vm_initialized() and Jfr:on_vm_start() start-up order for correct option parsing Reviewed-by: sspitsyn, egahlin ! src/share/vm/jfr/instrumentation/jfrJvmtiAgent.cpp ! src/share/vm/jfr/jfr.cpp ! src/share/vm/jfr/jfr.hpp ! src/share/vm/jfr/jni/jfrJavaSupport.cpp ! src/share/vm/jfr/jni/jfrJavaSupport.hpp ! src/share/vm/jfr/jni/jfrJniMethod.cpp ! src/share/vm/jfr/recorder/jfrRecorder.cpp ! src/share/vm/jfr/recorder/jfrRecorder.hpp ! src/share/vm/jfr/recorder/service/jfrOptionSet.cpp ! src/share/vm/jfr/recorder/service/jfrOptionSet.hpp ! src/share/vm/runtime/thread.cpp + test/runtime/8233197/T.java + test/runtime/8233197/Test8233197.sh + test/runtime/8233197/libJvmtiAgent.c Changeset: 1edff9dfe606 Author: mchinnathamb Date: 2018-10-26 18:35 +0530 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1edff9dfe606 8211714: Need to update vm_version.cpp to recognise VS2017 minor versions Reviewed-by: dholmes ! src/share/vm/runtime/vm_version.cpp Changeset: 103d1261f1f4 Author: mbaesken Date: 2019-12-06 12:42 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/103d1261f1f4 8235243: handle VS2017 15.9 and VS2019 in abstract_vm_version 8235325: build failure on Linux after 8235243 Reviewed-by: dholmes, mdoerr ! src/share/vm/runtime/vm_version.cpp Changeset: db357034b763 Author: bulasevich Date: 2020-06-16 11:03 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/db357034b763 8217647: JFR: recordings on 32-bit systems unreadable Reviewed-by: egahlin Contributed-by: boris.ulasevich at bell-sw.com, markus.gronlund at oracle.com ! src/share/vm/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp ! src/share/vm/jfr/recorder/checkpoint/jfrCheckpointWriter.hpp ! src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp ! src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp ! src/share/vm/jfr/recorder/repository/jfrChunkState.cpp ! src/share/vm/jfr/recorder/repository/jfrChunkState.hpp ! src/share/vm/jfr/recorder/repository/jfrChunkWriter.cpp ! src/share/vm/jfr/recorder/repository/jfrChunkWriter.hpp ! src/share/vm/jfr/recorder/repository/jfrRepository.cpp ! src/share/vm/jfr/recorder/repository/jfrRepository.hpp ! src/share/vm/jfr/recorder/service/jfrRecorderService.cpp ! src/share/vm/jfr/writers/jfrEventWriterHost.inline.hpp ! src/share/vm/jfr/writers/jfrPosition.hpp ! src/share/vm/jfr/writers/jfrPosition.inline.hpp ! src/share/vm/jfr/writers/jfrStreamWriterHost.hpp ! src/share/vm/jfr/writers/jfrStreamWriterHost.inline.hpp ! src/share/vm/jfr/writers/jfrWriterHost.hpp ! src/share/vm/jfr/writers/jfrWriterHost.inline.hpp Changeset: ae4fc0906f45 Author: stefank Date: 2016-04-11 08:51 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ae4fc0906f45 8153583: Make OutputAnalyzer.reportDiagnosticSummary public Reviewed-by: brutisso, sjohanss ! test/testlibrary/com/oracle/java/testlibrary/OutputAnalyzer.java Changeset: fb74ae591209 Author: andrew Date: 2020-06-29 21:30 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fb74ae591209 Merge ! .hgtags ! src/share/vm/jfr/jni/jfrJavaSupport.cpp ! src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.cpp ! src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.hpp ! src/share/vm/runtime/thread.cpp Changeset: f3ceb2e8bd21 Author: kevinw Date: 2020-03-09 12:54 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f3ceb2e8bd21 8240295: hs_err elapsed time in seconds is not accurate enough Reviewed-by: dholmes, sspitsyn ! src/share/vm/runtime/os.cpp Changeset: 2f07f8d27acf Author: mbaesken Date: 2020-03-30 17:55 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2f07f8d27acf 8230711: ConnectionGraph::unique_java_object(Node* N) return NULL if n is not in the CG Reviewed-by: mdoerr ! src/share/vm/opto/escape.cpp Changeset: 19056c781208 Author: roland Date: 2020-01-28 13:36 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/19056c781208 8237951: CTW: C2 compilation fails with "malformed control flow" Reviewed-by: vlivanov, kvn ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.cpp Changeset: 8a8f679915aa Author: roland Date: 2016-10-10 17:04 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8a8f679915aa 8167300: Scheduling failures during gcm should be fatal Reviewed-by: kvn, mcberg ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp Changeset: 1f0cffcf648a Author: phh Date: 2020-07-02 18:09 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1f0cffcf648a 8006205: [TESTBUG] NEED_TEST: please JTREGIFY test/compiler/7177917/Test7177917.java Summary: Update header comment to run with jtreg Reviewed-by: phh, sgehwolf Contributed-by: tianshi at amazon.com ! test/compiler/7177917/Test7177917.java Changeset: 02b4fd2f9041 Author: zgu Date: 2020-07-02 16:51 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/02b4fd2f9041 8248643: Remove extra leading space in JDK-8240295 8u backport Reviewed-by: kevinw, tschatzl ! src/share/vm/runtime/os.cpp Changeset: d961c6fee216 Author: andrew Date: 2020-07-24 13:16 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d961c6fee216 Merge ! .hgtags Changeset: d2ec2776ad0c Author: roland Date: 2020-03-09 17:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d2ec2776ad0c 8214862: assert(proj != __null) at compile.cpp:3251 Reviewed-by: kvn, thartmann ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/phaseX.cpp + test/compiler/inlining/StringConcatInfiniteLoop.java Changeset: 147bfde2dfd4 Author: andrew Date: 2020-07-24 13:37 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/147bfde2dfd4 Merge Changeset: ccdd791d3a6f Author: jbachorik Date: 2020-07-28 09:48 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ccdd791d3a6f 8243489: Thread CPU Load event may contain wrong data for CPU time under certain conditions Reviewed-by: jbachorik Contributed-by: Nikolay Martynov ! src/share/vm/jfr/periodic/jfrThreadCPULoadEvent.cpp Changeset: 8c3972a290c0 Author: andrew Date: 2020-07-29 05:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8c3972a290c0 Merge ! .hgtags Changeset: be13f53a2a55 Author: thartmann Date: 2019-12-03 08:29 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/be13f53a2a55 8234617: C1: Incorrect result of field load due to missing narrowing conversion Summary: Emit an explicit conversion to get the correct field value after the write. Reviewed-by: vlivanov, mdoerr, phh, andrew ! src/share/vm/c1/c1_GraphBuilder.cpp + test/compiler/conversions/Conversion.jasm + test/compiler/conversions/TestPrimitiveConversions.java Changeset: 85c9d74850ed Author: igerasim Date: 2019-09-10 09:08 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/85c9d74850ed 8230303: JDB hangs when running monitor command Reviewed-by: sspitsyn + test/vmTestbase/nsk/jdb/monitor/monitor002/monitor002.java + test/vmTestbase/nsk/jdb/monitor/monitor002/monitor002a.java Changeset: 014319f04f71 Author: andrew Date: 2020-08-01 03:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/014319f04f71 Merge jdk8u272-b01 ! .hgtags ! src/share/vm/c1/c1_GraphBuilder.cpp ! src/share/vm/c1/c1_Instruction.cpp ! src/share/vm/ci/ciEnv.cpp ! src/share/vm/ci/ciEnv.hpp ! src/share/vm/ci/ciMethod.cpp ! src/share/vm/opto/c2compiler.cpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/vm_version.cpp Changeset: 0a6f06133453 Author: andrew Date: 2020-08-01 03:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0a6f06133453 Added tag aarch64-shenandoah-jdk8u272-b01 for changeset 014319f04f71 ! .hgtags Changeset: e06616a839d0 Author: andrew Date: 2020-08-06 06:50 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e06616a839d0 Merge From aph at redhat.com Thu Aug 6 11:41:39 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 6 Aug 2020 12:41:39 +0100 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> Message-ID: <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> On 8/6/20 2:13 AM, Yangfei (Felix) wrote: > I have added tests for sha512 crypto instructions in this script and regenerated the code. > Tier1-3 tested with an aarch64 fastdebug build on my aarch64 linux host to cover this part. > Updated webrev: http://cr.openjdk.java.net/~fyang/8165404/webrev.02/ > Is it OK? Yes, thanks. It's a bit annoying that the indentation seems to change so frequently. I'm wondering if perhaps some people have been running this on Windows, which has different tab sizes, but that seems very unlikely, given that this is a Linux port. But never mind, that's not your problem. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ci_notify at linaro.org Thu Aug 6 13:32:23 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 6 Aug 2020 13:32:23 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 4172 Fixed Message-ID: <1643408817.3400.1596720744221@localhost> OpenJDK AArch64 jdk/jdk build status is Fixed Build details - https://ci.linaro.org/jenkins/job/jdkX-ci-build/4172/ Changes - zgu: 1f74c0319302ed6fd9bec9cee7c4eba8c8b09dd9 - src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp --"8251192: Shenandoah: Shenandoah build failed after JDK-8235573 Reviewed-by: stuefe, ysuenaga, adityam " Build output - Creating jdk.internal.le.jmod Creating jdk.internal.opt.jmod Creating jdk.internal.vm.ci.jmod Creating jdk.internal.vm.compiler.jmod Creating jdk.internal.vm.compiler.management.jmod Creating jdk.jartool.jmod Creating jdk.javadoc.jmod Creating jdk.jcmd.jmod Creating jdk.jconsole.jmod Creating jdk.jdeps.jmod Creating jdk.jdi.jmod Creating jdk.jdwp.agent.jmod Creating jdk.jfr.jmod Creating interim java.base.jmod Creating interim java.logging.jmod Creating jdk.jshell.jmod Creating jdk.jsobject.jmod Creating jdk.jstatd.jmod Creating jdk.localedata.jmod Creating jdk.management.jmod Creating jdk.management.agent.jmod Creating jdk.management.jfr.jmod Creating jdk.naming.dns.jmod Creating jdk.naming.rmi.jmod Creating jdk.net.jmod Creating jdk.nio.mapmode.jmod Creating jdk.sctp.jmod Creating jdk.security.auth.jmod Creating jdk.security.jgss.jmod Creating jdk.unsupported.jmod Creating jdk.unsupported.desktop.jmod Creating jdk.xml.dom.jmod Creating jdk.zipfs.jmod Compiling 3 files for BUILD_DEMO_CodePointIM Updating support/demos/image/jfc/CodePointIM/src.zip Compiling 3 files for BUILD_DEMO_FileChooserDemo Updating support/demos/image/jfc/FileChooserDemo/src.zip Compiling 29 files for BUILD_DEMO_SwingSet2 Updating support/demos/image/jfc/SwingSet2/src.zip Compiling 3 files for BUILD_DEMO_Font2DTest Updating support/demos/image/jfc/Font2DTest/src.zip Compiling 64 files for BUILD_DEMO_J2Ddemo Updating support/demos/image/jfc/J2Ddemo/src.zip Compiling 15 files for BUILD_DEMO_Metalworks Updating support/demos/image/jfc/Metalworks/src.zip Compiling 2 files for BUILD_DEMO_Notepad Updating support/demos/image/jfc/Notepad/src.zip Compiling 5 files for BUILD_DEMO_Stylepad Updating support/demos/image/jfc/Stylepad/src.zip Compiling 5 files for BUILD_DEMO_SampleTree Updating support/demos/image/jfc/SampleTree/src.zip Compiling 8 files for BUILD_DEMO_TableExample Updating support/demos/image/jfc/TableExample/src.zip Compiling 1 files for BUILD_DEMO_TransparentRuler Updating support/demos/image/jfc/TransparentRuler/src.zip Creating support/demos/image/jfc/CodePointIM/CodePointIM.jar Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar Creating support/demos/image/jfc/Font2DTest/Font2DTest.jar [0.036s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.032s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.007s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.088s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.051s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.006s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.006s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.025s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar [0.006s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/Metalworks/Metalworks.jar [0.006s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/Notepad/Notepad.jar [0.008s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/Stylepad/Stylepad.jar [0.024s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.061s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.008s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.053s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.009s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/SampleTree/SampleTree.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar [0.006s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.031s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.048s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.060s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.060s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.054s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating interim jimage Compiling 1 files for CLASSLIST_JAR Creating support/classlist.jar [0.005s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.056s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating jdk.jlink.jmod Creating java.base.jmod Creating jdk image Creating CDS archive for jdk image Creating CDS-NOCOOPS archive for jdk image Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From aph at redhat.com Thu Aug 6 13:34:08 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 6 Aug 2020 14:34:08 +0100 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8221658: aarch64: add necessary predicate for ubfx patterns In-Reply-To: References: Message-ID: On 8/6/20 2:41 AM, Yangfei (Felix) wrote: > Webrev for 8u-aarch64: http://cr.openjdk.java.net/~fyang/8221658-8u/webrev.00/ > Code changes to pattern ubfizL in the original patch is not necessary as it is not there in 8u aarch64. > > Performed full jtreg test with 8u aarch64 release build. OK to backport? Oh yes, definitely. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From beurba at microsoft.com Thu Aug 6 15:13:42 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Thu, 6 Aug 2020 15:13:42 +0000 Subject: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply In-Reply-To: References: , , Message-ID: Hello, can someone sponsor this change please? Webrev: http://cr.openjdk.java.net/~burban/8248816/ Thank you, -Bernhard ________________________________________ From: Bernhard Urban-Forster Sent: Friday, July 31, 2020 11:26 To: Andrew Haley; hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply Thank you for the review Andrew. I've updated the Reviewed-By line in the Webrev: http://cr.openjdk.java.net/~burban/8248816/ -Bernhard ________________________________________ From: Andrew Haley Sent: Thursday, July 30, 2020 19:14 To: Bernhard Urban-Forster; hotspot-dev Source Developers; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply On 30/07/2020 14:11, Bernhard Urban-Forster wrote: > Hi all, > > this is a small fixup: the declaration of `strength_reduce_multiply` uses a `jint` for the parameter `constant` [1], but some backends were using `int` instead. > > JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248816&data=02%7C01%7Cbeurba%40microsoft.com%7C5527aeead1ce44e1b67e08d834ac03c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317260684765118&sdata=28A9Rb7tzDC0rGgUJM6hQglZxzRmKBPtqEnXEbWYxWM%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~burban%2F8248816%2F&data=02%7C01%7Cbeurba%40microsoft.com%7C5527aeead1ce44e1b67e08d834ac03c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317260684765118&sdata=trUG1lHI%2F4CONPNFZQfZAai336f6vGfmsvbX5QTMLMs%3D&reserved=0 OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7Cbeurba%40microsoft.com%7C5527aeead1ce44e1b67e08d834ac03c1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637317260684765118&sdata=NYh2gNU6IIcZa4NW8eP173%2FoXpstoVF%2B02dFZsYTFzY%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Fri Aug 7 00:53:26 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 7 Aug 2020 00:53:26 +0000 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8221658: aarch64: add necessary predicate for ubfx patterns In-Reply-To: References: Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Thursday, August 6, 2020 9:34 PM > To: Yangfei (Felix) ; aarch64-port- > dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] 8u-aarch64: Backport 8221658: aarch64: add > necessary predicate for ubfx patterns > > On 8/6/20 2:41 AM, Yangfei (Felix) wrote: > > Webrev for 8u-aarch64: > > http://cr.openjdk.java.net/~fyang/8221658-8u/webrev.00/ > > Code changes to pattern ubfizL in the original patch is not necessary as it is > not there in 8u aarch64. > > > > Performed full jtreg test with 8u aarch64 release build. OK to backport? > > Oh yes, definitely. Thanks. Thanks for reviewing this. Pushed as: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/eeb2f76383f2 Felix From felix.yang at huawei.com Fri Aug 7 06:20:25 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Fri, 7 Aug 2020 06:20:25 +0000 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Thursday, August 6, 2020 7:42 PM > To: Yangfei (Felix) ; hotspot-runtime- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic > > On 8/6/20 2:13 AM, Yangfei (Felix) wrote: > > I have added tests for sha512 crypto instructions in this script and > regenerated the code. > > Tier1-3 tested with an aarch64 fastdebug build on my aarch64 linux host to > cover this part. > > Updated webrev: http://cr.openjdk.java.net/~fyang/8165404/webrev.02/ > > Is it OK? > > Yes, thanks. > > It's a bit annoying that the indentation seems to change so frequently. I'm > wondering if perhaps some people have been running this on Windows, > which has different tab sizes, but that seems very unlikely, given that this is a > Linux port. But never mind, that's not your problem. I see the output of the python script contains tabs which is not allowed by jcheck. So I guess it may depends on the way in which people substitute these tabs. I used vim editor to do the replacement, which is simple. Open the file which contains the script output and do: :set ts=8 :set expandtab :%retab! Looks like the indentation is more consistent this way. Hope that helps. Pushed as: https://hg.openjdk.java.net/jdk/jdk/rev/09ad5b67a099 Thanks, Felix From nick.gasson at arm.com Fri Aug 7 09:04:49 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 07 Aug 2020 17:04:49 +0800 Subject: [aarch64-port-dev ] RFR: 8247354: [aarch64] PopFrame causes assert(oopDesc::is_oop(obj)) failed: not an oop Message-ID: <85364ykery.fsf@nicgas01-pc.shanghai.arm.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8247354 Webrev: http://cr.openjdk.java.net/~ngasson/8247354/webrev.0/ Running jtreg test vmTestbase/nsk/jdb/pop/pop001/pop001.java with -Xcomp causes this assertion failure: assert(oopDesc::is_oop(obj)) failed: not an oop: 0x0000ffff60b334c0 This test has a sequence of method calls func1(0) -> func2(1) -> ... -> func5(4) -> lastBreak() with a breakpoint in lastBreak(). func{2..5} are inlined into func1 when compiled. At the breakpoint the debugger is used to pop four frames and then continue executing from func2. This causes func1 to be deoptimized but the recreated interpreter frame for func2 has garbage values in its temporary expression stack (the parameters for func3), which triggers the above assertion when the invoke bytecode re-executes. The outgoing parameters in func2's expression stack should be filled in when we recreate the locals for func3. But on AArch64 the template interpreter inserts padding between the locals block and the saved sender SP to align the machine SP to 16-bytes. This extra padding is accounted for by AbstractInterpreter::size_activation() but not when recreating the frame in layout_activation(). This causes the incoming parameters in the callee frame to be misaligned with outgoing parameters in the caller frame. This patch fixes that by using the caller's ESP to calculate the location of the locals if the caller is an interpreted frame. Tested jtreg hotspot_all_no_apps, jdk_core plus tier1 with -XX:+DeoptimizeALot. -- Thanks, Nick From adinn at redhat.com Fri Aug 7 13:25:09 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 7 Aug 2020 14:25:09 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> Message-ID: Hi Ningsheng, On 31/07/2020 02:41, Ningsheng Jian wrote: > Hi Andrew, > > Thanks a lot!! > > FYI, the latest patch: > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-July/039289.html > > > And some descriptions: > > http://cr.openjdk.java.net/~njian/8231441/README-RFR.txt Thanks for doing such a great job. This is very good work. Also, thanks for splitting the patch up to separate out the different steps -- that was immensely helpful. I have one general query and a small number of detailed comments which are provided separately for each patch. See below. Testing: I was able to test this patch on a loaned Fujitsu FX700. I replicated your results, passing tier1 tests and the jtreg compiler tests in vectorization, codegen, c2/cr6340864 and loopopts. I also eyeballed /some/ of the generated code to check that it looked ok. I'd really like to be able to do that systematically for a comprehensive test suite that exercised every rule but I only had the machine for a few days. This really ought to be done as a follow-up to ensure that all the rules are working as expected. General Comments: Sizing the NEON registers using 8 slots -- even though there might actually be more (or less!) slots in use for a VecA is fine. However, I think this needs a little bit more explanation in the .ad. file (see comments on ra webrev below) I'm ok with your choice to use p7 as an always true predicate register and also how you choose to init and re-init from code defined via the ad file based on C->max_vector_size(). I am not clear why you are choosing to re-init ptrue after certain JVM runtime calls (e.g. when Z calls into the runtime) and not others e.g. when we call a JVM_ENTRY. Could you explain the rationale you have followed here? Specific Comments (feature webrev): globals_aarch64.hpp:102 Just out of interest why does UseSVE have range(0,2)? It seems you are only testing for UseSVE > 0. Does value 2 correspond to an optional subset? Specific Comments (register allocator webrev): aarch64.ad:97-100 Why have you added a reg_def for R8 and R9 here and also to alloc_class chunk0 at lines 544-545? They aren't used by C2 so why define them? assembler_aarch64.hpp:280 (also 699) prf sets a predicate register field. pgrf sets a governing predicate register field. Should the name not be gprf. chaitin.cpp:648-660 The comment is rather oddly formatted. At line 650 you guard the assert with a test for lrg._is_vector. Is that not always going to be guaranteed by the outer condition lrg._is_scalable? If so then you should really assert lrg._is_vector. The special case code for computation of num_regs for a vector stack slot also appears in this file with a slightly different organization in find_first_set (line 1350) and in PhaseChaitin::Select (line 1590). There is another similar case in RegMask::num_registers at regmask.cpp: 98. It would be better to factor out the common code into methods of LRG. Maybe using the following? bool LRG::is_scalable_vector() { if (_is_scalable) { assert(_is_vector == 1); assert(_num_regs == == RegMask::SlotsPerVecA) return true; } return false; } int LRG::scalable_num_regs() { assert(is_scalable_vector()); if (OptoReg::is_stack(_reg)) { return _scalable_reg_slots } else { return num_reg_slots; } } chaitin.cpp:1350 Once again the test for lrg._is_vector should be guaranteed by the outer test of lrg._is_scalable. Refactoring using the common methods of LRG as above ought to help. chaitin.cpp:1591 Use common method code. postaloc.cpp:308/323 Once again you should be able to use common method code of LRG here. regmask.cpp:91 Once again you should be able to use common method code of LRG here. Specific Comments (c2 webrev): aarch64.ad:3815 very nice defensive check! assembler_aarch64.hpp:2469 & 2699+ Andrew Haley is definitely going to ask you to update function entry (assembler_aarch64.cpp:76) to call these new instruction generation methods and then validate the generated code using asm_check So, I guess you might as well do that now ;-) zBarrierSetAssembler_aarch64.cpp:434 Can you explain why we need to check p7 here and not do so in other places where we call into the JVM? I'm not saying this is wrong. I just want to know how you decided where re-init of p7 was needed. superword.cpp:97 Does this mean that is someone sets the maximum vector size to a non-power of two, such as 384, all superword operations will be bypassed? Including those which can be done using NEON vectors? regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From luhenry at microsoft.com Sun Aug 9 03:19:20 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Sun, 9 Aug 2020 03:19:20 +0000 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 Message-ID: Hello, Bug: https://bugs.openjdk.java.net/browse/JDK-8251216 Webrev: http://cr.openjdk.java.net/~luhenry/8251216/webrev.00 Testing: Linux-AArch64, fastdebug, test/hotspot/jtreg/compiler/intrinsics/sha/ test/hotspot/jtreg:tier1 test/jdk:tier1 This patch implements the MD5 intrinsic on AArch64 following its implementation on x86 [1]. The performance improvements are the following (on Linux-AArch64 on a Marvell TX2): -XX:-UseMD5Intrinsics Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units MessageDigests.digest md5 64 DEFAULT thrpt 10 1616.238 ? 28.082 ops/ms MessageDigests.digest md5 1024 DEFAULT thrpt 10 215.030 ? 0.691 ops/ms MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.228 ? 0.001 ops/ms -XX:+UseMD5Intrinsics Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units MessageDigests.digest md5 64 DEFAULT thrpt 10 2005.233 ? 40.513 ops/ms => 24% speedup MessageDigests.digest md5 1024 DEFAULT thrpt 10 275.979 ? 0.455 ops/ms => 28% speedup MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.279 ? 0.001 ops/ms => 22% speedup Thank you, Ludovic [1] https://bugs.openjdk.java.net/browse/JDK-8250902 From aph at redhat.com Sun Aug 9 14:32:48 2020 From: aph at redhat.com (Andrew Haley) Date: Sun, 9 Aug 2020 15:32:48 +0100 Subject: [aarch64-port-dev ] RFR: 8247354: [aarch64] PopFrame causes assert(oopDesc::is_oop(obj)) failed: not an oop In-Reply-To: <85364ykery.fsf@nicgas01-pc.shanghai.arm.com> References: <85364ykery.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: On 8/7/20 10:04 AM, Nick Gasson wrote: > Bug:https://bugs.openjdk.java.net/browse/JDK-8247354 > Webrev:http://cr.openjdk.java.net/~ngasson/8247354/webrev.0/ How did you test this? I'm looking through the test suite, but I can't find the test vectors. They must be in there somewhere. https://www.nist.gov/itl/ssd/software-quality-group/nsrl-test-data -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Mon Aug 10 01:34:41 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 10 Aug 2020 09:34:41 +0800 Subject: [aarch64-port-dev ] RFR: 8247354: [aarch64] PopFrame causes assert(oopDesc::is_oop(obj)) failed: not an oop In-Reply-To: References: <85364ykery.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <85lfinwafi.fsf@nicgas01-pc.shanghai.arm.com> On 08/09/20 22:32 pm, Andrew Haley wrote: > On 8/7/20 10:04 AM, Nick Gasson wrote: >> Bug:https://bugs.openjdk.java.net/browse/JDK-8247354 >> Webrev:http://cr.openjdk.java.net/~ngasson/8247354/webrev.0/ > > How did you test this? I'm looking through the test suite, but I can't > find the test vectors. They must be in there somewhere. > > https://www.nist.gov/itl/ssd/software-quality-group/nsrl-test-data Hi Andrew, did you reply to the wrong mail...? -- Nick From Pengfei.Li at arm.com Mon Aug 10 04:45:17 2020 From: Pengfei.Li at arm.com (Pengfei Li) Date: Mon, 10 Aug 2020 04:45:17 +0000 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> Message-ID: Hi Andrew Dinn, Thank you so much for taking the time to review this. As Ningsheng is on leave this week, I will attempt to answer your specific questions based on what I know. I'm sorry that I'm not able to answer all your questions since I'm not familiar with every detail of the patch. And you may still need to wait him coming back to update the webrev(s). > I was able to test this patch on a loaned Fujitsu FX700. I replicated your > results, passing tier1 tests and the jtreg compiler tests in vectorization, > codegen, c2/cr6340864 and loopopts. > > I also eyeballed /some/ of the generated code to check that it looked ok. I'd > really like to be able to do that systematically for a comprehensive test suite > that exercised every rule but I only had the machine for a few days. This > really ought to be done as a follow-up to ensure that all the rules are working > as expected. Not sure if you have tried my newly added test in the vectorization folder. It checks if expected SVE/NEON instructions are generated as expected for each C2 vectornode by checking the OptoAssembly output. I put it in another webrev so you may have missed it. http://cr.openjdk.java.net/~pli/rfr/8231441/jtreg.webrev.00/ > Specific Comments (feature webrev): > > > globals_aarch64.hpp:102 > > Just out of interest why does UseSVE have range(0,2)? It seems you are only > testing for UseSVE > 0. Does value 2 correspond to an optional subset? AArch64 SVE has multiple versions. Current Fujitsu FX machine supports SVE1 only. We leave 2 here for SVE2 support in the near future. https://developer.arm.com/tools-and-software/server-and-hpc/compile/arm-instruction-emulator/resources/tutorials/sve/sve-vs-sve2/introduction-to-sve2 > Specific Comments (register allocator webrev): > > > aarch64.ad:97-100 > > Why have you added a reg_def for R8 and R9 here and also to alloc_class > chunk0 at lines 544-545? They aren't used by C2 so why define them? This has no functionality change to the two scratch registers. But if these are missing in the register definition, the regmask for vector registers won't start at an aligned position. So we prefer adding them back to make the computation easier. > assembler_aarch64.hpp:280 (also 699) > > prf sets a predicate register field. pgrf sets a governing predicate register field. > Should the name not be gprf. I guess the reason is that the ArmARM doc says "the Pg field". > chaitin.cpp:648-660 > > The comment is rather oddly formatted. Thanks for catching this. > At line 650 you guard the assert with a test for lrg._is_vector. Is that not > always going to be guaranteed by the outer condition lrg._is_scalable? If so > then you should really assert lrg._is_vector. > > The special case code for computation of num_regs for a vector stack slot > also appears in this file with a slightly different organization in find_first_set > (line 1350) and in PhaseChaitin::Select (line 1590). > There is another similar case in RegMask::num_registers at regmask.cpp: > 98. It would be better to factor out the common code into methods of LRG. > Maybe using the following? > > bool LRG::is_scalable_vector() { > if (_is_scalable) { > assert(_is_vector == 1); > assert(_num_regs == == RegMask::SlotsPerVecA) > return true; > } > return false; > } > > int LRG::scalable_num_regs() { > assert(is_scalable_vector()); > if (OptoReg::is_stack(_reg)) { > return _scalable_reg_slots > } else { > return num_reg_slots; > } > } > > > chaitin.cpp:1350 > > Once again the test for lrg._is_vector should be guaranteed by the outer test > of lrg._is_scalable. Refactoring using the common methods of LRG as above > ought to help. > > chaitin.cpp:1591 > > Use common method code. > > > postaloc.cpp:308/323 > > Once again you should be able to use common method code of LRG here. > > > regmask.cpp:91 > > Once again you should be able to use common method code of LRG here. Thanks for above suggestions. We will consider refactoring these parts. > Specific Comments (c2 webrev): > > > aarch64.ad:3815 > > very nice defensive check! > > > assembler_aarch64.hpp:2469 & 2699+ > > Andrew Haley is definitely going to ask you to update function entry > (assembler_aarch64.cpp:76) to call these new instruction generation > methods and then validate the generated code using asm_check So, I guess > you might as well do that now ;-) Thanks for letting us know. We will check how to validate those. > zBarrierSetAssembler_aarch64.cpp:434 > > Can you explain why we need to check p7 here and not do so in other places > where we call into the JVM? I'm not saying this is wrong. I just want to know > how you decided where re-init of p7 was needed. Sorry I don't know how the places are decided. But I will ask Ningsheng to explain this question and reply you later. > superword.cpp:97 > > Does this mean that is someone sets the maximum vector size to a non- > power of two, such as 384, all superword operations will be bypassed? > Including those which can be done using NEON vectors? The existing SLP doesn't support non-power-of-2 vector size (there are some assertions inside) so we added this. Yes, it's better if we have some mechanism to fall back to NEON for non-power-of-2 size. But so far in practice, we don't know any real chip implements the non-power-of-2 vector size. Also, we are now working on a new predicate-driven auto-vectorization pass to support SVE better. Do you think it's ok if we print some warnings if someone sets a non-power-of-2 size in vm options? Or any other suggestions in the short term? -- Thanks, Pengfei From yueshi.zwj at alibaba-inc.com Mon Aug 10 07:24:52 2020 From: yueshi.zwj at alibaba-inc.com (Joshua Zhu) Date: Mon, 10 Aug 2020 15:24:52 +0800 Subject: [aarch64-port-dev ] =?utf-8?b?562U5aSNOiAgUkZSKEwpOiA4MjMxNDQx?= =?utf-8?q?=3A_AArch64=3A_Initial_SVE_backend_support?= In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> Message-ID: <003101d66ee7$56b5e3f0$0421abd0$@alibaba-inc.com> Hi Andrew, Thanks a lot for your review. > As Ningsheng is on leave this week, I will attempt to answer your specific > questions based on what I know. I'm sorry that I'm not able to answer all > your questions since I'm not familiar with every detail of the patch. And you > may still need to wait him coming back to update the webrev(s). I will help answer questions related with RA. > > Specific Comments (register allocator webrev): > > > > > > aarch64.ad:97-100 > > > > Why have you added a reg_def for R8 and R9 here and also to > > alloc_class > > chunk0 at lines 544-545? They aren't used by C2 so why define them? > > This has no functionality change to the two scratch registers. But if these are > missing in the register definition, the regmask for vector registers won't start > at an aligned position. So we prefer adding them back to make the > computation easier. Yes. Thanks Pengfei. > > > assembler_aarch64.hpp:280 (also 699) > > > > prf sets a predicate register field. pgrf sets a governing predicate register > field. > > Should the name not be gprf. > > I guess the reason is that the ArmARM doc says "the Pg field". > > > chaitin.cpp:648-660 > > > > The comment is rather oddly formatted. > > Thanks for catching this. > > > At line 650 you guard the assert with a test for lrg._is_vector. Is > > that not always going to be guaranteed by the outer condition > > lrg._is_scalable? If so then you should really assert lrg._is_vector. _is_scalable tells the register length for the live range is scalable. This rule applies for both SVE vector register and predicate register. Each predicate register holds one bit per byte of SVE vector register, meaning that each predicate register is one-eighth of the size of SVE vector register. Each predicate register is an IMPLEMENTATION DEFINED multiple of 16 bits, up to 256 bits. Although the actual length of predicate register is scalable, the max slots is always defined as 1. class PRegisterImpl: public AbstractRegisterImpl { public: enum { number_of_registers = 16, max_slots_per_register = 1 }; I think this patch under review does not include the part of predicate register allocation. > > The special case code for computation of num_regs for a vector stack > > slot also appears in this file with a slightly different organization > > in find_first_set (line 1350) and in PhaseChaitin::Select (line 1590). > > There is another similar case in RegMask::num_registers at regmask.cpp: > > 98. It would be better to factor out the common code into methods of LRG. > > Maybe using the following? > > > > bool LRG::is_scalable_vector() { > > if (_is_scalable) { > > assert(_is_vector == 1); > > assert(_num_regs == == RegMask::SlotsPerVecA) > > return true; > > } > > return false; > > } > > > > int LRG::scalable_num_regs() { > > assert(is_scalable_vector()); > > if (OptoReg::is_stack(_reg)) { > > return _scalable_reg_slots > > } else { > > return num_reg_slots; > > } > > } > > > > chaitin.cpp:1350 > > > > Once again the test for lrg._is_vector should be guaranteed by the > > outer test of lrg._is_scalable. Refactoring using the common methods > > of LRG as above ought to help. > > > > chaitin.cpp:1591 > > > > Use common method code. > > > > > > postaloc.cpp:308/323 > > > > Once again you should be able to use common method code of LRG here. > > > > > > regmask.cpp:91 > > > > Once again you should be able to use common method code of LRG here. PhaseChaitin::Select (line 1590) will cover both SVE vector and predicate cases in future. 1590 // We always choose the high bit, then mask the low bits by register size 1591 if (lrg->_is_scalable && OptoReg::is_stack(lrg->reg())) { // stack 1592 n_regs = lrg->scalable_reg_slots(); 1593 } I think regmask.cpp (line 98) in future will look like: 98 if (lrg._is_scalable && OptoReg::is_stack(assigned)) { 99 if (lrg._is_vector) { 100 assert(ireg == Op_VecA, "scalable vector register"); 101 } else if (lrg._is_predicate) { assert(ireg == Op_RegVMask, "scalable predicate register"); } 102 n_regs = lrg.scalable_reg_slots(); 103 } 104 105 return n_regs; 106 } Please correct me if any issues. Thanks. Best Regards, Joshua From adinn at redhat.com Mon Aug 10 08:43:34 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 10 Aug 2020 09:43:34 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> Message-ID: <6562d0da-f081-ede8-dfef-d3d6c70fb998@redhat.com> Hi Pengfei, On 10/08/2020 05:45, Pengfei Li wrote: >> I also eyeballed /some/ of the generated code to check that it >> looked ok. I'd really like to be able to do that systematically for >> a comprehensive test suite that exercised every rule but I only had >> the machine for a few days. This really ought to be done as a >> follow-up to ensure that all the rules are working as expected. > > Not sure if you have tried my newly added test in the vectorization > folder. It checks if expected SVE/NEON instructions are generated as > expected for each C2 vectornode by checking the OptoAssembly output. > I put it in another webrev so you may have missed it. > http://cr.openjdk.java.net/~pli/rfr/8231441/jtreg.webrev.00/ Ah, thank you. That was not in the patch I Ningsheng pointed me at. It is exactly what is needed to check the generation rules are all working. >> Just out of interest why does UseSVE have range(0,2)? It seems you >> are only testing for UseSVE > 0. Does value 2 correspond to an >> optional subset? > AArch64 SVE has multiple versions. Current Fujitsu FX machine > supports SVE1 only. We leave 2 here for SVE2 support in the near > future. > https://developer.arm.com/tools-and-software/server-and-hpc/compile/arm-instruction-emulator/resources/tutorials/sve/sve-vs-sve2/introduction-to-sve2 Ah ok, thanks. Got it. Being able to switch on level 1 without level 2 is a good idea. >> Why have you added a reg_def for R8 and R9 here and also to >> alloc_class chunk0 at lines 544-545? They aren't used by C2 so why >> define them? > > This has no functionality change to the two scratch registers. But if > these are missing in the register definition, the regmask for vector > registers won't start at an aligned position. So we prefer adding > them back to make the computation easier. It would be good to make this clear with a comment. Also, I think you should change the name of the registers to R8_UNUSED and R9_UNUSED just to emphasize that these are not expected to be included in any register sets. >> prf sets a predicate register field. pgrf sets a governing >> predicate register field. Should the name not be gprf. > > I guess the reason is that the ArmARM doc says "the Pg field". Ok, let's leave it at that then and blame ARM ;-) >> chaitin.cpp:648-660 >> >> The comment is rather oddly formatted. > > Thanks for catching this. Well, that's what reviews are for ... >> At line 650 you guard the assert with a test for lrg._is_vector. Is >> that not always going to be guaranteed by the outer condition >> lrg._is_scalable? If so then you should really assert >> lrg._is_vector. >> >> . . . > Thanks for above suggestions. We will consider refactoring these > parts. Ok, I'll wait for an updated webrev. >> Andrew Haley is definitely going to ask you to update function >> entry (assembler_aarch64.cpp:76) to call these new instruction >> generation methods and then validate the generated code using >> asm_check So, I guess you might as well do that now ;-) > > Thanks for letting us know. We will check how to validate those. Ok, thanks. >> Can you explain why we need to check p7 here and not do so in other >> places where we call into the JVM? I'm not saying this is wrong. I >> just want to know how you decided where re-init of p7 was needed. > > Sorry I don't know how the places are decided. But I will ask > Ningsheng to explain this question and reply you later. Sure, thanks. >> Does this mean that is someone sets the maximum vector size to a >> non- power of two, such as 384, all superword operations will be >> bypassed? Including those which can be done using NEON vectors? > > The existing SLP doesn't support non-power-of-2 vector size (there > are some assertions inside) so we added this. Yes, it's better if we > have some mechanism to fall back to NEON for non-power-of-2 size. But > so far in practice, we don't know any real chip implements the > non-power-of-2 vector size. Also, we are now working on a new > predicate-driven auto-vectorization pass to support SVE better. Do > you think it's ok if we print some warnings if someone sets a > non-power-of-2 size in vm options? Or any other suggestions in the > short term? Well, the test for MaxVectorSize in vm_version.cpp currently only ensures it has been set to a multiple of 16. I think you probably ought to check for a power of two at that point and exit the VM otherwise. If hardware comes along that supports a non-power of two we can deal with it at that point. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Mon Aug 10 09:18:59 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 10 Aug 2020 10:18:59 +0100 Subject: [aarch64-port-dev ] =?utf-8?b?562U5aSNOiAgUkZSKEwpOiA4MjMxNDQx?= =?utf-8?q?=3A_AArch64=3A_Initial_SVE_backend_support?= In-Reply-To: <003101d66ee7$56b5e3f0$0421abd0$@alibaba-inc.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <003101d66ee7$56b5e3f0$0421abd0$@alibaba-inc.com> Message-ID: Hi Joshua, On 10/08/2020 08:24, Joshua Zhu wrote: > I will help answer questions related with RA. Thanks for your help. >>> At line 650 you guard the assert with a test for lrg._is_vector. Is >>> that not always going to be guaranteed by the outer condition >>> lrg._is_scalable? If so then you should really assert lrg._is_vector. > > _is_scalable tells the register length for the live range is > scalable. This rule applies for both SVE vector register and > predicate register. Each predicate register holds one bit per > byte of SVE vector register, meaning that each predicate > register is one-eighth of the size of SVE vector register. > Each predicate register is an IMPLEMENTATION DEFINED multiple > of 16 bits, up to 256 bits. Although the actual length of > predicate register is scalable, the max slots is always defined > as 1.> class PRegisterImpl: public AbstractRegisterImpl { > public: > enum { > number_of_registers = 16, > max_slots_per_register = 1 > }; > I think this patch under review does not include the part of > predicate register allocation. Ok, I understand that _is_scalable is meant to identify both a predicate register and an SVE vector register. Something definitely seems to be missing because field LRG::_is_scalable is not set in the case where we have a PRegisterImpl (Op_RegVMask). In webrev03 it only ever gets set at chaitin.cpp:822: if (RegMask::is_vector(ireg)) { lrg._is_vector = 1; if (ireg == Op_VecA) { assert(Matcher::supports_scalable_vector(), "scalable vector should be supported"); lrg._is_scalable = 1; // For scalable vector, when it is allocated in physical register, // num_regs is RegMask::SlotsPerVecA for reg mask, // which may not be the actual physical register size. // If it is allocated in stack, we need to get the actual // physical length of scalable vector register. lrg.set_scalable_reg_slots(Matcher::scalable_vector_reg_size(T_FLOAT)); } So, it seems LRG::_is_scalable will only be set for a VecA register. If you could check what code might be missing and post a new webrev I'll look at this again. However, it would still be good to try to factor out some common code into methods if possible. >>> The special case code for computation of num_regs for a vector stack >>> slot also appears in this file with a slightly different organization >>> . . . > PhaseChaitin::Select (line 1590) will cover both SVE vector and predicate cases in future. > 1590 // We always choose the high bit, then mask the low bits by register size > 1591 if (lrg->_is_scalable && OptoReg::is_stack(lrg->reg())) { // stack > 1592 n_regs = lrg->scalable_reg_slots(); > 1593 } > > I think regmask.cpp (line 98) in future will look like: > 98 if (lrg._is_scalable && OptoReg::is_stack(assigned)) { > 99 if (lrg._is_vector) { > 100 assert(ireg == Op_VecA, "scalable vector register"); > 101 } > else if (lrg._is_predicate) { > assert(ireg == Op_RegVMask, "scalable predicate register"); > } > 102 n_regs = lrg.scalable_reg_slots(); > 103 } > 104 > 105 return n_regs; > 106 } > > Please correct me if any issues. Thanks. Ok, I agree that this will be correct when we can come across the case where lrg._is_scalable is true and ireg == Op_RegVMask. However, that case does not currently arise. So, a new webrev that allows for this case would help. Thanks for helping to explain what is going on here. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From beurba at microsoft.com Mon Aug 10 13:01:45 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 10 Aug 2020 13:01:45 +0000 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 In-Reply-To: <9074F4C9-589A-4519-BBAB-2F3161B814D7@oracle.com> References: , <9074F4C9-589A-4519-BBAB-2F3161B814D7@oracle.com> Message-ID: Hey Doug, replying on behalf for Ludovic, as he is on vacation :-) Currently we are not planning to implement the intrinsic for Graal. Also we didn't check the generated code by Graal. I believe it will do a better job eliminated array bounds checks, but I'm curious to learn how "compiling the relevant Java code without array bounds checks" works. Is something like that done for other methods already? This is the relevant Java method for the MD5 intrinsic: https://github.com/openjdk/jdk/blob/733218137289d6a0eb705103ed7be30f1e68d17a/src/java.base/share/classes/sun/security/provider/MD5.java#L172 -Bernhard ________________________________________ From: Doug Simon Sent: Monday, August 10, 2020 11:55 To: Ludovic Henry Cc: hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 Subject: Re: [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 Hi Ludovic, Are you considering also implementing this intrinsic in Graal? Is the intrinsification purely about removing the array bounds checks? If so, it may be possible to have the Graal intrinsify the method by compiling the relevant Java code without array bounds checks. -Doug > On 9 Aug 2020, at 05:19, Ludovic Henry wrote: > > Hello, > > Bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8251216&data=02%7C01%7Cbeurba%40microsoft.com%7C087d5d80f9484f13ddcc08d83d138f3a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637326501506459034&sdata=C7Bi8BTsmtR3HFgWgYTw7jww63BcHGutNXE8o9x2bdY%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~luhenry%2F8251216%2Fwebrev.00&data=02%7C01%7Cbeurba%40microsoft.com%7C087d5d80f9484f13ddcc08d83d138f3a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637326501506459034&sdata=0CZOMfpmtPZiy64za8NYYpVjCdawmjGacEOc3WfADDA%3D&reserved=0 > > Testing: Linux-AArch64, fastdebug, test/hotspot/jtreg/compiler/intrinsics/sha/ test/hotspot/jtreg:tier1 test/jdk:tier1 > > This patch implements the MD5 intrinsic on AArch64 following its implementation on x86 [1]. The performance improvements are the following (on Linux-AArch64 on a Marvell TX2): > > -XX:-UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 1616.238 ? 28.082 ops/ms > MessageDigests.digest md5 1024 DEFAULT thrpt 10 215.030 ? 0.691 ops/ms > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.228 ? 0.001 ops/ms > > -XX:+UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 2005.233 ? 40.513 ops/ms => 24% speedup > MessageDigests.digest md5 1024 DEFAULT thrpt 10 275.979 ? 0.455 ops/ms => 28% speedup > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.279 ? 0.001 ops/ms => 22% speedup > > Thank you, > Ludovic > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250902&data=02%7C01%7Cbeurba%40microsoft.com%7C087d5d80f9484f13ddcc08d83d138f3a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637326501506459034&sdata=5KcoG5n10rnVMU9y8L076jpCoEd0NBzNqr%2F8M5ghO3c%3D&reserved=0 From patric.hedlin at oracle.com Tue Aug 11 09:00:15 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Tue, 11 Aug 2020 11:00:15 +0200 Subject: [aarch64-port-dev ] RFR(XS/T): 8250848: [aarch64] nativeGotJump_at() missing call to verify(). Message-ID: <6a148562-eb36-1fc5-895f-024a6135b002@oracle.com> Please review this trivial change/update. --- a/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp??? Mon Aug 10 12:57:38 2020 +0100 +++ b/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp??? Mon Aug 10 16:50:20 2020 +0200 @@ -537,6 +537,7 @@ ?inline NativeGotJump* nativeGotJump_at(address addr) { ?? NativeGotJump* jump = (NativeGotJump*)(addr); +? DEBUG_ONLY(jump->verify()); ?? return jump; ?} Issue: https://bugs.openjdk.java.net/browse/JDK-8250848 Webrev with additional (trivial) /code style/ conforming clean-up: ? ? ?? http://cr.openjdk.java.net/~phedlin/tr8250848/ Testing: tier1-3 Best regards, Patric From aph at redhat.com Tue Aug 11 10:06:03 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 11 Aug 2020 11:06:03 +0100 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 In-Reply-To: References: Message-ID: <2d960bbe-0191-db94-2d5c-7df511a36dba@redhat.com> On 09/08/2020 04:19, Ludovic Henry wrote: > Hello, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251216 > Webrev: http://cr.openjdk.java.net/~luhenry/8251216/webrev.00 > > Testing: Linux-AArch64, fastdebug, test/hotspot/jtreg/compiler/intrinsics/sha/ test/hotspot/jtreg:tier1 test/jdk:tier1 > > This patch implements the MD5 intrinsic on AArch64 following its implementation on x86 [1]. The performance improvements are the following (on Linux-AArch64 on a Marvell TX2): > > -XX:-UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 1616.238 ? 28.082 ops/ms > MessageDigests.digest md5 1024 DEFAULT thrpt 10 215.030 ? 0.691 ops/ms > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.228 ? 0.001 ops/ms > > -XX:+UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 2005.233 ? 40.513 ops/ms => 24% speedup > MessageDigests.digest md5 1024 DEFAULT thrpt 10 275.979 ? 0.455 ops/ms => 28% speedup > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.279 ? 0.001 ops/ms => 22% speedup > > Thank you, > Ludovic > > [1] https://bugs.openjdk.java.net/browse/JDK-8250902 > How did you test this? I'm looking through the test suite, but I can't find the test vectors. They must be in there somewhere. https://www.nist.gov/itl/ssd/software-quality-group/nsrl-test-data -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 11 10:06:28 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 11 Aug 2020 11:06:28 +0100 Subject: [aarch64-port-dev ] RFR: 8247354: [aarch64] PopFrame causes assert(oopDesc::is_oop(obj)) failed: not an oop In-Reply-To: <85lfinwafi.fsf@nicgas01-pc.shanghai.arm.com> References: <85364ykery.fsf@nicgas01-pc.shanghai.arm.com> <85lfinwafi.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <8b4d4db0-01d0-3501-8114-382fff8b06bc@redhat.com> On 10/08/2020 02:34, Nick Gasson wrote: > Hi Andrew, did you reply to the wrong mail...? Looks like it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 11 10:08:53 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 11 Aug 2020 11:08:53 +0100 Subject: [aarch64-port-dev ] RFR(XS/T): 8250848: [aarch64] nativeGotJump_at() missing call to verify(). In-Reply-To: <6a148562-eb36-1fc5-895f-024a6135b002@oracle.com> References: <6a148562-eb36-1fc5-895f-024a6135b002@oracle.com> Message-ID: <4ddd50f6-6449-fd4a-58c0-dc77a523434e@redhat.com> On 11/08/2020 10:00, Patric Hedlin wrote: > > Issue:https://bugs.openjdk.java.net/browse/JDK-8250848 > > Webrev with additional (trivial)/code style/ conforming clean-up: > http://cr.openjdk.java.net/~phedlin/tr8250848/ OK. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From patric.hedlin at oracle.com Tue Aug 11 11:16:51 2020 From: patric.hedlin at oracle.com (Patric Hedlin) Date: Tue, 11 Aug 2020 13:16:51 +0200 Subject: [aarch64-port-dev ] RFR(XS/T): 8250848: [aarch64] nativeGotJump_at() missing call to verify(). In-Reply-To: <4ddd50f6-6449-fd4a-58c0-dc77a523434e@redhat.com> References: <6a148562-eb36-1fc5-895f-024a6135b002@oracle.com> <4ddd50f6-6449-fd4a-58c0-dc77a523434e@redhat.com> Message-ID: Thank you for reviewing Andrew. /Patric On 2020-08-11 12:08, Andrew Haley wrote: > On 11/08/2020 10:00, Patric Hedlin wrote: >> >> Issue:https://bugs.openjdk.java.net/browse/JDK-8250848 >> >> Webrev with additional (trivial)/code style/? conforming clean-up: >> ???????? http://cr.openjdk.java.net/~phedlin/tr8250848/ > > OK. > From Monica.Beckwith at microsoft.com Tue Aug 11 18:15:24 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Tue, 11 Aug 2020 18:15:24 +0000 Subject: [aarch64-port-dev ] Collaboration proposal: Draft JEP MacOS/AArch64 Port Message-ID: Hello everyone,? It gives me immense pleasure to see the draft JEP?for?'MacOS/AArch64 Port'?[1].?At Microsoft, we are in the?process of expanding our CI infrastructure by adding Apple?DevKits?[2]. We are?entirely?in support?of you and your?team, @Anton Kozlov.?You all bring your immense?knowledge from?the?AArch32 port,?and we welcome?you?and would like to extend our?collaboration?on?the MacOS?port.?More specifically,?we would like to work with you?on?the?-?? . Implementation (low-level code additions, shared code modifications and?maintenance, adhering to?HotSpot?coding style/conventions [3], etc.)?? . Testing (all?regression,?functional, integration?and performance?tests)? . Integration to?jdk/jdk?(tip)? Since the?MacOS?port?work depends on the?Windows port modifications, I?propose a?collaboration (sub-)Project [4]?repo where we?can?jointly?work in the open.? If it is OK with you and your team, next week,?I can propose the creation of?a new (sub-)Project?for?'jdk-mac'?and send it out to?mailto:discuss at openjdk.java.net and mailto:aarch64-port-dev at openjdk.java.net. Once we have a sponsor,?we can?send the?info out on?mailto:announce at openjdk.java.net. We can work?on?the details of these offline.?Please let me know if you have already?made traction on the (sub-)Project front,?and we can jump?in and help?wherever?you are.? This?is?a?wonderful?opportunity?for?OpenJDK,?and?the?team?here?at?Microsoft?is excited about?the?prospects, and we are?looking?forward?to?working?with?your?team.? Thanks,? Monica [1] http://openjdk.java.net/jeps/8251280 [2] https://developer.apple.com/programs/universal/ [3] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide [4] http://openjdk.java.net/projects/#new-project From luhenry at microsoft.com Tue Aug 11 18:28:56 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Tue, 11 Aug 2020 18:28:56 +0000 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 In-Reply-To: <2d960bbe-0191-db94-2d5c-7df511a36dba@redhat.com> References: <2d960bbe-0191-db94-2d5c-7df511a36dba@redhat.com> Message-ID: Hi Andrew, (I'm currently on vacation and will come back on the 20th.) I've relied on the existing test suite, which was also enhanced when submitting the patch for the MD5 intrinsic on x86 [1]. To help in the development, I've also generated 1k random strings, got them through md5sum on Linux, and compared the output of this MD5 intrinsic on the same input. I did not use [2] as a testing bed, but would be happy to add it to the OpenJDK test suite (if the license allows for it, I didn't check yet where it's allowed). > I'm looking through the test suite, but I can't find the test vectors. They must be in there somewhere. test/hotspot/jtreg/compiler/intrinsics/sha/TestDigest.java covers that by running a single value with and without the intrinsic. -- Ludovic [1] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-August/039327.html [2] https://www.nist.gov/itl/ssd/software-quality-group/nsrl-test-data From beurba at microsoft.com Tue Aug 11 20:23:50 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Tue, 11 Aug 2020 20:23:50 +0000 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 In-Reply-To: References: <9074F4C9-589A-4519-BBAB-2F3161B814D7@oracle.com> , Message-ID: Hey Doug, since I was curious I did a bit of digging. Here are my findings: 1. Graal is able to detect that it only needs to do the array bounds check once for all the 16 array accesses, as I expected. 2. Thus the generated code by Graal is almost as fast as the MD5 intrinsic. 3. The gap, from what I can tell, is that the SchedulePhase decides to put all the 16 FloatingReadNodes at the top of the basic block, and thus increasing register pressure and therefore ending up needing to spill on x86_64. It would be nice if the read access would be scheduled next to its usage in this case. I couldn't figure out how to do that, it has been a while since I've touched that code :-) Here are some numbers plus the generated code of C2, the intrinsic and Graal: https://gist.github.com/lewurm/3b874558d369fd56b3737e28f1616740 -Bernhard ________________________________________ From: Doug Simon Sent: Monday, August 10, 2020 15:38 To: Bernhard Urban-Forster Cc: Ludovic Henry; hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 Subject: Re: [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 Hi Bernhard, On 10 Aug 2020, at 15:01, Bernhard Urban-Forster > wrote: Hey Doug, replying on behalf for Ludovic, as he is on vacation :-) Currently we are not planning to implement the intrinsic for Graal. Schade ;-) Also we didn't check the generated code by Graal. I believe it will do a better job eliminated array bounds checks, but I'm curious to learn how "compiling the relevant Java code without array bounds checks" works. Is something like that done for other methods already? I don?t think we do that anywhere currently but I imagine it wouldn?t be hard to put the BytecodeParser into a mode whereby an array access generates a AccessIndexedNode that omits the bounds check (generated by org.graalvm.compiler.replacements.DefaultJavaLoweringProvider.getBoundsCheck). -Doug This is the relevant Java method for the MD5 intrinsic: https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/733218137289d6a0eb705103ed7be30f1e68d17a/src/java.base/share/classes/sun/security/provider/MD5.java*L172__;Iw!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E6ijVLDV$ -Bernhard ________________________________________ From: Doug Simon > Sent: Monday, August 10, 2020 11:55 To: Ludovic Henry Cc: hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 Subject: Re: [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 Hi Ludovic, Are you considering also implementing this intrinsic in Graal? Is the intrinsification purely about removing the array bounds checks? If so, it may be possible to have the Graal intrinsify the method by compiling the relevant Java code without array bounds checks. -Doug On 9 Aug 2020, at 05:19, Ludovic Henry > wrote: Hello, Bug: https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbugs.openjdk.java.net*2Fbrowse*2FJDK-8251216&data=02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034&sdata=C7Bi8BTsmtR3HFgWgYTw7jww63BcHGutNXE8o9x2bdY*3D&reserved=0__;JSUlJSUlJSUlJSUlJSU!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E97IPBA3$ Webrev: https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=http:*2F*2Fcr.openjdk.java.net*2F*luhenry*2F8251216*2Fwebrev.00&data=02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034&sdata=0CZOMfpmtPZiy64za8NYYpVjCdawmjGacEOc3WfADDA*3D&reserved=0__;JSUlfiUlJSUlJSUlJSUl!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E84nlzLJ$ Testing: Linux-AArch64, fastdebug, test/hotspot/jtreg/compiler/intrinsics/sha/ test/hotspot/jtreg:tier1 test/jdk:tier1 This patch implements the MD5 intrinsic on AArch64 following its implementation on x86 [1]. The performance improvements are the following (on Linux-AArch64 on a Marvell TX2): -XX:-UseMD5Intrinsics Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units MessageDigests.digest md5 64 DEFAULT thrpt 10 1616.238 ? 28.082 ops/ms MessageDigests.digest md5 1024 DEFAULT thrpt 10 215.030 ? 0.691 ops/ms MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.228 ? 0.001 ops/ms -XX:+UseMD5Intrinsics Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units MessageDigests.digest md5 64 DEFAULT thrpt 10 2005.233 ? 40.513 ops/ms => 24% speedup MessageDigests.digest md5 1024 DEFAULT thrpt 10 275.979 ? 0.455 ops/ms => 28% speedup MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.279 ? 0.001 ops/ms => 22% speedup Thank you, Ludovic [1] https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbugs.openjdk.java.net*2Fbrowse*2FJDK-8250902&data=02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034&sdata=5KcoG5n10rnVMU9y8L076jpCoEd0NBzNqr*2F8M5ghO3c*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUl!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E6SPJBTN$ From beurba at microsoft.com Tue Aug 11 20:45:27 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Tue, 11 Aug 2020 20:45:27 +0000 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 In-Reply-To: <80E25174-9E0E-40EF-AF75-7295782CE360@oracle.com> References: <9074F4C9-589A-4519-BBAB-2F3161B814D7@oracle.com> , <80E25174-9E0E-40EF-AF75-7295782CE360@oracle.com> Message-ID: That's great to hear :-) Thank you, -Bernhard ________________________________________ From: Doug Simon Sent: Tuesday, August 11, 2020 22:32 To: Bernhard Urban-Forster Cc: Ludovic Henry; hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64; Thomas Wuerthinger; David Leopoldseder Subject: Re: [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 Thanks for the digging and results Bernhard. We?ve discussed making the SchedulePhase do latency-aware scheduling within blocks but haven?t done anything yet. -Doug > On 11 Aug 2020, at 22:23, Bernhard Urban-Forster wrote: > > Hey Doug, > > since I was curious I did a bit of digging. Here are my findings: > > 1. Graal is able to detect that it only needs to do the array bounds check once for all the 16 array accesses, as I expected. > 2. Thus the generated code by Graal is almost as fast as the MD5 intrinsic. > 3. The gap, from what I can tell, is that the SchedulePhase decides to put all the 16 FloatingReadNodes at the top of the basic block, and thus increasing register pressure and therefore ending up needing to spill on x86_64. It would be nice if the read access would be scheduled next to its usage in this case. I couldn't figure out how to do that, it has been a while since I've touched that code :-) > > Here are some numbers plus the generated code of C2, the intrinsic and Graal: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgist.github.com%2Flewurm%2F3b874558d369fd56b3737e28f1616740__%3B!!GqivPVa7Brio!L6XXaWxHy6hbPWSWzBRyX9XuZtH1g0pfzTBa7gBrTWM3Fd7snIsiUwYctRenoV51%24&data=02%7C01%7Cbeurba%40microsoft.com%7C4604acd9be3e4dafdb8d08d83e35c6ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637327747982263260&sdata=da4FNCvOEUajDgNYLdNl2DNo3diwgsCsGy8BCD%2BipPA%3D&reserved=0 > > -Bernhard > > ________________________________________ > From: Doug Simon > Sent: Monday, August 10, 2020 15:38 > To: Bernhard Urban-Forster > Cc: Ludovic Henry; hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 > Subject: Re: [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 > > Hi Bernhard, > > > On 10 Aug 2020, at 15:01, Bernhard Urban-Forster > wrote: > > Hey Doug, > > replying on behalf for Ludovic, as he is on vacation :-) > > Currently we are not planning to implement the intrinsic for Graal. > > Schade ;-) > > Also we didn't check the generated code by Graal. I believe it will do a better job eliminated array bounds checks, but I'm curious to learn how "compiling the relevant Java code without array bounds checks" works. Is something like that done for other methods already? > > I don?t think we do that anywhere currently but I imagine it wouldn?t be hard to put the BytecodeParser into a mode whereby an array access generates a AccessIndexedNode that omits the bounds check (generated by org.graalvm.compiler.replacements.DefaultJavaLoweringProvider.getBoundsCheck). > > -Doug > > > This is the relevant Java method for the MD5 intrinsic: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F733218137289d6a0eb705103ed7be30f1e68d17a%2Fsrc%2Fjava.base%2Fshare%2Fclasses%2Fsun%2Fsecurity%2Fprovider%2FMD5.java*L172__%3BIw!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E6ijVLDV%24&data=02%7C01%7Cbeurba%40microsoft.com%7C4604acd9be3e4dafdb8d08d83e35c6ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637327747982273214&sdata=BTu7UyXhnF1XPmbzhpVQ3y3mQ1evQHuVe0qKMgj%2FNDs%3D&reserved=0 > > > -Bernhard > > ________________________________________ > From: Doug Simon > > Sent: Monday, August 10, 2020 11:55 > To: Ludovic Henry > Cc: hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 > Subject: Re: [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 > > Hi Ludovic, > > Are you considering also implementing this intrinsic in Graal? > > Is the intrinsification purely about removing the array bounds checks? If so, it may be possible to have the Graal intrinsify the method by compiling the relevant Java code without array bounds checks. > > -Doug > > On 9 Aug 2020, at 05:19, Ludovic Henry > wrote: > > Hello, > > Bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fbugs.openjdk.java.net*2Fbrowse*2FJDK-8251216%26amp%3Bdata%3D02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034%26amp%3Bsdata%3DC7Bi8BTsmtR3HFgWgYTw7jww63BcHGutNXE8o9x2bdY*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSU!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E97IPBA3%24&data=02%7C01%7Cbeurba%40microsoft.com%7C4604acd9be3e4dafdb8d08d83e35c6ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637327747982273214&sdata=gzxWbxSJGlmPvXnYko6rvVAKnbeJOWhWhISqTJvVaA8%3D&reserved=0 > Webrev: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%3A*2F*2Fcr.openjdk.java.net*2F*luhenry*2F8251216*2Fwebrev.00%26amp%3Bdata%3D02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034%26amp%3Bsdata%3D0CZOMfpmtPZiy64za8NYYpVjCdawmjGacEOc3WfADDA*3D%26amp%3Breserved%3D0__%3BJSUlfiUlJSUlJSUlJSUl!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E84nlzLJ%24&data=02%7C01%7Cbeurba%40microsoft.com%7C4604acd9be3e4dafdb8d08d83e35c6ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637327747982273214&sdata=%2FTz7d6sQ2Hx8MGSGgUv5eKLxgCxtKEIdSJA2EYX3pHE%3D&reserved=0 > > Testing: Linux-AArch64, fastdebug, test/hotspot/jtreg/compiler/intrinsics/sha/ test/hotspot/jtreg:tier1 test/jdk:tier1 > > This patch implements the MD5 intrinsic on AArch64 following its implementation on x86 [1]. The performance improvements are the following (on Linux-AArch64 on a Marvell TX2): > > -XX:-UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 1616.238 ? 28.082 ops/ms > MessageDigests.digest md5 1024 DEFAULT thrpt 10 215.030 ? 0.691 ops/ms > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.228 ? 0.001 ops/ms > > -XX:+UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 2005.233 ? 40.513 ops/ms => 24% speedup > MessageDigests.digest md5 1024 DEFAULT thrpt 10 275.979 ? 0.455 ops/ms => 28% speedup > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.279 ? 0.001 ops/ms => 22% speedup > > Thank you, > Ludovic > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam06.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fbugs.openjdk.java.net*2Fbrowse*2FJDK-8250902%26amp%3Bdata%3D02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034%26amp%3Bsdata%3D5KcoG5n10rnVMU9y8L076jpCoEd0NBzNqr*2F8M5ghO3c*3D%26amp%3Breserved%3D0__%3BJSUlJSUlJSUlJSUlJSUl!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E6SPJBTN%24&data=02%7C01%7Cbeurba%40microsoft.com%7C4604acd9be3e4dafdb8d08d83e35c6ae%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637327747982273214&sdata=8kQJdfsUCcdDq%2BS3UA0vWV2QADQGhGSEsZFiXZK0e%2Bw%3D&reserved=0 > From aph at redhat.com Wed Aug 12 09:47:50 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 12 Aug 2020 10:47:50 +0100 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 In-Reply-To: References: <9074F4C9-589A-4519-BBAB-2F3161B814D7@oracle.com> Message-ID: On 8/10/20 2:38 PM, Doug Simon wrote: > I don?t think we do that anywhere currently but I imagine it > wouldn?t be hard to put the BytecodeParser into a mode whereby an > array access generates a AccessIndexedNode that omits the bounds > check (generated by > org.graalvm.compiler.replacements.DefaultJavaLoweringProvider.getBoundsCheck). We could do that in C2 as well. And it'd be far more attractive than hand-coded intrinsics. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Thu Aug 13 08:06:13 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 13 Aug 2020 09:06:13 +0100 Subject: [aarch64-port-dev ] RFR: 8247354: [aarch64] PopFrame causes assert(oopDesc::is_oop(obj)) failed: not an oop In-Reply-To: <85364ykery.fsf@nicgas01-pc.shanghai.arm.com> References: <85364ykery.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <10b37c70-c522-7f65-3c7e-bbeeaf7e1c3d@redhat.com> Hi Nick, On 07/08/2020 10:04, Nick Gasson wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8247354 > Webrev: http://cr.openjdk.java.net/~ngasson/8247354/webrev.0/ Nice detective work. The patch looks ok to me. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Thu Aug 13 08:36:13 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 13 Aug 2020 09:36:13 +0100 Subject: [aarch64-port-dev ] RFR(XS) 8248816: C1: Fix signature conflict in LIRGenerator::strength_reduce_multiply In-Reply-To: References: Message-ID: On 06/08/2020 16:13, Bernhard Urban-Forster wrote: > can someone sponsor this change please? > > Webrev: http://cr.openjdk.java.net/~burban/8248816/ I have pushed this change. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From dmitry.chuyko at bell-sw.com Thu Aug 13 11:04:37 2020 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 13 Aug 2020 14:04:37 +0300 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) Message-ID: Hello, Please review a faster version of Math.signum() for AArch64. Two new intrinsics (double and float) are introduced in general code, with appropriate new nodes. New JTreg test is added to cover the intrinsic case (enabled only for aarch64). AArch64 implementation uses FACGT (compare abslute fp values) and BSL (fp bit selection) to avoid branches and moves to non-fp registers and back. Performance results show ~30% better time in the benchmark with a black hole [1] on Cortex. E.g. on random numbers 4.8 ns/op --> 3.5 ns/op, overhead is 2.9 ns/op. rfe: https://bugs.openjdk.java.net/browse/JDK-8251525 webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.00/ testing: jck, jtreg including new dedicated test -Dmitry [1] https://cr.openjdk.java.net/~dchuyko/8249198/DoubleSignum.java From vladimir.x.ivanov at oracle.com Thu Aug 13 11:51:59 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 13 Aug 2020 14:51:59 +0300 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: References: Message-ID: Hi Dmitry, Some comments on shared code changes: src/hotspot/share/opto/library_call.cpp: + case vmIntrinsics::_dsignum: + return UseSignumIntrinsic && (Matcher::match_rule_supported(Op_SignumD) ? inline_double_math(id) : false); There's no need in repeating UseSignumIntrinsic and (Matcher::match_rule_supported(Op_SignumD) checks. C2Compiler::is_intrinsic_supported() already covers taht. src/hotspot/share/opto/signum.hpp: 32 class SignumNode : public Node { 33 public: 34 SignumNode(Node* in) : Node(0, in) {} 35 virtual int Opcode() const; 36 virtual const Type *bottom_type() const { return NULL; } 37 virtual uint ideal_reg() const { return Op_RegD; } 38 }; Any particular reason to keep SignumNode? I don't see any and would just drop it. Also, having a dedicated header file just for a couple of nodes with trivial implementations looks like an overkill. As an alternative location, intrinsicnode.cpp should be a better option. Best regards, Vladimir Ivanov On 13.08.2020 14:04, Dmitry Chuyko wrote: > Hello, > > Please review a faster version of Math.signum() for AArch64. > > Two new intrinsics (double and float) are introduced in general code, > with appropriate new nodes. New JTreg test is added to cover the > intrinsic case (enabled only for aarch64). > > AArch64 implementation uses FACGT (compare abslute fp values) and BSL > (fp bit selection) to avoid branches and moves to non-fp registers and > back. > > Performance results show ~30% better time in the benchmark with a black > hole [1] on Cortex. E.g. on random numbers 4.8 ns/op --> 3.5 ns/op, > overhead is 2.9 ns/op. > > rfe: https://bugs.openjdk.java.net/browse/JDK-8251525 > webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.00/ > testing: jck, jtreg including new dedicated test > > -Dmitry > > [1] https://cr.openjdk.java.net/~dchuyko/8249198/DoubleSignum.java > From akozlov at azul.com Thu Aug 13 13:03:53 2020 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 13 Aug 2020 16:03:53 +0300 Subject: [aarch64-port-dev ] Collaboration proposal: Draft JEP MacOS/AArch64 Port In-Reply-To: References: Message-ID: <8c9621f4-54cc-17a7-f84b-fc47387a15e0@azul.com> Hello Monica, Thank you for your proposal. It was a bit unexpected :) We would be happy to collaborate! Our mac/aarch64 port is in the R&D phase. At some point, maybe we (OpenJDK community) will need a project or repo for integration. But having win/aarch64 integrated, it may happen that mac/aarch64 support will be just a series of considerably isolated changes. An example is "JDK-8250876: Fix issues with cross-compile on macos" [1]. If all changes will be such self-containing, they may be reviewed and integrated one-by-one. Probably we won't need a project. I think this work is blocked by the JEP for the new platform support. I'll start a discussion email thread for that really soon. I hope we would be able to collaborate in all of the areas. I expect us to get soon to the point when we can start reviewing changes made for win/aarch64 and evaluate how do they fit mac/aarch64. Thanks, Anton [1] https://bugs.openjdk.java.net/browse/JDK-8250876 On 11.08.2020 21:15, Monica Beckwith wrote: > Hello everyone,? > > It gives me immense pleasure to see the draft JEP?for?'MacOS/AArch64 Port'?[1].?At Microsoft, we are in the?process of expanding our CI infrastructure by adding Apple?DevKits?[2]. We are?entirely?in support?of you and your?team, @Anton Kozlov.?You all bring your immense?knowledge from?the?AArch32 port,?and we welcome?you?and would like to extend our?collaboration?on?the MacOS?port.?More specifically,?we would like to work with you?on?the?-?? > > . Implementation (low-level code additions, shared code modifications and?maintenance, adhering to?HotSpot?coding style/conventions [3], etc.)?? > . Testing (all?regression,?functional, integration?and performance?tests)? > . Integration to?jdk/jdk?(tip)? > > Since the?MacOS?port?work depends on the?Windows port modifications, I?propose a?collaboration (sub-)Project [4]?repo where we?can?jointly?work in the open.? > > If it is OK with you and your team, next week,?I can propose the creation of?a new (sub-)Project?for?'jdk-mac'?and send it out to?mailto:discuss at openjdk.java.net and mailto:aarch64-port-dev at openjdk.java.net. Once we have a sponsor,?we can?send the?info out on?mailto:announce at openjdk.java.net. > > We can work?on?the details of these offline.?Please let me know if you have already?made traction on the (sub-)Project front,?and we can jump?in and help?wherever?you are.? > > This?is?a?wonderful?opportunity?for?OpenJDK,?and?the?team?here?at?Microsoft?is excited about?the?prospects, and we are?looking?forward?to?working?with?your?team.? > > Thanks,? > Monica > > [1] http://openjdk.java.net/jeps/8251280 > [2] https://developer.apple.com/programs/universal/ > [3] https://wiki.openjdk.java.net/display/HotSpot/StyleGuide > [4] http://openjdk.java.net/projects/#new-project > From aph at redhat.com Thu Aug 13 13:07:38 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 13 Aug 2020 14:07:38 +0100 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: References: Message-ID: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> On 13/08/2020 12:04, Dmitry Chuyko wrote: > Performance results show ~30% better time in the benchmark with a black > hole [1] on Cortex. E.g. on random numbers 4.8 ns/op --> 3.5 ns/op, > overhead is 2.9 ns/op. > > rfe:https://bugs.openjdk.java.net/browse/JDK-8251525 > webrev:http://cr.openjdk.java.net/~dchuyko/8251525/webrev.00/ > testing: jck, jtreg including new dedicated test Please show all of the JMH results. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitry.chuyko at bell-sw.com Thu Aug 13 13:50:01 2020 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Thu, 13 Aug 2020 16:50:01 +0300 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> References: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> Message-ID: <790171f2-0499-21ed-899c-59fd788c34ba@bell-sw.com> Hi Andrew, On 8/13/20 4:07 PM, Andrew Haley wrote: > On 13/08/2020 12:04, Dmitry Chuyko wrote: >> Performance results show ~30% better time in the benchmark with a black >> hole [1] on Cortex. E.g. on random numbers 4.8 ns/op --> 3.5 ns/op, >> overhead is 2.9 ns/op. >> ...... > > Please show all of the JMH results. > Results for other sub-benchmarks are listed in the RFE, here is a copy: Baseline DoubleSignum.ofMostlyNaN 5.019 ? 0.060 ns/op DoubleSignum.ofMostlyNeg 4.919 ? 0.030 ns/op DoubleSignum.ofMostlyPos 4.827 ? 0.081 ns/op DoubleSignum.ofMostlyZero 4.936 ? 0.107 ns/op DoubleSignum.ofRandom 4.825 ? 0.026 ns/op DoubleSignum.overhead 2.846 ? 0.027 ns/op Patch DoubleSignum.ofMostlyNaN 3.478 ? 0.368 ns/op DoubleSignum.ofMostlyNeg 3.509 ? 0.487 ns/op DoubleSignum.ofMostlyPos 3.513 ? 0.451 ns/op DoubleSignum.ofMostlyZero 3.494 ? 0.220 ns/op DoubleSignum.ofRandom 3.506 ? 0.343 ns/op DoubleSignum.overhead 2.848 ? 0.019 ns/op -Dmitry From akozlov at azul.com Thu Aug 13 14:47:55 2020 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 13 Aug 2020 17:47:55 +0300 Subject: [aarch64-port-dev ] RFC: JEP draft JDK-8251280: macOS/AArch64 Port Message-ID: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> Hello, Could you please look at and comment on a draft of JEP for macOS/AArch64 port[1]? Usually, platform JEPs serve for integration rather than development. According to current understanding, mac/aarch64 is an incremental extension to both mac/x86 and linux-windows/aarch64. It is not expected that a considerable rework will be required to implement mac/aarch64. The JEP initiates a discussion about mac/aarch64 as a supported platform also to enable a certain workflow. If the mac/aarch64 platform would be accepted, changes toward its support will be unblocked for review, testing, and integration. For example, it was possible to isolate build system changes[2] from the rest. Another example would be a solution to the W^X problem, parts of which may be useful for OpenJDK in hardened runtime[3] configuration on mac/x86 (the one which will use MAP_JIT mmap() flag). Gradual changes integration is hoped to reduce overall overhead for reviewers and enable more parties to contribute. I find these goals desirable (at the expense of some overhead for contributors), but the community may have more opinions. I hope that the JEP draft covers all the important topics. If something is missing or wrong, please let me know. Thanks, Anton [1] https://bugs.openjdk.java.net/browse/JDK-8251280 [2] https://bugs.openjdk.java.net/browse/JDK-8250876 [3] https://developer.apple.com/documentation/security/hardened_runtime From gnu.andrew at redhat.com Thu Aug 13 19:07:10 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 13 Aug 2020 20:07:10 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b02 Upstream Sync Message-ID: <20200813190710.GA2495896@stopbrexit> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/root/merge.changeset Changes in aarch64-shenandoah-jdk8u272-b02: - JDK-8023697: failed class resolution reports different class name in detail message for the first and subsequent times - JDK-8025886: replace [[ and == bash extensions in regtest - JDK-8046274: Removing dependency on jakarta-regexp - JDK-8048933: -XX:+TraceExceptions output should include the message - JDK-8076151: [TESTBUG] Test java/awt/FontClass/CreateFont/fileaccess/FontFile.java fails - JDK-8148854: Class names "SomeClass" and "LSomeClass;" treated by JVM as an equivalent - JDK-8154313: Generated javadoc scattered all over the place - JDK-8161072: AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure - JDK-8163251: Hard coded loop limit prevents reading of smart card data greater than 8k - JDK-8171537: aarch64: compiler/c1/Test6849574.java generates guarantee failure in C1 - JDK-8173300: [TESTBUG]compiler/tiered/NonTieredLevelsTest.java fails with compiler.whitebox.SimpleTestCaseHelper(int) must be compiled - JDK-8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java - JDK-8191678: [TESTBUG] Add keyword headful in java/awt FocusTransitionTest test. - JDK-8201633: Problems with AES-GCM native acceleration - JDK-8211049: Second parameter of "initialize" method is not used - JDK-8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero - JDK-8220165: Encryption using GCM results in RuntimeException- input length out of bound - JDK-8220555: JFR tool shows potentially misleading message when it cannot access a file - JDK-8221658: aarch64: add necessary predicate for ubfx patterns - JDK-8224217: RecordingInfo should use textual representation of path - JDK-8231779: crash HeapWord*ParallelScavengeHeap::failed_mem_allocate - JDK-8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 - JDK-8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 - JDK-8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 - JDK-8242556: Cannot load RSASSA-PSS public key with non-null params from byte array - JDK-8250755: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java Main issues of note: None, clean merge. diffstat for root b/.hgtags | 2 ++ b/THIRD_PARTY_README | 1 - b/make/Javadoc.gmk | 38 +++++++++++++++++++++++++++++++++++++- b/make/Main.gmk | 14 +++++++++++--- 4 files changed, 50 insertions(+), 5 deletions(-) diffstat for corba b/.hgtags | 2 ++ b/THIRD_PARTY_README | 1 - 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for jaxp a/src/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java | 76 a/src/com/sun/org/apache/regexp/internal/CharacterIterator.java | 42 a/src/com/sun/org/apache/regexp/internal/RE.java | 1760 ---------- a/src/com/sun/org/apache/regexp/internal/RECompiler.java | 1520 -------- a/src/com/sun/org/apache/regexp/internal/REDebugCompiler.java | 225 - a/src/com/sun/org/apache/regexp/internal/REProgram.java | 158 a/src/com/sun/org/apache/regexp/internal/RESyntaxException.java | 43 a/src/com/sun/org/apache/regexp/internal/RETest.java | 883 ----- a/src/com/sun/org/apache/regexp/internal/REUtil.java | 61 a/src/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java | 164 a/src/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java | 161 a/src/com/sun/org/apache/regexp/internal/StringCharacterIterator.java | 62 a/src/com/sun/org/apache/regexp/internal/recompile.java | 137 b/.hgtags | 2 b/THIRD_PARTY_README | 1 b/src/com/sun/org/apache/bcel/internal/util/InstructionFinder.java | 97 16 files changed, 30 insertions(+), 5362 deletions(-) diffstat for jaxws b/.hgtags | 2 ++ b/THIRD_PARTY_README | 1 - 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for langtools b/.hgtags | 2 ++ b/THIRD_PARTY_README | 1 - 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for nashorn b/.hgtags | 2 ++ b/THIRD_PARTY_README | 1 - 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for jdk b/.hgtags | 2 b/THIRD_PARTY_README | 1 b/src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java | 66 ++ b/src/share/classes/jdk/jfr/internal/PlatformRecorder.java | 4 b/src/share/classes/jdk/jfr/internal/PlatformRecording.java | 4 b/src/share/classes/jdk/jfr/internal/WriteableUserPath.java | 22 b/src/share/classes/jdk/jfr/internal/management/ManagementSupport.java | 12 b/src/share/classes/jdk/jfr/internal/tool/Command.java | 4 b/src/share/classes/jdk/management/jfr/RecordingInfo.java | 5 b/src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java | 2 b/src/share/classes/sun/security/smartcardio/ChannelImpl.java | 8 b/src/share/classes/sun/security/x509/AlgorithmId.java | 4 b/src/solaris/native/java/lang/childproc.c | 3 b/src/solaris/native/java/lang/childproc.h | 4 b/src/solaris/native/sun/nio/ch/sctp/Sctp.h | 14 b/src/solaris/native/sun/nio/ch/sctp/SctpNet.c | 9 b/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c | 5 b/src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h | 4 b/test/com/sun/crypto/provider/Cipher/AEAD/GCMLargeDataKAT.java | 228 ++++++++++ b/test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java | 4 b/test/java/awt/FontClass/CreateFont/fileaccess/FontFile.java | 27 + b/test/java/awt/FontClass/CreateFont/fileaccess/TestFontFile.sh | 84 +++ b/test/javax/imageio/plugins/shared/CanWriteSequence.java | 55 +- b/test/javax/imageio/plugins/shared/WriteAfterAbort.java | 137 +++--- b/test/jdk/jfr/tool/TestPrint.java | 4 b/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh | 7 b/test/sun/security/rsa/TestKeyPairGeneratorInit.java | 60 ++ b/test/sun/security/rsa/pss/PSSParametersTest.java | 46 +- b/test/sun/security/rsa/pss/TestPSSKeySupport.java | 5 29 files changed, 667 insertions(+), 163 deletions(-) diffstat for hotspot b/.hgtags | 2 b/THIRD_PARTY_README | 1 b/src/share/vm/classfile/classFileParser.cpp | 12 b/src/share/vm/classfile/javaClasses.cpp | 10 b/src/share/vm/classfile/javaClasses.hpp | 1 b/src/share/vm/classfile/resolutionErrors.cpp | 23 + b/src/share/vm/classfile/resolutionErrors.hpp | 14 - b/src/share/vm/classfile/systemDictionary.cpp | 23 + b/src/share/vm/classfile/systemDictionary.hpp | 8 b/src/share/vm/classfile/verifier.cpp | 2 b/src/share/vm/classfile/verifier.hpp | 6 b/src/share/vm/interpreter/interpreterRuntime.cpp | 13 b/src/share/vm/jfr/periodic/sampling/jfrCallTrace.cpp | 5 b/src/share/vm/jfr/recorder/service/jfrOptionSet.cpp | 7 b/src/share/vm/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp | 4 b/src/share/vm/jfr/utilities/jfrTypes.hpp | 3 b/src/share/vm/memory/threadLocalAllocBuffer.cpp | 8 b/src/share/vm/oops/constantPool.cpp | 127 ++++----- b/src/share/vm/oops/constantPool.hpp | 6 b/src/share/vm/runtime/reflection.cpp | 2 b/src/share/vm/utilities/constantTag.cpp | 14 + b/src/share/vm/utilities/constantTag.hpp | 3 b/test/compiler/tiered/NonTieredLevelsTest.java | 3 b/test/runtime/ClassFile/BadHelloWorld.jcod | 138 ++++++++++ b/test/runtime/ClassFile/FormatCheckingTest.java | 43 +++ b/test/runtime/ClassResolutionFail/Property.java | 27 + b/test/runtime/ClassResolutionFail/PropertySuper.java | 28 ++ b/test/runtime/ClassResolutionFail/TestClassResolutionFail.java | 57 ++++ b/test/runtime/CommandLine/TraceExceptionsTest.java | 48 +++ 29 files changed, 531 insertions(+), 107 deletions(-) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From nick.gasson at arm.com Fri Aug 14 02:26:11 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 14 Aug 2020 10:26:11 +0800 Subject: [aarch64-port-dev ] RFR: 8247354: [aarch64] PopFrame causes assert(oopDesc::is_oop(obj)) failed: not an oop In-Reply-To: <10b37c70-c522-7f65-3c7e-bbeeaf7e1c3d@redhat.com> References: <85364ykery.fsf@nicgas01-pc.shanghai.arm.com> <10b37c70-c522-7f65-3c7e-bbeeaf7e1c3d@redhat.com> Message-ID: <85k0y2q7y4.fsf@nicgas01-pc.shanghai.arm.com> On 08/13/20 16:06 pm, Andrew Dinn wrote: > Hi Nick, > > On 07/08/2020 10:04, Nick Gasson wrote: >> Bug: https://bugs.openjdk.java.net/browse/JDK-8247354 >> Webrev: http://cr.openjdk.java.net/~ngasson/8247354/webrev.0/ > Nice detective work. The patch looks ok to me. > Thanks for the review Andrew. I've pushed it. -- Nick From dmitry.chuyko at bell-sw.com Fri Aug 14 17:14:54 2020 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Fri, 14 Aug 2020 20:14:54 +0300 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: References: Message-ID: <220c8f3d-3443-4c4d-bf42-078bec651335@bell-sw.com> Hi Vladimir, Thank you for the comments. Here is a version with simplified node definitions: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.01/ -Dmitry On 8/13/20 2:51 PM, Vladimir Ivanov wrote: > Hi Dmitry, > > Some comments on shared code changes: > > src/hotspot/share/opto/library_call.cpp: > > +? case vmIntrinsics::_dsignum: > +??? return UseSignumIntrinsic && > (Matcher::match_rule_supported(Op_SignumD) ? inline_double_math(id) : > false); > > There's no need in repeating UseSignumIntrinsic and > (Matcher::match_rule_supported(Op_SignumD) checks. > C2Compiler::is_intrinsic_supported() already covers taht. > > > src/hotspot/share/opto/signum.hpp: > > ? 32 class SignumNode : public Node { > ? 33 public: > ? 34?? SignumNode(Node* in) : Node(0, in) {} > ? 35?? virtual int Opcode() const; > ? 36?? virtual const Type *bottom_type() const { return NULL; } > ? 37?? virtual uint ideal_reg() const { return Op_RegD; } > ? 38 }; > > Any particular reason to keep SignumNode? I don't see any and would > just drop it. > > Also, having a dedicated header file just for a couple of nodes with > trivial implementations looks like an overkill. As an alternative > location, intrinsicnode.cpp should be a better option. > > Best regards, > Vladimir Ivanov > > On 13.08.2020 14:04, Dmitry Chuyko wrote: >> Hello, >> >> Please review a faster version of Math.signum() for AArch64. >> >> Two new intrinsics (double and float) are introduced in general code, >> with appropriate new nodes. New JTreg test is added to cover the >> intrinsic case (enabled only for aarch64). >> >> AArch64 implementation uses FACGT (compare abslute fp values) and BSL >> (fp bit selection) to avoid branches and moves to non-fp registers >> and back. >> >> Performance results show ~30% better time in the benchmark with a >> black hole [1] on Cortex. E.g. on random numbers 4.8 ns/op --> 3.5 >> ns/op, overhead is 2.9 ns/op. >> >> rfe: https://bugs.openjdk.java.net/browse/JDK-8251525 >> webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.00/ >> testing: jck, jtreg including new dedicated test >> >> -Dmitry >> >> [1] https://cr.openjdk.java.net/~dchuyko/8249198/DoubleSignum.java >> From vladimir.x.ivanov at oracle.com Fri Aug 14 18:53:04 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 14 Aug 2020 21:53:04 +0300 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: <220c8f3d-3443-4c4d-bf42-078bec651335@bell-sw.com> References: <220c8f3d-3443-4c4d-bf42-078bec651335@bell-sw.com> Message-ID: <3d8f2ce2-d106-6cb6-ffb8-861905d8f49e@oracle.com> > http://cr.openjdk.java.net/~dchuyko/8251525/webrev.01/ Changes in shared code look good. Best regards, Vladimir Ivanov > On 8/13/20 2:51 PM, Vladimir Ivanov wrote: >> Hi Dmitry, >> >> Some comments on shared code changes: >> >> src/hotspot/share/opto/library_call.cpp: >> >> +? case vmIntrinsics::_dsignum: >> +??? return UseSignumIntrinsic && >> (Matcher::match_rule_supported(Op_SignumD) ? inline_double_math(id) : >> false); >> >> There's no need in repeating UseSignumIntrinsic and >> (Matcher::match_rule_supported(Op_SignumD) checks. >> C2Compiler::is_intrinsic_supported() already covers taht. >> >> >> src/hotspot/share/opto/signum.hpp: >> >> ? 32 class SignumNode : public Node { >> ? 33 public: >> ? 34?? SignumNode(Node* in) : Node(0, in) {} >> ? 35?? virtual int Opcode() const; >> ? 36?? virtual const Type *bottom_type() const { return NULL; } >> ? 37?? virtual uint ideal_reg() const { return Op_RegD; } >> ? 38 }; >> >> Any particular reason to keep SignumNode? I don't see any and would >> just drop it. >> >> Also, having a dedicated header file just for a couple of nodes with >> trivial implementations looks like an overkill. As an alternative >> location, intrinsicnode.cpp should be a better option. >> >> Best regards, >> Vladimir Ivanov >> >> On 13.08.2020 14:04, Dmitry Chuyko wrote: >>> Hello, >>> >>> Please review a faster version of Math.signum() for AArch64. >>> >>> Two new intrinsics (double and float) are introduced in general code, >>> with appropriate new nodes. New JTreg test is added to cover the >>> intrinsic case (enabled only for aarch64). >>> >>> AArch64 implementation uses FACGT (compare abslute fp values) and BSL >>> (fp bit selection) to avoid branches and moves to non-fp registers >>> and back. >>> >>> Performance results show ~30% better time in the benchmark with a >>> black hole [1] on Cortex. E.g. on random numbers 4.8 ns/op --> 3.5 >>> ns/op, overhead is 2.9 ns/op. >>> >>> rfe: https://bugs.openjdk.java.net/browse/JDK-8251525 >>> webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.00/ >>> testing: jck, jtreg including new dedicated test >>> >>> -Dmitry >>> >>> [1] https://cr.openjdk.java.net/~dchuyko/8249198/DoubleSignum.java >>> From aph at redhat.com Sat Aug 15 13:50:42 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 15 Aug 2020 14:50:42 +0100 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> References: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> Message-ID: <67e67230-cac7-d940-1cca-6ab4e8cba8d4@redhat.com> I've been looking at the way Math.signum() is used, mostly by searching the GitHub code database. I've changed the JMH test to be IMO more realistic: it's at http://cr.openjdk.java.net/~aph/DoubleSignum.java. I think it's more realitic because signum() results usually aren't stored but are used to feed other arithmetic ops, usually + or *. Baseline: Benchmark Mode Cnt Score Error Units DoubleSignum.ofMostlyNaN avgt 3 2.409 ? 0.051 ns/op DoubleSignum.ofMostlyNeg avgt 3 2.475 ? 0.211 ns/op DoubleSignum.ofMostlyPos avgt 3 2.494 ? 0.015 ns/op DoubleSignum.ofMostlyZero avgt 3 2.501 ? 0.008 ns/op DoubleSignum.ofRandom avgt 3 2.458 ? 0.373 ns/op DoubleSignum.overhead avgt 3 2.373 ? 0.029 ns/op -XX:+UseSignumIntrinsic: Benchmark Mode Cnt Score Error Units DoubleSignum.ofMostlyNaN avgt 3 2.776 ? 0.006 ns/op DoubleSignum.ofMostlyNeg avgt 3 2.773 ? 0.066 ns/op DoubleSignum.ofMostlyPos avgt 3 2.772 ? 0.084 ns/op DoubleSignum.ofMostlyZero avgt 3 2.770 ? 0.045 ns/op DoubleSignum.ofRandom avgt 3 2.769 ? 0.005 ns/op DoubleSignum.overhead avgt 3 2.376 ? 0.013 ns/op I think it might be more useful for you to work on optimizing Math.copysign(). -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Mon Aug 17 02:07:26 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 17 Aug 2020 02:07:26 +0000 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> Message-ID: P.S., I witnessed some random assembler warnings when executing aarch64-asmtest.py script. $ python ./src/hotspot/cpu/aarch64/aarch64-asmtest.py | grep Warning aarch64ops.s: Assembler messages: aarch64ops.s:424: Warning: unpredictable load of register pair -- `ldpsw x10,x10,[x9,#-32]' aarch64ops.s:428: Warning: unpredictable transfer with writeback -- `stp w30,w12,[x30,#-256]!' aarch64ops.s:435: Warning: unpredictable transfer with writeback -- `ldp w4,w23,[x4],#-112' aarch64ops.s:221: Warning: unpredictable transfer with writeback -- `str x6,[x6,11]!' aarch64ops.s:223: Warning: unpredictable transfer with writeback -- `strb w0,[x0,-8]!' I think we should avoid this kind of noise. This could be fixed by the following fix: diff -r ff84f0491003 src/hotspot/cpu/aarch64/aarch64-asmtest.py --- a/src/hotspot/cpu/aarch64/aarch64-asmtest.py Sat Aug 15 18:13:49 2020 -0700 +++ b/src/hotspot/cpu/aarch64/aarch64-asmtest.py Mon Aug 17 09:40:12 2020 +0800 @@ -741,6 +741,11 @@ regMode = FloatRegister if isFloat else GeneralRegister self.reg = regMode().generate() + + kindStr = Address.kindToStr(self.kind); + if (not isFloat) and (kindStr is "pre" or kindStr is "post"): + (self.reg.number, self.adr.base.number) = random.sample(range(31), 2) + return self def cstr(self): @@ -777,6 +782,16 @@ self.reg = [OperandFactory.create(self.mode).generate() for i in range(self.numRegs)] self.base = OperandFactory.create('x').generate() + + kindStr = Address.kindToStr(self.kind); + if kindStr is "pre" or kindStr is "post": + if self._name.startswith("ld"): + (self.reg[0].number, self.reg[1].number, self.base.number) = random.sample(range(31), 3) + if self._name.startswith("st"): + self.base.number = random.choice(list(set(range(31)) - set([self.reg[0].number, self.reg[1].number]))) + elif self._name.startswith("ld"): + (self.reg[0].number, self.reg[1].number) = random.sample(range(31), 2) + return self def astr(self): > -----Original Message----- > From: Yangfei (Felix) > Sent: Friday, August 7, 2020 2:20 PM > To: 'Andrew Haley' ; hotspot-runtime- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: RE: RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic > > Hi, > > > -----Original Message----- > > From: Andrew Haley [mailto:aph at redhat.com] > > Sent: Thursday, August 6, 2020 7:42 PM > > To: Yangfei (Felix) ; hotspot-runtime- > > dev at openjdk.java.net > > Cc: aarch64-port-dev at openjdk.java.net > > Subject: Re: RFR: 8165404: AArch64: Implement SHA512 > > accelerator/intrinsic > > > > On 8/6/20 2:13 AM, Yangfei (Felix) wrote: > > > I have added tests for sha512 crypto instructions in this script and > > regenerated the code. > > > Tier1-3 tested with an aarch64 fastdebug build on my aarch64 linux > > > host to > > cover this part. > > > Updated webrev: > http://cr.openjdk.java.net/~fyang/8165404/webrev.02/ > > > Is it OK? > > > > Yes, thanks. > > > > It's a bit annoying that the indentation seems to change so > > frequently. I'm wondering if perhaps some people have been running > > this on Windows, which has different tab sizes, but that seems very > > unlikely, given that this is a Linux port. But never mind, that's not your > problem. > > I see the output of the python script contains tabs which is not allowed by > jcheck. > So I guess it may depends on the way in which people substitute these tabs. > I used vim editor to do the replacement, which is simple. > Open the file which contains the script output and do: > > :set ts=8 > :set expandtab > :%retab! > > Looks like the indentation is more consistent this way. Hope that helps. > Pushed as: https://hg.openjdk.java.net/jdk/jdk/rev/09ad5b67a099 > > Thanks, > Felix From ningsheng.jian at arm.com Mon Aug 17 06:00:13 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 17 Aug 2020 14:00:13 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> Message-ID: <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> Hi Andrew, Thanks a lot for the review! Sorry for the late reply, as I was on vacation last week. And thanks to Pengfei and Joshua for helping clarifying some details in the patch. > > Testing: > > I was able to test this patch on a loaned Fujitsu FX700. I replicated > your results, passing tier1 tests and the jtreg compiler tests in > vectorization, codegen, c2/cr6340864 and loopopts. > Thanks for the testing. > I also eyeballed /some/ of the generated code to check that it looked > ok. I'd really like to be able to do that systematically for a > comprehensive test suite that exercised every rule but I only had the > machine for a few days. This really ought to be done as a follow-up to > ensure that all the rules are working as expected. > > Yes, we would expect Pengfei's OptoAssembly check patch can get merged in future. > > General Comments: > > Sizing the NEON registers using 8 slots -- even though there might > actually be more (or less!) slots in use for a VecA is fine. However, I > think this needs a little bit more explanation in the .ad. file (see > comments on ra webrev below) > OK, I will try to have some more clear comments in ad file. > I'm ok with your choice to use p7 as an always true predicate register > and also how you choose to init and re-init from code defined via the ad > file based on C->max_vector_size(). > > I am not clear why you are choosing to re-init ptrue after certain JVM > runtime calls (e.g. when Z calls into the runtime) and not others e.g. > when we call a JVM_ENTRY. Could you explain the rationale you have > followed here? > > We do the re-init at any possible return points to c2 code, not in any runtime c++ functions, which will reduce the re-init calls. Actually I found those entries by some hack of jvm. In the hacky code below we use gcc option -finstrument-functions to build hotspot. With this option, each C/C++ function entry/exit will call the instrument functions we defined. In instrument functions, we clobber p7 (or other reg for test) register, and in c2 function return we verify that p7 (or other reg) has been reinitialized. http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Specific Comments (feature webrev): > > > globals_aarch64.hpp:102 > > Just out of interest why does UseSVE have range(0,2)? It seems you are > only testing for UseSVE > 0. Does value 2 correspond to an optional subset? > > Thanks to Pengfei's reply for this. :-) > > Specific Comments (register allocator webrev): > > > aarch64.ad:97-100 > > Why have you added a reg_def for R8 and R9 here and also to alloc_class > chunk0 at lines 544-545? They aren't used by C2 so why define them? > I think Pengfei has helped to explain that. I will either add clear comments or rename the register name as you suggested. > > assembler_aarch64.hpp:280 (also 699) > > prf sets a predicate register field. pgrf sets a governing predicate > register field. Should the name not be gprf. > Thanks to Pengfei's comment. > > chaitin.cpp:648-660 > > The comment is rather oddly formatted. > Thanks! > At line 650 you guard the assert with a test for lrg._is_vector. Is that > not always going to be guaranteed by the outer condition > lrg._is_scalable? If so then you should really assert lrg._is_vector. > > The special case code for computation of num_regs for a vector stack > slot also appears in this file with a slightly different organization in > find_first_set (line 1350) and in PhaseChaitin::Select (line 1590). > There is another similar case in RegMask::num_registers at regmask.cpp: > 98. It would be better to factor out the common code into methods of > LRG. Maybe using the following? > > bool LRG::is_scalable_vector() { > if (_is_scalable) { > assert(_is_vector == 1); > assert(_num_regs == == RegMask::SlotsPerVecA) > return true; > } > return false; > } > > int LRG::scalable_num_regs() { > assert(is_scalable_vector()); > if (OptoReg::is_stack(_reg)) { > return _scalable_reg_slots > } else { > return num_reg_slots; > } > } > > > chaitin.cpp:1350 > > Once again the test for lrg._is_vector should be guaranteed by the outer > test of lrg._is_scalable. Refactoring using the common methods of LRG as > above ought to help. > > chaitin.cpp:1591 > > Use common method code. > > > postaloc.cpp:308/323 > > Once again you should be able to use common method code of LRG here. > > > regmask.cpp:91 > > Once again you should be able to use common method code of LRG here. > As Joshua clarified, we are also working on predicate scalable reg, which is not in this patch. Thanks for the suggestion, I will try to refactor this a bit. > Specific Comments (c2 webrev): > > > aarch64.ad:3815 > > very nice defensive check! > > > assembler_aarch64.hpp:2469 & 2699+ > > Andrew Haley is definitely going to ask you to update function entry > (assembler_aarch64.cpp:76) to call these new instruction generation > methods and then validate the generated code using asm_check So, I guess > you might as well do that now ;-) > > Yes! :-) Will add the test code. Thanks! > zBarrierSetAssembler_aarch64.cpp:434 > > Can you explain why we need to check p7 here and not do so in other > places where we call into the JVM? I'm not saying this is wrong. I just > want to know how you decided where re-init of p7 was needed. > Actually I found this by my hack patch above while running jtreg tests. The stub slowpath here can be a c++ function. > superword.cpp:97 > > Does this mean that is someone sets the maximum vector size to a > non-power of two, such as 384, all superword operations will be > bypassed? Including those which can be done using NEON vectors? > Current SLP vectorizer only supports power-of-2 vector size. We are trying to work out a new vectorizer to support all SVE vector sizes, so we would expect a size like 384 could go to that path. I tried current patch on a 512-bit SVE hardware which does not support 384-bit: $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) openjdk version "16-internal" 2021-03-16 $ java -XX:MaxVectorSize=48 -version OpenJDK 64-Bit Server VM warning: Current system only supports max SVE vector length 32. Set MaxVectorSize to 32 (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 instead of unsupported 48: https://www.kernel.org/doc/Documentation/arm64/sve.txt) Do you think we need to exit vm instead of warning and fallbacking to 32 here? Thanks, Ningsheng From felix.yang at huawei.com Mon Aug 17 07:35:20 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 17 Aug 2020 07:35:20 +0000 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8203699: java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 Message-ID: Hi, Original Bug: https://bugs.openjdk.java.net/browse/JDK-8203699 Original patch: http://hg.openjdk.java.net/jdk/jdk/rev/cc2b36619704 This bug can be reproduced with 8u aarch64 fastdebug build by running this test: http://cr.openjdk.java.net/~fyang/8203699-8u/TestDefenderMethodLookup.java $./jtreg/bin/jtreg -othervm hotspot/test/TestDefenderMethodLookup.java Webrev for 8u-aarch64: http://cr.openjdk.java.net/~fyang/8203699-8u/webrev.00/ Performed full jtreg test with 8u aarch64 fastdebug & release build. OK to backport? Thanks, Felix From aph at redhat.com Mon Aug 17 08:29:33 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Aug 2020 09:29:33 +0100 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8203699: java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 In-Reply-To: References: Message-ID: <600a5d5f-9506-f72a-b1c5-9bb60d632edf@redhat.com> On 17/08/2020 08:35, Yangfei (Felix) wrote: > Webrev for 8u-aarch64: http://cr.openjdk.java.net/~fyang/8203699-8u/webrev.00/ > > Performed full jtreg test with 8u aarch64 fastdebug & release build. OK to backport? Great, thanks for catching this. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Aug 17 08:32:41 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Aug 2020 09:32:41 +0100 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> Message-ID: <9e733fb0-5916-2342-7962-ee1ec2f6f076@redhat.com> On 17/08/2020 03:07, Yangfei (Felix) wrote: > P.S., I witnessed some random assembler warnings when executing aarch64-asmtest.py script. > > $ python ./src/hotspot/cpu/aarch64/aarch64-asmtest.py | grep Warning > aarch64ops.s: Assembler messages: > aarch64ops.s:424: Warning: unpredictable load of register pair -- `ldpsw x10,x10,[x9,#-32]' > aarch64ops.s:428: Warning: unpredictable transfer with writeback -- `stp w30,w12,[x30,#-256]!' > aarch64ops.s:435: Warning: unpredictable transfer with writeback -- `ldp w4,w23,[x4],#-112' > aarch64ops.s:221: Warning: unpredictable transfer with writeback -- `str x6,[x6,11]!' > aarch64ops.s:223: Warning: unpredictable transfer with writeback -- `strb w0,[x0,-8]!' > > I think we should avoid this kind of noise. This could be fixed by the following fix: Looks good. If I were editing the Python script I'd also add random.seed(0) so that the generated code doesn't change every time. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From adinn at redhat.com Mon Aug 17 08:52:56 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 17 Aug 2020 09:52:56 +0100 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: References: Message-ID: On 13/08/2020 12:04, Dmitry Chuyko wrote: > Please review a faster version of Math.signum() for AArch64. > > Two new intrinsics (double and float) are introduced in general code, > with appropriate new nodes. New JTreg test is added to cover the > intrinsic case (enabled only for aarch64). > > AArch64 implementation uses FACGT (compare abslute fp values) and BSL > (fp bit selection) to avoid branches and moves to non-fp registers and > back. > > Performance results show ~30% better time in the benchmark with a black > hole [1] on Cortex. E.g. on random numbers 4.8 ns/op --> 3.5 ns/op, > overhead is 2.9 ns/op. > > rfe: https://bugs.openjdk.java.net/browse/JDK-8251525 > webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.00/ > testing: jck, jtreg including new dedicated test The arrays float_cases and double_cases in that dedicated test (TestSignumIntrinsic) include some rather randomly picked float literals with either exponent or a large exponent. They do not include a denormal float literal (excluding the obvious corner cases Float/Double.MIN_VALUE). At least one sample value from the denormal range ought to be included even though (indeed, precisely because) it ought to be of no consequence for the algorithm being used. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Mon Aug 17 09:16:47 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 17 Aug 2020 10:16:47 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> Message-ID: <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Hi Pengfei, On 17/08/2020 07:00, Ningsheng Jian wrote: > Thanks a lot for the review! Sorry for the late reply, as I was on > vacation last week. And thanks to Pengfei and Joshua for helping > clarifying some details in the patch. Yes, they did a very good job of answering most of the pending questions. >> I also eyeballed /some/ of the generated code to check that it looked >> ok. I'd really like to be able to do that systematically for a >> comprehensive test suite that exercised every rule but I only had the >> machine for a few days. This really ought to be done as a follow-up to >> ensure that all the rules are working as expected. > > Yes, we would expect Pengfei's OptoAssembly check patch can get merged > in future. I'm fine with that as a follow-up patch if you raise a JIRA for it. >> I am not clear why you are choosing to re-init ptrue after certain JVM >> runtime calls (e.g. when Z calls into the runtime) and not others e.g. >> when we call a JVM_ENTRY. Could you explain the rationale you have >> followed here? > > We do the re-init at any possible return points to c2 code, not in any > runtime c++ functions, which will reduce the re-init calls. > > Actually I found those entries by some hack of jvm. In the hacky code > below we use gcc option -finstrument-functions to build hotspot. With > this option, each C/C++ function entry/exit will call the instrument > functions we defined. In instrument functions, we clobber p7 (or other > reg for test) register, and in c2 function return we verify that p7 (or > other reg) has been reinitialized. > > http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch Nice work. It's very good to have that documented. I'm willing to accept i) that this has found all current cases and ii) that the verify will catch any cases that might get introduced by future changes (e.g. the callout introduced by ZGC that you mention below). As the above mot say there is a slim chance this might have missed some cases but I think it is pretty unlikely. >> Specific Comments (register allocator webrev): >> >> >> aarch64.ad:97-100 >> >> Why have you added a reg_def for R8 and R9 here and also to alloc_class >> chunk0 at lines 544-545? They aren't used by C2 so why define them? >> > > I think Pengfei has helped to explain that. I will either add clear > comments or rename the register name as you suggested. Ok, good. > As Joshua clarified, we are also working on predicate scalable reg, > which is not in this patch. Thanks for the suggestion, I will try to > refactor this a bit. Ok, I'll wait for an updated patch. Are you planning to include the scalable predicate reg code as part of this patch? I think that would be better as it would help to clarify the need to distinguish vector regs as a subset of scalable regs. >> zBarrierSetAssembler_aarch64.cpp:434 >> >> Can you explain why we need to check p7 here and not do so in other >> places where we call into the JVM? I'm not saying this is wrong. I just >> want to know how you decided where re-init of p7 was needed. >> > > Actually I found this by my hack patch above while running jtreg tests. > The stub slowpath here can be a c++ function. Yes, good catch. >> superword.cpp:97 >> >> Does this mean that is someone sets the maximum vector size to a >> non-power of two, such as 384, all superword operations will be >> bypassed? Including those which can be done using NEON vectors? >> > > Current SLP vectorizer only supports power-of-2 vector size. We are > trying to work out a new vectorizer to support all SVE vector sizes, so > we would expect a size like 384 could go to that path. I tried current > patch on a 512-bit SVE hardware which does not support 384-bit: > > $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) > openjdk version "16-internal" 2021-03-16 > > $ java -XX:MaxVectorSize=48 -version > OpenJDK 64-Bit Server VM warning: Current system only supports max SVE > vector length 32. Set MaxVectorSize to 32 > > (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 > instead of unsupported 48: > https://www.kernel.org/doc/Documentation/arm64/sve.txt) > > Do you think we need to exit vm instead of warning and fallbacking to 32 > here? Yes, I think a vm exit would probably be a better choice. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From ningsheng.jian at arm.com Mon Aug 17 10:19:04 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 17 Aug 2020 18:19:04 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: <294d013f-e6d4-4eba-4455-78bd4cfd1148@arm.com> Hi Andrew, > >> As Joshua clarified, we are also working on predicate scalable reg, >> which is not in this patch. Thanks for the suggestion, I will try to >> refactor this a bit. > > Ok, I'll wait for an updated patch. Are you planning to include the > scalable predicate reg code as part of this patch? I think that would be > better as it would help to clarify the need to distinguish vector regs > as a subset of scalable regs. > My original plan was not to include scalable predicate reg related code, as they are not used and tested without proper mid-end/back-end code. Do you think just adding some comments is OK for now, e.g. saying that a scalable reg could also be a predicate reg in future? >> $ java -XX:MaxVectorSize=48 -version >> OpenJDK 64-Bit Server VM warning: Current system only supports max SVE >> vector length 32. Set MaxVectorSize to 32 >> >> (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 >> instead of unsupported 48: >> https://www.kernel.org/doc/Documentation/arm64/sve.txt) >> >> Do you think we need to exit vm instead of warning and fallbacking to 32 >> here? > > Yes, I think a vm exit would probably be a better choice. > OK, will do that. Thanks! Regards, Ningsheng From adinn at redhat.com Mon Aug 17 10:29:11 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 17 Aug 2020 11:29:11 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <294d013f-e6d4-4eba-4455-78bd4cfd1148@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <294d013f-e6d4-4eba-4455-78bd4cfd1148@arm.com> Message-ID: <9e045763-4a5d-57b5-18c9-63f8a6072c2e@redhat.com> On 17/08/2020 11:19, Ningsheng Jian wrote: >>> As Joshua clarified, we are also working on predicate scalable reg, >>> which is not in this patch. Thanks for the suggestion, I will try to >>> refactor this a bit. >> >> Ok, I'll wait for an updated patch. Are you planning to include the >> scalable predicate reg code as part of this patch? I think that would be >> better as it would help to clarify the need to distinguish vector regs >> as a subset of scalable regs. >> > > My original plan was not to include scalable predicate reg related code, > as they are not used and tested without proper mid-end/back-end code. Do > you think just adding some comments is OK for now, e.g. saying that a > scalable reg could also be a predicate reg in future? Sure. A comment describing the meaning of the scalable and vector properties and their independence from each other will be good enough for now and it will still be helpful once the extra code is added. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From felix.yang at huawei.com Mon Aug 17 12:01:45 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 17 Aug 2020 12:01:45 +0000 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: <9e733fb0-5916-2342-7962-ee1ec2f6f076@redhat.com> References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> <9e733fb0-5916-2342-7962-ee1ec2f6f076@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Monday, August 17, 2020 4:33 PM > To: Yangfei (Felix) ; hotspot-runtime- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic > > On 17/08/2020 03:07, Yangfei (Felix) wrote: > > P.S., I witnessed some random assembler warnings when executing > aarch64-asmtest.py script. > > > > $ python ./src/hotspot/cpu/aarch64/aarch64-asmtest.py | grep Warning > > aarch64ops.s: Assembler messages: > > aarch64ops.s:424: Warning: unpredictable load of register pair -- `ldpsw > x10,x10,[x9,#-32]' > > aarch64ops.s:428: Warning: unpredictable transfer with writeback -- `stp > w30,w12,[x30,#-256]!' > > aarch64ops.s:435: Warning: unpredictable transfer with writeback -- `ldp > w4,w23,[x4],#-112' > > aarch64ops.s:221: Warning: unpredictable transfer with writeback -- `str > x6,[x6,11]!' > > aarch64ops.s:223: Warning: unpredictable transfer with writeback -- `strb > w0,[x0,-8]!' > > > > I think we should avoid this kind of noise. This could be fixed by the > following fix: > > Looks good. If I were editing the Python script I'd also add > random.seed(0) so that the generated code doesn't change every time. Thanks for the quick reply. Do you mean we need any more change? For the purpose for testing the instructions, it might not be a good idea to add random.seed(0). This will limit the randomness of the register numbers used for each run. Best regards, Felix From aph at redhat.com Mon Aug 17 12:28:50 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Aug 2020 13:28:50 +0100 Subject: [aarch64-port-dev ] RFC: JEP draft JDK-8251280: macOS/AArch64 Port In-Reply-To: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> References: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> Message-ID: <0b74974b-923f-1aa2-4551-0e6661eec14c@redhat.com> On 13/08/2020 15:47, Anton Kozlov wrote: > Another example would be a solution to the W^X problem, parts of > which may be useful for OpenJDK in hardened runtime[3] configuration > on mac/x86 (the one which will use MAP_JIT mmap() flag). The JEP looks good to me. Re W^X: there are very few places where we now need runtime-patchable methods in the code cache. On AArch64, we deoptimize and recompile rather than patch in most cases. This is because the only instructions we're allowed to patch concurrently are direct jumps, traps, and nops. This leads to very little slowdown in practice because in a tiered- compilation-enabled JVM 90% of recompilations are due to tier escalation rather than patching needed, and most fields are resolved in the interpreter before C1 kicks in. The remaining places we patch today are nmethod::make_not_entrant_or_zombie and compiled inline caches for method calls. We can perhaps get rid of the first because we now have nmethod entry barriers, and Erik ?sterlund has been working on a replacement for inline caches. Finally, we would have to change the trampoline logic to go via a separate data table. I think that's it. Not that I'm suggesting you need this for Apple/ AArch64, but we're very close. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.osterlund at oracle.com Mon Aug 17 13:17:47 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 17 Aug 2020 15:17:47 +0200 Subject: [aarch64-port-dev ] RFC: JEP draft JDK-8251280: macOS/AArch64 Port In-Reply-To: <0b74974b-923f-1aa2-4551-0e6661eec14c@redhat.com> References: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> <0b74974b-923f-1aa2-4551-0e6661eec14c@redhat.com> Message-ID: <206dd7dd-eba1-669a-2fd5-e40c2802bf6e@oracle.com> Hi, On 2020-08-17 14:28, Andrew Haley wrote: > On 13/08/2020 15:47, Anton Kozlov wrote: > >> Another example would be a solution to the W^X problem, parts of >> which may be useful for OpenJDK in hardened runtime[3] configuration >> on mac/x86 (the one which will use MAP_JIT mmap() flag). > The JEP looks good to me. > > Re W^X: there are very few places where we now need runtime-patchable > methods in the code cache. > > On AArch64, we deoptimize and recompile rather than patch in most > cases. This is because the only instructions we're allowed to patch > concurrently are direct jumps, traps, and nops. > > This leads to very little slowdown in practice because in a tiered- > compilation-enabled JVM 90% of recompilations are due to tier > escalation rather than patching needed, and most fields are resolved > in the interpreter before C1 kicks in. > > The remaining places we patch today are > nmethod::make_not_entrant_or_zombie and compiled inline caches for > method calls. We can perhaps get rid of the first because we now have > nmethod entry barriers, and Erik ?sterlund has been working on a > replacement for inline caches. Right. The relevant JEP draft for these changes is here for interested readers: https://bugs.openjdk.java.net/browse/JDK-8221828 In my current implementation prototype, all the above code patching has indeed been removed. I still have the nmethod entry barriers, but as mentioned they do not patch anything on AArch64. Thanks, /Erik > Finally, we would have to change the trampoline logic to go via a > separate data table. > > I think that's it. Not that I'm suggesting you need this for Apple/ > AArch64, but we're very close. > From felix.yang at huawei.com Mon Aug 17 15:05:23 2020 From: felix.yang at huawei.com (felix.yang at huawei.com) Date: Mon, 17 Aug 2020 15:05:23 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8203699: java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 Message-ID: <202008171505.07HF5NHl024461@aojmv0008.oracle.com> Changeset: 7b0c9ad6dcbd Author: fyang Date: 2020-08-12 19:59 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7b0c9ad6dcbd 8203699: java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 Summary: fastdebug build fails with SIGILL Reviewed-by: shade, drwhite, aph ! src/cpu/aarch64/vm/macroAssembler_aarch64.cpp From aph at redhat.com Mon Aug 17 15:53:48 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 17 Aug 2020 16:53:48 +0100 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> <9e733fb0-5916-2342-7962-ee1ec2f6f076@redhat.com> Message-ID: <80b588a5-e07f-9d8e-1079-c14530570549@redhat.com> On 17/08/2020 13:01, Yangfei (Felix) wrote: >> Looks good. If I were editing the Python script I'd also add >> random.seed(0) so that the generated code doesn't change every time. > Thanks for the quick reply. Do you mean we need any more change? > For the purpose for testing the instructions, it might not be a good > idea to add random.seed(0). This will limit the randomness of the > register numbers used for each run. Not really, because we paste the output into assembler.cpp so that we use the same values every time it runs. I don't think it helps anyone that we use different random offsets every time the test code is regenerated. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From akozlov at azul.com Mon Aug 17 16:01:07 2020 From: akozlov at azul.com (Anton Kozlov) Date: Mon, 17 Aug 2020 19:01:07 +0300 Subject: [aarch64-port-dev ] RFC: JEP draft JDK-8251280: macOS/AArch64 Port In-Reply-To: <206dd7dd-eba1-669a-2fd5-e40c2802bf6e@oracle.com> References: <8fb50473-7791-39b6-f9c9-9911158380ec@azul.com> <0b74974b-923f-1aa2-4551-0e6661eec14c@redhat.com> <206dd7dd-eba1-669a-2fd5-e40c2802bf6e@oracle.com> Message-ID: <85475381-6c92-9d09-510f-d0b2cea3287f@azul.com> Hi all, > On 2020-08-17 14:28, Andrew Haley wrote: >> The JEP looks good to me. Thank you for the very fast response! Would you add yourself to the reviewers field? On 17.08.2020 16:17, Erik ?sterlund wrote: >> >> Re W^X: there are very few places where we now need runtime-patchable >> methods in the code cache. >> >> On AArch64, we deoptimize and recompile rather than patch in most >> cases. This is because the only instructions we're allowed to patch >> concurrently are direct jumps, traps, and nops. >> >> This leads to very little slowdown in practice because in a tiered- >> compilation-enabled JVM 90% of recompilations are due to tier >> escalation rather than patching needed, and most fields are resolved >> in the interpreter before C1 kicks in. >> >> The remaining places we patch today are >> nmethod::make_not_entrant_or_zombie and compiled inline caches for >> method calls. We can perhaps get rid of the first because we now have >> nmethod entry barriers, and Erik ?sterlund has been working on a >> replacement for inline caches. > > Right. The relevant JEP draft for these changes is here for interested readers: > https://bugs.openjdk.java.net/browse/JDK-8221828 > > In my current implementation prototype, all the above code patching has indeed been removed. > I still have the nmethod entry barriers, but as mentioned they do not patch anything on AArch64. > > Thanks, > /Erik > >> Finally, we would have to change the trampoline logic to go via a >> separate data table. >> >> I think that's it. Not that I'm suggesting you need this for Apple/ >> AArch64, but we're very close. These new mechanisms (nmethods barriers and new invoke binding) are certainly interesting and worth studying. I suppose the idea is to place volatile information to the metaspace instead of the codecache, so it can be patched more freely. But I need to read about these more carefully. Thanks for pointing! Modifying code in runtime is a part of the problem, another is that some meta information is stored in the codecache as well. For example, an allocation of a new code blob requires write capability to the code cache (allocator's data is near the blob). And blobs such as native adapters may be allocated and filled in on-demand, in a runtime call on a java thread, one that executed generated code before the call. Fortunately, it appears that Apple hasn't meant to break self-modifying programs, so they've introduced a mechanism (pthread_jit_write_protect_np[1]) that allows seeing pages as writable or executable depending on a state of the current thread, not a state of the target page. This ability may make the W^X implementation more straightforward and more boring than expected :) Thanks, Anton [1] https://developer.apple.com/documentation/apple_silicon/porting_just-in-time_compilers_to_apple_silicon?language=objc From shade at redhat.com Mon Aug 17 17:37:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 17 Aug 2020 19:37:37 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b02 Upstream Sync In-Reply-To: <20200813190710.GA2495896@stopbrexit> References: <20200813190710.GA2495896@stopbrexit> Message-ID: On 8/13/20 9:07 PM, Andrew Hughes wrote: > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/ > > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/corba/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/jaxp/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/jaxws/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/langtools/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/nashorn/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/root/merge.changeset Looks good. > Ok to push? Yes, I think so. -- Thanks, -Aleksey From felix.yang at huawei.com Tue Aug 18 01:26:08 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 18 Aug 2020 01:26:08 +0000 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8203699: java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 In-Reply-To: <600a5d5f-9506-f72a-b1c5-9bb60d632edf@redhat.com> References: <600a5d5f-9506-f72a-b1c5-9bb60d632edf@redhat.com> Message-ID: Hi, > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Monday, August 17, 2020 4:30 PM > To: Yangfei (Felix) ; aarch64-port- > dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] 8u-aarch64: Backport 8203699: > java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 > > On 17/08/2020 08:35, Yangfei (Felix) wrote: > > Webrev for 8u-aarch64: > > http://cr.openjdk.java.net/~fyang/8203699-8u/webrev.00/ > > > > Performed full jtreg test with 8u aarch64 fastdebug & release build. OK to > backport? > > Great, thanks for catching this. Thanks for looking at this. Pushed. Best Regards, Felix From gnu.andrew at redhat.com Tue Aug 18 02:47:53 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 18 Aug 2020 02:47:53 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 6 new changesets Message-ID: <202008180247.07I2lrMo015335@aojmv0008.oracle.com> Changeset: e49b9bfd5f86 Author: andrew Date: 2020-08-01 03:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/e49b9bfd5f86 Added tag jdk8u272-b01 for changeset c962b0325d3e ! .hgtags Changeset: 5d0057342d17 Author: shade Date: 2020-07-29 09:43 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/5d0057342d17 8046274: Removing dependency on jakarta-regexp Reviewed-by: lancea ! THIRD_PARTY_README Changeset: a702bd3d9db1 Author: andrew Date: 2020-08-06 21:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/a702bd3d9db1 Merge Changeset: eea7b1a818e9 Author: andrew Date: 2020-08-06 21:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/eea7b1a818e9 Added tag jdk8u272-b02 for changeset a702bd3d9db1 ! .hgtags Changeset: 0c08339c4215 Author: andrew Date: 2020-08-09 17:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/0c08339c4215 Merge jdk8u272-b02 ! .hgtags ! THIRD_PARTY_README Changeset: 8f786b75ca00 Author: andrew Date: 2020-08-09 18:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/8f786b75ca00 Added tag aarch64-shenandoah-jdk8u272-b02 for changeset 0c08339c4215 ! .hgtags From gnu.andrew at redhat.com Tue Aug 18 02:46:08 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 18 Aug 2020 02:46:08 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 7 new changesets Message-ID: <202008180246.07I2k87k014822@aojmv0008.oracle.com> Changeset: 91e8e866f772 Author: andrew Date: 2020-08-01 03:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/91e8e866f772 Added tag jdk8u272-b01 for changeset 1bda51d3d528 ! .hgtags Changeset: 834c6a13c8c8 Author: shade Date: 2020-07-29 09:43 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/834c6a13c8c8 8046274: Removing dependency on jakarta-regexp Reviewed-by: lancea ! THIRD_PARTY_README Changeset: 741aff26fe61 Author: jvanek Date: 2020-08-06 06:35 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/741aff26fe61 8154313: Generated javadoc scattered all over the place Summary: Added new top level target zip-docs which scans all generated javadocs and prepare zip-archive in way understandable to most IDEs Reviewed-by: sgehwolf, andrew ! make/Javadoc.gmk ! make/Main.gmk Changeset: 1059e4b7426a Author: andrew Date: 2020-08-06 21:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/1059e4b7426a Merge Changeset: fbad06cacb73 Author: andrew Date: 2020-08-06 21:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/fbad06cacb73 Added tag jdk8u272-b02 for changeset 1059e4b7426a ! .hgtags Changeset: 10eb16496624 Author: andrew Date: 2020-08-09 17:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/10eb16496624 Merge jdk8u272-b02 ! .hgtags ! THIRD_PARTY_README Changeset: 11823e500b27 Author: andrew Date: 2020-08-09 18:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/11823e500b27 Added tag aarch64-shenandoah-jdk8u272-b02 for changeset 10eb16496624 ! .hgtags From gnu.andrew at redhat.com Tue Aug 18 02:59:18 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 18 Aug 2020 02:59:18 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 6 new changesets Message-ID: <202008180259.07I2xI5l021569@aojmv0008.oracle.com> Changeset: 954f42e0d190 Author: andrew Date: 2020-08-01 03:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/954f42e0d190 Added tag jdk8u272-b01 for changeset 1bc3598fbad0 ! .hgtags Changeset: 682b2794d6f3 Author: joehw Date: 2016-05-10 16:19 -0700 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/682b2794d6f3 8046274: Removing dependency on jakarta-regexp Reviewed-by: lancea ! THIRD_PARTY_README ! src/com/sun/org/apache/bcel/internal/util/InstructionFinder.java - src/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java - src/com/sun/org/apache/regexp/internal/CharacterIterator.java - src/com/sun/org/apache/regexp/internal/RE.java - src/com/sun/org/apache/regexp/internal/RECompiler.java - src/com/sun/org/apache/regexp/internal/REDebugCompiler.java - src/com/sun/org/apache/regexp/internal/REProgram.java - src/com/sun/org/apache/regexp/internal/RESyntaxException.java - src/com/sun/org/apache/regexp/internal/RETest.java - src/com/sun/org/apache/regexp/internal/REUtil.java - src/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java - src/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java - src/com/sun/org/apache/regexp/internal/StringCharacterIterator.java - src/com/sun/org/apache/regexp/internal/recompile.java Changeset: 7694bb86e023 Author: andrew Date: 2020-08-06 21:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/7694bb86e023 Merge Changeset: 370157535629 Author: andrew Date: 2020-08-06 21:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/370157535629 Added tag jdk8u272-b02 for changeset 7694bb86e023 ! .hgtags Changeset: fe691799416f Author: andrew Date: 2020-08-09 17:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/fe691799416f Merge jdk8u272-b02 ! .hgtags ! THIRD_PARTY_README - src/com/sun/org/apache/regexp/internal/CharacterArrayCharacterIterator.java - src/com/sun/org/apache/regexp/internal/CharacterIterator.java - src/com/sun/org/apache/regexp/internal/RE.java - src/com/sun/org/apache/regexp/internal/RECompiler.java - src/com/sun/org/apache/regexp/internal/REDebugCompiler.java - src/com/sun/org/apache/regexp/internal/REProgram.java - src/com/sun/org/apache/regexp/internal/RESyntaxException.java - src/com/sun/org/apache/regexp/internal/RETest.java - src/com/sun/org/apache/regexp/internal/REUtil.java - src/com/sun/org/apache/regexp/internal/ReaderCharacterIterator.java - src/com/sun/org/apache/regexp/internal/StreamCharacterIterator.java - src/com/sun/org/apache/regexp/internal/StringCharacterIterator.java - src/com/sun/org/apache/regexp/internal/recompile.java Changeset: c84c071249db Author: andrew Date: 2020-08-09 18:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/c84c071249db Added tag aarch64-shenandoah-jdk8u272-b02 for changeset fe691799416f ! .hgtags From gnu.andrew at redhat.com Tue Aug 18 02:59:48 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 18 Aug 2020 02:59:48 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 6 new changesets Message-ID: <202008180259.07I2xns2021847@aojmv0008.oracle.com> Changeset: f80fd05ef28e Author: andrew Date: 2020-08-01 03:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/f80fd05ef28e Added tag jdk8u272-b01 for changeset 38d13ac335fe ! .hgtags Changeset: ea5a0882d747 Author: shade Date: 2020-07-29 09:44 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/ea5a0882d747 8046274: Removing dependency on jakarta-regexp Reviewed-by: lancea ! THIRD_PARTY_README Changeset: 7aeb5d972262 Author: andrew Date: 2020-08-06 21:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/7aeb5d972262 Merge Changeset: c87827b363e7 Author: andrew Date: 2020-08-06 21:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/c87827b363e7 Added tag jdk8u272-b02 for changeset 7aeb5d972262 ! .hgtags Changeset: 69ac3fa44dad Author: andrew Date: 2020-08-09 17:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/69ac3fa44dad Merge jdk8u272-b02 ! .hgtags ! THIRD_PARTY_README Changeset: 50672b95cb58 Author: andrew Date: 2020-08-09 18:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/50672b95cb58 Added tag aarch64-shenandoah-jdk8u272-b02 for changeset 69ac3fa44dad ! .hgtags From gnu.andrew at redhat.com Tue Aug 18 03:11:08 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 18 Aug 2020 03:11:08 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 22 new changesets Message-ID: <202008180311.07I3B8gw027537@aojmv0008.oracle.com> Changeset: 84c5676f140b Author: andrew Date: 2020-08-01 03:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/84c5676f140b Added tag jdk8u272-b01 for changeset 2f117c583973 ! .hgtags Changeset: 929db9f048e1 Author: shade Date: 2020-07-29 09:44 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/929db9f048e1 8046274: Removing dependency on jakarta-regexp Reviewed-by: lancea ! THIRD_PARTY_README Changeset: e350c3661d4a Author: valeriep Date: 2018-11-07 01:04 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/e350c3661d4a 8211049: Second parameter of "initialize" method is not used Summary: Use the specified random object instead of system default Reviewed-by: weijun ! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java + test/sun/security/rsa/TestKeyPairGeneratorInit.java Changeset: fdcd822abdcf Author: valeriep Date: 2020-04-14 22:12 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/fdcd822abdcf 8242556: Cannot load RSASSA-PSS public key with non-null params from byte array Summary: Update AlgorithmId to use alg name before oid str when parsing DER bytes Reviewed-by: mullan ! src/share/classes/sun/security/x509/AlgorithmId.java ! test/sun/security/rsa/pss/PSSParametersTest.java ! test/sun/security/rsa/pss/TestPSSKeySupport.java Changeset: ba9b355d6057 Author: zgu Date: 2020-07-30 11:37 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ba9b355d6057 8183349: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java and WriteAfterAbort.java Reviewed-by: serb, pnarayanan ! test/javax/imageio/plugins/shared/CanWriteSequence.java ! test/javax/imageio/plugins/shared/WriteAfterAbort.java Changeset: 22d7558e7fe1 Author: serb Date: 2020-07-31 00:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/22d7558e7fe1 8250755: Better cleanup for jdk/test/javax/imageio/plugins/shared/CanWriteSequence.java Reviewed-by: jdv ! test/javax/imageio/plugins/shared/CanWriteSequence.java Changeset: 22eb5e7d689b Author: goetz Date: 2017-11-21 17:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/22eb5e7d689b 8191678: [TESTBUG] Add keyword headful in java/awt FocusTransitionTest test. Reviewed-by: serb, sgehwolf, andrew ! test/java/awt/Focus/FocusTransitionTest/FocusTransitionTest.java Changeset: 8151a0b310d9 Author: ascarpino Date: 2019-02-11 13:23 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/8151a0b310d9 8201633: Problems with AES-GCM native acceleration Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java Changeset: ce745f7b37a9 Author: ascarpino Date: 2019-03-07 19:35 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ce745f7b37a9 8220165: Encryption using GCM results in RuntimeException- input length out of bound Reviewed-by: valeriep ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java + test/com/sun/crypto/provider/Cipher/AEAD/GCMLargeDataKAT.java Changeset: 006dc5ec67ea Author: igerasim Date: 2020-02-17 16:32 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/006dc5ec67ea 8163251: Hard coded loop limit prevents reading of smart card data greater than 8k Reviewed-by: valeriep, rriggs ! src/share/classes/sun/security/smartcardio/ChannelImpl.java Changeset: 0d51b3ba8061 Author: pchopra Date: 2015-04-10 11:35 +0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/0d51b3ba8061 8076151: [TESTBUG] Test java/awt/FontClass/CreateFont/fileaccess/FontFile.java fails Reviewed-by: alexsch, azvegint ! test/java/awt/FontClass/CreateFont/fileaccess/FontFile.java + test/java/awt/FontClass/CreateFont/fileaccess/TestFontFile.sh Changeset: 1ac38ddb865c Author: ysuenaga Date: 2019-03-16 21:27 +0900 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1ac38ddb865c 8220555: JFR tool shows potentially misleading message when it cannot access a file Reviewed-by: egahlin, mseledtsov ! src/share/classes/jdk/jfr/internal/tool/Command.java ! test/jdk/jfr/tool/TestPrint.java Changeset: 87091b543626 Author: egahlin Date: 2019-06-06 15:22 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/87091b543626 8224217: RecordingInfo should use textual representation of path Reviewed-by: mgronlun ! src/share/classes/jdk/jfr/internal/PlatformRecorder.java ! src/share/classes/jdk/jfr/internal/PlatformRecording.java ! src/share/classes/jdk/jfr/internal/WriteableUserPath.java ! src/share/classes/jdk/jfr/internal/management/ManagementSupport.java ! src/share/classes/jdk/management/jfr/RecordingInfo.java Changeset: a844d7f2ac12 Author: qpzhang Date: 2020-02-05 17:14 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/a844d7f2ac12 8238386: (sctp) jdk.sctp/unix/native/libsctp/SctpNet.c "multiple definition" link errors with GCC10 Summary: Fixed libsctp link errors caused by GCC10 default -fno-common Reviewed-by: chegar, sgehwolf Contributed-by: Leslie Zhai ! src/solaris/native/sun/nio/ch/sctp/Sctp.h ! src/solaris/native/sun/nio/ch/sctp/SctpNet.c Changeset: 41be6128f4c1 Author: qpzhang Date: 2020-02-04 21:27 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/41be6128f4c1 8238380: java.base/unix/native/libjava/childproc.c "multiple definition" link errors with GCC10 Reviewed-by: stuefe, clanger, rriggs, sgehwolf Contributed-by: Leslie Zhai ! src/solaris/native/java/lang/childproc.c ! src/solaris/native/java/lang/childproc.h Changeset: d5c69bd5f7ad Author: qpzhang Date: 2020-02-05 20:31 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/d5c69bd5f7ad 8238388: libj2gss/NativeFunc.o "multiple definition" link errors with GCC10 Summary: Fixed libj2gss link errors caused by GCC10 default -fno-common Reviewed-by: weijun, sgehwolf Contributed-by: Leslie Zhai ! src/solaris/native/sun/security/jgss/wrapper/NativeFunc.c ! src/solaris/native/sun/security/jgss/wrapper/NativeFunc.h Changeset: 655f1d059a8c Author: andrew Date: 2020-08-06 06:23 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/655f1d059a8c Merge Changeset: b9ec89d5d8fa Author: igerasim Date: 2014-01-20 19:23 +0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/b9ec89d5d8fa 8025886: replace [[ and == bash extensions in regtest Reviewed-by: dsamersoff, sla ! test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh Changeset: 2b92a111b4bd Author: andrew Date: 2020-08-06 21:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2b92a111b4bd Merge Changeset: aba0b4743822 Author: andrew Date: 2020-08-06 21:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/aba0b4743822 Added tag jdk8u272-b02 for changeset 2b92a111b4bd ! .hgtags Changeset: 051a8d2a65e3 Author: andrew Date: 2020-08-09 17:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/051a8d2a65e3 Merge jdk8u272-b02 ! .hgtags ! THIRD_PARTY_README ! src/share/classes/com/sun/crypto/provider/GaloisCounterMode.java ! src/share/classes/sun/security/rsa/RSAKeyPairGenerator.java Changeset: 4809ecb1e0a1 Author: andrew Date: 2020-08-09 18:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/4809ecb1e0a1 Added tag aarch64-shenandoah-jdk8u272-b02 for changeset 051a8d2a65e3 ! .hgtags From gnu.andrew at redhat.com Tue Aug 18 05:18:05 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 18 Aug 2020 05:18:05 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 13 new changesets Message-ID: <202008180518.07I5I5R9027815@aojmv0008.oracle.com> Changeset: 741cd0f77fac Author: andrew Date: 2020-08-01 03:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/741cd0f77fac Added tag jdk8u272-b01 for changeset 85c9d74850ed ! .hgtags Changeset: 45ec778a8e8d Author: shade Date: 2020-07-29 09:43 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/45ec778a8e8d 8046274: Removing dependency on jakarta-regexp Reviewed-by: lancea ! THIRD_PARTY_README Changeset: c39172598323 Author: poonam Date: 2020-03-23 17:57 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c39172598323 8231779: crash HeapWord*ParallelScavengeHeap::failed_mem_allocate Reviewed-by: dlong, tschatzl, pliden ! src/share/vm/memory/threadLocalAllocBuffer.cpp Changeset: baf9f57c9b46 Author: coleenp Date: 2014-05-05 19:53 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/baf9f57c9b46 8023697: failed class resolution reports different class name in detail message for the first and subsequent times Summary: Cache detail message when we cache exception for constant pool resolution. Reviewed-by: acorn, twisti, jrose ! src/share/vm/classfile/resolutionErrors.cpp ! src/share/vm/classfile/resolutionErrors.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp + test/runtime/ClassResolutionFail/Property.java + test/runtime/ClassResolutionFail/PropertySuper.java + test/runtime/ClassResolutionFail/TestClassResolutionFail.java Changeset: 7ada1402bda0 Author: ysuenaga Date: 2019-04-24 17:09 +0900 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7ada1402bda0 8219566: JFR did not collect call stacks when MaxJavaStackTraceDepth is set to zero Reviewed-by: egahlin, mgronlun, neugens, andrew ! src/share/vm/jfr/periodic/sampling/jfrCallTrace.cpp ! src/share/vm/jfr/recorder/service/jfrOptionSet.cpp ! src/share/vm/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp ! src/share/vm/jfr/utilities/jfrTypes.hpp Changeset: 9a8c9d2291bb Author: jcm Date: 2017-01-24 20:47 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9a8c9d2291bb 8173300: [TESTBUG]compiler/tiered/NonTieredLevelsTest.java fails with compiler.whitebox.SimpleTestCaseHelper(int) must be compiled Summary: Corrected available compilation levels for client builds. Reviewed-by: kvn ! test/compiler/tiered/NonTieredLevelsTest.java Changeset: 40f45911050f Author: zgu Date: 2016-08-25 09:23 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/40f45911050f 8148854: Class names "SomeClass" and "LSomeClass;" treated by JVM as an equivalent Summary: Added default format checking of class names loaded by the app class loader Reviewed-by: andrew ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/classfile/verifier.hpp ! src/share/vm/runtime/reflection.cpp + test/runtime/ClassFile/BadHelloWorld.jcod + test/runtime/ClassFile/FormatCheckingTest.java Changeset: f614bd5c9561 Author: coleenp Date: 2014-07-09 22:37 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f614bd5c9561 8048933: -XX:+TraceExceptions output should include the message Summary: Add the exception detail message to the tracing output Reviewed-by: minqi, dholmes ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/oops/constantPool.cpp + test/runtime/CommandLine/TraceExceptionsTest.java Changeset: 414c1dcfc3f3 Author: andrew Date: 2020-08-06 21:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/414c1dcfc3f3 Merge Changeset: 182c3887f2e6 Author: andrew Date: 2020-08-06 21:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/182c3887f2e6 Added tag jdk8u272-b02 for changeset 414c1dcfc3f3 ! .hgtags Changeset: 21931e4cd1dc Author: andrew Date: 2020-08-09 17:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/21931e4cd1dc Merge jdk8u272-b02 ! .hgtags ! THIRD_PARTY_README ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/verifier.cpp ! src/share/vm/interpreter/interpreterRuntime.cpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/oops/constantPool.cpp ! src/share/vm/oops/constantPool.hpp ! src/share/vm/runtime/reflection.cpp ! src/share/vm/utilities/constantTag.cpp ! src/share/vm/utilities/constantTag.hpp Changeset: cdd717f72101 Author: andrew Date: 2020-08-09 18:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cdd717f72101 Added tag aarch64-shenandoah-jdk8u272-b02 for changeset 21931e4cd1dc ! .hgtags Changeset: 0db44af78de2 Author: andrew Date: 2020-08-18 06:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0db44af78de2 Merge From gnu.andrew at redhat.com Tue Aug 18 05:24:29 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Aug 2020 06:24:29 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b02 Upstream Sync In-Reply-To: References: <20200813190710.GA2495896@stopbrexit> Message-ID: <20200818052429.GA2812922@stopbrexit> On 19:37 Mon 17 Aug , Aleksey Shipilev wrote: > On 8/13/20 9:07 PM, Andrew Hughes wrote: > > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/ > > > > Merge changesets: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/corba/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/jaxp/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/jaxws/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/jdk/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/hotspot/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/langtools/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/nashorn/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b02/root/merge.changeset > Looks good. > > > Ok to push? > > Yes, I think so. > > -- > Thanks, > -Aleksey > Thanks, pushed. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Tue Aug 18 05:18:55 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 18 Aug 2020 05:18:55 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 6 new changesets Message-ID: <202008180518.07I5ItrR028225@aojmv0008.oracle.com> Changeset: 45fb59535711 Author: andrew Date: 2020-08-01 03:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/45fb59535711 Added tag jdk8u272-b01 for changeset a51cd1abb0c9 ! .hgtags Changeset: 386a7083c3b1 Author: shade Date: 2020-07-29 09:44 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/386a7083c3b1 8046274: Removing dependency on jakarta-regexp Reviewed-by: lancea ! THIRD_PARTY_README Changeset: 54f67143c956 Author: andrew Date: 2020-08-06 21:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/54f67143c956 Merge Changeset: 4e02b68de458 Author: andrew Date: 2020-08-06 21:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/4e02b68de458 Added tag jdk8u272-b02 for changeset 54f67143c956 ! .hgtags Changeset: 8f5a886fa53b Author: andrew Date: 2020-08-09 17:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/8f5a886fa53b Merge jdk8u272-b02 ! .hgtags ! THIRD_PARTY_README Changeset: cab55cd92864 Author: andrew Date: 2020-08-09 18:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/cab55cd92864 Added tag aarch64-shenandoah-jdk8u272-b02 for changeset 8f5a886fa53b ! .hgtags From gnu.andrew at redhat.com Tue Aug 18 05:19:21 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 18 Aug 2020 05:19:21 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 6 new changesets Message-ID: <202008180519.07I5JLa8028465@aojmv0008.oracle.com> Changeset: aaf3f5ef88ec Author: andrew Date: 2020-08-01 03:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/aaf3f5ef88ec Added tag jdk8u272-b01 for changeset ab242949177c ! .hgtags Changeset: 891522de716b Author: shade Date: 2020-07-29 09:44 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/891522de716b 8046274: Removing dependency on jakarta-regexp Reviewed-by: lancea ! THIRD_PARTY_README Changeset: cf78b728ecca Author: andrew Date: 2020-08-06 21:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/cf78b728ecca Merge Changeset: 1409bb48eea8 Author: andrew Date: 2020-08-06 21:23 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/1409bb48eea8 Added tag jdk8u272-b02 for changeset cf78b728ecca ! .hgtags Changeset: 2d5e96d811f7 Author: andrew Date: 2020-08-09 17:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/2d5e96d811f7 Merge jdk8u272-b02 ! .hgtags ! THIRD_PARTY_README Changeset: c3d60ae7494e Author: andrew Date: 2020-08-09 18:54 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/c3d60ae7494e Added tag aarch64-shenandoah-jdk8u272-b02 for changeset 2d5e96d811f7 ! .hgtags From gnu.andrew at redhat.com Tue Aug 18 05:38:19 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 18 Aug 2020 06:38:19 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b03 Upstream Sync Message-ID: <20200818053819.GB2812922@stopbrexit> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/root/merge.changeset Changes in aarch64-shenandoah-jdk8u272-b03: - JDK-6574989: TEST_BUG: javax/sound/sampled/Clip/bug5070081.java fails sometimes - JDK-8148754: C2 loop unrolling fails due to unexpected graph shape - JDK-8192953: sun/management/jmxremote/bootstrap/*.sh tests fail with error : revokeall.exe: Permission denied - JDK-8203357: Container Metrics - JDK-8209113: Use WeakReference for lastFontStrike for created Fonts - JDK-8216283: Allow shorter method sampling interval than 10 ms - JDK-8221569: JFR tool produces incorrect output when both --categories and --events are specified - JDK-8233097: Fontmetrics for large Fonts has zero width - JDK-8248851: CMS: Missing memory fences between free chunk check and klass read - JDK-8250875: Incorrect parameter type for update_number in JDK_Version::jdk_update Main issues of note: * Slight context difference in jdk/test/tools/launcher/Settings.java due to presence of JDK-8163363, which conflicts with JDK-8203357. * JDK-8203699 was added to the HotSpot repository after tagging, so a merge was necessary and this appears as an uncredited change to src/cpu/aarch64/vm/macroAssembler_aarch64.cpp in the webrev. The change will be included in the next tag. diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/make/CompileJavaClasses.gmk | 6 b/src/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java | 461 +++++++++ b/src/linux/classes/jdk/internal/platform/cgroupv1/SubSystem.java | 208 ++++ b/src/share/classes/jdk/internal/platform/Container.java | 43 b/src/share/classes/jdk/internal/platform/Metrics.java | 507 ++++++++++ b/src/share/classes/jdk/jfr/conf/default.jfc | 41 b/src/share/classes/jdk/jfr/conf/profile.jfc | 43 b/src/share/classes/jdk/jfr/internal/tool/Print.java | 24 b/src/share/classes/sun/font/Font2D.java | 50 b/src/share/classes/sun/font/FontStrikeDisposer.java | 20 b/src/share/classes/sun/font/SunFontManager.java | 25 b/src/share/classes/sun/launcher/LauncherHelper.java | 108 ++ b/src/share/classes/sun/launcher/resources/launcher.properties | 8 b/src/share/native/sun/font/freetypeScaler.c | 87 + b/test/java/awt/FontClass/MassiveMetricsTest.java | 69 + b/test/javax/sound/sampled/Clip/bug5070081.java | 24 b/test/jdk/internal/platform/cgroup/TestCgroupMetrics.java | 55 + b/test/jdk/internal/platform/docker/Dockerfile-BasicTest | 8 b/test/jdk/internal/platform/docker/Dockerfile-BasicTest-aarch64 | 8 b/test/jdk/internal/platform/docker/Dockerfile-BasicTest-ppc64le | 10 b/test/jdk/internal/platform/docker/Dockerfile-BasicTest-s390x | 7 b/test/jdk/internal/platform/docker/MetricsCpuTester.java | 178 +++ b/test/jdk/internal/platform/docker/MetricsMemoryTester.java | 140 ++ b/test/jdk/internal/platform/docker/TestDockerCpuMetrics.java | 164 +++ b/test/jdk/internal/platform/docker/TestDockerMemoryMetrics.java | 143 ++ b/test/jdk/internal/platform/docker/TestSystemMetrics.java | 58 + b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java | 8 b/test/sun/management/jmxremote/bootstrap/GeneratePropertyPassword.sh | 17 b/test/tools/launcher/Settings.java | 19 30 files changed, 2444 insertions(+), 96 deletions(-) diffstat for hotspot b/.hgtags | 1 b/src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp | 15 +++ b/src/share/vm/jfr/periodic/sampling/jfrThreadSampler.cpp | 4 b/src/share/vm/opto/loopTransform.cpp | 42 +++------- b/src/share/vm/opto/loopnode.cpp | 35 ++++++++ b/src/share/vm/opto/loopnode.hpp | 3 b/src/share/vm/opto/superword.cpp | 18 +--- b/src/share/vm/runtime/java.hpp | 2 8 files changed, 77 insertions(+), 43 deletions(-) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le, aarch32 (Zero) & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Tue Aug 18 05:43:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 18 Aug 2020 07:43:06 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b03 Upstream Sync In-Reply-To: <20200818053819.GB2812922@stopbrexit> References: <20200818053819.GB2812922@stopbrexit> Message-ID: <20c0bc32-572e-fcb2-d29d-4534c2581977@redhat.com> On 8/18/20 7:38 AM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/jaxws/merge.changeset Look trivial and good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b03/root/merge.changeset Look trivial and good. > Ok to push? Yes. -- Thanks, -Aleksey From felix.yang at huawei.com Tue Aug 18 06:27:35 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 18 Aug 2020 06:27:35 +0000 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> <9e733fb0-5916-2342-7962-ee1ec2f6f076@redhat.com> <80b588a5-e07f-9d8e-1079-c14530570549@redhat.com> Message-ID: CCing to the mailing lists. Sorry for forgetting that. > -----Original Message----- > From: Yangfei (Felix) > Sent: Tuesday, August 18, 2020 2:17 PM > To: 'Andrew Haley' > Subject: RE: RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic > > Hi, > > > -----Original Message----- > > From: Andrew Haley [mailto:aph at redhat.com] > > Sent: Monday, August 17, 2020 11:54 PM > > To: Yangfei (Felix) ; hotspot-runtime- > > dev at openjdk.java.net > > Cc: aarch64-port-dev at openjdk.java.net > > Subject: Re: RFR: 8165404: AArch64: Implement SHA512 > > accelerator/intrinsic > > > > On 17/08/2020 13:01, Yangfei (Felix) wrote: > > >> Looks good. If I were editing the Python script I'd also add > > >> random.seed(0) so that the generated code doesn't change every time. > > > > > Thanks for the quick reply. Do you mean we need any more change? > > > For the purpose for testing the instructions, it might not be a good > > > idea to add random.seed(0). This will limit the randomness of the > > > register numbers used for each run. > > > > Not really, because we paste the output into assembler.cpp so that we > > use the same values every time it runs. I don't think it helps anyone > > that we use different random offsets every time the test code is > regenerated. > > Make sense to me in that respect. > > I created a new issue and prepared a webrev for this: > Bug: https://bugs.openjdk.java.net/browse/JDK-8251885 > Webrev: http://cr.openjdk.java.net/~fyang/8251885/webrev.01 > > This added random.seed(0) to aarch64-asmtest.py and regenerate the code > as a baseline. > Passed the smoke test for assembler in assembler_aarch64.cpp with a > slowdebug build. > Is it good to go? > > Thanks, > Felix From felix.yang at huawei.com Tue Aug 18 06:46:17 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Tue, 18 Aug 2020 06:46:17 +0000 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg Message-ID: Hi, Original Bug: https://bugs.openjdk.java.net/browse/JDK-8247979 Original patch: https://hg.openjdk.java.net/jdk/jdk/rev/9fce19fdda7e Review thread: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-June/009120.html As mentioned in the review thread, this poses similar risk as bug: 8224828: aarch64: rflags is not correct after safepoint poll. It will be very hard to find out if this kind of bug triggers. Webrev for 8u-aarch64: http://cr.openjdk.java.net/~fyang/8247979-8u/webrev.00/ This handles both clearArray_reg_reg and clearArray_imm_reg as rflags can be clobbered by both of them. This is not the case for clearArray_imm_reg in jdk11+ versions. Performed full jtreg test with 8u aarch64 release build. OK to backport? Thanks, Felix From aph at redhat.com Tue Aug 18 09:34:00 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 18 Aug 2020 10:34:00 +0100 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> <9e733fb0-5916-2342-7962-ee1ec2f6f076@redhat.com> <80b588a5-e07f-9d8e-1079-c14530570549@redhat.com> Message-ID: On 18/08/2020 07:27, Yangfei (Felix) wrote: > I created a new issue and prepared a webrev for this: > Bug: https://bugs.openjdk.java.net/browse/JDK-8251885 > Webrev: http://cr.openjdk.java.net/~fyang/8251885/webrev.01 > > This added random.seed(0) to aarch64-asmtest.py and regenerate the code > as a baseline. > Passed the smoke test for assembler in assembler_aarch64.cpp with a > slowdebug build. > Is it good to go? Super! Thank you for your patience and great work. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 18 09:37:58 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 18 Aug 2020 10:37:58 +0100 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg In-Reply-To: References: Message-ID: <5a55943c-09bc-6128-d2f0-d8a9a13c38cb@redhat.com> On 18/08/2020 07:46, Yangfei (Felix) wrote: > Webrev for 8u-aarch64: http://cr.openjdk.java.net/~fyang/8247979-8u/webrev.00/ > This handles both clearArray_reg_reg and clearArray_imm_reg as rflags can be clobbered by both of them. > This is not the case for clearArray_imm_reg in jdk11+ versions. > > Performed full jtreg test with 8u aarch64 release build. OK to backport? Sure, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Tue Aug 18 14:11:19 2020 From: felix.yang at huawei.com (felix.yang at huawei.com) Date: Tue, 18 Aug 2020 14:11:19 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg Message-ID: <202008181411.07IEBJXS002692@aojmv0008.oracle.com> Changeset: ed70d5208f5f Author: fyang Date: 2020-06-22 20:26 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ed70d5208f5f 8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg Reviewed-by: adinn Contributed-by: wangyadong4 at huawei.com ! src/cpu/aarch64/vm/aarch64.ad From dmitry.chuyko at bell-sw.com Tue Aug 18 15:05:01 2020 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 18 Aug 2020 18:05:01 +0300 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: <67e67230-cac7-d940-1cca-6ab4e8cba8d4@redhat.com> References: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> <67e67230-cac7-d940-1cca-6ab4e8cba8d4@redhat.com> Message-ID: <9e792a33-4f90-8829-2f7b-158d07d3fd15@bell-sw.com> Hi Andrew, Thanks for taking a look. This work has started as a try to improve common code, see JDK-8249198 [1] and short related discussion [2]. And the original benchmark [3] is quite similar to the one that you used. As you kindly tried the patch on a hardware where it shows degradation (baseline is quite slow btw), I think it makes sense to limit it to Cortex/Neoverse. So I restored UseSignumInrinsic flag which is enabled only for CPU_ARM. Disabling InlineMathNatives also disables it. webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.02/ As suggested by Anrew Dinn, there are few more test cases in the test: +-MIN_NORMAL and some denormal numbers. Some more results for a benchmark with reduce(): -XX:-UseSignumIntrinsic DoubleOrigSignum.ofMostlyNaN 0.914 ? 0.001 ns/op DoubleOrigSignum.ofMostlyNeg 1.178 ? 0.001 ns/op DoubleOrigSignum.ofMostlyPos 1.176 ? 0.017 ns/op DoubleOrigSignum.ofMostlyZero 0.803 ? 0.001 ns/op DoubleOrigSignum.ofRandom 1.175 ? 0.012 ns/op -XX:+UseSignumIntrinsic DoubleOrigSignum.ofMostlyNaN 1.040 ? 0.007 ns/op DoubleOrigSignum.ofMostlyNeg 1.040 ? 0.004 ns/op DoubleOrigSignum.ofMostlyPos 1.039 ? 0.003 ns/op DoubleOrigSignum.ofMostlyZero 1.040 ? 0.001 ns/op DoubleOrigSignum.ofRandom 1.040 ? 0.003 ns/op If we only intrinsify copySign() we lose free mask that we get from facgt. In such case improvement (for signum) decreases like from ~30% to ~15%, and it also greatly depends on the particular HW. We can additionally introduce an intrinsic for Math.copySign(), especially it makes sense for float where it can be just 2 fp instructions: movi+bsl (fmovd+fnegd+bsl for double). -Dmitry [1] https://bugs.openjdk.java.net/browse/JDK-8249198 [2] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-July/067666.html [3] http://cr.openjdk.java.net/~dchuyko/8249198/webrev.00/raw_files/new/test/micro/org/openjdk/bench/java/lang/DoubleSignum.java On 8/15/20 4:50 PM, Andrew Haley wrote: > I've been looking at the way Math.signum() is used, mostly by > searching the GitHub code database. I've changed the JMH test to be > IMO more realistic: it's at > http://cr.openjdk.java.net/~aph/DoubleSignum.java. I think it's more > realitic because signum() results usually aren't stored but are used > to feed other arithmetic ops, usually + or *. > > Baseline: > > Benchmark Mode Cnt Score Error Units > DoubleSignum.ofMostlyNaN avgt 3 2.409 ? 0.051 ns/op > DoubleSignum.ofMostlyNeg avgt 3 2.475 ? 0.211 ns/op > DoubleSignum.ofMostlyPos avgt 3 2.494 ? 0.015 ns/op > DoubleSignum.ofMostlyZero avgt 3 2.501 ? 0.008 ns/op > DoubleSignum.ofRandom avgt 3 2.458 ? 0.373 ns/op > DoubleSignum.overhead avgt 3 2.373 ? 0.029 ns/op > > -XX:+UseSignumIntrinsic: > > Benchmark Mode Cnt Score Error Units > DoubleSignum.ofMostlyNaN avgt 3 2.776 ? 0.006 ns/op > DoubleSignum.ofMostlyNeg avgt 3 2.773 ? 0.066 ns/op > DoubleSignum.ofMostlyPos avgt 3 2.772 ? 0.084 ns/op > DoubleSignum.ofMostlyZero avgt 3 2.770 ? 0.045 ns/op > DoubleSignum.ofRandom avgt 3 2.769 ? 0.005 ns/op > DoubleSignum.overhead avgt 3 2.376 ? 0.013 ns/op > > > I think it might be more useful for you to work on optimizing > Math.copysign(). > From akozlov at azul.com Tue Aug 18 15:21:53 2020 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 18 Aug 2020 18:21:53 +0300 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot Message-ID: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> Hi, Could you please review a fix for C++ types mismatch in cpu/aarch64. Bug: https://bugs.openjdk.java.net/browse/JDK-8251930 Webrev: http://cr.openjdk.java.net/~akozlov/8251930/webrev.00/ The issue was discovered by trying to compile by aarch64-darwin toolchain, but it just uncovered a more general problem. Extra method overloads with for int, long, ... are added to catch all (suitable) types used for intptr_t, int64_t. Now there are overloads only for int (for literal values) and int64, latter usually shares a fundamental type with intptr. The new toolchain provides different types for int64 and intptr. Then both overloads are not perfect for an intptr argument but possible, so compilation is failed. Providing additional overload for intptr fixes compilation on new toolchain but breaks linux, as intptr and int64 are different overloads for essentially the same type. Another approach is to leave a single overload for integer type, but literal integer could still be ambiguously promoted to e.g. pointer or int64. So every user will have to explicitly cast literal integers to a certain type. Tested on aarch64-darwin (succesfully compiles cpu/aarch64 code) and aarch64-linux toolchains. Thanks, Anton From akozlov at azul.com Tue Aug 18 17:53:06 2020 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 18 Aug 2020 20:53:06 +0300 Subject: [aarch64-port-dev ] RFR(S) 8248660: AArch64: JDK-Windows: Make _clear_cache and _nop portable In-Reply-To: <107e0d1b-38cf-f70f-b69e-c50c21cbd340@redhat.com> References: <107e0d1b-38cf-f70f-b69e-c50c21cbd340@redhat.com> Message-ID: <2323b65a-0f63-2e53-96bf-1e19011f7853@azul.com> Hi, > On 8/3/20 11:29 PM, Monica Beckwith wrote: >> Hi all, could I please get a review for the following webrev? I had previously sent this out for feedback and Kim had provided feedback on the usual way to handle such changes: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-July/009272.html >> >> I have made the needful changes and ran them through JTREG for linux-aarch64, windows-aarch64, windows-x86-64, and linux-x86-64. >> >> Webrev: http://cr.openjdk.java.net/~mbeckwit/8248660/webrev.01/ >> JBS: https://bugs.openjdk.java.net/browse/JDK-8248660 +++ b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp - asm volatile ("nop"); + NOP(); This code seems to be the only user of the new NOP() macro. This [1] and another [2] place are the only occurrences of asm_bp. It looks like a debugging aid that is unlikely to be used by anyone now. Is it possible to remove asm_bp and the nop at all? And nitpiking, --- a/src/hotspot/cpu/aarch64/icache_aarch64.hpp +++ b/src/hotspot/os_cpu/linux_aarch64/icache_linux_aarch64.hpp - __builtin___clear_cache((char *)addr, (char *)(addr + 3)); + __builtin___clear_cache((char *)addr, (char *)(addr + 4)); an extra byte is invalidated, a typo? Thanks, Anton [1] http://hg.openjdk.java.net/jdk/jdk/file/a51ce7f4ee54/src/hotspot/cpu/aarch64/assembler_aarch64.cpp#l33 [2] http://hg.openjdk.java.net/jdk/jdk/file/a51ce7f4ee54/src/hotspot/cpu/aarch64/assembler_aarch64.hpp#l611 From Monica.Beckwith at microsoft.com Tue Aug 18 19:02:00 2020 From: Monica.Beckwith at microsoft.com (Monica Beckwith) Date: Tue, 18 Aug 2020 19:02:00 +0000 Subject: [aarch64-port-dev ] RFR(S) 8248660: AArch64: JDK-Windows: Make _clear_cache and _nop portable In-Reply-To: <2323b65a-0f63-2e53-96bf-1e19011f7853@azul.com> References: <107e0d1b-38cf-f70f-b69e-c50c21cbd340@redhat.com> <2323b65a-0f63-2e53-96bf-1e19011f7853@azul.com> Message-ID: Anton - please refer to my email on the builtin__clear_cache fix: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009403.html. (Gist: The original +3 was not correct and hence the change to +4) -Monica -----Original Message----- From: Anton Kozlov Sent: Tuesday, August 18, 2020 12:53 PM To: Andrew Haley ; Monica Beckwith ; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(S) 8248660: AArch64: JDK-Windows: Make _clear_cache and _nop portable Hi, > On 8/3/20 11:29 PM, Monica Beckwith wrote: >> Hi all, could I please get a review for the following webrev? I had >> previously sent this out for feedback and Kim had provided feedback >> on the usual way to handle such changes: >> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai >> l.openjdk.java.net%2Fpipermail%2Faarch64-port-dev%2F2020-July%2F00927 >> 2.html&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35b >> ffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C >> 637333692914167361&sdata=xm8za2G1bPPqlXoM6yA7CBFg94R1l9F6Gr82ZJMi >> EBs%3D&reserved=0 >> >> I have made the needful changes and ran them through JTREG for linux-aarch64, windows-aarch64, windows-x86-64, and linux-x86-64. >> >> Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~mbeckwit%2F8248660%2Fwebrev.01%2F&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35bffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333692914177315&sdata=t7jYLFTBIMBatnkJdJY%2BQmISAozEHnZmXvytGiVvHsk%3D&reserved=0 >> JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248660&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35bffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333692914177315&sdata=bGLGYacKtU4GCm9zEjWqL8PyWtzzR1u%2FStCbxRhhRwc%3D&reserved=0 +++ b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp - asm volatile ("nop"); + NOP(); This code seems to be the only user of the new NOP() macro. This [1] and another [2] place are the only occurrences of asm_bp. It looks like a debugging aid that is unlikely to be used by anyone now. Is it possible to remove asm_bp and the nop at all? And nitpiking, --- a/src/hotspot/cpu/aarch64/icache_aarch64.hpp +++ b/src/hotspot/os_cpu/linux_aarch64/icache_linux_aarch64.hpp - __builtin___clear_cache((char *)addr, (char *)(addr + 3)); + __builtin___clear_cache((char *)addr, (char *)(addr + 4)); an extra byte is invalidated, a typo? Thanks, Anton [1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2Fa51ce7f4ee54%2Fsrc%2Fhotspot%2Fcpu%2Faarch64%2Fassembler_aarch64.cpp%23l33&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35bffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333692914177315&sdata=ozVwjDL5m9tzPvlOz%2FXomVbJeNAD8zyPCILyb5QR%2BwU%3D&reserved=0 [2] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2Fa51ce7f4ee54%2Fsrc%2Fhotspot%2Fcpu%2Faarch64%2Fassembler_aarch64.hpp%23l611&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35bffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333692914177315&sdata=8%2BLXdyP2%2F5vf%2B8yG0ko4f6LkFvjdBosu%2BexeUk43q5A%3D&reserved=0 From beurba at microsoft.com Tue Aug 18 19:43:25 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Tue, 18 Aug 2020 19:43:25 +0000 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> Message-ID: Hi Anton, > Another approach is to leave a single overload for integer type, but literal integer could still be ambiguously promoted to e.g. pointer or int64. So every user will have to explicitly cast literal integers to a certain type. That's how I did it initially, but it's quite a noisy patch and in reality doesn't add any value, so I prefer your solution. I applied your patch on my WIP branch for aarch64-darwin and it builds for me as well. Just a small comment: With JDK-8248414 [1] we tried to eliminate many unsigned long/long usages, since "unsigned long" ends up with different bittness on LLP64 (Windows) vs. LP64 (Linux, macOS, etc.). So I would suggest to add overloads using the [u]int{32,64}_t + [u]intptr_t types instead, which adds a bit more clarity imho. Otherwise your change looks good (but I'm not a reviewer :-)). Thanks, -Bernhard [1] https://bugs.openjdk.java.net/browse/JDK-8248414 ________________________________________ From: aarch64-port-dev on behalf of Anton Kozlov Sent: Tuesday, August 18, 2020 17:21 To: hotspot-dev at openjdk.java.net Cc: aarch64-port-dev at openjdk.java.net Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot Hi, Could you please review a fix for C++ types mismatch in cpu/aarch64. Bug: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8251930&data=02%7C01%7Cbeurba%40microsoft.com%7Cd014403573904a86151008d8438956d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333604431135902&sdata=jgh%2FFoiw2n80g54p%2B8WyrODMswn9Hst0gt3eVnn2%2B%2BY%3D&reserved=0 Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~akozlov%2F8251930%2Fwebrev.00%2F&data=02%7C01%7Cbeurba%40microsoft.com%7Cd014403573904a86151008d8438956d1%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333604431135902&sdata=IKEdHXv0rIK4DqVqDfI%2BN2o7ArwctDiltSRi8vmvP0Y%3D&reserved=0 The issue was discovered by trying to compile by aarch64-darwin toolchain, but it just uncovered a more general problem. Extra method overloads with for int, long, ... are added to catch all (suitable) types used for intptr_t, int64_t. Now there are overloads only for int (for literal values) and int64, latter usually shares a fundamental type with intptr. The new toolchain provides different types for int64 and intptr. Then both overloads are not perfect for an intptr argument but possible, so compilation is failed. Providing additional overload for intptr fixes compilation on new toolchain but breaks linux, as intptr and int64 are different overloads for essentially the same type. Another approach is to leave a single overload for integer type, but literal integer could still be ambiguously promoted to e.g. pointer or int64. So every user will have to explicitly cast literal integers to a certain type. Tested on aarch64-darwin (succesfully compiles cpu/aarch64 code) and aarch64-linux toolchains. Thanks, Anton From felix.yang at huawei.com Wed Aug 19 00:57:20 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 19 Aug 2020 00:57:20 +0000 Subject: [aarch64-port-dev ] 8u-aarch64: Backport 8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg In-Reply-To: <5a55943c-09bc-6128-d2f0-d8a9a13c38cb@redhat.com> References: <5a55943c-09bc-6128-d2f0-d8a9a13c38cb@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, August 18, 2020 5:38 PM > To: Yangfei (Felix) ; aarch64-port- > dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] 8u-aarch64: Backport 8247979: aarch64: > missing side effect of killing flags for clearArray_reg_reg > > On 18/08/2020 07:46, Yangfei (Felix) wrote: > > Webrev for 8u-aarch64: > > http://cr.openjdk.java.net/~fyang/8247979-8u/webrev.00/ > > This handles both clearArray_reg_reg and clearArray_imm_reg as rflags can > be clobbered by both of them. > > This is not the case for clearArray_imm_reg in jdk11+ versions. > > > > Performed full jtreg test with 8u aarch64 release build. OK to backport? > > Sure, thanks. Thanks for looking at this. Pushed. Felix From felix.yang at huawei.com Wed Aug 19 00:58:42 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Wed, 19 Aug 2020 00:58:42 +0000 Subject: [aarch64-port-dev ] RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic In-Reply-To: References: <654e8a2e-87a1-9c3d-4c58-36b4215bb0ad@redhat.com> <5350e745-87af-ce34-8711-2b652a38e323@redhat.com> <4d1f7179-2cad-620d-f833-949e8b39ee06@redhat.com> <7cedaced-9628-32b3-6d01-beae760fc964@redhat.com> <9e733fb0-5916-2342-7962-ee1ec2f6f076@redhat.com> <80b588a5-e07f-9d8e-1079-c14530570549@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Tuesday, August 18, 2020 5:34 PM > To: Yangfei (Felix) > Cc: hotspot-runtime-dev at openjdk.java.net; aarch64-port- > dev at openjdk.java.net > Subject: Re: RFR: 8165404: AArch64: Implement SHA512 accelerator/intrinsic > > On 18/08/2020 07:27, Yangfei (Felix) wrote: > > I created a new issue and prepared a webrev for this: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251885 > > Webrev: http://cr.openjdk.java.net/~fyang/8251885/webrev.01 > > > > This added random.seed(0) to aarch64-asmtest.py and regenerate the > > code as a baseline. > > Passed the smoke test for assembler in assembler_aarch64.cpp with a > > slowdebug build. > > Is it good to go? > > Super! Thank you for your patience and great work. Thanks for reviewing this. Pushed as: https://hg.openjdk.java.net/jdk/jdk/rev/06a0743e84d9 Felix From akozlov at azul.com Wed Aug 19 07:41:01 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 19 Aug 2020 10:41:01 +0300 Subject: [aarch64-port-dev ] RFR(S) 8248660: AArch64: JDK-Windows: Make _clear_cache and _nop portable In-Reply-To: References: <107e0d1b-38cf-f70f-b69e-c50c21cbd340@redhat.com> <2323b65a-0f63-2e53-96bf-1e19011f7853@azul.com> Message-ID: My bad, sorry. Don't know how I missed that, probably dived into the patch after reading about NOP. Agree, __builtin___clear_cache change seems correct (I'm not a reviewer) Thanks, Anton On 18.08.2020 22:02, Monica Beckwith wrote: > Anton - please refer to my email on the builtin__clear_cache fix: https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009403.html. (Gist: The original +3 was not correct and hence the change to +4) > > -Monica > > -----Original Message----- > From: Anton Kozlov > Sent: Tuesday, August 18, 2020 12:53 PM > To: Andrew Haley ; Monica Beckwith ; aarch64-port-dev at openjdk.java.net > Cc: openjdk-aarch64 > Subject: Re: [aarch64-port-dev ] RFR(S) 8248660: AArch64: JDK-Windows: Make _clear_cache and _nop portable > > Hi, > >> On 8/3/20 11:29 PM, Monica Beckwith wrote: >>> Hi all, could I please get a review for the following webrev? I had >>> previously sent this out for feedback and Kim had provided feedback >>> on the usual way to handle such changes: >>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmai >>> l.openjdk.java.net%2Fpipermail%2Faarch64-port-dev%2F2020-July%2F00927 >>> 2.html&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35b >>> ffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C >>> 637333692914167361&sdata=xm8za2G1bPPqlXoM6yA7CBFg94R1l9F6Gr82ZJMi >>> EBs%3D&reserved=0 >>> >>> I have made the needful changes and ran them through JTREG for linux-aarch64, windows-aarch64, windows-x86-64, and linux-x86-64. >>> >>> Webrev: https://nam06.safelinks.protection.outlook.com/?url=http:%2F%2Fcr.openjdk.java.net%2F~mbeckwit%2F8248660%2Fwebrev.01%2F&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35bffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333692914177315&sdata=t7jYLFTBIMBatnkJdJY%2BQmISAozEHnZmXvytGiVvHsk%3D&reserved=0 >>> JBS: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248660&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35bffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333692914177315&sdata=bGLGYacKtU4GCm9zEjWqL8PyWtzzR1u%2FStCbxRhhRwc%3D&reserved=0 > > +++ b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp > - asm volatile ("nop"); > + NOP(); > > This code seems to be the only user of the new NOP() macro. This [1] and another [2] place are the only occurrences of asm_bp. It looks like a debugging aid that is unlikely to be used by anyone now. Is it possible to remove asm_bp and the nop at all? > > > And nitpiking, > > --- a/src/hotspot/cpu/aarch64/icache_aarch64.hpp > +++ b/src/hotspot/os_cpu/linux_aarch64/icache_linux_aarch64.hpp > - __builtin___clear_cache((char *)addr, (char *)(addr + 3)); > + __builtin___clear_cache((char *)addr, (char *)(addr + 4)); > > an extra byte is invalidated, a typo? > > Thanks, > Anton > > [1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2Fa51ce7f4ee54%2Fsrc%2Fhotspot%2Fcpu%2Faarch64%2Fassembler_aarch64.cpp%23l33&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35bffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333692914177315&sdata=ozVwjDL5m9tzPvlOz%2FXomVbJeNAD8zyPCILyb5QR%2BwU%3D&reserved=0 > [2] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.openjdk.java.net%2Fjdk%2Fjdk%2Ffile%2Fa51ce7f4ee54%2Fsrc%2Fhotspot%2Fcpu%2Faarch64%2Fassembler_aarch64.hpp%23l611&data=02%7C01%7Cmonica.beckwith%40microsoft.com%7C877aba35bffc49bc771b08d8439df0d8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637333692914177315&sdata=8%2BLXdyP2%2F5vf%2B8yG0ko4f6LkFvjdBosu%2BexeUk43q5A%3D&reserved=0 > From aph at redhat.com Wed Aug 19 08:13:12 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 09:13:12 +0100 Subject: [aarch64-port-dev ] RFR(S) 8248660: AArch64: JDK-Windows: Make _clear_cache and _nop portable In-Reply-To: <2323b65a-0f63-2e53-96bf-1e19011f7853@azul.com> References: <107e0d1b-38cf-f70f-b69e-c50c21cbd340@redhat.com> <2323b65a-0f63-2e53-96bf-1e19011f7853@azul.com> Message-ID: <9f504d27-e5f7-cf8f-6b52-8db8d1cc9cdc@redhat.com> On 18/08/2020 18:53, Anton Kozlov wrote: > +++ b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp > - asm volatile ("nop"); > + NOP(); > > This code seems to be the only user of the new NOP() macro. This [1] and > another [2] place are the only occurrences of asm_bp. It looks like a debugging > aid that is unlikely to be used by anyone now. Is it possible to remove asm_bp > and the nop at all? It's still useful. Feel free to make it Linux-only if you like. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Aug 19 08:35:57 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 09:35:57 +0100 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: <9e792a33-4f90-8829-2f7b-158d07d3fd15@bell-sw.com> References: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> <67e67230-cac7-d940-1cca-6ab4e8cba8d4@redhat.com> <9e792a33-4f90-8829-2f7b-158d07d3fd15@bell-sw.com> Message-ID: On 18/08/2020 16:05, Dmitry Chuyko wrote: > Some more results for a benchmark with reduce(): > > -XX:-UseSignumIntrinsic > DoubleOrigSignum.ofMostlyNaN 0.914 ? 0.001 ns/op > DoubleOrigSignum.ofMostlyNeg 1.178 ? 0.001 ns/op > DoubleOrigSignum.ofMostlyPos 1.176 ? 0.017 ns/op > DoubleOrigSignum.ofMostlyZero 0.803 ? 0.001 ns/op > DoubleOrigSignum.ofRandom 1.175 ? 0.012 ns/op > -XX:+UseSignumIntrinsic > DoubleOrigSignum.ofMostlyNaN 1.040 ? 0.007 ns/op > DoubleOrigSignum.ofMostlyNeg 1.040 ? 0.004 ns/op > DoubleOrigSignum.ofMostlyPos 1.039 ? 0.003 ns/op > DoubleOrigSignum.ofMostlyZero 1.040 ? 0.001 ns/op > DoubleOrigSignum.ofRandom 1.040 ? 0.003 ns/op That's almost no difference, isn't it? Down in the noise. > If we only intrinsify copySign() we lose free mask that we get from > facgt. In such case improvement (for signum) decreases like from ~30% to > ~15%, and it also greatly depends on the particular HW. We can > additionally introduce an intrinsic for Math.copySign(), especially it > makes sense for float where it can be just 2 fp instructions: movi+bsl > (fmovd+fnegd+bsl for double). I think this is worth doing, because moves between GPRs and vector regs tend to have a long latency. Can you please add that, and we can all try it on our various hardware. We're measuring two different things, throughput and latency. The first JMH test you provided was really testing latency, because Blackhole waits for everything to complete. [ Note to self: Blackhole.consume() seems to be particularly slow on some AArch64 implementations because it uses a volatile read. What seems to be happening, judging by how long it takes, is that the store buffer is drained before the volatile read. Maybe some other construct would work better but still provide the guarantees Blackhole.consume() needs. ] For throughput we want to keep everything moving. Sure, sometimes we are going to have to wait for some calculation to complete, so if we can improve latency without adverse cost we should. For that, staying in the vector regs helps. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From akozlov at azul.com Wed Aug 19 08:55:47 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 19 Aug 2020 11:55:47 +0300 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> Message-ID: Hi Bernhard, On 18.08.2020 22:43, Bernhard Urban-Forster wrote: > I applied your patch on my WIP branch for aarch64-darwin and it builds for me as well. Just a small comment: With JDK-8248414 [1] we tried to eliminate many unsigned long/long usages, since "unsigned long" ends up with different bittness on LLP64 (Windows) vs. LP64 (Linux, macOS, etc.). So I would suggest to add overloads using the [u]int{32,64}_t + [u]intptr_t types instead, which adds a bit more clarity imho. I also would like to have explicit overloads for int32_t/64_t/intptr_t, but as I wrote it creates another issue. Consider a valid set of system types for LP64 (I think there are valid sets for LLP64 demonstrating the same): typedef int int32_t; typedef long int int64_t; typedef long int intptr_t; then mov(Register, int64_t) { /* overload 1 */ } mov(Register, intptr_t) { /* overload 2 */ } are multiple overloads for same the same set of arguments, so it won't compile. I don't like introducing fundamental types again too. But the patch treats both (long) and (long long) uniformly, so the code should work for LLP64 as well as for LP64. It was really surprising for me, how smooth the work went and why hadn't you solved the same problems in the latest JEP 388 patch, until I found 8248414 :-) These bugs are linked in JBS. Thanks, Anton From aph at redhat.com Wed Aug 19 08:45:18 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 09:45:18 +0100 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> Message-ID: <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> On 18/08/2020 16:21, Anton Kozlov wrote: > Extra method overloads with for int, long, ... are added to catch > all (suitable) types used for intptr_t, int64_t. Now there are > overloads only for int (for literal values) and int64, latter > usually shares a fundamental type with intptr. The new toolchain > provides different types for int64 and intptr. Well, that's very silly. Out of interest, what is the fundamental type? Or are they compiler builtins? > Then both overloads are not perfect for an intptr argument but > possible, so compilation is failed. Providing additional overload > for intptr fixes compilation on new toolchain but breaks linux, as > intptr and int64 are different overloads for essentially the same > type. I wonder what ISO C++ says about all of this. We are in danger of turning the code into an effectively unmaintainable mess because a Linux programmer makes a change, it breaks Darwin, and vice versa. Are there any compiler flags that might help here? > Another approach is to leave a single overload for integer type, but > literal integer could still be ambiguously promoted to e.g. pointer > or int64. So every user will have to explicitly cast literal > integers to a certain type. Maybe a template function for mov() ? Be careful with sign extension. We want to make sure mov(reg, -1) works correctly. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From akozlov at azul.com Wed Aug 19 09:42:39 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 19 Aug 2020 12:42:39 +0300 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> Message-ID: <907599c1-6040-2727-1bd1-239400827d3c@azul.com> On 19.08.2020 11:45, Andrew Haley wrote: > On 18/08/2020 16:21, Anton Kozlov wrote: > >> Extra method overloads with for int, long, ... are added to catch >> all (suitable) types used for intptr_t, int64_t. Now there are >> overloads only for int (for literal values) and int64, latter >> usually shares a fundamental type with intptr. The new toolchain >> provides different types for int64 and intptr. > > Well, that's very silly. Out of interest, what is the fundamental > type? Or are they compiler builtins? I mean int, long, long long, ... [1] intptr_t,int32_t,int64_t are usually typedef's of int,long,... Overloads operating on compiler (fundamental) types, not results of typedef. > >> Then both overloads are not perfect for an intptr argument but >> possible, so compilation is failed. Providing additional overload >> for intptr fixes compilation on new toolchain but breaks linux, as >> intptr and int64 are different overloads for essentially the same >> type. > > I wonder what ISO C++ says about all of this. We are in danger of > turning the code into an effectively unmaintainable mess because a > Linux programmer makes a change, it breaks Darwin, and vice versa. > > Are there any compiler flags that might help here? I don't think there is a flag for that. Once we provided an overload for (address) and e.g (int64_t), we need the rest set of overloads to capture (int) for literals, (intptr) that may be a type unrelated to (int64_t)... The process converges, I think. The provided overloads for mov() and Address() are reasonable upper bound. The only possibility to break a build is to call another function that provides some but not all overloads with an argument of a new type. The user will have to choose to cast the argument or to introduce overload. At the worst case, we would have a set of overloads for few widely used functions, following the pattern from this patch. I think there is always a chance to break a build by changing shared code, and cpu/aarch64 is becoming such. Fortunately, build failures are easy to detect and fix. > >> Another approach is to leave a single overload for integer type, but >> literal integer could still be ambiguously promoted to e.g. pointer >> or int64. So every user will have to explicitly cast literal >> integers to a certain type. > > Maybe a template function for mov() ? > > Be careful with sign extension. We want to make sure mov(reg, -1) > works correctly. > A template is interesting, it may save as a few lines and reduce the amount of choices to several. I'll try to do that. As for sign extension, that's why unsigned variants provided as well, so mov(r, -1) should choose mov(Register, int) and not mov(Register, unsigned int). Thanks, Anton [1] https://en.cppreference.com/w/cpp/language/types From ningsheng.jian at arm.com Wed Aug 19 09:53:45 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 19 Aug 2020 17:53:45 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: Hi Andrew, I have updated the patch based on the review comments. Would you mind taking another look? Thanks! Full: http://cr.openjdk.java.net/~njian/8231441/webrev.04/ Incremental: http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ Also add build-dev, as there's a makefile change. And the split parts: 1) SVE feature detection: http://cr.openjdk.java.net/~njian/8231441/webrev.04-feature 2) c2 register allocation: http://cr.openjdk.java.net/~njian/8231441/webrev.04-ra 3) SVE c2 backend: http://cr.openjdk.java.net/~njian/8231441/webrev.04-c2 Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 CSR: https://bugs.openjdk.java.net/browse/JDK-8248742 JTreg tests are still running, and so far no new failure found. Thanks, Ningsheng On 8/17/20 5:16 PM, Andrew Dinn wrote: > Hi Pengfei, > > On 17/08/2020 07:00, Ningsheng Jian wrote: >> Thanks a lot for the review! Sorry for the late reply, as I was on >> vacation last week. And thanks to Pengfei and Joshua for helping >> clarifying some details in the patch. > > Yes, they did a very good job of answering most of the pending questions. > >>> I also eyeballed /some/ of the generated code to check that it looked >>> ok. I'd really like to be able to do that systematically for a >>> comprehensive test suite that exercised every rule but I only had the >>> machine for a few days. This really ought to be done as a follow-up to >>> ensure that all the rules are working as expected. >> >> Yes, we would expect Pengfei's OptoAssembly check patch can get merged >> in future. > > I'm fine with that as a follow-up patch if you raise a JIRA for it. > >>> I am not clear why you are choosing to re-init ptrue after certain JVM >>> runtime calls (e.g. when Z calls into the runtime) and not others e.g. >>> when we call a JVM_ENTRY. Could you explain the rationale you have >>> followed here? >> >> We do the re-init at any possible return points to c2 code, not in any >> runtime c++ functions, which will reduce the re-init calls. >> >> Actually I found those entries by some hack of jvm. In the hacky code >> below we use gcc option -finstrument-functions to build hotspot. With >> this option, each C/C++ function entry/exit will call the instrument >> functions we defined. In instrument functions, we clobber p7 (or other >> reg for test) register, and in c2 function return we verify that p7 (or >> other reg) has been reinitialized. >> >> http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch > > Nice work. It's very good to have that documented. I'm willing to accept > i) that this has found all current cases and ii) that the verify will > catch any cases that might get introduced by future changes (e.g. the > callout introduced by ZGC that you mention below). As the above mot say > there is a slim chance this might have missed some cases but I think it > is pretty unlikely. > > >>> Specific Comments (register allocator webrev): >>> >>> >>> aarch64.ad:97-100 >>> >>> Why have you added a reg_def for R8 and R9 here and also to alloc_class >>> chunk0 at lines 544-545? They aren't used by C2 so why define them? >>> >> >> I think Pengfei has helped to explain that. I will either add clear >> comments or rename the register name as you suggested. > > Ok, good. > >> As Joshua clarified, we are also working on predicate scalable reg, >> which is not in this patch. Thanks for the suggestion, I will try to >> refactor this a bit. > > Ok, I'll wait for an updated patch. Are you planning to include the > scalable predicate reg code as part of this patch? I think that would be > better as it would help to clarify the need to distinguish vector regs > as a subset of scalable regs. > >>> zBarrierSetAssembler_aarch64.cpp:434 >>> >>> Can you explain why we need to check p7 here and not do so in other >>> places where we call into the JVM? I'm not saying this is wrong. I just >>> want to know how you decided where re-init of p7 was needed. >>> >> >> Actually I found this by my hack patch above while running jtreg tests. >> The stub slowpath here can be a c++ function. > > Yes, good catch. > >>> superword.cpp:97 >>> >>> Does this mean that is someone sets the maximum vector size to a >>> non-power of two, such as 384, all superword operations will be >>> bypassed? Including those which can be done using NEON vectors? >>> >> >> Current SLP vectorizer only supports power-of-2 vector size. We are >> trying to work out a new vectorizer to support all SVE vector sizes, so >> we would expect a size like 384 could go to that path. I tried current >> patch on a 512-bit SVE hardware which does not support 384-bit: >> >> $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) >> openjdk version "16-internal" 2021-03-16 >> >> $ java -XX:MaxVectorSize=48 -version >> OpenJDK 64-Bit Server VM warning: Current system only supports max SVE >> vector length 32. Set MaxVectorSize to 32 >> >> (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 >> instead of unsupported 48: >> https://www.kernel.org/doc/Documentation/arm64/sve.txt) >> >> Do you think we need to exit vm instead of warning and fallbacking to 32 >> here? > > Yes, I think a vm exit would probably be a better choice. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From magnus.ihse.bursie at oracle.com Wed Aug 19 10:05:01 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 19 Aug 2020 12:05:01 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> On 2020-08-19 11:53, Ningsheng Jian wrote: > Hi Andrew, > > I have updated the patch based on the review comments. Would you mind > taking another look? Thanks! > > Full: > http://cr.openjdk.java.net/~njian/8231441/webrev.04/ Build changes look good. Thank you for remembering to cc build-dev! This is maybe not relevant, but I was surprised to find src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, and b) the name implies that it is a test, even though that it resides in src. Is this really proper? /Magnus > > Incremental: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ > > Also add build-dev, as there's a makefile change. > > And the split parts: > > 1) SVE feature detection: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-feature > > 2) c2 register allocation: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-ra > > 3) SVE c2 backend: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-c2 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 > CSR: https://bugs.openjdk.java.net/browse/JDK-8248742 > > JTreg tests are still running, and so far no new failure found. > > Thanks, > Ningsheng > > On 8/17/20 5:16 PM, Andrew Dinn wrote: >> Hi Pengfei, >> >> On 17/08/2020 07:00, Ningsheng Jian wrote: >>> Thanks a lot for the review! Sorry for the late reply, as I was on >>> vacation last week. And thanks to Pengfei and Joshua for helping >>> clarifying some details in the patch. >> >> Yes, they did a very good job of answering most of the pending >> questions. >> >>>> I also eyeballed /some/ of the generated code to check that it looked >>>> ok. I'd really like to be able to do that systematically for a >>>> comprehensive test suite that exercised every rule but I only had the >>>> machine for a few days. This really ought to be done as a follow-up to >>>> ensure that all the rules are working as expected. >>> >>> Yes, we would expect Pengfei's OptoAssembly check patch can get merged >>> in future. >> >> I'm fine with that as a follow-up patch if you raise a JIRA for it. >> >>>> I am not clear why you are choosing to re-init ptrue after certain JVM >>>> runtime calls (e.g. when Z calls into the runtime) and not others e.g. >>>> when we call a JVM_ENTRY. Could you explain the rationale you have >>>> followed here? >>> >>> We do the re-init at any possible return points to c2 code, not in any >>> runtime c++ functions, which will reduce the re-init calls. >>> >>> Actually I found those entries by some hack of jvm. In the hacky code >>> below we use gcc option -finstrument-functions to build hotspot. With >>> this option, each C/C++ function entry/exit will call the instrument >>> functions we defined. In instrument functions, we clobber p7 (or other >>> reg for test) register, and in c2 function return we verify that p7 (or >>> other reg) has been reinitialized. >>> >>> http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch >>> >> >> Nice work. It's very good to have that documented. I'm willing to accept >> i) that this has found all current cases and ii) that the verify will >> catch any cases that might get introduced by future changes (e.g. the >> callout introduced by ZGC that you mention below). As the above mot say >> there is a slim chance this might have missed some cases but I think it >> is pretty unlikely. >> >> >>>> Specific Comments (register allocator webrev): >>>> >>>> >>>> aarch64.ad:97-100 >>>> >>>> Why have you added a reg_def for R8 and R9 here and also to >>>> alloc_class >>>> chunk0 at lines 544-545? They aren't used by C2 so why define them? >>>> >>> >>> I think Pengfei has helped to explain that. I will either add clear >>> comments or rename the register name as you suggested. >> >> Ok, good. >> >>> As Joshua clarified, we are also working on predicate scalable reg, >>> which is not in this patch. Thanks for the suggestion, I will try to >>> refactor this a bit. >> >> Ok, I'll wait for an updated patch. Are you planning to include the >> scalable predicate reg code as part of this patch? I think that would be >> better as it would help to clarify the need to distinguish vector regs >> as a subset of scalable regs. >> >>>> zBarrierSetAssembler_aarch64.cpp:434 >>>> >>>> Can you explain why we need to check p7 here and not do so in other >>>> places where we call into the JVM? I'm not saying this is wrong. I >>>> just >>>> want to know how you decided where re-init of p7 was needed. >>>> >>> >>> Actually I found this by my hack patch above while running jtreg tests. >>> The stub slowpath here can be a c++ function. >> >> Yes, good catch. >> >>>> superword.cpp:97 >>>> >>>> Does this mean that is someone sets the maximum vector size to a >>>> non-power of two, such as 384, all superword operations will be >>>> bypassed? Including those which can be done using NEON vectors? >>>> >>> >>> Current SLP vectorizer only supports power-of-2 vector size. We are >>> trying to work out a new vectorizer to support all SVE vector sizes, so >>> we would expect a size like 384 could go to that path. I tried current >>> patch on a 512-bit SVE hardware which does not support 384-bit: >>> >>> $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) >>> openjdk version "16-internal" 2021-03-16 >>> >>> $ java -XX:MaxVectorSize=48 -version >>> OpenJDK 64-Bit Server VM warning: Current system only supports max SVE >>> vector length 32. Set MaxVectorSize to 32 >>> >>> (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 >>> instead of unsupported 48: >>> https://www.kernel.org/doc/Documentation/arm64/sve.txt) >>> >>> Do you think we need to exit vm instead of warning and fallbacking >>> to 32 >>> here? >> >> Yes, I think a vm exit would probably be a better choice. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Red Hat Distinguished Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> > From beurba at microsoft.com Wed Aug 19 10:33:35 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Wed, 19 Aug 2020 10:33:35 +0000 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> , Message-ID: Argh, I only tried my suggestion on aarch64-darwin, but you are right, it causes issues on aarch64-linux and presumably on aarch64-win as well. Thanks for the explanation, -Bernhard ________________________________________ From: Anton Kozlov Sent: Wednesday, August 19, 2020 10:55 To: Bernhard Urban-Forster; hotspot-dev at openjdk.java.net Cc: aarch64-port-dev at openjdk.java.net; openjdk-aarch64 Subject: Re: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot Hi Bernhard, On 18.08.2020 22:43, Bernhard Urban-Forster wrote: > I applied your patch on my WIP branch for aarch64-darwin and it builds for me as well. Just a small comment: With JDK-8248414 [1] we tried to eliminate many unsigned long/long usages, since "unsigned long" ends up with different bittness on LLP64 (Windows) vs. LP64 (Linux, macOS, etc.). So I would suggest to add overloads using the [u]int{32,64}_t + [u]intptr_t types instead, which adds a bit more clarity imho. I also would like to have explicit overloads for int32_t/64_t/intptr_t, but as I wrote it creates another issue. Consider a valid set of system types for LP64 (I think there are valid sets for LLP64 demonstrating the same): typedef int int32_t; typedef long int int64_t; typedef long int intptr_t; then mov(Register, int64_t) { /* overload 1 */ } mov(Register, intptr_t) { /* overload 2 */ } are multiple overloads for same the same set of arguments, so it won't compile. I don't like introducing fundamental types again too. But the patch treats both (long) and (long long) uniformly, so the code should work for LLP64 as well as for LP64. It was really surprising for me, how smooth the work went and why hadn't you solved the same problems in the latest JEP 388 patch, until I found 8248414 :-) These bugs are linked in JBS. Thanks, Anton From ningsheng.jian at arm.com Wed Aug 19 10:40:49 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 19 Aug 2020 18:40:49 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> Message-ID: <4ec335ca-0a88-3b98-f6e4-fe7a0453ae7b@arm.com> Hi Magnus, Thanks for the review! On 8/19/20 6:05 PM, Magnus Ihse Bursie wrote: > On 2020-08-19 11:53, Ningsheng Jian wrote: >> Hi Andrew, >> >> I have updated the patch based on the review comments. Would you mind >> taking another look? Thanks! >> >> Full: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04/ > Build changes look good. Thank you for remembering to cc build-dev! > > This is maybe not relevant, but I was surprised to find > src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, > and b) the name implies that it is a test, even though that it resides > in src. Is this really proper? This handy script is used to (manually) generate some code in assembler_aarch64.cpp. The generated code is for assembler smoke test, so it named that. It's helpful to make sure the assembler emits correct binary code, but I am not sure whether a python code in the project is proper or not. Thanks, Ningsheng > > /Magnus >> >> Incremental: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ >> >> Also add build-dev, as there's a makefile change. >> >> And the split parts: >> >> 1) SVE feature detection: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-feature >> >> 2) c2 register allocation: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-ra >> >> 3) SVE c2 backend: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-c2 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 >> CSR: https://bugs.openjdk.java.net/browse/JDK-8248742 >> >> JTreg tests are still running, and so far no new failure found. >> >> Thanks, >> Ningsheng >> >> On 8/17/20 5:16 PM, Andrew Dinn wrote: >>> Hi Pengfei, >>> >>> On 17/08/2020 07:00, Ningsheng Jian wrote: >>>> Thanks a lot for the review! Sorry for the late reply, as I was on >>>> vacation last week. And thanks to Pengfei and Joshua for helping >>>> clarifying some details in the patch. >>> >>> Yes, they did a very good job of answering most of the pending >>> questions. >>> >>>>> I also eyeballed /some/ of the generated code to check that it looked >>>>> ok. I'd really like to be able to do that systematically for a >>>>> comprehensive test suite that exercised every rule but I only had the >>>>> machine for a few days. This really ought to be done as a follow-up to >>>>> ensure that all the rules are working as expected. >>>> >>>> Yes, we would expect Pengfei's OptoAssembly check patch can get merged >>>> in future. >>> >>> I'm fine with that as a follow-up patch if you raise a JIRA for it. >>> >>>>> I am not clear why you are choosing to re-init ptrue after certain JVM >>>>> runtime calls (e.g. when Z calls into the runtime) and not others e.g. >>>>> when we call a JVM_ENTRY. Could you explain the rationale you have >>>>> followed here? >>>> >>>> We do the re-init at any possible return points to c2 code, not in any >>>> runtime c++ functions, which will reduce the re-init calls. >>>> >>>> Actually I found those entries by some hack of jvm. In the hacky code >>>> below we use gcc option -finstrument-functions to build hotspot. With >>>> this option, each C/C++ function entry/exit will call the instrument >>>> functions we defined. In instrument functions, we clobber p7 (or other >>>> reg for test) register, and in c2 function return we verify that p7 (or >>>> other reg) has been reinitialized. >>>> >>>> http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch >>>> >>> >>> Nice work. It's very good to have that documented. I'm willing to accept >>> i) that this has found all current cases and ii) that the verify will >>> catch any cases that might get introduced by future changes (e.g. the >>> callout introduced by ZGC that you mention below). As the above mot say >>> there is a slim chance this might have missed some cases but I think it >>> is pretty unlikely. >>> >>> >>>>> Specific Comments (register allocator webrev): >>>>> >>>>> >>>>> aarch64.ad:97-100 >>>>> >>>>> Why have you added a reg_def for R8 and R9 here and also to >>>>> alloc_class >>>>> chunk0 at lines 544-545? They aren't used by C2 so why define them? >>>>> >>>> >>>> I think Pengfei has helped to explain that. I will either add clear >>>> comments or rename the register name as you suggested. >>> >>> Ok, good. >>> >>>> As Joshua clarified, we are also working on predicate scalable reg, >>>> which is not in this patch. Thanks for the suggestion, I will try to >>>> refactor this a bit. >>> >>> Ok, I'll wait for an updated patch. Are you planning to include the >>> scalable predicate reg code as part of this patch? I think that would be >>> better as it would help to clarify the need to distinguish vector regs >>> as a subset of scalable regs. >>> >>>>> zBarrierSetAssembler_aarch64.cpp:434 >>>>> >>>>> Can you explain why we need to check p7 here and not do so in other >>>>> places where we call into the JVM? I'm not saying this is wrong. I >>>>> just >>>>> want to know how you decided where re-init of p7 was needed. >>>>> >>>> >>>> Actually I found this by my hack patch above while running jtreg tests. >>>> The stub slowpath here can be a c++ function. >>> >>> Yes, good catch. >>> >>>>> superword.cpp:97 >>>>> >>>>> Does this mean that is someone sets the maximum vector size to a >>>>> non-power of two, such as 384, all superword operations will be >>>>> bypassed? Including those which can be done using NEON vectors? >>>>> >>>> >>>> Current SLP vectorizer only supports power-of-2 vector size. We are >>>> trying to work out a new vectorizer to support all SVE vector sizes, so >>>> we would expect a size like 384 could go to that path. I tried current >>>> patch on a 512-bit SVE hardware which does not support 384-bit: >>>> >>>> $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) >>>> openjdk version "16-internal" 2021-03-16 >>>> >>>> $ java -XX:MaxVectorSize=48 -version >>>> OpenJDK 64-Bit Server VM warning: Current system only supports max SVE >>>> vector length 32. Set MaxVectorSize to 32 >>>> >>>> (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 >>>> instead of unsupported 48: >>>> https://www.kernel.org/doc/Documentation/arm64/sve.txt) >>>> >>>> Do you think we need to exit vm instead of warning and fallbacking >>>> to 32 >>>> here? >>> >>> Yes, I think a vm exit would probably be a better choice. >>> >>> regards, >>> >>> >>> Andrew Dinn >>> ----------- >>> Red Hat Distinguished Engineer >>> Red Hat UK Ltd >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham, Michael ("Mike") O'Neill >>> >> > From aph at redhat.com Wed Aug 19 11:10:10 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 12:10:10 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> Message-ID: On 19/08/2020 11:05, Magnus Ihse Bursie wrote: > This is maybe not relevant, but I was surprised to find > src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, > and b) the name implies that it is a test, even though that it resides > in src. Is this really proper? I have no idea whether it's really proper, but it allows us to check that instructions are encoded correctly by cross-checking with the system's assembler. There might well be a more hygienic way to do that, but I don't want to be without it. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From akozlov at azul.com Wed Aug 19 13:10:21 2020 From: akozlov at azul.com (Anton Kozlov) Date: Wed, 19 Aug 2020 16:10:21 +0300 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: <907599c1-6040-2727-1bd1-239400827d3c@azul.com> References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> <907599c1-6040-2727-1bd1-239400827d3c@azul.com> Message-ID: On 19.08.2020 12:42, Anton Kozlov wrote: > On 19.08.2020 11:45, Andrew Haley wrote: >> On 18/08/2020 16:21, Anton Kozlov wrote: >>> Another approach is to leave a single overload for integer type, but >>> literal integer could still be ambiguously promoted to e.g. pointer >>> or int64. So every user will have to explicitly cast literal >>> integers to a certain type. >> >> Maybe a template function for mov() ? >> > > A template is interesting, it may save as a few lines and reduce the amount of > choices to several. I'll try to do that. > A template is complicated by the existing mov(Register, Address) overload. We need a single template to capture all integer types and the other template or overload to handle Address() and its subclasses. For example template inline void mov(Register dst, T imm) { mov_immediate64(dst, (uint64_t)imm); } void mov(Register dst, Address a); doesn't compile for mov(r0, RuntimeAddress()) without an explicit cast of RuntimeAddress to Address. With C++14, it is possible to avoid casts with use something like enable_if[1], so the code in macroassembler would look like template::value>* = nullptr> void mov(Register r, T imm) { ... } template::value>* = nullptr> void mov(Register r, T addr) { ... } Compared to the current patch, I don't think such template would be less error-prone or more maintainable. I would stick to the current version. Thanks, Anton [1] https://en.cppreference.com/w/cpp/types/enable_if From adinn at redhat.com Wed Aug 19 13:01:44 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 19 Aug 2020 14:01:44 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> Hi Ningsheng, On 19/08/2020 10:53, Ningsheng Jian wrote: > I have updated the patch based on the review comments. Would you mind > taking another look? Thanks! > > Full: > http://cr.openjdk.java.net/~njian/8231441/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ That looks ok. A few suggested tweaks: aarch64.ad:168 I think the following comment explains more clearly what is going on: // For SVE vector registers, we simply extend vector register size to 8 // 'logical' slots. This is nominally 256 bits but it actually covers // all possible 'physical' SVE vector register lengths from 128 ~ 2048 bits. // The 'physical' SVE vector register length is detected during startup // so the register allocator is able to identify the correct number of // bytes needed for an SVE spill/unspill. // Note that a vector register with 4 slots, denotes a 128-bit NEON // register allowing it to be distinguished from the // corresponding SVE vector register when the SVE vector length // is 128 bits. postaloc.cpp:312 & 322 311 if (lrgs(val_idx).is_scalable()) { 312 assert(val->ideal_reg() == Op_VecA, "scalable vector register"); . . . 321 if (lrgs(val_idx).is_scalable()) { 322 assert(val->ideal_reg() == Op_VecA, "scalable vector register"); You don't strictly need the asserts here as this is already asserted in the call to is_scalable(). > JTreg tests are still running, and so far no new failure found. Ok, well assuming they pass I am happy with this latest patch modulo the tweaks above. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Wed Aug 19 17:03:24 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 19 Aug 2020 18:03:24 +0100 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> <907599c1-6040-2727-1bd1-239400827d3c@azul.com> Message-ID: On 19/08/2020 14:10, Anton Kozlov wrote: > With C++14, it is possible to avoid casts with use something like enable_if[1], > so the code in macroassembler would look like > > template::value>* = nullptr> > void mov(Register r, T imm) { ... } > > template::value>* = nullptr> > void mov(Register r, T addr) { ... } > > Compared to the current patch, I don't think such template would be less > error-prone or more maintainable. I would stick to the current version. OK. I rather like the template version: it's clear to me what the intention is. But I agree it's marginal. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From beurba at microsoft.com Wed Aug 19 21:52:15 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Wed, 19 Aug 2020 21:52:15 +0000 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: Hello everyone, here is an updated changeset: http://cr.openjdk.java.net/~burban/8248238/webrev.01/ I have: - rebased against current jdk tip (thus JDK-8248816 got removed from the changeset) - incorporated some review feedback on JDK-8248660 and JDK-8248663 - resolved merge conflicts around vm_version_aarch64.cpp and detection for SHA512 `aarch64-port/jdk-windows` will need another update from `jdk/jdk` before the changeset will apply cleanly. Thank you, -Bernhard ________________________________________ From: Bernhard Urban-Forster Sent: Friday, July 31, 2020 23:08 To: aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: 8248238: Implementation of JEP: Windows AArch64 Support Hi all, please consider importing the following changeset into `aarch64-port/jdk-windows`. JBS: https://bugs.openjdk.java.net/browse/JDK-8248238 Webrev: https://cr.openjdk.java.net/~burban/8248238 Thank you, Monica, Ludovic and Bernhard From ningsheng.jian at arm.com Thu Aug 20 02:27:08 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Thu, 20 Aug 2020 10:27:08 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> Message-ID: <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> Hi Andrew, On 8/19/20 9:01 PM, Andrew Dinn wrote: > Hi Ningsheng, > > On 19/08/2020 10:53, Ningsheng Jian wrote: >> I have updated the patch based on the review comments. Would you mind >> taking another look? Thanks! >> >> Full: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04/ >> >> Incremental: >> http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ > > That looks ok. A few suggested tweaks: > Thanks! > aarch64.ad:168 > > I think the following comment explains more clearly what is going on: > > // For SVE vector registers, we simply extend vector register size to 8 > // 'logical' slots. This is nominally 256 bits but it actually covers > // all possible 'physical' SVE vector register lengths from 128 ~ 2048 bits. > // The 'physical' SVE vector register length is detected during startup > // so the register allocator is able to identify the correct number of > // bytes needed for an SVE spill/unspill. > // Note that a vector register with 4 slots, denotes a 128-bit NEON > // register allowing it to be distinguished from the > // corresponding SVE vector register when the SVE vector length > // is 128 bits. > This looks better than mine. Thanks! :-) > postaloc.cpp:312 & 322 > > 311 if (lrgs(val_idx).is_scalable()) { > 312 assert(val->ideal_reg() == Op_VecA, "scalable vector register"); > > . . . > > 321 if (lrgs(val_idx).is_scalable()) { > 322 assert(val->ideal_reg() == Op_VecA, "scalable vector register"); > > You don't strictly need the asserts here as this is already asserted in > the call to is_scalable(). > The assertion in LRG::is_scalable() is different, while this is an assertion for ideal_reg of a given node. > >> JTreg tests are still running, and so far no new failure found. > Ok, well assuming they pass I am happy with this latest patch modulo the > tweaks above. > Will report back once the tests on real hardware passed. Thanks, Ningsheng From nick.gasson at arm.com Thu Aug 20 04:48:30 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 20 Aug 2020 12:48:30 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> Message-ID: <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> On 08/19/20 19:10 pm, Andrew Haley wrote: > On 19/08/2020 11:05, Magnus Ihse Bursie wrote: >> This is maybe not relevant, but I was surprised to find >> src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, >> and b) the name implies that it is a test, even though that it resides >> in src. Is this really proper? > > I have no idea whether it's really proper, but it allows us to check > that instructions are encoded correctly by cross-checking with the > system's assembler. There might well be a more hygienic way to do > that, but I don't want to be without it. It is perhaps a bit strange to have the test code under src/ and embedded in the assembler implementation. How about we move it under test/ using the existing gtest framework for native code tests? That runs in tier1 and also for release builds. I tried this just now and it's easy to do. -- Thanks, Nick From adinn at redhat.com Thu Aug 20 08:34:45 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Aug 2020 09:34:45 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> Message-ID: Hi Ningsheng, >> postaloc.cpp:312 & 322 >> >> 311???? if (lrgs(val_idx).is_scalable()) { >> 312?????? assert(val->ideal_reg() == Op_VecA, "scalable vector >> register"); >> >> ???????? . . . >> >> 321?????? if (lrgs(val_idx).is_scalable()) { >> 322???????? assert(val->ideal_reg() == Op_VecA, "scalable vector >> register"); >> >> You don't strictly need the asserts here as this is already asserted in >> the call to is_scalable(). > > The assertion in LRG::is_scalable() is different, while this is an > assertion for ideal_reg of a given node. Yes, my apologies for misreading that. These assertions should be retained. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Thu Aug 20 08:48:07 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Aug 2020 09:48:07 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> On 20/08/2020 05:48, Nick Gasson wrote: > On 08/19/20 19:10 pm, Andrew Haley wrote: >> On 19/08/2020 11:05, Magnus Ihse Bursie wrote: >>> This is maybe not relevant, but I was surprised to find >>> src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, >>> and b) the name implies that it is a test, even though that it resides >>> in src. Is this really proper? >> >> I have no idea whether it's really proper, but it allows us to check >> that instructions are encoded correctly by cross-checking with the >> system's assembler. There might well be a more hygienic way to do >> that, but I don't want to be without it. > > It is perhaps a bit strange to have the test code under src/ and > embedded in the assembler implementation. How about we move it under > test/ using the existing gtest framework for native code tests? That > runs in tier1 and also for release builds. I tried this just now and > it's easy to do. I'm not sure that would be an improvement. This python code is used to generate C code run as part of JVM startup in a debug JVM build i.e. code that is linked into the JVM itself. So, the code it generates is really the same as the debug code embedded in the JVM. It doesn't really bear any relation to the code in the test tree. If the generator code were to go anywhere else it would perhaps make most sense to put it in the make tree. I'm not sure that is required though or even appropriate. There is already a precedent for keeping generator code in the source tree and, when it is specific to a given arch, keeping it next to the related source. The adlc generator code sits in the shared source tree. The m4 file used to generate parts of aarch64.ad is in the aarch64 source tree. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Thu Aug 20 08:50:32 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Aug 2020 09:50:32 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <47a0b915-291d-7bee-c298-a85d57b1c3a7@redhat.com> <01299e5a-8786-bd78-83f4-5e7f900f96da@arm.com> Message-ID: <7a12ad31-9196-c724-16c9-9994b096974c@redhat.com> On 20/08/2020 03:27, Ningsheng Jian wrote: > // Note that a vector register with 4 slots, denotes a 128-bit NEON Lose the comma. :-) Never known to miss a trivial point, -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Thu Aug 20 08:53:52 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Aug 2020 09:53:52 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <6fea2144-b416-cad3-8c99-068a82490256@redhat.com> On 20/08/2020 05:48, Nick Gasson wrote: > On 08/19/20 19:10 pm, Andrew Haley wrote: >> On 19/08/2020 11:05, Magnus Ihse Bursie wrote: >>> This is maybe not relevant, but I was surprised to find >>> src/hotspot/cpu/aarch64/aarch64-asmtest.py, because a) it's python code, >>> and b) the name implies that it is a test, even though that it resides >>> in src. Is this really proper? >> >> I have no idea whether it's really proper, but it allows us to check >> that instructions are encoded correctly by cross-checking with the >> system's assembler. There might well be a more hygienic way to do >> that, but I don't want to be without it. > > It is perhaps a bit strange to have the test code under src/ and > embedded in the assembler implementation. How about we move it under > test/ using the existing gtest framework for native code tests? That > runs in tier1 and also for release builds. I tried this just now and > it's easy to do. Go on, then! Bear in mind that the idea of this test is that it checks the encoding of all instructions, regardless of whether the processor supports them or not. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Thu Aug 20 08:58:57 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 20 Aug 2020 16:58:57 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> Message-ID: <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> Hi Andrew, On 08/20/20 16:48 pm, Andrew Dinn wrote: >> >> It is perhaps a bit strange to have the test code under src/ and >> embedded in the assembler implementation. How about we move it under >> test/ using the existing gtest framework for native code tests? That >> runs in tier1 and also for release builds. I tried this just now and >> it's easy to do. > I'm not sure that would be an improvement. This python code is used to > generate C code run as part of JVM startup in a debug JVM build i.e. > code that is linked into the JVM itself. So, the code it generates is > really the same as the debug code embedded in the JVM. It doesn't really > bear any relation to the code in the test tree. > I meant move the test itself - entry() and asm_check() in assembler_aarch64.cpp - under test/hotspot/gtest. The generator would move with it. > If the generator code were to go anywhere else it would perhaps make > most sense to put it in the make tree. I'm not sure that is required > though or even appropriate. There is already a precedent for keeping > generator code in the source tree and, when it is specific to a given > arch, keeping it next to the related source. The adlc generator code > sits in the shared source tree. The m4 file used to generate parts of > aarch64.ad is in the aarch64 source tree. > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Thu Aug 20 09:08:18 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Aug 2020 10:08:18 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: Hi, On 20/08/2020 09:58, Nick Gasson wrote: > > On 08/20/20 16:48 pm, Andrew Dinn wrote: >>> >>> It is perhaps a bit strange to have the test code under src/ and >>> embedded in the assembler implementation. How about we move it under >>> test/ using the existing gtest framework for native code tests? That >>> runs in tier1 and also for release builds. I tried this just now and >>> it's easy to do. >> I'm not sure that would be an improvement. This python code is used to >> generate C code run as part of JVM startup in a debug JVM build i.e. >> code that is linked into the JVM itself. So, the code it generates is >> really the same as the debug code embedded in the JVM. It doesn't really >> bear any relation to the code in the test tree. > > I meant move the test itself - entry() and asm_check() in > assembler_aarch64.cpp - under test/hotspot/gtest. The generator would > move with it. Hmm. I'm still not sure how this would work. Let's see the patch and we can talk about it. It still sounds to me rather like pointlessly moving the furniture around. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From nick.gasson at arm.com Thu Aug 20 09:40:34 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 20 Aug 2020 17:40:34 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> On 08/20/20 17:08 pm, Andrew Haley wrote: >> >> I meant move the test itself - entry() and asm_check() in >> assembler_aarch64.cpp - under test/hotspot/gtest. The generator would >> move with it. > > Hmm. I'm still not sure how this would work. Let's see the patch and > we can talk about it. It still sounds to me rather like pointlessly > moving the furniture around. http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ Then you'd run it with make exploded-test TEST="gtest:AssemblerAArch64" The downside is that it won't run on every startup of a debug build, but it will run in the tier1 tests, including for release builds, which arguably gives more coverage. It looks a lot tidier to me, but that's clearly subjective. -- Thanks, Nick From magnus.ihse.bursie at oracle.com Thu Aug 20 10:14:36 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Aug 2020 12:14:36 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> Message-ID: <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> On 2020-08-20 11:40, Nick Gasson wrote: > On 08/20/20 17:08 pm, Andrew Haley wrote: >>> I meant move the test itself - entry() and asm_check() in >>> assembler_aarch64.cpp - under test/hotspot/gtest. The generator would >>> move with it. >> Hmm. I'm still not sure how this would work. Let's see the patch and >> we can talk about it. It still sounds to me rather like pointlessly >> moving the furniture around. > http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ > > Then you'd run it with > > make exploded-test TEST="gtest:AssemblerAArch64" > > The downside is that it won't run on every startup of a debug build, but > it will run in the tier1 tests, including for release builds, which > arguably gives more coverage. It looks a lot tidier to me, but that's > clearly subjective. FWIW, it definitely looks tidier to me too. /Magnus > > -- > Thanks, > Nick From adinn at redhat.com Thu Aug 20 10:38:32 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 20 Aug 2020 11:38:32 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> Message-ID: <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> On 20/08/2020 11:14, Magnus Ihse Bursie wrote: > On 2020-08-20 11:40, Nick Gasson wrote: >> http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ >> >> Then you'd run it with >> >> ?? make exploded-test TEST="gtest:AssemblerAArch64" >> >> The downside is that it won't run on every startup of a debug build, but >> it will run in the tier1 tests, including for release builds, which >> arguably gives more coverage. It looks a lot tidier to me, but that's >> clearly subjective. > FWIW, it definitely looks tidier to me too. Well, perhaps this check ought to be done as a standalone test rather than as debug build validation. I don't really have any deep commitment either way. However, if we do proceed with this I think it ought to be in a separate follow-up patch and with its own JIRA. It should not stop Ningsheng's SVE patch going in as is since that merely corrects the status quo to allow for SVE instructions. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From shade at redhat.com Thu Aug 20 12:02:02 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Aug 2020 14:02:02 +0200 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: Message-ID: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> On 8/19/20 11:52 PM, Bernhard Urban-Forster wrote: > Hello everyone, > > here is an updated changeset: > http://cr.openjdk.java.net/~burban/8248238/webrev.01/ Looking briefly: *) make/autoconf/jvm-features.m4: are we sure Shenandoah does not work with Windows AArch64? I don't think there should be a problem with it. I also see there are Shenandoah-related changes elsewhere, so I assume it was built at some time? *) src/hotspot/cpu/aarch64/aarch64.ad: are these needed? 993 #include "gc/shared/barrierSet.hpp" 994 #include "gc/shared/barrierSetAssembler.hpp" *) src/hotspot/share/runtime/vm_version.hpp: new includes in the .hpp file? Wouldn't it be better to do them in the relevant compilation units? 28 #include "memory/allocation.hpp" 29 #include "utilities/ostream.hpp" None of this blocks the push to staging repository, but maybe consider following up on these going forward? -- Thanks, -Aleksey From vladimir.x.ivanov at oracle.com Thu Aug 20 12:29:27 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 20 Aug 2020 15:29:27 +0300 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> Message-ID: <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> Hi Ningsheng, > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-July/039289.html Impressive work, Ningsheng! > http://cr.openjdk.java.net/~njian/8231441/README-RFR.txt "Since the bottom 128 bits are shared with the NEON, we extend current register mask definition of V0-V31 registers. Currently, c2 uses one bit mask for a 32-bit register slot, so to define at most 2048 bits we will need to add 64 slots in AD file. That's a really large number, and will also break current regmask assumption." Can you, please, elaborate on the last point? What RegMask assumptions are broken for 2048-bit vectors? I'm looking at [1] and try to understand the motivation for the changes in shared code. Compared to x86 w/ AVX512, architectural state for vector registers is 4x larger in the worst case (ignoring predicate registers for now). Here are the relevant constants on x86: gensrc/adfiles/adGlobals_x86.hpp: // the number of reserved registers + machine registers. #define REG_COUNT 545 ... // Size of register-mask in ints #define RM_SIZE 22 My estimate is that for AArch64 with SVE support the constants will be: REG_COUNT < 2500 RM_SIZE < 100 which don't look too bad. Also, I don't see any changes related to stack management. So, I assume it continues to be managed in slots. Any problems there? As I understand, wide SVE registers are caller-save, so there may be many spills of huge vectors around a call. (Probably, not possible with C2 auto-vectorizer as it is now, but Vector API will expose it.) Have you noticed any performance problems? If that's the case, then AVX512 support on x86 would benefit from similar optimization as well. FTR there was a similar exercise [2] on x86 to abstract away exact sizes of vector registers, but it didn't have to worry about RA since all the operands were already available. Also, vectors of all different sizes may be used. So, it makes it hard to compare. Best regards, Vladimir Ivanov [1] http://cr.openjdk.java.net/~njian/8231441/webrev.03-ra/ [2] https://bugs.openjdk.java.net/browse/JDK-8230015 > On 7/30/20 7:26 PM, Andrew Dinn wrote: >> Hi Ningsheng, >> >> I will start to review this either later today or (more likely) >> tomorrow. It will probably take some time to work through it all. I will >> work from the updated patch posted by PengFei. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Red Hat Distinguished Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> >> On 21/07/2020 07:05, Ningsheng Jian wrote: >>> [Ping] >>> >>> Could anyone please help to review this patch, especially for the c2 >>> register allocation part? >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8231441 >>> >>> The latest webrev: >>> http://cr.openjdk.java.net/~njian/8231441/webrev.02 >>> >>> In the latest webrev, we block one predicate register (p7) with all >>> elements preset to TRUE, so that c2 compiled code can use it freely to >>> generate instructions for unpredicated operations. >>> >>> And the split parts: >>> >>> 1) SVE feature detection: >>> http://cr.openjdk.java.net/~njian/8231441/webrev.02-feature >>> >>> 2) c2 register allocation: >>> http://cr.openjdk.java.net/~njian/8231441/webrev.02-ra >>> >>> 3) SVE c2 backend: >>> http://cr.openjdk.java.net/~njian/8231441/webrev.02-c2 >>> >>> The initial RFR which has some descriptions of the patch: >>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-March/037628.html >>> >>> >>> >>> The description can also be found at: >>> http://cr.openjdk.java.net/~njian/8231441/README-RFR.txt >>> >>> Notes to verify the patch on QEMU user emulation, with an example of >>> compiled code: >>> http://cr.openjdk.java.net/~njian/8231441/running-sve-in-qemu-user.txt >>> >>> Thanks, >>> Ningsheng >>> >>> >>> On 5/27/20 3:23 PM, Ningsheng Jian wrote: >>>> Hi, >>>> >>>> I have rebased this patch with some more comments added. And also >>>> relaxed the instruction matching conditions for 128-bit vector. >>>> >>>> I would appreciate if someone could help to review this. >>>> >>>> Whole patch: >>>> http://cr.openjdk.java.net/~njian/8231441/webrev.01 >>>> >>>> Different parts of changes: >>>> >>>> 1) SVE feature detection >>>> http://cr.openjdk.java.net/~njian/8231441/webrev.01-feature >>>> >>>> 2) c2 registion allocation >>>> http://cr.openjdk.java.net/~njian/8231441/webrev.01-ra >>>> >>>> 3) SVE c2 backend >>>> http://cr.openjdk.java.net/~njian/8231441/webrev.01-c2 >>>> >>>> (Or should I split this into different JBS?) >>>> >>>> Thanks, >>>> Ningsheng >>>> >>>> On 3/25/20 2:37 PM, Ningsheng Jian wrote: >>>>> Hi, >>>>> >>>>> Could you please help to review this patch adding AArch64 SVE support? >>>>> It also touches c2 compiler shared code. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 >>>>> Webrev: http://cr.openjdk.java.net/~njian/8231441/webrev.00 >>>>> >>>>> Arm has released new vector ISA extension for AArch64, SVE [1] and >>>>> SVE2 [2]. This patch adds the initial SVE support in OpenJDK. In this >>>>> patch we have: >>>>> >>>>> 1) SVE feature enablement and detection >>>>> 2) SVE vector register allocation support with initial predicate >>>>> register definition >>>>> 3) SVE c2 backend for current SLP based vectorizer. (We also have a >>>>> POC >>>>> patch of a new vectorizer using SVE predicate-driven loop control, but >>>>> that's still under development.) >>>>> >>>>> SVE register definition >>>>> ======================= >>>>> Unlike other SIMD architectures, SVE allows hardware >>>>> implementations to >>>>> choose a vector register length from 128 and 2048 bits, multiple of >>>>> 128 >>>>> bits. So we introduce a new vector type VectorA, i.e. length agnostic >>>>> (scalable) vector type, and Op_VecA for machine vectora register. >>>>> In the >>>>> meantime, to minimize register allocation code changes, we also take >>>>> advantage of one JIT compiler aspect, that is during the compile >>>>> time we >>>>> actually know the real hardware SVE vector register size of current >>>>> running machine. So, the register allocator actually knows how many >>>>> register slots an Op_VecA ideal reg requires, and could work fine >>>>> without much modification. >>>>> >>>>> Since the bottom 128 bits are shared with the NEON, we extend current >>>>> register mask definition of V0-V31 registers. Currently, c2 uses >>>>> one bit >>>>> mask for a 32-bit register slot, so to define at most 2048 bits we >>>>> will >>>>> need to add 64 slots in AD file. That's a really large number, and >>>>> will >>>>> also break current regmask assumption. Considering the SVE vector >>>>> register is architecturally scalable for different sizes, we just >>>>> define >>>>> double of original NEON vector register slots, i.e. 8 slots: Vx, Vx_H, >>>>> Vx_J ... Vx_O. After adlc, the generated register masks now looks >>>>> like: >>>>> >>>>> const RegMask _VECTORA_REG_mask( 0x0, 0x0, 0xffffffff, 0xffffffff, >>>>> 0xffffffff, 0xffffffff, 0xffffffff, 0xffffffff, ... >>>>> >>>>> const RegMask _VECTORD_REG_mask( 0x0, 0x0, 0x3030303, 0x3030303, >>>>> 0x3030303, 0x3030303, 0x3030303, 0x3030303, ... >>>>> >>>>> const RegMask _VECTORX_REG_mask( 0x0, 0x0, 0xf0f0f0f, 0xf0f0f0f, >>>>> 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, 0xf0f0f0f, ... >>>>> >>>>> And we use SlotsPerVecA to indicate regmask bit size for a VecA >>>>> register. >>>>> >>>>> Although for physical register allocation, register allocator does not >>>>> need to know the real VecA register size, while doing spill/unspill, >>>>> current register allocation needs to know actual stack slot size to >>>>> store/load VecA registers. SVE is able to do vector size agnostic >>>>> spilling, but to minimize the code changes, as I mentioned before, we >>>>> just let RA know the actual vector register size in current running >>>>> machine, by calling scalable_vector_reg_size(). >>>>> >>>>> In the meantime, since some vector operations do not have unpredicated >>>>> SVE1 instructions, but only predicate version, e.g. vector multiply, >>>>> vector load/store. We have also defined predicate registers in this >>>>> patch, and c2 register allocator will allocate a temp predicate >>>>> register >>>>> to fulfill the expecting unpredicated operations. And this can also be >>>>> used for future predicate-driven vectorizer. This is not efficient for >>>>> now, as we can see many ptrue instructions in the generated code. One >>>>> possible solution I can see, is to block one predicate register, and >>>>> preset it to all true. But to preserve/reinitialize a caller save >>>>> register value cross calls seems risky to work in this patch. I decide >>>>> to defer it to further optimization work. If anyone has any >>>>> suggestions >>>>> on this, I would appreciate. >>>>> >>>>> SVE feature detection >>>>> ===================== >>>>> Since we may have some compiled code based on the initial detected SVE >>>>> vector register length and the compiled code is compiled only for that >>>>> vector register length, we assume that the SVE vector register length >>>>> will not be changed during the JVM lifetime. However, SVE vector >>>>> length >>>>> is per-thread and can be changed by system call [3], so we need to >>>>> make >>>>> sure that each jni call will not change the sve vector length. >>>>> >>>>> Currently, we verify the SVE vector register length on each JNI >>>>> return, >>>>> and if an SVE vector length change is detected, jvm simply reports >>>>> error >>>>> and stops running. The VM running vector length can also be set by >>>>> existing VM option MaxVectorSize with c2 enabled. If MaxVectorSize is >>>>> specified not the same as system default sve vector length (in >>>>> /proc/sys/abi/sve_default_vector_length), JVM will set current process >>>>> sve vector length to the specified vector length. >>>>> >>>>> Compiled code >>>>> ============= >>>>> We have added all current c2 backend codegen on par with NEON, but >>>>> only >>>>> for vector length larger than 128-bit. >>>>> >>>>> On a 1024 bit SVE environment, for the following simple loop with int >>>>> array element type: >>>>> >>>>> ???? for (int i = 0; i < LENGTH; i++) { >>>>> ?????? c[i] = a[i] + b[i]; >>>>> ???? } >>>>> >>>>> c2 generated loop: >>>>> >>>>> ???? 0x0000ffff811c0820:?? sbfiz?? x11, x10, #2, #32 >>>>> ???? 0x0000ffff811c0824:?? add???? x13, x18, x11 >>>>> ???? 0x0000ffff811c0828:?? add???? x14, x1, x11 >>>>> ???? 0x0000ffff811c082c:?? add???? x13, x13, #0x10 >>>>> ???? 0x0000ffff811c0830:?? add???? x14, x14, #0x10 >>>>> ???? 0x0000ffff811c0834:?? add???? x11, x0, x11 >>>>> ???? 0x0000ffff811c0838:?? add???? x11, x11, #0x10 >>>>> ???? 0x0000ffff811c083c:?? ptrue?? p1.s??? // To be optimized >>>>> ???? 0x0000ffff811c0840:?? ld1w??? {z16.s}, p1/z, [x14] >>>>> ???? 0x0000ffff811c0844:?? ptrue?? p0.s >>>>> ???? 0x0000ffff811c0848:?? ld1w??? {z17.s}, p0/z, [x13] >>>>> ???? 0x0000ffff811c084c:?? add???? z16.s, z17.s, z16.s >>>>> ???? 0x0000ffff811c0850:?? ptrue?? p1.s >>>>> ???? 0x0000ffff811c0854:?? st1w??? {z16.s}, p1, [x11] >>>>> ???? 0x0000ffff811c0858:?? add???? w10, w10, #0x20 >>>>> ???? 0x0000ffff811c085c:?? cmp???? w10, w12 >>>>> ???? 0x0000ffff811c0860:?? b.lt??? 0x0000ffff811c0820 >>>>> >>>>> Test >>>>> ==== >>>>> Currently, we don't have real hardware to verify SVE features (and >>>>> performance). But we have run jtreg tests with SVE in some >>>>> emulators. On >>>>> QEMU system emulator, which has SVE emulation support, jtreg tier1-3 >>>>> passed with different vector sizes. We've also verified it with full >>>>> jtreg tests without SVE on both x86 and AArch64, to make sure that >>>>> there's no regression. >>>>> >>>>> The patch has also been applied to Vector API code base, and >>>>> verified on >>>>> emulator. In Vector API, there are more vector related tests and is >>>>> more >>>>> possible to generate vector instructions by intrinsification. >>>>> >>>>> A simple test can also run in QEMU user emulation, e.g. >>>>> >>>>> $ qemu-aarch64 -cpu max,sve-max-vq=2 java -XX:UseSVE=1 SIMD >>>>> >>>>> ( >>>>> To run it in user emulation mode, we will need to bypass SVE feature >>>>> detection code in this patch. E.g. apply: >>>>> http://cr.openjdk.java.net/~njian/8231441/user-emulation.patch >>>>> )l >>>>> >>>>> Others >>>>> ====== >>>>> Since this patch is a bit large, I've also split it into 3 parts, for >>>>> easy review: >>>>> >>>>> 1) SVE feature detection >>>>> http://cr.openjdk.java.net/~njian/8231441/webrev.00-feature >>>>> >>>>> 2) c2 registion allocation >>>>> http://cr.openjdk.java.net/~njian/8231441/webrev.00-ra >>>>> >>>>> 3) SVE c2 backend >>>>> http://cr.openjdk.java.net/~njian/8231441/webrev.00-c2 >>>>> >>>>> Part of this patch has been contributed by Joshua Zhu and Yang Zhang. >>>>> >>>>> Refs >>>>> ==== >>>>> [1] https://developer.arm.com/docs/ddi0584/latest >>>>> [2] https://developer.arm.com/docs/ddi0602/latest >>>>> [3] https://www.kernel.org/doc/Documentation/arm64/sve.txt >>>>> >>>>> Thanks, >>>>> Ningsheng >>>>> >>>> >>> >> > From shade at redhat.com Thu Aug 20 13:03:46 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Aug 2020 15:03:46 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252096: Shenandoah: adjust SerialPageShiftCount for x86_32 and JFR Message-ID: <1a01be59-1aa1-0631-ea54-87d7fd09c98f@redhat.com> Hi, Once I added bootcycle-images to x86_32 test configurations, this failure was discovered: # Internal Error (/home/shade/trunks/shenandoah-jdk8/hotspot/src/share/vm/runtime/os.cpp:1280), pid=490815, tid=0xf5fefb40 # assert(SerializePageShiftCount == count) failed: thread size changed, fix SerializePageShiftCount constant It happens when all three things hold true: - JFR is enabled at build time - Shenandoah is enabled at build time (i.e. the build config is not "minimal1") - 32-bit VM is being built Therefore, it only affects aarch64-port/jdk8u-shenandoah, and here is the minimal fix that adjusts the constant when all three things are in effect at the same time: diff -r ed70d5208f5f src/share/vm/utilities/globalDefinitions.hpp --- a/src/share/vm/utilities/globalDefinitions.hpp Mon Jun 22 20:26:02 2020 +0800 +++ b/src/share/vm/utilities/globalDefinitions.hpp Thu Aug 20 13:03:44 2020 +0200 @@ -143,12 +143,18 @@ // log2_intptr(sizeof(class JavaThread)) - log2_intptr(64); // see os::set_memory_serialize_page() #ifdef _LP64 const int SerializePageShiftCount = 4; #else +#if INCLUDE_JFR && INCLUDE_ALL_GCS +// JavaThread already has quite a few Shenandoah fields. Adding many JFR fields +// trips sizeof(JavaThread) > 1024. Need to adjust it here. +const int SerializePageShiftCount = 4; +#else const int SerializePageShiftCount = 3; #endif +#endif // An opaque struct of heap-word width, so that HeapWord* can be a generic // pointer into the heap. We require that object sizes be measured in // units of heap words, so that that // HeapWord* hw; Testing: Linux {x86_64, x86_32} x {zero, minimal1, server} x {default, jfr} bootcycle-images build -- Thanks, -Aleksey From aph at redhat.com Thu Aug 20 14:19:18 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 20 Aug 2020 15:19:18 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> Message-ID: <57d07f23-c0f1-31eb-586a-71fa59b80891@redhat.com> On 20/08/2020 11:38, Andrew Dinn wrote: > Well, perhaps this check ought to be done as a standalone test rather > than as debug build validation. I don't really have any deep commitment > either way. However, if we do proceed with this I think it ought to be > in a separate follow-up patch and with its own JIRA. It should not stop > Ningsheng's SVE patch going in as is since that merely corrects the > status quo to allow for SVE instructions. I agree. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From magnus.ihse.bursie at oracle.com Thu Aug 20 14:37:42 2020 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 20 Aug 2020 16:37:42 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <2d6e1fc5-d8f3-d046-325e-f07aa5f3cd83@oracle.com> <85blj5ylb5.fsf@nicgas01-pc.shanghai.arm.com> <301b8518-164d-b328-ed14-6aaa3b69b2ef@redhat.com> <857dtty9pq.fsf@nicgas01-pc.shanghai.arm.com> <85364hy7sd.fsf@nicgas01-pc.shanghai.arm.com> <39664366-1ba9-6eb1-dcee-c8a4f07877b7@oracle.com> <4ea979d6-c81f-fa3b-7c23-e563f52141dd@redhat.com> Message-ID: On 2020-08-20 12:38, Andrew Dinn wrote: > On 20/08/2020 11:14, Magnus Ihse Bursie wrote: >> On 2020-08-20 11:40, Nick Gasson wrote: >>> http://cr.openjdk.java.net/~ngasson/asmtest/webrev.0/ >>> >>> Then you'd run it with >>> >>> ?? make exploded-test TEST="gtest:AssemblerAArch64" >>> >>> The downside is that it won't run on every startup of a debug build, but >>> it will run in the tier1 tests, including for release builds, which >>> arguably gives more coverage. It looks a lot tidier to me, but that's >>> clearly subjective. >> FWIW, it definitely looks tidier to me too. > Well, perhaps this check ought to be done as a standalone test rather > than as debug build validation. I don't really have any deep commitment > either way. However, if we do proceed with this I think it ought to be > in a separate follow-up patch and with its own JIRA. It should not stop > Ningsheng's SVE patch going in as is since that merely corrects the > status quo to allow for SVE instructions. Yes, I fully agree, and never meant to imply anything else. /Magnus > > regards, > > > Andrew Dinn > ----------- > Red Hat Distinguished Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > From gnu.andrew at redhat.com Thu Aug 20 14:33:11 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 20 Aug 2020 14:33:11 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets Message-ID: <202008201433.07KEXB1r008313@aojmv0008.oracle.com> Changeset: 65124bf6fe1f Author: andrew Date: 2020-08-13 08:38 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/65124bf6fe1f Added tag jdk8u272-b03 for changeset eea7b1a818e9 ! .hgtags Changeset: f826380c857e Author: andrew Date: 2020-08-16 20:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/f826380c857e Merge jdk8u272-b03 ! .hgtags Changeset: 799ef14e9fd1 Author: andrew Date: 2020-08-16 20:49 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/799ef14e9fd1 Added tag aarch64-shenandoah-jdk8u272-b03 for changeset f826380c857e ! .hgtags From gnu.andrew at redhat.com Thu Aug 20 14:35:29 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 20 Aug 2020 14:35:29 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 3 new changesets Message-ID: <202008201435.07KEZTcW009628@aojmv0008.oracle.com> Changeset: 35842246f661 Author: andrew Date: 2020-08-13 08:38 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/35842246f661 Added tag jdk8u272-b03 for changeset 4e02b68de458 ! .hgtags Changeset: b716212328d1 Author: andrew Date: 2020-08-16 20:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/b716212328d1 Merge jdk8u272-b03 ! .hgtags Changeset: 7958dd03be50 Author: andrew Date: 2020-08-16 20:49 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/7958dd03be50 Added tag aarch64-shenandoah-jdk8u272-b03 for changeset b716212328d1 ! .hgtags From gnu.andrew at redhat.com Thu Aug 20 15:20:47 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 20 Aug 2020 16:20:47 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b04 Upstream Sync Message-ID: <20200820152047.GB3112706@stopbrexit> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/root/merge.changeset Changes in aarch64-shenandoah-jdk8u272-b04: - JDK-8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double - JDK-8177334: Update xmldsig implementation to Apache Santuario 2.1.1 - JDK-8203699: java/lang/invoke/SpecialInterfaceCall fails with SIGILL on aarch64 - JDK-8217878: ENVELOPING XML signature no longer works in JDK 11 - JDK-8218629: XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10 - JDK-8243138: Enhance BaseLdapServer to support starttls extended request Main issues of note: Clean merge (few HotSpot changes). JDK-8203699 is already upstream, and so appears as an uncredited change to src/cpu/aarch64/vm/macroAssembler_aarch64.cpp in the webrev. JDK-8247979 was added to the HotSpot repository after tagging, so a merge was necessary and this appears as an uncredited change to src/cpu/aarch64/vm/aarch64.ad. The change will be included in the next tag. diffstat for root b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for corba b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for jaxp b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for jaxws b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for langtools b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for nashorn b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diffstat for jdk a/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java | 687 - a/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AbstractSerializer.java | 249 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java | 157 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherData.java | 95 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherReference.java | 95 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherValue.java | 46 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/DocumentSerializer.java | 114 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedData.java | 46 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedKey.java | 113 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedType.java | 197 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java | 133 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java | 87 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java | 121 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java | 99 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java | 109 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Serializer.java | 77 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Transforms.java | 50 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java | 3539 ---------- a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherInput.java | 192 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherParameters.java | 86 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLEncryptionException.java | 80 a/src/share/classes/com/sun/org/apache/xml/internal/security/encryption/package.html | 25 a/src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/EncryptedKeyResolver.java | 150 a/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/keys/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/package.html | 36 a/src/share/classes/com/sun/org/apache/xml/internal/security/resource/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/signature/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementChecker.java | 41 a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java | 90 a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionElementProxy.java | 63 a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/package.html | 3 a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/package.html | 8 a/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/package.html | 8 b/.hgtags | 1 b/THIRD_PARTY_README | 2 b/src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java | 3 b/src/share/classes/com/sun/org/apache/xml/internal/security/Init.java | 157 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/Algorithm.java | 13 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/ClassLoaderUtils.java | 206 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java | 241 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java | 13 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java | 85 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithmSpi.java | 4 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/ECDSAUtils.java | 918 ++ b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java | 121 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java | 229 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java | 109 b/src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java | 274 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizationException.java | 25 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java | 113 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java | 40 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/ClassLoaderUtils.java | 84 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/InvalidCanonicalizerException.java | 20 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java | 3 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/C14nHelper.java | 8 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_OmitComments.java | 5 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_WithComments.java | 5 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java | 188 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java | 88 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclOmitComments.java | 4 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclWithComments.java | 4 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315OmitComments.java | 5 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315WithComments.java | 5 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java | 162 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerPhysical.java | 72 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java | 33 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java | 247 b/src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/XmlAttrStack.java | 412 + b/src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/AlgorithmAlreadyRegisteredException.java | 20 b/src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/Base64DecodingException.java | 21 b/src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityException.java | 51 b/src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityRuntimeException.java | 39 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/ContentHandlerAlreadyRegisteredException.java | 20 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java | 334 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyUtils.java | 5 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java | 38 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoContent.java | 1 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoReference.java | 32 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyName.java | 9 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyValue.java | 49 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/MgmtData.java | 9 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/PGPData.java | 9 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/RetrievalMethod.java | 38 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/SPKIData.java | 9 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/X509Data.java | 109 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/DSAKeyValue.java | 23 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/RSAKeyValue.java | 21 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509CRL.java | 8 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Certificate.java | 32 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509DataContent.java | 1 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Digest.java | 33 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509IssuerSerial.java | 16 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java | 33 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SubjectName.java | 11 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/ClassLoaderUtils.java | 84 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/InvalidKeyResolverException.java | 20 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java | 50 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverException.java | 24 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java | 51 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DEREncodedKeyValueResolver.java | 44 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DSAKeyValueResolver.java | 23 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/KeyInfoReferenceResolver.java | 115 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/PrivateKeyResolver.java | 85 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RSAKeyValueResolver.java | 27 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java | 147 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SecretKeyResolver.java | 35 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SingleKeyResolver.java | 50 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509CertificateResolver.java | 40 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509DigestResolver.java | 54 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509IssuerSerialResolver.java | 55 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SKIResolver.java | 33 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SubjectNameResolver.java | 53 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolver.java | 17 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverException.java | 25 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java | 88 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/KeyStoreResolver.java | 12 b/src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/SingleCertificateResolver.java | 8 b/src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml | 219 b/src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties | 254 b/src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties | 75 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidDigestValueException.java | 21 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidSignatureValueException.java | 21 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java | 145 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/MissingResourceFailureException.java | 73 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/NodeFilter.java | 8 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/ObjectContainer.java | 51 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java | 270 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/ReferenceNotInitializedException.java | 25 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperties.java | 48 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperty.java | 57 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignedInfo.java | 105 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java | 246 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureException.java | 25 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java | 103 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInputDebugger.java | 34 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceData.java | 2 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceNodeSetData.java | 14 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceOctetStreamData.java | 32 b/src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceSubTreeData.java | 8 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderUtils.java | 206 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/InvalidTransformException.java | 19 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java | 82 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformSpi.java | 7 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformationException.java | 25 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transforms.java | 111 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere.java | 4 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.java | 125 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N.java | 7 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11.java | 5 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11_WithComments.java | 5 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusive.java | 6 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusiveWithComments.java | 9 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NWithComments.java | 9 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformEnvelopedSignature.java | 9 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath.java | 19 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java | 36 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPointer.java | 3 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java | 66 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces.java | 41 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer.java | 57 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer04.java | 70 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathContainer.java | 28 b/src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathFilterCHGPContainer.java | 60 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java | 123 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java | 202 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/Constants.java | 12 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/DOMNamespaceContext.java | 10 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/DigesterOutputStream.java | 17 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java | 254 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionConstants.java | 204 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/HelperNodeList.java | 3 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/I18n.java | 28 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/IgnoreAllErrorHandler.java | 38 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/JDKXPathAPI.java | 15 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java | 89 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java | 30 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/Signature11ElementProxy.java | 16 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignatureElementProxy.java | 17 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignerOutputStream.java | 17 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncBufferedOutputStream.java | 131 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java | 30 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/WeakObjectPool.java | 118 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java | 308 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFactory.java | 4 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/XalanXPathAPI.java | 40 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ClassLoaderUtils.java | 84 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java | 99 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverException.java | 46 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java | 89 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverAnonymous.java | 18 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java | 115 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverFragment.java | 49 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverLocalFilesystem.java | 36 b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverXPointer.java | 33 b/src/share/classes/com/sun/org/slf4j/internal/Logger.java | 79 b/src/share/classes/com/sun/org/slf4j/internal/LoggerFactory.java | 33 b/src/share/classes/javax/xml/crypto/dsig/DigestMethod.java | 10 b/src/share/classes/javax/xml/crypto/dsig/SignatureMethod.java | 12 b/src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java | 16 b/src/share/classes/org/jcp/xml/dsig/internal/MacOutputStream.java | 2 b/src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java | 6 b/src/share/classes/org/jcp/xml/dsig/internal/dom/AbstractDOMSignatureMethod.java | 29 b/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java | 40 b/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java | 5 b/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java | 4 b/src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java | 40 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java | 6 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java | 5 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java | 7 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java | 53 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java | 22 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java | 71 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java | 5 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java | 19 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java | 80 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java | 110 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java | 53 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java | 16 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java | 200 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java | 53 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java | 95 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java | 163 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java | 96 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java | 427 + b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java | 55 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java | 47 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java | 125 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java | 5 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java | 11 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java | 45 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java | 11 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java | 138 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java | 101 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java | 31 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java | 94 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java | 140 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java | 50 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java | 30 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java | 10 b/src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java | 6 b/src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java | 34 b/src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java | 5 b/src/share/classes/sun/management/Flag.java | 1 b/src/share/classes/sun/management/HotSpotDiagnostic.java | 21 b/src/share/javavm/export/jmm.h | 5 b/src/share/native/sun/management/Flag.c | 16 b/test/com/sun/jndi/ldap/lib/BaseLdapServer.java | 83 b/test/com/sun/management/HotSpotDiagnosticMXBean/GetDoubleVMOption.java | 32 b/test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java | 11 b/test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java | 12 b/test/javax/xml/crypto/dsig/GenerationTests.java | 593 + b/test/javax/xml/crypto/dsig/KeySelectors.java | 34 b/test/javax/xml/crypto/dsig/data/envelope2.xml | 15 269 files changed, 8547 insertions(+), 12955 deletions(-) diffstat for hotspot b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- b/src/share/vm/services/jmm.h | 5 +++-- b/src/share/vm/services/management.cpp | 3 +++ b/test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java | 2 +- 5 files changed, 9 insertions(+), 4 deletions(-) Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le, aarch32 (Zero) & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Thu Aug 20 17:15:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 20 Aug 2020 19:15:44 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b04 Upstream Sync In-Reply-To: <20200820152047.GB3112706@stopbrexit> References: <20200820152047.GB3112706@stopbrexit> Message-ID: <50d99e3b-9082-0a05-d4f3-c12be10ee645@redhat.com> On 8/20/20 5:20 PM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/jdk/merge.changeset Whoa. Looks okay as far as I can see. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/root/merge.changeset Look trivially good. Ok to push. -Aleksey From ningsheng.jian at arm.com Fri Aug 21 07:56:19 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Fri, 21 Aug 2020 15:56:19 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> Message-ID: <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> Hi Vladimir, Thanks a lot for looking at this! On 8/20/20 8:29 PM, Vladimir Ivanov wrote: > Hi Ningsheng, > >> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-July/039289.html > > > Impressive work, Ningsheng! > >> http://cr.openjdk.java.net/~njian/8231441/README-RFR.txt > > "Since the bottom 128 bits are shared with the NEON, we extend current > register mask definition of V0-V31 registers. Currently, c2 uses one bit > mask for a 32-bit register slot, so to define at most 2048 bits we will > need to add 64 slots in AD file. That's a really large number, and will > also break current regmask assumption." > > Can you, please, elaborate on the last point? What RegMask assumptions > are broken for 2048-bit vectors? I'm looking at [1] and try to > understand the motivation for the changes in shared code. Current regmask is handled by an array of ints, so an element of regmask array can handle at most 32*32=1024 bits. Some regmask handling functions, e.g. clear_to_sets() for alignment, need to be re-examined for the support of 2048 bits. And we may even want to support non power-of-two physical reg sizes, that could be a lot more work. > > Compared to x86 w/ AVX512, architectural state for vector registers is > 4x larger in the worst case (ignoring predicate registers for now). Here > are the relevant constants on x86: > > gensrc/adfiles/adGlobals_x86.hpp: > > // the number of reserved registers + machine registers. > #define REG_COUNT??? 545 > ... > // Size of register-mask in ints > #define RM_SIZE 22 > > My estimate is that for AArch64 with SVE support the constants will be: > > ? REG_COUNT < 2500 > ? RM_SIZE < 100 > > which don't look too bad. > Right, but given that most real hardware implementations will be no larger than 512 bits, I think. Having a large bitmask array, with most bits useless, will be less efficient for regmask computation. > Also, I don't see any changes related to stack management. So, I assume > it continues to be managed in slots. Any problems there? As I > understand, wide SVE registers are caller-save, so there may be many > spills of huge vectors around a call. (Probably, not possible with C2 > auto-vectorizer as it is now, but Vector API will expose it.) > Yes, the stack is still managed in slots, but it will be allocated with real vector register length instead of 'virtual' slots for VecA. See the usages of scalable_reg_slots(), e.g. in chaitin.cpp:1587. We have also applied the patch to vector api, and did find a lot of vector spills with expected correct results. > Have you noticed any performance problems? If that's the case, then > AVX512 support on x86 would benefit from similar optimization as well. > Do you mean register allocation performance problems? I did not notice that before. Do you have any suggestion on how to measure that? > FTR there was a similar exercise [2] on x86 to abstract away exact sizes > of vector registers, but it didn't have to worry about RA since all the > operands were already available. Also, vectors of all different sizes > may be used. So, it makes it hard to compare. > I've also noticed that. That's an excellent work indeed. It could save a lot of backend match rules for different vector register sizes, which was one of the concerns when we started to work on SVE RA, if we defined all regmasks for different SVE vector register sizes. And yes, our current approach will also solve that problem. :-) > Best regards, > Vladimir Ivanov > > [1] http://cr.openjdk.java.net/~njian/8231441/webrev.03-ra/ > > [2] https://bugs.openjdk.java.net/browse/JDK-8230015 > Thanks, Ningsheng From erik.osterlund at oracle.com Fri Aug 21 16:21:53 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Fri, 21 Aug 2020 18:21:53 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: Hi, Have you tried this with ZGC on AArch64? It has custom code for saving live registers in the load barrier slow path. I can't see any code changes there, so assuming this will just crash instead. The relevant code is in ZBarrierSetAssembler on aarch64. Maybe I missed something? Thanks, /Erik On 2020-08-19 11:53, Ningsheng Jian wrote: > Hi Andrew, > > I have updated the patch based on the review comments. Would you mind > taking another look? Thanks! > > Full: > http://cr.openjdk.java.net/~njian/8231441/webrev.04/ > > Incremental: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-vs-03/ > > Also add build-dev, as there's a makefile change. > > And the split parts: > > 1) SVE feature detection: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-feature > > 2) c2 register allocation: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-ra > > 3) SVE c2 backend: > http://cr.openjdk.java.net/~njian/8231441/webrev.04-c2 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8231441 > CSR: https://bugs.openjdk.java.net/browse/JDK-8248742 > > JTreg tests are still running, and so far no new failure found. > > Thanks, > Ningsheng > > On 8/17/20 5:16 PM, Andrew Dinn wrote: >> Hi Pengfei, >> >> On 17/08/2020 07:00, Ningsheng Jian wrote: >>> Thanks a lot for the review! Sorry for the late reply, as I was on >>> vacation last week. And thanks to Pengfei and Joshua for helping >>> clarifying some details in the patch. >> >> Yes, they did a very good job of answering most of the pending >> questions. >> >>>> I also eyeballed /some/ of the generated code to check that it looked >>>> ok. I'd really like to be able to do that systematically for a >>>> comprehensive test suite that exercised every rule but I only had the >>>> machine for a few days. This really ought to be done as a follow-up to >>>> ensure that all the rules are working as expected. >>> >>> Yes, we would expect Pengfei's OptoAssembly check patch can get merged >>> in future. >> >> I'm fine with that as a follow-up patch if you raise a JIRA for it. >> >>>> I am not clear why you are choosing to re-init ptrue after certain JVM >>>> runtime calls (e.g. when Z calls into the runtime) and not others e.g. >>>> when we call a JVM_ENTRY. Could you explain the rationale you have >>>> followed here? >>> >>> We do the re-init at any possible return points to c2 code, not in any >>> runtime c++ functions, which will reduce the re-init calls. >>> >>> Actually I found those entries by some hack of jvm. In the hacky code >>> below we use gcc option -finstrument-functions to build hotspot. With >>> this option, each C/C++ function entry/exit will call the instrument >>> functions we defined. In instrument functions, we clobber p7 (or other >>> reg for test) register, and in c2 function return we verify that p7 (or >>> other reg) has been reinitialized. >>> >>> http://cr.openjdk.java.net/~njian/8231441/0001-RFC-Block-one-caller-save-register-for-C2.patch >>> >> >> Nice work. It's very good to have that documented. I'm willing to accept >> i) that this has found all current cases and ii) that the verify will >> catch any cases that might get introduced by future changes (e.g. the >> callout introduced by ZGC that you mention below). As the above mot say >> there is a slim chance this might have missed some cases but I think it >> is pretty unlikely. >> >> >>>> Specific Comments (register allocator webrev): >>>> >>>> >>>> aarch64.ad:97-100 >>>> >>>> Why have you added a reg_def for R8 and R9 here and also to >>>> alloc_class >>>> chunk0 at lines 544-545? They aren't used by C2 so why define them? >>>> >>> >>> I think Pengfei has helped to explain that. I will either add clear >>> comments or rename the register name as you suggested. >> >> Ok, good. >> >>> As Joshua clarified, we are also working on predicate scalable reg, >>> which is not in this patch. Thanks for the suggestion, I will try to >>> refactor this a bit. >> >> Ok, I'll wait for an updated patch. Are you planning to include the >> scalable predicate reg code as part of this patch? I think that would be >> better as it would help to clarify the need to distinguish vector regs >> as a subset of scalable regs. >> >>>> zBarrierSetAssembler_aarch64.cpp:434 >>>> >>>> Can you explain why we need to check p7 here and not do so in other >>>> places where we call into the JVM? I'm not saying this is wrong. I >>>> just >>>> want to know how you decided where re-init of p7 was needed. >>>> >>> >>> Actually I found this by my hack patch above while running jtreg tests. >>> The stub slowpath here can be a c++ function. >> >> Yes, good catch. >> >>>> superword.cpp:97 >>>> >>>> Does this mean that is someone sets the maximum vector size to a >>>> non-power of two, such as 384, all superword operations will be >>>> bypassed? Including those which can be done using NEON vectors? >>>> >>> >>> Current SLP vectorizer only supports power-of-2 vector size. We are >>> trying to work out a new vectorizer to support all SVE vector sizes, so >>> we would expect a size like 384 could go to that path. I tried current >>> patch on a 512-bit SVE hardware which does not support 384-bit: >>> >>> $ java -XX:MaxVectorSize=16 -version # (32 and 64 are the same) >>> openjdk version "16-internal" 2021-03-16 >>> >>> $ java -XX:MaxVectorSize=48 -version >>> OpenJDK 64-Bit Server VM warning: Current system only supports max SVE >>> vector length 32. Set MaxVectorSize to 32 >>> >>> (Fallbacks to 32 and issue a warning, as the prctl() call returns 32 >>> instead of unsupported 48: >>> https://www.kernel.org/doc/Documentation/arm64/sve.txt) >>> >>> Do you think we need to exit vm instead of warning and fallbacking >>> to 32 >>> here? >> >> Yes, I think a vm exit would probably be a better choice. >> >> regards, >> >> >> Andrew Dinn >> ----------- >> Red Hat Distinguished Engineer >> Red Hat UK Ltd >> Registered in England and Wales under Company Registration No. 03798903 >> Directors: Michael Cunningham, Michael ("Mike") O'Neill >> > From beurba at microsoft.com Fri Aug 21 22:13:32 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Fri, 21 Aug 2020 22:13:32 +0000 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> References: , <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> Message-ID: Hey Aleksey, thanks for your comments! > *) make/autoconf/jvm-features.m4: are we sure Shenandoah does not work with Windows AArch64? I > don't think there should be a problem with it. I also see there are Shenandoah-related changes > elsewhere, so I assume it was built at some time? Shenandoah (and ZGC for what it's worth) do work out of the box on Windows AArch64. We didn't test them extensively though and did intentionally not included them in the JEP to reduce the test surface for now. Monica has opened a bug for both GCs: https://bugs.openjdk.java.net/browse/JDK-8252114 > *) src/hotspot/cpu/aarch64/aarch64.ad: are these needed? > > 993 #include "gc/shared/barrierSet.hpp" > 994 #include "gc/shared/barrierSetAssembler.hpp" Good catch, they are not needed. Removed. > *) src/hotspot/share/runtime/vm_version.hpp: new includes in the .hpp file? > Wouldn't it be better to do them in the relevant compilation units? > > 28 #include "memory/allocation.hpp" > 29 #include "utilities/ostream.hpp" Apparently they aren't needed too, hu. Removed. Tested the build on Linux AArch64 and Windows AArch64. Updated Webrev: http://cr.openjdk.java.net/~burban/8248238/webrev.02/ Thank you, -Bernhard From vladimir.x.ivanov at oracle.com Fri Aug 21 22:34:40 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Sat, 22 Aug 2020 01:34:40 +0300 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> Message-ID: <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> Thanks for clarifications, Ningsheng. Let me share my thoughts on the topic and I'll start with summarizing the experience of migrating x86 code to generic vectors. JVM has quite a bit of special logic to support vectors. It hasn't exhausted the complexity budget yet, but it's quite close to the limit (as you probably noticed). While extending x86 backend to support Vector API, we pushed it over the limit and had to address some of the issues. The ultimate goal was to move to vectors which represent full-width hardware registers. After we were convinced that it will work well in AD files, we encountered some inefficiencies with vector spills: depending on actual hardware, smaller (than available) vectors may be used (e.g., integer computations on AVX-capable CPU). So, we stopped half-way and left post-matching part intact: depending on actual vector value width, appropriate operand (vecX/vecY/vecZ + legacy variants) is chosen. (I believe you may be in a similar situation on AArch64 with NEON vs SVE where both 128-bit and wide SVE vectors may be used at runtime.) Now back to the patch. What I see in the patch is that you try to attack the problem from the opposite side: you introduce new concept of a size-agnostic vector register on RA side and then directly use it during matching: vecA is used in aarch64_sve.ad and aarch64.ad relies on vecD/vecX. Unfortunately, it extends the implementation in orthogonal direction which looks too aarch64-specific to benefit other architectures and x86 particular. I believe there's an alternative approach which can benefit both aarch64 and x86, but it requires more experimentation. If I were to start from scratch, I would choose between 3 options: #1: reuse existing VecX/VecY/VecZ ideal registers and limit supported vector sizes to 128-/256-/512-bit values. #2: lift limitation on max size (to 1024/2048 bits), but ignore non-power-of-2 sizes; #3: introduce support for full range of vector register sizes (128-/.../2048-bit with 128-bit step); I see 2 (mostly unrelated) limitations: maximum vector size and non-power-of-2 sizes. My understanding is that you don't try to accurately represent SVE for now, but lay some foundations for future work: you give up on non-power-of-2 sized vectors, but still enable support for arbitrarily sized vectors (addressing both limitations on maximum size and size granularity) in RA (and it affects only spills). So, it is somewhere between #2 and #3. The ultimate goal is definitely #3, but how much more work will be required to teach the JVM about non-power-of-2 vectors? As I see in the patch, you don't have auto-vectorizer support yet, but Vector API will provide access to whatever size hardware exposes. What do you expect on hardware front in the near/mid-term future? Anything supporting vectors larger than 512-bit? What about 384-bit vectors? I don't have a good understanding where SVE/SVE2-capable hardware is moving and would benefit a lot from your insights about what to expect. If 256-/512-bit vectors end up as the only option, then #1 should fit them well. For larger vectors #2 (or a mix of #1 and #2) may be a good fit. My understanding that existing RA machinery should support 1024-bit vectors well. So, unless 2048-bit vectors are needed, we could live with the framework we have right now. If hardware has non-power-of-2 vectors, but JVM doesn't support them, then JVM can work with just power-of-2 portion of them (384-bit => 256-bit). Giving up on #3 for now and starting with less ambitious goals (#1 or #2) would reduce pressure on RA and give more time for additional experiments to come with a better and more universal support/representation of generic/size-agnostic vectors. And, in a longer term, help reducing complexity and technical debt in the area. Some more comments follow inline. >> Compared to x86 w/ AVX512, architectural state for vector registers is >> 4x larger in the worst case (ignoring predicate registers for now). >> Here are the relevant constants on x86: >> >> gensrc/adfiles/adGlobals_x86.hpp: >> >> // the number of reserved registers + machine registers. >> #define REG_COUNT??? 545 >> ... >> // Size of register-mask in ints >> #define RM_SIZE 22 >> >> My estimate is that for AArch64 with SVE support the constants will be: >> >> ?? REG_COUNT < 2500 >> ?? RM_SIZE < 100 >> >> which don't look too bad. >> > > Right, but given that most real hardware implementations will be no > larger than 512 bits, I think. Having a large bitmask array, with most > bits useless, will be less efficient for regmask computation. Does it make sense to limit the maximum supported size to 512-bit then (at least, initially)? In that case, the overhead won't be worse it is on x86 now. >> Also, I don't see any changes related to stack management. So, I >> assume it continues to be managed in slots. Any problems there? As I >> understand, wide SVE registers are caller-save, so there may be many >> spills of huge vectors around a call. (Probably, not possible with C2 >> auto-vectorizer as it is now, but Vector API will expose it.) >> > > Yes, the stack is still managed in slots, but it will be allocated with > real vector register length instead of 'virtual' slots for VecA. See the > usages of scalable_reg_slots(), e.g. in chaitin.cpp:1587. We have also > applied the patch to vector api, and did find a lot of vector spills > with expected correct results. I'm curious whether similar problems may arise for spills. Considering wide vector registers are caller-saved, it's possible to have lots of 256-byte values to end up on stack (especially, with Vector API). Any concerns with that? >> Have you noticed any performance problems? If that's the case, then >> AVX512 support on x86 would benefit from similar optimization as well. >> > > Do you mean register allocation performance problems? I did not notice > that before. Do you have any suggestion on how to measure that? I'd try to run some applications/benchmarks with -XX:+CITime to get a sense how much RA may be affected. Best regards, Vladimir Ivanov From ningsheng.jian at arm.com Mon Aug 24 09:16:07 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 24 Aug 2020 17:16:07 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> Message-ID: Hi Vladimir, Thanks for your valuable inputs! On 8/22/20 6:34 AM, Vladimir Ivanov wrote: > Thanks for clarifications, Ningsheng. > > Let me share my thoughts on the topic and I'll start with summarizing > the experience of migrating x86 code to generic vectors. > > JVM has quite a bit of special logic to support vectors. It hasn't > exhausted the complexity budget yet, but it's quite close to the limit > (as you probably noticed). While extending x86 backend to support Vector > API, we pushed it over the limit and had to address some of the issues. > > The ultimate goal was to move to vectors which represent full-width > hardware registers. After we were convinced that it will work well in AD > files, we encountered some inefficiencies with vector spills: depending > on actual hardware, smaller (than available) vectors may be used (e.g., > integer computations on AVX-capable CPU). So, we stopped half-way and > left post-matching part intact: depending on actual vector value width, > appropriate operand (vecX/vecY/vecZ + legacy variants) is chosen. > > (I believe you may be in a similar situation on AArch64 with NEON vs SVE > where both 128-bit and wide SVE vectors may be used at runtime.) > Thanks for sharing the background. > Now back to the patch. > > What I see in the patch is that you try to attack the problem from the > opposite side: you introduce new concept of a size-agnostic vector > register on RA side and then directly use it during matching: vecA is > used in aarch64_sve.ad and aarch64.ad relies on vecD/vecX. > > Unfortunately, it extends the implementation in orthogonal direction > which looks too aarch64-specific to benefit other architectures and x86 > particular. I believe there's an alternative approach which can benefit > both aarch64 and x86, but it requires more experimentation. > Since vecA and vecX (and others) are architecturally different vector registers, I think it's quite natural that we just introduced the new vector register type vecA, to represent what we need for corresponding hardware vector register. Please note that in vector length agnostic ISA, like Arm SVE and RISC-V vector extension [1], the vector registers are architecturally the same type of register despite the different hardware implementations. > If I were to start from scratch, I would choose between 3 options: > > #1: reuse existing VecX/VecY/VecZ ideal registers and limit supported > vector sizes to 128-/256-/512-bit values. > > #2: lift limitation on max size (to 1024/2048 bits), but ignore > non-power-of-2 sizes; > > #3: introduce support for full range of vector register sizes > (128-/.../2048-bit with 128-bit step); > > I see 2 (mostly unrelated) limitations: maximum vector size and > non-power-of-2 sizes. > > My understanding is that you don't try to accurately represent SVE for > now, but lay some foundations for future work: you give up on > non-power-of-2 sized vectors, but still enable support for arbitrarily > sized vectors (addressing both limitations on maximum size and size > granularity) in RA (and it affects only spills). So, it is somewhere > between #2 and #3. > > The ultimate goal is definitely #3, but how much more work will be > required to teach the JVM about non-power-of-2 vectors? As I see in the > patch, you don't have auto-vectorizer support yet, but Vector API will > provide access to whatever size hardware exposes. What do you expect on > hardware front in the near/mid-term future? Anything supporting vectors > larger than 512-bit? What about 384-bit vectors? > I think our patch is now in 3. :-) We do not give up non-power-of-2 sized vectors, instead we are supporting them well in this patch. And are still using current regmask framework. (Actually, I think the only limitation to the vector size is that it should be multiple of 32-bits - bits per 1 reg slot.) I am not sure about other Arm partners' hardware implementations in the mid-term future, as it's free for cpu implementer to choose any max vector sizes as long as it follows SVE architecture specification. But we did tested the patch with Vector API on different SVE supported vector sizes on emulator, e.g. 384, 768, 1024, 2048 etc. The register allocator including the spill/unspill works well on those different sizes with Vector API. (Thanks to your great work on Vector API. :-)) We currently limit the vector size to power-of-2 in vm_version_aarch64.cpp, as suggested by Andrew Dinn, is because current SLP vectorizer only supports power-of-2 vectors. With Vector API in, I think such restriction can be removed. And we are also working on a new vectorizer to support predication/mask, which should not have power-of-2 limitation. > I don't have a good understanding where SVE/SVE2-capable hardware is > moving and would benefit a lot from your insights about what to expect. > > If 256-/512-bit vectors end up as the only option, then #1 should fit > them well. > > For larger vectors #2 (or a mix of #1 and #2) may be a good fit. My > understanding that existing RA machinery should support 1024-bit vectors > well. So, unless 2048-bit vectors are needed, we could live with the > framework we have right now. > > If hardware has non-power-of-2 vectors, but JVM doesn't support them, > then JVM can work with just power-of-2 portion of them (384-bit => 256-bit). > Yes, we can make JVM to support portion of vectors, at least for SVE. My concern is that the performance wouldn't be as good as the full available vector width. > Giving up on #3 for now and starting with less ambitious goals (#1 or > #2) would reduce pressure on RA and give more time for additional > experiments to come with a better and more universal > support/representation of generic/size-agnostic vectors. And, in a > longer term, help reducing complexity and technical debt in the area. > > Some more comments follow inline. > >>> Compared to x86 w/ AVX512, architectural state for vector registers is >>> 4x larger in the worst case (ignoring predicate registers for now). >>> Here are the relevant constants on x86: >>> >>> gensrc/adfiles/adGlobals_x86.hpp: >>> >>> // the number of reserved registers + machine registers. >>> #define REG_COUNT??? 545 >>> ... >>> // Size of register-mask in ints >>> #define RM_SIZE 22 >>> >>> My estimate is that for AArch64 with SVE support the constants will be: >>> >>> ?? REG_COUNT < 2500 >>> ?? RM_SIZE < 100 >>> >>> which don't look too bad. >>> >> >> Right, but given that most real hardware implementations will be no >> larger than 512 bits, I think. Having a large bitmask array, with most >> bits useless, will be less efficient for regmask computation. > > Does it make sense to limit the maximum supported size to 512-bit then > (at least, initially)? In that case, the overhead won't be worse it is > on x86 now. > Technically, this may be possible though I haven't tried. My concerns are: 1) A larger regmask arrays would be less efficient (we only use 256 bits - 8 slots for SVE in this patch), though won't be worse than x86. 2) Given that current patch already supports larger sizes and non-power-of-2 sizes well with relative small size in diff, if we want to support other sizes soon, there may be some more work to roll-back ad file changes. >>> Also, I don't see any changes related to stack management. So, I >>> assume it continues to be managed in slots. Any problems there? As I >>> understand, wide SVE registers are caller-save, so there may be many >>> spills of huge vectors around a call. (Probably, not possible with C2 >>> auto-vectorizer as it is now, but Vector API will expose it.) >>> >> >> Yes, the stack is still managed in slots, but it will be allocated with >> real vector register length instead of 'virtual' slots for VecA. See the >> usages of scalable_reg_slots(), e.g. in chaitin.cpp:1587. We have also >> applied the patch to vector api, and did find a lot of vector spills >> with expected correct results. > > I'm curious whether similar problems may arise for spills. Considering > wide vector registers are caller-saved, it's possible to have lots of > 256-byte values to end up on stack (especially, with Vector API). Any > concerns with that? > No, we don't need to have such big (256-byte) slots for a smaller vector register. The spill slots are the same size as of real vector length, e.g. 48 bytes for 384-bit vector. Even for alignment, we currently choose SlotsPerVecA (8 slots for 32 bytes, 256 bits) for alignment (skipped slots can still be allocated to other args), which is still smaller than AVX512 (64 bytes, 512 bits). We can tweak the patch to choose other smaller value, if we think the alignment is too large. (Yes, we should always try to avoid spills for wide vectors, especially with Vector API, to avoid performance pitfalls.) >>> Have you noticed any performance problems? If that's the case, then >>> AVX512 support on x86 would benefit from similar optimization as well. >>> >> >> Do you mean register allocation performance problems? I did not notice >> that before. Do you have any suggestion on how to measure that? > > I'd try to run some applications/benchmarks with -XX:+CITime to get a > sense how much RA may be affected. > Thanks! I will give a try. [1] https://github.com/riscv/riscv-v-spec/releases/tag/0.9 Thanks, Ningsheng From ningsheng.jian at arm.com Mon Aug 24 09:59:20 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 24 Aug 2020 17:59:20 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> Message-ID: <5397e0d1-9d40-0107-c164-304740bc5d7f@arm.com> Hi Erik, Thanks for the review! On 8/22/20 12:21 AM, Erik ?sterlund wrote: > Hi, > > Have you tried this with ZGC on AArch64? It has custom code for saving > live registers in the load barrier slow path. > I can't see any code changes there, so assuming this will just crash > instead. > The relevant code is in ZBarrierSetAssembler on aarch64. > > Maybe I missed something? > I didn't add ZGC option while running tests. I think I need to update push_fp() which is called by ZSaveLiveRegisters. But do we need to get size info (float/neon/sve) instead of saving the whole vector register? Currently, it just simply saves the whole NEON register. And in ZBarrierSetAssembler::load_at(), before calling to runtime code, we call push_call_clobbered_registers_except(), which just saves floating point registers instead of the whole NEON vector registers. Similar behavior in x86 implementation. Is that correct (not saving vectors)? Thanks, Ningsheng From vladimir.x.ivanov at oracle.com Mon Aug 24 12:03:47 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Mon, 24 Aug 2020 15:03:47 +0300 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> Message-ID: <9fd1e3b1-7884-1cf7-64ba-040a16c74425@oracle.com> Hi Ningsheng, >> What I see in the patch is that you try to attack the problem from the >> opposite side: you introduce new concept of a size-agnostic vector >> register on RA side and then directly use it during matching: vecA is >> used in aarch64_sve.ad and aarch64.ad relies on vecD/vecX. >> >> Unfortunately, it extends the implementation in orthogonal direction >> which looks too aarch64-specific to benefit other architectures and x86 >> particular. I believe there's an alternative approach which can benefit >> both aarch64 and x86, but it requires more experimentation. >> > > Since vecA and vecX (and others) are architecturally different vector > registers, I think it's quite natural that we just introduced the new > vector register type vecA, to represent what we need for corresponding > hardware vector register. Please note that in vector length agnostic > ISA, like Arm SVE and RISC-V vector extension [1], the vector registers > are architecturally the same type of register despite the different > hardware implementations. FTR vecX et al don't represent hardware registers, they represent vector values of predefined size. (For example, vecS, vecD, and vecX map to the very same set of 128-bit vector registers on x86.) My point is: in terms of existing concepts what you are adding is not "yet another flavor of vector". It's a new full-fledged concept (which is manifested as special cases across the JVM) and you end up with 2 different representations of vectors. I agree that hardware is quite different, but I don't see it makes much of a difference in the context of the JVM and abstractions used to hide it are similar. For example, as of now, most of x86-specific code in C2 works just fine with full-width hardware vectors which are oblivious of their sizes until RA kicks in. And SVE patch you propose completely omits implicit predication hardware provides which makes it similar to AVX512 (modulo wider range of vector width sizes supported). So, even though hardware abstractions being used aren't actually *that* different, vecA piles complexity and introduces a separate way to achieve similar results (but slightly differently). And that's what bothers me. I'd like to see more unification instead which should bring reduction in complexity and an opportunity to address long-standing technical debt (and 5 flavors of ideal registers for vectors is part of it IMO). So far, I see 2 main directions for RA work: (a) support vectors of arbitrary size: (1) helps push the upper limit on the size (1024-bit) (2) handle non-power-of-2 sizes (b) optimize RA implementation for large values Anything else? Speaking of (a), in particular, I don't see why possible solution for it should not supersede vecX et al altogether. Also, I may be wrong, but I don't see a clear evidence there's a pressing need to have all of that fixed right from the beginning. (That's why I put #1 and #2 options on the table.) Starting with #1/#2 would untie initial SVE support from the exploratory work needed to choose the most appropriate solution for (a) and (b). >> If I were to start from scratch, I would choose between 3 options: >> >> ??? #1: reuse existing VecX/VecY/VecZ ideal registers and limit supported >> vector sizes to 128-/256-/512-bit values. >> >> ??? #2: lift limitation on max size (to 1024/2048 bits), but ignore >> non-power-of-2 sizes; >> >> ??? #3: introduce support for full range of vector register sizes >> (128-/.../2048-bit with 128-bit step); >> >> I see 2 (mostly unrelated) limitations: maximum vector size and >> non-power-of-2 sizes. >> >> My understanding is that you don't try to accurately represent SVE for >> now, but lay some foundations for future work: you give up on >> non-power-of-2 sized vectors, but still enable support for arbitrarily >> sized vectors (addressing both limitations on maximum size and size >> granularity) in RA (and it affects only spills). So, it is somewhere >> between #2 and #3. >> >> The ultimate goal is definitely #3, but how much more work will be >> required to teach the JVM about non-power-of-2 vectors? As I see in the >> patch, you don't have auto-vectorizer support yet, but Vector API will >> provide access to whatever size hardware exposes. What do you expect on >> hardware front in the near/mid-term future? Anything supporting vectors >> larger than 512-bit? What about 384-bit vectors? >> > > I think our patch is now in 3. :-) We do not give up non-power-of-2 > sized vectors, instead we are supporting them well in this patch. And > are still using current regmask framework. (Actually, I think the only > limitation to the vector size is that it should be multiple of 32-bits - > bits per 1 reg slot.) > I am not sure about other Arm partners' hardware implementations in the > mid-term future, as it's free for cpu implementer to choose any max > vector sizes as long as it follows SVE architecture specification. But > we did tested the patch with Vector API on different SVE supported > vector sizes on emulator, e.g. 384, 768, 1024, 2048 etc. The register > allocator including the spill/unspill works well on those different > sizes with Vector API. (Thanks to your great work on Vector API. :-)) > > We currently limit the vector size to power-of-2 in > vm_version_aarch64.cpp, as suggested by Andrew Dinn, is because current > SLP vectorizer only supports power-of-2 vectors. With Vector API in, I > think such restriction can be removed. And we are also working on a new > vectorizer to support predication/mask, which should not have power-of-2 > limitation. [...] > Yes, we can make JVM to support portion of vectors, at least for SVE. My > concern is that the performance wouldn't be as good as the full > available vector width. To be clear: I called it "somewhere between #2 and #3" solely because auto-vectorizer bails out on non-power-of-2 sizes. And even though Vector API will work with such cases just fine, IMO having auto-vectorizer support is required before calling #3 complete. In that respect, choosing smaller vector size auto-vectorizer supports is preferrable to picking up the full-width vectors and turning off auto-vectorizer (even though Vector API will support them). It can be turned into heuristic (by default, pick only power-of-2 sizes; let users explicitly specify non-power-of-2 sizes), but speaking of priorities, IMO auto-vectorizer support is more important. >> Giving up on #3 for now and starting with less ambitious goals (#1 or >> #2) would reduce pressure on RA and give more time for additional >> experiments to come with a better and more universal >> support/representation of generic/size-agnostic vectors. And, in a >> longer term, help reducing complexity and technical debt in the area. >> >> Some more comments follow inline. >> >>>> Compared to x86 w/ AVX512, architectural state for vector registers is >>>> 4x larger in the worst case (ignoring predicate registers for now). >>>> Here are the relevant constants on x86: >>>> >>>> gensrc/adfiles/adGlobals_x86.hpp: >>>> >>>> // the number of reserved registers + machine registers. >>>> #define REG_COUNT??? 545 >>>> ... >>>> // Size of register-mask in ints >>>> #define RM_SIZE 22 >>>> >>>> My estimate is that for AArch64 with SVE support the constants will be: >>>> >>>> ??? REG_COUNT < 2500 >>>> ??? RM_SIZE < 100 >>>> >>>> which don't look too bad. >>>> >>> >>> Right, but given that most real hardware implementations will be no >>> larger than 512 bits, I think. Having a large bitmask array, with most >>> bits useless, will be less efficient for regmask computation. >> >> Does it make sense to limit the maximum supported size to 512-bit then >> (at least, initially)? In that case, the overhead won't be worse it is >> on x86 now. >> > > Technically, this may be possible though I haven't tried. My concerns are: > > 1) A larger regmask arrays would be less efficient (we only use 256 bits > - 8 slots for SVE in this patch), though won't be worse than x86. > > 2) Given that current patch already supports larger sizes and > non-power-of-2 sizes well with relative small size in diff, if we want > to support other sizes soon, there may be some more work to roll-back ad > file changes. > >>>> Also, I don't see any changes related to stack management. So, I >>>> assume it continues to be managed in slots. Any problems there? As I >>>> understand, wide SVE registers are caller-save, so there may be many >>>> spills of huge vectors around a call. (Probably, not possible with C2 >>>> auto-vectorizer as it is now, but Vector API will expose it.) >>>> >>> >>> Yes, the stack is still managed in slots, but it will be allocated with >>> real vector register length instead of 'virtual' slots for VecA. See the >>> usages of scalable_reg_slots(), e.g. in chaitin.cpp:1587. We have also >>> applied the patch to vector api, and did find a lot of vector spills >>> with expected correct results. >> >> I'm curious whether similar problems may arise for spills. Considering >> wide vector registers are caller-saved, it's possible to have lots of >> 256-byte values to end up on stack (especially, with Vector API). Any >> concerns with that? >> > > No, we don't need to have such big (256-byte) slots for a smaller vector > register. The spill slots are the same size as of real vector length, > e.g. 48 bytes for 384-bit vector. Even for alignment, we currently > choose SlotsPerVecA (8 slots for 32 bytes, 256 bits) for alignment > (skipped slots can still be allocated to other args), which is still > smaller than AVX512 (64 bytes, 512 bits). We can tweak the patch to > choose other smaller value, if we think the alignment is too large. > (Yes, we should always try to avoid spills for wide vectors, especially > with Vector API, to avoid performance pitfalls.) Thanks for the clarifications. Any new problems/hitting some limitations envisioned when spilling large number of huge vectors (2048-bit) on stack? Best regards, Vladimir Ivanov >>>> Have you noticed any performance problems? If that's the case, then >>>> AVX512 support on x86 would benefit from similar optimization as well. >>>> >>> >>> Do you mean register allocation performance problems? I did not notice >>> that before. Do you have any suggestion on how to measure that? >> >> I'd try to run some applications/benchmarks with -XX:+CITime to get a >> sense how much RA may be affected. >> > > Thanks! I will give a try. > > [1] > https://urldefense.com/v3/__https://github.com/riscv/riscv-v-spec/releases/tag/0.9__;!!GqivPVa7Brio!IwFEx-c_8JDZcWgXPLcWp2ypX3pr1-IWTBfC7O7PHo7_0skMWtQa4fyWpo-lVor0NFv4Ivo$ > > Thanks, > Ningsheng > From adinn at redhat.com Mon Aug 24 13:40:53 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 24 Aug 2020 14:40:53 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> Message-ID: <35f8801f-4383-4804-2a9b-5818d1bda763@redhat.com> On 24/08/2020 10:16, Ningsheng Jian wrote: > On 8/22/20 6:34 AM, Vladimir Ivanov wrote: >> The ultimate goal was to move to vectors which represent full-width >> hardware registers. After we were convinced that it will work well in AD >> files, we encountered some inefficiencies with vector spills: depending >> on actual hardware, smaller (than available) vectors may be used (e.g., >> integer computations on AVX-capable CPU). So, we stopped half-way and >> left post-matching part intact: depending on actual vector value width, >> appropriate operand (vecX/vecY/vecZ + legacy variants) is chosen. >> >> (I believe you may be in a similar situation on AArch64 with NEON vs SVE >> where both 128-bit and wide SVE vectors may be used at runtime.) Your problem here seems to be a worry about spilling more data than is actually needed. As Ningsheng pointed out the amount of data spilled is determined by the actual length of the VecA registers, not by the logical size of the VecA mask (256 bits) nor by the maximum possible size of a VecA register on future architectures (2048 bits). So, no more stack space will be used than is needed to preserve the live bits that need preserving. >> Unfortunately, it extends the implementation in orthogonal direction >> which looks too aarch64-specific to benefit other architectures and x86 >> particular. I believe there's an alternative approach which can benefit >> both aarch64 and x86, but it requires more experimentation. >> > > Since vecA and vecX (and others) are architecturally different vector > registers, I think it's quite natural that we just introduced the new > vector register type vecA, to represent what we need for corresponding > hardware vector register. Please note that in vector length agnostic > ISA, like Arm SVE and RISC-V vector extension [1], the vector registers > are architecturally the same type of register despite the different > hardware implementations. Yes, I also see this as quite natural. Ningsheng's change extends the implementation in the architecture-specific direction that is needed for AArch64's vector model. The fact that this differs from x86_64 is not unexpected. >> If I were to start from scratch, I would choose between 3 options: >> >> ??? #1: reuse existing VecX/VecY/VecZ ideal registers and limit supported >> vector sizes to 128-/256-/512-bit values. >> >> ??? #2: lift limitation on max size (to 1024/2048 bits), but ignore >> non-power-of-2 sizes; >> >> ??? #3: introduce support for full range of vector register sizes >> (128-/.../2048-bit with 128-bit step); >> >> I see 2 (mostly unrelated) limitations: maximum vector size and >> non-power-of-2 sizes. Yes, but this patch deals with both of those and I cannot see it causing any problems for x86_64 nor do I see it adding any great complexity. The extra shard paths deal with scalable vectors wich onlu occur on AArch64. A scalable VecA register (and also eventually the scalable predicate register) caters for all possible vector sizes via a single 'logical' vector of size 8 slots (also eventually a single 'logical' predicate register of size 1 slot). Catering for scalable registers in shared code is localized and does not change handling of the existing, non-scalable VecX/Y/Z registers. >> My understanding is that you don't try to accurately represent SVE for >> now, but lay some foundations for future work: you give up on >> non-power-of-2 sized vectors, but still enable support for arbitrarily >> sized vectors (addressing both limitations on maximum size and size >> granularity) in RA (and it affects only spills). So, it is somewhere >> between #2 and #3. I have to disagree with your statement that this proposal doesn't 'accurately' represent SVE. Yes, the vector mask for this arbitrary-size vector is modelled 'logically' using a nominal 8 slots. However, that is merely to avoid wasting bits in the bit masks plus cpu time processing them. The 'physical' vector length models the actual number of slots, and includes the option to model a non-power of two. That 'physical' size is used in all operations that manipulate VecA register contents. So, although I grant that the code is /parameterized/, it is also 100% accurate. >> The ultimate goal is definitely #3, but how much more work will be >> required to teach the JVM about non-power-of-2 vectors? As I see in the >> patch, you don't have auto-vectorizer support yet, but Vector API will >> provide access to whatever size hardware exposes. What do you expect on >> hardware front in the near/mid-term future? Anything supporting vectors >> larger than 512-bit? What about 384-bit vectors? Do we need to know for sure such hardware is going to arrive in order to allow for it now? If there were a significant cost to doing so I'd maybe say yes but I don't really see one here. Most importantly, the changes to the AArch64 register model and small changes to the shared chaitin/reg mask code proposed here already work with the auto-vectorizer if the VecA slots are any of the possible powers of 2 VecA sizes. The extra work needed to profit from non-power-of-two vector involves upgrading the auto-vectorizer code. While this may be tricky I don't see ti as impossible. However, more importantly, even if such an upgrade cannot be achieved then this proposal is still a very simple way to allow for arbitrarily scalable SVE vectors that are a power of two size. It also allows any architecture with a non-power of two to work with the lowest power of two that fits. So, this is a very siple way to cater for what may turn up. >> For larger vectors #2 (or a mix of #1 and #2) may be a good fit. My >> understanding that existing RA machinery should support 1024-bit vectors >> well. So, unless 2048-bit vectors are needed, we could live with the >> framework we have right now. I'm not sure what you are proposing here but it sounds like introducing extra vectors beyond VecX, VecY for larger powers of two i.e. VecZ, vecZZ, VecZZZ ... and providing separate case processing for each of them where the relevant case is selected conditional on the actual vector size. Is that what you are proposing? I can't see any virtue in multiplying case handling fore ach new power-of-two size that turns up when all possible VecZ* power-of-two options can actually be handled as one uniform case. >> If hardware has non-power-of-2 vectors, but JVM doesn't support them, >> then JVM can work with just power-of-2 portion of them (384-bit => >> 256-bit). And, of course, the previous comment applies here /a fortiori/. >> Giving up on #3 for now and starting with less ambitious goals (#1 or >> #2) would reduce pressure on RA and give more time for additional >> experiments to come with a better and more universal >> support/representation of generic/size-agnostic vectors. And, in a >> longer term, help reducing complexity and technical debt in the area. Can you explain what you mean by 'reduce pressure on RA'? I'm also unclear as to what you see as complex about this proposal. >> Some more comments follow inline. >> >>>> Compared to x86 w/ AVX512, architectural state for vector registers is >>>> 4x larger in the worst case (ignoring predicate registers for now). >>>> Here are the relevant constants on x86: >>>> >>>> gensrc/adfiles/adGlobals_x86.hpp: >>>> >>>> // the number of reserved registers + machine registers. >>>> #define REG_COUNT??? 545 >>>> ... >>>> // Size of register-mask in ints >>>> #define RM_SIZE 22 >>>> >>>> My estimate is that for AArch64 with SVE support the constants will be: >>>> >>>> ??? REG_COUNT < 2500 >>>> ??? RM_SIZE < 100 >>>> >>>> which don't look too bad. I'm not sure what these numbers are meant to mean. The number of SVE vector registers is the same as the number of NEON vector registers i.e. 32. The register mask size for VecA registers is 8 * 32 bits. >>> Right, but given that most real hardware implementations will be no >>> larger than 512 bits, I think. Having a large bitmask array, with most >>> bits useless, will be less efficient for regmask computation. >> >> Does it make sense to limit the maximum supported size to 512-bit then >> (at least, initially)? In that case, the overhead won't be worse it is >> on x86 now. Well, no. It doesn't make sense when all you need is a 'logical' 8 * 32 bit mask whatever the actual 'physical' register size is. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Mon Aug 24 14:38:21 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 24 Aug 2020 15:38:21 +0100 Subject: [aarch64-port-dev ] Result: New aarch64-port Committer: Bernhard Urban-Forster In-Reply-To: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> References: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> Message-ID: <9eb5f8bb-9bb3-a775-2f89-46170f0ace41@redhat.com> Voting for Bernhard Urban-Forster [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009411.html -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Aug 24 14:31:02 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 24 Aug 2020 15:31:02 +0100 Subject: [aarch64-port-dev ] Result: New aarch64-port Committer: Ludovic Henry In-Reply-To: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> References: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> Message-ID: <0709769a-9ad5-2958-ae71-91d5c4e900e1@redhat.com> Voting for Ludovic Henry [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Aug 24 14:30:08 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 24 Aug 2020 15:30:08 +0100 Subject: [aarch64-port-dev ] Result: New aarch64-port Committer: Ludovic Henry In-Reply-To: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> References: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> Message-ID: <675814bf-7124-b5a6-5c6b-b1511268b894@redhat.com> Voting for Ludovic Henry [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009409.html -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Aug 24 14:37:30 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 24 Aug 2020 15:37:30 +0100 Subject: [aarch64-port-dev ] Result: New aarch64-port Committer: Monica Beckwith In-Reply-To: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> References: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> Message-ID: <6f47367e-ac7a-214b-c45f-479e1cfd943d@redhat.com> Voting for Monica Beckwith [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009410.html -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From erik.osterlund at oracle.com Mon Aug 24 15:26:30 2020 From: erik.osterlund at oracle.com (=?UTF-8?Q?Erik_=c3=96sterlund?=) Date: Mon, 24 Aug 2020 17:26:30 +0200 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <5397e0d1-9d40-0107-c164-304740bc5d7f@arm.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <5397e0d1-9d40-0107-c164-304740bc5d7f@arm.com> Message-ID: Hi Ningsheng, On 2020-08-24 11:59, Ningsheng Jian wrote: > Hi Erik, > > Thanks for the review! > > On 8/22/20 12:21 AM, Erik ?sterlund wrote: >> Hi, >> >> Have you tried this with ZGC on AArch64? It has custom code for saving >> live registers in the load barrier slow path. >> I can't see any code changes there, so assuming this will just crash >> instead. >> The relevant code is in ZBarrierSetAssembler on aarch64. >> >> Maybe I missed something? >> > > I didn't add ZGC option while running tests. I think I need to update > push_fp() which is called by ZSaveLiveRegisters. But do we need to get > size info (float/neon/sve) instead of saving the whole vector > register? Currently, it just simply saves the whole NEON register. What we found on x86_64 was that there was a significant cost in saving vector registers in load barriers. That is why we perform some analysis so that only the exact registers that are affected, and only the parts of the registers that are affected, get spilled. It actually mattered. It will of course work either way, but that was our observation on x86_64. But I am okay with that being deferred to a separate RFE. I just wanted to make sure that it at the very least works with the new code, for a start, so it doesn't start crashing. > And in ZBarrierSetAssembler::load_at(), before calling to runtime > code, we call push_call_clobbered_registers_except(), which just saves > floating point registers instead of the whole NEON vector registers. > Similar behavior in x86 implementation. Is that correct (not saving > vectors)? Yes. The call contexts are: 1) Interpreter. Does not use vector registers. 2) Method handle intrinsic. Uses only floats that are part of the Java calling convention, rest is garbage. No vectors here. 3) Checkcast arraycopy. Does not use vectors. Thanks, /Erik > Thanks, > Ningsheng From beurba at microsoft.com Mon Aug 24 18:53:20 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 24 Aug 2020 18:53:20 +0000 Subject: [aarch64-port-dev ] Result: New aarch64-port Committer: Bernhard Urban-Forster In-Reply-To: <9eb5f8bb-9bb3-a775-2f89-46170f0ace41@redhat.com> References: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com>, <9eb5f8bb-9bb3-a775-2f89-46170f0ace41@redhat.com> Message-ID: Thanks everyone! -Bernhard ________________________________________ From: aarch64-port-dev on behalf of Andrew Haley Sent: Monday, August 24, 2020 16:38 To: aarch64-port-dev at openjdk.java.net Cc: registrar Subject: [aarch64-port-dev ] Result: New aarch64-port Committer: Bernhard Urban-Forster Voting for Bernhard Urban-Forster [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.openjdk.java.net%2Fpipermail%2Faarch64-port-dev%2F2020-August%2F009411.html&data=02%7C01%7Cbeurba%40microsoft.com%7C5a6940bd5eeb49659b5608d8485b28a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637338903674192018&sdata=iq87Lpz8e%2FZaMp%2FyQTGaJZN8FRVzwN28xcLm3X3tASU%3D&reserved=0 -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7Cbeurba%40microsoft.com%7C5a6940bd5eeb49659b5608d8485b28a6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637338903674192018&sdata=ph9WwuNGc8KS3qlwltIfLGdrIsRvHs2t%2B1a7IXxVcGw%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From beurba at microsoft.com Mon Aug 24 20:11:57 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 24 Aug 2020 20:11:57 +0000 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: , <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com>, Message-ID: Alas my changes do break a --disable-precompiled-headers build. That's the missing bit: --- a/src/hotspot/cpu/aarch64/register_aarch64.hpp +++ b/src/hotspot/cpu/aarch64/register_aarch64.hpp @@ -27,6 +27,7 @@ #define CPU_AARCH64_REGISTER_AARCH64_HPP #include "asm/register.hpp" +#include "utilities/powerOfTwo.hpp" class VMRegImpl; typedef VMRegImpl* VMReg; Updated webrev: http://cr.openjdk.java.net/~burban/8248238/webrev.03/ Cheers, -Bernhard ________________________________________ From: Bernhard Urban-Forster Sent: Saturday, August 22, 2020 00:13 To: Aleksey Shipilev; aarch64-port-dev at openjdk.java.net Cc: openjdk-aarch64 Subject: Re: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support Hey Aleksey, thanks for your comments! > *) make/autoconf/jvm-features.m4: are we sure Shenandoah does not work with Windows AArch64? I > don't think there should be a problem with it. I also see there are Shenandoah-related changes > elsewhere, so I assume it was built at some time? Shenandoah (and ZGC for what it's worth) do work out of the box on Windows AArch64. We didn't test them extensively though and did intentionally not included them in the JEP to reduce the test surface for now. Monica has opened a bug for both GCs: https://bugs.openjdk.java.net/browse/JDK-8252114 > *) src/hotspot/cpu/aarch64/aarch64.ad: are these needed? > > 993 #include "gc/shared/barrierSet.hpp" > 994 #include "gc/shared/barrierSetAssembler.hpp" Good catch, they are not needed. Removed. > *) src/hotspot/share/runtime/vm_version.hpp: new includes in the .hpp file? > Wouldn't it be better to do them in the relevant compilation units? > > 28 #include "memory/allocation.hpp" > 29 #include "utilities/ostream.hpp" Apparently they aren't needed too, hu. Removed. Tested the build on Linux AArch64 and Windows AArch64. Updated Webrev: http://cr.openjdk.java.net/~burban/8248238/webrev.02/ Thank you, -Bernhard From luhenry at microsoft.com Mon Aug 24 21:04:13 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Mon, 24 Aug 2020 21:04:13 +0000 Subject: [aarch64-port-dev ] Result: New aarch64-port Committer: Ludovic Henry In-Reply-To: <0709769a-9ad5-2958-ae71-91d5c4e900e1@redhat.com> References: <497c1ded-92cc-ac37-843d-9b68fdc4f7c3@redhat.com> <0709769a-9ad5-2958-ae71-91d5c4e900e1@redhat.com> Message-ID: Thank you very much! Looking forward to learn even more ?? -- Ludovic -----Original Message----- From: aarch64-port-dev On Behalf Of Andrew Haley Sent: Monday, August 24, 2020 7:31 AM To: aarch64-port-dev at openjdk.java.net Subject: [aarch64-port-dev ] Result: New aarch64-port Committer: Ludovic Henry Voting for Ludovic Henry [1] is now closed. Yes: 3 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7Cluhenry%40microsoft.com%7Ce6b4a99dbe8f4233fa2f08d8485aeb69%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637338902624955767&sdata=HvSDKIjyW6Y%2FStSSU6e2aNgxokkzBHFE8i0SsYzBU34%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dmitry.chuyko at bell-sw.com Mon Aug 24 21:52:06 2020 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Tue, 25 Aug 2020 00:52:06 +0300 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: References: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> <67e67230-cac7-d940-1cca-6ab4e8cba8d4@redhat.com> <9e792a33-4f90-8829-2f7b-158d07d3fd15@bell-sw.com> Message-ID: Hi Andrew, I added two more intrinsics -- for copySign, they are controlled by UseCopySignIntrinsic flag. webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.03/ It also contains 'benchmarks' directory: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.03/benchmarks/ There are 8 benchmarks there: (double | float) x (blackhole | reduce) x (current j.l.Math.signum | abs()>0 check). My results on Arm are in signum-facgt-copysign.ods. Main case is 'random' which is actually a random from positive and negative numbers between -0.5 and +0.5. Basically we have ~14% improvement in 'reduce' benchmark variant but ~20% regression in 'blackhole' variant in case of only copySign() intrinsified. Same picture if abs()>0 check is used in signum() (+-5%). This variant is included as it shows very good results on x86. Intrinsic for signum() gives improvement of main case in both 'blackhole' and 'reduce' variants of benchmark: 28% and 11%, which is a noticeable difference. -Dmitry On 8/19/20 11:35 AM, Andrew Haley wrote: > On 18/08/2020 16:05, Dmitry Chuyko wrote: >> Some more results for a benchmark with reduce(): >> >> -XX:-UseSignumIntrinsic >> DoubleOrigSignum.ofMostlyNaN 0.914 ? 0.001 ns/op >> DoubleOrigSignum.ofMostlyNeg 1.178 ? 0.001 ns/op >> DoubleOrigSignum.ofMostlyPos 1.176 ? 0.017 ns/op >> DoubleOrigSignum.ofMostlyZero 0.803 ? 0.001 ns/op >> DoubleOrigSignum.ofRandom 1.175 ? 0.012 ns/op >> -XX:+UseSignumIntrinsic >> DoubleOrigSignum.ofMostlyNaN 1.040 ? 0.007 ns/op >> DoubleOrigSignum.ofMostlyNeg 1.040 ? 0.004 ns/op >> DoubleOrigSignum.ofMostlyPos 1.039 ? 0.003 ns/op >> DoubleOrigSignum.ofMostlyZero 1.040 ? 0.001 ns/op >> DoubleOrigSignum.ofRandom 1.040 ? 0.003 ns/op > That's almost no difference, isn't it? Down in the noise. > >> If we only intrinsify copySign() we lose free mask that we get from >> facgt. In such case improvement (for signum) decreases like from ~30% to >> ~15%, and it also greatly depends on the particular HW. We can >> additionally introduce an intrinsic for Math.copySign(), especially it >> makes sense for float where it can be just 2 fp instructions: movi+bsl >> (fmovd+fnegd+bsl for double). > I think this is worth doing, because moves between GPRs and vector regs > tend to have a long latency. Can you please add that, and we can all try > it on our various hardware. > > We're measuring two different things, throughput and latency. The > first JMH test you provided was really testing latency, because > Blackhole waits for everything to complete. > > [ Note to self: Blackhole.consume() seems to be particularly slow on > some AArch64 implementations because it uses a volatile read. What > seems to be happening, judging by how long it takes, is that the store > buffer is drained before the volatile read. Maybe some other construct > would work better but still provide the guarantees Blackhole.consume() > needs. ] > > For throughput we want to keep everything moving. Sure, sometimes we > are going to have to wait for some calculation to complete, so if we > can improve latency without adverse cost we should. For that, staying > in the vector regs helps. > From yueshi.zwj at alibaba-inc.com Tue Aug 25 06:03:10 2020 From: yueshi.zwj at alibaba-inc.com (Joshua Zhu) Date: Tue, 25 Aug 2020 14:03:10 +0800 Subject: [aarch64-port-dev ] RFR: 8252259: AArch64: Adjust default value of FLOATPRESSURE Message-ID: <001101d67aa5$69851450$3c8f3cf0$@alibaba-inc.com> Hi, I have a small patch that will decrease the default value from 64 into 32 for aarch64's FLOATPRESSURE, which represents float LRG's number that constitutes high register pressure. With the proper value setting, in low register pressure (LRP) region, C2 can avoid unnecessary spilling and directly use register. I wrote a simple case that is able to reflect the effect of new value. http://cr.openjdk.java.net/~jzhu/8252259/Test.java For this case, with new FLOATPRESSURE value, only one iteration of iterative graph-coloring RA was required. The DefinitionSpillCopyNode was generated directly when crossing HRP boundary in Split phase [1]. And only one MemToRegSpillCopyNode in HRP region was generated at USE site. The dump of Split cycles and OptoAssembly is: http://cr.openjdk.java.net/~jzhu/8252259/frp_32.log For the same case, with current FLOATPRESSURE, the whole method was identified as LRP region. In the first iteration of graph-coloring, LRG was identified as spilled. In the second iteration, DefinitionSpillCopyNode was generated [2] and there were three MemToRegSpillCopy nodes were produced at each USE site. See dump: http://cr.openjdk.java.net/~jzhu/8252259/frp_64.log with the old FLOATPRSSURE. Therefore I propose the default value of FLOATPRESSURE be 32 because there are 32 float/SIMD registers on aarch64 and also the value of register pressure is the same as 1 for each LRG of Op_RegL/Op_RegD/Op_Vec. [3] Could you please help review this change? JBS: https://bugs.openjdk.java.net/browse/JDK-8252259 Webrev: http://cr.openjdk.java.net/~jzhu/8252259/webrev.00/ [1] https://hg.openjdk.java.net/jdk/jdk/file/332b3a2eb4cc/src/hotspot/share/opto /reg_split.cpp#l855 [2] https://hg.openjdk.java.net/jdk/jdk/file/332b3a2eb4cc/src/hotspot/share/opto /reg_split.cpp#l1198 [3] https://hg.openjdk.java.net/jdk/jdk/file/332b3a2eb4cc/src/hotspot/share/opto /chaitin.cpp#l926 Best Regards, Joshua From aph at redhat.com Tue Aug 25 09:44:30 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 10:44:30 +0100 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> Message-ID: On 24/08/2020 21:11, Bernhard Urban-Forster wrote: > Updated webrev:http://cr.openjdk.java.net/~burban/8248238/webrev.03/ Looks OK. It would be nice if you could get rid of some of the #ifndef _WIN64 stuff in common code by moving queries like icache_line_size() into os-specific files, but you may do that later. Thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ningsheng.jian at arm.com Tue Aug 25 10:07:30 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Tue, 25 Aug 2020 18:07:30 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <9fd1e3b1-7884-1cf7-64ba-040a16c74425@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <9fd1e3b1-7884-1cf7-64ba-040a16c74425@oracle.com> Message-ID: Hi Vladimir, On 8/24/20 8:03 PM, Vladimir Ivanov wrote: > Hi Ningsheng, > >>> What I see in the patch is that you try to attack the problem from the >>> opposite side: you introduce new concept of a size-agnostic vector >>> register on RA side and then directly use it during matching: vecA is >>> used in aarch64_sve.ad and aarch64.ad relies on vecD/vecX. >>> >>> Unfortunately, it extends the implementation in orthogonal direction >>> which looks too aarch64-specific to benefit other architectures and x86 >>> particular. I believe there's an alternative approach which can benefit >>> both aarch64 and x86, but it requires more experimentation. >>> >> >> Since vecA and vecX (and others) are architecturally different vector >> registers, I think it's quite natural that we just introduced the new >> vector register type vecA, to represent what we need for corresponding >> hardware vector register. Please note that in vector length agnostic >> ISA, like Arm SVE and RISC-V vector extension [1], the vector >> registers are architecturally the same type of register despite the >> different hardware implementations. > > FTR vecX et al don't represent hardware registers, they represent vector > values of predefined size. (For example, vecS, vecD, and vecX map to the > very same set of 128-bit vector registers on x86.) > > My point is: in terms of existing concepts what you are adding is not > "yet another flavor of vector". It's a new full-fledged concept (which > is manifested as special cases across the JVM) and you end up with 2 > different representations of vectors. > > I agree that hardware is quite different, but I don't see it makes much > of a difference in the context of the JVM and abstractions used to hide > it are similar. > > For example, as of now, most of x86-specific code in C2 works just fine > with full-width hardware vectors which are oblivious of their sizes > until RA kicks in. And SVE patch you propose completely omits implicit > predication hardware provides which makes it similar to AVX512 (modulo > wider range of vector width sizes supported). > > So, even though hardware abstractions being used aren't actually *that* > different, vecA piles complexity and introduces a separate way to > achieve similar results (but slightly differently). And that's what > bothers me. I'd like to see more unification instead which should bring > reduction in complexity and an opportunity to address long-standing > technical debt (and 5 flavors of ideal registers for vectors is part of > it IMO). > I can understand that a total solution for different archs and vector sizes is preferable. Do you have any initial idea how to achieve that? > So far, I see 2 main directions for RA work: > > ? (a) support vectors of arbitrary size: > ??? (1) helps push the upper limit on the size (1024-bit) > ??? (2) handle non-power-of-2 sizes > > ? (b) optimize RA implementation for large values > > Anything else? > Yes, and it's not just vector. SVE predicate register has scalable size (vector_size/8) as well. We also have predicate register allocator support well with proposed approach (not in this patch.). > Speaking of (a), in particular, I don't see why possible solution for it > should not supersede vecX et al altogether. > > Also, I may be wrong, but I don't see a clear evidence there's a > pressing need to have all of that fixed right from the beginning. > (That's why I put #1 and #2 options on the table.) Starting with #1/#2 > would untie initial SVE support from the exploratory work needed to > choose the most appropriate solution for (a) and (b). > Staring from partial SVE register support might be acceptable for initial patch (Andrew may not agree :-)), but I think we may end up with more follow-up work, given that our proposed approach already supports SVE well in terms of (a) and (b). If there's no other solution, would it be possible to use current proposed method? It's not difficult to backout our changes in register allocation part, if we find other better solution to support arbitrary vector/predicate sizes in future, as the patch there is actually not big IMO. >>> If I were to start from scratch, I would choose between 3 options: >>> >>> ??? #1: reuse existing VecX/VecY/VecZ ideal registers and limit >>> supported >>> vector sizes to 128-/256-/512-bit values. >>> >>> ??? #2: lift limitation on max size (to 1024/2048 bits), but ignore >>> non-power-of-2 sizes; >>> >>> ??? #3: introduce support for full range of vector register sizes >>> (128-/.../2048-bit with 128-bit step); >>> >>> I see 2 (mostly unrelated) limitations: maximum vector size and >>> non-power-of-2 sizes. >>> >>> My understanding is that you don't try to accurately represent SVE for >>> now, but lay some foundations for future work: you give up on >>> non-power-of-2 sized vectors, but still enable support for arbitrarily >>> sized vectors (addressing both limitations on maximum size and size >>> granularity) in RA (and it affects only spills). So, it is somewhere >>> between #2 and #3. >>> >>> The ultimate goal is definitely #3, but how much more work will be >>> required to teach the JVM about non-power-of-2 vectors? As I see in the >>> patch, you don't have auto-vectorizer support yet, but Vector API will >>> provide access to whatever size hardware exposes. What do you expect on >>> hardware front in the near/mid-term future? Anything supporting vectors >>> larger than 512-bit? What about 384-bit vectors? >>> >> >> I think our patch is now in 3. :-) We do not give up non-power-of-2 >> sized vectors, instead we are supporting them well in this patch. And >> are still using current regmask framework. (Actually, I think the only >> limitation to the vector size is that it should be multiple of 32-bits >> - bits per 1 reg slot.) > >> I am not sure about other Arm partners' hardware implementations in >> the mid-term future, as it's free for cpu implementer to choose any >> max vector sizes as long as it follows SVE architecture specification. >> But we did tested the patch with Vector API on different SVE supported >> vector sizes on emulator, e.g. 384, 768, 1024, 2048 etc. The register >> allocator including the spill/unspill works well on those different >> sizes with Vector API. (Thanks to your great work on Vector API. :-)) >> >> We currently limit the vector size to power-of-2 in >> vm_version_aarch64.cpp, as suggested by Andrew Dinn, is because >> current SLP vectorizer only supports power-of-2 vectors. With Vector >> API in, I think such restriction can be removed. And we are also >> working on a new vectorizer to support predication/mask, which should >> not have power-of-2 limitation. > > [...] > >> Yes, we can make JVM to support portion of vectors, at least for SVE. >> My concern is that the performance wouldn't be as good as the full >> available vector width. > > To be clear: I called it "somewhere between #2 and #3" solely because > auto-vectorizer bails out on non-power-of-2 sizes. And even though > Vector API will work with such cases just fine, IMO having > auto-vectorizer support is required before calling #3 complete. > > In that respect, choosing smaller vector size auto-vectorizer supports > is preferrable to picking up the full-width vectors and turning off > auto-vectorizer (even though Vector API will support them). > > It can be turned into heuristic (by default, pick only power-of-2 sizes; > let users explicitly specify non-power-of-2 sizes), but speaking of > priorities, IMO auto-vectorizer support is more important. > I agree that auto-vectorizer support is more important, and we are working on that. >>> Giving up on #3 for now and starting with less ambitious goals (#1 or >>> #2) would reduce pressure on RA and give more time for additional >>> experiments to come with a better and more universal >>> support/representation of generic/size-agnostic vectors. And, in a >>> longer term, help reducing complexity and technical debt in the area. >>> >>> Some more comments follow inline. >>> >>>>> Compared to x86 w/ AVX512, architectural state for vector registers is >>>>> 4x larger in the worst case (ignoring predicate registers for now). >>>>> Here are the relevant constants on x86: >>>>> >>>>> gensrc/adfiles/adGlobals_x86.hpp: >>>>> >>>>> // the number of reserved registers + machine registers. >>>>> #define REG_COUNT??? 545 >>>>> ... >>>>> // Size of register-mask in ints >>>>> #define RM_SIZE 22 >>>>> >>>>> My estimate is that for AArch64 with SVE support the constants will >>>>> be: >>>>> >>>>> ??? REG_COUNT < 2500 >>>>> ??? RM_SIZE < 100 >>>>> >>>>> which don't look too bad. >>>>> >>>> >>>> Right, but given that most real hardware implementations will be no >>>> larger than 512 bits, I think. Having a large bitmask array, with most >>>> bits useless, will be less efficient for regmask computation. >>> >>> Does it make sense to limit the maximum supported size to 512-bit then >>> (at least, initially)? In that case, the overhead won't be worse it is >>> on x86 now. >>> >> >> Technically, this may be possible though I haven't tried. My concerns >> are: >> >> 1) A larger regmask arrays would be less efficient (we only use 256 >> bits - 8 slots for SVE in this patch), though won't be worse than x86. >> >> 2) Given that current patch already supports larger sizes and >> non-power-of-2 sizes well with relative small size in diff, if we want >> to support other sizes soon, there may be some more work to roll-back >> ad file changes. >> >>>>> Also, I don't see any changes related to stack management. So, I >>>>> assume it continues to be managed in slots. Any problems there? As I >>>>> understand, wide SVE registers are caller-save, so there may be many >>>>> spills of huge vectors around a call. (Probably, not possible with C2 >>>>> auto-vectorizer as it is now, but Vector API will expose it.) >>>>> >>>> >>>> Yes, the stack is still managed in slots, but it will be allocated with >>>> real vector register length instead of 'virtual' slots for VecA. See >>>> the >>>> usages of scalable_reg_slots(), e.g. in chaitin.cpp:1587. We have also >>>> applied the patch to vector api, and did find a lot of vector spills >>>> with expected correct results. >>> >>> I'm curious whether similar problems may arise for spills. Considering >>> wide vector registers are caller-saved, it's possible to have lots of >>> 256-byte values to end up on stack (especially, with Vector API). Any >>> concerns with that? >>> >> >> No, we don't need to have such big (256-byte) slots for a smaller >> vector register. The spill slots are the same size as of real vector >> length, e.g. 48 bytes for 384-bit vector. Even for alignment, we >> currently choose SlotsPerVecA (8 slots for 32 bytes, 256 bits) for >> alignment (skipped slots can still be allocated to other args), which >> is still smaller than AVX512 (64 bytes, 512 bits). We can tweak the >> patch to choose other smaller value, if we think the alignment is too >> large. (Yes, we should always try to avoid spills for wide vectors, >> especially with Vector API, to avoid performance pitfalls.) > > Thanks for the clarifications. > > Any new problems/hitting some limitations envisioned when spilling large > number of huge vectors (2048-bit) on stack? > I haven't seen any so far. > Best regards, > Vladimir Ivanov > >>>>> Have you noticed any performance problems? If that's the case, then >>>>> AVX512 support on x86 would benefit from similar optimization as well. >>>>> >>>> >>>> Do you mean register allocation performance problems? I did not notice >>>> that before. Do you have any suggestion on how to measure that? >>> >>> I'd try to run some applications/benchmarks with -XX:+CITime to get a >>> sense how much RA may be affected. >>> >> >> Thanks! I will give a try. >> >> [1] >> https://urldefense.com/v3/__https://github.com/riscv/riscv-v-spec/releases/tag/0.9__;!!GqivPVa7Brio!IwFEx-c_8JDZcWgXPLcWp2ypX3pr1-IWTBfC7O7PHo7_0skMWtQa4fyWpo-lVor0NFv4Ivo$ >> Thanks, Ningsheng From ningsheng.jian at arm.com Tue Aug 25 10:13:14 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Tue, 25 Aug 2020 18:13:14 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <50271ba1-cc78-a325-aed5-2fc468084515@arm.com> <66a9812d-256d-d8ef-d435-3a18daa6bb1e@redhat.com> <5397e0d1-9d40-0107-c164-304740bc5d7f@arm.com> Message-ID: Hi Erik, On 8/24/20 11:26 PM, Erik ?sterlund wrote: > Hi Ningsheng, > > On 2020-08-24 11:59, Ningsheng Jian wrote: >> Hi Erik, >> >> Thanks for the review! >> >> On 8/22/20 12:21 AM, Erik ?sterlund wrote: >>> Hi, >>> >>> Have you tried this with ZGC on AArch64? It has custom code for saving >>> live registers in the load barrier slow path. >>> I can't see any code changes there, so assuming this will just crash >>> instead. >>> The relevant code is in ZBarrierSetAssembler on aarch64. >>> >>> Maybe I missed something? >>> >> >> I didn't add ZGC option while running tests. I think I need to update >> push_fp() which is called by ZSaveLiveRegisters. But do we need to get >> size info (float/neon/sve) instead of saving the whole vector >> register? Currently, it just simply saves the whole NEON register. > > What we found on x86_64 was that there was a significant cost in saving > vector registers in load barriers. That is why we perform some analysis > so that only the exact registers that are affected, and only the parts > of the registers that are affected, get spilled. It actually mattered. > It will of course work either way, but that was our observation on > x86_64. But I am okay with that being deferred to a separate RFE. I just > wanted to make sure that it at the very least works with the new code, > for a start, so it doesn't start crashing. > OK, I will make it to save the whole reg in this patch and have a separate RFE to optimize as what x86 does. >> And in ZBarrierSetAssembler::load_at(), before calling to runtime >> code, we call push_call_clobbered_registers_except(), which just saves >> floating point registers instead of the whole NEON vector registers. >> Similar behavior in x86 implementation. Is that correct (not saving >> vectors)? > > Yes. The call contexts are: > 1) Interpreter. Does not use vector registers. > 2) Method handle intrinsic. Uses only floats that are part of the Java > calling convention, rest is garbage. No vectors here. > 3) Checkcast arraycopy. Does not use vectors. > Thanks for sharing this. Thanks, Ningsheng From aph at redhat.com Tue Aug 25 11:51:30 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 12:51:30 +0100 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> Message-ID: On 24/08/2020 21:11, Bernhard Urban-Forster wrote: > Updated webrev:http://cr.openjdk.java.net/~burban/8248238/webrev.03/ Can you argue why this is correct? +inline void OrderAccess::release() { + _WriteBarrier(); + __dmb(_ARM64_BARRIER_ISHST); +} + -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 25 11:52:52 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 12:52:52 +0100 Subject: [aarch64-port-dev ] RFR: 8252259: AArch64: Adjust default value of FLOATPRESSURE In-Reply-To: <001101d67aa5$69851450$3c8f3cf0$@alibaba-inc.com> References: <001101d67aa5$69851450$3c8f3cf0$@alibaba-inc.com> Message-ID: On 25/08/2020 07:03, Joshua Zhu wrote: > Therefore I propose the default value of FLOATPRESSURE be 32 because > there are 32 float/SIMD registers on aarch64 and also the value of register > pressure is the same as 1 for each LRG of Op_RegL/Op_RegD/Op_Vec. [3] > > Could you please help review this change? > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252259 > Webrev: http://cr.openjdk.java.net/~jzhu/8252259/webrev.00/ Yes, thanks. I can't remember why FLOATPRESSURE is 64, but it certainly looks like 32 is a much more sensible value. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From vladimir.x.ivanov at oracle.com Tue Aug 25 12:12:38 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 25 Aug 2020 15:12:38 +0300 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <9fd1e3b1-7884-1cf7-64ba-040a16c74425@oracle.com> Message-ID: <5b452edb-2851-f35a-ac30-523d74d95851@oracle.com> > I can understand that a total solution for different archs and vector > sizes is preferable. Do you have any initial idea how to achieve that? I have only ideas right now (unfortunately) :-) So far, my observations from working on refactoring vector support on x86 with Intel folks are the following: (1) full-width register representation is good enough; Though on x86 all vector registers are accurately modeled (register masks properly track sizes and aliasing), it turns out that what matters in practice is aliasing. So, it's enough to use a single "virtual" slot to model XMM, YMM, and ZMM registers all at once unless RA supports packing multiple smaller vector values into a single register (separately managing lower and upper parts of the register; e.g., YMM = XMM(hi):XMM(lo) ). Though currently RA does support it, there are no code which utilizes that and no plans to do that in the future. I believe the situation on AArch64 with NEON and SVE is similar. (And scalable vectors make it harder to support packing in RA.) (2) vector width matters only for spills/refills and reg2reg moves. Matcher does type capturing, so all vector mach nodes keep precise type of the value they produce. On x86 it is heavily used later in code emission phase, but RA still relies on ideal registers (Op_VecX et al). I don't see why RA can't be migrated from ideal registers to types (TypeVect) to determine vector size when performing spilling. From aforementioned observations, I conclude there should be a way to declare a single ideal vector register (Op_Vec) which represents full-width vector supported by the hardware and use captured vector types (TypeVect instances) to guide RA and code generation. And that's the state where I'd like to see vector support in C2 be moving to. Regarding predicate registers, I haven't thought too much about them, so I don't have a strong opinion about whether they should be a separate entity (Op_RegVMask in your patch) or just treated as a vector of bits (Op_Vec). >> So far, I see 2 main directions for RA work: >> >> ?? (a) support vectors of arbitrary size: >> ???? (1) helps push the upper limit on the size (1024-bit) >> ???? (2) handle non-power-of-2 sizes >> >> ?? (b) optimize RA implementation for large values >> >> Anything else? >> > > Yes, and it's not just vector. SVE predicate register has scalable size > (vector_size/8) as well. We also have predicate register allocator > support well with proposed approach (not in this patch.). Though with AVX512 support predicate register support was left aside, I agree that predicate registers should be taken into account from the very beginning. (And glad to hear you are already working on supporting them!) Also, I believe options #1/#2 may be extended to cover predicate registers as well without too much effort. >> Speaking of (a), in particular, I don't see why possible solution for >> it should not supersede vecX et al altogether. >> >> Also, I may be wrong, but I don't see a clear evidence there's a >> pressing need to have all of that fixed right from the beginning. >> (That's why I put #1 and #2 options on the table.) Starting with #1/#2 >> would untie initial SVE support from the exploratory work needed to >> choose the most appropriate solution for (a) and (b). >> > > Staring from partial SVE register support might be acceptable for > initial patch (Andrew may not agree :-)), but I think we may end up with > more follow-up work, given that our proposed approach already supports > SVE well in terms of (a) and (b). If there's no other solution, would it > be possible to use current proposed method? It's not difficult to > backout our changes in register allocation part, if we find other better > solution to support arbitrary vector/predicate sizes in future, as the > patch there is actually not big IMO. Unfortunately, temporary solutions usually end up as permanent ones since there's much less motivation to replace them (and harder to justify the effort) after initial pressure is relieved. I'm OK with the proposed patch if we agree it's a stop-the-gap/temporary solution to the immediate problems you face with initial SVE support and are ready to commit resources into replacing it. That's why I think it's the right time to discuss general direction, work on a plan, and use it to guide the coordinated effort to improve vector support in C2. Also, considering it a stop-the-gap solution means we should strive for the simplest solution and that's another reason I put #1/#2 options on the table to consider. [...] >> Any new problems/hitting some limitations envisioned when spilling >> large number of huge vectors (2048-bit) on stack? >> > > I haven't seen any so far. Ok, good to know. I was curious whether stack representation should also move away from 32-bit slots to a more compact representation. Best regards, Vladimir Ivanov From akozlov at azul.com Tue Aug 25 12:46:06 2020 From: akozlov at azul.com (Anton Kozlov) Date: Tue, 25 Aug 2020 15:46:06 +0300 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> <907599c1-6040-2727-1bd1-239400827d3c@azul.com> Message-ID: Hi Andrew, On 19.08.2020 20:03, Andrew Haley wrote: >> Compared to the current patch, I don't think such template would be less >> error-prone or more maintainable. I would stick to the current version. > > OK. I rather like the template version: it's clear to me what the > intention is. But I agree it's marginal. > Does this count for the positive review? I assume concerns from you[1] and Bernhard[2] are resolved. And no more had followed. I would ask a colleague to sponsor this to jdk/jdk then. [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042733.html [2] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042731.html From vladimir.x.ivanov at oracle.com Tue Aug 25 13:18:12 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 25 Aug 2020 16:18:12 +0300 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <35f8801f-4383-4804-2a9b-5818d1bda763@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <35f8801f-4383-4804-2a9b-5818d1bda763@redhat.com> Message-ID: <524a4aaa-3cf7-7b5e-3e0e-0fd7f4f89fbf@oracle.com> Hi Andrew, I elaborated on some of the points in the thread with Ningsheng. I put my responses in-line, but will try to avoid repeating myself too much. >>> The ultimate goal was to move to vectors which represent full-width >>> hardware registers. After we were convinced that it will work well in AD >>> files, we encountered some inefficiencies with vector spills: depending >>> on actual hardware, smaller (than available) vectors may be used (e.g., >>> integer computations on AVX-capable CPU). So, we stopped half-way and >>> left post-matching part intact: depending on actual vector value width, >>> appropriate operand (vecX/vecY/vecZ + legacy variants) is chosen. >>> >>> (I believe you may be in a similar situation on AArch64 with NEON vs SVE >>> where both 128-bit and wide SVE vectors may be used at runtime.) > > Your problem here seems to be a worry about spilling more data than is > actually needed. As Ningsheng pointed out the amount of data spilled is > determined by the actual length of the VecA registers, not by the > logical size of the VecA mask (256 bits) nor by the maximum possible > size of a VecA register on future architectures (2048 bits). So, no more > stack space will be used than is needed to preserve the live bits that > need preserving. I described the experience with doing a similar exercise on x86: migrating away from [leg]vec[SDXYZ] operands to a uniform size-agnostic representation (legVec/vec). The only problem with abandoning Op_VecX et al was the need to track the size of vector values in RA. >>> Unfortunately, it extends the implementation in orthogonal direction >>> which looks too aarch64-specific to benefit other architectures and x86 >>> particular. I believe there's an alternative approach which can benefit >>> both aarch64 and x86, but it requires more experimentation. >>> >> >> Since vecA and vecX (and others) are architecturally different vector >> registers, I think it's quite natural that we just introduced the new >> vector register type vecA, to represent what we need for corresponding >> hardware vector register. Please note that in vector length agnostic >> ISA, like Arm SVE and RISC-V vector extension [1], the vector registers >> are architecturally the same type of register despite the different >> hardware implementations. > > Yes, I also see this as quite natural. Ningsheng's change extends the > implementation in the architecture-specific direction that is needed for > AArch64's vector model. The fact that this differs from x86_64 is not > unexpected. And still C2 can model them in a similar way. Moreover, recent changes on x86 I described brings x86 very close to SVE. (I elaborated on that in the previous response to Ningsheng.) >>> If I were to start from scratch, I would choose between 3 options: >>> >>> ??? #1: reuse existing VecX/VecY/VecZ ideal registers and limit supported >>> vector sizes to 128-/256-/512-bit values. >>> >>> ??? #2: lift limitation on max size (to 1024/2048 bits), but ignore >>> non-power-of-2 sizes; >>> >>> ??? #3: introduce support for full range of vector register sizes >>> (128-/.../2048-bit with 128-bit step); >>> >>> I see 2 (mostly unrelated) limitations: maximum vector size and >>> non-power-of-2 sizes. > > Yes, but this patch deals with both of those and I cannot see it causing > any problems for x86_64 nor do I see it adding any great complexity. The > extra shard paths deal with scalable vectors wich onlu occur on AArch64. > A scalable VecA register (and also eventually the scalable predicate > register) caters for all possible vector sizes via a single 'logical' > vector of size 8 slots (also eventually a single 'logical' predicate > register of size 1 slot). Catering for scalable registers in shared code > is localized and does not change handling of the existing, non-scalable > VecX/Y/Z registers. Code needed for vector support in C2 has been growing in size over the years and now it comprises a noticeable part of the compiler. And it got there through relatively small incremental and localized changes. I agree that the proposed solution demonstrates a very clever way to overcome some of the limitations imposed by existing implementation. But it is still a workaround which only emphasizes the architectural limitations. And it's not specific to AArch64 with SVE: x86 stretches it hard as well (though in a slightly different direction) which FTR forced recent migration to "generic vectors". So, instead of proceeding with incremental changes and accumulating complexity (and technical debt along the way), I suggest to look into reworking vector support and making it relevant to the modern hardware (both x86 and AArch64). >>> My understanding is that you don't try to accurately represent SVE for >>> now, but lay some foundations for future work: you give up on >>> non-power-of-2 sized vectors, but still enable support for arbitrarily >>> sized vectors (addressing both limitations on maximum size and size >>> granularity) in RA (and it affects only spills). So, it is somewhere >>> between #2 and #3. > > I have to disagree with your statement that this proposal doesn't > 'accurately' represent SVE. Yes, the vector mask for this arbitrary-size > vector is modelled 'logically' using a nominal 8 slots. However, that is > merely to avoid wasting bits in the bit masks plus cpu time processing > them. The 'physical' vector length models the actual number of slots, > and includes the option to model a non-power of two. That 'physical' > size is used in all operations that manipulate VecA register contents. > So, although I grant that the code is /parameterized/, it is also 100% > accurate. My point is: the proposed solution makes a number of simplifying assumptions which makes it much easier to support SVE (e.g., VecA represents full-width vector which completely ignores implicit predication provided by the ISA). >>> The ultimate goal is definitely #3, but how much more work will be >>> required to teach the JVM about non-power-of-2 vectors? As I see in the >>> patch, you don't have auto-vectorizer support yet, but Vector API will >>> provide access to whatever size hardware exposes. What do you expect on >>> hardware front in the near/mid-term future? Anything supporting vectors >>> larger than 512-bit? What about 384-bit vectors? > > Do we need to know for sure such hardware is going to arrive in order to > allow for it now? If there were a significant cost to doing so I'd maybe > say yes but I don't really see one here. Most importantly, the changes > to the AArch64 register model and small changes to the shared > chaitin/reg mask code proposed here already work with the > auto-vectorizer if the VecA slots are any of the possible powers of 2 > VecA sizes. > > The extra work needed to profit from non-power-of-two vector involves > upgrading the auto-vectorizer code. While this may be tricky I don't see > ti as impossible. However, more importantly, even if such an upgrade > cannot be achieved then this proposal is still a very simple way to > allow for arbitrarily scalable SVE vectors that are a power of two size. > It also allows any architecture with a non-power of two to work with the > lowest power of two that fits. So, this is a very siple way to cater for > what may turn up. If it makes options #1/#2 viable, then there's no need to change shared code at all. Choosing between no code changes and low risk / small code changes which won't be used in practice, I'm strongly in favor of the former. >>> For larger vectors #2 (or a mix of #1 and #2) may be a good fit. My >>> understanding that existing RA machinery should support 1024-bit vectors >>> well. So, unless 2048-bit vectors are needed, we could live with the >>> framework we have right now. > > I'm not sure what you are proposing here but it sounds like introducing > extra vectors beyond VecX, VecY for larger powers of two i.e. VecZ, > vecZZ, VecZZZ ... and providing separate case processing for each of > them where the relevant case is selected conditional on the actual > vector size. Is that what you are proposing? I can't see any virtue in > multiplying case handling fore ach new power-of-two size that turns up > when all possible VecZ* power-of-two options can actually be handled as > one uniform case. Option #1 doesn't require anything more than Vec[SDXYZ]. Option #2 assumes 1 more operand & ideal register for 1024-bit. As Ningsheng pointed out, without introducing length-agnostic vectors, supporting 2048-bit vectors require changes in RegMask to accommodate for values spanning 64 slots. >>> Giving up on #3 for now and starting with less ambitious goals (#1 or >>> #2) would reduce pressure on RA and give more time for additional >>> experiments to come with a better and more universal >>> support/representation of generic/size-agnostic vectors. And, in a >>> longer term, help reducing complexity and technical debt in the area. > > Can you explain what you mean by 'reduce pressure on RA'? I'm also > unclear as to what you see as complex about this proposal. IMO vector support already introduces significant complexity in C2. Adding platform-specific features will only increase it. So, I'm in favor of reworking the support than applying band-aids to relax some inherent limitations of it. >>> Some more comments follow inline. >>> >>>>> Compared to x86 w/ AVX512, architectural state for vector registers is >>>>> 4x larger in the worst case (ignoring predicate registers for now). >>>>> Here are the relevant constants on x86: >>>>> >>>>> gensrc/adfiles/adGlobals_x86.hpp: >>>>> >>>>> // the number of reserved registers + machine registers. >>>>> #define REG_COUNT??? 545 >>>>> ... >>>>> // Size of register-mask in ints >>>>> #define RM_SIZE 22 >>>>> >>>>> My estimate is that for AArch64 with SVE support the constants will be: >>>>> >>>>> ??? REG_COUNT < 2500 >>>>> ??? RM_SIZE < 100 >>>>> >>>>> which don't look too bad. > > I'm not sure what these numbers are meant to mean. The number of SVE > vector registers is the same as the number of NEON vector registers i.e. > 32. The register mask size for VecA registers is 8 * 32 bits. I attempted to estimate the sizes of relevant structures if VecA is modelled the same way as VecX et al. >>>> Right, but given that most real hardware implementations will be no >>>> larger than 512 bits, I think. Having a large bitmask array, with most >>>> bits useless, will be less efficient for regmask computation. >>> >>> Does it make sense to limit the maximum supported size to 512-bit then >>> (at least, initially)? In that case, the overhead won't be worse it is >>> on x86 now. > > Well, no. It doesn't make sense when all you need is a 'logical' 8 * 32 > bit mask whatever the actual 'physical' register size is. I asked that question in a different context trying to get a sense of other simplifying assumptions which could be made in the initial implementation. But you should definitely prefer 1-slot design for vector registers then ;-) Best regards, Vladimir Ivanov From aph at redhat.com Tue Aug 25 15:47:39 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 16:47:39 +0100 Subject: [aarch64-port-dev ] RFR(s): 8251930: AArch64: Native types mismatch in hotspot In-Reply-To: References: <1de462b7-e28a-deae-3993-f7e7056e1235@azul.com> <2ae0b111-f610-ac01-cb7d-0d7578536de9@redhat.com> <907599c1-6040-2727-1bd1-239400827d3c@azul.com> Message-ID: <00cc6c76-feaf-57eb-f985-71e2aa03f1ba@redhat.com> On 25/08/2020 13:46, Anton Kozlov wrote: > Hi Andrew, > > On 19.08.2020 20:03, Andrew Haley wrote: >>> Compared to the current patch, I don't think such template would be less >>> error-prone or more maintainable. I would stick to the current version. >> >> OK. I rather like the template version: it's clear to me what the >> intention is. But I agree it's marginal. >> > > Does this count for the positive review? I assume concerns from you[1] and > Bernhard[2] are resolved. And no more had followed. I would ask a colleague to > sponsor this to jdk/jdk then. > > [1] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042733.html > [2] https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-August/042731.html OK. I'm sorry I wasn't clear enough. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Tue Aug 25 16:55:38 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 25 Aug 2020 17:55:38 +0100 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: References: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> <67e67230-cac7-d940-1cca-6ab4e8cba8d4@redhat.com> <9e792a33-4f90-8829-2f7b-158d07d3fd15@bell-sw.com> Message-ID: On 24/08/2020 22:52, Dmitry Chuyko wrote: > > I added two more intrinsics -- for copySign, they are controlled by > UseCopySignIntrinsic flag. > > webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.03/ > > It also contains 'benchmarks' directory: > http://cr.openjdk.java.net/~dchuyko/8251525/webrev.03/benchmarks/ > > There are 8 benchmarks there: (double | float) x (blackhole | reduce) x > (current j.l.Math.signum | abs()>0 check). > > My results on Arm are in signum-facgt-copysign.ods. Main case is > 'random' which is actually a random from positive and negative numbers > between -0.5 and +0.5. > > Basically we have ~14% improvement in 'reduce' benchmark variant but > ~20% regression in 'blackhole' variant in case of only copySign() > intrinsified. > > Same picture if abs()>0 check is used in signum() (+-5%). This variant > is included as it shows very good results on x86. > > Intrinsic for signum() gives improvement of main case in both > 'blackhole' and 'reduce' variants of benchmark: 28% and 11%, which is a > noticeable difference. Ignoring Blackhole for the moment, this is what I'm seeing for the reduction/random case: Benchmark Mode Cnt Score Error Units ThunderX 2: -XX:-UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 2.456 ? 0.065 ns/op -XX:+UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 2.766 ? 0.107 ns/op -XX:-UseSignumIntrinsic -XX:+UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 2.537 ? 0.770 ns/op Neoverse N1 (Actually Amazon m6g.16xlarge): -XX:-UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 1.173 ? 0.001 ns/op -XX:+UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 1.043 ? 0.022 ns/op -XX:-UseSignumIntrinsic -XX:+UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 1.012 ? 0.001 ns/op By your own numbers, in the reduce benchmark the signum intrinsic is worse than default for all 0 and NaN, but about 12% better for random, >0, and <0. If you take the average of the sppedups and slowdowns it's actually worse than default. By my reckoning, if you take all possibilities (Nan, <0, >0, 0, Random) into account, the best-performing on the reduce test is actually Abs/Copysign, but there's very little in it. The only time that the signum intrinsic actually wins is when you're storing the result into memory *and* flushing the store buffer. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Wed Aug 26 08:53:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Aug 2020 10:53:25 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp Message-ID: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> Hi, This is aarch64-port/jdk8u-shenandoah specific issue: https://bugs.openjdk.java.net/browse/JDK-8252366 The assert seems to fail on ppc64. Also, we might inline g1_write_barrier_pre_helper for clarity. 8u webrev: https://cr.openjdk.java.net/~shade/8252366/webrev.01/ Testing: x86_64 hotspot_gc_shenandoah -- Thanks, -Aleksey From yueshi.zwj at alibaba-inc.com Wed Aug 26 09:05:17 2020 From: yueshi.zwj at alibaba-inc.com (Joshua Zhu) Date: Wed, 26 Aug 2020 17:05:17 +0800 Subject: [aarch64-port-dev ] RFR: 8252259: AArch64: Adjust default value of FLOATPRESSURE In-Reply-To: References: <001101d67aa5$69851450$3c8f3cf0$@alibaba-inc.com> Message-ID: <003801d67b88$04e60340$0eb209c0$@alibaba-inc.com> Andrew, thanks a lot for your review. Ningsheng, could you please help push this change? Best Regards, Joshua > -----Original Message----- > From: Andrew Haley > Sent: 2020?8?25? 19:53 > To: Joshua Zhu ; hotspot-compiler- > dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR: 8252259: AArch64: Adjust default value of > FLOATPRESSURE > > On 25/08/2020 07:03, Joshua Zhu wrote: > > Therefore I propose the default value of FLOATPRESSURE be 32 because > > there are 32 float/SIMD registers on aarch64 and also the value of > > register pressure is the same as 1 for each LRG of > > Op_RegL/Op_RegD/Op_Vec. [3] > > > > Could you please help review this change? > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252259 > > Webrev: http://cr.openjdk.java.net/~jzhu/8252259/webrev.00/ > > Yes, thanks. I can't remember why FLOATPRESSURE is 64, but it certainly looks > like 32 is a much more sensible value. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rwestrel at redhat.com Wed Aug 26 09:10:15 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 26 Aug 2020 11:10:15 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp In-Reply-To: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> References: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> Message-ID: <875z957oy0.fsf@redhat.com> > This is aarch64-port/jdk8u-shenandoah specific issue: > https://bugs.openjdk.java.net/browse/JDK-8252366 > > The assert seems to fail on ppc64. Also, we might inline g1_write_barrier_pre_helper for clarity. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8252366/webrev.01/ I don't see where on this code path a load barrier would be added. Am I missing something? Roland. From aph at redhat.com Wed Aug 26 09:13:37 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Aug 2020 10:13:37 +0100 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp Message-ID: > This is aarch64-port/jdk8u-shenandoah specific issue: > https://bugs.openjdk.java.net/browse/JDK-8252366 > > The assert seems to fail on ppc64. Also, we might inline g1_write_barrier_pre_helper for clarity. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8252366/webrev.01/ > > Testing: x86_64 hotspot_gc_shenandoah OK, thanks. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From shade at redhat.com Wed Aug 26 09:20:22 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Aug 2020 11:20:22 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8 -> aarch64-port/jdk8u-shenandoah, 2020-08-26 Message-ID: Hi, I would like to integrate the usual round of sh/jdk8 backports to aarch64-port/jdk8u-shenandoah. Only hotspot repository is affected, and the merge is clean there. Since we need to coordinate the push with Andrew Hughes, I did not tag it yet. It would be something like "aarch64-shenandoah-jdk8u272-b03-shenandoah-merge-2020-08-26". 8u webrev: https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200826/webrev.01/ Testing: hotspot_gc_shenandoah; plus, this was tested with sh/jdk8 CIs -- Thanks, -Aleksey From shade at redhat.com Wed Aug 26 09:22:44 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Aug 2020 11:22:44 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp In-Reply-To: <875z957oy0.fsf@redhat.com> References: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> <875z957oy0.fsf@redhat.com> Message-ID: On 8/26/20 11:10 AM, Roland Westrelin wrote: >> This is aarch64-port/jdk8u-shenandoah specific issue: >> https://bugs.openjdk.java.net/browse/JDK-8252366 >> >> The assert seems to fail on ppc64. Also, we might inline g1_write_barrier_pre_helper for clarity. >> >> 8u webrev: >> https://cr.openjdk.java.net/~shade/8252366/webrev.01/ > > I don't see where on this code path a load barrier would be added. Am I > missing something? I don't think you are missing anything. There seems to be no barrier on that path, argh! But this does not relate to this RFR, and would be handled separately. -- Thanks, -Aleksey From ningsheng.jian at arm.com Wed Aug 26 09:31:41 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 26 Aug 2020 17:31:41 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <5b452edb-2851-f35a-ac30-523d74d95851@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <9fd1e3b1-7884-1cf7-64ba-040a16c74425@oracle.com> <5b452edb-2851-f35a-ac30-523d74d95851@oracle.com> Message-ID: <15ea964d-6605-7ba4-63bc-e61007407ed8@arm.com> Hi Vladimir, On 8/25/20 8:12 PM, Vladimir Ivanov wrote: > [...] > > So, it's enough to use a single "virtual" slot to model XMM, YMM, and > ZMM registers all at once unless RA supports packing multiple smaller > vector values into a single register (separately managing lower and > upper parts of the register; e.g., YMM = XMM(hi):XMM(lo) ). Though > currently RA does support it, there are no code which utilizes that and > no plans to do that in the future. > > I believe the situation on AArch64 with NEON and SVE is similar. (And > scalable vectors make it harder to support packing in RA.) > Right. > ? (2) vector width matters only for spills/refills and reg2reg moves. > > Matcher does type capturing, so all vector mach nodes keep precise type > of the value they produce. On x86 it is heavily used later in code > emission phase, but RA still relies on ideal registers (Op_VecX et al). > I don't see why RA can't be migrated from ideal registers to types > (TypeVect) to determine vector size when performing spilling. > > From aforementioned observations, I conclude there should be a way to > declare a single ideal vector register (Op_Vec) which represents > full-width vector supported by the hardware and use captured vector > types (TypeVect instances) to guide RA and code generation. And that's > the state where I'd like to see vector support in C2 be moving to. > That may be true. I think we can move forward step-by-step for easy maintenance. > Regarding predicate registers, I haven't thought too much about them, so > I don't have a strong opinion about whether they should be a separate > entity (Op_RegVMask in your patch) or just treated as a vector of bits > (Op_Vec). > >>> So far, I see 2 main directions for RA work: >>> >>> ?? (a) support vectors of arbitrary size: >>> ???? (1) helps push the upper limit on the size (1024-bit) >>> ???? (2) handle non-power-of-2 sizes >>> >>> ?? (b) optimize RA implementation for large values >>> >>> Anything else? >>> >> >> Yes, and it's not just vector. SVE predicate register has scalable >> size (vector_size/8) as well. We also have predicate register >> allocator support well with proposed approach (not in this patch.). > > Though with AVX512 support predicate register support was left aside, I > agree that predicate registers should be taken into account from the > very beginning. (And glad to hear you are already working on supporting > them!) > As that's one of the main feature of SVE, we have to do that. :-) With initial SVE support in, our further work on that could be easier. > Also, I believe options #1/#2 may be extended to cover predicate > registers as well without too much effort. > >>> Speaking of (a), in particular, I don't see why possible solution for >>> it should not supersede vecX et al altogether. >>> >>> Also, I may be wrong, but I don't see a clear evidence there's a >>> pressing need to have all of that fixed right from the beginning. >>> (That's why I put #1 and #2 options on the table.) Starting with >>> #1/#2 would untie initial SVE support from the exploratory work >>> needed to choose the most appropriate solution for (a) and (b). >>> >> >> Staring from partial SVE register support might be acceptable for >> initial patch (Andrew may not agree :-)), but I think we may end up >> with more follow-up work, given that our proposed approach already >> supports SVE well in terms of (a) and (b). If there's no other >> solution, would it be possible to use current proposed method? It's >> not difficult to backout our changes in register allocation part, if >> we find other better solution to support arbitrary vector/predicate >> sizes in future, as the patch there is actually not big IMO. > > Unfortunately, temporary solutions usually end up as permanent ones > since there's much less motivation to replace them (and harder to > justify the effort) after initial pressure is relieved. > > I'm OK with the proposed patch if we agree it's a stop-the-gap/temporary > solution to the immediate problems you face with initial SVE support and > are ready to commit resources into replacing it. > Yes, we will continue to maintain and improve it. Our idea might be Arm biased :), so we will need collaborations and suggestions from the community. > That's why I think it's the right time to discuss general direction, > work on a plan, and use it to guide the coordinated effort to improve > vector support in C2. > > Also, considering it a stop-the-gap solution means we should strive for > the simplest solution and that's another reason I put #1/#2 options on > the table to consider. > > [...] > >>> Any new problems/hitting some limitations envisioned when spilling >>> large number of huge vectors (2048-bit) on stack? >>> >> >> I haven't seen any so far. > > Ok, good to know. > > I was curious whether stack representation should also move away from > 32-bit slots to a more compact representation. > I think that's possible, if we could also have the alignment handled. Thanks, Ningsheng From Ningsheng.Jian at arm.com Wed Aug 26 09:43:23 2020 From: Ningsheng.Jian at arm.com (Ningsheng Jian) Date: Wed, 26 Aug 2020 09:43:23 +0000 Subject: [aarch64-port-dev ] RFR: 8252259: AArch64: Adjust default value of FLOATPRESSURE In-Reply-To: <003801d67b88$04e60340$0eb209c0$@alibaba-inc.com> References: <001101d67aa5$69851450$3c8f3cf0$@alibaba-inc.com> <003801d67b88$04e60340$0eb209c0$@alibaba-inc.com> Message-ID: Pushed. Regards, Ningsheng > -----Original Message----- > From: Joshua Zhu > Sent: Wednesday, August 26, 2020 5:05 PM > To: 'Andrew Haley' ; hotspot-compiler-dev at openjdk.java.net; > Ningsheng Jian > Cc: aarch64-port-dev at openjdk.java.net > Subject: RE: [aarch64-port-dev ] RFR: 8252259: AArch64: Adjust default value of > FLOATPRESSURE > > Andrew, thanks a lot for your review. > Ningsheng, could you please help push this change? > > Best Regards, > Joshua > > > -----Original Message----- > > From: Andrew Haley > > Sent: 2020?8?25? 19:53 > > To: Joshua Zhu ; hotspot-compiler- > > dev at openjdk.java.net > > Cc: aarch64-port-dev at openjdk.java.net > > Subject: Re: [aarch64-port-dev ] RFR: 8252259: AArch64: Adjust default > > value of FLOATPRESSURE > > > > On 25/08/2020 07:03, Joshua Zhu wrote: > > > Therefore I propose the default value of FLOATPRESSURE be 32 because > > > there are 32 float/SIMD registers on aarch64 and also the value of > > > register pressure is the same as 1 for each LRG of > > > Op_RegL/Op_RegD/Op_Vec. [3] > > > > > > Could you please help review this change? > > > > > > JBS: https://bugs.openjdk.java.net/browse/JDK-8252259 > > > Webrev: http://cr.openjdk.java.net/~jzhu/8252259/webrev.00/ > > > > Yes, thanks. I can't remember why FLOATPRESSURE is 64, but it > > certainly looks like 32 is a much more sensible value. > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Wed Aug 26 09:49:43 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 26 Aug 2020 11:49:43 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8 -> aarch64-port/jdk8u-shenandoah, 2020-08-26 In-Reply-To: References: Message-ID: Looks good to me. Thanks, Roman Am Mittwoch, den 26.08.2020, 11:20 +0200 schrieb Aleksey Shipilev: > Hi, > > I would like to integrate the usual round of sh/jdk8 backports to > aarch64-port/jdk8u-shenandoah. > > Only hotspot repository is affected, and the merge is clean there. > Since we need to coordinate the > push with Andrew Hughes, I did not tag it yet. It would be something > like > "aarch64-shenandoah-jdk8u272-b03-shenandoah-merge-2020-08-26". > > 8u webrev: > > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200826/webrev.01/ > > Testing: hotspot_gc_shenandoah; plus, this was tested with sh/jdk8 > CIs > From rkennke at redhat.com Wed Aug 26 10:13:39 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 26 Aug 2020 12:13:39 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp In-Reply-To: <875z957oy0.fsf@redhat.com> References: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> <875z957oy0.fsf@redhat.com> Message-ID: <4c29fbb37608c2843c54a2f6430ebfa9a3293893.camel@redhat.com> Am Mittwoch, den 26.08.2020, 11:10 +0200 schrieb Roland Westrelin: > > This is aarch64-port/jdk8u-shenandoah specific issue: > > https://bugs.openjdk.java.net/browse/JDK-8252366 > > > > The assert seems to fail on ppc64. Also, we might inline > > g1_write_barrier_pre_helper for clarity. > > > > 8u webrev: > > https://cr.openjdk.java.net/~shade/8252366/webrev.01/ > > I don't see where on this code path a load barrier would be added. Am > I > missing something? It looks like we added this assert there: assert(elembt != T_OBJECT && elembt != T_ARRAY, "sanity"); (which you actually removed in your patch) It looks like this is not actually used for reference types. The only uses are in library_call.cpp and they don't look like they ever load a reference. Please check and confirm to be sure. Roman From rwestrel at redhat.com Wed Aug 26 11:01:54 2020 From: rwestrel at redhat.com (Roland Westrelin) Date: Wed, 26 Aug 2020 13:01:54 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp In-Reply-To: <4c29fbb37608c2843c54a2f6430ebfa9a3293893.camel@redhat.com> References: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> <875z957oy0.fsf@redhat.com> <4c29fbb37608c2843c54a2f6430ebfa9a3293893.camel@redhat.com> Message-ID: <8736497jrx.fsf@redhat.com> > It looks like this is not actually used for reference types. The only > uses are in library_call.cpp and they don't look like they ever load a > reference. Please check and confirm to be sure. It does on PPC. In LibraryCallKit::get_key_start_from_aescrypt_object(). Roland. From shade at redhat.com Wed Aug 26 11:08:52 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 26 Aug 2020 13:08:52 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp In-Reply-To: <8736497jrx.fsf@redhat.com> References: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> <875z957oy0.fsf@redhat.com> <4c29fbb37608c2843c54a2f6430ebfa9a3293893.camel@redhat.com> <8736497jrx.fsf@redhat.com> Message-ID: On 8/26/20 1:01 PM, Roland Westrelin wrote: >> It looks like this is not actually used for reference types. The only >> uses are in library_call.cpp and they don't look like they ever load a >> reference. Please check and confirm to be sure. > > It does on PPC. In LibraryCallKit::get_key_start_from_aescrypt_object(). Yes. I misjudged the assert: it actually verifies the current Shenandoah uses do not need the LRB there. Shenandoah is not supported (yet) on PPC, so there is no bug yet, and assert is just too strong for PPC code. But it feels more future proof just to insert the Shenandoah barrier there. 8u webrev: https://cr.openjdk.java.net/~shade/8252366/webrev.02/ Testing: hotspot_gc_shenandoah {fastdebug,release} -- Thanks, -Aleksey From rkennke at redhat.com Wed Aug 26 11:15:31 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 26 Aug 2020 13:15:31 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp In-Reply-To: References: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> <875z957oy0.fsf@redhat.com> <4c29fbb37608c2843c54a2f6430ebfa9a3293893.camel@redhat.com> <8736497jrx.fsf@redhat.com> Message-ID: <90ec029af2e070057d782b1ea91be2a00ef6ff9a.camel@redhat.com> Am Mittwoch, den 26.08.2020, 13:08 +0200 schrieb Aleksey Shipilev: > On 8/26/20 1:01 PM, Roland Westrelin wrote: > > > It looks like this is not actually used for reference types. The > > > only > > > uses are in library_call.cpp and they don't look like they ever > > > load a > > > reference. Please check and confirm to be sure. > > > > It does on PPC. In > > LibraryCallKit::get_key_start_from_aescrypt_object(). > > Yes. I misjudged the assert: it actually verifies the current > Shenandoah uses do not need the LRB > there. Shenandoah is not supported (yet) on PPC, so there is no bug > yet, and assert is just too > strong for PPC code. But it feels more future proof just to insert > the Shenandoah barrier there. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8252366/webrev.02/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} Looks good. It's unfortunate that we currently have no way to verify if it works or not, though. It's currently dead code and if we ever backport an intrinsic that needs it, we hope for the best. Roman From beurba at microsoft.com Wed Aug 26 11:52:49 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Wed, 26 Aug 2020 11:52:49 +0000 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> , Message-ID: On 25/08/2020 11:44, Andrew Haley wrote: > Looks OK. It would be nice if you could get rid of some of the #ifndef > _WIN64 stuff in common code by moving queries like icache_line_size() > into os-specific files, but you may do that later. I agree, there are still a few opportunities to make it cleaner. I'll take care of it. Most _WIN64 ifdefs are around the calling convention difference (r18 being used for TLS by the Windows). As it turns out the ABI on macOS reserves r18 for the OS as well [1]. So I suggested that we introduce `R18_RESERVED` which would replace the _WIN64 ifdefs. Does that sound good? Thanks, -Bernhard [1] https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html Yes it's the iOS ABI, but the Apple documentation points to it for macOS here: https://developer.apple.com/documentation/apple_silicon/addressing_architectural_differences_in_your_macos_code From beurba at microsoft.com Wed Aug 26 12:05:27 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Wed, 26 Aug 2020 12:05:27 +0000 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> , Message-ID: On 25/08/2020 13:51, Andrew Haley wrote: > Can you argue why this is correct? > > +inline void OrderAccess::release() { > + _WriteBarrier(); > + __dmb(_ARM64_BARRIER_ISHST); > +} Not exactly sure what your questions is. _WriteBarrier() is the compiler barrier [1] while __dmb() is the intrinsic [2] for said ARM64 instruction (note, it's not the macro assembler one). -Bernhard [1] https://docs.microsoft.com/en-us/cpp/intrinsics/writebarrier?view=vs-2019 [2] https://docs.microsoft.com/en-us/cpp/intrinsics/arm64-intrinsics?view=vs-2019 From adinn at redhat.com Wed Aug 26 12:54:26 2020 From: adinn at redhat.com (Andrew Dinn) Date: Wed, 26 Aug 2020 13:54:26 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <524a4aaa-3cf7-7b5e-3e0e-0fd7f4f89fbf@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <35f8801f-4383-4804-2a9b-5818d1bda763@redhat.com> <524a4aaa-3cf7-7b5e-3e0e-0fd7f4f89fbf@oracle.com> Message-ID: <670fad6f-16ff-a7b3-8775-08dd79809ddf@redhat.com> Hi Vladimir, On 25/08/2020 14:18, Vladimir Ivanov wrote: > I elaborated on some of the points in the thread with Ningsheng. > > I put my responses in-line, but will try to avoid repeating myself too > much. Thanks for the response and also clarification in replies to Ningsheng. So, if I can summarize (please correct me if I misunderstand): You are as concerned about existing complexity in vector handling as much as complexity added by this patch, whether the latter is to AArch64 code or shared code. The goal you would like to achieve is a single set of rules for a single kind of vector register whose size is parameterized, the appropriate value being derived from each specific vector operation. Your main concern about this patch is that it adds yet another additional vector kind to the current 'wrong' multi-kind vector model and, what is worse, one with a different behaviour, taking us further from your desired goal. Your other concern is that this design does not allow for the AArch64 ISA predication or, indeed, for what you treat uniformly as the 'implicit' predication imposed on a 'logical' max vector size (2048 bits) by the specific AVX/SVE/NEON hardware vector size. > But you should definitely prefer 1-slot design for vector registers then > ;-) Indeed I do :-] So, let me respond to the above summary points, assuming I have them down right. I agree that your end goal is highly desirable. However, we are not there yet and since your attempts to do so have not succeeded so far I don't think that means we are compelled to drop the current patch. As you say this could (and, if it is adopted, should) be regarded as a useful stop-gap until we come up with a unified, parameterized vector implementation that makes it redundant. That said, I'm not pushing hard to keep the patch if the consequence is generating significant work later to undo it. The number of users who might benefit from using SVE vectors from Java now or in the near future does not look like it is going to be very large (if you are not making a lot of use of SVE registers then that is a lot of wasted silicon and I suspect it's going to be the rare case that someone codes an app in Java that needs to make continuous use of SVE -- mind you, by the same token I guess that also applies for AVX on Intel). I'm not sure pushing this now will add a lot more work later. It seems to me that this code is actually moving in the right direction for the sort of solution you want. The AArch64 VecA register /is/ size-parameterized, albeit by a size fixed at startup rather than per operation. So, that's one reason why I don't know if this implies a lot more rework to move towards your desired goal. Surely, if we do arrive at a unifying vector model that can replace the existing multi-kind vectors then it ought to be able to subsume this code - unless of course it replaces it wholesale. Are you concerned that adding this patch will result in more cases to pick through and correct? Are you worried that we might have to withdraw some of the support this patch enables to arrive at the final goal? Also, Ningsheng and his colleagues have laid some foundations for implementing predicated operations with this patch and have that work in the pipeline. Once again this is moving towards the desired goal even if it might end up doign so in a slightly sideways fashion. Perhaps we could continue this stop-gap experiment as an experimental option in order to learn from the experience? regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Wed Aug 26 12:59:48 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Aug 2020 13:59:48 +0100 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> Message-ID: On 26/08/2020 12:52, Bernhard Urban-Forster wrote: > Most _WIN64 ifdefs are around the calling convention difference (r18 being used for TLS by the Windows). As it turns out the ABI on macOS reserves r18 for the OS as well [1]. So I suggested that we introduce `R18_RESERVED` which would replace the _WIN64 ifdefs. Does that sound good? That's definitely more understandable where it's really needed. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Aug 26 13:05:28 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Aug 2020 14:05:28 +0100 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> Message-ID: On 26/08/2020 13:05, Bernhard Urban-Forster wrote: > On 25/08/2020 13:51, Andrew Haley wrote: >> Can you argue why this is correct? >> >> +inline void OrderAccess::release() { >> + _WriteBarrier(); >> + __dmb(_ARM64_BARRIER_ISHST); >> +} > > Not exactly sure what your questions is. _WriteBarrier() is the compiler barrier [1] while __dmb() is the intrinsic [2] for said ARM64 instruction (note, it's not the macro assembler one). DMB ST is not a release barrier. It's only a StoreStore; release needs LoadStore|StoreStore. See the spec for DMB. But surely Microsoft C++ knows how to emit a release barrier. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From beurba at microsoft.com Wed Aug 26 15:04:24 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Wed, 26 Aug 2020 15:04:24 +0000 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> , Message-ID: On 26/08/2020 15:05, Andrew Haley wrote: > DMB ST is not a release barrier. It's only a StoreStore; release needs > LoadStore|StoreStore. See the spec for DMB. But surely Microsoft C++ > knows how to emit a release barrier. Apparently it doesn't know :-( _WriteBarrier is a nop what code generation is concerned, so it will emit a dmb ishst. How this doesn't cause any major issues is beyond my understanding. FWIW the Linux implementation does turn into dmb ish with GCC 9. I'll look into it, but this will need some more testing. Thank you! -Bernhard From gnu.andrew at redhat.com Wed Aug 26 15:40:32 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 26 Aug 2020 15:40:32 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 4 new changesets Message-ID: <202008261540.07QFeWn8019998@aojmv0008.oracle.com> Changeset: 33e9ed39edb7 Author: ebaron Date: 2020-08-17 13:55 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/33e9ed39edb7 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 Reviewed-by: andrew ! THIRD_PARTY_README Changeset: dd27c46e8310 Author: andrew Date: 2020-08-18 03:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/dd27c46e8310 Added tag jdk8u272-b04 for changeset 33e9ed39edb7 ! .hgtags Changeset: 307f27ea5335 Author: andrew Date: 2020-08-18 07:01 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/307f27ea5335 Merge jdk8u272-b04 ! .hgtags ! THIRD_PARTY_README Changeset: 5adbdd81f58f Author: andrew Date: 2020-08-18 07:01 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/5adbdd81f58f Added tag aarch64-shenandoah-jdk8u272-b04 for changeset 307f27ea5335 ! .hgtags From gnu.andrew at redhat.com Wed Aug 26 15:41:06 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 26 Aug 2020 15:41:06 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 6 new changesets Message-ID: <202008261541.07QFf6Mv020485@aojmv0008.oracle.com> Changeset: 9f2b95a3c80b Author: phh Date: 2014-11-03 11:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9f2b95a3c80b 8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double Reviewed-by: simonis, andrew ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp ! test/testlibrary_tests/whitebox/vm_flags/DoubleTest.java Changeset: cbabffce5685 Author: ebaron Date: 2020-08-17 13:56 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cbabffce5685 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 Reviewed-by: andrew ! THIRD_PARTY_README Changeset: 636cc78f0f74 Author: andrew Date: 2020-08-18 03:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/636cc78f0f74 Added tag jdk8u272-b04 for changeset cbabffce5685 ! .hgtags Changeset: f9a4ff26a4bd Author: andrew Date: 2020-08-18 07:01 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f9a4ff26a4bd Merge jdk8u272-b04 ! .hgtags ! THIRD_PARTY_README ! src/share/vm/services/jmm.h ! src/share/vm/services/management.cpp Changeset: 0c4bb3e46471 Author: andrew Date: 2020-08-18 07:01 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0c4bb3e46471 Added tag aarch64-shenandoah-jdk8u272-b04 for changeset f9a4ff26a4bd ! .hgtags Changeset: bbb544bc4e85 Author: andrew Date: 2020-08-20 15:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bbb544bc4e85 Merge From gnu.andrew at redhat.com Wed Aug 26 15:41:16 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 26 Aug 2020 15:41:16 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 8 new changesets Message-ID: <202008261541.07QFfGZ5020712@aojmv0008.oracle.com> Changeset: c19e5d127e6c Author: xyin Date: 2020-04-23 16:36 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c19e5d127e6c 8243138: Enhance BaseLdapServer to support starttls extended request Reviewed-by: aefimov, dfuchs ! test/com/sun/jndi/ldap/lib/BaseLdapServer.java Changeset: 2bb5f6ae380f Author: andrew Date: 2020-08-17 15:09 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/2bb5f6ae380f Merge Changeset: ccb54d552a3b Author: phh Date: 2014-11-03 11:19 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ccb54d552a3b 8061616: HotspotDiagnosticMXBean.getVMOption() throws IllegalArgumentException for flags of type double Reviewed-by: simonis, andrew ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java ! src/share/classes/sun/management/Flag.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/javavm/export/jmm.h ! src/share/native/sun/management/Flag.c + test/com/sun/management/HotSpotDiagnosticMXBean/GetDoubleVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/GetVMOption.java ! test/com/sun/management/HotSpotDiagnosticMXBean/SetVMOption.java Changeset: 807a5fd65674 Author: ebaron Date: 2018-06-19 08:06 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/807a5fd65674 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 Summary: Includes DOMSignatureMethod.getSignature from JDK-8042967 Reviewed-by: andrew ! THIRD_PARTY_README ! src/share/classes/com/sun/org/apache/xml/internal/security/Init.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/Algorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/JCEMapper.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/MessageDigestAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithm.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/SignatureAlgorithmSpi.java + src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/ECDSAUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/IntegrityHmac.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureBaseRSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureDSA.java ! src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/SignatureECDSA.java - src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/Canonicalizer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/CanonicalizerSpi.java + src/share/classes/com/sun/org/apache/xml/internal/security/c14n/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/InvalidCanonicalizerException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/AttrCompare.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/C14nHelper.java - src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_OmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315Excl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclOmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315ExclWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315OmitComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer20010315WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerBase.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/CanonicalizerPhysical.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/NameSpaceSymbTable.java ! src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/UtfHelpper.java + src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/XmlAttrStack.java - src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/c14n/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AbstractSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherData.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherReference.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherValue.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/DocumentSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedData.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedKey.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedType.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Serializer.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Transforms.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherInput.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherParameters.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLEncryptionException.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/AlgorithmAlreadyRegisteredException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/Base64DecodingException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/XMLSecurityRuntimeException.java - src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/ContentHandlerAlreadyRegisteredException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/KeyUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/DEREncodedKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoContent.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyInfoReference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyName.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/KeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/MgmtData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/PGPData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/RetrievalMethod.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/SPKIData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/X509Data.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/DSAKeyValue.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/RSAKeyValue.java - src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509CRL.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Certificate.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509DataContent.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509Digest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509IssuerSerial.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SubjectName.java - src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/package.html + src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/InvalidKeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/KeyResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DEREncodedKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/DSAKeyValueResolver.java - src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/EncryptedKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/KeyInfoReferenceResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/PrivateKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RSAKeyValueResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/RetrievalMethodResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SecretKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/SingleKeyResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509CertificateResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509DigestResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509IssuerSerialResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SKIResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/X509SubjectNameResolver.java - src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/StorageResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/CertsInFilesystemDirectoryResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/KeyStoreResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/SingleCertificateResolver.java - src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/config.xml - src/share/classes/com/sun/org/apache/xml/internal/security/resource/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_de.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/resource/xmlsecurity_en.properties ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidDigestValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/InvalidSignatureValueException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Manifest.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/MissingResourceFailureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/NodeFilter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ObjectContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/ReferenceNotInitializedException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperties.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignatureProperty.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/SignedInfo.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInput.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignatureInputDebugger.java - src/share/classes/com/sun/org/apache/xml/internal/security/signature/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceNodeSetData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceOctetStreamData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/reference/ReferenceSubTreeData.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/InvalidTransformException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transform.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/TransformationException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/Transforms.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/FuncHere.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformBase64Decode.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14N11_WithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusive.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NExclusiveWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformC14NWithComments.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformEnvelopedSignature.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPath2Filter.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXPointer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/TransformXSLT.java - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/InclusiveNamespaces.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPath2FilterContainer04.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/transforms/params/XPathFilterCHGPContainer.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Constants.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/DOMNamespaceContext.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/DigesterOutputStream.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementChecker.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionConstants.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/HelperNodeList.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/I18n.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/IgnoreAllErrorHandler.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/JDKXPathAPI.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/JavaUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Signature11ElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignatureElementProxy.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/SignerOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncBufferedOutputStream.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/UnsyncByteArrayOutputStream.java + src/share/classes/com/sun/org/apache/xml/internal/security/utils/WeakObjectPool.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XPathFactory.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XalanXPathAPI.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/package.html + src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ClassLoaderUtils.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolver.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverException.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/ResourceResolverSpi.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverAnonymous.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverFragment.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverLocalFilesystem.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverXPointer.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/package.html + src/share/classes/com/sun/org/slf4j/internal/Logger.java + src/share/classes/com/sun/org/slf4j/internal/LoggerFactory.java ! src/share/classes/javax/xml/crypto/dsig/DigestMethod.java ! src/share/classes/javax/xml/crypto/dsig/SignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/DigesterOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/MacOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/SignerOutputStream.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/AbstractDOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheNodeSetData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java + src/share/classes/org/jcp/xml/dsig/internal/dom/BaseStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMBase64Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalizationMethod.java - src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java + src/share/classes/org/jcp/xml/dsig/internal/dom/Marshaller.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java + src/share/classes/org/jcp/xml/dsig/internal/dom/XmlWriter.java + src/share/classes/org/jcp/xml/dsig/internal/dom/XmlWriterToTree.java ! test/javax/xml/crypto/dsig/GenerationTests.java ! test/javax/xml/crypto/dsig/KeySelectors.java Changeset: 4d586f39fed3 Author: mullan Date: 2019-03-05 08:24 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/4d586f39fed3 8217878: ENVELOPING XML signature no longer works in JDK 11 8218629: XML Digital Signature throws NAMESPACE_ERR exception on OpenJDK 11, works 8/9/10 Summary: Backout and restore previous XML signature marshalling implementation Reviewed-by: weijun ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/Base64.java ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/AbstractDOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheCanonicalizer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheOctetStreamData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/ApacheTransform.java - src/share/classes/org/jcp/xml/dsig/internal/dom/BaseStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14N11Method.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCanonicalXMLC14NMethod.java + src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMDigestMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMEnvelopedTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMExcC14NMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyInfoFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyName.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMKeyValue.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMManifest.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMPGPData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMReference.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMRetrievalMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureMethod.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperties.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignatureProperty.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSignedInfo.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMStructure.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMSubTreeData.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMURIDereferencer.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMUtils.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509Data.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMX509IssuerSerial.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLObject.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignature.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXMLSignatureFactory.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathFilter2Transform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXPathTransform.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMXSLTTransform.java - src/share/classes/org/jcp/xml/dsig/internal/dom/Marshaller.java - src/share/classes/org/jcp/xml/dsig/internal/dom/XmlWriter.java - src/share/classes/org/jcp/xml/dsig/internal/dom/XmlWriterToTree.java ! test/javax/xml/crypto/dsig/GenerationTests.java + test/javax/xml/crypto/dsig/data/envelope2.xml Changeset: ce1f37506608 Author: andrew Date: 2020-08-18 03:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/ce1f37506608 Added tag jdk8u272-b04 for changeset 4d586f39fed3 ! .hgtags Changeset: 3463f5a842d5 Author: andrew Date: 2020-08-18 07:01 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3463f5a842d5 Merge jdk8u272-b04 ! .hgtags ! THIRD_PARTY_README ! src/share/classes/com/sun/management/HotSpotDiagnosticMXBean.java - src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/algorithms/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/c14n/helper/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/Canonicalizer11.java - src/share/classes/com/sun/org/apache/xml/internal/security/c14n/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/c14n/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AbstractSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/AgreementMethod.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherData.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherReference.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/CipherValue.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/DocumentSerializer.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedData.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedKey.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptedType.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionMethod.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperties.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/EncryptionProperty.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Reference.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/ReferenceList.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Serializer.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/Transforms.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipher.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherInput.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLCipherParameters.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/XMLEncryptionException.java - src/share/classes/com/sun/org/apache/xml/internal/security/encryption/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/exceptions/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/keyvalues/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/XMLX509SKI.java - src/share/classes/com/sun/org/apache/xml/internal/security/keys/content/x509/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/EncryptedKeyResolver.java - src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/keyresolver/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/keys/storage/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/resource/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/Reference.java ! src/share/classes/com/sun/org/apache/xml/internal/security/signature/XMLSignature.java - src/share/classes/com/sun/org/apache/xml/internal/security/signature/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/transforms/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementChecker.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/ElementCheckerImpl.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/EncryptionElementProxy.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/package.html ! src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/ResolverDirectHTTP.java - src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/implementations/package.html - src/share/classes/com/sun/org/apache/xml/internal/security/utils/resolver/package.html ! src/share/classes/org/jcp/xml/dsig/internal/dom/DOMCryptoBinary.java ! src/share/classes/org/jcp/xml/dsig/internal/dom/XMLDSigRI.java ! src/share/classes/sun/management/HotSpotDiagnostic.java ! src/share/javavm/export/jmm.h Changeset: 1974288e281a Author: andrew Date: 2020-08-18 07:01 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/1974288e281a Added tag aarch64-shenandoah-jdk8u272-b04 for changeset 3463f5a842d5 ! .hgtags From gnu.andrew at redhat.com Wed Aug 26 15:41:25 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Wed, 26 Aug 2020 15:41:25 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 4 new changesets Message-ID: <202008261541.07QFfPP7020826@aojmv0008.oracle.com> Changeset: d90c85ae0004 Author: ebaron Date: 2020-08-17 14:00 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/d90c85ae0004 8177334: Update xmldsig implementation to Apache Santuario 2.1.1 Reviewed-by: andrew ! THIRD_PARTY_README Changeset: 5e0be06a9cf2 Author: andrew Date: 2020-08-18 03:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/5e0be06a9cf2 Added tag jdk8u272-b04 for changeset d90c85ae0004 ! .hgtags Changeset: f305e6461406 Author: andrew Date: 2020-08-18 07:01 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/f305e6461406 Merge jdk8u272-b04 ! .hgtags ! THIRD_PARTY_README Changeset: 3e5b50ed717f Author: andrew Date: 2020-08-18 07:01 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/3e5b50ed717f Added tag aarch64-shenandoah-jdk8u272-b04 for changeset f305e6461406 ! .hgtags From aph at redhat.com Wed Aug 26 15:58:35 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 26 Aug 2020 16:58:35 +0100 Subject: [aarch64-port-dev ] 8248238: Implementation of JEP: Windows AArch64 Support In-Reply-To: References: <3834f328-d31f-0111-6ed3-afbe3fe3d9f7@redhat.com> Message-ID: <53ad7730-dbc7-583a-5db6-28f8f040ee51@redhat.com> On 26/08/2020 16:04, Bernhard Urban-Forster wrote: > Apparently it doesn't know :-( _WriteBarrier is a nop what code > generation is concerned, so it will emit a dmb ishst. How this > doesn't cause any major issues is beyond my understanding. The answer to that is probably that the actual physical implementations of AArch64 are more conservative about their memory ordering than they need to be. However, someone comes along with a new implementation, and bang. This has been seen a few times, such as recently when Felix Yang fixed 8248219: aarch64: missing memory barrier in fast_storefield and fast_accessfield. > FWIW the Linux implementation does turn into dmb ish with GCC 9. Yep, that's what we need. > I'll look into it, but this will need some more testing. Right. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From rkennke at redhat.com Wed Aug 26 17:05:40 2020 From: rkennke at redhat.com (Roman Kennke) Date: Wed, 26 Aug 2020 19:05:40 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252096: Shenandoah: adjust SerialPageShiftCount for x86_32 and JFR In-Reply-To: <1a01be59-1aa1-0631-ea54-87d7fd09c98f@redhat.com> References: <1a01be59-1aa1-0631-ea54-87d7fd09c98f@redhat.com> Message-ID: <99d4d40be2c86d12485d98e30b83829ab601e720.camel@redhat.com> Looks ok to me. Thanks, Roman Am Donnerstag, den 20.08.2020, 15:03 +0200 schrieb Aleksey Shipilev: > Hi, > > Once I added bootcycle-images to x86_32 test configurations, this > failure was discovered: > > # Internal Error (/home/shade/trunks/shenandoah- > jdk8/hotspot/src/share/vm/runtime/os.cpp:1280), > pid=490815, tid=0xf5fefb40 > # assert(SerializePageShiftCount == count) failed: thread size > changed, fix SerializePageShiftCount > constant > > It happens when all three things hold true: > - JFR is enabled at build time > - Shenandoah is enabled at build time (i.e. the build config is > not "minimal1") > - 32-bit VM is being built > > Therefore, it only affects aarch64-port/jdk8u-shenandoah, and here is > the minimal fix that adjusts > the constant when all three things are in effect at the same time: > > diff -r ed70d5208f5f src/share/vm/utilities/globalDefinitions.hpp > --- a/src/share/vm/utilities/globalDefinitions.hpp Mon Jun 22 > 20:26:02 2020 +0800 > +++ b/src/share/vm/utilities/globalDefinitions.hpp Thu Aug 20 > 13:03:44 2020 +0200 > @@ -143,12 +143,18 @@ > // log2_intptr(sizeof(class JavaThread)) - log2_intptr(64); > // see os::set_memory_serialize_page() > #ifdef _LP64 > const int SerializePageShiftCount = 4; > #else > +#if INCLUDE_JFR && INCLUDE_ALL_GCS > +// JavaThread already has quite a few Shenandoah fields. Adding many > JFR fields > +// trips sizeof(JavaThread) > 1024. Need to adjust it here. > +const int SerializePageShiftCount = 4; > +#else > const int SerializePageShiftCount = 3; > #endif > +#endif > > // An opaque struct of heap-word width, so that HeapWord* can be a > generic > // pointer into the heap. We require that object sizes be measured > in > // units of heap words, so that that > // HeapWord* hw; > > > Testing: Linux {x86_64, x86_32} x {zero, minimal1, server} x > {default, jfr} bootcycle-images build > From luhenry at microsoft.com Wed Aug 26 20:39:59 2020 From: luhenry at microsoft.com (Ludovic Henry) Date: Wed, 26 Aug 2020 20:39:59 +0000 Subject: [aarch64-port-dev ] Collaboration proposal: Draft JEP MacOS/AArch64 Port In-Reply-To: <8c9621f4-54cc-17a7-f84b-fc47387a15e0@azul.com> References: <8c9621f4-54cc-17a7-f84b-fc47387a15e0@azul.com> Message-ID: Hi Anton, As Monica is on vacation, I just wanted to give a quick update on where we are standing. As of today, we have most of hotspot:tier1 and jdk:tier1 passing. The main remaining issues are around calling convention from the compiler into native (we already fixed it from the interpreter) and deprecated APIs in 11.0.0 (used in AWT, for example). We are not running into any major issue with W^X, and we have come up with a systematic approach that requires few modifications. On the deprecated APIs, we can easily dismiss the warnings with -Wno-deprecated-declarations, but that is not a long term fix. We'd love to have a chat with you to figure out how you would like to share learnings and join efforts. I'll contact you offline with some time proposals. Thank you, Ludovic -----Original Message----- From: hotspot-dev On Behalf Of Anton Kozlov Sent: Thursday, August 13, 2020 6:04 AM To: Monica Beckwith Cc: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers Subject: Re: Collaboration proposal: Draft JEP MacOS/AArch64 Port Hello Monica, Thank you for your proposal. It was a bit unexpected :) We would be happy to collaborate! Our mac/aarch64 port is in the R&D phase. At some point, maybe we (OpenJDK community) will need a project or repo for integration. But having win/aarch64 integrated, it may happen that mac/aarch64 support will be just a series of considerably isolated changes. An example is "JDK-8250876: Fix issues with cross-compile on macos" [1]. If all changes will be such self-containing, they may be reviewed and integrated one-by-one. Probably we won't need a project. I think this work is blocked by the JEP for the new platform support. I'll start a discussion email thread for that really soon. I hope we would be able to collaborate in all of the areas. I expect us to get soon to the point when we can start reviewing changes made for win/aarch64 and evaluate how do they fit mac/aarch64. Thanks, Anton [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=etFFyw9zye9g5gGgRY%2BB%2FCsspLo0TZ8Ct0dTvB0aa98%3D&reserved=0 On 11.08.2020 21:15, Monica Beckwith wrote: > Hello everyone,? > > It gives me immense pleasure to see the draft JEP?for?'MacOS/AArch64 Port'?[1].?At Microsoft, we are in the?process of expanding our CI infrastructure by adding Apple?DevKits?[2]. We are?entirely?in support?of you and your?team, @Anton Kozlov.?You all bring your immense?knowledge from?the?AArch32 port,?and we welcome?you?and would like to extend our?collaboration?on?the MacOS?port.?More specifically,?we would like to work with you?on?the?-?? > > . Implementation (low-level code additions, shared code modifications and?maintenance, adhering to?HotSpot?coding style/conventions [3], etc.)?? > . Testing (all?regression,?functional, integration?and performance?tests)? > . Integration to?jdk/jdk?(tip)? > > Since the?MacOS?port?work depends on the?Windows port modifications, I?propose a?collaboration (sub-)Project [4]?repo where we?can?jointly?work in the open.? > > If it is OK with you and your team, next week,?I can propose the creation of?a new (sub-)Project?for?'jdk-mac'?and send it out to?mailto:discuss at openjdk.java.net and mailto:aarch64-port-dev at openjdk.java.net. Once we have a sponsor,?we can?send the?info out on?mailto:announce at openjdk.java.net. > > We can work?on?the details of these offline.?Please let me know if you have already?made traction on the (sub-)Project front,?and we can jump?in and help?wherever?you are.? > > This?is?a?wonderful?opportunity?for?OpenJDK,?and?the?team?here?at?Microsoft?is excited about?the?prospects, and we are?looking?forward?to?working?with?your?team.? > > Thanks,? > Monica > > [1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fjeps%2F8251280&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=oCZSZXoU9sDUpfyr4GXzxhrU0YrMFjAzTLgbcD1BNtc%3D&reserved=0 > [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fprograms%2Funiversal%2F&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=Taczc6541YW4mVDkkCzg4XLprCJMOgSi6I4oxtWhJW4%3D&reserved=0 > [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FHotSpot%2FStyleGuide&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=WLKmlWbb4oPkA7hN4Vz%2FE%2Ba6u52l7enipOvU0Gb3IgA%3D&reserved=0 > [4] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fprojects%2F%23new-project&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=aW1A%2BifN9I0fIcyHj7vGZFgvOI83h5t2ErlAu3u4z6M%3D&reserved=0 > From gnu.andrew at redhat.com Thu Aug 27 05:27:03 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Aug 2020 06:27:03 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b04 Upstream Sync In-Reply-To: <50d99e3b-9082-0a05-d4f3-c12be10ee645@redhat.com> References: <20200820152047.GB3112706@stopbrexit> <50d99e3b-9082-0a05-d4f3-c12be10ee645@redhat.com> Message-ID: <20200827052703.GA1050557@stopbrexit> On 19:15 Thu 20 Aug , Aleksey Shipilev wrote: > On 8/20/20 5:20 PM, Andrew Hughes wrote: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/corba/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/jaxp/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/jaxws/merge.changeset > > Look trivially good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/jdk/merge.changeset > > Whoa. Looks okay as far as I can see. > Yeah, that's pretty much one change (JDK-8177334: Update xmldsig implementation to Apache Santuario 2.1.1) which is why I was keen to get it in this otherwise low traffic promotion. > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/hotspot/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/langtools/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/nashorn/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b04/root/merge.changeset > > Look trivially good. > > Ok to push. > > -Aleksey > Thanks. Pushed. -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Aug 27 05:38:48 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Aug 2020 06:38:48 +0100 Subject: [aarch64-port-dev ] RFR (XS) 8252096: Shenandoah: adjust SerialPageShiftCount for x86_32 and JFR In-Reply-To: <1a01be59-1aa1-0631-ea54-87d7fd09c98f@redhat.com> References: <1a01be59-1aa1-0631-ea54-87d7fd09c98f@redhat.com> Message-ID: <20200827053848.GB1050557@stopbrexit> On 15:03 Thu 20 Aug , Aleksey Shipilev wrote: > Hi, > > Once I added bootcycle-images to x86_32 test configurations, this failure was discovered: > > # Internal Error (/home/shade/trunks/shenandoah-jdk8/hotspot/src/share/vm/runtime/os.cpp:1280), > pid=490815, tid=0xf5fefb40 > # assert(SerializePageShiftCount == count) failed: thread size changed, fix > SerializePageShiftCount constant > > It happens when all three things hold true: > - JFR is enabled at build time > - Shenandoah is enabled at build time (i.e. the build config is not "minimal1") > - 32-bit VM is being built > > Therefore, it only affects aarch64-port/jdk8u-shenandoah, and here is the > minimal fix that adjusts the constant when all three things are in effect at > the same time: > > diff -r ed70d5208f5f src/share/vm/utilities/globalDefinitions.hpp > --- a/src/share/vm/utilities/globalDefinitions.hpp Mon Jun 22 20:26:02 2020 +0800 > +++ b/src/share/vm/utilities/globalDefinitions.hpp Thu Aug 20 13:03:44 2020 +0200 > @@ -143,12 +143,18 @@ > // log2_intptr(sizeof(class JavaThread)) - log2_intptr(64); > // see os::set_memory_serialize_page() > #ifdef _LP64 > const int SerializePageShiftCount = 4; > #else > +#if INCLUDE_JFR && INCLUDE_ALL_GCS > +// JavaThread already has quite a few Shenandoah fields. Adding many JFR fields > +// trips sizeof(JavaThread) > 1024. Need to adjust it here. > +const int SerializePageShiftCount = 4; > +#else > const int SerializePageShiftCount = 3; > #endif > +#endif > > // An opaque struct of heap-word width, so that HeapWord* can be a generic > // pointer into the heap. We require that object sizes be measured in > // units of heap words, so that that > // HeapWord* hw; > > > Testing: Linux {x86_64, x86_32} x {zero, minimal1, server} x {default, jfr} bootcycle-images build > > -- > Thanks, > -Aleksey > This is the same issue I found when building x86 RPMs, as mentioned here: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-June/012016.html How did you find the correct value? I've been considering backporting https://bugs.openjdk.java.net/browse/JDK-8152358 as it makes the assert print the expected value. Anyway, if it only applies when Shenandoah + JFR are in operation, it explains why Azul have not seen it on upstream 8u. Change looks good to me and it will be good to get this fixed and JFR enabled on our x86 builds. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Thu Aug 27 05:47:50 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Aug 2020 07:47:50 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252096: Shenandoah: adjust SerialPageShiftCount for x86_32 and JFR In-Reply-To: <20200827053848.GB1050557@stopbrexit> References: <1a01be59-1aa1-0631-ea54-87d7fd09c98f@redhat.com> <20200827053848.GB1050557@stopbrexit> Message-ID: <3e6f9b6a-998d-6e2c-25cc-c09f400f3168@redhat.com> On 8/27/20 7:38 AM, Andrew Hughes wrote: > How did you find the correct value? I've been considering backporting > https://bugs.openjdk.java.net/browse/JDK-8152358 as it makes the assert > print the expected value. I printed out sizeof(JavaThread) in multiple build configurations, and discovered that with both JFR and Shenandoah it trips over 1024. Which means the expected count is log2_intptr(sizeof(class JavaThread)) - log2_intptr(64) = log2(2^10) - log2(2^6) = 4. That is basically +1 to current value. > Anyway, if it only applies when Shenandoah + JFR are in operation, it explains > why Azul have not seen it on upstream 8u. Change looks good to me and it will > be good to get this fixed and JFR enabled on our x86 builds. Yes. -- Thanks, -Aleksey From gnu.andrew at redhat.com Thu Aug 27 05:51:35 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Aug 2020 06:51:35 +0100 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp In-Reply-To: References: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> <875z957oy0.fsf@redhat.com> <4c29fbb37608c2843c54a2f6430ebfa9a3293893.camel@redhat.com> <8736497jrx.fsf@redhat.com> Message-ID: <20200827055135.GC1050557@stopbrexit> On 13:08 Wed 26 Aug , Aleksey Shipilev wrote: > On 8/26/20 1:01 PM, Roland Westrelin wrote: > > > It looks like this is not actually used for reference types. The only > > > uses are in library_call.cpp and they don't look like they ever load a > > > reference. Please check and confirm to be sure. > > > > It does on PPC. In LibraryCallKit::get_key_start_from_aescrypt_object(). > > Yes. I misjudged the assert: it actually verifies the current Shenandoah > uses do not need the LRB there. Shenandoah is not supported (yet) on PPC, so > there is no bug yet, and assert is just too strong for PPC code. But it > feels more future proof just to insert the Shenandoah barrier there. > > 8u webrev: > https://cr.openjdk.java.net/~shade/8252366/webrev.02/ > > Testing: hotspot_gc_shenandoah {fastdebug,release} > > -- > Thanks, > -Aleksey > Looks ok to me. Not having a g1_write_barrier_pre_helper function which is actually Shenandoah-only should add a little clarity :-) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Aug 27 06:01:07 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Aug 2020 07:01:07 +0100 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8 -> aarch64-port/jdk8u-shenandoah, 2020-08-26 In-Reply-To: References: Message-ID: <20200827060107.GD1050557@stopbrexit> On 11:20 Wed 26 Aug , Aleksey Shipilev wrote: > Hi, > > I would like to integrate the usual round of sh/jdk8 backports to aarch64-port/jdk8u-shenandoah. > > Only hotspot repository is affected, and the merge is clean there. Since we > need to coordinate the push with Andrew Hughes, I did not tag it yet. It > would be something like > "aarch64-shenandoah-jdk8u272-b03-shenandoah-merge-2020-08-26". > > 8u webrev: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200826/webrev.01/ > > Testing: hotspot_gc_shenandoah; plus, this was tested with sh/jdk8 CIs > > -- > Thanks, > -Aleksey > I've concentrated on the shared code, trusting you guys on the Shenandoah changes. The only one I'm curious about is the change to src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp. There's no associated bug ID so where does that change come from and is it specified to the 8u Shenandoah port? The other shared changes as part of the pacing stats and the cleanup of what is already a Shenandoah-only class loading change look ok. I'll post b05 shortly, and presume you will rebase on top of that as discussed. Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Thu Aug 27 06:14:11 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 27 Aug 2020 07:14:11 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b05 Upstream Sync Message-ID: <20200827061411.GE1050557@stopbrexit> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/root/merge.changeset Changes in aarch64-shenandoah-jdk8u272-b05: - JDK-8026236: Add PrimeTest for BigInteger - JDK-8057003: Large reference arrays cause extremely long synchronization times - JDK-8060721: Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler - JDK-8078334: Mark regression tests using randomness - JDK-8078880: Mark a few more intermittently failuring security-libs - JDK-8152077: (cal) Calendar.roll does not always roll the hours during daylight savings - JDK-8168517: java/lang/ProcessBuilder/Basic.java failed - JDK-8211163: UNIX version of Java_java_io_Console_echo does not return a clean boolean - JDK-8220674: [TESTBUG] MetricsMemoryTester failcount test in docker container only works with debug JVMs - JDK-8231213: Migrate SimpleDateFormatConstTest to JDK Repo - JDK-8236645: JDK 8u231 introduces a regression with incompatible handling of XML messages - JDK-8240676: Meet not symmetric failure when running lucene on jdk8 - JDK-8243321: Add Entrust root CA - G4 to Oracle Root CA program - JDK-8247979: aarch64: missing side effect of killing flags for clearArray_reg_reg - JDK-8249158: THREAD_START and THREAD_END event posted in primordial phase - JDK-8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics - JDK-8251546: 8u backport of JDK-8194298 breaks AIX and Solaris builds - JDK-8252084: Minimal VM fails to bootcycle: undefined symbol: AgeTableTracer::is_tenuring_distribution_event_enabled Main issues of note: Mostly clean. There was a minor conflict in src/share/vm/opto/compile.hpp, due to shenandoah_eliminate_g1_wb_pre being within the surrounding context of the _type_verify_symmetry addition. JDK-8247979 is already upstream, which is why the change to src/cpu/aarch64/vm/aarch64.ad appears uncredited. diffstat for root b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for corba b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxp b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jaxws b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for langtools b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for nashorn b/.hgtags | 1 + 1 file changed, 1 insertion(+) diffstat for jdk b/.hgtags | 1 b/make/data/cacerts/entrustrootcag4 | 43 + b/make/lib/CoreLibraries.gmk | 4 b/make/mapfiles/libjava/mapfile-vers | 1 b/src/linux/classes/jdk/internal/platform/cgroupv1/Metrics.java | 5 b/src/linux/native/jdk/internal/platform/cgroupv1/Metrics.c | 35 + b/src/share/classes/com/sun/org/apache/xml/internal/security/utils/XMLUtils.java | 7 b/src/share/classes/java/util/GregorianCalendar.java | 48 -- b/src/share/javavm/export/jvm.h | 3 b/src/solaris/native/java/io/Console_md.c | 2 b/src/solaris/native/java/net/ExtendedOptionsImpl.c | 16 b/test/com/sun/crypto/provider/Cipher/AES/CICO.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/CTR.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/Padding.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/Test4513830.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/Test4517355.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/TestAESCipher.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCM.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/TestCICOWithGCMAndAAD.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/TestISO10126Padding.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/TestNonexpanding.java | 1 b/test/com/sun/crypto/provider/Cipher/AES/TestSameBuffer.java | 1 b/test/com/sun/crypto/provider/Cipher/DES/FlushBug.java | 1 b/test/com/sun/crypto/provider/Cipher/PBE/PBESealedObject.java | 1 b/test/com/sun/crypto/provider/Cipher/PBE/PBKDF2Translate.java | 1 b/test/com/sun/crypto/provider/Cipher/PBE/PKCS12Cipher.java | 1 b/test/com/sun/crypto/provider/Cipher/PBE/TestCipherKeyWrapperPBEKey.java | 1 b/test/com/sun/crypto/provider/Cipher/RSA/TestOAEP.java | 1 b/test/com/sun/crypto/provider/Cipher/RSA/TestRSA.java | 1 b/test/com/sun/crypto/provider/Mac/HmacSaltLengths.java | 1 b/test/com/sun/crypto/provider/Mac/MacSameTest.java | 1 b/test/com/sun/management/ThreadMXBean/ThreadCpuTimeArray.java | 1 b/test/java/io/DataInputStream/ReadUTF.java | 1 b/test/java/io/File/GetXSpace.java | 1 b/test/java/io/PrintStream/OversynchronizedTest.java | 1 b/test/java/io/Serializable/corruptedUTFConsumption/CorruptedUTFConsumption.java | 1 b/test/java/io/Serializable/longString/LongString.java | 1 b/test/java/io/Serializable/proxy/Basic.java | 1 b/test/java/io/Serializable/sanityCheck/SanityCheck.java | 1 b/test/java/lang/Boolean/MakeBooleanComparable.java | 1 b/test/java/lang/ClassLoader/Assert.java | 1 b/test/java/lang/Compare.java | 1 b/test/java/lang/Double/ParseHexFloatingPoint.java | 1 b/test/java/lang/Enum/ValueOf.java | 1 b/test/java/lang/HashCode.java | 1 b/test/java/lang/Integer/BitTwiddle.java | 1 b/test/java/lang/Long/BitTwiddle.java | 1 b/test/java/lang/Math/CubeRootTests.java | 1 b/test/java/lang/Math/HypotTests.java | 1 b/test/java/lang/Math/IeeeRecommendedTests.java | 1 b/test/java/lang/Math/Log1pTests.java | 1 b/test/java/lang/ProcessBuilder/Basic.java | 10 b/test/java/lang/Runtime/exec/WinCommand.java | 1 b/test/java/lang/String/ContentEquals.java | 1 b/test/java/lang/String/ICCBasher.java | 1 b/test/java/lang/String/SBConstructor.java | 2 b/test/java/lang/String/Split.java | 1 b/test/java/lang/StringBuffer/AppendCharSequence.java | 1 b/test/java/lang/StringBuffer/AppendSB.java | 1 b/test/java/lang/StringBuffer/AppendStringBuilder.java | 1 b/test/java/lang/StringBuffer/Capacity.java | 1 b/test/java/lang/StringBuffer/IndexOf.java | 1 b/test/java/lang/StringBuffer/SBBasher.java | 2 b/test/java/lang/StringBuffer/Trim.java | 1 b/test/java/lang/StringBuilder/AppendStringBuffer.java | 1 b/test/java/lang/ToString.java | 1 b/test/java/lang/instrument/SingleTransformerTest.java | 1 b/test/java/lang/instrument/TransformMethodTest.java | 1 b/test/java/lang/invoke/MethodHandles/CatchExceptionTest.java | 1 b/test/java/lang/management/BufferPoolMXBean/Basic.java | 1 b/test/java/math/BigDecimal/StringConstructor.java | 1 b/test/java/math/BigInteger/BigIntegerTest.java | 1 b/test/java/math/BigInteger/ModPow65537.java | 1 b/test/java/math/BigInteger/PrimeTest.java | 197 ++++++++ b/test/java/math/BigInteger/SymmetricRangeTests.java | 1 b/test/java/net/InetAddress/HashSpread.java | 1 b/test/java/nio/Buffer/Chars.java | 1 b/test/java/nio/MappedByteBuffer/Force.java | 1 b/test/java/nio/MappedByteBuffer/ZeroMap.java | 1 b/test/java/nio/channels/AsynchronousChannelGroup/Basic.java | 1 b/test/java/nio/channels/AsynchronousChannelGroup/Identity.java | 1 b/test/java/nio/channels/AsynchronousChannelGroup/Restart.java | 1 b/test/java/nio/channels/AsynchronousFileChannel/Basic.java | 1 b/test/java/nio/channels/AsynchronousFileChannel/Lock.java | 1 b/test/java/nio/channels/AsynchronousFileChannel/LotsOfWrites.java | 1 b/test/java/nio/channels/AsynchronousSocketChannel/Basic.java | 1 b/test/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java | 1 b/test/java/nio/channels/Channels/Basic2.java | 1 b/test/java/nio/channels/Channels/ShortWrite.java | 1 b/test/java/nio/channels/DatagramChannel/AdaptDatagramSocket.java | 1 b/test/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java | 1 b/test/java/nio/channels/DatagramChannel/Promiscuous.java | 1 b/test/java/nio/channels/FileChannel/AtomicAppend.java | 1 b/test/java/nio/channels/FileChannel/ClosedByInterrupt.java | 1 b/test/java/nio/channels/FileChannel/MapTest.java | 1 b/test/java/nio/channels/FileChannel/Position.java | 1 b/test/java/nio/channels/FileChannel/Pread.java | 1 b/test/java/nio/channels/FileChannel/Pwrite.java | 1 b/test/java/nio/channels/FileChannel/Size.java | 1 b/test/java/nio/channels/FileChannel/Transfer.java | 1 b/test/java/nio/channels/FileChannel/Truncate.java | 1 b/test/java/nio/channels/Pipe/PipeChannel.java | 3 b/test/java/nio/channels/Pipe/ScatteringRead.java | 3 b/test/java/nio/channels/Pipe/SelectPipe.java | 1 b/test/java/nio/channels/Selector/SelectorTest.java | 1 b/test/java/nio/channels/ServerSocketChannel/NonBlockingAccept.java | 1 b/test/java/nio/channels/SocketChannel/CloseDuringWrite.java | 1 b/test/java/nio/channels/SocketChannel/OutOfBand.java | 1 b/test/java/nio/channels/SocketChannel/ShortWrite.java | 1 b/test/java/nio/channels/SocketChannel/VectorIO.java | 1 b/test/java/nio/channels/etc/AdaptorCloseAndInterrupt.java | 1 b/test/java/nio/charset/coders/BashCache.java | 1 b/test/java/nio/charset/coders/BashStreams.java | 1 b/test/java/nio/file/Files/BytesAndLines.java | 1 b/test/java/nio/file/Files/CopyAndMove.java | 1 b/test/java/nio/file/Files/walkFileTree/SkipSiblings.java | 1 b/test/java/nio/file/Files/walkFileTree/SkipSubtree.java | 1 b/test/java/nio/file/Files/walkFileTree/TerminateWalk.java | 1 b/test/java/nio/file/WatchService/LotsOfEvents.java | 1 b/test/java/nio/file/WatchService/MayFlies.java | 1 b/test/java/nio/file/WatchService/SensitivityModifier.java | 1 b/test/java/nio/file/attribute/AclFileAttributeView/Basic.java | 1 b/test/java/nio/file/attribute/FileTime/Basic.java | 1 b/test/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java | 1 b/test/java/security/MessageDigest/ByteBuffers.java | 1 b/test/java/security/MessageDigest/TestDigestIOStream.java | 1 b/test/java/security/MessageDigest/TestSameLength.java | 1 b/test/java/security/MessageDigest/TestSameValue.java | 1 b/test/java/security/Signature/ByteBuffers.java | 1 b/test/java/security/Signature/NONEwithRSA.java | 1 b/test/java/security/spec/EllipticCurveMatch.java | 1 b/test/java/sql/JavatimeTest.java | 1 b/test/java/text/Format/DateFormat/SimpleDateFormatPatternTest.java | 229 ++++++++++ b/test/java/text/Format/MessageFormat/Bug7003643.java | 1 b/test/java/util/Arrays/ArrayObjectMethods.java | 1 b/test/java/util/Arrays/CopyMethods.java | 1 b/test/java/util/Arrays/Correct.java | 1 b/test/java/util/Base64/TestBase64.java | 1 b/test/java/util/BitSet/BSMethods.java | 1 b/test/java/util/BitSet/ImportExport.java | 1 b/test/java/util/BitSet/PreviousBits.java | 1 b/test/java/util/Calendar/Bug8152077.java | 135 +++++ b/test/java/util/Calendar/JavatimeTest.java | 1 b/test/java/util/Collection/MOAT.java | 1 b/test/java/util/Collections/AddAll.java | 1 b/test/java/util/Collections/CheckedListBash.java | 1 b/test/java/util/Collections/CheckedMapBash.java | 1 b/test/java/util/Collections/CheckedSetBash.java | 1 b/test/java/util/Collections/Disjoint.java | 1 b/test/java/util/Collections/Rotate.java | 1 b/test/java/util/EnumSet/EnumSetBash.java | 1 b/test/java/util/HashSet/Serialization.java | 1 b/test/java/util/IdentityHashMap/Capacity.java | 1 b/test/java/util/List/LockStep.java | 1 b/test/java/util/Map/LockStep.java | 1 b/test/java/util/NavigableMap/LockStep.java | 1 b/test/java/util/Properties/ConcurrentLoadAndStoreXML.java | 1 b/test/java/util/Random/DistinctSeeds.java | 1 b/test/java/util/Random/RandomStreamTest.java | 1 b/test/java/util/Random/RandomTest.java | 1 b/test/java/util/ResourceBundle/Control/StressTest.java | 1 b/test/java/util/SplittableRandom/SplittableRandomTest.java | 1 b/test/java/util/Timer/DelayOverflow.java | 1 b/test/java/util/Timer/Purge.java | 1 b/test/java/util/UUID/Serial.java | 1 b/test/java/util/UUID/UUIDTest.java | 1 b/test/java/util/WeakHashMap/GCDuringIteration.java | 1 b/test/java/util/logging/CheckZombieLockTest.java | 1 b/test/java/util/logging/DrainFindDeadlockTest.java | 1 b/test/java/util/logging/FileHandlerPath.java | 1 b/test/java/util/logging/LoggingDeadlock.java | 4 b/test/java/util/logging/LoggingDeadlock2.java | 4 b/test/java/util/logging/TestLogConfigurationDeadLockWithConf.java | 1 b/test/java/util/regex/RegExTest.java | 1 b/test/java/util/zip/3GBZipFiles.sh | 1 b/test/java/util/zip/DeflateIn_InflateOut.java | 1 b/test/java/util/zip/FlaterTest.java | 1 b/test/java/util/zip/GZIP/Accordion.java | 1 b/test/java/util/zip/GZIP/GZIPInputStreamRead.java | 1 b/test/java/util/zip/InflateIn_DeflateOut.java | 1 b/test/java/util/zip/InflaterBufferSize.java | 1 b/test/java/util/zip/TimeChecksum.java | 1 b/test/java/util/zip/TotalInOut.java | 1 b/test/java/util/zip/ZipFile/Assortment.java | 1 b/test/java/util/zip/ZipFile/ClearStaleZipFileInputStreams.java | 1 b/test/java/util/zip/ZipFile/FinalizeZipFile.java | 1 b/test/java/util/zip/ZipFile/MultiThreadedReadTest.java | 1 b/test/java/util/zip/ZipFile/ReadZip.java | 1 b/test/javax/crypto/Cipher/ByteBuffers.java | 1 b/test/javax/crypto/CipherSpi/DirectBBRemaining.java | 1 b/test/javax/crypto/CryptoPermission/AllPermCheck.java | 1 b/test/javax/crypto/CryptoPermission/RC2PermCheck.java | 1 b/test/javax/crypto/JceSecurity/SunJCE_BC_LoadOrdering.java | 1 b/test/javax/crypto/KeyGenerator/TestKGParity.java | 1 b/test/javax/crypto/Mac/ByteBuffers.java | 1 b/test/javax/crypto/NullCipher/TestNPE.java | 1 b/test/javax/management/monitor/MultiMonitorTest.java | 1 b/test/javax/management/mxbean/ThreadMXBeanTest.java | 1 b/test/javax/management/remote/mandatory/loading/MissingClassTest.java | 1 b/test/javax/management/timer/MissingNotificationTest.java | 1 b/test/javax/smartcardio/TestCommandAPDU.java | 1 b/test/javax/xml/crypto/dsig/LineFeedOnlyTest.java | 214 +++++++++ b/test/jdk/internal/platform/docker/CheckUseContainerSupport.java | 46 ++ b/test/jdk/internal/platform/docker/MetricsMemoryTester.java | 11 b/test/jdk/internal/platform/docker/TestDockerMemoryMetrics.java | 1 b/test/jdk/internal/platform/docker/TestUseContainerSupport.java | 71 +++ b/test/security/infra/java/security/cert/CertPathValidator/certification/EntrustCA.java | 184 +++++++- b/test/sun/management/jmxremote/startstop/JMXStartStopTest.java | 1 b/test/sun/misc/CopyMemory.java | 1 b/test/sun/misc/FloatingDecimal/TestFloatingDecimal.java | 1 b/test/sun/net/www/ParseUtil_4922813.java | 1 b/test/sun/nio/cs/FindDecoderBugs.java | 1 b/test/sun/nio/cs/FindEncoderBugs.java | 1 b/test/sun/nio/cs/TestStringCoding.java | 1 b/test/sun/nio/cs/TestStringCodingUTF8.java | 1 b/test/sun/security/lib/cacerts/VerifyCACerts.java | 8 b/test/sun/security/mscapi/PrngSlow.java | 1 b/test/sun/security/mscapi/SignUsingSHA2withRSA.sh | 1 b/test/sun/security/pkcs11/Cipher/ReinitCipher.java | 1 b/test/sun/security/pkcs11/Cipher/TestRSACipher.java | 1 b/test/sun/security/pkcs11/Cipher/TestRawRSACipher.java | 1 b/test/sun/security/pkcs11/Cipher/TestSymmCiphers.java | 3 b/test/sun/security/pkcs11/Cipher/TestSymmCiphersNoPad.java | 1 b/test/sun/security/pkcs11/KeyGenerator/DESParity.java | 1 b/test/sun/security/pkcs11/Mac/MacSameTest.java | 1 b/test/sun/security/pkcs11/Mac/ReinitMac.java | 1 b/test/sun/security/pkcs11/MessageDigest/ByteBuffers.java | 1 b/test/sun/security/pkcs11/MessageDigest/ReinitDigest.java | 1 b/test/sun/security/pkcs11/MessageDigest/TestCloning.java | 1 b/test/sun/security/pkcs11/Secmod/AddPrivateKey.java | 1 b/test/sun/security/pkcs11/Secmod/Crypto.java | 1 b/test/sun/security/pkcs11/Secmod/GetPrivateKey.java | 1 b/test/sun/security/pkcs11/SecureRandom/Basic.java | 1 b/test/sun/security/pkcs11/Signature/ByteBuffers.java | 1 b/test/sun/security/pkcs11/Signature/ReinitSignature.java | 1 b/test/sun/security/pkcs11/Signature/TestDSA.java | 1 b/test/sun/security/pkcs11/Signature/TestDSAKeyLength.java | 1 b/test/sun/security/pkcs11/ec/ReadPKCS12.java | 1 b/test/sun/security/pkcs11/ec/TestCurves.java | 1 b/test/sun/security/pkcs11/ec/TestECDSA.java | 1 b/test/sun/security/pkcs11/rsa/KeyWrap.java | 1 b/test/sun/security/pkcs11/rsa/TestKeyPairGenerator.java | 1 b/test/sun/security/pkcs11/rsa/TestSignatures.java | 1 b/test/sun/security/provider/DSA/TestDSA.java | 1 b/test/sun/security/provider/DSA/TestDSA2.java | 1 b/test/sun/security/provider/SeedGenerator/Priority_Inversion.java | 1 b/test/sun/security/rsa/TestKeyPairGenerator.java | 1 b/test/sun/security/rsa/TestSignatures.java | 1 248 files changed, 1444 insertions(+), 67 deletions(-) diffstat for hotspot a/test/runtime/8233197/T.java | 11 a/test/runtime/8233197/Test8233197.sh | 153 ---------- a/test/runtime/8233197/libJvmtiAgent.c | 124 -------- b/.hgtags | 1 b/make/excludeSrc.make | 1 b/make/linux/makefiles/mapfile-vers-debug | 1 b/make/linux/makefiles/mapfile-vers-product | 1 b/src/share/vm/gc_implementation/g1/concurrentMark.cpp | 33 +- b/src/share/vm/gc_implementation/g1/concurrentMark.hpp | 8 b/src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp | 14 b/src/share/vm/gc_implementation/g1/g1ConcurrentMarkObjArrayProcessor.cpp | 87 +++++ b/src/share/vm/gc_implementation/g1/g1ConcurrentMarkObjArrayProcessor.hpp | 70 ++++ b/src/share/vm/gc_implementation/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp | 36 ++ b/src/share/vm/jfr/instrumentation/jfrJvmtiAgent.cpp | 127 +++----- b/src/share/vm/jfr/jfr.cpp | 19 - b/src/share/vm/jfr/jfr.hpp | 5 b/src/share/vm/jfr/jni/jfrJavaSupport.cpp | 4 b/src/share/vm/jfr/jni/jfrJavaSupport.hpp | 1 b/src/share/vm/jfr/jni/jfrJniMethod.cpp | 4 b/src/share/vm/jfr/recorder/jfrRecorder.cpp | 28 - b/src/share/vm/jfr/recorder/jfrRecorder.hpp | 5 b/src/share/vm/jfr/recorder/service/jfrOptionSet.cpp | 26 - b/src/share/vm/jfr/recorder/service/jfrOptionSet.hpp | 4 b/src/share/vm/memory/metaspaceShared.cpp | 11 b/src/share/vm/opto/compile.cpp | 3 b/src/share/vm/opto/compile.hpp | 3 b/src/share/vm/opto/type.cpp | 76 +++- b/src/share/vm/opto/type.hpp | 1 b/src/share/vm/prims/jvm.cpp | 11 b/src/share/vm/prims/jvm.h | 3 b/src/share/vm/runtime/globals.hpp | 2 b/src/share/vm/runtime/thread.cpp | 22 - b/src/share/vm/utilities/taskqueue.hpp | 3 b/test/compiler/types/TestArrayMeetNotSymmetrical.java | 70 ++++ 34 files changed, 477 insertions(+), 491 deletions(-) Built locally on x86_64 and is currently taking place on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero), ppc64, ppc64le, aarch32 (Zero) & aarch64 on our build infrastructure. I'm posting this now on the prediction that this will pass, allowing it to be reviewed in the meantime, but will obviously not push if this fails. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From shade at redhat.com Thu Aug 27 06:26:23 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Aug 2020 08:26:23 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8 -> aarch64-port/jdk8u-shenandoah, 2020-08-26 In-Reply-To: <20200827060107.GD1050557@stopbrexit> References: <20200827060107.GD1050557@stopbrexit> Message-ID: On 8/27/20 8:01 AM, Andrew Hughes wrote: > I've concentrated on the shared code, trusting you guys on the Shenandoah changes. > > The only one I'm curious about is the change to > src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp. There's no > associated bug ID so where does that change come from and is it > specified to the 8u Shenandoah port? It is specific to 8u Shenandoah port, comes from here: https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/049078100b90 Later refactorings eliminated the file, and the Shenandoah-specific issue (the absence of CV-qualified overload) with it. So, there is nothing to backport from. > I'll post b05 shortly, and presume you will rebase on top of that as > discussed. Yes, sure. -- Thanks, -Aleksey From shade at redhat.com Thu Aug 27 06:31:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 27 Aug 2020 08:31:39 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b05 Upstream Sync In-Reply-To: <20200827061411.GE1050557@stopbrexit> References: <20200827061411.GE1050557@stopbrexit> Message-ID: On 8/27/20 8:14 AM, Andrew Hughes wrote: > Merge changesets: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/root/merge.changeset Look trivially good. > Ok to push? Yes. Please push as soon as possible. -- Thanks, -Aleksey From akozlov at azul.com Thu Aug 27 08:17:10 2020 From: akozlov at azul.com (Anton Kozlov) Date: Thu, 27 Aug 2020 11:17:10 +0300 Subject: [aarch64-port-dev ] Collaboration proposal: Draft JEP MacOS/AArch64 Port In-Reply-To: References: <8c9621f4-54cc-17a7-f84b-fc47387a15e0@azul.com> Message-ID: <74fb31b5-22fe-41eb-d04e-50b288b23eb6@azul.com> Hi! It seems we are in a similar state. Same problem with native_wrapper, e.g subsequent byte arguments are adjacent on stack[1]. So far we bailout when a-smaller-than-word-argument is allocated on stack (and use interpreted version). The problem is VMReg for stack slots does not able to encode stack places with bytes granularity. I think it is fine to allocate same (or none) stack VMReg for small arguments, but we have not tried that yet. I think we've come up with the same or similar systematic approaches. I'm not ready to say I have something that is correct by construction for W^X, but I feel I'm close. A few latest iterations mostly works but a few edge cases makes me re-think about invariants. Thanks, Anton [1] https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html#//apple_ref/doc/uid/TP40013702-SW4 On 26.08.2020 23:39, Ludovic Henry wrote: > Hi Anton, > > As Monica is on vacation, I just wanted to give a quick update on where we are standing. > > As of today, we have most of hotspot:tier1 and jdk:tier1 passing. The main remaining issues are around calling convention from the compiler into native (we already fixed it from the interpreter) and deprecated APIs in 11.0.0 (used in AWT, for example). We are not running into any major issue with W^X, and we have come up with a systematic approach that requires few modifications. On the deprecated APIs, we can easily dismiss the warnings with -Wno-deprecated-declarations, but that is not a long term fix. > > We'd love to have a chat with you to figure out how you would like to share learnings and join efforts. I'll contact you offline with some time proposals. > > Thank you, > Ludovic > > -----Original Message----- > From: hotspot-dev On Behalf Of Anton Kozlov > Sent: Thursday, August 13, 2020 6:04 AM > To: Monica Beckwith > Cc: aarch64-port-dev at openjdk.java.net; hotspot-dev Source Developers > Subject: Re: Collaboration proposal: Draft JEP MacOS/AArch64 Port > > Hello Monica, > > Thank you for your proposal. It was a bit unexpected :) We would be happy to > collaborate! > > Our mac/aarch64 port is in the R&D phase. At some point, maybe we (OpenJDK > community) will need a project or repo for integration. But having win/aarch64 > integrated, it may happen that mac/aarch64 support will be just a series of > considerably isolated changes. An example is "JDK-8250876: Fix issues with > cross-compile on macos" [1]. If all changes will be such self-containing, they > may be reviewed and integrated one-by-one. Probably we won't need a project. > > I think this work is blocked by the JEP for the new platform support. I'll > start a discussion email thread for that really soon. > > I hope we would be able to collaborate in all of the areas. I expect us to get > soon to the point when we can start reviewing changes made for win/aarch64 and > evaluate how do they fit mac/aarch64. > > Thanks, > Anton > > [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8250876&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=etFFyw9zye9g5gGgRY%2BB%2FCsspLo0TZ8Ct0dTvB0aa98%3D&reserved=0 > > On 11.08.2020 21:15, Monica Beckwith wrote: >> Hello everyone,? >> >> It gives me immense pleasure to see the draft JEP?for?'MacOS/AArch64 Port'?[1].?At Microsoft, we are in the?process of expanding our CI infrastructure by adding Apple?DevKits?[2]. We are?entirely?in support?of you and your?team, @Anton Kozlov.?You all bring your immense?knowledge from?the?AArch32 port,?and we welcome?you?and would like to extend our?collaboration?on?the MacOS?port.?More specifically,?we would like to work with you?on?the?-?? >> >> . Implementation (low-level code additions, shared code modifications and?maintenance, adhering to?HotSpot?coding style/conventions [3], etc.)?? >> . Testing (all?regression,?functional, integration?and performance?tests)? >> . Integration to?jdk/jdk?(tip)? >> >> Since the?MacOS?port?work depends on the?Windows port modifications, I?propose a?collaboration (sub-)Project [4]?repo where we?can?jointly?work in the open.? >> >> If it is OK with you and your team, next week,?I can propose the creation of?a new (sub-)Project?for?'jdk-mac'?and send it out to?mailto:discuss at openjdk.java.net and mailto:aarch64-port-dev at openjdk.java.net. Once we have a sponsor,?we can?send the?info out on?mailto:announce at openjdk.java.net. >> >> We can work?on?the details of these offline.?Please let me know if you have already?made traction on the (sub-)Project front,?and we can jump?in and help?wherever?you are.? >> >> This?is?a?wonderful?opportunity?for?OpenJDK,?and?the?team?here?at?Microsoft?is excited about?the?prospects, and we are?looking?forward?to?working?with?your?team.? >> >> Thanks,? >> Monica >> >> [1] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fjeps%2F8251280&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=oCZSZXoU9sDUpfyr4GXzxhrU0YrMFjAzTLgbcD1BNtc%3D&reserved=0 >> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdeveloper.apple.com%2Fprograms%2Funiversal%2F&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=Taczc6541YW4mVDkkCzg4XLprCJMOgSi6I4oxtWhJW4%3D&reserved=0 >> [3] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.openjdk.java.net%2Fdisplay%2FHotSpot%2FStyleGuide&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=WLKmlWbb4oPkA7hN4Vz%2FE%2Ba6u52l7enipOvU0Gb3IgA%3D&reserved=0 >> [4] https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fopenjdk.java.net%2Fprojects%2F%23new-project&data=02%7C01%7Cluhenry%40microsoft.com%7C4623df4c26b74b3fc9fc08d83f8a4b37%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637329210503526908&sdata=aW1A%2BifN9I0fIcyHj7vGZFgvOI83h5t2ErlAu3u4z6M%3D&reserved=0 >> From vladimir.x.ivanov at oracle.com Thu Aug 27 12:54:23 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 27 Aug 2020 15:54:23 +0300 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <670fad6f-16ff-a7b3-8775-08dd79809ddf@redhat.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <35f8801f-4383-4804-2a9b-5818d1bda763@redhat.com> <524a4aaa-3cf7-7b5e-3e0e-0fd7f4f89fbf@oracle.com> <670fad6f-16ff-a7b3-8775-08dd79809ddf@redhat.com> Message-ID: Hi Andrew, > So, if I can summarize (please correct me if I misunderstand): > > You are as concerned about existing complexity in vector handling as > much as complexity added by this patch, whether the latter is to AArch64 > code or shared code. > > The goal you would like to achieve is a single set of rules for a > single kind of vector register whose size is parameterized, the > appropriate value being derived from each specific vector operation. > > Your main concern about this patch is that it adds yet another > additional vector kind to the current 'wrong' multi-kind vector model > and, what is worse, one with a different behaviour, taking us further > from your desired goal. Yes, correct. > Your other concern is that this design does not allow for the AArch64 > ISA predication or, indeed, for what you treat uniformly as the > 'implicit' predication imposed on a 'logical' max vector size (2048 > bits) by the specific AVX/SVE/NEON hardware vector size. No, I'm not concerned about that. I mentioned SVE implicit predication to illustrate that there's a higher-level abstraction in the JVM above ISA level which hides some of the functionality ISA exposes. And I'm perfectly fine with that. >> But you should definitely prefer 1-slot design for vector registers then >> ;-) > > Indeed I do :-] > > So, let me respond to the above summary points, assuming I have them > down right. > > I agree that your end goal is highly desirable. However, we are not > there yet and since your attempts to do so have not succeeded so far I > don't think that means we are compelled to drop the current patch. As > you say this could (and, if it is adopted, should) be regarded as a > useful stop-gap until we come up with a unified, parameterized vector > implementation that makes it redundant. Unfortunately, there was simply not enough motivation on x86 (and hence resources spent) to address it there. Vector API support for x86 stretched the implementation in a different direction: combinatorial explosion of AD instructions needed to cover all useful cases. It required switching to full-width vectors in x86.ad file which left RA concerns waiting next opportunity. > That said, I'm not pushing hard to keep the patch if the consequence is > generating significant work later to undo it. The number of users who > might benefit from using SVE vectors from Java now or in the near future > does not look like it is going to be very large (if you are not making a > lot of use of SVE registers then that is a lot of wasted silicon and I > suspect it's going to be the rare case that someone codes an app in Java > that needs to make continuous use of SVE -- mind you, by the same token > I guess that also applies for AVX on Intel). I don't consider RA part of the patch as the show-stopper issue for initial SVE support. As I said to Ningsheng, I'm fine with the patch as it is now if we agree it's a stop-the-gap solution and there's a commitment to invest into the proper support. I initially put options #1/#2 (which don't require any changes in RA shared code) as possible alternatives way to temporarily address the problem. Both require additional simplifying assumptions and hence I didn't insist they should be chosen. > I'm not sure pushing this now will add a lot more work later. It seems > to me that this code is actually moving in the right direction for the > sort of solution you want. The AArch64 VecA register /is/ > size-parameterized, albeit by a size fixed at startup rather than per > operation. So, that's one reason why I don't know if this implies a lot > more rework to move towards your desired goal. Surely, if we do arrive > at a unifying vector model that can replace the existing multi-kind > vectors then it ought to be able to subsume this code - unless of course > it replaces it wholesale. > > Are you concerned that adding this patch will result in more cases to > pick through and correct? > > Are you worried that we might have to withdraw some of the support this > patch enables to arrive at the final goal? > > Also, Ningsheng and his colleagues have laid some foundations for > implementing predicated operations with this patch and have that work in > the pipeline. Once again this is moving towards the desired goal even if > it might end up doign so in a slightly sideways fashion. Perhaps we > could continue this stop-gap experiment as an experimental option in > order to learn from the experience? I definitely don't want to hinder/block the impressive work Ningsheng and others at Arm are doing for SVE support. Frankly speaking, my main concern is that the implementation can stay that way forever ;-) That's why I'm trying to get enough ground covered in the discussion and some agreements/commitments to be made before it is integrated. I don't have any strong objections to the patch which could justify blocking its integration, but on a higher-level I do voice my concerns about where it pushes the implementation longer-term. Unfortunately, as it is shaped now, I don't see how x86 can benefit from it. So, I'm afraid this particular route with vecA and _is_scalable bit will stay purely AArch64-specific exercise. Leaving RA part aside, I have one suggestion which should help in the future: let's try to consistently follow full-width vector abstraction. In AD file, vecA operand is way too similar to vecX et al which makes a wrong impression it's yet another vector flavor. So, choosing a better name will help when representation changes. For example, x86 moved away from vecX/... operands to a single generic one (called "vec") and you can take a loot at x86.ad to see the result. Best regards, Vladimir Ivanov From gnu.andrew at redhat.com Fri Aug 28 03:36:04 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 28 Aug 2020 04:36:04 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b05 Upstream Sync In-Reply-To: References: <20200827061411.GE1050557@stopbrexit> Message-ID: <20200828033604.GA1136463@stopbrexit> On 08:31 Thu 27 Aug , Aleksey Shipilev wrote: > On 8/27/20 8:14 AM, Andrew Hughes wrote: > > Merge changesets: > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/corba/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/jaxp/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/jaxws/merge.changeset > > Look trivially good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/jdk/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/hotspot/merge.changeset > > Looks good. > > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/langtools/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/nashorn/merge.changeset > > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b05/root/merge.changeset > > Look trivially good. > > > Ok to push? > > Yes. Please push as soon as possible. > > -- > Thanks, > -Aleksey > I was hoping to push this morning, but woke up to an s390 size_t build failure instead, thanks to a MIN2 call introduced by JDK-8057003 :-( Fixed and built since, so I've now pushed. +- size_t words_to_scan = MIN2(remaining, ObjArrayMarkingStride); ++ size_t words_to_scan = MIN2(remaining, (size_t) ObjArrayMarkingStride); Reminds me we should get some variant of JDK-8203030 backported to 8u (the whole size_t fix to make s390 work is local to the RPM build at the moment) Thanks, -- Andrew :) Senior Free Java Software Engineer OpenJDK Package Owner Red Hat, Inc. (http://www.redhat.com) PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net) Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222 From gnu.andrew at redhat.com Fri Aug 28 03:33:19 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 28 Aug 2020 03:33:19 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets Message-ID: <202008280333.07S3XJKF001241@aojmv0008.oracle.com> Changeset: 213fddbce4f4 Author: andrew Date: 2020-08-26 03:59 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/213fddbce4f4 Added tag jdk8u272-b05 for changeset dd27c46e8310 ! .hgtags Changeset: 85f1e62ca611 Author: andrew Date: 2020-08-27 06:45 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/85f1e62ca611 Merge jdk8u272-b05 ! .hgtags Changeset: 5915068874b5 Author: andrew Date: 2020-08-27 06:45 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/5915068874b5 Added tag aarch64-shenandoah-jdk8u272-b05 for changeset 85f1e62ca611 ! .hgtags From gnu.andrew at redhat.com Fri Aug 28 03:33:26 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 28 Aug 2020 03:33:26 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 3 new changesets Message-ID: <202008280333.07S3XQdd001372@aojmv0008.oracle.com> Changeset: cd45db6086c0 Author: andrew Date: 2020-08-26 03:59 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/cd45db6086c0 Added tag jdk8u272-b05 for changeset 36d18f0fd6ee ! .hgtags Changeset: 90d7ccdbb614 Author: andrew Date: 2020-08-27 06:45 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/90d7ccdbb614 Merge jdk8u272-b05 ! .hgtags Changeset: 1cd3f49cc65d Author: andrew Date: 2020-08-27 06:45 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/1cd3f49cc65d Added tag aarch64-shenandoah-jdk8u272-b05 for changeset 90d7ccdbb614 ! .hgtags From gnu.andrew at redhat.com Fri Aug 28 03:33:46 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 28 Aug 2020 03:33:46 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 10 new changesets Message-ID: <202008280333.07S3XkqQ001673@aojmv0008.oracle.com> Changeset: 72053ed6f8d4 Author: tschatzl Date: 2016-11-24 11:27 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/72053ed6f8d4 8057003: Large reference arrays cause extremely long synchronization times Summary: Slice large object arrays into parts so that the synchronization of marking threads with an STW pause request does not take long. Reviewed-by: ehelin, pliden Contributed-by: maoliang.ml at alibaba-inc.com ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp + src/share/vm/gc_implementation/g1/g1ConcurrentMarkObjArrayProcessor.cpp + src/share/vm/gc_implementation/g1/g1ConcurrentMarkObjArrayProcessor.hpp + src/share/vm/gc_implementation/g1/g1ConcurrentMarkObjArrayProcessor.inline.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/utilities/taskqueue.hpp Changeset: 776722456213 Author: andrew Date: 2020-08-20 04:10 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/776722456213 Merge Changeset: 63dafc005680 Author: shade Date: 2020-08-21 09:07 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/63dafc005680 8252084: Minimal VM fails to bootcycle: undefined symbol: AgeTableTracer::is_tenuring_distribution_event_enabled Reviewed-by: sgehwolf ! make/excludeSrc.make Changeset: 8712be1ae49a Author: roland Date: 2020-06-30 18:05 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8712be1ae49a 8240676: Meet not symmetric failure when running lucene on jdk8 Reviewed-by: kvn, thartmann ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/types/TestArrayMeetNotSymmetrical.java Changeset: 85e682d8ab91 Author: jbachorik Date: 2020-07-17 11:54 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/85e682d8ab91 8249158: THREAD_START and THREAD_END event posted in primordial phase Reviewed-by: adinn ! src/share/vm/jfr/instrumentation/jfrJvmtiAgent.cpp ! src/share/vm/jfr/jfr.cpp ! src/share/vm/jfr/jfr.hpp ! src/share/vm/jfr/jni/jfrJavaSupport.cpp ! src/share/vm/jfr/jni/jfrJavaSupport.hpp ! src/share/vm/jfr/jni/jfrJniMethod.cpp ! src/share/vm/jfr/recorder/jfrRecorder.cpp ! src/share/vm/jfr/recorder/jfrRecorder.hpp ! src/share/vm/jfr/recorder/service/jfrOptionSet.cpp ! src/share/vm/jfr/recorder/service/jfrOptionSet.hpp ! src/share/vm/runtime/thread.cpp - test/runtime/8233197/T.java - test/runtime/8233197/Test8233197.sh - test/runtime/8233197/libJvmtiAgent.c Changeset: a025f6d9e6e8 Author: sgehwolf Date: 2020-07-24 14:32 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a025f6d9e6e8 8250627: Use -XX:+/-UseContainerSupport for enabling/disabling Java container metrics Reviewed-by: aph, dholmes, bobv, shade ! make/linux/makefiles/mapfile-vers-debug ! make/linux/makefiles/mapfile-vers-product ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h Changeset: 1b2d99958c29 Author: ccheung Date: 2014-11-10 10:13 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1b2d99958c29 8060721: Test runtime/SharedArchiveFile/LimitSharedSizes.java fails in jdk 9 fcs new platforms/compiler Summary: replaced strcat() with jio_snprintf() Reviewed-by: dholmes, iklam, dlong, minqi ! src/share/vm/memory/metaspaceShared.cpp Changeset: 6898cbe6d575 Author: andrew Date: 2020-08-26 03:59 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6898cbe6d575 Added tag jdk8u272-b05 for changeset 1b2d99958c29 ! .hgtags Changeset: 0bb5fba5f9b2 Author: andrew Date: 2020-08-27 06:45 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0bb5fba5f9b2 Merge jdk8u272-b05 ! .hgtags ! make/excludeSrc.make ! make/linux/makefiles/mapfile-vers-debug ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.inline.hpp ! src/share/vm/memory/metaspaceShared.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/compile.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/utilities/taskqueue.hpp - test/runtime/8233197/T.java - test/runtime/8233197/Test8233197.sh - test/runtime/8233197/libJvmtiAgent.c Changeset: 72dbeabdf2d4 Author: andrew Date: 2020-08-27 06:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/72dbeabdf2d4 Added tag aarch64-shenandoah-jdk8u272-b05 for changeset 0bb5fba5f9b2 ! .hgtags From shade at redhat.com Fri Aug 28 05:20:34 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Aug 2020 07:20:34 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252096: Shenandoah: adjust SerialPageShiftCount for x86_32 and JFR In-Reply-To: <3e6f9b6a-998d-6e2c-25cc-c09f400f3168@redhat.com> References: <1a01be59-1aa1-0631-ea54-87d7fd09c98f@redhat.com> <20200827053848.GB1050557@stopbrexit> <3e6f9b6a-998d-6e2c-25cc-c09f400f3168@redhat.com> Message-ID: <1b7d5d7b-d2ef-7590-d9ac-b3b59ffabf88@redhat.com> On 8/27/20 7:47 AM, Aleksey Shipilev wrote: > On 8/27/20 7:38 AM, Andrew Hughes wrote: >> How did you find the correct value? I've been considering backporting >> https://bugs.openjdk.java.net/browse/JDK-8152358 as it makes the assert >> print the expected value. > > I printed out sizeof(JavaThread) in multiple build configurations, and discovered that with both JFR > and Shenandoah it trips over 1024. Which means the expected count is log2_intptr(sizeof(class > JavaThread)) - log2_intptr(64) = log2(2^10) - log2(2^6) = 4. That is basically +1 to current value. > >> Anyway, if it only applies when Shenandoah + JFR are in operation, it explains >> why Azul have not seen it on upstream 8u. Change looks good to me and it will >> be good to get this fixed and JFR enabled on our x86 builds. > > Yes. Pushed: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/04d10e4240b9 -- Thanks, -Aleksey From shade at redhat.com Fri Aug 28 05:21:00 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Aug 2020 07:21:00 +0200 Subject: [aarch64-port-dev ] RFR (XS) 8252366: Shenandoah: revert/cleanup changes in graphKit.cpp In-Reply-To: <20200827055135.GC1050557@stopbrexit> References: <9fb1ffa8-648b-1f69-bd52-7c4fcb2cb098@redhat.com> <875z957oy0.fsf@redhat.com> <4c29fbb37608c2843c54a2f6430ebfa9a3293893.camel@redhat.com> <8736497jrx.fsf@redhat.com> <20200827055135.GC1050557@stopbrexit> Message-ID: On 8/27/20 7:51 AM, Andrew Hughes wrote: > Looks ok to me. Not having a g1_write_barrier_pre_helper function > which is actually Shenandoah-only should add a little clarity :-) Pushed: http://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e0a34665279f -- Thanks, -Aleksey From shade at redhat.com Fri Aug 28 05:48:47 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 28 Aug 2020 07:48:47 +0200 Subject: [aarch64-port-dev ] RFR: Bulk integration shenandoah/jdk8 -> aarch64-port/jdk8u-shenandoah, 2020-08-26 In-Reply-To: References: <20200827060107.GD1050557@stopbrexit> Message-ID: <98638fb1-4623-09e5-0414-9140fec13c5d@redhat.com> On 8/27/20 8:26 AM, Aleksey Shipilev wrote: > On 8/27/20 8:01 AM, Andrew Hughes wrote: >> I've concentrated on the shared code, trusting you guys on the Shenandoah changes. >> >> The only one I'm curious about is the change to >> src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp. There's no >> associated bug ID so where does that change come from and is it >> specified to the 8u Shenandoah port? > > It is specific to 8u Shenandoah port, comes from here: > https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/049078100b90 > > Later refactorings eliminated the file, and the Shenandoah-specific issue (the absence of > CV-qualified overload) with it. So, there is nothing to backport from. > >> I'll post b05 shortly, and presume you will rebase on top of that as >> discussed. > > Yes, sure. Rebased, re-tested, pushed and tagged "aarch64-shenandoah-jdk8u272-b05-shenandoah-merge-2020-08-28" -- Thanks, -Aleksey From ningsheng.jian at arm.com Fri Aug 28 05:56:56 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Fri, 28 Aug 2020 13:56:56 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <35f8801f-4383-4804-2a9b-5818d1bda763@redhat.com> <524a4aaa-3cf7-7b5e-3e0e-0fd7f4f89fbf@oracle.com> <670fad6f-16ff-a7b3-8775-08dd79809ddf@redhat.com> Message-ID: Hi Vladimir, Thanks a lot for helping clarifying your concerns which will benefit future direction. On 8/27/20 8:54 PM, Vladimir Ivanov wrote: > Hi Andrew, > >> So, if I can summarize (please correct me if I misunderstand): >> >> You are as concerned about existing complexity in vector handling as >> much as complexity added by this patch, whether the latter is to AArch64 >> code or shared code. >> >> The goal you would like to achieve is a single set of rules for a >> single kind of vector register whose size is parameterized, the >> appropriate value being derived from each specific vector operation. >> >> Your main concern about this patch is that it adds yet another >> additional vector kind to the current 'wrong' multi-kind vector model >> and, what is worse, one with a different behaviour, taking us further >> from your desired goal. > > Yes, correct. > >> Your other concern is that this design does not allow for the AArch64 >> ISA predication or, indeed, for what you treat uniformly as the >> 'implicit' predication imposed on a 'logical' max vector size (2048 >> bits) by the specific AVX/SVE/NEON hardware vector size. > > No, I'm not concerned about that. I mentioned SVE implicit predication > to illustrate that there's a higher-level abstraction in the JVM above > ISA level which hides some of the functionality ISA exposes. And I'm > perfectly fine with that. > >>> But you should definitely prefer 1-slot design for vector registers then >>> ;-) >> >> Indeed I do :-] >> >> So, let me respond to the above summary points, assuming I have them >> down right. >> >> I agree that your end goal is highly desirable. However, we are not >> there yet and since your attempts to do so have not succeeded so far I >> don't think that means we are compelled to drop the current patch. As >> you say this could (and, if it is adopted, should) be regarded as a >> useful stop-gap until we come up with a unified, parameterized vector >> implementation that makes it redundant. > > Unfortunately, there was simply not enough motivation on x86 (and hence > resources spent) to address it there. Vector API support for x86 > stretched the implementation in a different direction: combinatorial > explosion of AD instructions needed to cover all useful cases. It > required switching to full-width vectors in x86.ad file which left RA > concerns waiting next opportunity. > >> That said, I'm not pushing hard to keep the patch if the consequence is >> generating significant work later to undo it. The number of users who >> might benefit from using SVE vectors from Java now or in the near future >> does not look like it is going to be very large (if you are not making a >> lot of use of SVE registers then that is a lot of wasted silicon and I >> suspect it's going to be the rare case that someone codes an app in Java >> that needs to make continuous use of SVE -- mind you, by the same token >> I guess that also applies for AVX on Intel). > > I don't consider RA part of the patch as the show-stopper issue for > initial SVE support. As I said to Ningsheng, I'm fine with the patch as > it is now if we agree it's a stop-the-gap solution and there's a > commitment to invest into the proper support. > > I initially put options #1/#2 (which don't require any changes in RA > shared code) as possible alternatives way to temporarily address the > problem. Both require additional simplifying assumptions and hence I > didn't insist they should be chosen. > >> I'm not sure pushing this now will add a lot more work later. It seems >> to me that this code is actually moving in the right direction for the >> sort of solution you want. The AArch64 VecA register /is/ >> size-parameterized, albeit by a size fixed at startup rather than per >> operation. So, that's one reason why I don't know if this implies a lot >> more rework to move towards your desired goal. Surely, if we do arrive >> at a unifying vector model that can replace the existing multi-kind >> vectors then it ought to be able to subsume this code - unless of course >> it replaces it wholesale. >> >> Are you concerned that adding this patch will result in more cases to >> pick through and correct? >> >> Are you worried that we might have to withdraw some of the support this >> patch enables to arrive at the final goal? >> >> Also, Ningsheng and his colleagues have laid some foundations for >> implementing predicated operations with this patch and have that work in >> the pipeline. Once again this is moving towards the desired goal even if >> it might end up doign so in a slightly sideways fashion. Perhaps we >> could continue this stop-gap experiment as an experimental option in >> order to learn from the experience? > > I definitely don't want to hinder/block the impressive work Ningsheng > and others at Arm are doing for SVE support. > > Frankly speaking, my main concern is that the implementation can stay > that way forever ;-) That's why I'm trying to get enough ground covered > in the discussion and some agreements/commitments to be made before it > is integrated. > > I don't have any strong objections to the patch which could justify > blocking its integration, but on a higher-level I do voice my concerns > about where it pushes the implementation longer-term. > > Unfortunately, as it is shaped now, I don't see how x86 can benefit from > it. So, I'm afraid this particular route with vecA and _is_scalable bit > will stay purely AArch64-specific exercise. > > Leaving RA part aside, I have one suggestion which should help in the > future: let's try to consistently follow full-width vector abstraction. > In AD file, vecA operand is way too similar to vecX et al which makes a > wrong impression it's yet another vector flavor. So, choosing a better > name will help when representation changes. For example, x86 moved away > from vecX/... operands to a single generic one (called "vec") and you > can take a loot at x86.ad to see the result. > Thanks for the suggestion. In current implementation vecA does not include vecD/vecX for NEON - so actually it's regarded as another vector flavor. We try to keep the SVE implementation separated from original NEON code (and a new ad file is also introduced), to make the code better maintainable and reviewable. What do you think about this naming, Andrew? Thanks, Ningsheng From shade at redhat.com Fri Aug 28 05:48:30 2020 From: shade at redhat.com (shade at redhat.com) Date: Fri, 28 Aug 2020 05:48:30 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 27 new changesets Message-ID: <202008280548.07S5mUSg003860@aojmv0008.oracle.com> Changeset: f3ca97859eae Author: shade Date: 2020-07-20 16:06 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f3ca97859eae Shenandoah: enable low-frequency STW class unloading ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/runtime/arguments.cpp ! test/gc/shenandoah/options/TestClassUnloadingArguments.java Changeset: 5c1d47eb139e Author: zgu Date: 2020-04-08 11:21 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5c1d47eb139e [backport] 8242375: Shenandoah: Remove ShenandoahHeuristic::record_gc_start/end methods Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: 78b721a8ce6b Author: shade Date: 2020-06-18 19:14 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/78b721a8ce6b [backport] 8247860: Shenandoah: add update watermark line in rich assert failure message Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp Changeset: 1712d04788e7 Author: shade Date: 2020-06-17 17:21 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1712d04788e7 [backport] 8247751: Shenandoah: options tests should run with smaller heaps Reviewed-by: zgu, rkennke ! test/gc/shenandoah/options/TestArgumentRanges.java ! test/gc/shenandoah/options/TestClassUnloadingArguments.java ! test/gc/shenandoah/options/TestExplicitGC.java ! test/gc/shenandoah/options/TestExplicitGCNoConcurrent.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestHumongousThresholdArgs.java ! test/gc/shenandoah/options/TestModeUnlock.java ! test/gc/shenandoah/options/TestThreadCounts.java ! test/gc/shenandoah/options/TestThreadCountsOverride.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java ! test/gc/shenandoah/options/TestWrongBarrierEnable.java Changeset: 654f36595763 Author: shade Date: 2020-06-17 17:21 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/654f36595763 [backport] 8247754: Shenandoah: mxbeans tests can be shorter Reviewed-by: rkennke ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java Changeset: e276bbfff22f Author: shade Date: 2020-06-17 17:22 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e276bbfff22f [backport] 8247757: Shenandoah: split heavy tests by heuristics to improve parallelism Reviewed-by: rkennke ! test/gc/shenandoah/TestAllocHumongousFragment.java ! test/gc/shenandoah/TestAllocIntArrays.java ! test/gc/shenandoah/TestAllocObjectArrays.java ! test/gc/shenandoah/TestAllocObjects.java ! test/gc/shenandoah/TestLotsOfCycles.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestRetainObjects.java ! test/gc/shenandoah/TestSieveObjects.java ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java Changeset: c95b025483e0 Author: shade Date: 2020-07-23 12:15 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c95b025483e0 Shenandoah: fix forceful pacer claim Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp Changeset: 2047aa418aa8 Author: shade Date: 2020-07-23 12:46 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2047aa418aa8 [backport] 8249953: Shenandoah: gc/shenandoah/mxbeans tests should account for corner cases Reviewed-by: rkennke ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java Changeset: a9d5e574e818 Author: shade Date: 2020-07-10 10:37 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a9d5e574e818 [backport] 8248652: Shenandoah: SATB buffer handling may assume no forwarded objects Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp Changeset: 118e09aa9462 Author: shade Date: 2020-06-11 18:16 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/118e09aa9462 [backport] 8247367: Shenandoah: pacer should wait on lock instead of exponential backoff Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.inline.hpp Changeset: 226c8031111b Author: shade Date: 2020-06-17 09:43 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/226c8031111b [backport] 8247593: Shenandoah: should not block pacing reporters Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! 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: 1254144cf226 Author: shade Date: 2020-07-19 15:34 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1254144cf226 [backport] 8249649: Shenandoah: provide per-cycle pacing stats Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNumberSeq.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNumberSeq.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/runtime/thread.cpp ! src/share/vm/runtime/thread.hpp Changeset: 144156910d02 Author: shade Date: 2020-07-28 09:28 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/144156910d02 Shenandoah: pacer should use proper Atomics for intptr_t ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.inline.hpp Changeset: 049078100b90 Author: shade Date: 2020-07-29 10:09 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/049078100b90 Shenandoah: Zero build fails after recent Atomic cleanup in Pacer Reviewed-by: rkennke ! src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp Changeset: 01ce0b6fb7e3 Author: zgu Date: 2020-06-23 13:38 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/01ce0b6fb7e3 [backport] 8248041: Shenandoah: pre-Full GC root updates may miss some roots Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: 0026e8c8686d Author: rkennke Date: 2020-07-16 11:49 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0026e8c8686d [backport] 8249560: Shenandoah: Fix racy GC request handling Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp Changeset: 42c534ccf878 Author: rkennke Date: 2020-07-21 17:27 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/42c534ccf878 [backport] 8249801: Shenandoah: Clear soft-refs on requested GC cycle Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp Changeset: dbdef4a76e04 Author: shade Date: 2020-08-10 08:37 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dbdef4a76e04 [backport] 8241574: Shenandoah: remove ShenandoahAssertToSpaceClosure Reviewed-by: zgu, bmathiske, shade Contributed-by: Charlie Gracie ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: c1ddb1744d83 Author: shade Date: 2020-08-10 08:36 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c1ddb1744d83 [backport] 8241007: Shenandoah: remove ShenandoahCriticalControlThreadPriority support Reviewed-by: adityam, shade Contributed-by: Nikola Grcevski ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp - test/gc/shenandoah/options/TestCriticalControlThreadPriority.java Changeset: e2c6c9979d04 Author: shade Date: 2020-05-25 11:05 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e2c6c9979d04 [backport] 8245464: Shenandoah: allocate collection set bitmap at lower addresses Reviewed-by: rkennke ! 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/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp Changeset: 44f0ab6d3c92 Author: shade Date: 2020-05-26 13:07 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/44f0ab6d3c92 [backport] 8245773: Shenandoah: Windows assertion failure after JDK-8245464 Reviewed-by: stuefe ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: d1cc38b8a476 Author: shade Date: 2020-05-06 11:40 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d1cc38b8a476 [backport] 8244509: Shenandoah: refactor ShenandoahBarrierC2Support::test_* methods Reviewed-by: rkennke, roland ! src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.hpp Changeset: 015ad77f5bc1 Author: shade Date: 2020-05-08 23:17 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/015ad77f5bc1 [backport] 8244667: Shenandoah: SBC2Support::test_gc_state takes loop for wrong control Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.cpp Changeset: 6b0b5cfa32d7 Author: shade Date: 2020-05-25 11:05 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6b0b5cfa32d7 [backport] 8245465: Shenandoah: test_in_cset can use more efficient encoding Reviewed-by: rkennke, roland ! src/share/vm/gc_implementation/shenandoah/c2/shenandoahSupport.cpp Changeset: 8dd65390971d Author: shade Date: 2020-08-20 12:52 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8dd65390971d Shenandoah: hook statistics printing to PrintGCDetails, not PrintGC Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp Changeset: 17a0382f0419 Author: shade Date: 2020-08-28 07:17 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/17a0382f0419 Merge ! src/share/vm/runtime/thread.cpp Changeset: 86494fda8cde Author: shade Date: 2020-08-28 07:17 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/86494fda8cde Added tag aarch64-shenandoah-jdk8u272-b05-shenandoah-merge-2020-08-28 for changeset 17a0382f0419 ! .hgtags From shade at redhat.com Fri Aug 28 05:48:30 2020 From: shade at redhat.com (shade at redhat.com) Date: Fri, 28 Aug 2020 05:48:30 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: Added tag aarch64-shenandoah-jdk8u272-b05-shenandoah-merge-2020-08-28 for changeset 5915068874b5 Message-ID: <202008280548.07S5mUOI003857@aojmv0008.oracle.com> Changeset: 106e12306470 Author: shade Date: 2020-08-28 07:17 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/106e12306470 Added tag aarch64-shenandoah-jdk8u272-b05-shenandoah-merge-2020-08-28 for changeset 5915068874b5 ! .hgtags From adinn at redhat.com Fri Aug 28 09:21:29 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 28 Aug 2020 10:21:29 +0100 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <35f8801f-4383-4804-2a9b-5818d1bda763@redhat.com> <524a4aaa-3cf7-7b5e-3e0e-0fd7f4f89fbf@oracle.com> <670fad6f-16ff-a7b3-8775-08dd79809ddf@redhat.com> Message-ID: On 28/08/2020 06:56, Ningsheng Jian wrote: > On 8/27/20 8:54 PM, Vladimir Ivanov wrote: >> I definitely don't want to hinder/block the impressive work Ningsheng >> and others at Arm are doing for SVE support. >> >> Frankly speaking, my main concern is that the implementation can stay >> that way forever ;-) That's why I'm trying to get enough ground covered >> in the discussion and some agreements/commitments to be made before it >> is integrated. Sure, I agree that we should use this implementation as a stepping stone to a set of unified AArch64 vector rules that handle operations for vectors of all size. Having looked at the latest x86 vector code I get the impression that there is a much greater problem unifying the plethora of different cases within the x86_64 family than there will be unifying x86_64 and AArch64 in this regard. Your solution of using the vec (and legVec) register class(es) has tamed the proliferation of match rules yet it still leaves a great deal of complexity in the logic that controls the handling of those matches. I think it will be much easier to subsume the AArch64 Neon and SVE cases under one common vec type and the resulting case handling will be much less complex. Of course, the rationale for doing so is far less pressing than with x86 since the multiplication of match rules is not so large (particularly as there is no cross-combination with memory operands). Yet, it still seems worth doing. >> Leaving RA part aside, I have one suggestion which should help in the >> future: let's try to consistently follow full-width vector abstraction. >> In AD file, vecA operand is way too similar to vecX et al which makes a >> wrong impression it's yet another vector flavor. So, choosing a better >> name will help when representation changes. For example, x86 moved away >> from vecX/... operands to a single generic one (called "vec") and you >> can take a loot at x86.ad to see the result. > > Thanks for the suggestion. In current implementation vecA does not > include vecD/vecX for NEON - so actually it's regarded as another vector > flavor. We try to keep the SVE implementation separated from original > NEON code (and a new ad file is also introduced), to make the code > better maintainable and reviewable. What do you think about this naming, > Andrew? If the goal is that eventually a vec register class will parametrize the relevant rules for VecD, VecX and VecA operations then I don't see any harm in re-labelling the vecA class to simply be called vec. The intention to use this to handle all cases can be signalled by documenting this register class to explain that it is currently only used to specify VecA rules but will eventually be used as a generic class, parameterizing rules that subsume all applicable VecD, VecX and VecA cases. When that happens we can quite naturally fold the aarch64_sve rules back into aarch64.ad with common and/or special case handling merging under a single rule. regards, Andrew Dinn ----------- Red Hat Distinguished Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From vladimir.x.ivanov at oracle.com Fri Aug 28 09:56:10 2020 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 28 Aug 2020 12:56:10 +0300 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <35f8801f-4383-4804-2a9b-5818d1bda763@redhat.com> <524a4aaa-3cf7-7b5e-3e0e-0fd7f4f89fbf@oracle.com> <670fad6f-16ff-a7b3-8775-08dd79809ddf@redhat.com> Message-ID: <9b585dff-38be-16b5-b1a1-4ea0207458b9@oracle.com> >>> Frankly speaking, my main concern is that the implementation can stay >>> that way forever ;-) That's why I'm trying to get enough ground covered >>> in the discussion and some agreements/commitments to be made before it >>> is integrated. > > Sure, I agree that we should use this implementation as a stepping stone > to a set of unified AArch64 vector rules that handle operations for > vectors of all size. Having looked at the latest x86 vector code I get > the impression that there is a much greater problem unifying the > plethora of different cases within the x86_64 family than there will be > unifying x86_64 and AArch64 in this regard. Your solution of using the > vec (and legVec) register class(es) has tamed the proliferation of match > rules yet it still leaves a great deal of complexity in the logic that > controls the handling of those matches. I believe you are referring to ubiquitous presence of predicates in AD instructions for vector cases. The root cause is that operands have very limited influence on matching logic. There's a promising idea to introduce predicated operands and factor complex predicates into a set of simpler ones placed on operands instead. It should significantly reduce the perceived complexity, but the prototyping hasn't been finished yet. [...] >>> Leaving RA part aside, I have one suggestion which should help in the >>> future: let's try to consistently follow full-width vector abstraction. >>> In AD file, vecA operand is way too similar to vecX et al which makes a >>> wrong impression it's yet another vector flavor. So, choosing a better >>> name will help when representation changes. For example, x86 moved away >>> from vecX/... operands to a single generic one (called "vec") and you >>> can take a loot at x86.ad to see the result. >> >> Thanks for the suggestion. In current implementation vecA does not >> include vecD/vecX for NEON - so actually it's regarded as another vector >> flavor. We try to keep the SVE implementation separated from original >> NEON code (and a new ad file is also introduced), to make the code >> better maintainable and reviewable. What do you think about this naming, >> Andrew? > If the goal is that eventually a vec register class will parametrize the > relevant rules for VecD, VecX and VecA operations then I don't see any > harm in re-labelling the vecA class to simply be called vec. The > intention to use this to handle all cases can be signalled by > documenting this register class to explain that it is currently only > used to specify VecA rules but will eventually be used as a generic > class, parameterizing rules that subsume all applicable VecD, VecX and > VecA cases. When that happens we can quite naturally fold the > aarch64_sve rules back into aarch64.ad with common and/or special case > handling merging under a single rule. One more point on naming: though it was me who proposed the name "vec" on x86, I don't think it's the best option anymore. Considering it's desirable to get rid of VecS/VecD/VecX/... machine ideal registers and replace them with a single one, I think using Op_RegV is a better alternative to Op_Vec. Hence, regV/rRegV/vReg look better (depending on conventions adopted in particular AD file). Best regards, Vladimir Ivanov From hohensee at amazon.com Fri Aug 28 16:40:28 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Fri, 28 Aug 2020 16:40:28 +0000 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) Message-ID: <5D556B7D-1995-4FBC-9176-E79FFC789571@amazon.com> One's perspective on the benchmark results depends on the expected frequency of the input types. If we don't expect frequent NaNs (I don?t, because they mean your algorithm is numerically unstable and you're wasting your time running it), or zeros (somewhat arguable, but note that most codes go to some lengths to eliminate zeros, e.g., using sparse arrays), then this patch seems to me to be a win. Thanks, Paul ?On 8/25/20, 9:57 AM, "hotspot-compiler-dev on behalf of Andrew Haley" wrote: On 24/08/2020 22:52, Dmitry Chuyko wrote: > > I added two more intrinsics -- for copySign, they are controlled by > UseCopySignIntrinsic flag. > > webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.03/ > > It also contains 'benchmarks' directory: > http://cr.openjdk.java.net/~dchuyko/8251525/webrev.03/benchmarks/ > > There are 8 benchmarks there: (double | float) x (blackhole | reduce) x > (current j.l.Math.signum | abs()>0 check). > > My results on Arm are in signum-facgt-copysign.ods. Main case is > 'random' which is actually a random from positive and negative numbers > between -0.5 and +0.5. > > Basically we have ~14% improvement in 'reduce' benchmark variant but > ~20% regression in 'blackhole' variant in case of only copySign() > intrinsified. > > Same picture if abs()>0 check is used in signum() (+-5%). This variant > is included as it shows very good results on x86. > > Intrinsic for signum() gives improvement of main case in both > 'blackhole' and 'reduce' variants of benchmark: 28% and 11%, which is a > noticeable difference. Ignoring Blackhole for the moment, this is what I'm seeing for the reduction/random case: Benchmark Mode Cnt Score Error Units ThunderX 2: -XX:-UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 2.456 ? 0.065 ns/op -XX:+UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 2.766 ? 0.107 ns/op -XX:-UseSignumIntrinsic -XX:+UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 2.537 ? 0.770 ns/op Neoverse N1 (Actually Amazon m6g.16xlarge): -XX:-UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 1.173 ? 0.001 ns/op -XX:+UseSignumIntrinsic -XX:-UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 1.043 ? 0.022 ns/op -XX:-UseSignumIntrinsic -XX:+UseCopySignIntrinsic DoubleReduceBench.ofRandom avgt 3 1.012 ? 0.001 ns/op By your own numbers, in the reduce benchmark the signum intrinsic is worse than default for all 0 and NaN, but about 12% better for random, >0, and <0. If you take the average of the sppedups and slowdowns it's actually worse than default. By my reckoning, if you take all possibilities (Nan, <0, >0, 0, Random) into account, the best-performing on the reduce test is actually Abs/Copysign, but there's very little in it. The only time that the signum intrinsic actually wins is when you're storing the result into memory *and* flushing the store buffer. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Fri Aug 28 17:21:29 2020 From: aph at redhat.com (aph at redhat.com) Date: Fri, 28 Aug 2020 17:21:29 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk-windows: If you insist Message-ID: <202008281721.07SHLTZY025057@aojmv0008.oracle.com> Changeset: 40e31a529468 Author: aph Date: 2020-08-28 18:21 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk-windows/rev/40e31a529468 If you insist - DELETEME From aph at redhat.com Sun Aug 30 08:34:57 2020 From: aph at redhat.com (Andrew Haley) Date: Sun, 30 Aug 2020 09:34:57 +0100 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: <5D556B7D-1995-4FBC-9176-E79FFC789571@amazon.com> References: <5D556B7D-1995-4FBC-9176-E79FFC789571@amazon.com> Message-ID: <8289015c-711b-286f-ba99-e589edfed8a5@redhat.com> On 28/08/2020 17:40, Hohensee, Paul wrote: > One's perspective on the benchmark results depends on the expected > frequency of the input types. If we don't expect frequent NaNs (I > don?t, because they mean your algorithm is numerically unstable and > you're wasting your time running it), or zeros (somewhat arguable, > but note that most codes go to some lengths to eliminate zeros, > e.g., using sparse arrays), then this patch seems to me to be a win. Possibly. But it's a significant change that improves some cases while making some other cases worse. When it does makes some cases better, it's only by a small factor and it's not consistent across hardware implementations. Please consider the numbers. When you look at Abs/Copysign it improves all cases except 0, and it doesn't make any of them any worse. Copysign on its own gets close. Copysign is nearly as good. That's true at least for the reduce case, which I argue is representative, more so than the blackhole case, where the blackhole operation itself swamps the calculation we're trying to measure. Ignoring NaN, I've added averages for the four cases to http://cr.openjdk.java.net/~aph/signum-facgt-copysign.ods. But we still don't know what effect all of this has, if any, on real code. My guess is that copysign should always helps because it avoids a move between FPU and integer unit and is otherwise identical. But the blackhole benchmark suggests it can make latency worse, and I have no explanation for that. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ningsheng.jian at arm.com Mon Aug 31 04:00:48 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Mon, 31 Aug 2020 12:00:48 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: <9b585dff-38be-16b5-b1a1-4ea0207458b9@oracle.com> References: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> <707df21c-849d-ac9d-0ab2-61a30d1354f9@arm.com> <2df4a73f-7e84-87f1-6b2f-1ed6b45bbc27@redhat.com> <8bc0d357-07e7-ae55-b7b2-23ec54ea3e6a@arm.com> <01af5faf-0a40-fd8d-4466-5387e5b2c08c@oracle.com> <23fe078f-bdf8-d010-4e7d-0e699ecaf842@arm.com> <59e535e4-05bc-38cc-0049-5d9f29a882cb@oracle.com> <35f8801f-4383-4804-2a9b-5818d1bda763@redhat.com> <524a4aaa-3cf7-7b5e-3e0e-0fd7f4f89fbf@oracle.com> <670fad6f-16ff-a7b3-8775-08dd79809ddf@redhat.com> <9b585dff-38be-16b5-b1a1-4ea0207458b9@oracle.com> Message-ID: Hi Vladimir, On 8/28/20 5:56 PM, Vladimir Ivanov wrote: > [...] > > One more point on naming: though it was me who proposed the name "vec" > on x86, I don't think it's the best option anymore. Considering it's > desirable to get rid of VecS/VecD/VecX/... machine ideal registers and > replace them with a single one, I think using Op_RegV is a better > alternative to Op_Vec. Hence, regV/rRegV/vReg look better (depending on > conventions adopted in particular AD file). > vReg looks good to me. I will update it in the new webrev. Thanks! Regards, Ningsheng From felix.yang at huawei.com Mon Aug 31 06:50:34 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 31 Aug 2020 06:50:34 +0000 Subject: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic Message-ID: Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8252204 Webrev: http://cr.openjdk.java.net/~fyang/8252204/webrev.00/ This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-ce-core.S?h=v5.4.52 Trivial adaptation in SHA3. implCompress is needed for the purpose of adding the intrinsic. For SHA3, we need to pass one extra parameter "digestLength" to the stub for the calculation of block size. "digestLength" is also used in for the EOR loop before keccak to differentiate different SHA3 variants. We added jtreg tests for SHA3 and used QEMU system emulator which supports SHA3 instructions to test the functionality. Patch passed jtreg tier1-3 tests with QEMU system emulator. Also verified with jtreg tier1-3 tests without SHA3 instructions on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that there's no regression. We used one existing JMH test for performance test: test/micro/org/openjdk/bench/java/security/MessageDigests.java We measured the performance benefit with an aarch64 cycle-accurate simulator. Patch delivers 20% - 40% performance improvement depending on specific SHA3 digest length and size of the message. For now, this feature will not be enabled automatically for aarch64. We can auto-enable this when it is fully tested on real hardware. But for the above testing purposes, this is auto-enabled when the corresponding hardware feature is detected. Comments? Thanks, Felix From beurba at microsoft.com Mon Aug 31 07:51:59 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 31 Aug 2020 07:51:59 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk-windows: If you insist In-Reply-To: <202008281721.07SHLTZY025057@aojmv0008.oracle.com> References: <202008281721.07SHLTZY025057@aojmv0008.oracle.com> Message-ID: ooops? :-) ________________________________________ From: aarch64-port-dev on behalf of aph at redhat.com Sent: Friday, August 28, 2020 19:21 To: aarch64-port-dev at openjdk.java.net Subject: [aarch64-port-dev ] hg: aarch64-port/jdk-windows: If you insist Changeset: 40e31a529468 Author: aph Date: 2020-08-28 18:21 +0100 URL: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhg.openjdk.java.net%2Faarch64-port%2Fjdk-windows%2Frev%2F40e31a529468&data=02%7C01%7Cbeurba%40microsoft.com%7C4fd27b2df57f4c7388cb08d84b783e88%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637342327103988049&sdata=AIkKOgfacNk30Df1fb6v6ntFuiigrE3PR6Ku0j52ceg%3D&reserved=0 If you insist - DELETEME From aph at redhat.com Mon Aug 31 08:41:26 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 31 Aug 2020 09:41:26 +0100 Subject: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: References: Message-ID: <1729f1b1-056d-76c9-c820-d38bd6c1235d@redhat.com> On 31/08/2020 07:50, Yangfei (Felix) wrote: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252204 > Webrev: http://cr.openjdk.java.net/~fyang/8252204/webrev.00/ > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto Extensions. > Reference implementation for core SHA-3 transform using ARMv8.2 Crypto Extensions: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/crypto/sha3-cecore.S?h=v5.4.52 > Trivial adaptation in SHA3. implCompress is needed for the purpose > of adding the intrinsic. For SHA3, we need to pass one extra > parameter "digestLength" to the stub for the calculation of block > size. "digestLength" is also used in for the EOR loop before > keccak to differentiate different SHA3 variants. > > We added jtreg tests for SHA3 and used QEMU system emulator > which supports SHA3 instructions to test the functionality. > Patch passed jtreg tier1-3 tests with QEMU system emulator. > Also verified with jtreg tier1-3 tests without SHA3 instructions > on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that > there's no regression. > > We used one existing JMH test for performance test: > test/micro/org/openjdk/bench/java/security/MessageDigests.java > We measured the performance benefit with an aarch64 > cycle-accurate simulator. > Patch delivers 20% - 40% performance improvement depending on > specific SHA3 digest length and size of the message. > For now, this feature will not be enabled automatically for > aarch64. We can auto-enable this when it is fully tested on > real hardware. > But for the above testing purposes, this is auto-enabled when > the corresponding hardware feature is detected. > > Comments? This looks like a direct copy of the sha3-cecore.S file.You'll need Linaro to contribute it. I don't imagine they'll have any problem with that: they are OCA signatories Also, given that we've got the assembly source file, why not just copy that into OpenJDK? I can't see the point rewriting it into the HotSpot assembler. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Mon Aug 31 09:26:38 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 31 Aug 2020 10:26:38 +0100 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk-windows: If you insist In-Reply-To: References: <202008281721.07SHLTZY025057@aojmv0008.oracle.com> Message-ID: <368b9cff-8f0b-183b-a51a-d6b7952037ea@redhat.com> On 31/08/2020 08:51, Bernhard Urban-Forster wrote: > ooops? :-) Not at all, why do you ask? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From felix.yang at huawei.com Mon Aug 31 09:46:58 2020 From: felix.yang at huawei.com (Yangfei (Felix)) Date: Mon, 31 Aug 2020 09:46:58 +0000 Subject: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 accelerator/intrinsic In-Reply-To: <1729f1b1-056d-76c9-c820-d38bd6c1235d@redhat.com> References: <1729f1b1-056d-76c9-c820-d38bd6c1235d@redhat.com> Message-ID: > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Monday, August 31, 2020 4:41 PM > To: Yangfei (Felix) ; hotspot-compiler- > dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] RFR: 8252204: AArch64: Implement SHA3 > accelerator/intrinsic > > On 31/08/2020 07:50, Yangfei (Felix) wrote: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8252204 > > Webrev: http://cr.openjdk.java.net/~fyang/8252204/webrev.00/ > > > > This added an intrinsic for SHA3 using aarch64 v8.2 SHA3 Crypto > Extensions. > > Reference implementation for core SHA-3 transform using ARMv8.2 > Crypto Extensions: > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/ar > m64/crypto/sha3-cecore.S?h=v5.4.52 > > Trivial adaptation in SHA3. implCompress is needed for the purpose > > of adding the intrinsic. For SHA3, we need to pass one extra > > parameter "digestLength" to the stub for the calculation of block > > size. "digestLength" is also used in for the EOR loop before > > keccak to differentiate different SHA3 variants. > > > > We added jtreg tests for SHA3 and used QEMU system emulator > > which supports SHA3 instructions to test the functionality. > > Patch passed jtreg tier1-3 tests with QEMU system emulator. > > Also verified with jtreg tier1-3 tests without SHA3 instructions > > on aarch64-linux-gnu and x86_64-linux-gnu, to make sure that > > there's no regression. > > > > We used one existing JMH test for performance test: > > test/micro/org/openjdk/bench/java/security/MessageDigests.java > > We measured the performance benefit with an aarch64 > > cycle-accurate simulator. > > Patch delivers 20% - 40% performance improvement depending on > > specific SHA3 digest length and size of the message. > > For now, this feature will not be enabled automatically for > > aarch64. We can auto-enable this when it is fully tested on > > real hardware. > > But for the above testing purposes, this is auto-enabled when > > the corresponding hardware feature is detected. > > > > Comments? > > This looks like a direct copy of the sha3-cecore.S file.You'll need Linaro to > contribute it. I don't imagine they'll have any problem with that: they are > OCA signatories Since the code in sha3-cecore.S works in kernel space, we need several modifications here to makes it work in hotspot. First, we need to add callee-save & restore for d8 - d15 according to the aarch64 abi. Also, the following code snippet is not needed for user-space: if_will_cond_yield_neon add x8, x19, #32 st1 { v0.1d- v3.1d}, [x19] st1 { v4.1d- v7.1d}, [x8], #32 st1 { v8.1d-v11.1d}, [x8], #32 st1 {v12.1d-v15.1d}, [x8], #32 st1 {v16.1d-v19.1d}, [x8], #32 st1 {v20.1d-v23.1d}, [x8], #32 st1 {v24.1d}, [x8] do_cond_yield_neon b 0b endif_yield_neon And we need to handle the multi-block case differently for StubRoutines::sha3_implCompressMB: 3485 if (multi_block) { 3486 // block_size = 200 - 2 * digest_length, ofs += block_size 3487 __ add(ofs, ofs, 200); 3488 __ sub(ofs, ofs, digest_length, Assembler::LSL, 1); 3489 3490 __ cmp(ofs, limit); 3491 __ br(Assembler::LE, sha3_loop); 3492 __ mov(c_rarg0, ofs); // return ofs 3493 } And StubRoutines::sha3_implCompress does not even need this multi-block check logic. > Also, given that we've got the assembly source file, why not just copy that > into OpenJDK? I can't see the point rewriting it into the HotSpot assembler. Actually, we referenced the existing intrinsics implementation and took a similar way. It looks strange to have one intrinsic that goes differently. And we won't be able to emit this code on demand if we go that different way. Some cpu does not support these special sha3 instructions and thus does need this code at all. I think that's one advantage of using a stub. Thanks, Felix From dmitry.chuyko at bell-sw.com Mon Aug 31 14:28:46 2020 From: dmitry.chuyko at bell-sw.com (Dmitry Chuyko) Date: Mon, 31 Aug 2020 17:28:46 +0300 Subject: [aarch64-port-dev ] [16] RFR(S): 8251525: AARCH64: Faster Math.signum(fp) In-Reply-To: References: <4b0176e2-317b-8fa2-1409-0f77be3f41c3@redhat.com> <67e67230-cac7-d940-1cca-6ab4e8cba8d4@redhat.com> <9e792a33-4f90-8829-2f7b-158d07d3fd15@bell-sw.com> Message-ID: <0cca5c0c-9240-3a9f-98f0-519384ea69cb@bell-sw.com> Hi Andrew, Here is another version of intrinsics. It is an extension of webrev.03. Additional thing is that constants 0 and 1 that are used internally by intrinics are constructed as nodes. This is somehow similar to what is done for passing pointers to tables. webrev: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.04/ results: http://cr.openjdk.java.net/~dchuyko/8251525/webrev.04/benchmarks/signum-facgt_ir-copysign.ods As you can see the case of intrinsic for entire signum is now up to 29.2% better for "random" data. NaN is 30% better also. The only suffering case is 0, which is just 1 number (in two representations) of the whole range, and the regression is ~7%/10%. Performance in case of 0 becomes the same as for all other numbers (and NaN). I don't suppose that 0 is so special. Because if input data is all zeroes and program produces zeroes during the computation, it is trivial. If zero make half of the data, there still be a win. For the case of copySign(double), making a constant in IR amplifies regression in Blackhole benchmark, but still may be interesting to experiment with. Just in case, it will be interesting to remeasure Blackhole variants if compiler support [1] will be implemented. Here is also a benchmark variant [2] where we consume different data, and it shows same effects as Blackhole.consume(signum). -Dmitry [1] https://bugs.openjdk.java.net/browse/JDK-8252505 [2] http://cr.openjdk.java.net/~dchuyko/8251525/webrev.04/benchmarks/DoubleSideSinkBench.java From ci_notify at linaro.org Mon Aug 31 16:21:57 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Mon, 31 Aug 2020 16:21:57 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 4337 Failure Message-ID: <1430538204.7376.1598890918369@localhost> OpenJDK AArch64 jdk/jdk build status is Failure Build details - https://ci.linaro.org/jenkins/job/jdkX-ci-build/4337/ Changes - pconcannon: e10f558e1df506f1b7ef825cb0239074d69f2939 - test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/mapMultiOpTest.java - src/java.base/share/classes/java/util/stream/DoublePipeline.java - src/java.base/share/classes/java/util/stream/DoubleStream.java - src/java.base/share/classes/java/util/stream/IntPipeline.java - src/java.base/share/classes/java/util/stream/IntStream.java - src/java.base/share/classes/java/util/stream/LongPipeline.java - src/java.base/share/classes/java/util/stream/LongStream.java - src/java.base/share/classes/java/util/stream/ReferencePipeline.java - src/java.base/share/classes/java/util/stream/Stream.java - test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/FlatMapOpTest.java --"8238286: Add new flatMap stream operation that is more amenable to pushing Summary: This patch adds a new flatmap-like operation called mapMulti to the java.util.Stream class as well as the primitive variations of this operation i.e. mapMultiToInt, IntStream mapMulti, etc. Reviewed-by: psandoz, smarks " iklam: ee2c69f0637051d304c1d8c9428e4ff9f3a47b20 - src/hotspot/share/classfile/classLoadInfo.hpp - src/hotspot/share/aot/aotCodeHeap.cpp - src/hotspot/share/ci/ciField.cpp - src/hotspot/share/ci/ciReplay.cpp - src/hotspot/share/classfile/classFileParser.cpp - src/hotspot/share/classfile/classListParser.cpp - src/hotspot/share/classfile/classLoader.cpp - src/hotspot/share/classfile/classLoaderExt.cpp - src/hotspot/share/classfile/dictionary.cpp - src/hotspot/share/classfile/dictionary.hpp - src/hotspot/share/classfile/javaClasses.cpp - src/hotspot/share/classfile/javaClasses.hpp - src/hotspot/share/classfile/klassFactory.cpp - src/hotspot/share/classfile/systemDictionary.cpp - src/hotspot/share/classfile/systemDictionary.hpp - src/hotspot/share/classfile/systemDictionaryShared.hpp - src/hotspot/share/gc/g1/g1Arguments.cpp - src/hotspot/share/gc/g1/g1CollectedHeap.cpp - src/hotspot/share/gc/parallel/mutableNUMASpace.cpp - src/hotspot/share/gc/parallel/psParallelCompact.cpp - src/hotspot/share/gc/shared/gcVMOperations.cpp - src/hotspot/share/jfr/instrumentation/jfrEventClassTransformer.cpp - src/hotspot/share/jvmci/jvmciCompilerToVM.cpp - src/hotspot/share/jvmci/jvmciJavaClasses.cpp - src/hotspot/share/jvmci/jvmciRuntime.cpp - src/hotspot/share/memory/virtualspace.cpp - src/hotspot/share/oops/instanceKlass.cpp - src/hotspot/share/oops/klass.inline.hpp - src/hotspot/share/prims/jvm.cpp - src/hotspot/share/prims/jvmtiRedefineClasses.cpp - src/hotspot/share/prims/methodHandles.cpp - src/hotspot/share/prims/unsafe.cpp - src/hotspot/share/runtime/fieldDescriptor.inline.hpp - src/hotspot/share/runtime/signature.cpp - src/hotspot/share/runtime/signature.hpp --"8251560: Remove excessive header file inclusion from systemDictionary.hpp and others Reviewed-by: coleenp " Build output - Compiling 14 files for jdk.management.jfr Compiling 8 files for jdk.net Compiling 2 files for jdk.nio.mapmode Compiling 33 files for jdk.sctp Compiling 94 files for jdk.xml.dom Compiling 14 files for jdk.zipfs Compiling 15 files for java.prefs Compiling 197 files for java.naming Compiling 77 files for java.sql Compiling 15 files for jdk.attach Compiling 74 files for jdk.crypto.cryptoki Compiling 136 files for jdk.jdeps Compiling 40 files for jdk.jcmd Compiling 251 files for jdk.jdi Compiling 16 files for jdk.naming.dns Compiling 8 files for jdk.naming.rmi Compiling 2781 files for java.desktop Compiling 16 files for java.management.rmi Compiling 219 files for java.security.jgss Compiling 56 files for java.sql.rowset Compiling 83 files for jdk.jlink Compiling 31 files for jdk.management.agent Compiling 95 files for jdk.jshell Compiling 30 files for jdk.security.auth Compiling 16 files for jdk.security.jgss Compiling 1644 files for jdk.internal.vm.compiler Compiling 107 files for jdk.aot Compiling 70 files for COMPILE_CREATE_SYMBOLS Creating ct.sym classes Compiling 3 files for jdk.internal.vm.compiler.management Compiling 64 files for jdk.jconsole Compiling 8 files for jdk.unsupported.desktop Compiling 1 files for java.se Compiling 18 files for jdk.accessibility Updating support/src.zip Compiling 3 files for jdk.editpad Compiling 944 files for jdk.hotspot.agent Compiling 47 files for jdk.incubator.jpackage /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp: In member function 'virtual void ShenandoahArguments::initialize()': /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:77:100: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ConcGCThreads > 0, check -XX:ConcGCThreads=#"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:91:108: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ParallelGCThreads > 0, check -XX:ParallelGCThreads=#"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:104:78: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah thread count ergonomic error"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:107:140: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ConcGCThreads <= ParallelGCThreads, check -XX:ParallelGCThreads, -XX:ConcGCThreads"); ^ At global scope: cc1plus: error: unrecognized command line option '-Wno-shift-negative-value' [-Werror] cc1plus: error: unrecognized command line option '-Wno-cast-function-type' [-Werror] cc1plus: error: unrecognized command line option '-Wno-misleading-indentation' [-Werror] cc1plus: error: unrecognized command line option '-Wno-implicit-fallthrough' [-Werror] cc1plus: error: unrecognized command line option '-Wno-int-in-bool-context' [-Werror] cc1plus: all warnings being treated as errors lib/CompileJvm.gmk:141: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahArguments.o' failed make[3]: *** [/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahArguments.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make/Main.gmk:259: recipe for target 'hotspot-server-libs' failed make[2]: *** [hotspot-server-libs] Error 1 ERROR: Build failed for target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' (exit code 2) === Output from failing command(s) repeated here === * For target hotspot_variant-server_libjvm_objs_shenandoahArguments.o: /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp: In member function 'virtual void ShenandoahArguments::initialize()': /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:77:100: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ConcGCThreads > 0, check -XX:ConcGCThreads=#"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:91:108: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ParallelGCThreads > 0, check -XX:ParallelGCThreads=#"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:104:78: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah thread count ergonomic error"); ^ /home/buildslave/workspace/jdkX-ci-build/jdkX/src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:107:140: error: 'vm_exit_during_initialization' was not declared in this scope vm_exit_during_initialization("Shenandoah expects ConcGCThreads <= ParallelGCThreads, check -XX:ParallelGCThreads, -XX:ConcGCThreads"); ^ At global scope: cc1plus: error: unrecognized command line option '-Wno-shift-negative-value' [-Werror] ... (rest of output omitted) * All command lines available in /home/buildslave/workspace/jdkX-ci-build/build/make-support/failure-logs. === End of repeated output === === Make failed targets repeated here === lib/CompileJvm.gmk:141: recipe for target '/home/buildslave/workspace/jdkX-ci-build/build/hotspot/variant-server/libjvm/objs/shenandoahArguments.o' failed make/Main.gmk:259: recipe for target 'hotspot-server-libs' failed === End of repeated output === Hint: Try searching the build log for the name of the first failed target. Hint: See doc/building.html#troubleshooting for assistance. /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:310: recipe for target 'main' failed make[1]: *** [main] Error 1 /home/buildslave/workspace/jdkX-ci-build/jdkX/make/Init.gmk:186: recipe for target 'images' failed make: *** [images] Error 2 From beurba at microsoft.com Mon Aug 31 17:01:13 2020 From: beurba at microsoft.com (Bernhard Urban-Forster) Date: Mon, 31 Aug 2020 17:01:13 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk-windows: If you insist In-Reply-To: <368b9cff-8f0b-183b-a51a-d6b7952037ea@redhat.com> References: <202008281721.07SHLTZY025057@aojmv0008.oracle.com> , <368b9cff-8f0b-183b-a51a-d6b7952037ea@redhat.com> Message-ID: I'm not sure what the purpose is of those two commits. ________________________________________ From: Andrew Haley Sent: Monday, August 31, 2020 11:26 To: Bernhard Urban-Forster; aarch64-port-dev at openjdk.java.net Subject: Re: [aarch64-port-dev ] hg: aarch64-port/jdk-windows: If you insist On 31/08/2020 08:51, Bernhard Urban-Forster wrote: > ooops? :-) Not at all, why do you ask? -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fandrewhaley&data=02%7C01%7Cbeurba%40microsoft.com%7C7f807364e85f4702a1f808d84d8ffa1c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637344628052571356&sdata=kKW7jozBHku0Sie8Ayjjkz%2FQml3zoxyEjzX%2Fm9B5Azk%3D&reserved=0 EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From doug.simon at oracle.com Mon Aug 10 09:55:47 2020 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 10 Aug 2020 09:55:47 -0000 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 In-Reply-To: References: Message-ID: <9074F4C9-589A-4519-BBAB-2F3161B814D7@oracle.com> Hi Ludovic, Are you considering also implementing this intrinsic in Graal? Is the intrinsification purely about removing the array bounds checks? If so, it may be possible to have the Graal intrinsify the method by compiling the relevant Java code without array bounds checks. -Doug > On 9 Aug 2020, at 05:19, Ludovic Henry wrote: > > Hello, > > Bug: https://bugs.openjdk.java.net/browse/JDK-8251216 > Webrev: http://cr.openjdk.java.net/~luhenry/8251216/webrev.00 > > Testing: Linux-AArch64, fastdebug, test/hotspot/jtreg/compiler/intrinsics/sha/ test/hotspot/jtreg:tier1 test/jdk:tier1 > > This patch implements the MD5 intrinsic on AArch64 following its implementation on x86 [1]. The performance improvements are the following (on Linux-AArch64 on a Marvell TX2): > > -XX:-UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 1616.238 ? 28.082 ops/ms > MessageDigests.digest md5 1024 DEFAULT thrpt 10 215.030 ? 0.691 ops/ms > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.228 ? 0.001 ops/ms > > -XX:+UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 2005.233 ? 40.513 ops/ms => 24% speedup > MessageDigests.digest md5 1024 DEFAULT thrpt 10 275.979 ? 0.455 ops/ms => 28% speedup > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.279 ? 0.001 ops/ms => 22% speedup > > Thank you, > Ludovic > > [1] https://bugs.openjdk.java.net/browse/JDK-8250902 From doug.simon at oracle.com Mon Aug 10 13:38:56 2020 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 10 Aug 2020 13:38:56 -0000 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 In-Reply-To: References: <9074F4C9-589A-4519-BBAB-2F3161B814D7@oracle.com> Message-ID: Hi Bernhard, > On 10 Aug 2020, at 15:01, Bernhard Urban-Forster wrote: > > Hey Doug, > > replying on behalf for Ludovic, as he is on vacation :-) > > Currently we are not planning to implement the intrinsic for Graal. Schade ;-) > Also we didn't check the generated code by Graal. I believe it will do a better job eliminated array bounds checks, but I'm curious to learn how "compiling the relevant Java code without array bounds checks" works. Is something like that done for other methods already? I don?t think we do that anywhere currently but I imagine it wouldn?t be hard to put the BytecodeParser into a mode whereby an array access generates a AccessIndexedNode that omits the bounds check (generated by org.graalvm.compiler.replacements.DefaultJavaLoweringProvider.getBoundsCheck). -Doug > > This is the relevant Java method for the MD5 intrinsic: > https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/733218137289d6a0eb705103ed7be30f1e68d17a/src/java.base/share/classes/sun/security/provider/MD5.java*L172__;Iw!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E6ijVLDV$ > > > -Bernhard > > ________________________________________ > From: Doug Simon > > Sent: Monday, August 10, 2020 11:55 > To: Ludovic Henry > Cc: hotspot-compiler-dev at openjdk.java.net ; aarch64-port-dev at openjdk.java.net ; openjdk-aarch64 > Subject: Re: [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 > > Hi Ludovic, > > Are you considering also implementing this intrinsic in Graal? > > Is the intrinsification purely about removing the array bounds checks? If so, it may be possible to have the Graal intrinsify the method by compiling the relevant Java code without array bounds checks. > > -Doug > >> On 9 Aug 2020, at 05:19, Ludovic Henry wrote: >> >> Hello, >> >> Bug: https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbugs.openjdk.java.net*2Fbrowse*2FJDK-8251216&data=02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034&sdata=C7Bi8BTsmtR3HFgWgYTw7jww63BcHGutNXE8o9x2bdY*3D&reserved=0__;JSUlJSUlJSUlJSUlJSU!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E97IPBA3$ >> Webrev: https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=http:*2F*2Fcr.openjdk.java.net*2F*luhenry*2F8251216*2Fwebrev.00&data=02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034&sdata=0CZOMfpmtPZiy64za8NYYpVjCdawmjGacEOc3WfADDA*3D&reserved=0__;JSUlfiUlJSUlJSUlJSUl!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E84nlzLJ$ >> >> Testing: Linux-AArch64, fastdebug, test/hotspot/jtreg/compiler/intrinsics/sha/ test/hotspot/jtreg:tier1 test/jdk:tier1 >> >> This patch implements the MD5 intrinsic on AArch64 following its implementation on x86 [1]. The performance improvements are the following (on Linux-AArch64 on a Marvell TX2): >> >> -XX:-UseMD5Intrinsics >> Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units >> MessageDigests.digest md5 64 DEFAULT thrpt 10 1616.238 ? 28.082 ops/ms >> MessageDigests.digest md5 1024 DEFAULT thrpt 10 215.030 ? 0.691 ops/ms >> MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.228 ? 0.001 ops/ms >> >> -XX:+UseMD5Intrinsics >> Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units >> MessageDigests.digest md5 64 DEFAULT thrpt 10 2005.233 ? 40.513 ops/ms => 24% speedup >> MessageDigests.digest md5 1024 DEFAULT thrpt 10 275.979 ? 0.455 ops/ms => 28% speedup >> MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.279 ? 0.001 ops/ms => 22% speedup >> >> Thank you, >> Ludovic >> >> [1] https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbugs.openjdk.java.net*2Fbrowse*2FJDK-8250902&data=02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034&sdata=5KcoG5n10rnVMU9y8L076jpCoEd0NBzNqr*2F8M5ghO3c*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUl!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E6SPJBTN$ From doug.simon at oracle.com Tue Aug 11 20:33:14 2020 From: doug.simon at oracle.com (Doug Simon) Date: Tue, 11 Aug 2020 20:33:14 -0000 Subject: [aarch64-port-dev ] [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 In-Reply-To: References: <9074F4C9-589A-4519-BBAB-2F3161B814D7@oracle.com> Message-ID: <80E25174-9E0E-40EF-AF75-7295782CE360@oracle.com> Thanks for the digging and results Bernhard. We?ve discussed making the SchedulePhase do latency-aware scheduling within blocks but haven?t done anything yet. -Doug > On 11 Aug 2020, at 22:23, Bernhard Urban-Forster wrote: > > Hey Doug, > > since I was curious I did a bit of digging. Here are my findings: > > 1. Graal is able to detect that it only needs to do the array bounds check once for all the 16 array accesses, as I expected. > 2. Thus the generated code by Graal is almost as fast as the MD5 intrinsic. > 3. The gap, from what I can tell, is that the SchedulePhase decides to put all the 16 FloatingReadNodes at the top of the basic block, and thus increasing register pressure and therefore ending up needing to spill on x86_64. It would be nice if the read access would be scheduled next to its usage in this case. I couldn't figure out how to do that, it has been a while since I've touched that code :-) > > Here are some numbers plus the generated code of C2, the intrinsic and Graal: > https://urldefense.com/v3/__https://gist.github.com/lewurm/3b874558d369fd56b3737e28f1616740__;!!GqivPVa7Brio!L6XXaWxHy6hbPWSWzBRyX9XuZtH1g0pfzTBa7gBrTWM3Fd7snIsiUwYctRenoV51$ > > -Bernhard > > ________________________________________ > From: Doug Simon > Sent: Monday, August 10, 2020 15:38 > To: Bernhard Urban-Forster > Cc: Ludovic Henry; hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 > Subject: Re: [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 > > Hi Bernhard, > > > On 10 Aug 2020, at 15:01, Bernhard Urban-Forster > wrote: > > Hey Doug, > > replying on behalf for Ludovic, as he is on vacation :-) > > Currently we are not planning to implement the intrinsic for Graal. > > Schade ;-) > > Also we didn't check the generated code by Graal. I believe it will do a better job eliminated array bounds checks, but I'm curious to learn how "compiling the relevant Java code without array bounds checks" works. Is something like that done for other methods already? > > I don?t think we do that anywhere currently but I imagine it wouldn?t be hard to put the BytecodeParser into a mode whereby an array access generates a AccessIndexedNode that omits the bounds check (generated by org.graalvm.compiler.replacements.DefaultJavaLoweringProvider.getBoundsCheck). > > -Doug > > > This is the relevant Java method for the MD5 intrinsic: > https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/733218137289d6a0eb705103ed7be30f1e68d17a/src/java.base/share/classes/sun/security/provider/MD5.java*L172__;Iw!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E6ijVLDV$ > > > -Bernhard > > ________________________________________ > From: Doug Simon > > Sent: Monday, August 10, 2020 11:55 > To: Ludovic Henry > Cc: hotspot-compiler-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; openjdk-aarch64 > Subject: Re: [16] RFR[S]: 8251216: Implement MD5 intrinsics on AArch64 > > Hi Ludovic, > > Are you considering also implementing this intrinsic in Graal? > > Is the intrinsification purely about removing the array bounds checks? If so, it may be possible to have the Graal intrinsify the method by compiling the relevant Java code without array bounds checks. > > -Doug > > On 9 Aug 2020, at 05:19, Ludovic Henry > wrote: > > Hello, > > Bug: https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbugs.openjdk.java.net*2Fbrowse*2FJDK-8251216&data=02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034&sdata=C7Bi8BTsmtR3HFgWgYTw7jww63BcHGutNXE8o9x2bdY*3D&reserved=0__;JSUlJSUlJSUlJSUlJSU!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E97IPBA3$ > Webrev: https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=http:*2F*2Fcr.openjdk.java.net*2F*luhenry*2F8251216*2Fwebrev.00&data=02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034&sdata=0CZOMfpmtPZiy64za8NYYpVjCdawmjGacEOc3WfADDA*3D&reserved=0__;JSUlfiUlJSUlJSUlJSUl!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E84nlzLJ$ > > Testing: Linux-AArch64, fastdebug, test/hotspot/jtreg/compiler/intrinsics/sha/ test/hotspot/jtreg:tier1 test/jdk:tier1 > > This patch implements the MD5 intrinsic on AArch64 following its implementation on x86 [1]. The performance improvements are the following (on Linux-AArch64 on a Marvell TX2): > > -XX:-UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 1616.238 ? 28.082 ops/ms > MessageDigests.digest md5 1024 DEFAULT thrpt 10 215.030 ? 0.691 ops/ms > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.228 ? 0.001 ops/ms > > -XX:+UseMD5Intrinsics > Benchmark (digesterName) (length) (provider) Mode Cnt Score Error Units > MessageDigests.digest md5 64 DEFAULT thrpt 10 2005.233 ? 40.513 ops/ms => 24% speedup > MessageDigests.digest md5 1024 DEFAULT thrpt 10 275.979 ? 0.455 ops/ms => 28% speedup > MessageDigests.digest md5 1048576 DEFAULT thrpt 10 0.279 ? 0.001 ops/ms => 22% speedup > > Thank you, > Ludovic > > [1] https://urldefense.com/v3/__https://nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fbugs.openjdk.java.net*2Fbrowse*2FJDK-8250902&data=02*7C01*7Cbeurba*40microsoft.com*7C087d5d80f9484f13ddcc08d83d138f3a*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637326501506459034&sdata=5KcoG5n10rnVMU9y8L076jpCoEd0NBzNqr*2F8M5ghO3c*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUl!!GqivPVa7Brio!JeGQSBZgTB8CIzN7-UVXxlNivNOxJk8QFqhCQ1eJZaNvYHYqSf2gkNv2E6SPJBTN$ > From terje at kvernes.no Mon Aug 31 18:15:43 2020 From: terje at kvernes.no (Terje Kvernes) Date: Mon, 31 Aug 2020 20:15:43 +0200 Subject: [aarch64-port-dev ] A binary download for aarch64. Message-ID: <17F1A584-2B04-49AF-B846-F76F56D48B59@kvernes.no> Dear all, I am currently working on expanding EasyBuilds[1] support for ARM in the HPC space. One of the hurdles I have come across is that EasyBuild on both x86_64 and POWER install OpenJDK as a binary. On x86_64 this is done by fetching and installing https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz , linked from https://jdk.java.net/archive/ . Now, I have been unable to find a similar service for aarch64, and I was hoping I had simply missed something. Is there such a binary available for aarch64? [1] https://easybuild.readthedocs.io/en/latest/ -- Terje Kvernes