From ci_notify at linaro.org Fri May 1 06:19:27 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Fri, 1 May 2020 06:19:27 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <1876720074.19772.1588313967776.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2020/121/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/17 pass: 5,764; fail: 2 Build 1: aarch64/2019/oct/31 pass: 5,784; fail: 1 Build 2: aarch64/2019/nov/09 pass: 5,773; fail: 3 Build 3: aarch64/2019/nov/16 pass: 5,775; fail: 1 Build 4: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 5: aarch64/2019/dec/05 pass: 5,775; fail: 1 Build 6: aarch64/2019/dec/08 pass: 5,775; fail: 1 Build 7: aarch64/2019/dec/14 pass: 5,775; fail: 1 Build 8: aarch64/2019/dec/17 pass: 5,775; fail: 1 Build 9: aarch64/2019/dec/21 pass: 5,775; fail: 1 Build 10: aarch64/2020/jan/16 pass: 5,775; fail: 1 Build 11: aarch64/2020/jan/30 pass: 5,791; fail: 1 Build 12: aarch64/2020/feb/06 pass: 5,791; fail: 1 Build 13: aarch64/2020/feb/13 pass: 5,792; fail: 1 Build 14: aarch64/2020/apr/30 pass: 5,813; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/17 pass: 8,452; fail: 493; error: 16 Build 1: aarch64/2019/oct/31 pass: 8,468; fail: 490; error: 14 Build 2: aarch64/2019/nov/09 pass: 8,487; fail: 470; error: 16 Build 3: aarch64/2019/nov/16 pass: 8,475; fail: 484; error: 15 Build 4: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 5: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 Build 6: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 Build 7: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 Build 8: aarch64/2019/dec/17 pass: 8,485; fail: 505; error: 15 Build 9: aarch64/2019/dec/21 pass: 8,499; fail: 496; error: 10 Build 10: aarch64/2020/jan/16 pass: 8,513; fail: 474; error: 17 Build 11: aarch64/2020/jan/30 pass: 8,513; fail: 501; error: 13 Build 12: aarch64/2020/feb/06 pass: 8,496; fail: 517; error: 14 Build 13: aarch64/2020/feb/13 pass: 8,509; fail: 507; error: 14 Build 14: aarch64/2020/apr/30 pass: 8,534; fail: 519; error: 15 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/17 pass: 3,910 Build 1: aarch64/2019/oct/31 pass: 3,910 Build 2: aarch64/2019/nov/09 pass: 3,910 Build 3: aarch64/2019/nov/16 pass: 3,910 Build 4: aarch64/2019/nov/21 pass: 3,910 Build 5: aarch64/2019/dec/05 pass: 3,910 Build 6: aarch64/2019/dec/08 pass: 3,910 Build 7: aarch64/2019/dec/14 pass: 3,910 Build 8: aarch64/2019/dec/17 pass: 3,910 Build 9: aarch64/2019/dec/21 pass: 3,910 Build 10: aarch64/2020/jan/16 pass: 3,910 Build 11: aarch64/2020/jan/30 pass: 3,913 Build 12: aarch64/2020/feb/06 pass: 3,913 Build 13: aarch64/2020/feb/13 pass: 3,913 Build 14: aarch64/2020/apr/30 pass: 3,913 Previous results can be found here: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.75x Relative performance: Server critical-jOPS (nc): 8.71x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 213.86 Server 213.86 / Server 2014-04-01 (71.00): 3.01x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-10-05 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/277/results/ 2019-10-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/290/results/ 2019-11-01 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/304/results/ 2019-11-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/313/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ 2019-12-18 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/351/results/ 2019-12-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/355/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/037/results/ 2020-02-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/044/results/ 2020-05-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/121/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From erik.joelsson at oracle.com Fri May 1 13:04:59 2020 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 1 May 2020 06:04:59 -0700 Subject: [aarch64-port-dev ] FW: [Mach5] mach5-one-phh-JDK-8151779-20200427-2151-10554367: FAILED In-Reply-To: <9725176C-5E5A-499B-8093-A5865C4AC443@amazon.com> References: <858sifgbt3.fsf@arm.com> <57BB18E5-1F35-45AC-88BF-8D8C6A0767E3@amazon.com> <56d85fb9-6ce8-7c00-ff4f-bf3fe40718a4@redhat.com> <28A344AC-8FF4-49FB-96B9-6AC886C05930@amazon.com> <9725176C-5E5A-499B-8093-A5865C4AC443@amazon.com> Message-ID: <23d2cf6e-da04-4375-b777-0d29c8d813f3@oracle.com> Hello, My OracleJDK 14 displays: java version "14" 2020-03-17 Not sure where you found a version output without the word "version" in it. From what I understand, any distributor is free to change the "openjdk" prefix of this line, so relying on there only being 2 cases is not a good idea. If we assume the boot jdk must be an OpenJDK derivative, then a regular expression that tries to capture the line in more detail would be preferred. The aspects I would try to capture would be the word version and a bunch of numbers and dots (and possibly underscore if we want to keep it compatible with even older java versions for easier backports) inside double quotes. Something like this perhaps: grep "version \"[0-9\._]*\"" I tried that expression manually on Mac, Linux and Solaris so should be portable enough. /Erik On 2020-04-30 16:48, Liu, Xin wrote: > Hi, Andrew, > > How about this? I can use awk to capture java -version. There're 2 cases. > > I) openjdk > openjdk version "14.0.1" 2020-04-14 > 2) oraclejdk > java 14.0.1 2020-04-14 > > if somehow java displays some error/warning messages, awk can filter them out and capture the version line. > Eg. > $ ~/builds/jdk-14.0.1+7/bin/java -version > [0.009s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 > openjdk version "14.0.1" 2020-04-14 > OpenJDK Runtime Environment AdoptOpenJDK (build 14.0.1+7) > OpenJDK 64-Bit Server VM AdoptOpenJDK (build 14.0.1+7, mixed mode) > $ ~/builds/jdk-14.0.1+7/bin/java -version 2>&1 | awk '/^(openjdk version|java)/ {print $0}' > openjdk version "14.0.1" 2020-04-14 > > I think this awk stmt is portable, but it's always good to ask experts to review it, so I cc build-dev. > > Hers is the change. > > diff --git a/make/autoconf/boot-jdk.m4 b/make/autoconf/boot-jdk.m4 > --- a/make/autoconf/boot-jdk.m4 > +++ b/make/autoconf/boot-jdk.m4 > @@ -74,7 +74,7 @@ > BOOT_JDK_FOUND=no > else > # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? > - BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXE_SUFFIX" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $HEAD -n 1` > + BOOT_JDK_VERSION=`"$BOOT_JDK/bin/java$EXE_SUFFIX" $USER_BOOT_JDK_OPTIONS -version 2>&1 | $AWK '/^(openjdk version|java)/ {print [$]0}'` > if [ [[ "$BOOT_JDK_VERSION" =~ "Picked up" ]] ]; then > AC_MSG_NOTICE([You have _JAVA_OPTIONS or JAVA_TOOL_OPTIONS set. This can mess up the build. Please use --with-boot-jdk-jvmargs instead.]) > AC_MSG_NOTICE([Java reports: "$BOOT_JDK_VERSION".]) > @@ -529,7 +529,7 @@ > BUILD_JDK_FOUND=no > else > # Oh, this is looking good! We probably have found a proper JDK. Is it the correct version? > - BUILD_JDK_VERSION=`"$BUILD_JDK/bin/java" -version 2>&1 | $HEAD -n 1` > + BUILD_JDK_VERSION=`"$BUILD_JDK/bin/java" -version 2>&1 | $AWK '/^(openjdk version|java)/ {print [$]0}'` > > # Extra M4 quote needed to protect [] in grep expression. > [FOUND_CORRECT_VERSION=`echo $BUILD_JDK_VERSION | $EGREP "\"$VERSION_FEATURE([\.+-].*)?\""`] > > > > ?On 4/30/20, 2:52 PM, "aarch64-port-dev on behalf of Liu, Xin" wrote: > > Hi, Andrew, > > That's a hack. A general way should use grep or sed to capture the needed line instead of hardcoding first or second line. > Okay, Let me try to do that. > > Thanks, > --lx > > > On 4/30/20, 1:19 AM, "aph at redhat.com" wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > On 4/30/20 12:43 AM, Liu, Xin wrote: > > One trick here. It's very easy to cheat configure by hacking the boot-jdk.m4 to "$HEAD -n 2". Everything looks fine then. > > The fix should be submitted to build-dev. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > > > From thomas.stuefe at gmail.com Mon May 4 09:29:14 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 4 May 2020 11:29:14 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: Message-ID: Hi, I updated the webrev and rebased it to jdk head (now atop of 4198213fc371: 8230940: Obsolete MonitorBound). New webrev: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.01/webrev/ Delta to last: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.01/webrev/index.html @Ioi Lam : > // User may have specified an invalid base address. Should we ignore >it or assert? >guarantee(CompressedKlassPointers::is_valid_base((address)shared_base), > "SharedBaseAddress: " PTR_FORMAT " is not a valid base.", >p2i(shared_base)); > >This will cause the VM to crash. I think it's better (1) exit the VM >properly with an error code, or (2) override the user's input. I reworked this coding. I opted for ignoring this - if the user specifies a SharedBaseAddress which is invalid on the given platform the VM will print a warning and choose the default value. This mirrors (roughly) how we handle mapping errors when we cannot attach at SharedBaseAddress due to ASLR, which is also not treated as a fatal error. >For testing the CDS relocation code, I would suggest running: > >cd test/hotspot/jtreg >jtreg -javaoption:-XX:+UnlockDiagnosticVMOptions \ > -javaoption:-XX:ArchiveRelocationMode=1 \ > -javaoption:-XX:NativeMemoryTracking=detail > :hotspot_cds_relocation > >This will place the CCS at random locations picked by the OS. Tested on my linux x64 box, all went well. >metaspace.cpp: > >If your intention is to "shake things up a little", it's not a good idea >to include it in a complex change set. If things indeed go wrong, we >don't know who caused it (your CCS changes, or old bugs triggered by >this debug code), and we will end up backing out the entire changeset. I see your point and removed that code. I am not completely happy with it because this code is supposed to test whether this patch works as intended (removing all dependencies to Metaspace::reserve_alignment()). But since I have enough test runs with an increased alignment, I can disable this and will move this into a separate RFR. >I would suggest putting this in a different RFE, and even push it now. Cannot push it now, since it depends on this rework patch. In isolation it will cause crashes in CDS, which is one of the reason for this rework. @Nick Gasson : >On line 42 I'd prefer to use (4 << LogKlassAlignmentInBytes)*G as it >currently is in metaspace.cpp instead of the literal 32. Done. As for the discussions about optimizing the compressed class pointer encoding on aarch64, unless you have specific wishes about this patch I am ignoring it for now; I understand you want to do any optimizations for that in a follow up patch. Thank you, Thomas From aph at redhat.com Mon May 4 10:21:21 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 4 May 2020 11:21:21 +0100 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: Message-ID: <5cf3654a-e5d0-6405-6568-15639353b778@redhat.com> On 5/4/20 10:29 AM, Thomas St?fe wrote: > As for the discussions about optimizing the compressed class pointer > encoding on aarch64, unless you have specific wishes about this patch I am > ignoring it for now; I understand you want to do any optimizations for that > in a follow up patch. 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 gnu.andrew at redhat.com Tue May 5 05:39:08 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Tue, 5 May 2020 06:39:08 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b01 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b01/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/root/merge.changeset Changes in aarch64-shenandoah-jdk8u252-b09: - JDK-4949105: Access Bridge lacks html tags parsing - JDK-8003209: JFR events for network utilization - JDK-8028431: NullPointerException in DerValue.equals(DerValue) - JDK-8030680: 292 cleanup from default method code assessment - JDK-8035633: TEST_BUG: java/net/NetworkInterface/Equals.java and some tests failed on windows intermittently - JDK-8041626: Shutdown tracing event - JDK-8041915: Move 8 awt tests to OpenJDK regression tests tree - JDK-8141056: Erroneous assignment in HeapRegionSet.cpp - JDK-8149338: JVM Crash caused by Marlin renderer not handling NaN coordinates - JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded" - JDK-8165675: Trace event for thread park has incorrect unit for timeout - JDK-8176182: 4 security tests are not run - JDK-8178910: Problemlist sample tests - JDK-8183925: [AArch64] Decouple crash protection from watcher thread - JDK-8183925: Decouple crash protection from watcher thread - JDK-8191393: Random crashes during cfree+0x1c - JDK-8195817: JFR.stop should require name of recording - JDK-8195818: JFR.start should increase autogenerated name by one - JDK-8195819: Remove recording=x from jcmd JFR.check output - JDK-8199712: [AArch64] Flight Recorder - JDK-8199712: Flight Recorder - JDK-8202578: Revisit location for class unload events - JDK-8202835: jfr/event/os/TestSystemProcess.java fails on missing events - JDK-8203287: Zero fails to build after JDK-8199712 (Flight Recorder) - JDK-8203346: JFR: Inconsistent signature of jfr_add_string_constant - JDK-8203664: JFR start failure after AppCDS archive created with JFR StartFlightRecording - JDK-8203921: JFR thread sampling is missing fixes from JDK-8194552 - JDK-8203929: Limit amount of data for JFR.dump - JDK-8205516: JFR tool - JDK-8207392: [PPC64] Implement JFR profiling - JDK-8207829: FlightRecorderMXBeanImpl is leaking the first classloader which calls it - JDK-8209960: -Xlog:jfr* doesn't work with the JFR - JDK-8210024: JFR calls virtual is_Java_thread from ~Thread() - JDK-8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 - JDK-8211239: Build fails without JFR: empty JFR events signatures mismatch - JDK-8212232: Wrong metadata for the configuration of the cutoff for old object sample events - JDK-8213015: Inconsistent settings between JFR.configure and -XX:FlightRecorderOptions - JDK-8213421: Line number information for execution samples always 0 - JDK-8213617: JFR should record the PID of the recorded process - JDK-8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. - JDK-8213914: [TESTBUG] Several JFR VM events are not covered by tests - JDK-8213917: [TESTBUG] Shutdown JFR event is not covered by test - JDK-8213966: The ZGC JFR events should be marked as experimental - JDK-8214542: JFR: Old Object Sample event slow on a deep heap in debug builds - JDK-8214750: Unnecessary

tags in jfr classes - JDK-8214896: JFR Tool left files behind - JDK-8214906: [TESTBUG] jfr/event/sampling/TestNative.java fails with UnsatisfiedLinkError - JDK-8214925: JFR tool fails to execute - JDK-8215175: Inconsistencies in JFR event metadata - JDK-8215237: jdk.jfr.Recording javadoc does not compile - JDK-8215284: Reduce noise induced by periodic task getFileSize() - JDK-8215355: Object monitor deadlock with no threads holding the monitor (using jemalloc 5.1) - JDK-8215362: JFR GTest JfrTestNetworkUtilization fails - JDK-8215771: The jfr tool should pretty print reference chains - JDK-8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64 - JDK-8216064: -XX:StartFlightRecording:settings= doesn't work properly - JDK-8216486: Possibility of integer overflow in JfrThreadSampler::run() - JDK-8216528: test/jdk/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java failing with Xcomp - JDK-8216559: [JFR] Native libraries not correctly parsed from /proc/self/maps - JDK-8216578: Remove unused/obsolete method in JFR code - JDK-8216995: Clean up JFR command line processing - JDK-8217744: [TESTBUG] JFR TestShutdownEvent fails on some systems due to process surviving SIGINT - JDK-8217748: [TESTBUG] Exclude TestSig test case from JFR TestShutdownEvent - JDK-8218935: Make jfr strncpy uses GCC 8.x friendly - JDK-8223147: JFR Backport - JDK-8223689: Add JFR Thread Sampling Support - JDK-8223690: Add JFR BiasedLock Event Support - JDK-8223691: Add JFR G1 Region Type Change Event Support - JDK-8223692: Add JFR G1 Heap Summary Event Support - JDK-8224172: assert(jfr_is_event_enabled(id)) failed: invariant - JDK-8224475: JTextPane does not show images in HTML rendering - JDK-8226253: JAWS reports wrong number of radio buttons when buttons are hidden. - JDK-8226779: [TESTBUG] Test JFR API from Java agent - JDK-8226892: ActionListeners on JRadioButtons don't get notified when selection is changed with arrow keys - JDK-8227011: Starting a JFR recording in response to JVMTI VMInit and / or Java agent premain corrupts memory - JDK-8227605: Kitchensink fails "assert((((klass)->trace_id() & (JfrTraceIdEpoch::leakp_in_use_this_epoch_bit())) != 0)) failed: invariant" - JDK-8229366: JFR backport allows unchecked writing to memory - JDK-8229401: Fix JFR code cache test failures - JDK-8229708: JFR backport code does not initialize - JDK-8229873: 8229401 broke jdk8u-jfr-incubator - JDK-8230448: [test] JFRSecurityTestSuite.java is failing on Windows - JDK-8230707: JFR related tests are failing - JDK-8230782: Robot.createScreenCapture() fails if ?awt.robot.gtk? is set to false - JDK-8230856: Java_java_net_NetworkInterface_getByName0 on unix misses ReleaseStringUTFChars in early return - JDK-8230947: TestLookForUntestedEvents.java is failing after JDK-8230707 - JDK-8231995: two jtreg tests failed after 8229366 is fixed - JDK-8233623: Add classpath exception to copyright in EventHandlerProxyCreator.java file - JDK-8236002: CSR for JFR backport suggests not leaving out the package-info - JDK-8236008: Some backup files were accidentally left in the hotspot tree - JDK-8236074: Missed package-info - JDK-8236174: Should update javadoc since tags - JDK-8238076: Fix OpenJDK 7 Bootstrap Broken by JFR Backport - JDK-8238452: Keytool generates wrong expiration date if validity is set to 2050/01/01 - JDK-8238555: Allow Initialization of SunPKCS11 with NSS when there are external FIPS modules in the NSSDB - JDK-8238589: Necessary code cleanup in JFR for JDK8u - JDK-8238590: Enable JFR by default during compilation in 8u - JDK-8239055: Wrong implementation of VMState.hasListener - JDK-8239476: JDK-8238589 broke windows build by moving OrderedPair - JDK-8239479: minimal1 and zero builds are failing - JDK-8239867: correct over use of INCLUDE_JFR macro - JDK-8240375: Disable JFR by default for July 2020 release - JDK-8241444: Metaspace::_class_vsm not initialized if compressed class pointers are disabled - JDK-8241902: AIX Build broken after integration of JDK-8223147 (JFR Backport) - JDK-8242788: Non-PCH build is broken after JDK-8191393 Main issues of note: This is the first build promotion to contain JFR. Additional changes had to be backported to make this work on AArch64. It was necessary to get access to an AArch64 machine and build manually there first of all, after initial attempts at tagging and building failed. The following three additional changes were added in the end to get a successful build: - JDK-8183925: [AArch64] Decouple crash protection from watcher thread - JDK-8199712: [AArch64] Flight Recorder - JDK-8215961: jdk/jfr/event/os/TestCPUInformation.java fails on AArch64 The 8183925 renaming of os::WatcherThreadCrashProtection -> os::ThreadCrashProtection needed to be applied to src/os_cpu/linux_aarch64/vm/os_linux_aarch64.cpp. This was a clean backport. vm_version_ext had to be introduced for AArch64 and referenced in src/os/linux/vm/os_perf_linux.cpp. One minor change was necessary, because 8u does not have _features_string(). Instead, we use cpu_features(), which returns the same value. This port-specific function was removed in 11u by 8143072 ("[JVMCI] Port JVMCI to AArch64"), with the same value instead returned by the shared _features_string(). 8215961 is a simple followup fix for this, which prefixes the features output with "AArch64" so the JFR test passes. Most JFR tests passed with the AArch64 build. Those that didn't seemed unrelated to AArch64 specifically. $ cat tests.log |grep -v '^Passed' FAILED: jdk/jfr/api/consumer/TestRecordedFullStackTrace.java FAILED: jdk/jfr/event/io/TestInstrumentation.java FAILED: jdk/jfr/event/oldobject/TestClassLoaderLeak.java Error: jdk/jfr/event/oldobject/TestObjectDescription.java Error: jdk/jfr/event/oldobject/TestSanityDefault.java FAILED: jdk/jfr/event/profiling/TestFullStackTrace.java Error: jdk/jfr/event/sampling/TestNative.java Test results: passed: 422; failed: 4; error: 3 This gets AArch64 to build with JFR, but more support may need to be added. diffstat for root b/.hgignore | 2 + b/.hgtags | 3 + b/THIRD_PARTY_README | 30 ++++++++---------- b/common/autoconf/generated-configure.sh | 51 +++++++++++++++++++++++++++++-- b/common/autoconf/jdk-options.m4 | 26 +++++++++++++++ 5 files changed, 92 insertions(+), 20 deletions(-) diffstat for corba b/.hgtags | 4 ++++ b/THIRD_PARTY_README | 30 ++++++++++++++---------------- 2 files changed, 18 insertions(+), 16 deletions(-) diffstat for jaxp b/.hgtags | 3 + b/THIRD_PARTY_README | 30 ++++------ b/src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java | 26 ++++++-- 3 files changed, 36 insertions(+), 23 deletions(-) diffstat for jaxws b/.hgtags | 3 +++ b/THIRD_PARTY_README | 30 ++++++++++++++---------------- 2 files changed, 17 insertions(+), 16 deletions(-) diffstat for langtools b/.hgtags | 3 +++ b/THIRD_PARTY_README | 30 ++++++++++++++---------------- 2 files changed, 17 insertions(+), 16 deletions(-) diffstat for nashorn b/.hgtags | 3 +++ b/THIRD_PARTY_README | 30 ++++++++++++++---------------- 2 files changed, 17 insertions(+), 16 deletions(-) diffstat for jdk a/src/solaris/native/sun/awt/robot_common.c | 101 - a/src/solaris/native/sun/awt/robot_common.h | 39 b/.hgtags | 3 b/THIRD_PARTY_README | 30 b/make/CompileLaunchers.gmk | 4 b/make/CopyFiles.gmk | 11 b/make/CopyIntoClasses.gmk | 6 b/make/CreateJars.gmk | 26 b/make/Images.gmk | 3 b/make/mapfiles/libjava/mapfile-vers | 1 b/src/share/classes/com/sun/tools/jdi/VMState.java | 11 b/src/share/classes/java/lang/Runtime.java | 1 b/src/share/classes/java/lang/Shutdown.java | 6 b/src/share/classes/javax/swing/JList.java | 8 b/src/share/classes/javax/swing/plaf/basic/BasicHTML.java | 31 b/src/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java | 7 b/src/share/classes/javax/swing/text/html/ImageView.java | 32 b/src/share/classes/jdk/jfr/AnnotationElement.java | 420 ++++ b/src/share/classes/jdk/jfr/BooleanFlag.java | 45 b/src/share/classes/jdk/jfr/Category.java | 130 + b/src/share/classes/jdk/jfr/Configuration.java | 197 ++ b/src/share/classes/jdk/jfr/ContentType.java | 45 b/src/share/classes/jdk/jfr/DataAmount.java | 60 b/src/share/classes/jdk/jfr/Description.java | 52 b/src/share/classes/jdk/jfr/Enabled.java | 58 b/src/share/classes/jdk/jfr/Event.java | 171 + b/src/share/classes/jdk/jfr/EventFactory.java | 251 ++ b/src/share/classes/jdk/jfr/EventSettings.java | 141 + b/src/share/classes/jdk/jfr/EventType.java | 237 ++ b/src/share/classes/jdk/jfr/Experimental.java | 59 b/src/share/classes/jdk/jfr/FlightRecorder.java | 353 +++ b/src/share/classes/jdk/jfr/FlightRecorderListener.java | 80 b/src/share/classes/jdk/jfr/FlightRecorderPermission.java | 211 ++ b/src/share/classes/jdk/jfr/Frequency.java | 45 b/src/share/classes/jdk/jfr/Label.java | 55 b/src/share/classes/jdk/jfr/MemoryAddress.java | 45 b/src/share/classes/jdk/jfr/MetadataDefinition.java | 81 b/src/share/classes/jdk/jfr/Name.java | 53 b/src/share/classes/jdk/jfr/Percentage.java | 50 b/src/share/classes/jdk/jfr/Period.java | 72 b/src/share/classes/jdk/jfr/Recording.java | 676 +++++++ b/src/share/classes/jdk/jfr/RecordingState.java | 71 b/src/share/classes/jdk/jfr/Registered.java | 55 b/src/share/classes/jdk/jfr/Relational.java | 43 b/src/share/classes/jdk/jfr/SettingControl.java | 220 ++ b/src/share/classes/jdk/jfr/SettingDefinition.java | 70 b/src/share/classes/jdk/jfr/SettingDescriptor.java | 215 ++ b/src/share/classes/jdk/jfr/StackTrace.java | 57 b/src/share/classes/jdk/jfr/Threshold.java | 69 b/src/share/classes/jdk/jfr/Timespan.java | 75 b/src/share/classes/jdk/jfr/Timestamp.java | 63 b/src/share/classes/jdk/jfr/TransitionFrom.java | 43 b/src/share/classes/jdk/jfr/TransitionTo.java | 43 b/src/share/classes/jdk/jfr/Unsigned.java | 45 b/src/share/classes/jdk/jfr/ValueDescriptor.java | 322 +++ b/src/share/classes/jdk/jfr/conf/default.jfc | 816 ++++++++ b/src/share/classes/jdk/jfr/conf/profile.jfc | 817 ++++++++ b/src/share/classes/jdk/jfr/consumer/ChunkParser.java | 174 + b/src/share/classes/jdk/jfr/consumer/ConstantMap.java | 139 + b/src/share/classes/jdk/jfr/consumer/EventParser.java | 72 b/src/share/classes/jdk/jfr/consumer/LongMap.java | 61 b/src/share/classes/jdk/jfr/consumer/ObjectFactory.java | 85 b/src/share/classes/jdk/jfr/consumer/Parser.java | 45 b/src/share/classes/jdk/jfr/consumer/ParserFactory.java | 303 +++ b/src/share/classes/jdk/jfr/consumer/RecordedClass.java | 103 + b/src/share/classes/jdk/jfr/consumer/RecordedClassLoader.java | 90 b/src/share/classes/jdk/jfr/consumer/RecordedEvent.java | 124 + b/src/share/classes/jdk/jfr/consumer/RecordedFrame.java | 113 + b/src/share/classes/jdk/jfr/consumer/RecordedMethod.java | 120 + b/src/share/classes/jdk/jfr/consumer/RecordedObject.java | 903 +++++++++ b/src/share/classes/jdk/jfr/consumer/RecordedStackTrace.java | 80 b/src/share/classes/jdk/jfr/consumer/RecordedThread.java | 118 + b/src/share/classes/jdk/jfr/consumer/RecordedThreadGroup.java | 70 b/src/share/classes/jdk/jfr/consumer/RecordingFile.java | 269 ++ b/src/share/classes/jdk/jfr/consumer/TimeConverter.java | 72 b/src/share/classes/jdk/jfr/consumer/package-info.java | 82 b/src/share/classes/jdk/jfr/events/AbstractJDKEvent.java | 37 b/src/share/classes/jdk/jfr/events/ActiveRecordingEvent.java | 67 b/src/share/classes/jdk/jfr/events/ActiveSettingEvent.java | 48 b/src/share/classes/jdk/jfr/events/ErrorThrownEvent.java | 44 b/src/share/classes/jdk/jfr/events/ExceptionStatisticsEvent.java | 44 b/src/share/classes/jdk/jfr/events/ExceptionThrownEvent.java | 45 b/src/share/classes/jdk/jfr/events/FileForceEvent.java | 59 b/src/share/classes/jdk/jfr/events/FileReadEvent.java | 66 b/src/share/classes/jdk/jfr/events/FileWriteEvent.java | 61 b/src/share/classes/jdk/jfr/events/SocketReadEvent.java | 79 b/src/share/classes/jdk/jfr/events/SocketWriteEvent.java | 68 b/src/share/classes/jdk/jfr/internal/ASMToolkit.java | 162 + b/src/share/classes/jdk/jfr/internal/AnnotationConstruct.java | 136 + b/src/share/classes/jdk/jfr/internal/Bits.java | 227 ++ b/src/share/classes/jdk/jfr/internal/ChunkInputStream.java | 116 + b/src/share/classes/jdk/jfr/internal/ChunksChannel.java | 145 + b/src/share/classes/jdk/jfr/internal/Control.java | 209 ++ b/src/share/classes/jdk/jfr/internal/Cutoff.java | 75 b/src/share/classes/jdk/jfr/internal/EventClassBuilder.java | 142 + b/src/share/classes/jdk/jfr/internal/EventControl.java | 291 +++ b/src/share/classes/jdk/jfr/internal/EventHandlerCreator.java | 338 +++ b/src/share/classes/jdk/jfr/internal/EventHandlerProxyCreator.java | 126 + b/src/share/classes/jdk/jfr/internal/EventInstrumentation.java | 528 +++++ b/src/share/classes/jdk/jfr/internal/EventWriter.java | 355 +++ b/src/share/classes/jdk/jfr/internal/EventWriterMethod.java | 81 b/src/share/classes/jdk/jfr/internal/JVM.java | 527 +++++ b/src/share/classes/jdk/jfr/internal/JVMSupport.java | 86 b/src/share/classes/jdk/jfr/internal/JVMUpcalls.java | 152 + b/src/share/classes/jdk/jfr/internal/LogLevel.java | 41 b/src/share/classes/jdk/jfr/internal/LogTag.java | 90 b/src/share/classes/jdk/jfr/internal/Logger.java | 69 b/src/share/classes/jdk/jfr/internal/MetadataDescriptor.java | 273 ++ b/src/share/classes/jdk/jfr/internal/MetadataHandler.java | 421 ++++ b/src/share/classes/jdk/jfr/internal/MetadataReader.java | 271 ++ b/src/share/classes/jdk/jfr/internal/MetadataRepository.java | 277 ++ b/src/share/classes/jdk/jfr/internal/MetadataWriter.java | 225 ++ b/src/share/classes/jdk/jfr/internal/OldObjectSample.java | 98 + b/src/share/classes/jdk/jfr/internal/Options.java | 162 + b/src/share/classes/jdk/jfr/internal/PlatformEventType.java | 281 +++ b/src/share/classes/jdk/jfr/internal/PlatformRecorder.java | 554 +++++ b/src/share/classes/jdk/jfr/internal/PlatformRecording.java | 778 ++++++++ b/src/share/classes/jdk/jfr/internal/PrivateAccess.java | 97 + b/src/share/classes/jdk/jfr/internal/Repository.java | 165 + b/src/share/classes/jdk/jfr/internal/RepositoryChunk.java | 210 ++ b/src/share/classes/jdk/jfr/internal/RequestEngine.java | 256 ++ b/src/share/classes/jdk/jfr/internal/SecuritySupport.java | 391 ++++ b/src/share/classes/jdk/jfr/internal/SettingsManager.java | 292 +++ b/src/share/classes/jdk/jfr/internal/ShutdownHook.java | 105 + b/src/share/classes/jdk/jfr/internal/StringPool.java | 135 + b/src/share/classes/jdk/jfr/internal/Type.java | 326 +++ b/src/share/classes/jdk/jfr/internal/TypeLibrary.java | 492 +++++ b/src/share/classes/jdk/jfr/internal/Utils.java | 554 +++++ b/src/share/classes/jdk/jfr/internal/WriteableUserPath.java | 129 + b/src/share/classes/jdk/jfr/internal/consumer/ChunkHeader.java | 184 + b/src/share/classes/jdk/jfr/internal/consumer/RecordingInput.java | 339 +++ b/src/share/classes/jdk/jfr/internal/consumer/RecordingInternals.java | 47 b/src/share/classes/jdk/jfr/internal/dcmd/AbstractDCmd.java | 201 ++ b/src/share/classes/jdk/jfr/internal/dcmd/DCmdCheck.java | 164 + b/src/share/classes/jdk/jfr/internal/dcmd/DCmdConfigure.java | 217 ++ b/src/share/classes/jdk/jfr/internal/dcmd/DCmdDump.java | 205 ++ b/src/share/classes/jdk/jfr/internal/dcmd/DCmdException.java | 69 b/src/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java | 259 ++ b/src/share/classes/jdk/jfr/internal/dcmd/DCmdStop.java | 87 b/src/share/classes/jdk/jfr/internal/handlers/EventHandler.java | 123 + b/src/share/classes/jdk/jfr/internal/instrument/ConstructorTracerWriter.java | 86 b/src/share/classes/jdk/jfr/internal/instrument/ConstructorWriter.java | 89 b/src/share/classes/jdk/jfr/internal/instrument/FileChannelImplInstrumentor.java | 197 ++ b/src/share/classes/jdk/jfr/internal/instrument/FileInputStreamInstrumentor.java | 115 + b/src/share/classes/jdk/jfr/internal/instrument/FileOutputStreamInstrumentor.java | 99 + b/src/share/classes/jdk/jfr/internal/instrument/JDKEvents.java | 144 + b/src/share/classes/jdk/jfr/internal/instrument/JIClassInstrumentation.java | 140 + b/src/share/classes/jdk/jfr/internal/instrument/JIInliner.java | 113 + b/src/share/classes/jdk/jfr/internal/instrument/JIInstrumentationMethod.java | 36 b/src/share/classes/jdk/jfr/internal/instrument/JIInstrumentationTarget.java | 37 b/src/share/classes/jdk/jfr/internal/instrument/JIMethodCallInliner.java | 149 + b/src/share/classes/jdk/jfr/internal/instrument/JIMethodInliningAdapter.java | 76 b/src/share/classes/jdk/jfr/internal/instrument/JIMethodMergeAdapter.java | 120 + b/src/share/classes/jdk/jfr/internal/instrument/JITypeMapping.java | 35 b/src/share/classes/jdk/jfr/internal/instrument/RandomAccessFileInstrumentor.java | 173 + b/src/share/classes/jdk/jfr/internal/instrument/SocketChannelImplInstrumentor.java | 174 + b/src/share/classes/jdk/jfr/internal/instrument/SocketInputStreamInstrumentor.java | 88 b/src/share/classes/jdk/jfr/internal/instrument/SocketOutputStreamInstrumentor.java | 84 b/src/share/classes/jdk/jfr/internal/instrument/ThrowableTracer.java | 64 b/src/share/classes/jdk/jfr/internal/jfc/JFC.java | 247 ++ b/src/share/classes/jdk/jfr/internal/jfc/JFCParser.java | 85 b/src/share/classes/jdk/jfr/internal/jfc/JFCParserHandler.java | 106 + b/src/share/classes/jdk/jfr/internal/jfc/jfc.xsd | 177 + b/src/share/classes/jdk/jfr/internal/jfc/package-info.java | 31 b/src/share/classes/jdk/jfr/internal/management/ManagementSupport.java | 89 b/src/share/classes/jdk/jfr/internal/settings/BooleanValue.java | 74 b/src/share/classes/jdk/jfr/internal/settings/CutoffSetting.java | 97 + b/src/share/classes/jdk/jfr/internal/settings/EnabledSetting.java | 75 b/src/share/classes/jdk/jfr/internal/settings/PeriodSetting.java | 136 + b/src/share/classes/jdk/jfr/internal/settings/StackTraceSetting.java | 75 b/src/share/classes/jdk/jfr/internal/settings/ThresholdSetting.java | 90 b/src/share/classes/jdk/jfr/internal/test/WhiteBox.java | 48 b/src/share/classes/jdk/jfr/internal/tool/Assemble.java | 127 + b/src/share/classes/jdk/jfr/internal/tool/Command.java | 306 +++ b/src/share/classes/jdk/jfr/internal/tool/Disassemble.java | 250 ++ b/src/share/classes/jdk/jfr/internal/tool/EventPrintWriter.java | 139 + b/src/share/classes/jdk/jfr/internal/tool/Help.java | 76 b/src/share/classes/jdk/jfr/internal/tool/JSONWriter.java | 261 ++ b/src/share/classes/jdk/jfr/internal/tool/Main.java | 110 + b/src/share/classes/jdk/jfr/internal/tool/Metadata.java | 139 + b/src/share/classes/jdk/jfr/internal/tool/PrettyWriter.java | 634 ++++++ b/src/share/classes/jdk/jfr/internal/tool/Print.java | 262 ++ b/src/share/classes/jdk/jfr/internal/tool/StructuredWriter.java | 121 + b/src/share/classes/jdk/jfr/internal/tool/Summary.java | 162 + b/src/share/classes/jdk/jfr/internal/tool/UserDataException.java | 49 b/src/share/classes/jdk/jfr/internal/tool/UserSyntaxException.java | 45 b/src/share/classes/jdk/jfr/internal/tool/Version.java | 51 b/src/share/classes/jdk/jfr/internal/tool/XMLWriter.java | 200 ++ b/src/share/classes/jdk/jfr/package-info.java | 196 ++ b/src/share/classes/jdk/management/jfr/ConfigurationInfo.java | 241 ++ b/src/share/classes/jdk/management/jfr/EventTypeInfo.java | 262 ++ b/src/share/classes/jdk/management/jfr/FlightRecorderMXBean.java | 639 ++++++ b/src/share/classes/jdk/management/jfr/FlightRecorderMXBeanImpl.java | 440 ++++ b/src/share/classes/jdk/management/jfr/MBeanUtils.java | 130 + b/src/share/classes/jdk/management/jfr/RecordingInfo.java | 398 ++++ b/src/share/classes/jdk/management/jfr/SettingDescriptorInfo.java | 232 ++ b/src/share/classes/jdk/management/jfr/Stream.java | 81 b/src/share/classes/jdk/management/jfr/StreamCleanupTask.java | 50 b/src/share/classes/jdk/management/jfr/StreamManager.java | 82 b/src/share/classes/jdk/management/jfr/Stringifier.java | 60 b/src/share/classes/jdk/management/jfr/internal/FlightRecorderMXBeanProvider.java | 113 + b/src/share/classes/sun/java2d/marlin/Renderer.java | 55 b/src/share/classes/sun/management/ExtendedPlatformComponent.java | 27 b/src/share/classes/sun/security/pkcs11/Secmod.java | 4 b/src/share/classes/sun/security/util/DerValue.java | 24 b/src/share/classes/sun/security/x509/CertificateValidity.java | 7 b/src/share/classes/sun/security/x509/X509CRLEntryImpl.java | 5 b/src/share/classes/sun/security/x509/X509CRLImpl.java | 5 b/src/share/javavm/export/jvm.h | 3 b/src/share/lib/security/java.security-aix | 10 b/src/share/lib/security/java.security-linux | 10 b/src/share/lib/security/java.security-macosx | 10 b/src/share/lib/security/java.security-solaris | 11 b/src/share/lib/security/java.security-windows | 10 b/src/share/native/java/lang/Shutdown.c | 7 b/src/solaris/native/java/net/NetworkInterface.c | 1 b/src/solaris/native/sun/awt/awt_Robot.c | 4 b/src/solaris/native/sun/awt/list.c | 107 - b/src/solaris/native/sun/awt/list.h | 61 b/src/solaris/native/sun/awt/multiVis.c | 768 ++++---- b/src/solaris/native/sun/awt/multiVis.h | 48 b/src/solaris/native/sun/awt/wsutils.h | 133 - b/src/windows/classes/com/sun/java/accessibility/AccessBridge.java | 88 b/test/ProblemList.txt | 5 b/test/TEST.ROOT | 2 b/test/TEST.groups | 4 b/test/java/awt/EventQueue/InvocationEventTest/InvocationEventTest.java | 203 ++ b/test/java/awt/Frame/DecoratedExceptions/DecoratedExceptions.java | 81 b/test/java/awt/Window/ShapedAndTranslucentWindows/Common.java | 316 +++ b/test/java/awt/Window/ShapedAndTranslucentWindows/FocusAWTTest.java | 225 ++ b/test/java/awt/Window/ShapedAndTranslucentWindows/Shaped.java | 69 b/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedByAPI.java | 71 b/test/java/awt/Window/ShapedAndTranslucentWindows/ShapedTranslucent.java | 70 b/test/java/awt/Window/ShapedAndTranslucentWindows/StaticallyShaped.java | 68 b/test/java/awt/Window/ShapedAndTranslucentWindows/Translucent.java | 71 b/test/java/lang/SecurityManager/CheckPackageAccess.java | 3 b/test/java/net/MulticastSocket/TestInterfaces.java | 5 b/test/java/net/NetworkInterface/Equals.java | 5 b/test/java/net/NetworkInterface/IndexTest.java | 5 b/test/java/nio/channels/AsyncCloseAndInterrupt.java | 26 b/test/java/rmi/transport/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java | 7 b/test/java/security/cert/X509Certificate/X509BadCertificate.java | 63 b/test/java/security/cert/X509Certificate/bad-cert-1.pem | 21 b/test/javax/accessibility/AccessibleName/GetAccessibleNameTest.java | 137 + b/test/javax/swing/JRadioButton/8033699/bug8033699.java | 46 b/test/javax/swing/JTextPane/TestJTextPaneHTMLRendering.java | 173 + b/test/javax/xml/jaxp/parsers/8213734/SAXParserTest.java | 79 b/test/jdk/jfr/TEST.properties | 2 b/test/jdk/jfr/api/consumer/TEST.properties | 2 b/test/jdk/jfr/api/consumer/TestFieldAccess.java | 151 + b/test/jdk/jfr/api/consumer/TestGetStackTrace.java | 103 + b/test/jdk/jfr/api/consumer/TestHiddenMethod.java | 112 + b/test/jdk/jfr/api/consumer/TestMethodGetModifiers.java | 81 b/test/jdk/jfr/api/consumer/TestReadTwice.java | 85 b/test/jdk/jfr/api/consumer/TestRecordedClassLoader.java | 120 + b/test/jdk/jfr/api/consumer/TestRecordedEvent.java | 110 + b/test/jdk/jfr/api/consumer/TestRecordedEventGetThread.java | 72 b/test/jdk/jfr/api/consumer/TestRecordedEventGetThreadOther.java | 109 + b/test/jdk/jfr/api/consumer/TestRecordedFrame.java | 122 + b/test/jdk/jfr/api/consumer/TestRecordedFullStackTrace.java | 180 + b/test/jdk/jfr/api/consumer/TestRecordedInstantEventTimestamp.java | 60 b/test/jdk/jfr/api/consumer/TestRecordedMethodDescriptor.java | 97 + b/test/jdk/jfr/api/consumer/TestRecordedObject.java | 408 ++++ b/test/jdk/jfr/api/consumer/TestRecordedThreadGroupParent.java | 89 b/test/jdk/jfr/api/consumer/TestRecordingFile.java | 408 ++++ b/test/jdk/jfr/api/consumer/TestRecordingFileReadEventEof.java | 62 b/test/jdk/jfr/api/consumer/TestRecordingInternals.java | 81 b/test/jdk/jfr/api/consumer/TestSingleRecordedEvent.java | 69 b/test/jdk/jfr/api/consumer/TestToString.java | 95 + b/test/jdk/jfr/api/consumer/TestValueDescriptorRecorded.java | 79 b/test/jdk/jfr/api/event/TEST.properties | 2 b/test/jdk/jfr/api/event/TestAbstractEvent.java | 117 + b/test/jdk/jfr/api/event/TestBeginEnd.java | 114 + b/test/jdk/jfr/api/event/TestClinitRegistration.java | 206 ++ b/test/jdk/jfr/api/event/TestClonedEvent.java | 96 + b/test/jdk/jfr/api/event/TestEnableDisable.java | 102 + b/test/jdk/jfr/api/event/TestEventFactory.java | 81 b/test/jdk/jfr/api/event/TestEventFactoryRegisterTwice.java | 75 b/test/jdk/jfr/api/event/TestEventFactoryRegistration.java | 107 + b/test/jdk/jfr/api/event/TestExtends.java | 188 ++ b/test/jdk/jfr/api/event/TestGetDuration.java | 131 + b/test/jdk/jfr/api/event/TestIsEnabled.java | 88 b/test/jdk/jfr/api/event/TestIsEnabledMultiple.java | 128 + b/test/jdk/jfr/api/event/TestOwnCommit.java | 124 + b/test/jdk/jfr/api/event/TestShouldCommit.java | 195 ++ b/test/jdk/jfr/api/event/TestStaticEnable.java | 86 b/test/jdk/jfr/api/event/dynamic/TestDynamicAnnotations.java | 219 ++ b/test/jdk/jfr/api/event/dynamic/TestEventFactory.java | 289 +++ b/test/jdk/jfr/api/flightrecorder/MyListener.java | 48 b/test/jdk/jfr/api/flightrecorder/TestAddListenerTwice.java | 58 b/test/jdk/jfr/api/flightrecorder/TestAddPeriodicEvent.java | 107 + b/test/jdk/jfr/api/flightrecorder/TestFlightRecorderListenerRecorderInitialized.java | 99 + b/test/jdk/jfr/api/flightrecorder/TestGetEventTypes.java | 95 + b/test/jdk/jfr/api/flightrecorder/TestGetPlatformRecorder.java | 46 b/test/jdk/jfr/api/flightrecorder/TestGetRecordings.java | 85 b/test/jdk/jfr/api/flightrecorder/TestGetSettings.java | 132 + b/test/jdk/jfr/api/flightrecorder/TestIsAvailable.java | 47 b/test/jdk/jfr/api/flightrecorder/TestIsInitialized.java | 51 b/test/jdk/jfr/api/flightrecorder/TestListener.java | 66 b/test/jdk/jfr/api/flightrecorder/TestListenerNull.java | 54 b/test/jdk/jfr/api/flightrecorder/TestPeriodicEventsSameHook.java | 62 b/test/jdk/jfr/api/flightrecorder/TestRecorderInitializationCallback.java | 64 b/test/jdk/jfr/api/flightrecorder/TestRegisterUnregisterEvent.java | 82 b/test/jdk/jfr/api/flightrecorder/TestSettingsControl.java | 94 + b/test/jdk/jfr/api/flightrecorder/TestSnapshot.java | 187 ++ b/test/jdk/jfr/api/metadata/annotations/TestCategory.java | 53 b/test/jdk/jfr/api/metadata/annotations/TestContentType.java | 77 b/test/jdk/jfr/api/metadata/annotations/TestDescription.java | 98 + b/test/jdk/jfr/api/metadata/annotations/TestDynamicAnnotation.java | 56 b/test/jdk/jfr/api/metadata/annotations/TestEnabled.java | 72 b/test/jdk/jfr/api/metadata/annotations/TestExperimental.java | 80 b/test/jdk/jfr/api/metadata/annotations/TestFieldAnnotations.java | 110 + b/test/jdk/jfr/api/metadata/annotations/TestFormatMissingValue.java | 124 + b/test/jdk/jfr/api/metadata/annotations/TestHasValue.java | 65 b/test/jdk/jfr/api/metadata/annotations/TestInheritedAnnotations.java | 208 ++ b/test/jdk/jfr/api/metadata/annotations/TestLabel.java | 96 + b/test/jdk/jfr/api/metadata/annotations/TestMetadata.java | 85 b/test/jdk/jfr/api/metadata/annotations/TestName.java | 110 + b/test/jdk/jfr/api/metadata/annotations/TestPeriod.java | 52 b/test/jdk/jfr/api/metadata/annotations/TestRegistered.java | 68 b/test/jdk/jfr/api/metadata/annotations/TestRegisteredFalseAndRunning.java | 53 b/test/jdk/jfr/api/metadata/annotations/TestRelational.java | 72 b/test/jdk/jfr/api/metadata/annotations/TestSimpleMetadataEvent.java | 60 b/test/jdk/jfr/api/metadata/annotations/TestStackTrace.java | 61 b/test/jdk/jfr/api/metadata/annotations/TestThreshold.java | 52 b/test/jdk/jfr/api/metadata/annotations/TestTypesIdentical.java | 95 + b/test/jdk/jfr/api/metadata/eventtype/EventWithCustomSettings.java | 52 b/test/jdk/jfr/api/metadata/eventtype/TestGetAnnotation.java | 82 b/test/jdk/jfr/api/metadata/eventtype/TestGetAnnotationElements.java | 153 + b/test/jdk/jfr/api/metadata/eventtype/TestGetAnnotations.java | 76 b/test/jdk/jfr/api/metadata/eventtype/TestGetCategory.java | 70 b/test/jdk/jfr/api/metadata/eventtype/TestGetDefaultValues.java | 99 + b/test/jdk/jfr/api/metadata/eventtype/TestGetDescription.java | 80 b/test/jdk/jfr/api/metadata/eventtype/TestGetEventType.java | 62 b/test/jdk/jfr/api/metadata/eventtype/TestGetField.java | 77 b/test/jdk/jfr/api/metadata/eventtype/TestGetFields.java | 86 b/test/jdk/jfr/api/metadata/eventtype/TestGetSettings.java | 57 b/test/jdk/jfr/api/metadata/eventtype/TestUnloadingEventClass.java | 180 + b/test/jdk/jfr/api/metadata/settingdescriptor/AnnotatedSetting.java | 60 b/test/jdk/jfr/api/metadata/settingdescriptor/BaseEvent.java | 73 b/test/jdk/jfr/api/metadata/settingdescriptor/CustomEvent.java | 103 + b/test/jdk/jfr/api/metadata/settingdescriptor/PlainSetting.java | 48 b/test/jdk/jfr/api/metadata/settingdescriptor/TestDefaultValue.java | 59 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetAnnotation.java | 70 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetAnnotationElement.java | 87 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetContentType.java | 73 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetDescription.java | 70 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetLabel.java | 70 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetName.java | 65 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetTypeId.java | 73 b/test/jdk/jfr/api/metadata/settingdescriptor/TestGetTypeName.java | 68 b/test/jdk/jfr/api/metadata/valuedescriptor/TestClasses.java | 86 b/test/jdk/jfr/api/metadata/valuedescriptor/TestConstructor.java | 70 b/test/jdk/jfr/api/metadata/valuedescriptor/TestGetAnnotations.java | 95 + b/test/jdk/jfr/api/metadata/valuedescriptor/TestGetFields.java | 47 b/test/jdk/jfr/api/metadata/valuedescriptor/TestIsArray.java | 64 b/test/jdk/jfr/api/metadata/valuedescriptor/TestSimpleTypes.java | 132 + b/test/jdk/jfr/api/metadata/valuedescriptor/TestValueDescriptorContentType.java | 90 b/test/jdk/jfr/api/modules/TestModularizedEvent.java | 104 + b/test/jdk/jfr/api/modules/src_mods/test.jfr.annotation/test/jfr/annotation/ModularizedAnnotation.java | 42 b/test/jdk/jfr/api/modules/src_mods/test.jfr.event/test/jfr/event/ModularizedOrdinaryEvent.java | 44 b/test/jdk/jfr/api/modules/src_mods/test.jfr.event/test/jfr/event/ModularizedPeriodicEvent.java | 44 b/test/jdk/jfr/api/modules/src_mods/test.jfr.main/test/jfr/main/MainTest.java | 154 + b/test/jdk/jfr/api/modules/src_mods/test.jfr.setting/test/jfr/setting/ModularizedSetting.java | 62 b/test/jdk/jfr/api/recorder/TestRecorderInitialized.java | 68 b/test/jdk/jfr/api/recorder/TestRecorderListener.java | 106 + b/test/jdk/jfr/api/recorder/TestStartStopRecording.java | 80 b/test/jdk/jfr/api/recording/destination/TestDestFileExist.java | 68 b/test/jdk/jfr/api/recording/destination/TestDestFileReadOnly.java | 65 b/test/jdk/jfr/api/recording/destination/TestDestInvalid.java | 104 + b/test/jdk/jfr/api/recording/destination/TestDestLongPath.java | 66 b/test/jdk/jfr/api/recording/destination/TestDestMultiple.java | 111 + b/test/jdk/jfr/api/recording/destination/TestDestReadOnly.java | 84 b/test/jdk/jfr/api/recording/destination/TestDestState.java | 79 b/test/jdk/jfr/api/recording/destination/TestDestToDiskFalse.java | 80 b/test/jdk/jfr/api/recording/destination/TestDestToDiskTrue.java | 73 b/test/jdk/jfr/api/recording/destination/TestDestWithDuration.java | 76 b/test/jdk/jfr/api/recording/dump/TestDump.java | 61 b/test/jdk/jfr/api/recording/dump/TestDumpInvalid.java | 85 b/test/jdk/jfr/api/recording/dump/TestDumpLongPath.java | 70 b/test/jdk/jfr/api/recording/dump/TestDumpMultiple.java | 105 + b/test/jdk/jfr/api/recording/dump/TestDumpReadOnly.java | 70 b/test/jdk/jfr/api/recording/dump/TestDumpState.java | 107 + b/test/jdk/jfr/api/recording/event/TEST.properties | 2 b/test/jdk/jfr/api/recording/event/TestChunkPeriod.java | 103 + b/test/jdk/jfr/api/recording/event/TestEnableClass.java | 53 b/test/jdk/jfr/api/recording/event/TestEnableName.java | 62 b/test/jdk/jfr/api/recording/event/TestEventTime.java | 184 + b/test/jdk/jfr/api/recording/event/TestLoadEventAfterStart.java | 90 b/test/jdk/jfr/api/recording/event/TestPeriod.java | 127 + b/test/jdk/jfr/api/recording/event/TestReEnableClass.java | 80 b/test/jdk/jfr/api/recording/event/TestReEnableMultiple.java | 147 + b/test/jdk/jfr/api/recording/event/TestReEnableName.java | 97 + b/test/jdk/jfr/api/recording/event/TestRecordingEnableDisable.java | 125 + b/test/jdk/jfr/api/recording/event/TestThreshold.java | 91 b/test/jdk/jfr/api/recording/misc/TestGetId.java | 68 b/test/jdk/jfr/api/recording/misc/TestGetSize.java | 64 b/test/jdk/jfr/api/recording/misc/TestGetSizeToMem.java | 66 b/test/jdk/jfr/api/recording/misc/TestGetStream.java | 154 + b/test/jdk/jfr/api/recording/misc/TestRecordingBase.java | 175 + b/test/jdk/jfr/api/recording/misc/TestRecordingCopy.java | 112 + b/test/jdk/jfr/api/recording/options/TestDuration.java | 66 b/test/jdk/jfr/api/recording/options/TestName.java | 93 + b/test/jdk/jfr/api/recording/settings/TestConfigurationGetContents.java | 70 b/test/jdk/jfr/api/recording/settings/TestCreateConfigFromPath.java | 85 b/test/jdk/jfr/api/recording/settings/TestCreateConfigFromReader.java | 87 b/test/jdk/jfr/api/recording/settings/TestGetConfigurations.java | 80 b/test/jdk/jfr/api/recording/settings/TestSettingsAvailability.java | 123 + b/test/jdk/jfr/api/recording/settings/settings.jfc | 11 b/test/jdk/jfr/api/recording/state/TestOptionState.java | 92 b/test/jdk/jfr/api/recording/state/TestState.java | 56 b/test/jdk/jfr/api/recording/state/TestStateDuration.java | 73 b/test/jdk/jfr/api/recording/state/TestStateIdenticalListeners.java | 73 b/test/jdk/jfr/api/recording/state/TestStateInvalid.java | 70 b/test/jdk/jfr/api/recording/state/TestStateMultiple.java | 86 b/test/jdk/jfr/api/recording/state/TestStateScheduleStart.java | 73 b/test/jdk/jfr/api/recording/time/TestTime.java | 78 b/test/jdk/jfr/api/recording/time/TestTimeDuration.java | 68 b/test/jdk/jfr/api/recording/time/TestTimeMultiple.java | 87 b/test/jdk/jfr/api/recording/time/TestTimeScheduleStart.java | 68 b/test/jdk/jfr/api/settings/RegExpControl.java | 51 b/test/jdk/jfr/api/settings/StringListSetting.java | 105 + b/test/jdk/jfr/api/settings/TestFilterEvents.java | 99 + b/test/jdk/jfr/event/TEST.properties | 2 b/test/jdk/jfr/event/compiler/TestAllocInNewTLAB.java | 127 + b/test/jdk/jfr/event/compiler/TestAllocOutsideTLAB.java | 104 + b/test/jdk/jfr/event/compiler/TestCodeCacheConfig.java | 104 + b/test/jdk/jfr/event/compiler/TestCodeCacheFull.java | 106 + b/test/jdk/jfr/event/compiler/TestCodeCacheStats.java | 65 b/test/jdk/jfr/event/compiler/TestCodeSweeper.java | 224 ++ b/test/jdk/jfr/event/compiler/TestCodeSweeperConfig.java | 61 b/test/jdk/jfr/event/compiler/TestCompilerCompile.java | 141 + b/test/jdk/jfr/event/compiler/TestCompilerConfig.java | 59 b/test/jdk/jfr/event/compiler/TestCompilerInlining.java | 406 ++++ b/test/jdk/jfr/event/compiler/TestCompilerPhase.java | 89 b/test/jdk/jfr/event/compiler/TestCompilerStats.java | 68 b/test/jdk/jfr/event/gc/collection/AppGCProvoker.java | 57 b/test/jdk/jfr/event/gc/collection/GCEventAll.java | 531 +++++ b/test/jdk/jfr/event/gc/collection/GCGarbageCollectionUtil.java | 105 + b/test/jdk/jfr/event/gc/collection/TestGCCauseWithCMSConcurrent.java | 47 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithCMSMarkSweep.java | 48 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithG1ConcurrentMark.java | 49 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithG1FullCollection.java | 48 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithPSMarkSweep.java | 49 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithParallelOld.java | 47 b/test/jdk/jfr/event/gc/collection/TestGCCauseWithSerial.java | 47 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithCMSConcurrent.java | 43 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithCMSMarkSweep.java | 43 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithG1ConcurrentMark.java | 44 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithG1FullCollection.java | 42 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithPSMarkSweep.java | 42 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithParNew.java | 43 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithParallelOld.java | 42 b/test/jdk/jfr/event/gc/collection/TestGCEventMixedWithSerial.java | 41 b/test/jdk/jfr/event/gc/collection/TestGCGarbageCollectionEvent.java | 68 b/test/jdk/jfr/event/gc/collection/TestGCWithFasttime.java | 66 b/test/jdk/jfr/event/gc/collection/TestYoungGarbageCollectionEventWithDefNew.java | 42 b/test/jdk/jfr/event/gc/collection/TestYoungGarbageCollectionEventWithG1New.java | 42 b/test/jdk/jfr/event/gc/collection/TestYoungGarbageCollectionEventWithParNew.java | 42 b/test/jdk/jfr/event/gc/collection/TestYoungGarbageCollectionEventWithParallelScavenge.java | 42 b/test/jdk/jfr/event/gc/collection/YoungGarbageCollectionEvent.java | 79 b/test/jdk/jfr/event/gc/collection/gc-testsettings.jfc | 32 b/test/jdk/jfr/event/gc/configuration/GCHeapConfigurationEventTester.java | 52 b/test/jdk/jfr/event/gc/configuration/GCHeapConfigurationEventVerifier.java | 68 b/test/jdk/jfr/event/gc/configuration/GCYoungGenerationConfigurationEventTester.java | 51 b/test/jdk/jfr/event/gc/configuration/TestGCConfigurationEvent.java | 112 + b/test/jdk/jfr/event/gc/configuration/TestGCConfigurationEventWithDefaultPauseTarget.java | 67 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.java | 64 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWith32BitOops.sh | 61 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWithHeapBasedOops.java | 59 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWithHeapBasedOops.sh | 63 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWithZeroBasedOops.java | 60 b/test/jdk/jfr/event/gc/configuration/TestGCHeapConfigurationEventWithZeroBasedOops.sh | 60 b/test/jdk/jfr/event/gc/configuration/TestGCSurvivorConfigurationEvent.java | 76 b/test/jdk/jfr/event/gc/configuration/TestGCTLABConfigurationEvent.java | 86 b/test/jdk/jfr/event/gc/configuration/TestGCYoungGenerationConfigurationEventWithMinAndMaxSize.java | 88 b/test/jdk/jfr/event/gc/configuration/TestGCYoungGenerationConfigurationEventWithNewRatio.java | 66 b/test/jdk/jfr/event/gc/detailed/ExecuteOOMApp.java | 63 b/test/jdk/jfr/event/gc/detailed/OOMApp.java | 68 b/test/jdk/jfr/event/gc/detailed/PromotionEvent.java | 205 ++ b/test/jdk/jfr/event/gc/detailed/PromotionFailedEvent.java | 63 b/test/jdk/jfr/event/gc/detailed/StressAllocationGCEvents.java | 201 ++ b/test/jdk/jfr/event/gc/detailed/TestCMSConcurrentModeFailureEvent.java | 88 b/test/jdk/jfr/event/gc/detailed/TestEvacuationFailedEvent.java | 75 b/test/jdk/jfr/event/gc/detailed/TestEvacuationInfoEvent.java | 137 + b/test/jdk/jfr/event/gc/detailed/TestG1ConcurrentModeFailureEvent.java | 88 b/test/jdk/jfr/event/gc/detailed/TestG1EvacMemoryStatsEvent.java | 76 b/test/jdk/jfr/event/gc/detailed/TestG1HeapRegionInformationEvent.java | 74 b/test/jdk/jfr/event/gc/detailed/TestG1HeapRegionTypeChangeEvent.java | 89 b/test/jdk/jfr/event/gc/detailed/TestG1MMUEvent.java | 82 b/test/jdk/jfr/event/gc/detailed/TestPromotionEventWithG1.java | 44 b/test/jdk/jfr/event/gc/detailed/TestPromotionEventWithParallelScavenge.java | 42 b/test/jdk/jfr/event/gc/detailed/TestPromotionFailedEventWithDefNew.java | 43 b/test/jdk/jfr/event/gc/detailed/TestPromotionFailedEventWithParNew.java | 45 b/test/jdk/jfr/event/gc/detailed/TestPromotionFailedEventWithParallelScavenge.java | 44 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithCMS.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithDefNew.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithG1.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParNew.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressAllocationGCEventsWithParallel.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithCMS.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithDefNew.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithG1.java | 45 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParNew.java | 39 b/test/jdk/jfr/event/gc/detailed/TestStressBigAllocationGCEventsWithParallel.java | 39 b/test/jdk/jfr/event/gc/detailed/TestTenuringDistributionEvent.java | 87 b/test/jdk/jfr/event/gc/detailed/concurrentmodefailure-testsettings.jfc | 32 b/test/jdk/jfr/event/gc/detailed/evacuationfailed-testsettings.jfc | 32 b/test/jdk/jfr/event/gc/detailed/promotionfailed-testsettings.jfc | 32 b/test/jdk/jfr/event/gc/heapsummary/HeapSummaryEventAllGcs.java | 225 ++ b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryCommittedSize.java | 92 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventConcurrentCMS.java | 94 + b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventDefNewSerial.java | 41 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventG1.java | 41 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventPSParOld.java | 41 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventPSSerial.java | 41 b/test/jdk/jfr/event/gc/heapsummary/TestHeapSummaryEventParNewCMS.java | 41 b/test/jdk/jfr/event/gc/objectcount/ObjectCountAfterGCEvent.java | 98 + b/test/jdk/jfr/event/gc/objectcount/ObjectCountEventVerifier.java | 80 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithCMSConcurrent.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithCMSMarkSweep.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithG1ConcurrentMark.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithG1FullCollection.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithPSMarkSweep.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithParallelOld.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountAfterGCEventWithSerial.java | 41 b/test/jdk/jfr/event/gc/objectcount/TestObjectCountEvent.java | 86 b/test/jdk/jfr/event/gc/refstat/RefStatEvent.java | 102 + b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithCMSConcurrent.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithCMSMarkSweep.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithDefNew.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithG1ConcurrentMark.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithG1FullCollection.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithG1New.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithPSMarkSweep.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithParallelOld.java | 41 b/test/jdk/jfr/event/gc/refstat/TestRefStatEventWithParallelScavenge.java | 41 b/test/jdk/jfr/event/gc/stacktrace/AllocationStackTrace.java | 497 +++++ b/test/jdk/jfr/event/gc/stacktrace/TEST.properties | 2 b/test/jdk/jfr/event/gc/stacktrace/TestConcMarkSweepAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestDefNewAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestG1HumongousAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestG1OldAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestG1YoungAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestMarkSweepCompactAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestMetaspaceConcMarkSweepGCAllocationPendingStackTrace.java | 42 b/test/jdk/jfr/event/gc/stacktrace/TestMetaspaceG1GCAllocationPendingStackTrace.java | 42 b/test/jdk/jfr/event/gc/stacktrace/TestMetaspaceParallelGCAllocationPendingStackTrace.java | 42 b/test/jdk/jfr/event/gc/stacktrace/TestMetaspaceSerialGCAllocationPendingStackTrace.java | 42 b/test/jdk/jfr/event/gc/stacktrace/TestParNewAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestParallelMarkSweepAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/gc/stacktrace/TestParallelScavengeAllocationPendingStackTrace.java | 41 b/test/jdk/jfr/event/io/EvilInstrument.java | 158 + b/test/jdk/jfr/event/io/IOEvent.java | 210 ++ b/test/jdk/jfr/event/io/IOHelper.java | 129 + b/test/jdk/jfr/event/io/InstrumentationCallback.java | 49 b/test/jdk/jfr/event/io/MakeJAR.sh | 45 b/test/jdk/jfr/event/io/TestDisabledEvents.java | 134 + b/test/jdk/jfr/event/io/TestFileChannelEvents.java | 123 + b/test/jdk/jfr/event/io/TestFileReadOnly.java | 101 + b/test/jdk/jfr/event/io/TestFileStreamEvents.java | 96 + b/test/jdk/jfr/event/io/TestInstrumentation.java | 373 ++++ b/test/jdk/jfr/event/io/TestInstrumentation.mf | 4 b/test/jdk/jfr/event/io/TestRandomAccessFileEvents.java | 116 + b/test/jdk/jfr/event/io/TestRandomAccessFileThread.java | 226 ++ b/test/jdk/jfr/event/io/TestSocketChannelEvents.java | 130 + b/test/jdk/jfr/event/io/TestSocketEvents.java | 121 + b/test/jdk/jfr/event/metadata/TestDefaultConfigurations.java | 204 ++ b/test/jdk/jfr/event/metadata/TestEventMetadata.java | 216 ++ b/test/jdk/jfr/event/metadata/TestLookForUntestedEvents.java | 217 ++ b/test/jdk/jfr/event/oldobject/OldObjects.java | 281 +++ b/test/jdk/jfr/event/oldobject/TestAllocationTime.java | 126 + b/test/jdk/jfr/event/oldobject/TestArrayInformation.java | 125 + b/test/jdk/jfr/event/oldobject/TestCMS.java | 78 b/test/jdk/jfr/event/oldobject/TestCircularReference.java | 86 b/test/jdk/jfr/event/oldobject/TestClassLoader.java | 127 + b/test/jdk/jfr/event/oldobject/TestClassLoaderLeak.java | 82 b/test/jdk/jfr/event/oldobject/TestFieldInformation.java | 121 + b/test/jdk/jfr/event/oldobject/TestG1.java | 78 b/test/jdk/jfr/event/oldobject/TestHeapDeep.java | 87 b/test/jdk/jfr/event/oldobject/TestHeapShallow.java | 83 b/test/jdk/jfr/event/oldobject/TestLargeRootSet.java | 127 + b/test/jdk/jfr/event/oldobject/TestLastKnownHeapUsage.java | 87 b/test/jdk/jfr/event/oldobject/TestListenerLeak.java | 102 + b/test/jdk/jfr/event/oldobject/TestMetadataObject.java | 50 b/test/jdk/jfr/event/oldobject/TestMetadataRetention.java | 189 ++ b/test/jdk/jfr/event/oldobject/TestObjectDescription.java | 216 ++ b/test/jdk/jfr/event/oldobject/TestParallel.java | 78 b/test/jdk/jfr/event/oldobject/TestParallelOld.java | 78 b/test/jdk/jfr/event/oldobject/TestReferenceChainLimit.java | 84 b/test/jdk/jfr/event/oldobject/TestSanityDefault.java | 88 b/test/jdk/jfr/event/oldobject/TestSerial.java | 78 b/test/jdk/jfr/event/oldobject/TestThreadLocalLeak.java | 79 b/test/jdk/jfr/event/os/TestCPUInformation.java | 61 b/test/jdk/jfr/event/os/TestCPULoad.java | 79 b/test/jdk/jfr/event/os/TestCPUTimeStampCounter.java | 60 b/test/jdk/jfr/event/os/TestInitialEnvironmentVariable.java | 65 b/test/jdk/jfr/event/os/TestInitialEnvironmentVariable.sh | 38 b/test/jdk/jfr/event/os/TestOSInfo.java | 57 b/test/jdk/jfr/event/os/TestPhysicalMemoryEvent.java | 58 b/test/jdk/jfr/event/os/TestSystemProcess.java | 57 b/test/jdk/jfr/event/os/TestThreadContextSwitches.java | 56 b/test/jdk/jfr/event/profiling/TestFullStackTrace.java | 171 + b/test/jdk/jfr/event/runtime/TestActiveRecordingEvent.java | 126 + b/test/jdk/jfr/event/runtime/TestActiveSettingEvent.java | 253 ++ b/test/jdk/jfr/event/runtime/TestBiasedLockRevocationEvents.java | 319 +++ b/test/jdk/jfr/event/runtime/TestClassDefineEvent.java | 80 b/test/jdk/jfr/event/runtime/TestClassLoadEvent.java | 86 b/test/jdk/jfr/event/runtime/TestClassLoaderStatsEvent.java | 133 + b/test/jdk/jfr/event/runtime/TestClassLoadingStatisticsEvent.java | 142 + b/test/jdk/jfr/event/runtime/TestClassUnloadEvent.java | 93 + b/test/jdk/jfr/event/runtime/TestClasses.java | 83 b/test/jdk/jfr/event/runtime/TestExceptionEvents.java | 200 ++ b/test/jdk/jfr/event/runtime/TestExceptionSubclass.java | 65 b/test/jdk/jfr/event/runtime/TestJavaBlockedEvent.java | 119 + b/test/jdk/jfr/event/runtime/TestJavaMonitorInflateEvent.java | 116 + b/test/jdk/jfr/event/runtime/TestJavaMonitorWaitEvent.java | 107 + b/test/jdk/jfr/event/runtime/TestJavaMonitorWaitTimeOut.java | 126 + b/test/jdk/jfr/event/runtime/TestJavaThreadStatisticsEvent.java | 91 b/test/jdk/jfr/event/runtime/TestJavaThreadStatisticsEventBean.java | 85 b/test/jdk/jfr/event/runtime/TestNativeLibrariesEvent.java | 104 + b/test/jdk/jfr/event/runtime/TestNetworkUtilizationEvent.java | 108 + b/test/jdk/jfr/event/runtime/TestSafepointEvents.java | 117 + b/test/jdk/jfr/event/runtime/TestShutdownEvent.java | 253 ++ b/test/jdk/jfr/event/runtime/TestSizeTFlags.java | 109 + b/test/jdk/jfr/event/runtime/TestSystemPropertyEvent.java | 112 + b/test/jdk/jfr/event/runtime/TestThreadAllocationEvent.java | 210 ++ b/test/jdk/jfr/event/runtime/TestThreadCpuTimeEvent.java | 276 ++ b/test/jdk/jfr/event/runtime/TestThreadDumpEvent.java | 66 b/test/jdk/jfr/event/runtime/TestThreadParkEvent.java | 132 + b/test/jdk/jfr/event/runtime/TestThreadSleepEvent.java | 72 b/test/jdk/jfr/event/runtime/TestThreadStartEndEvents.java | 138 + b/test/jdk/jfr/event/runtime/TestThrowableInstrumentation.java | 61 b/test/jdk/jfr/event/runtime/TestVMInfoEvent.flags | 1 b/test/jdk/jfr/event/runtime/TestVMInfoEvent.java | 80 b/test/jdk/jfr/event/runtime/TestVMInfoEvent.sh | 35 b/test/jdk/jfr/event/runtime/TestVMOperation.java | 72 b/test/jdk/jfr/event/runtime/TestVmFlagChangedEvent.java | 118 + b/test/jdk/jfr/event/runtime/exception.security.policy | 20 b/test/jdk/jfr/event/sampling/TestNative.java | 94 + b/test/jdk/jfr/event/sampling/libTestNative.c | 41 b/test/jdk/jfr/javaagent/EventEmitterAgent.java | 106 + b/test/jdk/jfr/javaagent/JavaAgentBuilder.java | 87 b/test/jdk/jfr/javaagent/TestLoadedAgent.java | 57 b/test/jdk/jfr/javaagent/TestPremainAgent.java | 47 b/test/jdk/jfr/jcmd/JcmdAsserts.java | 190 ++ b/test/jdk/jfr/jcmd/JcmdHelper.java | 123 + b/test/jdk/jfr/jcmd/TEST.properties | 2 b/test/jdk/jfr/jcmd/TestJcmdConfigure.java | 120 + b/test/jdk/jfr/jcmd/TestJcmdDump.java | 172 + b/test/jdk/jfr/jcmd/TestJcmdDumpGeneratedFilename.java | 136 + b/test/jdk/jfr/jcmd/TestJcmdDumpLimited.java | 294 +++ b/test/jdk/jfr/jcmd/TestJcmdDumpPathToGCRoots.java | 133 + b/test/jdk/jfr/jcmd/TestJcmdLegacy.java | 93 + b/test/jdk/jfr/jcmd/TestJcmdSaveToFile.java | 70 b/test/jdk/jfr/jcmd/TestJcmdStartDirNotExist.java | 54 b/test/jdk/jfr/jcmd/TestJcmdStartInvaldFile.java | 52 b/test/jdk/jfr/jcmd/TestJcmdStartPathToGCRoots.java | 86 b/test/jdk/jfr/jcmd/TestJcmdStartReadOnlyFile.java | 60 b/test/jdk/jfr/jcmd/TestJcmdStartStopDefault.java | 77 b/test/jdk/jfr/jcmd/TestJcmdStartWithOptions.java | 143 + b/test/jdk/jfr/jcmd/TestJcmdStartWithSettings.java | 178 + b/test/jdk/jfr/jcmd/TestJcmdStopInvalidFile.java | 58 b/test/jdk/jfr/jcmd/TestJcmdStopReadOnlyFile.java | 65 b/test/jdk/jfr/jcmd/jcmd-testsettings.2.jfc | 10 b/test/jdk/jfr/jcmd/jcmd-testsettings.jfc | 10 b/test/jdk/jfr/jcmd/jcmd-testsettings3.jfc | 8 b/test/jdk/jfr/jcmd/legacy.jfc | 7 b/test/jdk/jfr/jmx/JmxHelper.java | 281 +++ b/test/jdk/jfr/jmx/TEST.properties | 2 b/test/jdk/jfr/jmx/TestClone.java | 102 + b/test/jdk/jfr/jmx/TestCloneRepeat.java | 84 b/test/jdk/jfr/jmx/TestConfigurationInfo.java | 60 b/test/jdk/jfr/jmx/TestCopyTo.java | 65 b/test/jdk/jfr/jmx/TestCopyToInvalidPath.java | 59 b/test/jdk/jfr/jmx/TestCopyToReadOnlyDir.java | 72 b/test/jdk/jfr/jmx/TestCopyToRunning.java | 83 b/test/jdk/jfr/jmx/TestEventTypes.java | 156 + b/test/jdk/jfr/jmx/TestGetRecordings.java | 50 b/test/jdk/jfr/jmx/TestGetRecordingsMultiple.java | 122 + b/test/jdk/jfr/jmx/TestMultipleRecordings.java | 95 + b/test/jdk/jfr/jmx/TestNotificationListener.java | 65 b/test/jdk/jfr/jmx/TestPredefinedConfiguration.java | 61 b/test/jdk/jfr/jmx/TestPredefinedConfigurationInvalid.java | 75 b/test/jdk/jfr/jmx/TestRecordingOptions.java | 130 + b/test/jdk/jfr/jmx/TestRecordingSettings.java | 76 b/test/jdk/jfr/jmx/TestRecordingSettingsInvalid.java | 81 b/test/jdk/jfr/jmx/TestRecordingSettingsMultiple.java | 87 b/test/jdk/jfr/jmx/TestRecordingState.java | 59 b/test/jdk/jfr/jmx/TestRecordingStateInvalid.java | 97 + b/test/jdk/jfr/jmx/TestSetConfiguration.java | 80 b/test/jdk/jfr/jmx/TestSetConfigurationInvalid.java | 108 + b/test/jdk/jfr/jmx/TestSnapshot.java | 75 b/test/jdk/jfr/jmx/TestStartRecording.java | 66 b/test/jdk/jfr/jmx/TestStream.java | 83 b/test/jdk/jfr/jmx/TestStreamClosed.java | 63 b/test/jdk/jfr/jmx/TestStreamMultiple.java | 81 b/test/jdk/jfr/jmx/TestWrongId.java | 64 b/test/jdk/jfr/jmx/info/TestConfigurationInfo.java | 109 + b/test/jdk/jfr/jmx/info/TestEventTypeInfo.java | 89 b/test/jdk/jfr/jmx/info/TestRecordingInfo.java | 75 b/test/jdk/jfr/jmx/info/TestSettingDescriptorInfo.java | 75 b/test/jdk/jfr/jmx/security/TestEnoughPermission.java | 105 + b/test/jdk/jfr/jmx/security/TestNoControlPermission.java | 73 b/test/jdk/jfr/jmx/security/TestNoMonitorPermission.java | 65 b/test/jdk/jfr/jmx/security/TestNotificationListenerPermission.java | 87 b/test/jdk/jfr/jmx/security/enough.policy | 19 b/test/jdk/jfr/jmx/security/listener.policy | 11 b/test/jdk/jfr/jmx/security/nocontrol.policy | 11 b/test/jdk/jfr/jmx/security/nomonitor.policy | 11 b/test/jdk/jfr/jvm/HelloWorldEvent1.java | 40 b/test/jdk/jfr/jvm/HelloWorldEvent2.java | 40 b/test/jdk/jfr/jvm/TestBeginAndEnd.java | 49 b/test/jdk/jfr/jvm/TestClassId.java | 60 b/test/jdk/jfr/jvm/TestCounterTime.java | 62 b/test/jdk/jfr/jvm/TestCreateNative.java | 76 b/test/jdk/jfr/jvm/TestDumpOnCrash.java | 110 + b/test/jdk/jfr/jvm/TestGetAllEventClasses.java | 125 + b/test/jdk/jfr/jvm/TestGetEventWriter.java | 51 b/test/jdk/jfr/jvm/TestGetStackTraceId.java | 71 b/test/jdk/jfr/jvm/TestJFRIntrinsic.java | 154 + b/test/jdk/jfr/jvm/TestJavaEvent.java | 213 ++ b/test/jdk/jfr/jvm/TestLargeJavaEvent512k.java | 148 + b/test/jdk/jfr/jvm/TestLargeJavaEvent64k.java | 148 + b/test/jdk/jfr/jvm/TestLogImplementation.java | 144 + b/test/jdk/jfr/jvm/TestPid.java | 76 b/test/jdk/jfr/jvm/TestUnloadEventClassCount.java | 111 + b/test/jdk/jfr/jvm/TestUnsupportedVM.java | 228 ++ b/test/jdk/jfr/security/JFRSecurityTestSuite.java | 442 ++++ b/test/jdk/jfr/startupargs/StartupHelper.java | 106 + b/test/jdk/jfr/startupargs/TestBadOptionValues.java | 151 + b/test/jdk/jfr/startupargs/TestDumpOnExit.java | 114 + b/test/jdk/jfr/startupargs/TestMemoryOptions.java | 656 +++++++ b/test/jdk/jfr/startupargs/TestMultipleStartupRecordings.java | 109 + b/test/jdk/jfr/startupargs/TestOldObjectQueueSize.java | 87 b/test/jdk/jfr/startupargs/TestRepositoryPath.java | 53 b/test/jdk/jfr/startupargs/TestRepositoryPathLong.java | 56 b/test/jdk/jfr/startupargs/TestRetransform.java | 74 b/test/jdk/jfr/startupargs/TestRetransformUsingLog.java | 114 + b/test/jdk/jfr/startupargs/TestStartDelay.java | 57 b/test/jdk/jfr/startupargs/TestStartDelayRunning.java | 55 b/test/jdk/jfr/startupargs/TestStartDuration.java | 111 + b/test/jdk/jfr/startupargs/TestStartMaxAgeSize.java | 54 b/test/jdk/jfr/startupargs/TestStartName.java | 72 b/test/jdk/jfr/startupargs/TestStartNoSettings.java | 68 b/test/jdk/jfr/startupargs/TestStartRecording.java | 55 b/test/jdk/jfr/tool/ExecuteHelper.java | 136 + b/test/jdk/jfr/tool/TestAssemble.java | 144 + b/test/jdk/jfr/tool/TestDisassemble.java | 124 + b/test/jdk/jfr/tool/TestHelp.java | 55 b/test/jdk/jfr/tool/TestMetadata.java | 62 b/test/jdk/jfr/tool/TestPrint.java | 60 b/test/jdk/jfr/tool/TestPrintDefault.java | 52 b/test/jdk/jfr/tool/TestPrintJSON.java | 162 + b/test/jdk/jfr/tool/TestPrintXML.java | 259 ++ b/test/jdk/jfr/tool/TestSummary.java | 61 b/test/jdk/jfr/tool/jfr.xsd | 81 b/test/lib/ClassFileInstaller.java | 257 ++ b/test/lib/RedefineClassHelper.java | 79 b/test/lib/jdk/test/lib/Asserts.java | 620 ++++++ b/test/lib/jdk/test/lib/BuildHelper.java | 106 + b/test/lib/jdk/test/lib/ByteCodeLoader.java | 90 b/test/lib/jdk/test/lib/Convert.java | 85 b/test/lib/jdk/test/lib/FileInstaller.java | 106 + b/test/lib/jdk/test/lib/InfiniteLoop.java | 66 b/test/lib/jdk/test/lib/JDKToolFinder.java | 106 + b/test/lib/jdk/test/lib/JDKToolLauncher.java | 132 + b/test/lib/jdk/test/lib/LockFreeLogger.java | 84 b/test/lib/jdk/test/lib/NetworkConfiguration.java | 272 ++ b/test/lib/jdk/test/lib/Platform.java | 363 +++ b/test/lib/jdk/test/lib/RandomFactory.java | 103 + b/test/lib/jdk/test/lib/SecurityTools.java | 131 + b/test/lib/jdk/test/lib/TimeLimitedRunner.java | 86 b/test/lib/jdk/test/lib/Utils.java | 811 ++++++++ b/test/lib/jdk/test/lib/apps/LingeredApp.java | 511 +++++ b/test/lib/jdk/test/lib/apps/LingeredAppWithDeadlock.java | 81 b/test/lib/jdk/test/lib/artifacts/Artifact.java | 39 b/test/lib/jdk/test/lib/artifacts/ArtifactContainer.java | 33 b/test/lib/jdk/test/lib/artifacts/ArtifactManager.java | 31 b/test/lib/jdk/test/lib/artifacts/ArtifactResolver.java | 69 b/test/lib/jdk/test/lib/artifacts/ArtifactResolverException.java | 15 b/test/lib/jdk/test/lib/artifacts/DefaultArtifactManager.java | 46 b/test/lib/jdk/test/lib/artifacts/JibArtifactManager.java | 93 + b/test/lib/jdk/test/lib/cds/CDSOptions.java | 71 b/test/lib/jdk/test/lib/cds/CDSTestUtils.java | 585 ++++++ b/test/lib/jdk/test/lib/classloader/ClassLoadUtils.java | 149 + b/test/lib/jdk/test/lib/classloader/FilterClassLoader.java | 50 b/test/lib/jdk/test/lib/classloader/GeneratingClassLoader.java | 198 ++ b/test/lib/jdk/test/lib/classloader/ParentLastURLClassLoader.java | 51 b/test/lib/jdk/test/lib/cli/CPUSpecificCommandLineOptionTest.java | 65 b/test/lib/jdk/test/lib/cli/CommandLineOptionTest.java | 545 +++++ b/test/lib/jdk/test/lib/cli/predicate/AndPredicate.java | 49 b/test/lib/jdk/test/lib/cli/predicate/CPUSpecificPredicate.java | 71 b/test/lib/jdk/test/lib/cli/predicate/NotPredicate.java | 39 b/test/lib/jdk/test/lib/cli/predicate/OrPredicate.java | 41 b/test/lib/jdk/test/lib/compiler/CompilerUtils.java | 124 + b/test/lib/jdk/test/lib/compiler/InMemoryJavaCompiler.java | 200 ++ b/test/lib/jdk/test/lib/compiler/ModuleInfoMaker.java | 129 + b/test/lib/jdk/test/lib/containers/cgroup/CPUSetsReader.java | 155 + b/test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java | 597 ++++++ b/test/lib/jdk/test/lib/containers/docker/Common.java | 89 b/test/lib/jdk/test/lib/containers/docker/DockerRunOptions.java | 77 b/test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java | 285 +++ b/test/lib/jdk/test/lib/dcmd/CommandExecutor.java | 75 b/test/lib/jdk/test/lib/dcmd/CommandExecutorException.java | 36 b/test/lib/jdk/test/lib/dcmd/FileJcmdExecutor.java | 81 b/test/lib/jdk/test/lib/dcmd/JMXExecutor.java | 187 ++ b/test/lib/jdk/test/lib/dcmd/JcmdExecutor.java | 58 b/test/lib/jdk/test/lib/dcmd/MainClassJcmdExecutor.java | 57 b/test/lib/jdk/test/lib/dcmd/PidJcmdExecutor.java | 63 b/test/lib/jdk/test/lib/hprof/HprofParser.java | 97 + b/test/lib/jdk/test/lib/hprof/README | 13 b/test/lib/jdk/test/lib/hprof/model/AbstractJavaHeapObjectVisitor.java | 60 b/test/lib/jdk/test/lib/hprof/model/ArrayTypeCodes.java | 50 b/test/lib/jdk/test/lib/hprof/model/HackJavaValue.java | 66 b/test/lib/jdk/test/lib/hprof/model/JavaBoolean.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaByte.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaChar.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaClass.java | 504 +++++ b/test/lib/jdk/test/lib/hprof/model/JavaDouble.java | 53 b/test/lib/jdk/test/lib/hprof/model/JavaField.java | 69 b/test/lib/jdk/test/lib/hprof/model/JavaFloat.java | 53 b/test/lib/jdk/test/lib/hprof/model/JavaHeapObject.java | 207 ++ b/test/lib/jdk/test/lib/hprof/model/JavaHeapObjectVisitor.java | 55 b/test/lib/jdk/test/lib/hprof/model/JavaInt.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaLazyReadObject.java | 168 + b/test/lib/jdk/test/lib/hprof/model/JavaLong.java | 53 b/test/lib/jdk/test/lib/hprof/model/JavaObject.java | 333 +++ b/test/lib/jdk/test/lib/hprof/model/JavaObjectArray.java | 165 + b/test/lib/jdk/test/lib/hprof/model/JavaObjectRef.java | 98 + b/test/lib/jdk/test/lib/hprof/model/JavaShort.java | 54 b/test/lib/jdk/test/lib/hprof/model/JavaStatic.java | 79 b/test/lib/jdk/test/lib/hprof/model/JavaThing.java | 99 + b/test/lib/jdk/test/lib/hprof/model/JavaValue.java | 62 b/test/lib/jdk/test/lib/hprof/model/JavaValueArray.java | 354 +++ b/test/lib/jdk/test/lib/hprof/model/ReachableExcludes.java | 50 b/test/lib/jdk/test/lib/hprof/model/ReachableExcludesImpl.java | 103 + b/test/lib/jdk/test/lib/hprof/model/ReachableObjects.java | 148 + b/test/lib/jdk/test/lib/hprof/model/ReferenceChain.java | 69 b/test/lib/jdk/test/lib/hprof/model/Root.java | 174 + b/test/lib/jdk/test/lib/hprof/model/Snapshot.java | 635 ++++++ b/test/lib/jdk/test/lib/hprof/model/StackFrame.java | 101 + b/test/lib/jdk/test/lib/hprof/model/StackTrace.java | 77 b/test/lib/jdk/test/lib/hprof/parser/FileReadBuffer.java | 94 + b/test/lib/jdk/test/lib/hprof/parser/HprofReader.java | 926 ++++++++++ b/test/lib/jdk/test/lib/hprof/parser/MappedReadBuffer.java | 136 + b/test/lib/jdk/test/lib/hprof/parser/PositionDataInputStream.java | 64 b/test/lib/jdk/test/lib/hprof/parser/PositionInputStream.java | 84 b/test/lib/jdk/test/lib/hprof/parser/ReadBuffer.java | 48 b/test/lib/jdk/test/lib/hprof/parser/Reader.java | 135 + b/test/lib/jdk/test/lib/hprof/util/ArraySorter.java | 147 + b/test/lib/jdk/test/lib/hprof/util/Comparer.java | 49 b/test/lib/jdk/test/lib/hprof/util/CompositeEnumeration.java | 63 b/test/lib/jdk/test/lib/hprof/util/Misc.java | 112 + b/test/lib/jdk/test/lib/hprof/util/VectorSorter.java | 148 + b/test/lib/jdk/test/lib/jfr/AppExecutorHelper.java | 80 b/test/lib/jdk/test/lib/jfr/CommonHelper.java | 117 + b/test/lib/jdk/test/lib/jfr/EventField.java | 149 + b/test/lib/jdk/test/lib/jfr/EventNames.java | 183 + b/test/lib/jdk/test/lib/jfr/EventTypePrototype.java | 80 b/test/lib/jdk/test/lib/jfr/EventVerifier.java | 53 b/test/lib/jdk/test/lib/jfr/Events.java | 390 ++++ b/test/lib/jdk/test/lib/jfr/FileHelper.java | 124 + b/test/lib/jdk/test/lib/jfr/GCHelper.java | 468 +++++ b/test/lib/jdk/test/lib/jfr/RecurseThread.java | 93 + b/test/lib/jdk/test/lib/jfr/SimpleEvent.java | 32 b/test/lib/jdk/test/lib/jfr/SimpleEventHelper.java | 107 + b/test/lib/jdk/test/lib/jfr/SimpleSetting.java | 47 b/test/lib/jdk/test/lib/jfr/Stressor.java | 49 b/test/lib/jdk/test/lib/jfr/TestClassLoader.java | 78 b/test/lib/jdk/test/lib/jfr/VoidFunction.java | 31 b/test/lib/jdk/test/lib/management/DynamicVMOption.java | 166 + b/test/lib/jdk/test/lib/management/InputArguments.java | 41 b/test/lib/jdk/test/lib/management/ThreadMXBeanTool.java | 71 b/test/lib/jdk/test/lib/process/ExitCode.java | 40 b/test/lib/jdk/test/lib/process/OutputAnalyzer.java | 557 ++++++ b/test/lib/jdk/test/lib/process/OutputBuffer.java | 59 b/test/lib/jdk/test/lib/process/ProcessTools.java | 596 ++++++ b/test/lib/jdk/test/lib/process/StreamPumper.java | 197 ++ b/test/lib/jdk/test/lib/thread/TestThread.java | 204 ++ b/test/lib/jdk/test/lib/thread/XRun.java | 56 b/test/lib/jdk/test/lib/util/FileUtils.java | 276 ++ b/test/lib/jdk/test/lib/util/JarUtils.java | 175 + b/test/lib/jdk/test/lib/util/Pair.java | 68 b/test/lib/jdk/test/lib/util/SerializationUtils.java | 56 b/test/lib/jdk/test/lib/util/Triple.java | 90 b/test/lib/sun/hotspot/WhiteBox.java | 450 ++++ b/test/lib/sun/hotspot/code/BlobType.java | 69 b/test/lib/sun/hotspot/code/CodeBlob.java | 74 b/test/lib/sun/hotspot/code/Compiler.java | 136 + b/test/lib/sun/hotspot/code/NMethod.java | 58 b/test/lib/sun/hotspot/cpuinfo/CPUInfo.java | 96 + b/test/lib/sun/hotspot/gc/GC.java | 72 b/test/lib/sun/hotspot/parser/DiagnosticCommand.java | 77 b/test/lib/testlibrary/ExtendedRobot.java | 45 b/test/lib/testlibrary/jdk/testlibrary/thread/TestThread.java | 204 ++ b/test/lib/testlibrary/jdk/testlibrary/thread/XRun.java | 56 b/test/sun/java2d/marlin/CrashNaNTest.java | 143 + b/test/sun/java2d/marlin/TextClipErrorTest.java | 22 b/test/sun/security/ec/SignedObjectChain.java | 3 b/test/sun/security/mscapi/SignedObjectChain.java | 3 b/test/sun/security/ssl/rsa/SignedObjectChain.java | 1 b/test/sun/security/x509/X509CertImpl/CertificateValidation.java | 60 b/test/tools/launcher/VersionCheck.java | 1 904 files changed, 102413 insertions(+), 927 deletions(-) diffstat for hotspot a/make/aix/makefiles/trace.make | 120 a/make/bsd/makefiles/trace.make | 121 a/make/linux/makefiles/trace.make | 120 a/make/solaris/makefiles/trace.make | 120 a/make/windows/makefiles/trace.make | 120 a/src/share/vm/runtime/vmStructs_trace.hpp | 35 a/src/share/vm/trace/noTraceBackend.hpp | 44 a/src/share/vm/trace/trace.dtd | 86 a/src/share/vm/trace/trace.xml | 443 -- a/src/share/vm/trace/traceBackend.hpp | 62 a/src/share/vm/trace/traceDataTypes.hpp | 69 a/src/share/vm/trace/traceEvent.hpp | 157 - a/src/share/vm/trace/traceEventClasses.xsl | 251 - a/src/share/vm/trace/traceEventIds.xsl | 72 a/src/share/vm/trace/traceMacros.hpp | 44 a/src/share/vm/trace/traceStream.hpp | 114 a/src/share/vm/trace/traceTime.hpp | 32 a/src/share/vm/trace/traceTypes.xsl | 73 a/src/share/vm/trace/tracetypes.xml | 376 -- a/src/share/vm/trace/tracing.hpp | 31 a/src/share/vm/trace/xinclude.mod | 37 a/src/share/vm/trace/xsl_util.xsl | 78 a/src/share/vm/utilities/ticks.inline.hpp | 97 b/.hgtags | 3 b/THIRD_PARTY_README | 30 b/agent/src/share/classes/sun/jvm/hotspot/runtime/JavaThread.java | 4 b/make/Makefile | 5 b/make/aix/makefiles/buildtree.make | 23 b/make/aix/makefiles/jfr.make | 92 b/make/aix/makefiles/mapfile-vers-debug | 1 b/make/aix/makefiles/mapfile-vers-product | 1 b/make/aix/makefiles/rules.make | 4 b/make/aix/makefiles/top.make | 10 b/make/aix/makefiles/vm.make | 18 b/make/bsd/makefiles/buildtree.make | 19 b/make/bsd/makefiles/jfr.make | 92 b/make/bsd/makefiles/mapfile-vers-debug | 1 b/make/bsd/makefiles/mapfile-vers-product | 1 b/make/bsd/makefiles/rules.make | 4 b/make/bsd/makefiles/top.make | 8 b/make/bsd/makefiles/vm.make | 15 b/make/defs.make | 4 b/make/linux/makefiles/buildtree.make | 22 b/make/linux/makefiles/jfr.make | 92 b/make/linux/makefiles/mapfile-vers-debug | 1 b/make/linux/makefiles/mapfile-vers-product | 1 b/make/linux/makefiles/rules.make | 4 b/make/linux/makefiles/top.make | 8 b/make/linux/makefiles/vm.make | 15 b/make/solaris/makefiles/buildtree.make | 23 b/make/solaris/makefiles/jfr.make | 92 b/make/solaris/makefiles/mapfile-vers | 1 b/make/solaris/makefiles/rules.make | 4 b/make/solaris/makefiles/top.make | 8 b/make/solaris/makefiles/vm.make | 18 b/make/windows/build.make | 1 b/make/windows/create_obj_files.sh | 10 b/make/windows/makefiles/compile.make | 8 b/make/windows/makefiles/defs.make | 3 b/make/windows/makefiles/generated.make | 10 b/make/windows/makefiles/jfr.make | 81 b/make/windows/makefiles/rules.make | 4 b/make/windows/makefiles/vm.make | 85 b/make/windows/projectfiles/common/Makefile | 4 b/src/cpu/ppc/vm/frame_ppc.cpp | 134 b/src/cpu/ppc/vm/vm_version_ext_ppc.cpp | 87 b/src/cpu/ppc/vm/vm_version_ext_ppc.hpp | 62 b/src/cpu/sparc/vm/vm_version_ext_sparc.cpp | 195 + b/src/cpu/sparc/vm/vm_version_ext_sparc.hpp | 69 b/src/cpu/x86/vm/rdtsc_x86.cpp | 225 + b/src/cpu/x86/vm/rdtsc_x86.hpp | 50 b/src/cpu/x86/vm/vm_version_ext_x86.cpp | 966 ++++++ b/src/cpu/x86/vm/vm_version_ext_x86.hpp | 100 b/src/cpu/zero/vm/vm_version_ext_zero.cpp | 82 b/src/cpu/zero/vm/vm_version_ext_zero.hpp | 52 b/src/os/aix/vm/os_aix.cpp | 9 b/src/os/aix/vm/os_perf_aix.cpp | 1053 ++++++ b/src/os/bsd/vm/os_bsd.cpp | 51 b/src/os/bsd/vm/os_perf_bsd.cpp | 491 +++ b/src/os/bsd/vm/semaphore_bsd.cpp | 107 b/src/os/bsd/vm/semaphore_bsd.hpp | 63 b/src/os/linux/vm/os_linux.cpp | 39 b/src/os/linux/vm/os_perf_linux.cpp | 1148 +++++++ b/src/os/posix/vm/os_posix.cpp | 40 b/src/os/posix/vm/os_posix.hpp | 13 b/src/os/posix/vm/semaphore_posix.cpp | 98 b/src/os/posix/vm/semaphore_posix.hpp | 53 b/src/os/solaris/vm/os_perf_solaris.cpp | 851 +++++ b/src/os/solaris/vm/os_solaris.cpp | 46 b/src/os/windows/vm/iphlp_interface.cpp | 104 b/src/os/windows/vm/iphlp_interface.hpp | 51 b/src/os/windows/vm/os_perf_windows.cpp | 1456 +++++++++ b/src/os/windows/vm/os_windows.cpp | 100 b/src/os/windows/vm/os_windows.hpp | 14 b/src/os/windows/vm/pdh_interface.cpp | 165 + b/src/os/windows/vm/pdh_interface.hpp | 64 b/src/os/windows/vm/semaphore_windows.cpp | 60 b/src/os/windows/vm/semaphore_windows.hpp | 52 b/src/os_cpu/bsd_x86/vm/os_bsd_x86.cpp | 2 b/src/os_cpu/linux_ppc/vm/thread_linux_ppc.cpp | 57 b/src/os_cpu/linux_ppc/vm/thread_linux_ppc.hpp | 2 b/src/os_cpu/linux_sparc/vm/os_linux_sparc.cpp | 2 b/src/os_cpu/linux_x86/vm/os_linux_x86.cpp | 4 b/src/os_cpu/linux_zero/vm/thread_linux_zero.hpp | 8 b/src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp | 2 b/src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp | 2 b/src/os_cpu/solaris_x86/vm/os_solaris_x86.inline.hpp | 4 b/src/share/vm/c1/c1_GraphBuilder.cpp | 44 b/src/share/vm/c1/c1_LIRGenerator.cpp | 57 b/src/share/vm/c1/c1_LIRGenerator.hpp | 5 b/src/share/vm/c1/c1_Runtime1.cpp | 5 b/src/share/vm/ci/ciEnv.cpp | 1 b/src/share/vm/ci/ciMethod.hpp | 11 b/src/share/vm/classfile/classFileParser.cpp | 40 b/src/share/vm/classfile/classFileParser.hpp | 8 b/src/share/vm/classfile/classFileStream.cpp | 32 b/src/share/vm/classfile/classFileStream.hpp | 20 b/src/share/vm/classfile/classLoader.cpp | 9 b/src/share/vm/classfile/classLoaderData.cpp | 53 b/src/share/vm/classfile/classLoaderData.hpp | 26 b/src/share/vm/classfile/javaClasses.cpp | 3 b/src/share/vm/classfile/systemDictionary.cpp | 108 b/src/share/vm/classfile/systemDictionary.hpp | 4 b/src/share/vm/classfile/vmSymbols.cpp | 2 b/src/share/vm/classfile/vmSymbols.hpp | 11 b/src/share/vm/code/codeBlob.cpp | 2 b/src/share/vm/code/codeBlob.hpp | 11 b/src/share/vm/code/codeCache.cpp | 10 b/src/share/vm/compiler/compileBroker.cpp | 34 b/src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp | 24 b/src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp | 6 b/src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp | 8 b/src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp | 4 b/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.cpp | 5 b/src/share/vm/gc_implementation/g1/g1GCPhaseTimes.hpp | 2 b/src/share/vm/gc_implementation/g1/g1HeapRegionEventSender.cpp | 49 b/src/share/vm/gc_implementation/g1/g1HeapRegionEventSender.hpp | 35 b/src/share/vm/gc_implementation/g1/g1HeapRegionTraceType.hpp | 56 b/src/share/vm/gc_implementation/g1/g1MMUTracker.cpp | 4 b/src/share/vm/gc_implementation/g1/g1MarkSweep.cpp | 4 b/src/share/vm/gc_implementation/g1/g1ParScanThreadState.cpp | 19 b/src/share/vm/gc_implementation/g1/g1ParScanThreadState.hpp | 4 b/src/share/vm/gc_implementation/g1/heapRegion.cpp | 36 b/src/share/vm/gc_implementation/g1/heapRegion.hpp | 14 b/src/share/vm/gc_implementation/g1/heapRegionSet.cpp | 2 b/src/share/vm/gc_implementation/g1/heapRegionTracer.cpp | 43 b/src/share/vm/gc_implementation/g1/heapRegionTracer.hpp | 40 b/src/share/vm/gc_implementation/g1/heapRegionType.cpp | 15 b/src/share/vm/gc_implementation/g1/heapRegionType.hpp | 2 b/src/share/vm/gc_implementation/parNew/parNewGeneration.cpp | 2 b/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp | 4 b/src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp | 4 b/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.hpp | 4 b/src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.inline.hpp | 39 b/src/share/vm/gc_implementation/parallelScavenge/psScavenge.hpp | 1 b/src/share/vm/gc_implementation/shared/ageTable.cpp | 6 b/src/share/vm/gc_implementation/shared/ageTable.hpp | 3 b/src/share/vm/gc_implementation/shared/ageTableTracer.cpp | 43 b/src/share/vm/gc_implementation/shared/ageTableTracer.hpp | 37 b/src/share/vm/gc_implementation/shared/gcConfiguration.cpp | 159 + b/src/share/vm/gc_implementation/shared/gcConfiguration.hpp | 80 b/src/share/vm/gc_implementation/shared/gcHeapSummary.hpp | 20 b/src/share/vm/gc_implementation/shared/gcTimer.cpp | 6 b/src/share/vm/gc_implementation/shared/gcTrace.cpp | 32 b/src/share/vm/gc_implementation/shared/gcTrace.hpp | 36 b/src/share/vm/gc_implementation/shared/gcTraceSend.cpp | 136 b/src/share/vm/gc_implementation/shared/gcTraceTime.cpp | 4 b/src/share/vm/gc_implementation/shared/objectCountEventSender.cpp | 59 b/src/share/vm/gc_implementation/shared/objectCountEventSender.hpp | 9 b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp | 4 b/src/share/vm/gc_interface/allocTracer.cpp | 19 b/src/share/vm/gc_interface/allocTracer.hpp | 4 b/src/share/vm/gc_interface/collectedHeap.cpp | 2 b/src/share/vm/gc_interface/collectedHeap.inline.hpp | 2 b/src/share/vm/jfr/GenerateJfrFiles.java | 756 ++++ b/src/share/vm/jfr/dcmd/jfrDcmds.cpp | 675 ++++ b/src/share/vm/jfr/dcmd/jfrDcmds.hpp | 194 + b/src/share/vm/jfr/instrumentation/jfrEventClassTransformer.cpp | 1551 ++++++++++ b/src/share/vm/jfr/instrumentation/jfrEventClassTransformer.hpp | 45 b/src/share/vm/jfr/instrumentation/jfrJvmtiAgent.cpp | 278 + b/src/share/vm/jfr/instrumentation/jfrJvmtiAgent.hpp | 41 b/src/share/vm/jfr/jfr.cpp | 106 b/src/share/vm/jfr/jfr.hpp | 60 b/src/share/vm/jfr/jfrEvents.hpp | 35 b/src/share/vm/jfr/jni/jfrGetAllEventClasses.cpp | 190 + b/src/share/vm/jfr/jni/jfrGetAllEventClasses.hpp | 41 b/src/share/vm/jfr/jni/jfrJavaCall.cpp | 380 ++ b/src/share/vm/jfr/jni/jfrJavaCall.hpp | 134 b/src/share/vm/jfr/jni/jfrJavaSupport.cpp | 583 +++ b/src/share/vm/jfr/jni/jfrJavaSupport.hpp | 111 b/src/share/vm/jfr/jni/jfrJniMethod.cpp | 312 ++ b/src/share/vm/jfr/jni/jfrJniMethod.hpp | 139 b/src/share/vm/jfr/jni/jfrJniMethodRegistration.cpp | 95 b/src/share/vm/jfr/jni/jfrJniMethodRegistration.hpp | 39 b/src/share/vm/jfr/jni/jfrUpcalls.cpp | 190 + b/src/share/vm/jfr/jni/jfrUpcalls.hpp | 60 b/src/share/vm/jfr/leakprofiler/chains/bfsClosure.cpp | 234 + b/src/share/vm/jfr/leakprofiler/chains/bfsClosure.hpp | 73 b/src/share/vm/jfr/leakprofiler/chains/bitset.cpp | 58 b/src/share/vm/jfr/leakprofiler/chains/bitset.hpp | 79 b/src/share/vm/jfr/leakprofiler/chains/dfsClosure.cpp | 183 + b/src/share/vm/jfr/leakprofiler/chains/dfsClosure.hpp | 65 b/src/share/vm/jfr/leakprofiler/chains/edge.cpp | 65 b/src/share/vm/jfr/leakprofiler/chains/edge.hpp | 59 b/src/share/vm/jfr/leakprofiler/chains/edgeQueue.cpp | 100 b/src/share/vm/jfr/leakprofiler/chains/edgeQueue.hpp | 60 b/src/share/vm/jfr/leakprofiler/chains/edgeStore.cpp | 319 ++ b/src/share/vm/jfr/leakprofiler/chains/edgeStore.hpp | 107 b/src/share/vm/jfr/leakprofiler/chains/edgeUtils.cpp | 151 b/src/share/vm/jfr/leakprofiler/chains/edgeUtils.hpp | 51 b/src/share/vm/jfr/leakprofiler/chains/objectSampleMarker.hpp | 81 b/src/share/vm/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp | 131 b/src/share/vm/jfr/leakprofiler/chains/pathToGcRootsOperation.hpp | 46 b/src/share/vm/jfr/leakprofiler/chains/rootSetClosure.cpp | 95 b/src/share/vm/jfr/leakprofiler/chains/rootSetClosure.hpp | 42 b/src/share/vm/jfr/leakprofiler/checkpoint/eventEmitter.cpp | 147 b/src/share/vm/jfr/leakprofiler/checkpoint/eventEmitter.hpp | 58 b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.cpp | 293 + b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleCheckpoint.hpp | 52 b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp | 216 + b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleDescription.hpp | 74 b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleWriter.cpp | 602 +++ b/src/share/vm/jfr/leakprofiler/checkpoint/objectSampleWriter.hpp | 46 b/src/share/vm/jfr/leakprofiler/checkpoint/rootResolver.cpp | 436 ++ b/src/share/vm/jfr/leakprofiler/checkpoint/rootResolver.hpp | 52 b/src/share/vm/jfr/leakprofiler/leakProfiler.cpp | 110 b/src/share/vm/jfr/leakprofiler/leakProfiler.hpp | 46 b/src/share/vm/jfr/leakprofiler/sampling/objectSample.hpp | 249 + b/src/share/vm/jfr/leakprofiler/sampling/objectSampler.cpp | 285 + b/src/share/vm/jfr/leakprofiler/sampling/objectSampler.hpp | 97 b/src/share/vm/jfr/leakprofiler/sampling/sampleList.cpp | 146 b/src/share/vm/jfr/leakprofiler/sampling/sampleList.hpp | 64 b/src/share/vm/jfr/leakprofiler/sampling/samplePriorityQueue.cpp | 150 b/src/share/vm/jfr/leakprofiler/sampling/samplePriorityQueue.hpp | 58 b/src/share/vm/jfr/leakprofiler/startOperation.hpp | 42 b/src/share/vm/jfr/leakprofiler/stopOperation.hpp | 39 b/src/share/vm/jfr/leakprofiler/utilities/granularTimer.cpp | 75 b/src/share/vm/jfr/leakprofiler/utilities/granularTimer.hpp | 46 b/src/share/vm/jfr/leakprofiler/utilities/rootType.hpp | 109 b/src/share/vm/jfr/leakprofiler/utilities/saveRestore.cpp | 111 b/src/share/vm/jfr/leakprofiler/utilities/saveRestore.hpp | 128 b/src/share/vm/jfr/leakprofiler/utilities/unifiedOop.hpp | 55 b/src/share/vm/jfr/leakprofiler/utilities/vmOperation.hpp | 41 b/src/share/vm/jfr/metadata/jfrSerializer.hpp | 100 b/src/share/vm/jfr/metadata/metadata.xml | 1143 +++++++ b/src/share/vm/jfr/metadata/metadata.xsd | 122 b/src/share/vm/jfr/periodic/jfrNetworkUtilization.cpp | 190 + b/src/share/vm/jfr/periodic/jfrNetworkUtilization.hpp | 38 b/src/share/vm/jfr/periodic/jfrOSInterface.cpp | 254 + b/src/share/vm/jfr/periodic/jfrOSInterface.hpp | 61 b/src/share/vm/jfr/periodic/jfrPeriodic.cpp | 560 +++ b/src/share/vm/jfr/periodic/jfrThreadCPULoadEvent.cpp | 147 b/src/share/vm/jfr/periodic/jfrThreadCPULoadEvent.hpp | 45 b/src/share/vm/jfr/periodic/jfrThreadDumpEvent.cpp | 63 b/src/share/vm/jfr/periodic/jfrThreadDumpEvent.hpp | 39 b/src/share/vm/jfr/periodic/sampling/jfrCallTrace.cpp | 117 b/src/share/vm/jfr/periodic/sampling/jfrCallTrace.hpp | 45 b/src/share/vm/jfr/periodic/sampling/jfrThreadSampler.cpp | 674 ++++ b/src/share/vm/jfr/periodic/sampling/jfrThreadSampler.hpp | 56 b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointBlob.cpp | 93 b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointBlob.hpp | 59 b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointManager.cpp | 379 ++ b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointManager.hpp | 108 b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointWriter.cpp | 185 + b/src/share/vm/jfr/recorder/checkpoint/jfrCheckpointWriter.hpp | 88 b/src/share/vm/jfr/recorder/checkpoint/jfrMetadataEvent.cpp | 89 b/src/share/vm/jfr/recorder/checkpoint/jfrMetadataEvent.hpp | 46 b/src/share/vm/jfr/recorder/checkpoint/types/jfrThreadGroup.cpp | 413 ++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrThreadGroup.hpp | 65 b/src/share/vm/jfr/recorder/checkpoint/types/jfrThreadState.cpp | 82 b/src/share/vm/jfr/recorder/checkpoint/types/jfrThreadState.hpp | 37 b/src/share/vm/jfr/recorder/checkpoint/types/jfrType.cpp | 351 ++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrType.hpp | 138 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.cpp | 249 + b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeManager.hpp | 44 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.cpp | 901 +++++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSet.hpp | 68 b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.cpp | 271 + b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetUtils.hpp | 381 ++ b/src/share/vm/jfr/recorder/checkpoint/types/jfrTypeSetWriter.hpp | 108 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.cpp | 215 + b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.hpp | 124 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceId.inline.hpp | 148 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceIdBits.inline.hpp | 108 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.cpp | 39 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceIdEpoch.hpp | 103 b/src/share/vm/jfr/recorder/checkpoint/types/traceid/jfrTraceIdMacros.hpp | 187 + b/src/share/vm/jfr/recorder/jfrEventSetting.cpp | 63 b/src/share/vm/jfr/recorder/jfrEventSetting.hpp | 52 b/src/share/vm/jfr/recorder/jfrEventSetting.inline.hpp | 51 b/src/share/vm/jfr/recorder/jfrRecorder.cpp | 405 ++ b/src/share/vm/jfr/recorder/jfrRecorder.hpp | 73 b/src/share/vm/jfr/recorder/repository/jfrChunkRotation.cpp | 81 b/src/share/vm/jfr/recorder/repository/jfrChunkRotation.hpp | 44 b/src/share/vm/jfr/recorder/repository/jfrChunkState.cpp | 119 b/src/share/vm/jfr/recorder/repository/jfrChunkState.hpp | 60 b/src/share/vm/jfr/recorder/repository/jfrChunkWriter.cpp | 123 b/src/share/vm/jfr/recorder/repository/jfrChunkWriter.hpp | 57 b/src/share/vm/jfr/recorder/repository/jfrEmergencyDump.cpp | 164 + b/src/share/vm/jfr/recorder/repository/jfrEmergencyDump.hpp | 40 b/src/share/vm/jfr/recorder/repository/jfrRepository.cpp | 473 +++ b/src/share/vm/jfr/recorder/repository/jfrRepository.hpp | 73 b/src/share/vm/jfr/recorder/service/jfrEvent.cpp | 63 b/src/share/vm/jfr/recorder/service/jfrEvent.hpp | 214 + b/src/share/vm/jfr/recorder/service/jfrMemorySizer.cpp | 433 ++ b/src/share/vm/jfr/recorder/service/jfrMemorySizer.hpp | 56 b/src/share/vm/jfr/recorder/service/jfrOptionSet.cpp | 729 ++++ b/src/share/vm/jfr/recorder/service/jfrOptionSet.hpp | 87 b/src/share/vm/jfr/recorder/service/jfrPostBox.cpp | 173 + b/src/share/vm/jfr/recorder/service/jfrPostBox.hpp | 97 b/src/share/vm/jfr/recorder/service/jfrRecorderService.cpp | 551 +++ b/src/share/vm/jfr/recorder/service/jfrRecorderService.hpp | 77 b/src/share/vm/jfr/recorder/service/jfrRecorderThread.cpp | 117 b/src/share/vm/jfr/recorder/service/jfrRecorderThread.hpp | 45 b/src/share/vm/jfr/recorder/service/jfrRecorderThreadLoop.cpp | 94 b/src/share/vm/jfr/recorder/stacktrace/jfrStackTraceRepository.cpp | 445 ++ b/src/share/vm/jfr/recorder/stacktrace/jfrStackTraceRepository.hpp | 157 + b/src/share/vm/jfr/recorder/storage/jfrBuffer.cpp | 249 + b/src/share/vm/jfr/recorder/storage/jfrBuffer.hpp | 187 + b/src/share/vm/jfr/recorder/storage/jfrMemorySpace.hpp | 168 + b/src/share/vm/jfr/recorder/storage/jfrMemorySpace.inline.hpp | 385 ++ b/src/share/vm/jfr/recorder/storage/jfrMemorySpaceRetrieval.hpp | 113 b/src/share/vm/jfr/recorder/storage/jfrStorage.cpp | 761 ++++ b/src/share/vm/jfr/recorder/storage/jfrStorage.hpp | 98 b/src/share/vm/jfr/recorder/storage/jfrStorageControl.cpp | 141 b/src/share/vm/jfr/recorder/storage/jfrStorageControl.hpp | 68 b/src/share/vm/jfr/recorder/storage/jfrStorageUtils.hpp | 124 b/src/share/vm/jfr/recorder/storage/jfrStorageUtils.inline.hpp | 98 b/src/share/vm/jfr/recorder/storage/jfrVirtualMemory.cpp | 534 +++ b/src/share/vm/jfr/recorder/storage/jfrVirtualMemory.hpp | 66 b/src/share/vm/jfr/recorder/stringpool/jfrStringPool.cpp | 245 + b/src/share/vm/jfr/recorder/stringpool/jfrStringPool.hpp | 83 b/src/share/vm/jfr/recorder/stringpool/jfrStringPoolBuffer.cpp | 67 b/src/share/vm/jfr/recorder/stringpool/jfrStringPoolBuffer.hpp | 46 b/src/share/vm/jfr/recorder/stringpool/jfrStringPoolWriter.cpp | 50 b/src/share/vm/jfr/recorder/stringpool/jfrStringPoolWriter.hpp | 58 b/src/share/vm/jfr/support/jfrAllocationTracer.cpp | 43 b/src/share/vm/jfr/support/jfrAllocationTracer.hpp | 40 b/src/share/vm/jfr/support/jfrEventClass.cpp | 87 b/src/share/vm/jfr/support/jfrEventClass.hpp | 64 b/src/share/vm/jfr/support/jfrFlush.cpp | 84 b/src/share/vm/jfr/support/jfrFlush.hpp | 79 b/src/share/vm/jfr/support/jfrIntrinsics.hpp | 56 b/src/share/vm/jfr/support/jfrKlassExtension.hpp | 42 b/src/share/vm/jfr/support/jfrStackTraceMark.cpp | 82 b/src/share/vm/jfr/support/jfrStackTraceMark.hpp | 47 b/src/share/vm/jfr/support/jfrThreadExtension.hpp | 56 b/src/share/vm/jfr/support/jfrThreadId.hpp | 41 b/src/share/vm/jfr/support/jfrThreadLocal.cpp | 167 + b/src/share/vm/jfr/support/jfrThreadLocal.hpp | 222 + b/src/share/vm/jfr/support/jfrTraceIdExtension.hpp | 81 b/src/share/vm/jfr/utilities/jfrAllocation.cpp | 146 b/src/share/vm/jfr/utilities/jfrAllocation.hpp | 74 b/src/share/vm/jfr/utilities/jfrBigEndian.hpp | 150 b/src/share/vm/jfr/utilities/jfrDoublyLinkedList.hpp | 218 + b/src/share/vm/jfr/utilities/jfrHashtable.hpp | 283 + b/src/share/vm/jfr/utilities/jfrIterator.hpp | 107 b/src/share/vm/jfr/utilities/jfrJavaLog.cpp | 141 b/src/share/vm/jfr/utilities/jfrJavaLog.hpp | 48 b/src/share/vm/jfr/utilities/jfrRefCountPointer.hpp | 154 b/src/share/vm/jfr/utilities/jfrResourceManager.hpp | 60 b/src/share/vm/jfr/utilities/jfrSpinlockHelper.hpp | 50 b/src/share/vm/jfr/utilities/jfrTime.cpp | 71 b/src/share/vm/jfr/utilities/jfrTime.hpp | 44 b/src/share/vm/jfr/utilities/jfrTimeConverter.cpp | 89 b/src/share/vm/jfr/utilities/jfrTimeConverter.hpp | 53 b/src/share/vm/jfr/utilities/jfrTryLock.hpp | 74 b/src/share/vm/jfr/utilities/jfrTypes.hpp | 44 b/src/share/vm/jfr/writers/jfrBigEndianWriter.hpp | 42 b/src/share/vm/jfr/writers/jfrEncoders.hpp | 312 ++ b/src/share/vm/jfr/writers/jfrEncoding.hpp | 117 b/src/share/vm/jfr/writers/jfrEventWriterHost.hpp | 51 b/src/share/vm/jfr/writers/jfrEventWriterHost.inline.hpp | 97 b/src/share/vm/jfr/writers/jfrJavaEventWriter.cpp | 249 + b/src/share/vm/jfr/writers/jfrJavaEventWriter.hpp | 51 b/src/share/vm/jfr/writers/jfrMemoryWriterHost.hpp | 72 b/src/share/vm/jfr/writers/jfrMemoryWriterHost.inline.hpp | 99 b/src/share/vm/jfr/writers/jfrNativeEventWriter.hpp | 38 b/src/share/vm/jfr/writers/jfrPosition.hpp | 57 b/src/share/vm/jfr/writers/jfrPosition.inline.hpp | 102 b/src/share/vm/jfr/writers/jfrStorageAdapter.hpp | 243 + b/src/share/vm/jfr/writers/jfrStorageHost.hpp | 59 b/src/share/vm/jfr/writers/jfrStorageHost.inline.hpp | 138 b/src/share/vm/jfr/writers/jfrStreamWriterHost.hpp | 60 b/src/share/vm/jfr/writers/jfrStreamWriterHost.inline.hpp | 139 b/src/share/vm/jfr/writers/jfrWriterHost.hpp | 100 b/src/share/vm/jfr/writers/jfrWriterHost.inline.hpp | 360 ++ b/src/share/vm/memory/defNewGeneration.cpp | 6 b/src/share/vm/memory/defNewGeneration.hpp | 2 b/src/share/vm/memory/genCollectedHeap.cpp | 4 b/src/share/vm/memory/metaspace.cpp | 2 b/src/share/vm/memory/metaspaceTracer.cpp | 7 b/src/share/vm/memory/referenceProcessor.cpp | 4 b/src/share/vm/oops/arrayKlass.cpp | 1 b/src/share/vm/oops/instanceKlass.cpp | 12 b/src/share/vm/oops/instanceKlass.hpp | 6 b/src/share/vm/oops/klass.cpp | 8 b/src/share/vm/oops/klass.hpp | 8 b/src/share/vm/oops/klassVtable.cpp | 27 b/src/share/vm/oops/method.hpp | 8 b/src/share/vm/opto/bytecodeInfo.cpp | 31 b/src/share/vm/opto/compile.cpp | 9 b/src/share/vm/opto/compile.hpp | 6 b/src/share/vm/opto/library_call.cpp | 92 b/src/share/vm/opto/parse.hpp | 2 b/src/share/vm/opto/superword.hpp | 51 b/src/share/vm/prims/jni.cpp | 23 b/src/share/vm/prims/jvm.cpp | 24 b/src/share/vm/prims/jvm.h | 3 b/src/share/vm/prims/methodHandles.cpp | 2 b/src/share/vm/prims/nativeLookup.cpp | 6 b/src/share/vm/prims/unsafe.cpp | 27 b/src/share/vm/prims/whitebox.cpp | 149 b/src/share/vm/prims/whitebox.hpp | 4 b/src/share/vm/runtime/arguments.cpp | 21 b/src/share/vm/runtime/biasedLocking.cpp | 68 b/src/share/vm/runtime/frame.cpp | 13 b/src/share/vm/runtime/frame.hpp | 2 b/src/share/vm/runtime/globals.cpp | 30 b/src/share/vm/runtime/globals.hpp | 60 b/src/share/vm/runtime/globals_extension.hpp | 1 b/src/share/vm/runtime/handles.cpp | 3 b/src/share/vm/runtime/java.cpp | 12 b/src/share/vm/runtime/mutex.cpp | 8 b/src/share/vm/runtime/mutexLocker.cpp | 12 b/src/share/vm/runtime/mutexLocker.hpp | 7 b/src/share/vm/runtime/objectMonitor.cpp | 50 b/src/share/vm/runtime/objectMonitor.hpp | 7 b/src/share/vm/runtime/os.cpp | 19 b/src/share/vm/runtime/os.hpp | 11 b/src/share/vm/runtime/os_perf.hpp | 292 + b/src/share/vm/runtime/safepoint.cpp | 209 + b/src/share/vm/runtime/safepoint.hpp | 1 b/src/share/vm/runtime/semaphore.hpp | 63 b/src/share/vm/runtime/semaphore.inline.hpp | 41 b/src/share/vm/runtime/sweeper.cpp | 32 b/src/share/vm/runtime/synchronizer.cpp | 18 b/src/share/vm/runtime/thread.cpp | 61 b/src/share/vm/runtime/thread.hpp | 29 b/src/share/vm/runtime/vmStructs.cpp | 33 b/src/share/vm/runtime/vmThread.cpp | 35 b/src/share/vm/runtime/vmThread.hpp | 3 b/src/share/vm/runtime/vm_operations.cpp | 1 b/src/share/vm/runtime/vm_operations.hpp | 1 b/src/share/vm/runtime/vm_version.hpp | 9 b/src/share/vm/services/diagnosticArgument.cpp | 2 b/src/share/vm/services/memTracker.hpp | 2 b/src/share/vm/utilities/align.hpp | 152 b/src/share/vm/utilities/bitMap.inline.hpp | 2 b/src/share/vm/utilities/globalDefinitions.hpp | 8 b/src/share/vm/utilities/globalDefinitions_gcc.hpp | 11 b/src/share/vm/utilities/globalDefinitions_sparcWorks.hpp | 4 b/src/share/vm/utilities/globalDefinitions_visCPP.hpp | 12 b/src/share/vm/utilities/globalDefinitions_xlc.hpp | 2 b/src/share/vm/utilities/growableArray.hpp | 42 b/src/share/vm/utilities/macros.hpp | 14 b/src/share/vm/utilities/ostream.cpp | 65 b/src/share/vm/utilities/ostream.hpp | 4 b/src/share/vm/utilities/ticks.cpp | 122 b/src/share/vm/utilities/ticks.hpp | 308 + b/src/share/vm/utilities/vmError.cpp | 12 b/test/runtime/EnableTracing/TestEnableTracing.java | 11 b/test/testlibrary/whitebox/sun/hotspot/WhiteBox.java | 11 463 files changed, 46861 insertions(+), 3661 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer 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 https://keybase.io/gnu_andrew From shade at redhat.com Tue May 5 09:38:06 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Tue, 5 May 2020 11:38:06 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b01 Upstream Sync In-Reply-To: References: Message-ID: <70151c3f-4a75-71e3-8274-d02afa47788e@redhat.com> On 5/5/20 7:39 AM, Andrew John Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u252-b01/corba/merge.changeset Looks trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jaxws/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/jdk/merge.changeset Huge JFR merge, looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/hotspot/merge.changeset Huge JFR merge. Not sure about this change: diff --git a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp --- a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp @@ -33,7 +33,7 @@ #include "runtime/thread.inline.hpp" #include "runtime/timer.hpp" #include "utilities/ostream.hpp" -#include "utilities/ticks.inline.hpp" +#include "utilities/ticks.hpp" It looks to me that .inline.hpp is always safe to include instead of .hpp. Changing it the other way around may introduce build failures? Otherwise looks fine. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/langtools/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/nashorn/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b01/root/merge.changeset Looks good. > Ok to push? Apart from the Shenandoah include question, the whole bunch looks good. -- Thanks, -Aleksey From aph at redhat.com Tue May 5 11:32:35 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 May 2020 12:32:35 +0100 Subject: [aarch64-port-dev ] AArch64: Neoverse N1 atomic operations and -moutline-atomics Message-ID: <3a5e43e7-2039-8574-7470-5827267fb88d@redhat.com> Seen here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956418 It looks like there's a Neoverse N1 processor "feature" that leads to severe performance differences between atomic operations using the atomic memory instructions (e.g.CAS) and those using Exclusive Loads and Stores (e.g. LDAXR and STLXR.) The latter can be much slower in some cases. Therefore, if we want to avoid severe performance degradation we have to use atomic memory instructions on Neoverse N1 processors. This has caused some interesting problems for the authors of libgcc and glibc, which are statically compiled and do not generate code depending on the processor in use, as we do in generated code in HotSpot. The solution, which no-one likes very much, is to get GCC to generate subroutine calls for all atomic memory operations. The called routines look like this: __aarch64_cas4_relax: <+0>: adrp x16, 0x420000 <__aarch64_have_lse_atomics> <+4>: ldrb w16, [x16, :lo12:__aarch64_have_lse_atomics] <+8>: cbz w16, 0x400584 <__aarch64_cas4_relax+20> <+12>: cas w0, w1, [x2] <+16>: ret <+20>: mov w16, w0 <+24>: ldxr w0, [x2] <+28>: cmp w0, w16 <+32>: b.ne 0x40059c <__aarch64_cas4_relax+44> <+36>: stxr w17, w1, [x2] <+40>: cbnz w17, 0x400588 <__aarch64_cas4_relax+24> <+44>: ret This is, as you can see, horrible, but but thankfully we don't have to change AArch64 HotSpot because we use GCC's atomic builtins everywhere in C++ code. All we'll have to do is compile HotSpot with a new GCC and we'll be done. However, we also generate atomic operations. Happily, for some time we have generated and used atomic memory instructions whenever possible, so we don't have to change that either. Yay! Go us. https://gcc.gnu.org/legacy-ml/gcc-patches/2019-09/msg01036.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 Tue May 5 11:40:54 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 5 May 2020 12:40:54 +0100 Subject: [aarch64-port-dev ] AArch64: Neoverse N1 atomic operations and -moutline-atomics In-Reply-To: <3a5e43e7-2039-8574-7470-5827267fb88d@redhat.com> References: <3a5e43e7-2039-8574-7470-5827267fb88d@redhat.com> Message-ID: On 5/5/20 12:32 PM, Andrew Haley wrote: > This is, as you can see, horrible, but but thankfully we don't have to > change AArch64 HotSpot because we use GCC's atomic builtins everywhere > in C++ code. All we'll have to do is compile HotSpot with a new GCC > and we'll be done. Having said that, we should fix the AArch64 HotSpot build so that we use the -moutline-atomics option whenever it's available. -- 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 gnu.andrew at redhat.com Wed May 6 00:40:43 2020 From: gnu.andrew at redhat.com (Andrew John Hughes) Date: Wed, 6 May 2020 01:40:43 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b01 Upstream Sync In-Reply-To: <70151c3f-4a75-71e3-8274-d02afa47788e@redhat.com> References: <70151c3f-4a75-71e3-8274-d02afa47788e@redhat.com> Message-ID: <3d9a2ee2-982f-f68b-2f45-260997303e36@redhat.com> On 05/05/2020 10:38, Aleksey Shipilev wrote: > On 5/5/20 7:39 AM, Andrew John Hughes wrote: snip... > > Not sure about this change: > > diff --git a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp > b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp > --- a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp > +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp > @@ -33,7 +33,7 @@ > #include "runtime/thread.inline.hpp" > #include "runtime/timer.hpp" > #include "utilities/ostream.hpp" > -#include "utilities/ticks.inline.hpp" > +#include "utilities/ticks.hpp" > > It looks to me that .inline.hpp is always safe to include instead of .hpp. Changing it the other way > around may introduce build failures? > > Otherwise looks fine. Not when it doesn't exist :-) With all the AArch64 changes, I forgot about this one which turned up on the local build. ticks.inline.hpp is removed by 8223147: "JFR Backport" and this same change is made there in the shared GC code e.g. https://hg.openjdk.java.net/jdk8u/jdk8u/hotspot/rev/b985cbb00e68#l113.7 -- Andrew :) Senior Free Java Software Engineer 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 https://keybase.io/gnu_andrew From ningsheng.jian at arm.com Wed May 6 06:35:06 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 6 May 2020 14:35:06 +0800 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> Message-ID: <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Hi Xin, Martin's review comments reminds me that we should worry about code size increase on AArch64 with your patch, given that the HaltNode will be generated in many cases now. Currently in AArch64 MacroAssembler::stop(), it will generate many register saving instructions by pusha() before calling to debug64(). But I think debug64() only uses the regs[] and pc arguments when ShowMessageBoxOnError is on. Maybe we should at least only do the saving and pc arg passing when ShowMessageBoxOnError is on in MacroAssembler::stop(), as what x86 does in macroAssembler_x86.cpp? Thanks, Ningsheng On 5/5/20 7:26 AM, Liu, Xin wrote: > Hi, Martin, > > Thank you to review it and build it on s390 and PPC! > > If I delete size(4) in ppc.ad, hotspot can work out the correct size of instruction chunk, can't it? > I found most of instructions in ppc.ad have size(xx), but there're a couple of exceptions: cacheWB & cacheWBPreSync. > > I think it should be in product hotspot. Here are my arguments. > 1. Crash reports of release build are more common. > Some customers even don't bother trying again with a debug build. > > Let me take the crash report on aarch64 as an example. I paste the comparison before and after. > https://bugs.openjdk.java.net/browse/JDK-8230552?focusedCommentId=14334977&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14334977 > > Without stop(_halt_reason), what we know is "there's a bug in C2-generated code". If the method is big, which is very likely because of inlining, it's easy to get lost. > > I feel it's more helpful with the patch. We can locate which HaltNode it is by searching _halt_reason in codebase. > Hopefully, we can find the culprit method from "Compilation events". > > 2. HaltNode is rarely generated and will be removed if it's dead. > IMHO, the semantic of that Node is "halt". If It remains after optimizer or lowering to mach-nodes, something wrong and unrecoverable happened in the compilers. After we fix the compiler bug, it should be gone. That's is too say, it shouldn't cause any problem about code size in ideal cases. > > In reality, I observe that a HaltNode always follows the uncommon_trap call. Christian also observed that in JDK-8022574. > Isn't uncommon trap a one-way ticket for all architectures? I feel the control flow never returns after uncommon_trap, why do we generate a HaltNode after that? Nevertheless, it's a separated issue. > > Let me make another revision to fix PPC and I found that sparc.ad is gonna gone. > > Thanks, > --lx > > > ?On 5/4/20, 1:47 PM, "Doerr, Martin" wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi lx, > > the size attribute is wrong on PPC64 (stop is larger than 4 Bytes). S390 builds fine. > I've only run the build. No tests. > > Should this feature be debug-only? > Do we want the lengthy code emitted in product build? > > Best regards, > Martin > > > > -----Original Message----- > > From: hotspot-compiler-dev > bounces at openjdk.java.net> On Behalf Of Liu, Xin > > Sent: Donnerstag, 30. April 2020 06:03 > > To: hotspot-compiler-dev at openjdk.java.net > > Subject: RFR(XS): Provide information when hitting a HaltNode for > > architectures other than x86 > > > > Hi, > > > > Could you review this small patch? It unifies codegen of HaltNode for other > > architectures. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8230552 > > Webrev: https://cr.openjdk.java.net/~xliu/8230552/00/webrev/ > > > > I tested on aarch64. It generates the same crash report as x86_64 when it > > does hit HaltNode. Halt reason is displayed. I paste report on the JBS. > > I ran hotspot:tier1 on aarch64 fastdebug build. It passed except for 3 > > relevant failures[1]. > > > > I plan to do that on aarch64 only, but it?s trivial on other architectures, so I > > bravely modified them all. May I invite s390, SPARC arm32 maintainers take a > > look at it? > > If it goes through the review, I hope a sponsor can help me to push the > > submit repo and see if it works. > > > > [1] those 3 tests failed on aarch64 with/without my changes. > > gc/shenandoah/mxbeans/TestChurnNotifications.java#id2 > > gc/shenandoah/mxbeans/TestChurnNotifications.java#id1 > > gc/shenandoah/mxbeans/TestPauseNotifications.java#id1 > > > > thanks, > > -lx > > > > From xxinliu at amazon.com Wed May 6 07:25:18 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 6 May 2020 07:25:18 +0000 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: ?On 5/5/20, 11:35 PM, "Ningsheng Jian" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Xin, Martin's review comments reminds me that we should worry about code size increase on AArch64 with your patch, given that the HaltNode will be generated in many cases now. > Yes, I inspected aarch64's stop() too. HaltNode will increase from 1 instruction to 7 instructions. I acknowledge that code size is a big issue for both aarch64 and ppc. I agree with Martin, so I'd like to work on JDK-8022574 first. I think It's feasible. I have 2 ideas. 1) get rid of the HaltNode after the callnode of uncommon_trap. 2) give that special HaltNode a mark, so codegen can skip stop() for it. Currently in AArch64 MacroAssembler::stop(), it will generate many register saving instructions by pusha() before calling to debug64(). But I think debug64() only uses the regs[] and pc arguments when ShowMessageBoxOnError is on. Maybe we should at least only do the saving and pc arg passing when ShowMessageBoxOnError is on in MacroAssembler::stop(), as what x86 does in macroAssembler_x86.cpp? Thanks, Ningsheng > It makes sense, I will add if (ShowMessageBoxOnError) when I come back to this issue. Thanks, --lx On 5/5/20 7:26 AM, Liu, Xin wrote: > Hi, Martin, > > Thank you to review it and build it on s390 and PPC! > > If I delete size(4) in ppc.ad, hotspot can work out the correct size of instruction chunk, can't it? > I found most of instructions in ppc.ad have size(xx), but there're a couple of exceptions: cacheWB & cacheWBPreSync. > > I think it should be in product hotspot. Here are my arguments. > 1. Crash reports of release build are more common. > Some customers even don't bother trying again with a debug build. > > Let me take the crash report on aarch64 as an example. I paste the comparison before and after. > https://bugs.openjdk.java.net/browse/JDK-8230552?focusedCommentId=14334977&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14334977 > > Without stop(_halt_reason), what we know is "there's a bug in C2-generated code". If the method is big, which is very likely because of inlining, it's easy to get lost. > > I feel it's more helpful with the patch. We can locate which HaltNode it is by searching _halt_reason in codebase. > Hopefully, we can find the culprit method from "Compilation events". > > 2. HaltNode is rarely generated and will be removed if it's dead. > IMHO, the semantic of that Node is "halt". If It remains after optimizer or lowering to mach-nodes, something wrong and unrecoverable happened in the compilers. After we fix the compiler bug, it should be gone. That's is too say, it shouldn't cause any problem about code size in ideal cases. > > In reality, I observe that a HaltNode always follows the uncommon_trap call. Christian also observed that in JDK-8022574. > Isn't uncommon trap a one-way ticket for all architectures? I feel the control flow never returns after uncommon_trap, why do we generate a HaltNode after that? Nevertheless, it's a separated issue. > > Let me make another revision to fix PPC and I found that sparc.ad is gonna gone. > > Thanks, > --lx > > > On 5/4/20, 1:47 PM, "Doerr, Martin" wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi lx, > > the size attribute is wrong on PPC64 (stop is larger than 4 Bytes). S390 builds fine. > I've only run the build. No tests. > > Should this feature be debug-only? > Do we want the lengthy code emitted in product build? > > Best regards, > Martin > > > > -----Original Message----- > > From: hotspot-compiler-dev > bounces at openjdk.java.net> On Behalf Of Liu, Xin > > Sent: Donnerstag, 30. April 2020 06:03 > > To: hotspot-compiler-dev at openjdk.java.net > > Subject: RFR(XS): Provide information when hitting a HaltNode for > > architectures other than x86 > > > > Hi, > > > > Could you review this small patch? It unifies codegen of HaltNode for other > > architectures. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8230552 > > Webrev: https://cr.openjdk.java.net/~xliu/8230552/00/webrev/ > > > > I tested on aarch64. It generates the same crash report as x86_64 when it > > does hit HaltNode. Halt reason is displayed. I paste report on the JBS. > > I ran hotspot:tier1 on aarch64 fastdebug build. It passed except for 3 > > relevant failures[1]. > > > > I plan to do that on aarch64 only, but it?s trivial on other architectures, so I > > bravely modified them all. May I invite s390, SPARC arm32 maintainers take a > > look at it? > > If it goes through the review, I hope a sponsor can help me to push the > > submit repo and see if it works. > > > > [1] those 3 tests failed on aarch64 with/without my changes. > > gc/shenandoah/mxbeans/TestChurnNotifications.java#id2 > > gc/shenandoah/mxbeans/TestChurnNotifications.java#id1 > > gc/shenandoah/mxbeans/TestPauseNotifications.java#id1 > > > > thanks, > > -lx > > > > From christian.hagedorn at oracle.com Wed May 6 07:26:57 2020 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 6 May 2020 09:26:57 +0200 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: <6f0ed258-8fad-43df-60cb-3281397ddf9b@oracle.com> Hi Ningsheng On 06.05.20 08:35, Ningsheng Jian wrote: > Currently in AArch64 MacroAssembler::stop(), it will generate many > register saving instructions by pusha() before calling to debug64(). But > I think debug64() only uses the regs[] and pc arguments when > ShowMessageBoxOnError is on. Maybe we should at least only do the saving > and pc arg passing when ShowMessageBoxOnError is on in > MacroAssembler::stop(), as what x86 does in macroAssembler_x86.cpp? That's a good point. The change from Assembler::ud2() to MacroAssembler::stop() for a HaltNode in JDK-8225653 indeed resulted in some performance regressions for x86 since MacroAssembler::debug64() set up those arguments [1]. Especially, it called Assembler::pusha() for 64-bit which emits a move instructions for each of the 16 registers. Even though the code was never called, it had a bad influence on code cache space which had a bad influence on performance. The fix was to only do it if ShowMessageBoxOnError was set. So, I think it's indeed a good idea to also do the same for other architectures. Best regards, Christian [1] https://bugs.openjdk.java.net/browse/JDK-8231720 > > > Thanks, > Ningsheng > > On 5/5/20 7:26 AM, Liu, Xin wrote: >> Hi, Martin, >> >> Thank you to review it and build it on s390 and PPC! >> >> If I delete size(4) in ppc.ad,? hotspot can work out the correct size >> of instruction chunk, can't it? >> I found most of instructions in ppc.ad have size(xx), but there're a >> couple of exceptions:? cacheWB & cacheWBPreSync. >> >> I think it should be in product hotspot.? Here are my arguments. >> 1.? Crash reports of release build are more common. >> Some customers even don't bother trying again with a debug build. >> >> Let me take the crash report on aarch64 as an example. I paste the >> comparison before and after. >> https://bugs.openjdk.java.net/browse/JDK-8230552?focusedCommentId=14334977&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14334977 >> >> >> Without stop(_halt_reason), what we know is "there's a bug in >> C2-generated code". If the method is big,? which is very likely >> because of inlining, it's easy to get lost. >> >> I feel it's more helpful with the patch. We can locate which HaltNode >> it is by searching _halt_reason in codebase. >> Hopefully, we can find the culprit method from "Compilation events". >> >> 2. HaltNode is rarely generated and will be removed if it's dead. >> IMHO, the semantic of that Node is "halt". If It remains after >> optimizer or lowering to mach-nodes,? something wrong and >> unrecoverable happened in the compilers. After we fix the compiler >> bug,? it should be gone.? That's is too say, it shouldn't cause any >> problem about code size in ideal cases. >> >> In reality, I observe that a HaltNode always follows the uncommon_trap >> call.? Christian also observed that in JDK-8022574. >> Isn't uncommon trap a one-way ticket for all architectures? I feel the >> control flow never returns after uncommon_trap, why do we generate a >> HaltNode after that? Nevertheless, it's a separated issue. >> >> Let me make another revision to fix PPC and I found that sparc.ad is >> gonna gone. >> >> Thanks, >> --lx >> >> >> ?On 5/4/20, 1:47 PM, "Doerr, Martin" wrote: >> >> ???? CAUTION: This email originated from outside of the organization. >> Do not click links or open attachments unless you can confirm the >> sender and know the content is safe. >> >> >> >> ???? Hi lx, >> >> ???? the size attribute is wrong on PPC64 (stop is larger than 4 >> Bytes). S390 builds fine. >> ???? I've only run the build. No tests. >> >> ???? Should this feature be debug-only? >> ???? Do we want the lengthy code emitted in product build? >> >> ???? Best regards, >> ???? Martin >> >> >> ???? > -----Original Message----- >> ???? > From: hotspot-compiler-dev > ???? > bounces at openjdk.java.net> On Behalf Of Liu, Xin >> ???? > Sent: Donnerstag, 30. April 2020 06:03 >> ???? > To: hotspot-compiler-dev at openjdk.java.net >> ???? > Subject: RFR(XS): Provide information when hitting a HaltNode for >> ???? > architectures other than x86 >> ???? > >> ???? > Hi, >> ???? > >> ???? > Could you review this small patch?? It unifies codegen of >> HaltNode for other >> ???? > architectures. >> ???? > JBS: https://bugs.openjdk.java.net/browse/JDK-8230552 >> ???? > Webrev: https://cr.openjdk.java.net/~xliu/8230552/00/webrev/ >> ???? > >> ???? > I tested on aarch64.? It generates the same crash report as >> x86_64 when it >> ???? > does hit HaltNode.? Halt reason is displayed. I paste report on >> the JBS. >> ???? > I ran hotspot:tier1 on aarch64 fastdebug build.? It passed >> except for 3 >> ???? > relevant failures[1]. >> ???? > >> ???? > I plan to do that on aarch64 only, but it?s trivial on other >> architectures, so I >> ???? > bravely modified them all.? May I invite s390, SPARC arm32 >> maintainers take a >> ???? > look at it? >> ???? > If it goes through the review, I hope a sponsor can help me to >> push the >> ???? > submit repo and see if it works. >> ???? > >> ???? > [1] those 3 tests failed on aarch64 with/without my changes. >> ???? > gc/shenandoah/mxbeans/TestChurnNotifications.java#id2 >> ???? > gc/shenandoah/mxbeans/TestChurnNotifications.java#id1 >> ???? > gc/shenandoah/mxbeans/TestPauseNotifications.java#id1 >> ???? > >> ???? > thanks, >> ???? > -lx >> ???? > >> >> > From aph at redhat.com Wed May 6 08:19:26 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 May 2020 09:19:26 +0100 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: On 5/6/20 8:25 AM, Liu, Xin wrote: > Currently in AArch64 MacroAssembler::stop(), it will generate many > register saving instructions by pusha() before calling to debug64(). But > I think debug64() only uses the regs[] and pc arguments when > ShowMessageBoxOnError is on. Maybe we should at least only do the saving > and pc arg passing when ShowMessageBoxOnError is on in > MacroAssembler::stop(), as what x86 does in macroAssembler_x86.cpp? Maybe we should think about a better way to do it. All we have to do, after all, is put the reason into, say, r8, and execute a trap. We don't need to push and pop anything because the trap handler will do 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 aph at redhat.com Wed May 6 08:40:40 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 May 2020 09:40:40 +0100 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <6f0ed258-8fad-43df-60cb-3281397ddf9b@oracle.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <6f0ed258-8fad-43df-60cb-3281397ddf9b@oracle.com> Message-ID: <55cd970b-5a4e-4d1a-e17c-77289a412022@redhat.com> On 5/6/20 8:26 AM, Christian Hagedorn wrote: > The fix was to > only do it if ShowMessageBoxOnError was set. So, I think it's indeed a > good idea to also do the same for other architectures. Really? Can't we fix stop() so that it generates only a tiny little bit of code? I can do it 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 Yang.Zhang at arm.com Wed May 6 08:46:28 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Wed, 6 May 2020 08:46:28 +0000 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs Message-ID: Hi, Could you please help to review this patch? JBS: https://bugs.openjdk.java.net/browse/JDK-8243597 Webrev: http://cr.openjdk.java.net/~yzhang/8243597/webrev.00/ In JDK-8222074 [1], x86 enables auto vectorization for integer vector abs, and jtreg tests are also added. In this patch, the missing AbsVB/S/I/L support for AArch64 is added. Testing: Full jtreg test Vector API tests which cover vector abs Test case: public static void absvs(short[] a, short[] b, short[] c) { for (int i = 0; i < a.length; i++) { c[i] = (short)Math.abs((a[i] + b[i])); } } Assembly code generated by C2: 0x0000ffffaca3f3ac: ldr q17, [x16, #16] 0x0000ffffaca3f3b0: ldr q16, [x15, #16] 0x0000ffffaca3f3b4: add v16.8h, v16.8h, v17.8h 0x0000ffffaca3f3b8: abs v16.8h, v16.8h 0x0000ffffaca3f3c0: str q16, [x12, #16] Similar test cases for byte/int/long are also tested and NEON abs instruction is generated by C2. Performance: JMH tests are uploaded. http://cr.openjdk.java.net/~yzhang/8243597/TestScalar.java http://cr.openjdk.java.net/~yzhang/8243597/TestVect.java Vector abs: Before: Benchmark (size) Mode Cnt Score Error Units TestVect.testVectAbsVB 1024 avgt 5 1041.720 ? 2.606 us/op TestVect.testVectAbsVI 1024 avgt 5 659.788 ? 2.057 us/op TestVect.testVectAbsVL 1024 avgt 5 711.043 ? 5.489 us/op TestVect.testVectAbsVS 1024 avgt 5 659.157 ? 2.531 us/op After Benchmark (size) Mode Cnt Score Error Units TestVect.testVectAbsVB 1024 avgt 5 88.821 ? 1.886 us/op TestVect.testVectAbsVI 1024 avgt 5 199.081 ? 2.539 us/op TestVect.testVectAbsVL 1024 avgt 5 447.536 ? 1.195 us/op TestVect.testVectAbsVS 1024 avgt 5 119.172 ? 0.340 us/op Scalar abs: Before: Benchmark (size) Mode Cnt Score Error Units TestScalar.testAbsI 1024 avgt 5 3770.345 ? 6.760 us/op TestScalar.testAbsL 1024 avgt 5 3767.570 ? 9.097 us/op After: Benchmark (size) Mode Cnt Score Error Units TestScalar.testAbsI 1024 avgt 5 3141.312 ? 2.000 us/op TestScalar.testAbsL 1024 avgt 5 3103.143 ? 8.989 us/op [1] https://bugs.openjdk.java.net/browse/JDK-8222074 Regards Yang From shade at redhat.com Wed May 6 09:12:37 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 6 May 2020 11:12:37 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b01 Upstream Sync In-Reply-To: <3d9a2ee2-982f-f68b-2f45-260997303e36@redhat.com> References: <70151c3f-4a75-71e3-8274-d02afa47788e@redhat.com> <3d9a2ee2-982f-f68b-2f45-260997303e36@redhat.com> Message-ID: <9c3cc67f-0332-1c09-0de2-caecc2452c06@redhat.com> On 5/6/20 2:40 AM, Andrew John Hughes wrote: > On 05/05/2020 10:38, Aleksey Shipilev wrote: >> On 5/5/20 7:39 AM, Andrew John Hughes wrote: >> Not sure about this change: >> >> diff --git a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp >> b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp >> --- a/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp >> +++ b/src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp >> @@ -33,7 +33,7 @@ >> #include "runtime/thread.inline.hpp" >> #include "runtime/timer.hpp" >> #include "utilities/ostream.hpp" >> -#include "utilities/ticks.inline.hpp" >> +#include "utilities/ticks.hpp" >> >> It looks to me that .inline.hpp is always safe to include instead of .hpp. Changing it the other way >> around may introduce build failures? >> >> Otherwise looks fine. > > Not when it doesn't exist :-) Ah, okay then :D -- Thanks, -Aleksey From christian.hagedorn at oracle.com Wed May 6 09:14:16 2020 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Wed, 6 May 2020 11:14:16 +0200 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <55cd970b-5a4e-4d1a-e17c-77289a412022@redhat.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <6f0ed258-8fad-43df-60cb-3281397ddf9b@oracle.com> <55cd970b-5a4e-4d1a-e17c-77289a412022@redhat.com> Message-ID: <2c9c0c59-73cc-4c88-c568-deba5d73e4f5@oracle.com> Hi Andrew On 5/6/20 8:26 AM, Christian Hagedorn wrote >> [..] since MacroAssembler::debug64() set up those arguments [..] Sorry, I mixed that up. I meant that MacroAssembler::stop() on x86 emitted those additional instructions as arguments needed by debug64(). This was then guarded by ShowMessageBoxOnError to only emit the message argument for debug64() by default. On 06.05.20 10:40, Andrew Haley wrote: > On 5/6/20 8:26 AM, Christian Hagedorn wrote >> The fix was to >> only do it if ShowMessageBoxOnError was set. So, I think it's indeed a >> good idea to also do the same for other architectures. > > Really? Can't we fix stop() so that it generates only a tiny little bit > of code? I can do it if you like. This is probably what you've meant. I agree with you, the fewer instructions emitted by stop() the better. Best regards, Christian From ci_notify at linaro.org Wed May 6 14:16:47 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 6 May 2020 14:16:47 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 14 on AArch64 Message-ID: <1704794019.741.1588774607548.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/openjdk-jtreg-nightly-tests/summary/2020/126/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 5,773; fail: 45 Build 1: aarch64/2020/jan/30 pass: 5,773; fail: 45 Build 2: aarch64/2020/feb/06 pass: 5,773; fail: 46 Build 3: aarch64/2020/feb/09 pass: 5,775; fail: 44 Build 4: aarch64/2020/apr/07 pass: 5,781; fail: 45 Build 5: aarch64/2020/may/05 pass: 5,762; fail: 45 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 8,831; fail: 524; error: 18 Build 1: aarch64/2020/jan/30 pass: 8,839; fail: 518; error: 17 Build 2: aarch64/2020/feb/06 pass: 8,838; fail: 517; error: 18 Build 3: aarch64/2020/feb/09 pass: 8,832; fail: 523; error: 18 Build 4: aarch64/2020/apr/07 pass: 8,844; fail: 505; error: 20 Build 5: aarch64/2020/may/05 pass: 8,839; fail: 515; error: 18 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 4,031 Build 1: aarch64/2020/jan/30 pass: 4,031 Build 2: aarch64/2020/feb/03 pass: 4,031 Build 3: aarch64/2020/feb/06 pass: 4,031 Build 4: aarch64/2020/feb/09 pass: 4,031 Build 5: aarch64/2020/apr/07 pass: 4,031 Build 6: aarch64/2020/may/05 pass: 4,031 Previous results can be found here: http://openjdk.linaro.org/jdk14/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 8.14x Relative performance: Server critical-jOPS (nc): 9.58x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/023/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/037/results/ 2020-02-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/040/results/ 2020-04-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/098/results/ 2020-05-06 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/126/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/ From aph at redhat.com Wed May 6 14:38:23 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 May 2020 15:38:23 +0100 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <2c9c0c59-73cc-4c88-c568-deba5d73e4f5@oracle.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <6f0ed258-8fad-43df-60cb-3281397ddf9b@oracle.com> <55cd970b-5a4e-4d1a-e17c-77289a412022@redhat.com> <2c9c0c59-73cc-4c88-c568-deba5d73e4f5@oracle.com> Message-ID: <408cac5b-0151-b0cb-a1a2-5bce673e42b0@redhat.com> On 5/6/20 10:14 AM, Christian Hagedorn wrote: > On 06.05.20 10:40, Andrew Haley wrote: >> On 5/6/20 8:26 AM, Christian Hagedorn wrote >>> The fix was to >>> only do it if ShowMessageBoxOnError was set. So, I think it's indeed a >>> good idea to also do the same for other architectures. >> Really? Can't we fix stop() so that it generates only a tiny little bit >> of code? I can do it if you like. > This is probably what you've meant. I agree with you, the fewer > instructions emitted by stop() the better. ShowMessageBoxOnError is completely the wrong thing to use. I run in GDB all the time, and I want accurate error messages, and I never use ShowMessageBoxOnError. If we get this right we can have near-zero code expansion, and keep this on at all times, even in production. -- 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 derekw at marvell.com Wed May 6 15:47:24 2020 From: derekw at marvell.com (Derek White) Date: Wed, 6 May 2020 15:47:24 +0000 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: Hi Ningsheng, Completely agree! I've had a patch related to this on the back-burner for a long time. If Andrew's trap version works out that would be good too. - Derek -----Original Message----- From: aarch64-port-dev On Behalf Of Ningsheng Jian Sent: Wednesday, May 6, 2020 2:35 AM To: Liu, Xin ; Doerr, Martin ; hotspot-compiler-dev at openjdk.java.net Cc: aarch64-port-dev at openjdk.java.net Subject: [EXT] Re: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 External Email ---------------------------------------------------------------------- Hi Xin, Martin's review comments reminds me that we should worry about code size increase on AArch64 with your patch, given that the HaltNode will be generated in many cases now. Currently in AArch64 MacroAssembler::stop(), it will generate many register saving instructions by pusha() before calling to debug64(). But I think debug64() only uses the regs[] and pc arguments when ShowMessageBoxOnError is on. Maybe we should at least only do the saving and pc arg passing when ShowMessageBoxOnError is on in MacroAssembler::stop(), as what x86 does in macroAssembler_x86.cpp? Thanks, Ningsheng On 5/5/20 7:26 AM, Liu, Xin wrote: > Hi, Martin, > > Thank you to review it and build it on s390 and PPC! > > If I delete size(4) in ppc.ad, hotspot can work out the correct size of instruction chunk, can't it? > I found most of instructions in ppc.ad have size(xx), but there're a couple of exceptions: cacheWB & cacheWBPreSync. > > I think it should be in product hotspot. Here are my arguments. > 1. Crash reports of release build are more common. > Some customers even don't bother trying again with a debug build. > > Let me take the crash report on aarch64 as an example. I paste the comparison before and after. > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java > .net_browse_JDK-2D8230552-3FfocusedCommentId-3D14334977-26page-3Dcom.a > tlassian.jira.plugin.system.issuetabpanels-253Acomment-2Dtabpanel-23co > mment-2D14334977&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X > 2mceubwzCNjT0vmaU97kngYUJk&m=ujj4giApNOH52SLyvnUxdMe0pO3gqYFlEMayYqVsr > F8&s=JrGUdO8_yl-2ls3pMr2Hir7yzy2gZM7H8lS2_t5fA0s&e= > > Without stop(_halt_reason), what we know is "there's a bug in C2-generated code". If the method is big, which is very likely because of inlining, it's easy to get lost. > > I feel it's more helpful with the patch. We can locate which HaltNode it is by searching _halt_reason in codebase. > Hopefully, we can find the culprit method from "Compilation events". > > 2. HaltNode is rarely generated and will be removed if it's dead. > IMHO, the semantic of that Node is "halt". If It remains after optimizer or lowering to mach-nodes, something wrong and unrecoverable happened in the compilers. After we fix the compiler bug, it should be gone. That's is too say, it shouldn't cause any problem about code size in ideal cases. > > In reality, I observe that a HaltNode always follows the uncommon_trap call. Christian also observed that in JDK-8022574. > Isn't uncommon trap a one-way ticket for all architectures? I feel the control flow never returns after uncommon_trap, why do we generate a HaltNode after that? Nevertheless, it's a separated issue. > > Let me make another revision to fix PPC and I found that sparc.ad is gonna gone. > > Thanks, > --lx > > > ?On 5/4/20, 1:47 PM, "Doerr, Martin" wrote: > > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. > > > > Hi lx, > > the size attribute is wrong on PPC64 (stop is larger than 4 Bytes). S390 builds fine. > I've only run the build. No tests. > > Should this feature be debug-only? > Do we want the lengthy code emitted in product build? > > Best regards, > Martin > > > > -----Original Message----- > > From: hotspot-compiler-dev > bounces at openjdk.java.net> On Behalf Of Liu, Xin > > Sent: Donnerstag, 30. April 2020 06:03 > > To: hotspot-compiler-dev at openjdk.java.net > > Subject: RFR(XS): Provide information when hitting a HaltNode for > > architectures other than x86 > > > > Hi, > > > > Could you review this small patch? It unifies codegen of HaltNode for other > > architectures. > > JBS: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8230552&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=ujj4giApNOH52SLyvnUxdMe0pO3gqYFlEMayYqVsrF8&s=zinJ3kLMxMM1eJWAyO_HiZjVJKBkUExIO5iXPveTnCw&e= > > Webrev: https://urldefense.proofpoint.com/v2/url?u=https-3A__cr.openjdk.java.net_-7Exliu_8230552_00_webrev_&d=DwIDaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=ujj4giApNOH52SLyvnUxdMe0pO3gqYFlEMayYqVsrF8&s=AjLxZxLJhyWpV8dTOwQF2ePi83mjS2Omp7jjk0ib-DM&e= > > > > I tested on aarch64. It generates the same crash report as x86_64 when it > > does hit HaltNode. Halt reason is displayed. I paste report on the JBS. > > I ran hotspot:tier1 on aarch64 fastdebug build. It passed except for 3 > > relevant failures[1]. > > > > I plan to do that on aarch64 only, but it?s trivial on other architectures, so I > > bravely modified them all. May I invite s390, SPARC arm32 maintainers take a > > look at it? > > If it goes through the review, I hope a sponsor can help me to push the > > submit repo and see if it works. > > > > [1] those 3 tests failed on aarch64 with/without my changes. > > gc/shenandoah/mxbeans/TestChurnNotifications.java#id2 > > gc/shenandoah/mxbeans/TestChurnNotifications.java#id1 > > gc/shenandoah/mxbeans/TestPauseNotifications.java#id1 > > > > thanks, > > -lx > > > > From aph at redhat.com Wed May 6 17:27:58 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 6 May 2020 18:27:58 +0100 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> On 5/6/20 4:47 PM, Derek White wrote: > If Andrew's trap version works out that would be good too. Oh, uh, I guess I'll have to write it, then. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Wed May 6 20:45:35 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 6 May 2020 20:45:35 +0000 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: Hi Andrew, I had also thought about using a trap based implementation. Maybe it makes sense to add a feature to shared code for that. E.g. we could emit an illegal instruction (which raises SIGILL) followed by some kind of index into a descriptor array. PPC64 would also benefit from a more compact solution. Best regards, Martin > -----Original Message----- > From: Andrew Haley > Sent: Mittwoch, 6. Mai 2020 19:28 > To: Derek White ; Ningsheng Jian > ; Liu, Xin ; Doerr, Martin > ; hotspot-compiler-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [EXT] Re: [aarch64-port-dev ] RFR(XS): Provide information > when hitting a HaltNode for architectures other than x86 > > On 5/6/20 4:47 PM, Derek White wrote: > > If Andrew's trap version works out that would be good too. > > Oh, uh, I guess I'll have to write it, then. :-) > > -- > 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 May 6 21:21:05 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 6 May 2020 21:21:05 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <2098421836.799.1588800066699.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2020/127/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/17 pass: 837; fail: 9; error: 1 Build 1: aarch64/2019/aug/22 pass: 837; fail: 9; error: 1 Build 2: aarch64/2019/sep/10 pass: 838; fail: 13; error: 1 Build 3: aarch64/2019/sep/21 pass: 838; fail: 13; error: 1 Build 4: aarch64/2019/nov/02 pass: 843; fail: 9; error: 1 Build 5: aarch64/2019/nov/14 pass: 843; fail: 9; error: 1 Build 6: aarch64/2019/dec/16 pass: 843; fail: 10; error: 1 Build 7: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 Build 8: aarch64/2019/dec/19 pass: 846; fail: 10; error: 2 Build 9: aarch64/2019/dec/21 pass: 848; fail: 10; error: 2 Build 10: aarch64/2020/jan/09 pass: 848; fail: 10; error: 1 Build 11: aarch64/2020/jan/11 pass: 848; fail: 10; error: 1 Build 12: aarch64/2020/jan/20 pass: 848; fail: 10; error: 1 Build 13: aarch64/2020/jan/25 pass: 848; fail: 10; error: 1 Build 14: aarch64/2020/may/06 pass: 885; fail: 12; error: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/22 pass: 5,945; fail: 279; error: 20 Build 1: aarch64/2019/sep/10 pass: 5,951; fail: 273; error: 23 Build 2: aarch64/2019/sep/21 pass: 5,964; fail: 261; error: 22 Build 3: aarch64/2019/nov/02 pass: 5,956; fail: 278; error: 18 Build 4: aarch64/2019/nov/14 pass: 5,956; fail: 275; error: 21 Build 5: aarch64/2019/dec/16 pass: 5,964; fail: 267; error: 21 Build 6: aarch64/2019/dec/17 pass: 5,963; fail: 267; error: 22 Build 7: aarch64/2019/dec/19 pass: 5,959; fail: 272; error: 21 Build 8: aarch64/2019/dec/21 pass: 5,970; fail: 262; error: 21 Build 9: aarch64/2020/jan/09 pass: 5,963; fail: 276; error: 20 Build 10: aarch64/2020/jan/11 pass: 5,959; fail: 279; error: 21 Build 11: aarch64/2020/jan/20 pass: 5,987; fail: 256; error: 24 Build 12: aarch64/2020/jan/25 pass: 5,962; fail: 285; error: 22 Build 13: aarch64/2020/feb/03 pass: 5,976; fail: 278; error: 19 Build 14: aarch64/2020/may/06 pass: 5,998; fail: 281; error: 21 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/17 pass: 3,116; fail: 2 Build 1: aarch64/2019/aug/22 pass: 3,116; fail: 2 Build 2: aarch64/2019/sep/10 pass: 3,116; fail: 2 Build 3: aarch64/2019/sep/21 pass: 3,116; fail: 2 Build 4: aarch64/2019/nov/02 pass: 3,116; fail: 2 Build 5: aarch64/2019/nov/14 pass: 3,116; fail: 2 Build 6: aarch64/2019/dec/16 pass: 3,116; fail: 2 Build 7: aarch64/2019/dec/17 pass: 3,117; fail: 2 Build 8: aarch64/2019/dec/19 pass: 3,117; fail: 2 Build 9: aarch64/2019/dec/21 pass: 3,117; fail: 2 Build 10: aarch64/2020/jan/09 pass: 3,117; fail: 2 Build 11: aarch64/2020/jan/11 pass: 3,117; fail: 2 Build 12: aarch64/2020/jan/20 pass: 3,117; fail: 2 Build 13: aarch64/2020/jan/25 pass: 3,117; fail: 2 Build 14: aarch64/2020/may/06 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.05x Relative performance: Server critical-jOPS (nc): 9.01x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 178.67 Server 178.67 / Server 2014-04-01 (71.00): 2.52x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-17 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/229/results/ 2019-08-23 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/234/results/ 2019-09-11 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/253/results/ 2019-09-22 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/264/results/ 2019-11-02 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/306/results/ 2019-11-15 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/318/results/ 2019-12-16 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/350/results/ 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ 2019-12-19 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/353/results/ 2019-12-22 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/355/results/ 2020-01-09 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/009/results/ 2020-01-11 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/011/results/ 2020-01-20 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/020/results/ 2020-01-25 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/025/results/ 2020-05-06 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/127/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From christian.hagedorn at oracle.com Thu May 7 08:11:32 2020 From: christian.hagedorn at oracle.com (Christian Hagedorn) Date: Thu, 7 May 2020 10:11:32 +0200 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <408cac5b-0151-b0cb-a1a2-5bce673e42b0@redhat.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <6f0ed258-8fad-43df-60cb-3281397ddf9b@oracle.com> <55cd970b-5a4e-4d1a-e17c-77289a412022@redhat.com> <2c9c0c59-73cc-4c88-c568-deba5d73e4f5@oracle.com> <408cac5b-0151-b0cb-a1a2-5bce673e42b0@redhat.com> Message-ID: <680dafab-56ee-043b-4555-a092c67c4b57@oracle.com> Hi Andrew On 06.05.20 16:38, Andrew Haley wrote: > On 5/6/20 10:14 AM, Christian Hagedorn wrote: >> On 06.05.20 10:40, Andrew Haley wrote: >>> On 5/6/20 8:26 AM, Christian Hagedorn wrote >>>> The fix was to >>>> only do it if ShowMessageBoxOnError was set. So, I think it's indeed a >>>> good idea to also do the same for other architectures. >>> Really? Can't we fix stop() so that it generates only a tiny little bit >>> of code? I can do it if you like. >> This is probably what you've meant. I agree with you, the fewer >> instructions emitted by stop() the better. > > ShowMessageBoxOnError is completely the wrong thing to use. I run > in GDB all the time, and I want accurate error messages, and I never > use ShowMessageBoxOnError. If we get this right we can have near-zero > code expansion, and keep this on at all times, even in production. I like your suggestion of a trap solution as suggested in the other thread. This sounds much better than the original fix for HaltNodes on x86 which only had in mind to adapt stop() in such a way that it works with debug64() while avoiding the unnecessary regs[] and pc argument when ShowMessageBoxOnError is not set (which is probably not used much anyways). If a trap approach could get rid of all of it and emit minimal code, we should go for it. Best regards, Christian From aph at redhat.com Thu May 7 08:11:41 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 09:11:41 +0100 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: On 5/6/20 9:45 PM, Doerr, Martin wrote: > I had also thought about using a trap based implementation. > Maybe it makes sense to add a feature to shared code for that. > E.g. we could emit an illegal instruction (which raises SIGILL) followed by some kind of index into a descriptor array. > PPC64 would also benefit from a more compact solution. Most of the stuff to handle this would be in the back end, I would have thought. I'll have a look. -- 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 May 7 09:14:00 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 10:14:00 +0100 Subject: [aarch64-port-dev ] RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered Message-ID: This is Nick Gasson's patch, stripped of the changes that were due to adaptations made because of later changes to MacroAssembler. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8217368.patch -- 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 May 7 09:14:23 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 10:14:23 +0100 Subject: [aarch64-port-dev ] RFR: Backport: 8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 Message-ID: The final patch for this bug was very complex and did not apply to jdk8u. This patch is almost identical to Dmitrij Pochepko's first proposal, so he still gets the credit. It is also far, far simpler than the final patch. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8216989.patch -- 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 May 7 09:14:29 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 10:14:29 +0100 Subject: [aarch64-port-dev ] RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command Message-ID: This is a somewhat cut-down and adjusted version of Nick Gasson's patch, which also rearranged code elsewhere. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8209413.patch -- 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 May 7 09:53:24 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 10:53:24 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered In-Reply-To: References: Message-ID: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> Forwarding to also include jdk8u-dev -------- Forwarded Message -------- Subject: [aarch64-port-dev ] RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered Date: Thu, 7 May 2020 10:14:00 +0100 From: Andrew Haley To: aarch64-port-dev at openjdk.java.net This is Nick Gasson's patch, stripped of the changes that were due to adaptations made because of later changes to MacroAssembler. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8217368.patch -- 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 May 7 09:53:59 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 10:53:59 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 In-Reply-To: References: Message-ID: Forwarding to also include jdk8u-dev -------- Forwarded Message -------- Subject: [aarch64-port-dev ] RFR: Backport: 8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 Date: Thu, 7 May 2020 10:14:23 +0100 From: Andrew Haley To: aarch64-port-dev at openjdk.java.net The final patch for this bug was very complex and did not apply to jdk8u. This patch is almost identical to Dmitrij Pochepko's first proposal, so he still gets the credit. It is also far, far simpler than the final patch. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8216989.patch -- 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 May 7 09:54:31 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 10:54:31 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: Message-ID: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> Forwarding to also include jdk8u-dev -------- Forwarded Message -------- Subject: [aarch64-port-dev ] RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command Date: Thu, 7 May 2020 10:14:29 +0100 From: Andrew Haley To: aarch64-port-dev at openjdk.java.net This is a somewhat cut-down and adjusted version of Nick Gasson's patch, which also rearranged code elsewhere. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8209413.patch -- 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 May 7 10:32:02 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 11:32:02 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered In-Reply-To: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> References: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> Message-ID: <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> On 07/05/2020 10:53, Andrew Dinn wrote: > This is Nick Gasson's patch, stripped of the changes that were due > to adaptations made because of later changes to MacroAssembler. > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8217368.patch Well, this patch looks fine apart from the small detail that the line at which it is to be applied is wrong. I managed to apply it but only with a suitable fuzz: "Hunk #1 succeeded at 3333 with fuzz 1 (offset -1506 lines)." Is the line number disparity there because this is /literally/ the original jdk13u patch Nick suggested on the mail thread? Or is there something else I have missed? That aside I entirely agree that this is the correct /backport/ patch. It precisely fixes the original problem without pulling in all the gubbins that was approrpiate upstream in order to remove technical debt. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Thu May 7 10:43:01 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 11:43:01 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 In-Reply-To: References: Message-ID: On 07/05/2020 10:53, Andrew Dinn wrote: > Forwarding to also include jdk8u-dev > > > -------- Forwarded Message -------- > Subject: [aarch64-port-dev ] RFR: Backport: 8216989: > CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does > not check for zero length on AARCH64 > Date: Thu, 7 May 2020 10:14:23 +0100 > From: Andrew Haley > To: aarch64-port-dev at openjdk.java.net > > The final patch for this bug was very complex and did not apply to > jdk8u. This patch is almost identical to Dmitrij Pochepko's first > proposal, so he still gets the credit. It is also far, far simpler > than the final patch. > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8216989.patch Hmm, indeed, unbelievably simpler and yet still correct. All those layers of abstraction the upstream patch had to work its way through must be buying us something though, surely? ;-> regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From adinn at redhat.com Thu May 7 10:47:43 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 11:47:43 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> References: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> Message-ID: On 07/05/2020 10:54, Andrew Dinn wrote: > Forwarding to also include jdk8u-dev > > > -------- Forwarded Message -------- > Subject: [aarch64-port-dev ] RFR: Backport: 8209413: AArch64: NPE in > clhsdb jstack command > Date: Thu, 7 May 2020 10:14:29 +0100 > From: Andrew Haley > To: aarch64-port-dev at openjdk.java.net > > This is a somewhat cut-down and adjusted version of Nick Gasson's > patch, which also rearranged code elsewhere. > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8209413.patch Something is definitely wrong here as I cannot apply this patch without failures: [adinn at localhost jdk8u-aarch64-shenandoah]$ hg -R hotspot/ patch 8209413.patch.diff applying 8209413.patch.diff patching file src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp Hunk #1 FAILED at 0 1 out of 3 hunks FAILED -- saving rejects to file src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp.rej patching file src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp Hunk #2 FAILED at 1119 1 out of 2 hunks FAILED -- saving rejects to file src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp.rej abort: patch failed to apply Am I doing something wrong? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From nick.gasson at arm.com Thu May 7 10:48:25 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Thu, 07 May 2020 18:48:25 +0800 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered In-Reply-To: <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> References: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> Message-ID: <85mu6kaume.fsf@arm.com> On 05/07/20 18:32 pm, Andrew Dinn wrote: > > That aside I entirely agree that this is the correct /backport/ patch. > It precisely fixes the original problem without pulling in all the > gubbins that was approrpiate upstream in order to remove technical debt. > Looks right to me too. It's the same as an earlier version of the patch before it was changed to use cmpxchg. -- Thanks, Nick From aph at redhat.com Thu May 7 12:53:33 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 13:53:33 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8217368: AArch64: C2 recursive stack locking optimisation not triggered In-Reply-To: <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> References: <326135b9-01c2-b999-1b20-ed582b4d8216@redhat.com> <7710f9f8-4656-8532-1be2-c3cba3f631da@redhat.com> Message-ID: On 5/7/20 11:32 AM, Andrew Dinn wrote: > On 07/05/2020 10:53, Andrew Dinn wrote: >> This is Nick Gasson's patch, stripped of the changes that were due >> to adaptations made because of later changes to MacroAssembler. >> >> http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8217368.patch > Well, this patch looks fine apart from the small detail that the line at > which it is to be applied is wrong. I managed to apply it but only with > a suitable fuzz: > > "Hunk #1 succeeded at 3333 with fuzz 1 (offset -1506 lines)." > > Is the line number disparity there because this is /literally/ the > original jdk13u patch Nick suggested on the mail thread? Or is there > something else I have missed? I have no idea! I'm surprised that hg import looks 1506 lines away. > That aside I entirely agree that this is the correct /backport/ patch. > It precisely fixes the original problem without pulling in all the > gubbins that was approrpiate upstream in order to remove technical debt. 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 aph at redhat.com Thu May 7 12:54:09 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 13:54:09 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 In-Reply-To: References: Message-ID: <504a1c4e-c685-da94-c7c0-3ca742dbec94@redhat.com> On 5/7/20 11:43 AM, Andrew Dinn wrote: > On 07/05/2020 10:53, Andrew Dinn wrote: >> Forwarding to also include jdk8u-dev >> >> >> -------- Forwarded Message -------- >> Subject: [aarch64-port-dev ] RFR: Backport: 8216989: >> CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does >> not check for zero length on AARCH64 >> Date: Thu, 7 May 2020 10:14:23 +0100 >> From: Andrew Haley >> To: aarch64-port-dev at openjdk.java.net >> >> The final patch for this bug was very complex and did not apply to >> jdk8u. This patch is almost identical to Dmitrij Pochepko's first >> proposal, so he still gets the credit. It is also far, far simpler >> than the final patch. >> >> http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8216989.patch > Hmm, indeed, unbelievably simpler and yet still correct. All those > layers of abstraction the upstream patch had to work its way through > must be buying us something though, surely? ;-> You might like to think so; I couldn't possibly comment. -- 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 May 7 13:38:56 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 14:38:56 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> Message-ID: On 5/7/20 11:47 AM, Andrew Dinn wrote: > > [adinn at localhost jdk8u-aarch64-shenandoah]$ hg -R hotspot/ patch > 8209413.patch.diff > applying 8209413.patch.diff > patching file src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp > Hunk #1 FAILED at 0 > 1 out of 3 hunks FAILED -- saving rejects to file > src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp.rej > patching file src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp > Hunk #2 FAILED at 1119 > 1 out of 2 hunks FAILED -- saving rejects to file > src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp.rej > abort: patch failed to apply > > Am I doing something wrong? No. The machine I was using is unstable, and the third time I logged back in to restart the tests I, er, seem to have used an old tree. Argh. http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8209413-v2.patch > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill > P.S. If you start your sig with the line "-- " it'll make life easier for people who reply to you. :-) -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Thu May 7 14:21:19 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 7 May 2020 16:21:19 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: Message-ID: Hi all, please take a look at the third iteration of this change: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ Changes in this version: - at the request of Coleen (sorry I did not see your post earlier) I removed all platform dependent files and put the platform dependent coding back to metaspace.cpp and compressedOops.cpp to ease the review pain. I used plain platform defines though (#ifdef AARCH64) instead of hiding them behind another macro to make things clearer. Note that I still intent to put this code away into the platform corners but will do so in a follow up RFE. - I reinstated, in a fashion, the special handling of reservations on Windows. On all platforms we reserve address space to map the archive files in with a subsequent mapping operation. However, on Windows, we cannot use MapViewOfFile() into an existing mapping. So I remove the mapping again before mapping the archives - see comment in code for details. All CI tests at SAP run through without problems, including on Win64 and aarch64, but I would be happy if others were to run test too. Thank you, Thomas On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe wrote: > Hi all, > > Could I have reviews for the following proposal of reworking cds/class > space reservation? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ > > (Many thanks to Ioi Lam for so patiently explaining CDS internals to me, > and to Andrew Haley and Nick Gasson for help with aarch64!) > > Reservation of the compressed class space is needlessly complicated and > has some minor issues. It can be simplified and made clearer. > > The complexity stems from the fact that this area lives at the > intersection of two to three sub systems, depending on how one counts. > Metaspace, CDS, and the platform which may or may not its own view of how > to reserve class space. And this code has been growing organically over > time. > > One small example: > > ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t > alignment, > bool large_pages, char > *requested_addr, > bool use_requested_addr) > > which I spent hours decoding, resulting in a very confused mail to > hs-runtime and aarch64-port-dev [2]. > > This patch attempts to simplify cds and metaspace setup a bit; to comment > implicit knowledge which is not immediately clear; to cleanly abstract > platform concerns like optimized class space placement; and to disentangle > cds from metaspace to solve issues which may bite us later with Elastic > Metaspace [4]. > > --- > > The main change is the reworked reservation mechanism. This is based on > Ioi's proposal [5]. > > When reserving class space, three things must happen: > > 1) reservation of the space obviously. If cds is active that space must be > in the vicinity of cds archives to be covered by compressed class pointer > encoding. > 2) setting up the internal Metaspace structures atop of that space > 3) setting up compressed class pointer encoding. > > In its current form, Metaspace may or may not do some or all of that in > one function > (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace > metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, > it will reserve the space for Metaspace and hand it in, otherwise it will > create it itself. > > When discussing this in [2], Ioi proposed to move the reservation of the > class space completely out of Metaspace and make it a responsibility of the > caller always. This would reduce some complexity, and this patch follows > the proposal. > > I removed > Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace > metaspace_rs, char* requested_addr, address cds_base); and all its sub > functions. > > (1) now has to always be done outside - a ReservedSpace for class space > has to be provided by the caller. However, Metaspace now offers a utility > function for reserving space at a "nice" location, and explicitly doing > nothing else: > > ReservedSpace > Metaspace::reserve_address_space_for_compressed_classes(size_t size); > > this function can be redefined on a platform level for platform optimized > reservation, see below for details. > > (2) is taken care of by a new function, > Metaspace::initialize_class_space(ReservedSpace rs) > > (3) is taken care of a new function CompressedKlassPointers::initialize(), > see below for details. > > > So, class space now is set up three explicit steps: > > - First, reserve a suitable space by however means you want. For > convenience you may use > Metaspace::reserve_address_space_for_compressed_classes(), or you may roll > your own reservation. > - Next, tell Metaspace to use that range as backing storage for class > space: Metaspace::initialize_class_space(ReservedSpace rs) > - Finally, set up encoding. Encoding is independent from the concept of a > ReservedSpace, it just gets an address range, see below for details. > > Separating these steps and moving them out of the responsibility of > Metaspace makes this whole thing more flexible; it also removes unnecessary > knowledge (e.g. Metaspace does not need to know anything about either ccp > encoding or cds). > > --- > > How it comes together: > > If CDS is off, we just reserve a space using > Metaspace::reserve_address_space_for_compressed_classes(), initialize it > with Metaspace::initialize_class_space(ReservedSpace rs), then set up > compressed class pointer encoding covering the range of this class space. > > If CDS is on (dump time), we reserve large 4G space, either at > SharedBaseAddress or using > Metaspace::reserve_address_space_for_compressed_classes(); we then split > that into 3G archive space and 1G class space; we set up that space with > Metaspace as class space; then we set up compressed class pointer encoding > covering both archive space and cds. > > If CDS is on (run time), we reserve a large space, split it into archive > space (large enough to hold both archives) and class space, then basically > proceed as above. > > Note that this is almost exactly how things worked before (modulo some > minor fixes, e.g. alignment issues), only the code is reformed and made > more explicit. > > --- > > I moved compressed class pointer setup over to CompressedKlassPointers and > changed the interface: > > -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace > metaspace_rs, address cds_base) > +void CompressedKlassPointers::initialize(address addr, size_t len); > > Instead of feeding it a single ReservedSpace, which is supposed to > represent class space, and an optional alternate base if cds is on, now we > give it just an numeric address range. That range marks the limits to where > Klass structures are to be expected, and is the implicit promise that > outside that range no Klass structures will exist, so encoding has to cover > only this range. > > This range may contain just the class space; or class space+cds; or > whatever allocation scheme we come up with in the future. Encoding does not > really care how the memory is organized as long as the input range covers > all possible Klass locations. That way we remove knowledge about class > space/cds from compressed class pointer encoding. > > Moving it away from metaspace.cpp into the CompressedKlassPointers class > also mirrors CompressedOops::initialize(). > > --- > > I renamed _narrow_klass_range to just _range, because strictly speaking > this is the range un-narrow Klass pointers can have. > > As for the implementation of CompressedKlassPointers::initialize(address > addr, size_t len), I mimicked very closely what happened before, so there > should be almost no differences. Since "almost no differences" sounds scary > :) here are the differences: > > - When CDS is active (dump or run time) we now always, unconditionally, > set the encoding range to 4G. This fixes a theoretical bug discussed on > aarch64-port-dev [1]. > > - When CDS is not active, we set the encoding range to the minimum > required length. Before, it was left at its default value of 4G. > > Both differences only affect aarch64, since they are currently the only > one using the range field in CompressedKlassPointers. > > I wanted to add an assert somewhere to test encoding of the very last > address of the CompressedKlassPointers range, again to prevent errors like > [3]. But I did not come up with a good place for this assert which would > cover also the encoding done by C1/C2. > > For the same reason I thought about introducing a mode where Klass > structures would be allocated in reverse order, starting at the end of the > ccs, but again left it out as too big a change. > > --- > > OS abstraction: platforms may have restrictions of what constitutes a > valid compressed class pointer encoding base. Or if not, they may have at > least preferences. There was logic like this in metaspace.cpp, which I > removed and cleanly factored out into platform dependent files, giving each > platform the option to add special logic. > > These are two new methods: > > - bool CompressedKlassPointers::is_valid_base(address p) > > to let the platform tell you whether it considers p to be a valid encoding > base. The only platform having these restrictions currently is aarch64. > > - ReservedSpace > Metaspace::reserve_address_space_for_compressed_classes(size_t size); > > this hands over the process of allocating a range suitable for compressed > class pointer encoding to the platform. Most platforms will allocate just > anywhere, but some platforms may have a better strategy (e.g. trying low > memory first, trying only correctly aligned addresses and so on). > > Beforehand, this coding existed in a similar form in metaspace.cpp for > aarch64 and AIX. For now, I left the AIX part out - it seems only half > done, and I want to check further if we even need it, if yes why not on > Linux ppc, and C1 does not seem to support anything other than base+offset > with shift either, but I may be mistaken. > > These two methods should give the platform enough control to implement > their own scheme for optimized class space placement without bothering any > shared code about it. > > Note about the form, I introduced two new platform dependent files, > "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about > this but this seems to be what we generally do in hotspot, right? > > --- > > Metaspace reserve alignment vs cds alignment > > CDS was using Metaspace reserve alignment for CDS internal purposes. I > guess this was just a copy paste issue. It never caused problems since > Metaspace reserve alignment == page size, but that is not true anymore in > the upcoming Elastic Metaspace where reserve alignment will be larger. This > causes a number of issues. > > I separated those two cleanly. CDS now uses os::vm_allocation_granularity. > Metaspace::reserve_alignment is only used in those two places where it is > needed, when CDS creates the address space for class space on behalf of the > Metaspace. > > --- > > Windows special handling in CDS > > To simplify coding I removed the windows specific handling which left out > reservation of the archive. This was needed because windows cannot mmap > files into reserved regions. But fallback code exists in filemap.cpp for > this case which just reads in the region instead of mapping it. > > Should that turn out to be a performance problem, I will reinstate the > feature. But a simpler way would be reserve the archive and later just > before mmapping the archive file to release the archive space. That would > not only be simpler but give us the best guarantee that that address space > is actually available. But I'd be happy to leave that part out completely > if we do not see any performance problems on windows x64. > > --- > > NMT cannot deal with spaces which are split. This problem manifests in > that bookkeeping for class space is done under "Shared Classes", not > "Classes" as it should. This problem exists today too at dump time and > randomly at run time. But since I simplified the reservation, this problem > now shows up always, whether or not we map at the SharedBaseAddress. > While I could work around this problem, I'd prefer this problem to be > solved at the core, and NMT to have an option to recognize reservation > splits. So I'd rather not put a workaround for this into the patch but > leave it for fixing as a separate issue. I opened this issue to track it > [6]. > > --- > > Jtreg tests: > > I expanded the CompressedOops/CompressedClassPointers.java. I also > extended them to Windows. The tests now optionally omit strict class space > placement tests, since these tests heavily depend on ASLR and were the > reason they were excluded on Windows. However I think even without checking > for class space placement they make sense, just to see that the VM comes up > and lives with the many different settings we can run in. > > --- > > Tests: > > - I ran the patch through Oracles submit repo > - I ran tests manually for aarch64, zero, linux 32bit and windows x64 > - The whole battery of nightly tests at SAP, including ppc, ppcle and > aarch64, unfortunately excluding windows because of unrelated errors. > Windows x64 tests will be redone tonight. > > > Thank you, > > Thomas > > [1] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html > [2] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html > [3] https://bugs.openjdk.java.net/browse/JDK-8193266 > [4] https://bugs.openjdk.java.net/browse/JDK-8221173 > [5] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html > [6] https://bugs.openjdk.java.net/browse/JDK-8243535 > > From adinn at redhat.com Thu May 7 14:27:51 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 7 May 2020 15:27:51 +0100 Subject: [aarch64-port-dev ] Fwd: RFR: Backport: 8209413: AArch64: NPE in clhsdb jstack command In-Reply-To: References: <605d5685-1bc0-d236-95f6-2ce1e8ea04b0@redhat.com> Message-ID: <0c7bb876-9992-1827-0924-9418da52545f@redhat.com> On 07/05/2020 14:38, Andrew Haley wrote: > No. The machine I was using is unstable, and the third time I logged back > in to restart the tests I, er, seem to have used an old tree. Argh. > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8209413-v2.patch Ok, so I note that you chose to ignore the updates to stubGenerator_aarch64.cpp and macroAssembler_aarch64.cpp. I assume not because they are incorrect but because they were not needed to fix this specific issue? That seems entirely reasonable to me. The changes you have chosen to apply all look good. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Thu May 7 17:48:29 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 7 May 2020 18:48:29 +0100 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: On 5/7/20 9:11 AM, Andrew Haley wrote: > On 5/6/20 9:45 PM, Doerr, Martin wrote: >> I had also thought about using a trap based implementation. >> Maybe it makes sense to add a feature to shared code for that. >> E.g. we could emit an illegal instruction (which raises SIGILL) followed by some kind of index into a descriptor array. >> PPC64 would also benefit from a more compact solution. > > Most of the stuff to handle this would be in the back end, I would > have thought. I'll have a look. This attached patch does the job for Linux/AArch64. It has two disadvantages: 1. It corrupts R8, rscratch1. This doesn't really matter for AArch64. 2. If we execute stop() in the context of a signal handler triggered by another trap, we'll have a double fault and the OS will kill our process. 1 is fixable by pushing rscratch1 before executing the trap. I'm not sure it's worth doing; I'd rather have a tiny implementation of stop() that we can use guilt-free in release code. I don't think 2 is an issue because we never call out to generated code from a signal handler. -- 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 -------------- next part -------------- diff -r ed406ec0c5cd src/hotspot/cpu/aarch64/aarch64.ad --- a/src/hotspot/cpu/aarch64/aarch64.ad Thu May 07 14:44:09 2020 +0100 +++ b/src/hotspot/cpu/aarch64/aarch64.ad Thu May 07 13:47:05 2020 -0400 @@ -15333,9 +15333,7 @@ format %{ "ShouldNotReachHere" %} ins_encode %{ - // +1 so NativeInstruction::is_sigill_zombie_not_entrant() doesn't - // return true - __ dpcs1(0xdead + 1); + __ stop(_halt_reason); %} ins_pipe(pipe_class_default); diff -r ed406ec0c5cd src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp --- a/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Thu May 07 14:44:09 2020 +0100 +++ b/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp Thu May 07 13:47:05 2020 -0400 @@ -2223,14 +2223,8 @@ } void MacroAssembler::stop(const char* msg) { - address ip = pc(); - pusha(); - mov(c_rarg0, (address)msg); - mov(c_rarg1, (address)ip); - mov(c_rarg2, sp); - mov(c_rarg3, CAST_FROM_FN_PTR(address, MacroAssembler::debug64)); - blr(c_rarg3); - hlt(0); + mov(rscratch1, (address)msg); + dpcs1(0xdeaf); } void MacroAssembler::warn(const char* msg) { @@ -2610,7 +2604,7 @@ BREAKPOINT; } } - fatal("DEBUG MESSAGE: %s", msg); + report_fatal(__FILE__, __LINE__, "DEBUG MESSAGE: %s", msg); } void MacroAssembler::push_call_clobbered_registers() { diff -r ed406ec0c5cd src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp --- a/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp Thu May 07 14:44:09 2020 +0100 +++ b/src/hotspot/cpu/aarch64/nativeInst_aarch64.cpp Thu May 07 13:47:05 2020 -0400 @@ -458,6 +458,10 @@ return uint_at(0) == 0xd4bbd5a1; // dcps1 #0xdead } +bool NativeInstruction::is_stop() { + return uint_at(0) == 0xd4bbd5e1; // dcps1 #0xdeaf +} + void NativeIllegalInstruction::insert(address code_pos) { *(juint*)code_pos = 0xd4bbd5a1; // dcps1 #0xdead } diff -r ed406ec0c5cd src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp --- a/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp Thu May 07 14:44:09 2020 +0100 +++ b/src/hotspot/cpu/aarch64/nativeInst_aarch64.hpp Thu May 07 13:47:05 2020 -0400 @@ -76,6 +76,7 @@ bool is_movz(); bool is_movk(); bool is_sigill_zombie_not_entrant(); + bool is_stop(); protected: address addr_at(int offset) const { return address(this) + offset; } diff -r ed406ec0c5cd src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp --- a/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp Thu May 07 14:44:09 2020 +0100 +++ b/src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp Thu May 07 13:47:05 2020 -0400 @@ -381,6 +381,10 @@ } stub = SharedRuntime::handle_unsafe_access(thread, next_pc); } + } else if (sig == SIGILL && nativeInstruction_at(pc)->is_stop()) { + int64_t *regs = (int64_t *)(uc->uc_mcontext.regs); + MacroAssembler::debug64((char*)regs[rscratch1->encoding()], + (int64_t)pc, regs); } else From ci_notify at linaro.org Thu May 7 19:31:59 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 7 May 2020 19:31:59 +0000 (UTC) Subject: [aarch64-port-dev ] Linaro OpenJDK AArch64 jdk/jdk build 3550 Fixed Message-ID: <890845742.913.1588879919755.JavaMail.javamailuser@localhost> OpenJDK AArch64 jdk/jdk build status is Fixed Build details - https://ci.linaro.org/job/jdkX-ci-build/3550/ Changes - aefimov: 868fe697bad4c7bf5651345e79cb9f7e1df465d2 - test/jdk/com/sun/jndi/ldap/NamingExceptionMessageTest.java - src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java - src/java.naming/share/classes/com/sun/jndi/ldap/LdapRequest.java --"8062947: Fix exception message to correctly represent LDAP connection failure Reviewed-by: dfuchs, xyin, vtewari " phh: 73c3fe1eefd7bbd8f7cd9b656f24fb57b3565e33 - make/autoconf/boot-jdk.m4 --"8244248: boot-jdk.m4 captures the version line using regex Summary: Use awk instead of head Reviewed-by: ihse, erikj Contributed-by: xxinliu at amazon.com " Build output - Creating jdk.incubator.jpackage.jmod Creating jdk.internal.ed.jmod Creating jdk.internal.jvmstat.jmod Creating jdk.internal.le.jmod Creating jdk.internal.opt.jmod Creating jdk.internal.vm.ci.jmod Creating jdk.internal.vm.compiler.management.jmod Creating jdk.internal.vm.compiler.jmod Creating jdk.jartool.jmod Creating jdk.javadoc.jmod Creating jdk.jcmd.jmod Creating jdk.jconsole.jmod Creating jdk.jdeps.jmod Creating jdk.jdi.jmodCreating jdk.jdwp.agent.jmod Creating jdk.jfr.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.net.jmod Creating jdk.naming.rmi.jmod Creating jdk.nio.mapmode.jmod Creating jdk.sctp.jmod Creating jdk.security.jgss.jmod Creating jdk.security.auth.jmod Creating jdk.unsupported.jmod Creating jdk.xml.dom.jmod Creating jdk.unsupported.desktop.jmod Creating jdk.zipfs.jmod Creating interim jimage 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/Font2DTest/Font2DTest.jar Creating support/demos/image/jfc/FileChooserDemo/FileChooserDemo.jar [0.036s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.052s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.052s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/Metalworks/Metalworks.jar [0.092s][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 [0.044s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.042s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.083s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.064s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/Stylepad/Stylepad.jar Creating support/demos/image/jfc/TableExample/TableExample.jar Creating support/demos/image/jfc/SampleTree/SampleTree.jar [0.053s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.015s][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 [0.068s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/TransparentRuler/TransparentRuler.jar [0.012s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/SwingSet2/SwingSet2.jar [0.052s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.021s][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.067s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.012s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Compiling 1 files for CLASSLIST_JAR[0.044s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/demos/image/jfc/J2Ddemo/J2Ddemo.jar [0.069s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.074s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 Creating support/classlist.jar [0.010s][error][cds] Unable to map CDS archive -- os::vm_allocation_granularity() expected: 65536 actual: 4096 [0.055s][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 Stopping sjavac server Finished building target 'images' in configuration '/home/buildslave/workspace/jdkX-ci-build/build' From gnu.andrew at redhat.com Thu May 7 19:42:44 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 07 May 2020 19:42:44 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 15 new changesets Message-ID: <202005071942.047JgiK9004068@aojmv0008.oracle.com> Changeset: ecde297a64f2 Author: andrew Date: 2020-04-14 19:55 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/ecde297a64f2 Added tag jdk8u252-ga for changeset 343c4ea489d5 ! .hgtags Changeset: e86abea74e04 Author: apetushkov Date: 2019-08-13 14:32 +0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/e86abea74e04 8223147: JFR Backport 8199712: Flight Recorder 8203346: JFR: Inconsistent signature of jfr_add_string_constant 8195817: JFR.stop should require name of recording 8195818: JFR.start should increase autogenerated name by one 8195819: Remove recording=x from jcmd JFR.check output 8203921: JFR thread sampling is missing fixes from JDK-8194552 8203929: Limit amount of data for JFR.dump 8203664: JFR start failure after AppCDS archive created with JFR StartFlightRecording 8003209: JFR events for network utilization 8207392: [PPC64] Implement JFR profiling Summary: Backport JFR from JDK11. Initial integration Reviewed-by: neugens ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 8d1426351f61 Author: neugens Date: 2020-02-17 18:08 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/8d1426351f61 8238590: Enable JFR by default during compilation in 8u Summary: Set the configure enable-jfr flag to true by default. Reviewed-by: andrew ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 147fe4a4c0ec Author: apetushkov Date: 2020-02-24 20:09 +0300 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/147fe4a4c0ec 8239479: minimal1 and zero builds are failing Summary: Disable JFR by default when minimal or zero VM build is requested Reviewed-by: andrew ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 0a7e81cbb5f7 Author: andrew Date: 2020-03-03 12:57 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/0a7e81cbb5f7 Merge ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 10b17658c758 Author: andrew Date: 2020-03-03 13:21 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/10b17658c758 8240375: Disable JFR by default for July 2020 release Reviewed-by: aph, neugens ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: f0ce75a706cb Author: andrew Date: 2020-03-03 13:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/f0ce75a706cb Added tag jdk8u262-b00 for changeset 62c9a2725c6c ! .hgtags Changeset: 8985babef9d9 Author: andrew Date: 2020-03-24 21:50 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/8985babef9d9 Merge ! .hgtags Changeset: d210e2dde238 Author: andrew Date: 2020-03-27 19:14 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/d210e2dde238 Merge ! .hgtags Changeset: e74aae3e716e Author: zgu Date: 2019-12-16 11:22 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/e74aae3e716e 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 Reviewed-by: serb ! .hgignore ! THIRD_PARTY_README Changeset: b187cde4b6f0 Author: clanger Date: 2020-04-21 12:00 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/b187cde4b6f0 8241902: AIX Build broken after integration of JDK-8223147 (JFR Backport) Reviewed-by: mdoerr, apetushkov ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: 3cf8935494d6 Author: andrew Date: 2020-04-24 03:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/3cf8935494d6 Merge ! .hgtags ! common/autoconf/generated-configure.sh Changeset: 041cb274be12 Author: andrew Date: 2020-04-24 04:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/041cb274be12 Added tag jdk8u262-b01 for changeset 3cf8935494d6 ! .hgtags Changeset: c55a600d3c28 Author: andrew Date: 2020-04-26 18:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/c55a600d3c28 Merge jdk8u262-b01 ! .hgtags ! THIRD_PARTY_README ! common/autoconf/generated-configure.sh ! common/autoconf/jdk-options.m4 Changeset: a81bab074ce9 Author: andrew Date: 2020-04-26 19:27 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/a81bab074ce9 Added tag aarch64-shenandoah-jdk8u262-b01 for changeset c55a600d3c28 ! .hgtags From gnu.andrew at redhat.com Thu May 7 19:43:11 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 07 May 2020 19:43:11 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxp: 10 new changesets Message-ID: <202005071943.047JhBrc004363@aojmv0008.oracle.com> Changeset: 500d6087cd1f Author: andrew Date: 2020-04-14 19:55 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/500d6087cd1f Added tag jdk8u252-ga for changeset 8476d78dc695 ! .hgtags Changeset: c5a7c1258fb0 Author: andrew Date: 2020-03-03 13:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/c5a7c1258fb0 Added tag jdk8u262-b00 for changeset 49013f07f606 ! .hgtags Changeset: b4ed224a1951 Author: andrew Date: 2020-03-24 21:50 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/b4ed224a1951 Merge ! .hgtags Changeset: 4b626df7c4ff Author: andrew Date: 2020-03-27 19:14 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/4b626df7c4ff Merge ! .hgtags Changeset: fd53cad7ff93 Author: zgu Date: 2019-12-16 11:27 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/fd53cad7ff93 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 Reviewed-by: serb ! THIRD_PARTY_README Changeset: 1b6fd3c61b05 Author: joehw Date: 2018-11-30 12:41 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/1b6fd3c61b05 8213734: SAXParser.parse(File, ..) does not close resources when Exception occurs. Reviewed-by: lancea ! src/com/sun/org/apache/xerces/internal/impl/XMLEntityManager.java Changeset: a3dcb5ebdf43 Author: andrew Date: 2020-04-24 03:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/a3dcb5ebdf43 Merge ! .hgtags Changeset: 7fe6268fe876 Author: andrew Date: 2020-04-24 04:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/7fe6268fe876 Added tag jdk8u262-b01 for changeset a3dcb5ebdf43 ! .hgtags Changeset: f1286213999b Author: andrew Date: 2020-04-26 18:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/f1286213999b Merge jdk8u262-b01 ! .hgtags ! THIRD_PARTY_README Changeset: c5f3ee4cd599 Author: andrew Date: 2020-04-26 19:27 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxp/rev/c5f3ee4cd599 Added tag aarch64-shenandoah-jdk8u262-b01 for changeset f1286213999b ! .hgtags From gnu.andrew at redhat.com Thu May 7 19:42:58 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 07 May 2020 19:42:58 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 9 new changesets Message-ID: <202005071942.047Jgw6D004226@aojmv0008.oracle.com> Changeset: 3da649db678e Author: andrew Date: 2020-04-14 19:55 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/3da649db678e Added tag jdk8u252-ga for changeset 9340b3be1b47 ! .hgtags Changeset: a4541b2a58eb Author: andrew Date: 2020-03-03 13:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/a4541b2a58eb Added tag jdk8u262-b00 for changeset b2c092b72c7c ! .hgtags Changeset: a0eab50cd355 Author: andrew Date: 2020-03-24 21:50 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/a0eab50cd355 Merge ! .hgtags Changeset: a38e61c49b56 Author: andrew Date: 2020-03-27 19:14 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/a38e61c49b56 Merge ! .hgtags Changeset: dd72530c1255 Author: zgu Date: 2019-12-16 11:26 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/dd72530c1255 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 Reviewed-by: serb ! THIRD_PARTY_README Changeset: 644b5985f127 Author: andrew Date: 2020-04-24 03:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/644b5985f127 Merge ! .hgtags Changeset: 43f43d941996 Author: andrew Date: 2020-04-24 04:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/43f43d941996 Added tag jdk8u262-b01 for changeset 644b5985f127 ! .hgtags Changeset: 46c9e5f5501a Author: andrew Date: 2020-04-26 18:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/46c9e5f5501a Merge jdk8u262-b01 ! .hgtags ! THIRD_PARTY_README Changeset: 2f4e96e75c0e Author: andrew Date: 2020-04-26 19:27 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/2f4e96e75c0e Added tag aarch64-shenandoah-jdk8u262-b01 for changeset 46c9e5f5501a ! .hgtags From gnu.andrew at redhat.com Thu May 7 19:43:22 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 07 May 2020 19:43:22 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 9 new changesets Message-ID: <202005071943.047JhM5L004505@aojmv0008.oracle.com> Changeset: c772bca13e9f Author: andrew Date: 2020-04-14 19:55 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/c772bca13e9f Added tag jdk8u252-ga for changeset b012193ff452 ! .hgtags Changeset: 78b398816044 Author: andrew Date: 2020-03-03 13:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/78b398816044 Added tag jdk8u262-b00 for changeset fac54385ffea ! .hgtags Changeset: 587f4d12fccf Author: andrew Date: 2020-03-24 21:50 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/587f4d12fccf Merge ! .hgtags Changeset: 9502e19d094c Author: andrew Date: 2020-03-27 19:14 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/9502e19d094c Merge ! .hgtags Changeset: 6c74f9af22a0 Author: zgu Date: 2019-12-16 11:27 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/6c74f9af22a0 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 Reviewed-by: serb ! THIRD_PARTY_README Changeset: c8d9ee347858 Author: andrew Date: 2020-04-24 03:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/c8d9ee347858 Merge ! .hgtags Changeset: ed881d547a80 Author: andrew Date: 2020-04-24 04:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/ed881d547a80 Added tag jdk8u262-b01 for changeset c8d9ee347858 ! .hgtags Changeset: 9faf0521fd87 Author: andrew Date: 2020-04-26 18:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/9faf0521fd87 Merge jdk8u262-b01 ! .hgtags ! THIRD_PARTY_README Changeset: 6b8e4be6b209 Author: andrew Date: 2020-04-26 19:27 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/6b8e4be6b209 Added tag aarch64-shenandoah-jdk8u262-b01 for changeset 9faf0521fd87 ! .hgtags From gnu.andrew at redhat.com Thu May 7 19:43:44 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Thu, 07 May 2020 19:43:44 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 9 new changesets Message-ID: <202005071943.047JhiG6004701@aojmv0008.oracle.com> Changeset: 13db9dac5175 Author: andrew Date: 2020-04-14 19:55 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/13db9dac5175 Added tag jdk8u252-ga for changeset 2f5ad880fd33 ! .hgtags Changeset: 8e4e6650c365 Author: andrew Date: 2020-03-03 13:22 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/8e4e6650c365 Added tag jdk8u262-b00 for changeset 7fd34fff5c44 ! .hgtags Changeset: 1461ea1799cd Author: andrew Date: 2020-03-24 21:50 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/1461ea1799cd Merge ! .hgtags Changeset: c923db271618 Author: andrew Date: 2020-03-27 19:15 +0000 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/c923db271618 Merge ! .hgtags Changeset: 5d64c42ac763 Author: zgu Date: 2019-12-16 11:28 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/5d64c42ac763 8210776: Upgrade X Window System 6.8.2 to the latest XWD 1.0.7 Reviewed-by: serb ! THIRD_PARTY_README Changeset: 0a00f1ccd7e9 Author: andrew Date: 2020-04-24 03:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/0a00f1ccd7e9 Merge ! .hgtags Changeset: 60239ecaefa2 Author: andrew Date: 2020-04-24 04:22 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/60239ecaefa2 Added tag jdk8u262-b01 for changeset 0a00f1ccd7e9 ! .hgtags Changeset: bf721abfa9f8 Author: andrew Date: 2020-04-26 18:58 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/bf721abfa9f8 Merge jdk8u262-b01 ! .hgtags ! THIRD_PARTY_README Changeset: 6b0f55ff6a74 Author: andrew Date: 2020-04-26 19:27 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/6b0f55ff6a74 Added tag aarch64-shenandoah-jdk8u262-b01 for changeset bf721abfa9f8 ! .hgtags From Xiaohong.Gong at arm.com Fri May 8 03:38:34 2020 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Fri, 8 May 2020 03:38:34 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option Message-ID: Hi, Please help to review this patch which obsoletes the product flag "-XX:UseBarrierssForVolatile" and its related code: Webrev: http://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ JBS: https://bugs.openjdk.java.net/browse/JDK-8243339 https://bugs.openjdk.java.net/browse/JDK-8243456 (CSR) As described in the CSR, using "-XX:+UseBarriersForVolatile" might have memory consistent issue like that mentioned in [1]. It needs more effort to fix the issue and maintain the memory consistency in future. Since "ldar/stlr" has worked well for a long time, and so does "ldaxr/stlxr" for unsafe atomics, we'd better simplify things by removing this option and the alternative implementation for the volatile access. Since its only one signifcant usage on a kind of CPU would also like to be removed (See [2]), it can work well without this option. So we directly obsolete this option and remove the code, rather than deprecate it firstly. Besides obsoleting this option, this patch also removes an AArch64 CPU feature "CPU_DMB_ATOMICS" together. It is a workaround while not an AArch64 official feature, which is not required anymore (See [2]). [1] https://bugs.openjdk.java.net/browse/JDK-8241137 [2] https://bugs.openjdk.java.net/browse/JDK-8242469 Testing: Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core, langtools::tier1 JCStress: tests-all Thanks, Xiaohong Gong From thomas.stuefe at gmail.com Fri May 8 07:33:35 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 8 May 2020 09:33:35 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> Message-ID: Hi Ioi, thanks for taking the time to look at this! On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: > Hi Thomas, > > I am running your patch in out CI pipeline now. Some comments: > > [1] Do we still need to use _class_space_list? It looks like we just have > a single range. Is _class_space_list->current_virtual_space() always the > same VS? > > if (_class_space_list != NULL) { > address base = > (address)_class_space_list->current_virtual_space()->bottom(); > address top = base + compressed_class_space_size(); > st->print("Compressed class space mapped at: " PTR_FORMAT "-" > PTR_FORMAT ", size: " SIZE_FORMAT, > p2i(base), p2i(top), top - base); > > Yes it is. Has been bugging me for years too. With ccs, the VirtualSpaceList is degenerated and only contains one node. It still makes some sense code wise. But maybe VirtualSpace*List* is a misnomer. It also ties in into the question whether Metaspace reservations should be able to grow on demand. Oracle folks I talk to tend to say yes. I personally think the "Metaspace is infinite don't worry" meme was broken since ccs was a thing, since CompressedClassSpaceSize is an absolute limit already. I may tweak and simplify the code a bit with Elastic Metaspace. Maybe, as you say, with ccs we can get rid of VirtualSpaceList and deal with the range directly. Have to check. [2] Does JDK-8243535 exist with the current jdk/jdk repo? > > // This does currently not work because rs may be the result of a split > operation > // and NMT seems not to be able to handle splits. > // See JDK-8243535. > // MemTracker::record_virtual_memory_type((address)rs.base(), mtClass); > > Yes. It shows up more rarely. With this patch, it will show up always. I had a conversation with Zhengyu about this. I think there may be workarounds, like removing the original mapping in NMT and replacing it with the two new ones for archive and ccs. But it seems iffy, I'd rather have this fixed in NMT. I also think it is not such a big deal, but if you think otherwise, I can integrate a workaround into this patch. > > [3] I think this can be put in header file. > > bool Metaspace::class_space_is_initialized() { > return _class_space_list != NULL; > } > > Will do. > [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is the > reason for the > gap in the following chart: > > // We do this by reserving space for the ccs behind the archives. Note > however that > // ccs follows a different alignment (Metaspace::reserve_alignment), > so there may > // be a gap between ccs and cds. > // We use a similar layout at runtime, see > reserve_address_space_for_archives(). > // > // +-- SharedBaseAddress (default = > 0x800000000) > // v > // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > // | Heap | Archive | | MC | RW | RO | [gap] | class > space | > // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > // |<-- MaxHeapSize -->| |<-- UnscaledClassSpaceMax = 4GB -->| > > No, nothing to do with large pages. CCS does not have large pages. The gap can result from different alignment rules between metaspace and cds. With Elastic Metaspace, metaspace reservations will be aligned to 4M. So, ccs will have to start at a 4M aligned border. > > _reserve_alignment is determined here: > > void Metaspace::ergo_initialize() { > if (DumpSharedSpaces) { > // Using large pages when dumping the shared archive is currently not > implemented. > FLAG_SET_ERGO(UseLargePagesInMetaspace, false); > } > > size_t page_size = os::vm_page_size(); > if (UseLargePages && UseLargePagesInMetaspace) { > page_size = os::large_page_size(); > } > > _commit_alignment = page_size; > _reserve_alignment = MAX2(page_size, > (size_t)os::vm_allocation_granularity()); > > But when CDS is enabled, the RS is reserved without large pages, so it > should be possible to incrementally commit the CCS using just > os::vm_allocation_granularity(). > > Absolutely. CCS does not use large pages for that reason. As I wrote, this is about the new reservation granularity of 4M. > [5] I see the aarch64 code in > Metaspace::reserve_address_space_for_compressed_classes has been changed. > Is this necessary for this RFE, or is it a separate improvement that can be > done in a different RFE? > Well, it had to be changed somewhat, since the prototype differs. I swapped Metaspace::reserve_preferred_space() for Metaspace::reserve_address_space_for_compressed_classes(), which follows a somewhat different protocol. That aside, the functionality for AARCH64 should be as unchanged as possible. I removed the AIX specific coding, since it was subtly wrong, but that's fine since we are AIX/ppc maintainers. > [6] For AARCH64, should we skip the part that reserves it right above the > heap? Or does AARCH64 always allocate the heap such that it's a preferable > address? > > Yes and yes :) We do skip that for aarch64 (at least if the address is wrong): 1157 // Try right above the Java heap... 1158 address base = align_up(CompressedOops::end(), Metaspace::reserve_alignment()); 1159 assert(base != NULL, "Sanity"); 1160 1161 const size_t size = align_up(CompressedClassSpaceSize, Metaspace::reserve_alignment()); 1162 if (CompressedKlassPointers::is_valid_base(base)) { 1163 rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* large */, (char*)base); 1164 } At 1162, we check if the attach address would be valid for this platform. If aarch64 says no, we won't reserve there but go straight to the "attach wherever you think is good" part. Which is implemented by Metaspace::reserve_address_space_for_compressed_classes(), which on aarch64 does search a suitable address. > // case (b) > ReservedSpace rs; > > // Try right above the Java heap... > address base = align_up(CompressedOops::end(), > Metaspace::reserve_alignment()); > assert(base != NULL, "Sanity"); > > const size_t size = align_up(CompressedClassSpaceSize, > Metaspace::reserve_alignment()); > if (CompressedKlassPointers::is_valid_base(base)) { > rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* > large */, (char*)base); > } > > // ...failing that, reserve anywhere, but let platform do optimized > placement: > if (!rs.is_reserved()) { > rs = Metaspace::reserve_address_space_for_compressed_classes(size); > } > > [7] argument.cpp checks this: > > if (UseSharedSpaces || DumpSharedSpaces) { > if > (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { > log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for > this platform, option will be ignored.", > p2i((address)SharedBaseAddress)); > FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); > } > } > > but initialize_dumptime_shared_and_meta_spaces aligns up the > SharedBaseAddress before doing the assert. > > void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { > assert(DumpSharedSpaces, "should be called for dump time only"); > > const size_t reserve_alignment = > MetaspaceShared::reserved_space_alignment(); > char* shared_base = (char*)align_up((char*)SharedBaseAddress, > reserve_alignment); > > #ifdef _LP64 > assert(CompressedKlassPointers::is_valid_base((address)shared_base), > "Sanity"); > > So theoretically shared_base may no longer be is_valid_base after the > align_up. It probably won't happen, but I think the code will be much > clearer tofirst to align_up, then check for is_valid_base and reset to > default, and finally assert. > > Okay, I'll change that. > [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the > following block can be simplified: > > if (!_shared_rs.is_reserved()) { > // Get a reserved space anywhere if attaching at the SharedBaseAddress > fails: > if (UseCompressedClassPointers) { > // If we need a compressed class space too, let the platform handle > the reservation. > _shared_rs = > Metaspace::reserve_address_space_for_compressed_classes(cds_total); > } else { > // anywhere is fine. > _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* > large */, (char*)NULL); > } > } > > ... if you change the declaration to: > > static ReservedSpace reserve_address_space_for_compressed_classes(size_t > size) NOT_LP64({ return ReservedSpace();}); > > [9] I think the #ifdef _LP64 is not necessary: > > #ifdef _LP64 > // Some sanity checks after reserving address spaces for archives and > class space. > assert(archive_space_rs.is_reserved(), "Sanity"); > if (Metaspace::using_class_space()) { > // Class space must closely follow the archive space. Both spaces > must be aligned correctly. > assert(class_space_rs.is_reserved(), "A class space should have been > reserved"); > assert(class_space_rs.base() >= archive_space_rs.end(), "class space > should follow the cds archive space"); > assert(is_aligned(archive_space_rs.base(), > MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); > assert(is_aligned(class_space_rs.base(), > Metaspace::reserve_alignment()), "class space misaligned"); > } > #endif > > I'll take a look. > The rest of the code looks OK to me, but I may take a look at it again > after getting more sleep :-) > > Sure. Thanks man! :) ..Thomas Thanks > - Ioi > > > > > On 5/7/20 7:21 AM, Thomas St?fe wrote: > > Hi all, > > please take a look at the third iteration of this change: > > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ > > Changes in this version: > > - at the request of Coleen (sorry I did not see your post earlier) I > removed all platform dependent files and put the platform dependent coding > back to metaspace.cpp and compressedOops.cpp to ease the review pain. I > used plain platform defines though (#ifdef AARCH64) instead of hiding them > behind another macro to make things clearer. Note that I still intent to > put this code away into the platform corners but will do so in a follow up > RFE. > > - I reinstated, in a fashion, the special handling of reservations on > Windows. On all platforms we reserve address space to map the archive files > in with a subsequent mapping operation. However, on Windows, we cannot use > MapViewOfFile() into an existing mapping. So I remove the mapping again > before mapping the archives - see comment in code for details. > > All CI tests at SAP run through without problems, including on Win64 and > aarch64, but I would be happy if others were to run test too. > > Thank you, Thomas > > On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe > wrote: > >> Hi all, >> >> Could I have reviews for the following proposal of reworking cds/class >> space reservation? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >> >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >> >> (Many thanks to Ioi Lam for so patiently explaining CDS internals to me, >> and to Andrew Haley and Nick Gasson for help with aarch64!) >> >> Reservation of the compressed class space is needlessly complicated and >> has some minor issues. It can be simplified and made clearer. >> >> The complexity stems from the fact that this area lives at the >> intersection of two to three sub systems, depending on how one counts. >> Metaspace, CDS, and the platform which may or may not its own view of how >> to reserve class space. And this code has been growing organically over >> time. >> >> One small example: >> >> ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t >> alignment, >> bool large_pages, char >> *requested_addr, >> bool use_requested_addr) >> >> which I spent hours decoding, resulting in a very confused mail to >> hs-runtime and aarch64-port-dev [2]. >> >> This patch attempts to simplify cds and metaspace setup a bit; to comment >> implicit knowledge which is not immediately clear; to cleanly abstract >> platform concerns like optimized class space placement; and to disentangle >> cds from metaspace to solve issues which may bite us later with Elastic >> Metaspace [4]. >> >> --- >> >> The main change is the reworked reservation mechanism. This is based on >> Ioi's proposal [5]. >> >> When reserving class space, three things must happen: >> >> 1) reservation of the space obviously. If cds is active that space must >> be in the vicinity of cds archives to be covered by compressed class >> pointer encoding. >> 2) setting up the internal Metaspace structures atop of that space >> 3) setting up compressed class pointer encoding. >> >> In its current form, Metaspace may or may not do some or all of that in >> one function >> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, >> it will reserve the space for Metaspace and hand it in, otherwise it will >> create it itself. >> >> When discussing this in [2], Ioi proposed to move the reservation of the >> class space completely out of Metaspace and make it a responsibility of the >> caller always. This would reduce some complexity, and this patch follows >> the proposal. >> >> I removed >> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base); and all its sub >> functions. >> >> (1) now has to always be done outside - a ReservedSpace for class space >> has to be provided by the caller. However, Metaspace now offers a utility >> function for reserving space at a "nice" location, and explicitly doing >> nothing else: >> >> ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >> >> this function can be redefined on a platform level for platform optimized >> reservation, see below for details. >> >> (2) is taken care of by a new function, >> Metaspace::initialize_class_space(ReservedSpace rs) >> >> (3) is taken care of a new function >> CompressedKlassPointers::initialize(), see below for details. >> >> >> So, class space now is set up three explicit steps: >> >> - First, reserve a suitable space by however means you want. For >> convenience you may use >> Metaspace::reserve_address_space_for_compressed_classes(), or you may roll >> your own reservation. >> - Next, tell Metaspace to use that range as backing storage for class >> space: Metaspace::initialize_class_space(ReservedSpace rs) >> - Finally, set up encoding. Encoding is independent from the concept of a >> ReservedSpace, it just gets an address range, see below for details. >> >> Separating these steps and moving them out of the responsibility of >> Metaspace makes this whole thing more flexible; it also removes unnecessary >> knowledge (e.g. Metaspace does not need to know anything about either ccp >> encoding or cds). >> >> --- >> >> How it comes together: >> >> If CDS is off, we just reserve a space using >> Metaspace::reserve_address_space_for_compressed_classes(), initialize it >> with Metaspace::initialize_class_space(ReservedSpace rs), then set up >> compressed class pointer encoding covering the range of this class space. >> >> If CDS is on (dump time), we reserve large 4G space, either at >> SharedBaseAddress or using >> Metaspace::reserve_address_space_for_compressed_classes(); we then split >> that into 3G archive space and 1G class space; we set up that space with >> Metaspace as class space; then we set up compressed class pointer encoding >> covering both archive space and cds. >> >> If CDS is on (run time), we reserve a large space, split it into archive >> space (large enough to hold both archives) and class space, then basically >> proceed as above. >> >> Note that this is almost exactly how things worked before (modulo some >> minor fixes, e.g. alignment issues), only the code is reformed and made >> more explicit. >> >> --- >> >> I moved compressed class pointer setup over to CompressedKlassPointers >> and changed the interface: >> >> -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >> metaspace_rs, address cds_base) >> +void CompressedKlassPointers::initialize(address addr, size_t len); >> >> Instead of feeding it a single ReservedSpace, which is supposed to >> represent class space, and an optional alternate base if cds is on, now we >> give it just an numeric address range. That range marks the limits to where >> Klass structures are to be expected, and is the implicit promise that >> outside that range no Klass structures will exist, so encoding has to cover >> only this range. >> >> This range may contain just the class space; or class space+cds; or >> whatever allocation scheme we come up with in the future. Encoding does not >> really care how the memory is organized as long as the input range covers >> all possible Klass locations. That way we remove knowledge about class >> space/cds from compressed class pointer encoding. >> >> Moving it away from metaspace.cpp into the CompressedKlassPointers class >> also mirrors CompressedOops::initialize(). >> >> --- >> >> I renamed _narrow_klass_range to just _range, because strictly speaking >> this is the range un-narrow Klass pointers can have. >> >> As for the implementation of CompressedKlassPointers::initialize(address >> addr, size_t len), I mimicked very closely what happened before, so there >> should be almost no differences. Since "almost no differences" sounds scary >> :) here are the differences: >> >> - When CDS is active (dump or run time) we now always, unconditionally, >> set the encoding range to 4G. This fixes a theoretical bug discussed on >> aarch64-port-dev [1]. >> >> - When CDS is not active, we set the encoding range to the minimum >> required length. Before, it was left at its default value of 4G. >> >> Both differences only affect aarch64, since they are currently the only >> one using the range field in CompressedKlassPointers. >> >> I wanted to add an assert somewhere to test encoding of the very last >> address of the CompressedKlassPointers range, again to prevent errors like >> [3]. But I did not come up with a good place for this assert which would >> cover also the encoding done by C1/C2. >> >> For the same reason I thought about introducing a mode where Klass >> structures would be allocated in reverse order, starting at the end of the >> ccs, but again left it out as too big a change. >> >> --- >> >> OS abstraction: platforms may have restrictions of what constitutes a >> valid compressed class pointer encoding base. Or if not, they may have at >> least preferences. There was logic like this in metaspace.cpp, which I >> removed and cleanly factored out into platform dependent files, giving each >> platform the option to add special logic. >> >> These are two new methods: >> >> - bool CompressedKlassPointers::is_valid_base(address p) >> >> to let the platform tell you whether it considers p to be a valid >> encoding base. The only platform having these restrictions currently is >> aarch64. >> >> - ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >> >> this hands over the process of allocating a range suitable for compressed >> class pointer encoding to the platform. Most platforms will allocate just >> anywhere, but some platforms may have a better strategy (e.g. trying low >> memory first, trying only correctly aligned addresses and so on). >> >> Beforehand, this coding existed in a similar form in metaspace.cpp for >> aarch64 and AIX. For now, I left the AIX part out - it seems only half >> done, and I want to check further if we even need it, if yes why not on >> Linux ppc, and C1 does not seem to support anything other than base+offset >> with shift either, but I may be mistaken. >> >> These two methods should give the platform enough control to implement >> their own scheme for optimized class space placement without bothering any >> shared code about it. >> >> Note about the form, I introduced two new platform dependent files, >> "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about >> this but this seems to be what we generally do in hotspot, right? >> >> --- >> >> Metaspace reserve alignment vs cds alignment >> >> CDS was using Metaspace reserve alignment for CDS internal purposes. I >> guess this was just a copy paste issue. It never caused problems since >> Metaspace reserve alignment == page size, but that is not true anymore in >> the upcoming Elastic Metaspace where reserve alignment will be larger. This >> causes a number of issues. >> >> I separated those two cleanly. CDS now uses >> os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in >> those two places where it is needed, when CDS creates the address space for >> class space on behalf of the Metaspace. >> >> --- >> >> Windows special handling in CDS >> >> To simplify coding I removed the windows specific handling which left out >> reservation of the archive. This was needed because windows cannot mmap >> files into reserved regions. But fallback code exists in filemap.cpp for >> this case which just reads in the region instead of mapping it. >> >> Should that turn out to be a performance problem, I will reinstate the >> feature. But a simpler way would be reserve the archive and later just >> before mmapping the archive file to release the archive space. That would >> not only be simpler but give us the best guarantee that that address space >> is actually available. But I'd be happy to leave that part out completely >> if we do not see any performance problems on windows x64. >> >> --- >> >> NMT cannot deal with spaces which are split. This problem manifests in >> that bookkeeping for class space is done under "Shared Classes", not >> "Classes" as it should. This problem exists today too at dump time and >> randomly at run time. But since I simplified the reservation, this problem >> now shows up always, whether or not we map at the SharedBaseAddress. >> While I could work around this problem, I'd prefer this problem to be >> solved at the core, and NMT to have an option to recognize reservation >> splits. So I'd rather not put a workaround for this into the patch but >> leave it for fixing as a separate issue. I opened this issue to track it >> [6]. >> >> --- >> >> Jtreg tests: >> >> I expanded the CompressedOops/CompressedClassPointers.java. I also >> extended them to Windows. The tests now optionally omit strict class space >> placement tests, since these tests heavily depend on ASLR and were the >> reason they were excluded on Windows. However I think even without checking >> for class space placement they make sense, just to see that the VM comes up >> and lives with the many different settings we can run in. >> >> --- >> >> Tests: >> >> - I ran the patch through Oracles submit repo >> - I ran tests manually for aarch64, zero, linux 32bit and windows x64 >> - The whole battery of nightly tests at SAP, including ppc, ppcle and >> aarch64, unfortunately excluding windows because of unrelated errors. >> Windows x64 tests will be redone tonight. >> >> >> Thank you, >> >> Thomas >> >> [1] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >> [2] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >> [5] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >> >> > From ioi.lam at oracle.com Fri May 8 05:37:08 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Thu, 7 May 2020 22:37:08 -0700 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: Message-ID: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> Hi Thomas, I am running your patch in out CI pipeline now. Some comments: [1] Do we still need to use _class_space_list? It looks like we just have a single range. Is _class_space_list->current_virtual_space() always the same VS? ? if (_class_space_list != NULL) { ??? address base = (address)_class_space_list->current_virtual_space()->bottom(); ??? address top = base + compressed_class_space_size(); ??? st->print("Compressed class space mapped at: " PTR_FORMAT "-" PTR_FORMAT ", size: " SIZE_FORMAT, ?????????????? p2i(base), p2i(top), top - base); [2] Does JDK-8243535 exist with the current jdk/jdk repo? ? // This does currently not work because rs may be the result of a split operation ? // and NMT seems not to be able to handle splits. ? // See JDK-8243535. ? // MemTracker::record_virtual_memory_type((address)rs.base(), mtClass); [3] I think this can be put in header file. bool Metaspace::class_space_is_initialized() { ? return _class_space_list != NULL; } [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is the reason for the ??? gap in the following chart: ??? // We do this by reserving space for the ccs behind the archives. Note however that ??? //? ccs follows a different alignment (Metaspace::reserve_alignment), so there may ??? //? be a gap between ccs and cds. ??? // We use a similar layout at runtime, see reserve_address_space_for_archives(). ??? // ??? //????????????????????????????? +-- SharedBaseAddress (default = 0x800000000) ??? //????????????????????????????? v ??? // +-..---------+---------+ ... +----+----+----+--------+--------------------+ ??? // |??? Heap??? | Archive |???? | MC | RW | RO | [gap]? | class space???? | ??? // +-..---------+---------+ ... +----+----+----+--------+--------------------+ ??? // |<--?? MaxHeapSize? -->|???? |<-- UnscaledClassSpaceMax = 4GB -->| _reserve_alignment is determined here: void Metaspace::ergo_initialize() { ? if (DumpSharedSpaces) { ??? // Using large pages when dumping the shared archive is currently not implemented. ??? FLAG_SET_ERGO(UseLargePagesInMetaspace, false); ? } ? size_t page_size = os::vm_page_size(); ? if (UseLargePages && UseLargePagesInMetaspace) { ??? page_size = os::large_page_size(); ? } ? _commit_alignment? = page_size; ? _reserve_alignment = MAX2(page_size, (size_t)os::vm_allocation_granularity()); But when CDS is enabled, the RS is reserved without large pages, so it should be possible to incrementally commit the CCS using just os::vm_allocation_granularity(). [5] I see the aarch64 code in Metaspace::reserve_address_space_for_compressed_classes has been changed. Is this necessary for this RFE, or is it a separate improvement that can be done in a different RFE? [6] For AARCH64, should we skip the part that reserves it right above the heap? Or does AARCH64 always allocate the heap such that it's a preferable address? ??? // case (b) ??? ReservedSpace rs; ??? // Try right above the Java heap... ??? address base = align_up(CompressedOops::end(), Metaspace::reserve_alignment()); ??? assert(base != NULL, "Sanity"); ??? const size_t size = align_up(CompressedClassSpaceSize, Metaspace::reserve_alignment()); ??? if (CompressedKlassPointers::is_valid_base(base)) { ????? rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* large */, (char*)base); ??? } ??? // ...failing that, reserve anywhere, but let platform do optimized placement: ??? if (!rs.is_reserved()) { ????? rs = Metaspace::reserve_address_space_for_compressed_classes(size); ??? } [7] argument.cpp checks this: ? if (UseSharedSpaces || DumpSharedSpaces) { ??? if (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { ????? log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for this platform, option will be ignored.", ?????????????????????? p2i((address)SharedBaseAddress)); ????? FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); ??? } ? } but initialize_dumptime_shared_and_meta_spaces aligns up the SharedBaseAddress before doing the assert. ? void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { ??? assert(DumpSharedSpaces, "should be called for dump time only"); ??? const size_t reserve_alignment = MetaspaceShared::reserved_space_alignment(); ??? char* shared_base = (char*)align_up((char*)SharedBaseAddress, reserve_alignment); ? #ifdef _LP64 assert(CompressedKlassPointers::is_valid_base((address)shared_base), "Sanity"); So theoretically shared_base may no longer be is_valid_base after the align_up. It probably won't happen, but I think the code will be much clearer tofirst to align_up, then check for is_valid_base and reset to default, and finally assert. [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the following block can be simplified: ? if (!_shared_rs.is_reserved()) { ??? // Get a reserved space anywhere if attaching at the SharedBaseAddress fails: ??? if (UseCompressedClassPointers) { ????? // If we need a compressed class space too, let the platform handle the reservation. ????? _shared_rs = Metaspace::reserve_address_space_for_compressed_classes(cds_total); ??? } else { ????? // anywhere is fine. ????? _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* large */, (char*)NULL); ??? } ? } ?? ... if you change the declaration to: ? static ReservedSpace reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return ReservedSpace();}); [9] I think the #ifdef _LP64 is not necessary: #ifdef _LP64 ??? // Some sanity checks after reserving address spaces for archives and class space. ??? assert(archive_space_rs.is_reserved(), "Sanity"); ??? if (Metaspace::using_class_space()) { ????? // Class space must closely follow the archive space. Both spaces must be aligned correctly. ????? assert(class_space_rs.is_reserved(), "A class space should have been reserved"); ????? assert(class_space_rs.base() >= archive_space_rs.end(), "class space should follow the cds archive space"); ????? assert(is_aligned(archive_space_rs.base(), MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); ????? assert(is_aligned(class_space_rs.base(), Metaspace::reserve_alignment()), "class space misaligned"); ??? } #endif The rest of the code looks OK to me, but I may take a look at it again after getting more sleep :-) Thanks - Ioi On 5/7/20 7:21 AM, Thomas St?fe wrote: > Hi all, > > please take a look at the third iteration of this change: > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ > > Changes in this version: > > - at the request of Coleen (sorry I did not see your post earlier) I > removed all platform dependent?files and put the platform dependent > coding back to metaspace.cpp and compressedOops.cpp to ease the review > pain. I used plain platform defines though (#ifdef AARCH64) instead of > hiding them behind another macro to make things clearer. Note that I > still intent to put this code away into the platform corners but will > do so in a follow up RFE. > > - I reinstated, in a fashion, the special handling of reservations on > Windows. On all platforms we reserve address space to map the archive > files in with a subsequent mapping operation. However, on Windows, we > cannot use MapViewOfFile() into an existing mapping. So I remove the > mapping again before mapping the archives - see comment in code for > details. > > All CI tests at SAP run through without problems, including on Win64 > and aarch64, but I would be happy if others were to run test too. > > Thank you, Thomas > > On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe > wrote: > > Hi all, > > Could I have reviews for the following proposal of reworking > cds/class space reservation? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ > > (Many thanks to Ioi Lam for so patiently explaining CDS internals > to me, and to Andrew Haley and Nick Gasson for help with aarch64!) > > Reservation of the compressed class space is needlessly > complicated and has some minor issues. It can be simplified and > made clearer. > > The complexity stems from the fact that this area lives at the > intersection of two to three sub systems, depending on how one > counts. Metaspace, CDS, and the platform which may or may not its > own view of how to reserve class space. And this code has been > growing organically over time. > > One small example: > > ReservedSpace Metaspace::reserve_preferred_space(size_t size, > size_t alignment, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bool large_pages, > char *requested_addr, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bool > use_requested_addr) > > which I spent hours decoding, resulting in a very confused mail to > hs-runtime and aarch64-port-dev [2]. > > This patch attempts to simplify cds and metaspace setup a bit; to > comment implicit knowledge which is not immediately clear; to > cleanly abstract platform concerns like optimized class space > placement; and to disentangle cds from metaspace to solve issues > which may bite us later with Elastic Metaspace [4]. > > --- > > The main change is the reworked reservation mechanism. This is > based on Ioi's proposal [5]. > > When reserving class space, three things must happen: > > 1) reservation of the space obviously. If cds is active that space > must be in the vicinity of cds archives to be covered by > compressed class pointer encoding. > 2) setting up the internal Metaspace structures atop of that space > 3) setting up compressed class pointer encoding. > > In its current form, Metaspace may or may not do some or all of > that in one function > (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace > metaspace_rs, char* requested_addr, address cds_base);) - if cds > is active, it will reserve the space for Metaspace and hand it in, > otherwise it will create it itself. > > When discussing this in [2], Ioi proposed to move the reservation > of the class space completely out of Metaspace and make it a > responsibility of the caller always. This would reduce some > complexity, and this patch follows the proposal. > > I removed > Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace > metaspace_rs, char* requested_addr, address cds_base); and all its > sub functions. > > (1) now has to always be done outside - a ReservedSpace for class > space has to be provided by the caller. However, Metaspace now > offers a utility function for reserving space at a "nice" > location, and explicitly doing nothing else: > > ReservedSpace > Metaspace::reserve_address_space_for_compressed_classes(size_t size); > > this function can be redefined on a platform level for platform > optimized reservation, see below for details. > > (2) is taken care of by a new function, > Metaspace::initialize_class_space(ReservedSpace rs) > > (3) is taken care of a new function > CompressedKlassPointers::initialize(), see below for details. > > > So, class space now is set up three explicit steps: > > - First, reserve a suitable space by however means you want. For > convenience you may use > Metaspace::reserve_address_space_for_compressed_classes(), or you > may roll your own reservation. > - Next, tell Metaspace to use that range as backing storage for > class space: Metaspace::initialize_class_space(ReservedSpace rs) > - Finally, set up encoding. Encoding is independent from the > concept of a ReservedSpace, it just gets an address range, see > below for details. > > Separating these steps and moving them out of the responsibility > of Metaspace makes this whole thing more flexible; it also removes > unnecessary knowledge (e.g. Metaspace does not need to know > anything about either ccp encoding or cds). > > --- > > How it comes together: > > If CDS is off, we just reserve a space using > Metaspace::reserve_address_space_for_compressed_classes(), > initialize it with Metaspace::initialize_class_space(ReservedSpace > rs), then set up compressed class pointer encoding covering the > range of this class space. > > If CDS is on (dump time), we reserve large 4G space, either at > SharedBaseAddress or using > Metaspace::reserve_address_space_for_compressed_classes(); we then > split that into 3G archive space and 1G class space; we set up > that space with Metaspace as class space; then we set > up?compressed class pointer encoding covering both archive space > and cds. > > If CDS is on (run time), we reserve a large space, split it into > archive space (large enough to hold both archives) and class > space, then basically proceed as above. > > Note that this is almost exactly how things worked before (modulo > some minor fixes, e.g. alignment issues), only the code is > reformed and made more explicit. > > --- > > I moved compressed class pointer setup over to > CompressedKlassPointers and changed the interface: > > -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace > metaspace_rs, address cds_base) > +void CompressedKlassPointers::initialize(address addr, size_t len); > > Instead of feeding it a single ReservedSpace, which is supposed to > represent class space, and an optional alternate base if cds is > on, now we give it just an numeric address range. That range marks > the limits to where Klass structures are to be expected, and is > the implicit promise that outside that range no Klass structures > will exist, so encoding has to cover only this range. > > This range may contain just the class space; or class space+cds; > or whatever allocation scheme we come up with in the future. > Encoding does not really care how the memory is organized as long > as the input range covers all possible Klass locations. That way > we remove knowledge about class space/cds from compressed class > pointer encoding. > > Moving it away from metaspace.cpp into the CompressedKlassPointers > class also mirrors CompressedOops::initialize(). > > --- > > I renamed _narrow_klass_range to just _range, because strictly > speaking this is the range un-narrow Klass pointers can have. > > As for the implementation of > CompressedKlassPointers::initialize(address addr, size_t len), I > mimicked very closely what happened before, so there should be > almost no differences. Since "almost no differences" sounds scary > :) here are the differences: > > - When CDS is active (dump or run time) we now always, > unconditionally, set the encoding range to 4G. This fixes a > theoretical bug discussed on aarch64-port-dev [1]. > > - When CDS is not active, we set the encoding range to the minimum > required length. Before, it was left at its default value of 4G. > > Both differences only affect aarch64, since they are currently the > only one using the range field in CompressedKlassPointers. > > I wanted to add an assert somewhere to test encoding of the very > last address of the CompressedKlassPointers range, again to > prevent errors like [3]. But I did not come up with a good place > for this assert which would cover also the encoding done by C1/C2. > > For the same reason I thought about introducing a mode where Klass > structures would be allocated in reverse order, starting at the > end of the ccs, but again left it out as too big a change. > > --- > > OS abstraction: platforms may have restrictions of what > constitutes a valid compressed class pointer encoding base. Or if > not, they may have at least preferences. There was logic like this > in metaspace.cpp, which I removed and cleanly factored out into > platform dependent files, giving each platform the option to add > special logic. > > These are two new methods: > > - bool CompressedKlassPointers::is_valid_base(address p) > > to let the platform tell you whether it considers p to be a valid > encoding base. The only platform having these restrictions > currently is aarch64. > > - ReservedSpace > Metaspace::reserve_address_space_for_compressed_classes(size_t size); > > this hands over the process of allocating a range suitable for > compressed class pointer encoding to the platform. Most platforms > will allocate just anywhere, but some platforms may have a better > strategy (e.g. trying low memory first, trying only correctly > aligned addresses and so on). > > Beforehand, this coding existed in a similar form in metaspace.cpp > for aarch64 and AIX. For now, I left the AIX part out - it seems > only half done, and I want to check further if we even need it, if > yes why not on Linux ppc, and C1 does not seem to support anything > other than base+offset with shift either, but I may be mistaken. > > These two methods should give the platform enough control to > implement their own scheme for optimized class space placement > without bothering any shared code about it. > > Note about the form, I introduced two new platform dependent > files, "metaspace_.cpp" and "compressedOops_.cpp". I am > not happy about this but this seems to be what we generally do in > hotspot, right? > > --- > > Metaspace reserve alignment vs cds alignment > > CDS was using Metaspace reserve alignment for CDS internal > purposes. I guess this was just a copy paste issue. It never > caused problems since Metaspace reserve alignment == page size, > but that is not true anymore in the upcoming Elastic Metaspace > where reserve alignment will be larger. This causes a number of > issues. > > I separated those two cleanly. CDS now uses > os::vm_allocation_granularity. Metaspace::reserve_alignment is > only used in those two places where it is needed, when CDS creates > the address space for class space on behalf of the Metaspace. > > --- > > Windows special handling in CDS > > To simplify coding I removed the windows specific handling which > left out reservation of the archive. This was needed because > windows cannot mmap files into reserved regions. But fallback code > exists in filemap.cpp for this case which just reads in the region > instead of mapping?it. > > Should that turn out to be a performance problem, I will reinstate > the feature. But a simpler way would be reserve the archive and > later just before mmapping?the archive file to release the archive > space. That would not only be simpler but give us the best > guarantee that that address space is actually available. But I'd > be happy to leave that part out completely if we do not see any > performance problems on windows x64. > > --- > > NMT cannot deal with spaces which are split. This problem > manifests in that bookkeeping for class space is done under > "Shared Classes", not "Classes" as it should. This problem exists > today too at dump?time and randomly at run time. But since I > simplified the reservation, this problem now shows up always, > whether or not we map at the SharedBaseAddress. > While I could work around this problem, I'd prefer this problem to > be solved at the core, and NMT to have an option to recognize > reservation splits. So I'd rather not put a workaround for this > into the patch but leave it for fixing as a separate issue. I > opened this issue to track it [6]. > > --- > > Jtreg tests: > > I expanded the CompressedOops/CompressedClassPointers.java. I also > extended them to Windows. The tests now optionally omit strict > class space placement tests, since these tests heavily depend on > ASLR and were the reason they were excluded on Windows. However I > think even without checking for class space placement they make > sense, just to see that the VM comes up and lives with the many > different settings we can run in. > > --- > > Tests: > > - I ran the patch through Oracles submit repo > - I ran tests manually for aarch64, zero, linux 32bit and windows x64 > - The whole battery of nightly tests at SAP, including ppc, ppcle > and aarch64, unfortunately excluding windows because of unrelated > errors. Windows x64 tests will be redone tonight. > > > Thank you, > > Thomas > > [1] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html > [2] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html > [3] https://bugs.openjdk.java.net/browse/JDK-8193266 > [4] https://bugs.openjdk.java.net/browse/JDK-8221173 > [5] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html > [6] https://bugs.openjdk.java.net/browse/JDK-8243535 > From ci_notify at linaro.org Sat May 9 09:08:55 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 9 May 2020 09:08:55 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <616363276.1199.1589015335599.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2020/128/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/31 pass: 5,784; fail: 1 Build 1: aarch64/2019/nov/09 pass: 5,773; fail: 3 Build 2: aarch64/2019/nov/16 pass: 5,775; fail: 1 Build 3: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 4: aarch64/2019/dec/05 pass: 5,775; fail: 1 Build 5: aarch64/2019/dec/08 pass: 5,775; fail: 1 Build 6: aarch64/2019/dec/14 pass: 5,775; fail: 1 Build 7: aarch64/2019/dec/17 pass: 5,775; fail: 1 Build 8: aarch64/2019/dec/21 pass: 5,775; fail: 1 Build 9: aarch64/2020/jan/16 pass: 5,775; fail: 1 Build 10: aarch64/2020/jan/30 pass: 5,791; fail: 1 Build 11: aarch64/2020/feb/06 pass: 5,791; fail: 1 Build 12: aarch64/2020/feb/13 pass: 5,792; fail: 1 Build 13: aarch64/2020/apr/30 pass: 5,813; fail: 1 Build 14: aarch64/2020/may/07 pass: 5,813; fail: 2 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/31 pass: 8,468; fail: 490; error: 14 Build 1: aarch64/2019/nov/09 pass: 8,487; fail: 470; error: 16 Build 2: aarch64/2019/nov/16 pass: 8,475; fail: 484; error: 15 Build 3: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 4: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 Build 5: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 Build 6: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 Build 7: aarch64/2019/dec/17 pass: 8,485; fail: 505; error: 15 Build 8: aarch64/2019/dec/21 pass: 8,499; fail: 496; error: 10 Build 9: aarch64/2020/jan/16 pass: 8,513; fail: 474; error: 17 Build 10: aarch64/2020/jan/30 pass: 8,513; fail: 501; error: 13 Build 11: aarch64/2020/feb/06 pass: 8,496; fail: 517; error: 14 Build 12: aarch64/2020/feb/13 pass: 8,509; fail: 507; error: 14 Build 13: aarch64/2020/apr/30 pass: 8,534; fail: 519; error: 15 Build 14: aarch64/2020/may/07 pass: 8,540; fail: 515; error: 12 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/oct/31 pass: 3,910 Build 1: aarch64/2019/nov/09 pass: 3,910 Build 2: aarch64/2019/nov/16 pass: 3,910 Build 3: aarch64/2019/nov/21 pass: 3,910 Build 4: aarch64/2019/dec/05 pass: 3,910 Build 5: aarch64/2019/dec/08 pass: 3,910 Build 6: aarch64/2019/dec/14 pass: 3,910 Build 7: aarch64/2019/dec/17 pass: 3,910 Build 8: aarch64/2019/dec/21 pass: 3,910 Build 9: aarch64/2020/jan/16 pass: 3,910 Build 10: aarch64/2020/jan/30 pass: 3,913 Build 11: aarch64/2020/feb/06 pass: 3,913 Build 12: aarch64/2020/feb/13 pass: 3,913 Build 13: aarch64/2020/apr/30 pass: 3,913 Build 14: aarch64/2020/may/07 pass: 3,913 Previous results can be found here: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.83x Relative performance: Server critical-jOPS (nc): 7.95x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-10-18 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/290/results/ 2019-11-01 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/304/results/ 2019-11-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/313/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ 2019-12-18 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/351/results/ 2019-12-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/355/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/037/results/ 2020-02-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/044/results/ 2020-05-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/121/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/128/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From ci_notify at linaro.org Sun May 10 16:20:43 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 10 May 2020 16:20:43 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <357633221.1303.1589127643538.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2020/130/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/15 pass: 5,770; fail: 46 Build 1: aarch64/2020/jan/20 pass: 5,776; fail: 44 Build 2: aarch64/2020/jan/22 pass: 5,776; fail: 44 Build 3: aarch64/2020/jan/24 pass: 5,775; fail: 45 Build 4: aarch64/2020/jan/27 pass: 5,776; fail: 44 Build 5: aarch64/2020/jan/29 pass: 5,776; fail: 44 Build 6: aarch64/2020/feb/01 pass: 5,777; fail: 46 Build 7: aarch64/2020/feb/03 pass: 5,777; fail: 46 Build 8: aarch64/2020/feb/05 pass: 5,778; fail: 46 Build 9: aarch64/2020/feb/10 pass: 5,781; fail: 46 Build 10: aarch64/2020/feb/12 pass: 5,786; fail: 46 Build 11: aarch64/2020/mar/06 pass: 5,797; fail: 46 Build 12: aarch64/2020/mar/16 pass: 5,796; fail: 47 Build 13: aarch64/2020/apr/08 pass: 5,816; fail: 46; error: 2 Build 14: aarch64/2020/may/09 pass: 5,835; fail: 46 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/15 pass: 8,827; fail: 524; error: 19 Build 1: aarch64/2020/jan/20 pass: 8,830; fail: 529; error: 16 Build 2: aarch64/2020/jan/22 pass: 8,829; fail: 528; error: 19 Build 3: aarch64/2020/jan/24 pass: 8,832; fail: 537; error: 16 Build 4: aarch64/2020/jan/27 pass: 8,846; fail: 523; error: 17 Build 5: aarch64/2020/jan/29 pass: 8,844; fail: 522; error: 19 Build 6: aarch64/2020/feb/01 pass: 8,848; fail: 523; error: 18 Build 7: aarch64/2020/feb/03 pass: 8,851; fail: 525; error: 15 Build 8: aarch64/2020/feb/05 pass: 8,851; fail: 526; error: 15 Build 9: aarch64/2020/feb/10 pass: 8,858; fail: 518; error: 20 Build 10: aarch64/2020/feb/12 pass: 8,849; fail: 525; error: 17 Build 11: aarch64/2020/mar/06 pass: 8,870; fail: 526; error: 17 Build 12: aarch64/2020/mar/16 pass: 8,872; fail: 525; error: 16 Build 13: aarch64/2020/apr/08 pass: 8,891; fail: 532; error: 13 Build 14: aarch64/2020/may/09 pass: 8,929; fail: 543; error: 15 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/13 pass: 4,030 Build 1: aarch64/2020/jan/15 pass: 4,031 Build 2: aarch64/2020/jan/20 pass: 4,033 Build 3: aarch64/2020/jan/22 pass: 4,033 Build 4: aarch64/2020/jan/24 pass: 4,033 Build 5: aarch64/2020/jan/27 pass: 4,033 Build 6: aarch64/2020/feb/01 pass: 4,036 Build 7: aarch64/2020/feb/03 pass: 4,036 Build 8: aarch64/2020/feb/05 pass: 4,036 Build 9: aarch64/2020/feb/10 pass: 4,037 Build 10: aarch64/2020/feb/12 pass: 4,037 Build 11: aarch64/2020/mar/06 pass: 4,039 Build 12: aarch64/2020/mar/16 pass: 4,039 Build 13: aarch64/2020/apr/08 pass: 4,042 Build 14: aarch64/2020/may/09 pass: 4,052 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 8.24x Relative performance: Server critical-jOPS (nc): 12.90x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 210.67 Server 210.67 / Server 2014-04-01 (71.00): 2.97x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/013/results/ 2020-01-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/015/results/ 2020-01-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/020/results/ 2020-01-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/022/results/ 2020-01-25 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/024/results/ 2020-01-28 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/027/results/ 2020-02-02 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/032/results/ 2020-02-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/034/results/ 2020-02-06 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/036/results/ 2020-02-11 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/041/results/ 2020-02-13 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/043/results/ 2020-03-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/066/results/ 2020-03-19 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/076/results/ 2020-04-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/099/results/ 2020-05-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/130/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Sun May 10 22:51:24 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 10 May 2020 22:51:24 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <509244004.1325.1589151085573.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2020/131/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/22 pass: 837; fail: 9; error: 1 Build 1: aarch64/2019/sep/10 pass: 838; fail: 13; error: 1 Build 2: aarch64/2019/sep/21 pass: 838; fail: 13; error: 1 Build 3: aarch64/2019/nov/02 pass: 843; fail: 9; error: 1 Build 4: aarch64/2019/nov/14 pass: 843; fail: 9; error: 1 Build 5: aarch64/2019/dec/16 pass: 843; fail: 10; error: 1 Build 6: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 Build 7: aarch64/2019/dec/19 pass: 846; fail: 10; error: 2 Build 8: aarch64/2019/dec/21 pass: 848; fail: 10; error: 2 Build 9: aarch64/2020/jan/09 pass: 848; fail: 10; error: 1 Build 10: aarch64/2020/jan/11 pass: 848; fail: 10; error: 1 Build 11: aarch64/2020/jan/20 pass: 848; fail: 10; error: 1 Build 12: aarch64/2020/jan/25 pass: 848; fail: 10; error: 1 Build 13: aarch64/2020/may/06 pass: 885; fail: 12; error: 1 Build 14: aarch64/2020/may/10 pass: 885; fail: 12; error: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/10 pass: 5,951; fail: 273; error: 23 Build 1: aarch64/2019/sep/21 pass: 5,964; fail: 261; error: 22 Build 2: aarch64/2019/nov/02 pass: 5,956; fail: 278; error: 18 Build 3: aarch64/2019/nov/14 pass: 5,956; fail: 275; error: 21 Build 4: aarch64/2019/dec/16 pass: 5,964; fail: 267; error: 21 Build 5: aarch64/2019/dec/17 pass: 5,963; fail: 267; error: 22 Build 6: aarch64/2019/dec/19 pass: 5,959; fail: 272; error: 21 Build 7: aarch64/2019/dec/21 pass: 5,970; fail: 262; error: 21 Build 8: aarch64/2020/jan/09 pass: 5,963; fail: 276; error: 20 Build 9: aarch64/2020/jan/11 pass: 5,959; fail: 279; error: 21 Build 10: aarch64/2020/jan/20 pass: 5,987; fail: 256; error: 24 Build 11: aarch64/2020/jan/25 pass: 5,962; fail: 285; error: 22 Build 12: aarch64/2020/feb/03 pass: 5,976; fail: 278; error: 19 Build 13: aarch64/2020/may/06 pass: 5,998; fail: 281; error: 21 Build 14: aarch64/2020/may/10 pass: 6,025; fail: 695; error: 21 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/aug/22 pass: 3,116; fail: 2 Build 1: aarch64/2019/sep/10 pass: 3,116; fail: 2 Build 2: aarch64/2019/sep/21 pass: 3,116; fail: 2 Build 3: aarch64/2019/nov/02 pass: 3,116; fail: 2 Build 4: aarch64/2019/nov/14 pass: 3,116; fail: 2 Build 5: aarch64/2019/dec/16 pass: 3,116; fail: 2 Build 6: aarch64/2019/dec/17 pass: 3,117; fail: 2 Build 7: aarch64/2019/dec/19 pass: 3,117; fail: 2 Build 8: aarch64/2019/dec/21 pass: 3,117; fail: 2 Build 9: aarch64/2020/jan/09 pass: 3,117; fail: 2 Build 10: aarch64/2020/jan/11 pass: 3,117; fail: 2 Build 11: aarch64/2020/jan/20 pass: 3,117; fail: 2 Build 12: aarch64/2020/jan/25 pass: 3,117; fail: 2 Build 13: aarch64/2020/may/06 pass: 3,117; fail: 2 Build 14: aarch64/2020/may/10 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 6.81x Relative performance: Server critical-jOPS (nc): 8.49x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 172.13 Server 172.13 / Server 2014-04-01 (71.00): 2.42x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-08-23 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/234/results/ 2019-09-11 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/253/results/ 2019-09-22 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/264/results/ 2019-11-02 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/306/results/ 2019-11-15 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/318/results/ 2019-12-16 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/350/results/ 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ 2019-12-19 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/353/results/ 2019-12-22 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/355/results/ 2020-01-09 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/009/results/ 2020-01-11 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/011/results/ 2020-01-20 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/020/results/ 2020-01-25 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/025/results/ 2020-05-06 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/127/results/ 2020-05-10 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/131/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From Yang.Zhang at arm.com Mon May 11 01:50:16 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Mon, 11 May 2020 01:50:16 +0000 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs In-Reply-To: References: Message-ID: Hi, Ping it again. Could you please help to review this? Regards Yang -----Original Message----- From: aarch64-port-dev On Behalf Of Yang Zhang Sent: Wednesday, May 6, 2020 4:46 PM To: aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs Hi, Could you please help to review this patch? JBS: https://bugs.openjdk.java.net/browse/JDK-8243597 Webrev: http://cr.openjdk.java.net/~yzhang/8243597/webrev.00/ In JDK-8222074 [1], x86 enables auto vectorization for integer vector abs, and jtreg tests are also added. In this patch, the missing AbsVB/S/I/L support for AArch64 is added. Testing: Full jtreg test Vector API tests which cover vector abs Test case: public static void absvs(short[] a, short[] b, short[] c) { for (int i = 0; i < a.length; i++) { c[i] = (short)Math.abs((a[i] + b[i])); } } Assembly code generated by C2: 0x0000ffffaca3f3ac: ldr q17, [x16, #16] 0x0000ffffaca3f3b0: ldr q16, [x15, #16] 0x0000ffffaca3f3b4: add v16.8h, v16.8h, v17.8h 0x0000ffffaca3f3b8: abs v16.8h, v16.8h 0x0000ffffaca3f3c0: str q16, [x12, #16] Similar test cases for byte/int/long are also tested and NEON abs instruction is generated by C2. Performance: JMH tests are uploaded. http://cr.openjdk.java.net/~yzhang/8243597/TestScalar.java http://cr.openjdk.java.net/~yzhang/8243597/TestVect.java Vector abs: Before: Benchmark (size) Mode Cnt Score Error Units TestVect.testVectAbsVB 1024 avgt 5 1041.720 ? 2.606 us/op TestVect.testVectAbsVI 1024 avgt 5 659.788 ? 2.057 us/op TestVect.testVectAbsVL 1024 avgt 5 711.043 ? 5.489 us/op TestVect.testVectAbsVS 1024 avgt 5 659.157 ? 2.531 us/op After Benchmark (size) Mode Cnt Score Error Units TestVect.testVectAbsVB 1024 avgt 5 88.821 ? 1.886 us/op TestVect.testVectAbsVI 1024 avgt 5 199.081 ? 2.539 us/op TestVect.testVectAbsVL 1024 avgt 5 447.536 ? 1.195 us/op TestVect.testVectAbsVS 1024 avgt 5 119.172 ? 0.340 us/op Scalar abs: Before: Benchmark (size) Mode Cnt Score Error Units TestScalar.testAbsI 1024 avgt 5 3770.345 ? 6.760 us/op TestScalar.testAbsL 1024 avgt 5 3767.570 ? 9.097 us/op After: Benchmark (size) Mode Cnt Score Error Units TestScalar.testAbsI 1024 avgt 5 3141.312 ? 2.000 us/op TestScalar.testAbsL 1024 avgt 5 3103.143 ? 8.989 us/op [1] https://bugs.openjdk.java.net/browse/JDK-8222074 Regards Yang From nick.gasson at arm.com Mon May 11 07:56:23 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 11 May 2020 15:56:23 +0800 Subject: [aarch64-port-dev ] RFR: 8244164: AArch64: jaotc generates incorrect code for compressed OOPs with non-zero heap base Message-ID: <858shy9a6w.fsf@arm.com> Hi, Bug: https://bugs.openjdk.java.net/browse/JDK-8244164 Webrev: http://cr.openjdk.java.net/~ngasson/8244164/webrev.0/ On AArch64 if the VM jaotc is running in uses compressed oops with a zero base it will not emit instructions to add/subtract the heap base when compressing/decompressing oops. This causes a crash if the AOT'd shared library is loaded into a VM with non-zero heap base. Tested jtreg hotspot_all_no_apps, jdk_core with no new failures. I've made a separate pull request for Graal [1] but I'm submitting this here too as I want to backport to 14 and 11u and also add a jtreg test. Not sure if this is the right process to follow? [1] https://github.com/oracle/graal/pull/2446 -- Thanks, Nick From aph at redhat.com Mon May 11 09:19:33 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 May 2020 10:19:33 +0100 Subject: [aarch64-port-dev ] RFR: 8244164: AArch64: jaotc generates incorrect code for compressed OOPs with non-zero heap base In-Reply-To: <858shy9a6w.fsf@arm.com> References: <858shy9a6w.fsf@arm.com> Message-ID: <9ad52446-7779-1fe2-db26-2640f4da5b97@redhat.com> On 5/11/20 8:56 AM, Nick Gasson wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8244164 > Webrev: http://cr.openjdk.java.net/~ngasson/8244164/webrev.0/ > > On AArch64 if the VM jaotc is running in uses compressed oops with a > zero base it will not emit instructions to add/subtract the heap base > when compressing/decompressing oops. This causes a crash if the AOT'd > shared library is loaded into a VM with non-zero heap base. > > Tested jtreg hotspot_all_no_apps, jdk_core with no new failures. OK. > I've made a separate pull request for Graal [1] but I'm submitting this > here too as I want to backport to 14 and 11u and also add a jtreg > test. Not sure if this is the right process to follow? > > [1] https://github.com/oracle/graal/pull/2446 Sure. It's good to get input from both sides. -- 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 May 11 14:56:38 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 11 May 2020 15:56:38 +0100 Subject: [aarch64-port-dev ] Rejected AArch64 jdk8u backports Message-ID: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> I've been going though AArch64 jdk8u backports. The following backports should (probably) NOT be done in 8u; reasons follow. 8219006: AArch64: Register corruption in slow subtype check Only affects debug builds; patch is fiddly and risky. 8219698: aarch64: SIGILL triggered when specifying unsupported hardware features Only happens due to user error: the problem is between keyboard and chair. 8219993: AArch64: Compiled CI stubs are unsafely modified This is a rather theoretical bug in that the AArch64 back end modifies stubs in a way that IMO doesn't conform to the AArch64 memory model. However, the fix is complicated and the problem has never manifested in any test cases, so it's better to leave it as it is in 8u. 8222412: AARCH64: multiple instructions encoding issues Big and intrusive, fixes no user-visible bugs, so not appropriate for 8u. 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 Serviceability test. Not important. 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl C2 enhancement. Might break things, small performance improvement, hard to test, so not for 8u. 8233912: aarch64: minor improvements of atomic operations Another rather theoretical patch that fixes no known bugs. 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes Summary: try to map CDS shared space at 4G aligned address on AArch64 Not applicable to 8u. 8235385: AArch64: Crash on aarch64 JDK due to long offset This is a real bug but it requires a very contrived test case to trigger it and the fix is complex. Probably not worth it. 8237512: AArch64: aarch64TestHook leaks a BufferBlob Only gets triggered in debug builds. Not important for 8u. 8237524: AArch64: String.compareTo() may return incorrect result Code being patched does not exist in 8u. 8239787: AArch64: String.indexOf may incorrectly handle empty strings Likewise 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 Enhancement-only patch. -- 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 gnu.andrew at redhat.com Mon May 11 17:43:56 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 11 May 2020 18:43:56 +0100 Subject: [aarch64-port-dev ] Rejected AArch64 jdk8u backports In-Reply-To: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> References: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> Message-ID: <651fe7c2-bcca-a157-bbbe-ecbc00f9c7fe@redhat.com> On 11/05/2020 15:56, Andrew Haley wrote: > I've been going though AArch64 jdk8u backports. > The following backports should (probably) NOT be done in 8u; reasons follow. > > > 8219006: AArch64: Register corruption in slow subtype check > > Only affects debug builds; patch is fiddly and risky. > > 8219698: aarch64: SIGILL triggered when specifying unsupported hardware features > > Only happens due to user error: the problem is between keyboard and chair. > > 8219993: AArch64: Compiled CI stubs are unsafely modified > > This is a rather theoretical bug in that the AArch64 back end modifies > stubs in a way that IMO doesn't conform to the AArch64 memory > model. However, the fix is complicated and the problem has never > manifested in any test cases, so it's better to leave it as it is in > 8u. > > 8222412: AARCH64: multiple instructions encoding issues > > Big and intrusive, fixes no user-visible bugs, so not appropriate for > 8u. > > 8229118: [TESTBUG] serviceability/sa/ClhsdbFindPC fails on AArch64 > > Serviceability test. Not important. > > 8232591: AArch64: Add missing match rules for smaddl, smsubl and smnegl > > C2 enhancement. Might break things, small performance improvement, > hard to test, so not for 8u. > > 8233912: aarch64: minor improvements of atomic operations > > Another rather theoretical patch that fixes no known bugs. > > 8234794: AArch64: runtime/memory/ReadFromNoaccessArea.java crashes > Summary: try to map CDS shared space at 4G aligned address on AArch64 > > Not applicable to 8u. > > 8235385: AArch64: Crash on aarch64 JDK due to long offset > > This is a real bug but it requires a very contrived test case to > trigger it and the fix is complex. Probably not worth it. > > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > > Only gets triggered in debug builds. Not important for 8u. > > 8237524: AArch64: String.compareTo() may return incorrect result > > Code being patched does not exist in 8u. > > 8239787: AArch64: String.indexOf may incorrectly handle empty strings > > Likewise > > 8240353: AArch64: missing support for -XX:+ExtendedDTraceProbes in C1 > > Enhancement-only patch. > Is there a reason a lot of recent AArch64 posts have also been CCed to the 8u-dev list? Upstream 8u does not currently have an AArch64 port. Thanks, -- Andrew :) Senior Free Java Software Engineer 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 adinn at redhat.com Mon May 11 20:28:18 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 11 May 2020 21:28:18 +0100 Subject: [aarch64-port-dev ] Rejected AArch64 jdk8u backports In-Reply-To: <651fe7c2-bcca-a157-bbbe-ecbc00f9c7fe@redhat.com> References: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> <651fe7c2-bcca-a157-bbbe-ecbc00f9c7fe@redhat.com> Message-ID: On 11/05/2020 18:43, Andrew Hughes wrote: > > Is there a reason a lot of recent AArch64 posts have also been CCed to > the 8u-dev list? Upstream 8u does not currently have an AArch64 port. I think that was just me forwarding a few reviews. It wasn't necessary but I thought it might be useful for those subscribing to the updates list to know about the decisions being made and the rationale for them. I suppose we /may/ still see the AArch64 port upstreamed into jdk8u at some stage. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From nick.gasson at arm.com Tue May 12 02:25:44 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Tue, 12 May 2020 10:25:44 +0800 Subject: [aarch64-port-dev ] Rejected AArch64 jdk8u backports In-Reply-To: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> References: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> Message-ID: <854ksl99ef.fsf@arm.com> > > 8237512: AArch64: aarch64TestHook leaks a BufferBlob > > Only gets triggered in debug builds. Not important for 8u. > I think the leak is still there in release builds: the BufferBlob is allocated in aarch64TestHook() which is called from ICache::initialize(). That then calls into entry() in assembler_aarch64.cpp which does nothing if ASSERT is not defined. -- Thanks, Nick From aph at redhat.com Tue May 12 08:41:35 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2020 09:41:35 +0100 Subject: [aarch64-port-dev ] Rejected AArch64 jdk8u backports In-Reply-To: <854ksl99ef.fsf@arm.com> References: <972f8a76-ce2d-de9f-e836-7e6fea990de6@redhat.com> <854ksl99ef.fsf@arm.com> Message-ID: <2a16887d-1453-8d05-36ee-ea468ff0e3a4@redhat.com> On 5/12/20 3:25 AM, Nick Gasson wrote: >> >> 8237512: AArch64: aarch64TestHook leaks a BufferBlob >> >> Only gets triggered in debug builds. Not important for 8u. >> > > I think the leak is still there in release builds: the BufferBlob is > allocated in aarch64TestHook() which is called from > ICache::initialize(). That then calls into entry() in > assembler_aarch64.cpp which does nothing if ASSERT is not defined. Oh poo, you're right. Thanks, I'll fix 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 May 12 12:02:34 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 12 May 2020 13:02:34 +0100 Subject: [aarch64-port-dev ] RFR: Backport: 823751: AArch64: aarch64TestHook leaks a BufferBlob Message-ID: <011c1f56-974a-91e8-7956-11dfd2c1a0f6@redhat.com> This is Nick Gasson's patch, adjusted but not changed in any significant way: http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8237512.webrev/ Just out of curiosity, I looked at when this bug dates from, and I see # User aph # Date 1342803468 -3600 # Fri Jul 20 17:57:48 2012 +0100 Assembler bug fixes diff -r 0267a9670f59 -r f561ffc8c13f src/cpu/aarch64/vm/aarch64Test.cpp --- a/src/cpu/aarch64/vm/aarch64Test.cpp Fri Jul 20 12:39:25 2012 +0100 +++ b/src/cpu/aarch64/vm/aarch64Test.cpp Fri Jul 20 17:57:48 2012 +0100 @@ -17,7 +17,7 @@ void aarch64TestHook() { - BufferBlob* b = BufferBlob::create("aarch64Test", 5000); + BufferBlob* b = BufferBlob::create("aarch64Test", 500000); This was right at the beginning, when we were writing the assembler, and I needed some way to make sure the generated code was correct but we had no hardware. It's hard to remember what I was thinking, but I guess I thought that this was only test code, so it didn't matter. How wrong can you be? ?? Memo to self: don't do that again. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Tue May 12 12:41:48 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 12 May 2020 14:41:48 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> Message-ID: On Tue, May 12, 2020 at 12:01 AM Ioi Lam wrote: > > > On 5/8/20 12:33 AM, Thomas St?fe wrote: > > Hi Ioi, > > thanks for taking the time to look at this! > > On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: > >> Hi Thomas, >> >> I am running your patch in out CI pipeline now. Some comments: >> >> [1] Do we still need to use _class_space_list? It looks like we just have >> a single range. Is _class_space_list->current_virtual_space() always the >> same VS? >> >> if (_class_space_list != NULL) { >> address base = >> (address)_class_space_list->current_virtual_space()->bottom(); >> address top = base + compressed_class_space_size(); >> st->print("Compressed class space mapped at: " PTR_FORMAT "-" >> PTR_FORMAT ", size: " SIZE_FORMAT, >> p2i(base), p2i(top), top - base); >> >> > Yes it is. Has been bugging me for years too. With ccs, the > VirtualSpaceList is degenerated and only contains one node. It still makes > some sense code wise. But maybe VirtualSpace*List* is a misnomer. > > It also ties in into the question whether Metaspace reservations should be > able to grow on demand. Oracle folks I talk to tend to say yes. I > personally think the "Metaspace is infinite don't worry" meme was broken > since ccs was a thing, since CompressedClassSpaceSize is an absolute limit > already. > > I may tweak and simplify the code a bit with Elastic Metaspace. Maybe, as > you say, with ccs we can get rid of VirtualSpaceList and deal with the > range directly. Have to check. > > [2] Does JDK-8243535 exist with the current jdk/jdk repo? >> >> // This does currently not work because rs may be the result of a split >> operation >> // and NMT seems not to be able to handle splits. >> // See JDK-8243535. >> // MemTracker::record_virtual_memory_type((address)rs.base(), mtClass); >> >> > Yes. It shows up more rarely. With this patch, it will show up always. I > had a conversation with Zhengyu about this. I think there may be > workarounds, like removing the original mapping in NMT and replacing it > with the two new ones for archive and ccs. But it seems iffy, I'd rather > have this fixed in NMT. > > I also think it is not such a big deal, but if you think otherwise, I can > integrate a workaround into this patch. > > > > My question is -- will NMT (or control-backspace) now always report > incorrect memory size for the metaspace when CDS is enabled? If so, I think > a work-around is necessary. > > What is control backspace? I'm staring at '^H' output in my terminal and feel like I miss something :) Today NMT reports wrong memory size at dumptime (I think no-one cares probably) and at runtime if the archive got relocated. With the patch NMT will also report wrong numbers at runtime when mapping to default address. But okay, I will add a workaround. > >> [3] I think this can be put in header file. >> >> bool Metaspace::class_space_is_initialized() { >> return _class_space_list != NULL; >> } >> >> > Will do. > > >> [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is the >> reason for the >> gap in the following chart: >> >> // We do this by reserving space for the ccs behind the archives. >> Note however that >> // ccs follows a different alignment (Metaspace::reserve_alignment), >> so there may >> // be a gap between ccs and cds. >> // We use a similar layout at runtime, see >> reserve_address_space_for_archives(). >> // >> // +-- SharedBaseAddress (default = >> 0x800000000) >> // v >> // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> // | Heap | Archive | | MC | RW | RO | [gap] | class >> space | >> // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> // |<-- MaxHeapSize -->| |<-- UnscaledClassSpaceMax = 4GB -->| >> >> > No, nothing to do with large pages. CCS does not have large pages. > > The gap can result from different alignment rules between metaspace and > cds. With Elastic Metaspace, metaspace reservations will be aligned to 4M. > So, ccs will have to start at a 4M aligned border. > > >> >> _reserve_alignment is determined here: >> >> void Metaspace::ergo_initialize() { >> if (DumpSharedSpaces) { >> // Using large pages when dumping the shared archive is currently not >> implemented. >> FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >> } >> >> size_t page_size = os::vm_page_size(); >> if (UseLargePages && UseLargePagesInMetaspace) { >> page_size = os::large_page_size(); >> } >> >> _commit_alignment = page_size; >> _reserve_alignment = MAX2(page_size, >> (size_t)os::vm_allocation_granularity()); >> >> But when CDS is enabled, the RS is reserved without large pages, so it >> should be possible to incrementally commit the CCS using just >> os::vm_allocation_granularity(). >> >> > Absolutely. CCS does not use large pages for that reason. As I wrote, this > is about the new reservation granularity of 4M. > > > OK, if I understand correctly: > > + With the current patch, the gap exists only when > UseLargePagesInMetaspace is used at run time. The gap actually is > unnecessary, since ccs doesn't use large pages. > > + With the upcoming Elastic Metaspace, _reserve_alignment will be 4MB, so > we will almost always have a gap. > Yes. Note that we decided to remove the large page feature from Metaspace with Elastic Metaspace for now, though we may reintroduce it later in a different form. See CSR: https://bugs.openjdk.java.net/browse/JDK-8243161 . > > > >> [5] I see the aarch64 code in >> Metaspace::reserve_address_space_for_compressed_classes has been changed. >> Is this necessary for this RFE, or is it a separate improvement that can be >> done in a different RFE? >> > > Well, it had to be changed somewhat, since the prototype differs. I > swapped Metaspace::reserve_preferred_space() for > Metaspace::reserve_address_space_for_compressed_classes(), which follows a > somewhat different protocol. > > That aside, the functionality for AARCH64 should be as unchanged as > possible. I removed the AIX specific coding, since it was subtly wrong, but > that's fine since we are AIX/ppc maintainers. > > >> [6] For AARCH64, should we skip the part that reserves it right above the >> heap? Or does AARCH64 always allocate the heap such that it's a preferable >> address? >> >> > Yes and yes :) > > We do skip that for aarch64 (at least if the address is wrong): > > 1157 // Try right above the Java heap... > 1158 address base = align_up(CompressedOops::end(), Metaspace::reserve_alignment()); > 1159 assert(base != NULL, "Sanity"); > 1160 > 1161 const size_t size = align_up(CompressedClassSpaceSize, Metaspace::reserve_alignment()); > 1162 if (CompressedKlassPointers::is_valid_base(base)) { > 1163 rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* large */, (char*)base); > 1164 } > > At 1162, we check if the attach address would be valid for this platform. > If aarch64 says no, we won't reserve there but go straight to the "attach > wherever you think is good" part. Which is implemented > by Metaspace::reserve_address_space_for_compressed_classes(), which on > aarch64 does search a suitable address. > > > >> // case (b) >> ReservedSpace rs; >> >> // Try right above the Java heap... >> address base = align_up(CompressedOops::end(), >> Metaspace::reserve_alignment()); >> assert(base != NULL, "Sanity"); >> >> const size_t size = align_up(CompressedClassSpaceSize, >> Metaspace::reserve_alignment()); >> if (CompressedKlassPointers::is_valid_base(base)) { >> rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* >> large */, (char*)base); >> } >> >> // ...failing that, reserve anywhere, but let platform do optimized >> placement: >> if (!rs.is_reserved()) { >> rs = Metaspace::reserve_address_space_for_compressed_classes(size); >> } >> >> [7] argument.cpp checks this: >> >> if (UseSharedSpaces || DumpSharedSpaces) { >> if >> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >> log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for >> this platform, option will be ignored.", >> p2i((address)SharedBaseAddress)); >> FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >> } >> } >> >> but initialize_dumptime_shared_and_meta_spaces aligns up the >> SharedBaseAddress before doing the assert. >> >> void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >> assert(DumpSharedSpaces, "should be called for dump time only"); >> >> const size_t reserve_alignment = >> MetaspaceShared::reserved_space_alignment(); >> char* shared_base = (char*)align_up((char*)SharedBaseAddress, >> reserve_alignment); >> >> #ifdef _LP64 >> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >> "Sanity"); >> >> So theoretically shared_base may no longer be is_valid_base after the >> align_up. It probably won't happen, but I think the code will be much >> clearer tofirst to align_up, then check for is_valid_base and reset to >> default, and finally assert. >> >> > Okay, I'll change that. > > >> [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >> following block can be simplified: >> >> if (!_shared_rs.is_reserved()) { >> // Get a reserved space anywhere if attaching at the >> SharedBaseAddress fails: >> if (UseCompressedClassPointers) { >> // If we need a compressed class space too, let the platform handle >> the reservation. >> _shared_rs = >> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >> } else { >> // anywhere is fine. >> _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >> large */, (char*)NULL); >> } >> } >> >> ... if you change the declaration to: >> >> static ReservedSpace >> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >> ReservedSpace();}); >> >> [9] I think the #ifdef _LP64 is not necessary: >> >> #ifdef _LP64 >> // Some sanity checks after reserving address spaces for archives and >> class space. >> assert(archive_space_rs.is_reserved(), "Sanity"); >> if (Metaspace::using_class_space()) { >> // Class space must closely follow the archive space. Both spaces >> must be aligned correctly. >> assert(class_space_rs.is_reserved(), "A class space should have >> been reserved"); >> assert(class_space_rs.base() >= archive_space_rs.end(), "class >> space should follow the cds archive space"); >> assert(is_aligned(archive_space_rs.base(), >> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >> assert(is_aligned(class_space_rs.base(), >> Metaspace::reserve_alignment()), "class space misaligned"); >> } >> #endif >> >> > I'll take a look. > > >> The rest of the code looks OK to me, but I may take a look at it again >> after getting more sleep :-) >> >> > Sure. Thanks man! :) > > > Good news. I ran our tiers 1-4 and there were no failures related to your > changes! > > Neat. This mirrors our results. I'll prepare a new webrev. ..Thomas From adinn at redhat.com Tue May 12 13:19:35 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 12 May 2020 14:19:35 +0100 Subject: [aarch64-port-dev ] RFR: Backport: 823751: AArch64: aarch64TestHook leaks a BufferBlob In-Reply-To: <011c1f56-974a-91e8-7956-11dfd2c1a0f6@redhat.com> References: <011c1f56-974a-91e8-7956-11dfd2c1a0f6@redhat.com> Message-ID: On 12/05/2020 13:02, Andrew Haley wrote: > This is Nick Gasson's patch, adjusted but not changed in any significant > way: > > http://cr.openjdk.java.net/~aph/aarch64-jdk8u/8237512.webrev/ Well, the patch doesn't really need a review but anyway it's reviewed. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From ci_notify at linaro.org Tue May 12 16:48:49 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 12 May 2020 16:48:49 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1279788224.1605.1589302129864.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2020/132/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/20 pass: 5,776; fail: 44 Build 1: aarch64/2020/jan/22 pass: 5,776; fail: 44 Build 2: aarch64/2020/jan/24 pass: 5,775; fail: 45 Build 3: aarch64/2020/jan/27 pass: 5,776; fail: 44 Build 4: aarch64/2020/jan/29 pass: 5,776; fail: 44 Build 5: aarch64/2020/feb/01 pass: 5,777; fail: 46 Build 6: aarch64/2020/feb/03 pass: 5,777; fail: 46 Build 7: aarch64/2020/feb/05 pass: 5,778; fail: 46 Build 8: aarch64/2020/feb/10 pass: 5,781; fail: 46 Build 9: aarch64/2020/feb/12 pass: 5,786; fail: 46 Build 10: aarch64/2020/mar/06 pass: 5,797; fail: 46 Build 11: aarch64/2020/mar/16 pass: 5,796; fail: 47 Build 12: aarch64/2020/apr/08 pass: 5,816; fail: 46; error: 2 Build 13: aarch64/2020/may/09 pass: 5,835; fail: 46 Build 14: aarch64/2020/may/11 pass: 5,835; fail: 46 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/20 pass: 8,830; fail: 529; error: 16 Build 1: aarch64/2020/jan/22 pass: 8,829; fail: 528; error: 19 Build 2: aarch64/2020/jan/24 pass: 8,832; fail: 537; error: 16 Build 3: aarch64/2020/jan/27 pass: 8,846; fail: 523; error: 17 Build 4: aarch64/2020/jan/29 pass: 8,844; fail: 522; error: 19 Build 5: aarch64/2020/feb/01 pass: 8,848; fail: 523; error: 18 Build 6: aarch64/2020/feb/03 pass: 8,851; fail: 525; error: 15 Build 7: aarch64/2020/feb/05 pass: 8,851; fail: 526; error: 15 Build 8: aarch64/2020/feb/10 pass: 8,858; fail: 518; error: 20 Build 9: aarch64/2020/feb/12 pass: 8,849; fail: 525; error: 17 Build 10: aarch64/2020/mar/06 pass: 8,870; fail: 526; error: 17 Build 11: aarch64/2020/mar/16 pass: 8,872; fail: 525; error: 16 Build 12: aarch64/2020/apr/08 pass: 8,891; fail: 532; error: 13 Build 13: aarch64/2020/may/09 pass: 8,929; fail: 543; error: 15 Build 14: aarch64/2020/may/11 pass: 8,929; fail: 544; error: 14 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/15 pass: 4,031 Build 1: aarch64/2020/jan/20 pass: 4,033 Build 2: aarch64/2020/jan/22 pass: 4,033 Build 3: aarch64/2020/jan/24 pass: 4,033 Build 4: aarch64/2020/jan/27 pass: 4,033 Build 5: aarch64/2020/feb/01 pass: 4,036 Build 6: aarch64/2020/feb/03 pass: 4,036 Build 7: aarch64/2020/feb/05 pass: 4,036 Build 8: aarch64/2020/feb/10 pass: 4,037 Build 9: aarch64/2020/feb/12 pass: 4,037 Build 10: aarch64/2020/mar/06 pass: 4,039 Build 11: aarch64/2020/mar/16 pass: 4,039 Build 12: aarch64/2020/apr/08 pass: 4,042 Build 13: aarch64/2020/may/09 pass: 4,052 Build 14: aarch64/2020/may/11 pass: 4,052 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 8.13x Relative performance: Server critical-jOPS (nc): 12.65x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 201.64 Server 201.64 / Server 2014-04-01 (71.00): 2.84x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-16 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/015/results/ 2020-01-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/020/results/ 2020-01-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/022/results/ 2020-01-25 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/024/results/ 2020-01-28 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/027/results/ 2020-02-02 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/032/results/ 2020-02-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/034/results/ 2020-02-06 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/036/results/ 2020-02-11 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/041/results/ 2020-02-13 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/043/results/ 2020-03-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/066/results/ 2020-03-19 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/076/results/ 2020-04-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/099/results/ 2020-05-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/130/results/ 2020-05-12 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/132/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ioi.lam at oracle.com Tue May 12 15:42:33 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 12 May 2020 08:42:33 -0700 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> Message-ID: On 5/12/20 5:41 AM, Thomas St?fe wrote: > > > On Tue, May 12, 2020 at 12:01 AM Ioi Lam > wrote: > > > > On 5/8/20 12:33 AM, Thomas St?fe wrote: >> Hi Ioi, >> >> thanks for taking the time to look at this! >> >> On Fri, May 8, 2020 at 7:37 AM Ioi Lam > > wrote: >> >> Hi Thomas, >> >> I am running your patch in out CI pipeline now. Some comments: >> >> [1] Do we still need to use _class_space_list? It looks like >> we just have a single range. Is >> _class_space_list->current_virtual_space() always the same VS? >> >> ? if (_class_space_list != NULL) { >> ??? address base = >> (address)_class_space_list->current_virtual_space()->bottom(); >> ??? address top = base + compressed_class_space_size(); >> ??? st->print("Compressed class space mapped at: " PTR_FORMAT >> "-" PTR_FORMAT ", size: " SIZE_FORMAT, >> ?????????????? p2i(base), p2i(top), top - base); >> >> >> Yes it is. Has been bugging me for years too. With ccs, the >> VirtualSpaceList is degenerated and only contains one node. It >> still makes some sense code wise. But maybe VirtualSpace*List* is >> a misnomer. >> >> It also ties in into the question whether Metaspace reservations >> should be able to grow on demand. Oracle folks I talk to tend to >> say yes. I personally think the "Metaspace is infinite don't >> worry" meme was broken since ccs was a thing, since >> CompressedClassSpaceSize is an absolute limit already. >> >> I may tweak and simplify the code a bit with Elastic Metaspace. >> Maybe, as you say, with ccs we can get rid of VirtualSpaceList >> and deal with the range directly. Have to check. >> >> [2] Does JDK-8243535 exist with the current jdk/jdk repo? >> >> ? // This does currently not work because rs may be the >> result of a split operation >> ? // and NMT seems not to be able to handle splits. >> ? // See JDK-8243535. >> ? // >> MemTracker::record_virtual_memory_type((address)rs.base(), >> mtClass); >> >> >> Yes. It shows up more rarely. With this patch, it will show up >> always. I had a conversation with Zhengyu about this. I think >> there may be workarounds, like removing the original mapping in >> NMT and replacing it with the two new ones for archive and ccs. >> But it seems iffy, I'd rather have this fixed in NMT. >> >> I also think it is not such a big deal, but if you think >> otherwise, I can integrate a workaround into this patch. > > My question is -- will NMT (or control-backspace) now always > report incorrect memory size for the metaspace when CDS is > enabled? If so, I think a work-around is necessary. > > > What is control backspace? I'm staring at '^H' output in my terminal > and feel like I miss something :) If you have a running foreground JVM in your Linux terminal, you can type "Ctrl-\" and see this. E.g., $ java -cp . SleepForever <...> Heap ?garbage-first heap?? total 1048576K, used 824K [0x0000000412000000, 0x0000000800000000) ? region size 8192K, 1 young (8192K), 0 survivors (0K) ?Metaspace?????? used 143K, capacity 4486K, committed 4864K, reserved 1056768K ? class space??? used 6K, capacity 386K, committed 512K, reserved 1048576K Actually I see that the current output is not correct -- class space doesn't include the CDS sizes :-( I am not sure how many people use this anyway, so it may not be important. Thanks - Ioi > > Today NMT reports wrong memory size at dumptime (I think no-one cares > probably) and at runtime if the archive got relocated. With the patch > NMT will also report wrong numbers at runtime when mapping to default > address. > > But okay, I will add a workaround. > >> >> [3] I think this can be put in header file. >> >> bool Metaspace::class_space_is_initialized() { >> ? return _class_space_list != NULL; >> } >> >> >> Will do. >> >> [4] Why does the CCS need to follow UseLargePagesInMetaspace? >> This is the reason for the >> ??? gap in the following chart: >> >> ??? // We do this by reserving space for the ccs behind the >> archives. Note however that >> ??? //? ccs follows a different alignment >> (Metaspace::reserve_alignment), so there may >> ??? //? be a gap between ccs and cds. >> ??? // We use a similar layout at runtime, see >> reserve_address_space_for_archives(). >> ??? // >> ??? //????????????????????????????? +-- SharedBaseAddress >> (default = 0x800000000) >> ??? //????????????????????????????? v >> ??? // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> ??? // |??? Heap??? | Archive |???? | MC | RW | RO | [gap]? >> |??? class space???? | >> ??? // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> ??? // |<--?? MaxHeapSize? -->| |<-- UnscaledClassSpaceMax = >> 4GB -->| >> >> >> No, nothing to do with large pages. CCS does not have large pages. >> >> The gap can result from different alignment rules between >> metaspace and cds. With Elastic Metaspace, metaspace reservations >> will be aligned to 4M. So, ccs will have to start at a 4M aligned >> border. >> >> >> _reserve_alignment is determined here: >> >> void Metaspace::ergo_initialize() { >> ? if (DumpSharedSpaces) { >> ??? // Using large pages when dumping the shared archive is >> currently not implemented. >> ??? FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >> ? } >> >> ? size_t page_size = os::vm_page_size(); >> ? if (UseLargePages && UseLargePagesInMetaspace) { >> ??? page_size = os::large_page_size(); >> ? } >> >> ? _commit_alignment? = page_size; >> ? _reserve_alignment = MAX2(page_size, >> (size_t)os::vm_allocation_granularity()); >> >> But when CDS is enabled, the RS is reserved without large >> pages, so it should be possible to incrementally commit the >> CCS using just os::vm_allocation_granularity(). >> >> >> Absolutely. CCS does not use large pages for that reason. As I >> wrote, this is about the new reservation granularity of 4M. > > OK, if I understand correctly: > > + With the current patch, the gap exists only when > UseLargePagesInMetaspace is used at run time. The gap actually is > unnecessary, since ccs doesn't use large pages. > > + With the upcoming Elastic Metaspace, _reserve_alignment will be > 4MB, so we will almost always have a gap. > > > Yes. > > Note that we decided to remove the large page feature from Metaspace > with Elastic Metaspace for now, though we may reintroduce it later in > a?different form.?See CSR: > https://bugs.openjdk.java.net/browse/JDK-8243161?. > > >> [5] I see the aarch64 code in >> Metaspace::reserve_address_space_for_compressed_classes has >> been changed. Is this necessary for this RFE, or is it a >> separate improvement that can be done in a different RFE? >> >> >> Well, it had to be changed somewhat, since the prototype differs. >> I swapped Metaspace::reserve_preferred_space() for >> Metaspace::reserve_address_space_for_compressed_classes(), which >> follows a somewhat different protocol. >> >> That aside, the functionality for AARCH64 should be as >> unchanged?as possible. I removed the AIX specific coding, since >> it was subtly?wrong, but that's fine since we are AIX/ppc >> maintainers. >> >> >> [6] For AARCH64, should we skip the part that reserves it >> right above the heap? Or does AARCH64 always allocate the >> heap such that it's a preferable address? >> >> >> Yes and yes :) >> >> We do skip that for aarch64 (at least if the address is wrong): >> >> 1157 // Try right above the Java heap... 1158 address base = >> align_up(CompressedOops::end(), Metaspace::reserve_alignment()); >> 1159 assert(base != NULL, "Sanity"); 1160 1161 const size_t size >> = align_up(CompressedClassSpaceSize, >> Metaspace::reserve_alignment()); 1162 if >> (CompressedKlassPointers::is_valid_base(base)) { 1163 rs = >> ReservedSpace(size, Metaspace::reserve_alignment(), false /* >> large */, (char*)base); 1164 } >> At 1162, we check if the attach address would be valid for this >> platform. If aarch64 says no, we won't reserve there but go >> straight to the "attach wherever you think is good" part. Which >> is implemented >> by?Metaspace::reserve_address_space_for_compressed_classes(), >> which on aarch64 does search a suitable address. >> >> ??? // case (b) >> ??? ReservedSpace rs; >> >> ??? // Try right above the Java heap... >> ??? address base = align_up(CompressedOops::end(), >> Metaspace::reserve_alignment()); >> ??? assert(base != NULL, "Sanity"); >> >> ??? const size_t size = align_up(CompressedClassSpaceSize, >> Metaspace::reserve_alignment()); >> ??? if (CompressedKlassPointers::is_valid_base(base)) { >> ????? rs = ReservedSpace(size, >> Metaspace::reserve_alignment(), false /* large */, (char*)base); >> ??? } >> >> ??? // ...failing that, reserve anywhere, but let platform do >> optimized placement: >> ??? if (!rs.is_reserved()) { >> ????? rs = >> Metaspace::reserve_address_space_for_compressed_classes(size); >> ??? } >> >> [7] argument.cpp checks this: >> >> ? if (UseSharedSpaces || DumpSharedSpaces) { >> ??? if >> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) >> { >> ????? log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is >> invalid for this platform, option will be ignored.", >> p2i((address)SharedBaseAddress)); >> ????? FLAG_SET_DEFAULT(SharedBaseAddress, >> default_SharedBaseAddress()); >> ??? } >> ? } >> >> but initialize_dumptime_shared_and_meta_spaces aligns up the >> SharedBaseAddress before doing the assert. >> >> ? void >> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >> ??? assert(DumpSharedSpaces, "should be called for dump time >> only"); >> >> ??? const size_t reserve_alignment = >> MetaspaceShared::reserved_space_alignment(); >> ??? char* shared_base = >> (char*)align_up((char*)SharedBaseAddress, reserve_alignment); >> >> ? #ifdef _LP64 >> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >> "Sanity"); >> >> So theoretically shared_base may no longer be is_valid_base >> after the align_up. It probably won't happen, but I think the >> code will be much clearer tofirst to align_up, then check for >> is_valid_base and reset to default, and finally assert. >> >> >> Okay, I'll change that. >> >> [8] In >> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, >> the following block can be simplified: >> >> ? if (!_shared_rs.is_reserved()) { >> ??? // Get a reserved space anywhere if attaching at the >> SharedBaseAddress fails: >> ??? if (UseCompressedClassPointers) { >> ????? // If we need a compressed class space too, let the >> platform handle the reservation. >> ????? _shared_rs = >> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >> ??? } else { >> ????? // anywhere is fine. >> ????? _shared_rs = ReservedSpace(cds_total, >> reserve_alignment, false /* large */, (char*)NULL); >> ??? } >> ? } >> >> ?? ... if you change the declaration to: >> >> ? static ReservedSpace >> reserve_address_space_for_compressed_classes(size_t size) >> NOT_LP64({ return ReservedSpace();}); >> >> [9] I think the #ifdef _LP64 is not necessary: >> >> #ifdef _LP64 >> ??? // Some sanity checks after reserving address spaces for >> archives and class space. >> ??? assert(archive_space_rs.is_reserved(), "Sanity"); >> ??? if (Metaspace::using_class_space()) { >> ????? // Class space must closely follow the archive space. >> Both spaces must be aligned correctly. >> ????? assert(class_space_rs.is_reserved(), "A class space >> should have been reserved"); >> ????? assert(class_space_rs.base() >= archive_space_rs.end(), >> "class space should follow the cds archive space"); >> assert(is_aligned(archive_space_rs.base(), >> MetaspaceShared::reserved_space_alignment()), "Archive space >> misaligned"); >> ????? assert(is_aligned(class_space_rs.base(), >> Metaspace::reserve_alignment()), "class space misaligned"); >> ??? } >> #endif >> >> >> I'll take a look. >> >> The rest of the code looks OK to me, but I may take a look at >> it again after getting more sleep :-) >> >> >> Sure. Thanks man! :) > > Good news. I ran our tiers 1-4 and there were no failures related > to your changes! > > > Neat. This mirrors our results. > > I'll prepare a new webrev. > > ..Thomas From ioi.lam at oracle.com Mon May 11 22:01:39 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 11 May 2020 15:01:39 -0700 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> Message-ID: On 5/8/20 12:33 AM, Thomas St?fe wrote: > Hi Ioi, > > thanks for taking the time to look at this! > > On Fri, May 8, 2020 at 7:37 AM Ioi Lam > wrote: > > Hi Thomas, > > I am running your patch in out CI pipeline now. Some comments: > > [1] Do we still need to use _class_space_list? It looks like we > just have a single range. Is > _class_space_list->current_virtual_space() always the same VS? > > ? if (_class_space_list != NULL) { > ??? address base = > (address)_class_space_list->current_virtual_space()->bottom(); > ??? address top = base + compressed_class_space_size(); > ??? st->print("Compressed class space mapped at: " PTR_FORMAT "-" > PTR_FORMAT ", size: " SIZE_FORMAT, > ?????????????? p2i(base), p2i(top), top - base); > > > Yes it is. Has been bugging me for years too. With ccs, the > VirtualSpaceList is degenerated and only contains one node. It still > makes some sense code wise. But maybe VirtualSpace*List* is a misnomer. > > It also ties in into the question whether Metaspace reservations > should be able to grow on demand. Oracle folks I talk to tend to say > yes. I personally think the "Metaspace is infinite don't worry" meme > was broken since ccs was a thing, since CompressedClassSpaceSize is an > absolute limit already. > > I may tweak and simplify the code a bit with Elastic Metaspace. Maybe, > as you say, with ccs we can get rid of VirtualSpaceList and deal with > the range directly. Have to check. > > [2] Does JDK-8243535 exist with the current jdk/jdk repo? > > ? // This does currently not work because rs may be the result of > a split operation > ? // and NMT seems not to be able to handle splits. > ? // See JDK-8243535. > ? // MemTracker::record_virtual_memory_type((address)rs.base(), > mtClass); > > > Yes. It shows up more rarely. With this patch, it will show up always. > I had a conversation with Zhengyu about this. I think there may be > workarounds, like removing the original mapping in NMT and replacing > it with the two new ones for archive and ccs. But it seems iffy, I'd > rather have this fixed in NMT. > > I also think it is not such a big deal, but if you think otherwise, I > can integrate a workaround into this patch. My question is -- will NMT (or control-backspace) now always report incorrect memory size for the metaspace when CDS is enabled? If so, I think a work-around is necessary. > > [3] I think this can be put in header file. > > bool Metaspace::class_space_is_initialized() { > ? return _class_space_list != NULL; > } > > > Will do. > > [4] Why does the CCS need to follow UseLargePagesInMetaspace? This > is the reason for the > ??? gap in the following chart: > > ??? // We do this by reserving space for the ccs behind the > archives. Note however that > ??? //? ccs follows a different alignment > (Metaspace::reserve_alignment), so there may > ??? //? be a gap between ccs and cds. > ??? // We use a similar layout at runtime, see > reserve_address_space_for_archives(). > ??? // > ??? //????????????????????????????? +-- SharedBaseAddress (default > = 0x800000000) > ??? //????????????????????????????? v > ??? // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > ??? // |??? Heap??? | Archive |???? | MC | RW | RO | [gap]? |??? > class space???? | > ??? // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > ??? // |<--?? MaxHeapSize? -->|???? |<-- UnscaledClassSpaceMax = > 4GB -->| > > > No, nothing to do with large pages. CCS does not have large pages. > > The gap can result from different alignment rules between metaspace > and cds. With Elastic Metaspace, metaspace reservations will be > aligned to 4M. So, ccs will have to start at a 4M aligned border. > > > _reserve_alignment is determined here: > > void Metaspace::ergo_initialize() { > ? if (DumpSharedSpaces) { > ??? // Using large pages when dumping the shared archive is > currently not implemented. > ??? FLAG_SET_ERGO(UseLargePagesInMetaspace, false); > ? } > > ? size_t page_size = os::vm_page_size(); > ? if (UseLargePages && UseLargePagesInMetaspace) { > ??? page_size = os::large_page_size(); > ? } > > ? _commit_alignment? = page_size; > ? _reserve_alignment = MAX2(page_size, > (size_t)os::vm_allocation_granularity()); > > But when CDS is enabled, the RS is reserved without large pages, > so it should be possible to incrementally commit the CCS using > just os::vm_allocation_granularity(). > > > Absolutely. CCS does not use large pages for that reason. As I wrote, > this is about the new reservation granularity of 4M. OK, if I understand correctly: + With the current patch, the gap exists only when UseLargePagesInMetaspace is used at run time. The gap actually is unnecessary, since ccs doesn't use large pages. + With the upcoming Elastic Metaspace, _reserve_alignment will be 4MB, so we will almost always have a gap. > [5] I see the aarch64 code in > Metaspace::reserve_address_space_for_compressed_classes has been > changed. Is this necessary for this RFE, or is it a separate > improvement that can be done in a different RFE? > > > Well, it had to be changed somewhat, since the prototype differs. I > swapped Metaspace::reserve_preferred_space() for > Metaspace::reserve_address_space_for_compressed_classes(), which > follows a somewhat different protocol. > > That aside, the functionality for AARCH64 should be as unchanged?as > possible. I removed the AIX specific coding, since it was > subtly?wrong, but that's fine since we are AIX/ppc maintainers. > > > [6] For AARCH64, should we skip the part that reserves it right > above the heap? Or does AARCH64 always allocate the heap such that > it's a preferable address? > > > Yes and yes :) > > We do skip that for aarch64 (at least if the address is wrong): > > 1157 // Try right above the Java heap... 1158 address base = > align_up(CompressedOops::end(), Metaspace::reserve_alignment()); 1159 > assert(base != NULL, "Sanity"); 1160 1161 const size_t size = > align_up(CompressedClassSpaceSize, Metaspace::reserve_alignment()); > 1162 if (CompressedKlassPointers::is_valid_base(base)) { 1163 rs = > ReservedSpace(size, Metaspace::reserve_alignment(), false /* large */, > (char*)base); 1164 } > At 1162, we check if the attach address would be valid for this > platform. If aarch64 says no, we won't reserve there but go straight > to the "attach wherever you think is good" part. Which is implemented > by?Metaspace::reserve_address_space_for_compressed_classes(), which on > aarch64 does search a suitable address. > > ??? // case (b) > ??? ReservedSpace rs; > > ??? // Try right above the Java heap... > ??? address base = align_up(CompressedOops::end(), > Metaspace::reserve_alignment()); > ??? assert(base != NULL, "Sanity"); > > ??? const size_t size = align_up(CompressedClassSpaceSize, > Metaspace::reserve_alignment()); > ??? if (CompressedKlassPointers::is_valid_base(base)) { > ????? rs = ReservedSpace(size, Metaspace::reserve_alignment(), > false /* large */, (char*)base); > ??? } > > ??? // ...failing that, reserve anywhere, but let platform do > optimized placement: > ??? if (!rs.is_reserved()) { > ????? rs = > Metaspace::reserve_address_space_for_compressed_classes(size); > ??? } > > [7] argument.cpp checks this: > > ? if (UseSharedSpaces || DumpSharedSpaces) { > ??? if > (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) > { > ????? log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is > invalid for this platform, option will be ignored.", > ?????????????????????? p2i((address)SharedBaseAddress)); > ????? FLAG_SET_DEFAULT(SharedBaseAddress, > default_SharedBaseAddress()); > ??? } > ? } > > but initialize_dumptime_shared_and_meta_spaces aligns up the > SharedBaseAddress before doing the assert. > > ? void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { > ??? assert(DumpSharedSpaces, "should be called for dump time only"); > > ??? const size_t reserve_alignment = > MetaspaceShared::reserved_space_alignment(); > ??? char* shared_base = (char*)align_up((char*)SharedBaseAddress, > reserve_alignment); > > ? #ifdef _LP64 > assert(CompressedKlassPointers::is_valid_base((address)shared_base), > "Sanity"); > > So theoretically shared_base may no longer be is_valid_base after > the align_up. It probably won't happen, but I think the code will > be much clearer tofirst to align_up, then check for is_valid_base > and reset to default, and finally assert. > > > Okay, I'll change that. > > [8] In > MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the > following block can be simplified: > > ? if (!_shared_rs.is_reserved()) { > ??? // Get a reserved space anywhere if attaching at the > SharedBaseAddress fails: > ??? if (UseCompressedClassPointers) { > ????? // If we need a compressed class space too, let the platform > handle the reservation. > ????? _shared_rs = > Metaspace::reserve_address_space_for_compressed_classes(cds_total); > ??? } else { > ????? // anywhere is fine. > ????? _shared_rs = ReservedSpace(cds_total, reserve_alignment, > false /* large */, (char*)NULL); > ??? } > ? } > > ?? ... if you change the declaration to: > > ? static ReservedSpace > reserve_address_space_for_compressed_classes(size_t size) > NOT_LP64({ return ReservedSpace();}); > > [9] I think the #ifdef _LP64 is not necessary: > > #ifdef _LP64 > ??? // Some sanity checks after reserving address spaces for > archives and class space. > ??? assert(archive_space_rs.is_reserved(), "Sanity"); > ??? if (Metaspace::using_class_space()) { > ????? // Class space must closely follow the archive space. Both > spaces must be aligned correctly. > ????? assert(class_space_rs.is_reserved(), "A class space should > have been reserved"); > ????? assert(class_space_rs.base() >= archive_space_rs.end(), > "class space should follow the cds archive space"); > ????? assert(is_aligned(archive_space_rs.base(), > MetaspaceShared::reserved_space_alignment()), "Archive space > misaligned"); > ????? assert(is_aligned(class_space_rs.base(), > Metaspace::reserve_alignment()), "class space misaligned"); > ??? } > #endif > > > I'll take a look. > > The rest of the code looks OK to me, but I may take a look at it > again after getting more sleep :-) > > > Sure. Thanks man! :) Good news. I ran our tiers 1-4 and there were no failures related to your changes! Thanks - Ioi > > ..Thomas > > Thanks > - Ioi > > > > > On 5/7/20 7:21 AM, Thomas St?fe wrote: >> Hi all, >> >> please take a look at the third iteration of this change: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >> >> Changes in this version: >> >> - at the request of Coleen (sorry I did not see your post >> earlier) I removed all platform dependent?files and put the >> platform dependent coding back to metaspace.cpp and >> compressedOops.cpp to ease the review pain. I used plain platform >> defines though (#ifdef AARCH64) instead of hiding them behind >> another macro to make things clearer. Note that I still intent to >> put this code away into the platform corners but will do so in a >> follow up RFE. >> >> - I reinstated, in a fashion, the special handling of >> reservations on Windows. On all platforms we reserve address >> space to map the archive files in with a subsequent mapping >> operation. However, on Windows, we cannot use MapViewOfFile() >> into an existing mapping. So I remove the mapping again before >> mapping the archives - see comment in code for details. >> >> All CI tests at SAP run through without problems, including on >> Win64 and aarch64, but I would be happy if others were to run >> test too. >> >> Thank you, Thomas >> >> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >> > wrote: >> >> Hi all, >> >> Could I have reviews for the following proposal of reworking >> cds/class space reservation? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >> >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >> >> (Many thanks to Ioi Lam for so patiently explaining CDS >> internals to me, and to Andrew Haley and Nick Gasson for help >> with aarch64!) >> >> Reservation of the compressed class space is needlessly >> complicated and has some minor issues. It can be simplified >> and made clearer. >> >> The complexity stems from the fact that this area lives at >> the intersection of two to three sub systems, depending on >> how one counts. Metaspace, CDS, and the platform which may or >> may not its own view of how to reserve class space. And this >> code has been growing organically over time. >> >> One small example: >> >> ReservedSpace Metaspace::reserve_preferred_space(size_t size, >> size_t alignment, >> ?bool large_pages, char *requested_addr, >> ?bool use_requested_addr) >> >> which I spent hours decoding, resulting in a very confused >> mail to hs-runtime and aarch64-port-dev [2]. >> >> This patch attempts to simplify cds and metaspace setup a >> bit; to comment implicit knowledge which is not immediately >> clear; to cleanly abstract platform concerns like optimized >> class space placement; and to disentangle cds from metaspace >> to solve issues which may bite us later with Elastic >> Metaspace [4]. >> >> --- >> >> The main change is the reworked reservation mechanism. This >> is based on Ioi's proposal [5]. >> >> When reserving class space, three things must happen: >> >> 1) reservation of the space obviously. If cds is active that >> space must be in the vicinity of cds archives to be covered >> by compressed class pointer encoding. >> 2) setting up the internal Metaspace structures atop of that >> space >> 3) setting up compressed class pointer encoding. >> >> In its current form, Metaspace may or may not do some or all >> of that in one function >> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base);) - if >> cds is active, it will reserve the space for Metaspace and >> hand it in, otherwise it will create it itself. >> >> When discussing this in [2], Ioi proposed to move the >> reservation of the class space completely out of Metaspace >> and make it a responsibility of the caller always. This would >> reduce some complexity, and this patch follows the proposal. >> >> I removed >> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base); and >> all its sub functions. >> >> (1) now has to always be done outside - a ReservedSpace for >> class space has to be provided by the caller. However, >> Metaspace now offers a utility function for reserving space >> at a "nice" location, and explicitly doing nothing else: >> >> ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t >> size); >> >> this function can be redefined on a platform level for >> platform optimized reservation, see below for details. >> >> (2) is taken care of by a new function, >> Metaspace::initialize_class_space(ReservedSpace rs) >> >> (3) is taken care of a new function >> CompressedKlassPointers::initialize(), see below for details. >> >> >> So, class space now is set up three explicit steps: >> >> - First, reserve a suitable space by however means you want. >> For convenience you may use >> Metaspace::reserve_address_space_for_compressed_classes(), or >> you may roll your own reservation. >> - Next, tell Metaspace to use that range as backing storage >> for class space: >> Metaspace::initialize_class_space(ReservedSpace rs) >> - Finally, set up encoding. Encoding is independent from the >> concept of a ReservedSpace, it just gets an address range, >> see below for details. >> >> Separating these steps and moving them out of the >> responsibility of Metaspace makes this whole thing more >> flexible; it also removes unnecessary knowledge (e.g. >> Metaspace does not need to know anything about either ccp >> encoding or cds). >> >> --- >> >> How it comes together: >> >> If CDS is off, we just reserve a space using >> Metaspace::reserve_address_space_for_compressed_classes(), >> initialize it with >> Metaspace::initialize_class_space(ReservedSpace rs), then set >> up compressed class pointer encoding covering the range of >> this class space. >> >> If CDS is on (dump time), we reserve large 4G space, either >> at SharedBaseAddress or using >> Metaspace::reserve_address_space_for_compressed_classes(); we >> then split that into 3G archive space and 1G class space; we >> set up that space with Metaspace as class space; then we set >> up?compressed class pointer encoding covering both archive >> space and cds. >> >> If CDS is on (run time), we reserve a large space, split it >> into archive space (large enough to hold both archives) and >> class space, then basically proceed as above. >> >> Note that this is almost exactly how things worked before >> (modulo some minor fixes, e.g. alignment issues), only the >> code is reformed and made more explicit. >> >> --- >> >> I moved compressed class pointer setup over to >> CompressedKlassPointers and changed the interface: >> >> -void >> Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >> metaspace_rs, address cds_base) >> +void CompressedKlassPointers::initialize(address addr, >> size_t len); >> >> Instead of feeding it a single ReservedSpace, which is >> supposed to represent class space, and an optional alternate >> base if cds is on, now we give it just an numeric address >> range. That range marks the limits to where Klass structures >> are to be expected, and is the implicit promise that outside >> that range no Klass structures will exist, so encoding has to >> cover only this range. >> >> This range may contain just the class space; or class >> space+cds; or whatever allocation scheme we come up with in >> the future. Encoding does not really care how the memory is >> organized as long as the input range covers all possible >> Klass locations. That way we remove knowledge about class >> space/cds from compressed class pointer encoding. >> >> Moving it away from metaspace.cpp into the >> CompressedKlassPointers class also mirrors >> CompressedOops::initialize(). >> >> --- >> >> I renamed _narrow_klass_range to just _range, because >> strictly speaking this is the range un-narrow Klass pointers >> can have. >> >> As for the implementation of >> CompressedKlassPointers::initialize(address addr, size_t >> len), I mimicked very closely what happened before, so there >> should be almost no differences. Since "almost no >> differences" sounds scary :) here are the differences: >> >> - When CDS is active (dump or run time) we now always, >> unconditionally, set the encoding range to 4G. This fixes a >> theoretical bug discussed on aarch64-port-dev [1]. >> >> - When CDS is not active, we set the encoding range to the >> minimum required length. Before, it was left at its default >> value of 4G. >> >> Both differences only affect aarch64, since they are >> currently the only one using the range field in >> CompressedKlassPointers. >> >> I wanted to add an assert somewhere to test encoding of the >> very last address of the CompressedKlassPointers range, again >> to prevent errors like [3]. But I did not come up with a good >> place for this assert which would cover also the encoding >> done by C1/C2. >> >> For the same reason I thought about introducing a mode where >> Klass structures would be allocated in reverse order, >> starting at the end of the ccs, but again left it out as too >> big a change. >> >> --- >> >> OS abstraction: platforms may have restrictions of what >> constitutes a valid compressed class pointer encoding base. >> Or if not, they may have at least preferences. There was >> logic like this in metaspace.cpp, which I removed and cleanly >> factored out into platform dependent files, giving each >> platform the option to add special logic. >> >> These are two new methods: >> >> - bool CompressedKlassPointers::is_valid_base(address p) >> >> to let the platform tell you whether it considers p to be a >> valid encoding base. The only platform having these >> restrictions currently is aarch64. >> >> - ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t >> size); >> >> this hands over the process of allocating a range suitable >> for compressed class pointer encoding to the platform. Most >> platforms will allocate just anywhere, but some platforms may >> have a better strategy (e.g. trying low memory first, trying >> only correctly aligned addresses and so on). >> >> Beforehand, this coding existed in a similar form in >> metaspace.cpp for aarch64 and AIX. For now, I left the AIX >> part out - it seems only half done, and I want to check >> further if we even need it, if yes why not on Linux ppc, and >> C1 does not seem to support anything other than base+offset >> with shift either, but I may be mistaken. >> >> These two methods should give the platform enough control to >> implement their own scheme for optimized class space >> placement without bothering any shared code about it. >> >> Note about the form, I introduced two new platform dependent >> files, "metaspace_.cpp" and "compressedOops_.cpp". >> I am not happy about this but this seems to be what we >> generally do in hotspot, right? >> >> --- >> >> Metaspace reserve alignment vs cds alignment >> >> CDS was using Metaspace reserve alignment for CDS internal >> purposes. I guess this was just a copy paste issue. It never >> caused problems since Metaspace reserve alignment == page >> size, but that is not true anymore in the upcoming Elastic >> Metaspace where reserve alignment will be larger. This causes >> a number of issues. >> >> I separated those two cleanly. CDS now uses >> os::vm_allocation_granularity. Metaspace::reserve_alignment >> is only used in those two places where it is needed, when CDS >> creates the address space for class space on behalf of the >> Metaspace. >> >> --- >> >> Windows special handling in CDS >> >> To simplify coding I removed the windows specific handling >> which left out reservation of the archive. This was needed >> because windows cannot mmap files into reserved regions. But >> fallback code exists in filemap.cpp for this case which just >> reads in the region instead of mapping?it. >> >> Should that turn out to be a performance problem, I will >> reinstate the feature. But a simpler way would be reserve the >> archive and later just before mmapping?the archive file to >> release the archive space. That would not only be simpler but >> give us the best guarantee that that address space is >> actually available. But I'd be happy to leave that part out >> completely if we do not see any performance problems on >> windows x64. >> >> --- >> >> NMT cannot deal with spaces which are split. This problem >> manifests in that bookkeeping for class space is done under >> "Shared Classes", not "Classes" as it should. This problem >> exists today too at dump?time and randomly at run time. But >> since I simplified the reservation, this problem now shows up >> always, whether or not we map at the SharedBaseAddress. >> While I could work around this problem, I'd prefer this >> problem to be solved at the core, and NMT to have an option >> to recognize reservation splits. So I'd rather not put a >> workaround for this into the patch but leave it for fixing as >> a separate issue. I opened this issue to track it [6]. >> >> --- >> >> Jtreg tests: >> >> I expanded the CompressedOops/CompressedClassPointers.java. I >> also extended them to Windows. The tests now optionally omit >> strict class space placement tests, since these tests heavily >> depend on ASLR and were the reason they were excluded on >> Windows. However I think even without checking for class >> space placement they make sense, just to see that the VM >> comes up and lives with the many different settings we can >> run in. >> >> --- >> >> Tests: >> >> - I ran the patch through Oracles submit repo >> - I ran tests manually for aarch64, zero, linux 32bit and >> windows x64 >> - The whole battery of nightly tests at SAP, including ppc, >> ppcle and aarch64, unfortunately excluding windows because of >> unrelated errors. Windows x64 tests will be redone tonight. >> >> >> Thank you, >> >> Thomas >> >> [1] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >> [2] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >> [5] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >> > From derekw at marvell.com Wed May 13 20:20:37 2020 From: derekw at marvell.com (Derek White) Date: Wed, 13 May 2020 20:20:37 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: Message-ID: Hi Xiaohong, This looks good to me (not a (R)eviewer). Thanks for including the patch for ThunderX ! This is a nice cleanup of the code and especially the volatile tests. I did NOT check that the removal of the Compiler Interface declarations does or doesn't impact compilation of the Graal compiler. Did you check that side? Thanks, - Derek -----Original Message----- From: hotspot-compiler-dev On Behalf Of Xiaohong Gong Sent: Thursday, May 7, 2020 11:39 PM To: aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: [EXT] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option External Email ---------------------------------------------------------------------- Hi, Please help to review this patch which obsoletes the product flag "-XX:UseBarrierssForVolatile" and its related code: Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Exgong_rfr_8243339_webrev.00_&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=oI-OcgRUa25GiBZaU5V4OmuS8aewSxBaMLbKw3A7lnA&e= JBS: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243339&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=T-oDfXrBvQorUBzFZq7Omb17P5yqQjg_q3dBo4EExCA&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243456&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=MDMAqUQRO_kmBtmTodGJ2wNuaVy-u_Y_jykpMmyMQwI&e= (CSR) As described in the CSR, using "-XX:+UseBarriersForVolatile" might have memory consistent issue like that mentioned in [1]. It needs more effort to fix the issue and maintain the memory consistency in future. Since "ldar/stlr" has worked well for a long time, and so does "ldaxr/stlxr" for unsafe atomics, we'd better simplify things by removing this option and the alternative implementation for the volatile access. Since its only one signifcant usage on a kind of CPU would also like to be removed (See [2]), it can work well without this option. So we directly obsolete this option and remove the code, rather than deprecate it firstly. Besides obsoleting this option, this patch also removes an AArch64 CPU feature "CPU_DMB_ATOMICS" together. It is a workaround while not an AArch64 official feature, which is not required anymore (See [2]). [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8241137&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=XQwo26nMgDENOKN5U4pW2EunOEt2UtLycucN1BCScaU&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8242469&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=ChT4b4Jj_TkXozuRs6HIqUVPn1iap0DzKvB-2dKYf0g&e= Testing: Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core, langtools::tier1 JCStress: tests-all Thanks, Xiaohong Gong From gnu.andrew at redhat.com Wed May 13 22:26:34 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 13 May 2020 23:26:34 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b02 Upstream Sync Message-ID: <5964076f-9adf-8d73-0263-887ae1a7a165@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/root/merge.changeset Changes in aarch64-shenandoah-jdk8u262-b02: - JDK-8130737: AffineTransformOp can't handle child raster with non-zero x-offset - JDK-8172559: [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Raster/TestChildRasterOp.java - JDK-8230926: [macosx] Two apostrophes are entered instead of one with "U.S. International - PC" layout - JDK-8240576: JVM crashes after transformation in C2 IdealLoopTree::merge_many_backedges - JDK-8242883: Incomplete backport of JDK-8078268: backport test part Main issues of note: Much simpler this time; clean merge, only one HotSpot change. 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/src/macosx/classes/sun/lwawt/macosx/CPlatformResponder.java | 7 b/src/macosx/classes/sun/lwawt/macosx/LWCToolkit.java | 17 b/src/share/native/sun/awt/medialib/awt_ImagingLib.c | 14 b/src/share/native/sun/awt/medialib/safe_alloc.h | 4 b/test/java/awt/image/Raster/TestChildRasterOp.java | 99 b/test/javax/swing/text/html/parser/Parser/8078268/bug8078268.java | 72 b/test/javax/swing/text/html/parser/Parser/8078268/slowparse.html | 3539 ++++++++++ 8 files changed, 3743 insertions(+), 10 deletions(-) diffstat for hotspot b/.hgtags | 1 b/src/share/vm/opto/loopnode.cpp | 2 b/test/compiler/loopopts/TestBeautifyLoops.java | 61 ++++++++++++++++++++++++ 3 files changed, 63 insertions(+), 1 deletion(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer 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 Xiaohong.Gong at arm.com Thu May 14 01:17:44 2020 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Thu, 14 May 2020 01:17:44 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: Message-ID: Hi Derek, Thanks for your review! > I did NOT check that the removal of the Compiler Interface declarations does or doesn't impact compilation of the Graal compiler. Did you check that side? Yes, sure! I have checked the impact for Graal compiler. The removed interfaces are not used in Graal compiler. The only used one is the CPU feature "DMB_ATOMICS", and it's used in Graal native-image. I will create another patch for graal substratevm to remove it. Thanks, Xiaohong -----Original Message----- From: Derek White Sent: Thursday, May 14, 2020 4:21 AM To: Xiaohong Gong ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: RE: RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option Hi Xiaohong, This looks good to me (not a (R)eviewer). Thanks for including the patch for ThunderX ! This is a nice cleanup of the code and especially the volatile tests. I did NOT check that the removal of the Compiler Interface declarations does or doesn't impact compilation of the Graal compiler. Did you check that side? Thanks, - Derek -----Original Message----- From: hotspot-compiler-dev On Behalf Of Xiaohong Gong Sent: Thursday, May 7, 2020 11:39 PM To: aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: [EXT] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option External Email ---------------------------------------------------------------------- Hi, Please help to review this patch which obsoletes the product flag "-XX:UseBarrierssForVolatile" and its related code: Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Exgong_rfr_8243339_webrev.00_&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=oI-OcgRUa25GiBZaU5V4OmuS8aewSxBaMLbKw3A7lnA&e= JBS: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243339&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=T-oDfXrBvQorUBzFZq7Omb17P5yqQjg_q3dBo4EExCA&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243456&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=MDMAqUQRO_kmBtmTodGJ2wNuaVy-u_Y_jykpMmyMQwI&e= (CSR) As described in the CSR, using "-XX:+UseBarriersForVolatile" might have memory consistent issue like that mentioned in [1]. It needs more effort to fix the issue and maintain the memory consistency in future. Since "ldar/stlr" has worked well for a long time, and so does "ldaxr/stlxr" for unsafe atomics, we'd better simplify things by removing this option and the alternative implementation for the volatile access. Since its only one signifcant usage on a kind of CPU would also like to be removed (See [2]), it can work well without this option. So we directly obsolete this option and remove the code, rather than deprecate it firstly. Besides obsoleting this option, this patch also removes an AArch64 CPU feature "CPU_DMB_ATOMICS" together. It is a workaround while not an AArch64 official feature, which is not required anymore (See [2]). [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8241137&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=XQwo26nMgDENOKN5U4pW2EunOEt2UtLycucN1BCScaU&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8242469&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=ChT4b4Jj_TkXozuRs6HIqUVPn1iap0DzKvB-2dKYf0g&e= Testing: Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core, langtools::tier1 JCStress: tests-all Thanks, Xiaohong Gong From derekw at marvell.com Thu May 14 03:21:40 2020 From: derekw at marvell.com (Derek White) Date: Thu, 14 May 2020 03:21:40 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: Message-ID: OK, that sounds good to me. - Derek -----Original Message----- From: Xiaohong Gong Sent: Wednesday, May 13, 2020 9:18 PM To: Derek White ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: RE: RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option Hi Derek, Thanks for your review! > I did NOT check that the removal of the Compiler Interface declarations does or doesn't impact compilation of the Graal compiler. Did you check that side? Yes, sure! I have checked the impact for Graal compiler. The removed interfaces are not used in Graal compiler. The only used one is the CPU feature "DMB_ATOMICS", and it's used in Graal native-image. I will create another patch for graal substratevm to remove it. Thanks, Xiaohong -----Original Message----- From: Derek White Sent: Thursday, May 14, 2020 4:21 AM To: Xiaohong Gong ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: RE: RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option Hi Xiaohong, This looks good to me (not a (R)eviewer). Thanks for including the patch for ThunderX ! This is a nice cleanup of the code and especially the volatile tests. I did NOT check that the removal of the Compiler Interface declarations does or doesn't impact compilation of the Graal compiler. Did you check that side? Thanks, - Derek -----Original Message----- From: hotspot-compiler-dev On Behalf Of Xiaohong Gong Sent: Thursday, May 7, 2020 11:39 PM To: aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: [EXT] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option External Email ---------------------------------------------------------------------- Hi, Please help to review this patch which obsoletes the product flag "-XX:UseBarrierssForVolatile" and its related code: Webrev: https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Exgong_rfr_8243339_webrev.00_&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=oI-OcgRUa25GiBZaU5V4OmuS8aewSxBaMLbKw3A7lnA&e= JBS: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243339&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=T-oDfXrBvQorUBzFZq7Omb17P5yqQjg_q3dBo4EExCA&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243456&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=MDMAqUQRO_kmBtmTodGJ2wNuaVy-u_Y_jykpMmyMQwI&e= (CSR) As described in the CSR, using "-XX:+UseBarriersForVolatile" might have memory consistent issue like that mentioned in [1]. It needs more effort to fix the issue and maintain the memory consistency in future. Since "ldar/stlr" has worked well for a long time, and so does "ldaxr/stlxr" for unsafe atomics, we'd better simplify things by removing this option and the alternative implementation for the volatile access. Since its only one signifcant usage on a kind of CPU would also like to be removed (See [2]), it can work well without this option. So we directly obsolete this option and remove the code, rather than deprecate it firstly. Besides obsoleting this option, this patch also removes an AArch64 CPU feature "CPU_DMB_ATOMICS" together. It is a workaround while not an AArch64 official feature, which is not required anymore (See [2]). [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8241137&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=XQwo26nMgDENOKN5U4pW2EunOEt2UtLycucN1BCScaU&e= [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8242469&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=ChT4b4Jj_TkXozuRs6HIqUVPn1iap0DzKvB-2dKYf0g&e= Testing: Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core, langtools::tier1 JCStress: tests-all Thanks, Xiaohong Gong From shade at redhat.com Thu May 14 05:59:03 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 14 May 2020 07:59:03 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b02 Upstream Sync In-Reply-To: <5964076f-9adf-8d73-0263-887ae1a7a165@redhat.com> References: <5964076f-9adf-8d73-0263-887ae1a7a165@redhat.com> Message-ID: <9ddc978f-3863-1970-9829-7546c1d90dc2@redhat.com> On 5/14/20 12:26 AM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jdk/merge.changeset Looks good. (Ok, this is a fun "" one). > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/root/merge.changeset Look trivially good. > Ok to push? Yes. -- Thanks, -Aleksey From ci_notify at linaro.org Thu May 14 06:21:28 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 14 May 2020 06:21:28 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 14 on AArch64 Message-ID: <1890557947.1835.1589437288745.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/openjdk-jtreg-nightly-tests/summary/2020/133/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 5,773; fail: 45 Build 1: aarch64/2020/jan/30 pass: 5,773; fail: 45 Build 2: aarch64/2020/feb/06 pass: 5,773; fail: 46 Build 3: aarch64/2020/feb/09 pass: 5,775; fail: 44 Build 4: aarch64/2020/apr/07 pass: 5,781; fail: 45 Build 5: aarch64/2020/may/05 pass: 5,762; fail: 45 Build 6: aarch64/2020/may/07 pass: 5,763; fail: 44 Build 7: aarch64/2020/may/12 pass: 5,761; fail: 46 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 8,831; fail: 524; error: 18 Build 1: aarch64/2020/jan/30 pass: 8,839; fail: 518; error: 17 Build 2: aarch64/2020/feb/06 pass: 8,838; fail: 517; error: 18 Build 3: aarch64/2020/feb/09 pass: 8,832; fail: 523; error: 18 Build 4: aarch64/2020/apr/07 pass: 8,844; fail: 505; error: 20 Build 5: aarch64/2020/may/05 pass: 8,839; fail: 515; error: 18 Build 6: aarch64/2020/may/07 pass: 8,835; fail: 517; error: 20 Build 7: aarch64/2020/may/12 pass: 8,836; fail: 517; error: 19 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 4,031 Build 1: aarch64/2020/jan/30 pass: 4,031 Build 2: aarch64/2020/feb/03 pass: 4,031 Build 3: aarch64/2020/feb/06 pass: 4,031 Build 4: aarch64/2020/feb/09 pass: 4,031 Build 5: aarch64/2020/apr/07 pass: 4,031 Build 6: aarch64/2020/may/05 pass: 4,031 Build 7: aarch64/2020/may/07 pass: 4,031 Build 8: aarch64/2020/may/12 pass: 4,031 Previous results can be found here: http://openjdk.linaro.org/jdk14/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.63x Relative performance: Server critical-jOPS (nc): 9.13x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/023/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/037/results/ 2020-02-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/040/results/ 2020-04-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/098/results/ 2020-05-06 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/126/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/128/results/ 2020-05-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/133/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/ From ci_notify at linaro.org Thu May 14 06:26:58 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Thu, 14 May 2020 06:26:58 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <1086970317.1839.1589437618535.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2020/133/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/10 pass: 838; fail: 13; error: 1 Build 1: aarch64/2019/sep/21 pass: 838; fail: 13; error: 1 Build 2: aarch64/2019/nov/02 pass: 843; fail: 9; error: 1 Build 3: aarch64/2019/nov/14 pass: 843; fail: 9; error: 1 Build 4: aarch64/2019/dec/16 pass: 843; fail: 10; error: 1 Build 5: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 Build 6: aarch64/2019/dec/19 pass: 846; fail: 10; error: 2 Build 7: aarch64/2019/dec/21 pass: 848; fail: 10; error: 2 Build 8: aarch64/2020/jan/09 pass: 848; fail: 10; error: 1 Build 9: aarch64/2020/jan/11 pass: 848; fail: 10; error: 1 Build 10: aarch64/2020/jan/20 pass: 848; fail: 10; error: 1 Build 11: aarch64/2020/jan/25 pass: 848; fail: 10; error: 1 Build 12: aarch64/2020/may/06 pass: 885; fail: 12; error: 1 Build 13: aarch64/2020/may/10 pass: 885; fail: 12; error: 1 Build 14: aarch64/2020/may/12 pass: 885; fail: 12; error: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/21 pass: 5,964; fail: 261; error: 22 Build 1: aarch64/2019/nov/02 pass: 5,956; fail: 278; error: 18 Build 2: aarch64/2019/nov/14 pass: 5,956; fail: 275; error: 21 Build 3: aarch64/2019/dec/16 pass: 5,964; fail: 267; error: 21 Build 4: aarch64/2019/dec/17 pass: 5,963; fail: 267; error: 22 Build 5: aarch64/2019/dec/19 pass: 5,959; fail: 272; error: 21 Build 6: aarch64/2019/dec/21 pass: 5,970; fail: 262; error: 21 Build 7: aarch64/2020/jan/09 pass: 5,963; fail: 276; error: 20 Build 8: aarch64/2020/jan/11 pass: 5,959; fail: 279; error: 21 Build 9: aarch64/2020/jan/20 pass: 5,987; fail: 256; error: 24 Build 10: aarch64/2020/jan/25 pass: 5,962; fail: 285; error: 22 Build 11: aarch64/2020/feb/03 pass: 5,976; fail: 278; error: 19 Build 12: aarch64/2020/may/06 pass: 5,998; fail: 281; error: 21 Build 13: aarch64/2020/may/10 pass: 6,025; fail: 695; error: 21 Build 14: aarch64/2020/may/12 pass: 6,011; fail: 709; error: 21 1 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/10 pass: 3,116; fail: 2 Build 1: aarch64/2019/sep/21 pass: 3,116; fail: 2 Build 2: aarch64/2019/nov/02 pass: 3,116; fail: 2 Build 3: aarch64/2019/nov/14 pass: 3,116; fail: 2 Build 4: aarch64/2019/dec/16 pass: 3,116; fail: 2 Build 5: aarch64/2019/dec/17 pass: 3,117; fail: 2 Build 6: aarch64/2019/dec/19 pass: 3,117; fail: 2 Build 7: aarch64/2019/dec/21 pass: 3,117; fail: 2 Build 8: aarch64/2020/jan/09 pass: 3,117; fail: 2 Build 9: aarch64/2020/jan/11 pass: 3,117; fail: 2 Build 10: aarch64/2020/jan/20 pass: 3,117; fail: 2 Build 11: aarch64/2020/jan/25 pass: 3,117; fail: 2 Build 12: aarch64/2020/may/06 pass: 3,117; fail: 2 Build 13: aarch64/2020/may/10 pass: 3,117; fail: 2 Build 14: aarch64/2020/may/12 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 6.73x Relative performance: Server critical-jOPS (nc): 8.42x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 172.13 Server 172.13 / Server 2014-04-01 (71.00): 2.42x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-09-11 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/253/results/ 2019-09-22 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/264/results/ 2019-11-02 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/306/results/ 2019-11-15 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/318/results/ 2019-12-16 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/350/results/ 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ 2019-12-19 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/353/results/ 2019-12-22 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/355/results/ 2020-01-09 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/009/results/ 2020-01-11 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/011/results/ 2020-01-20 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/020/results/ 2020-01-25 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/025/results/ 2020-05-06 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/127/results/ 2020-05-10 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/131/results/ 2020-05-14 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/133/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From adinn at redhat.com Thu May 14 08:48:47 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 14 May 2020 09:48:47 +0100 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: Message-ID: Hi Xiaohong, Just for references a direct link to the webrev, issue and CSR are: https://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8243339 https://bugs.openjdk.java.net/browse/JDK-8243456 The webrev looks fine to me. Nice work, thank you! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 13/05/2020 21:20, Derek White wrote: > Hi Xiaohong, > > This looks good to me (not a (R)eviewer). Thanks for including the patch for ThunderX ! > > This is a nice cleanup of the code and especially the volatile tests. > > I did NOT check that the removal of the Compiler Interface declarations does or doesn't impact compilation of the Graal compiler. Did you check that side? > > Thanks, > - Derek > > -----Original Message----- > From: hotspot-compiler-dev On Behalf Of Xiaohong Gong > Sent: Thursday, May 7, 2020 11:39 PM > To: aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Cc: nd > Subject: [EXT] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option > > External Email > > ---------------------------------------------------------------------- > Hi, > > Please help to review this patch which obsoletes the product flag "-XX:UseBarrierssForVolatile" and its related code: > Webrev: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Exgong_rfr_8243339_webrev.00_&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=oI-OcgRUa25GiBZaU5V4OmuS8aewSxBaMLbKw3A7lnA&e= > JBS: > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243339&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=T-oDfXrBvQorUBzFZq7Omb17P5yqQjg_q3dBo4EExCA&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243456&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=MDMAqUQRO_kmBtmTodGJ2wNuaVy-u_Y_jykpMmyMQwI&e= (CSR) > > As described in the CSR, using "-XX:+UseBarriersForVolatile" might have memory consistent issue like that mentioned in [1]. It needs more effort to fix the issue and maintain the memory consistency in future. Since "ldar/stlr" has worked well for a long time, and so does "ldaxr/stlxr" for unsafe atomics, we'd better simplify things by removing this option and the alternative implementation for the volatile access. > > Since its only one signifcant usage on a kind of CPU would also like to be removed (See [2]), it can work well without this option. So we directly obsolete this option and remove the code, rather than deprecate it firstly. > > Besides obsoleting this option, this patch also removes an AArch64 CPU feature "CPU_DMB_ATOMICS" together. It is a workaround while not an AArch64 official feature, which is not required anymore (See [2]). > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8241137&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=XQwo26nMgDENOKN5U4pW2EunOEt2UtLycucN1BCScaU&e= > [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8242469&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=ChT4b4Jj_TkXozuRs6HIqUVPn1iap0DzKvB-2dKYf0g&e= > > Testing: > Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core, langtools::tier1 > JCStress: tests-all > > Thanks, > Xiaohong Gong > > From Xiaohong.Gong at arm.com Thu May 14 08:52:28 2020 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Thu, 14 May 2020 08:52:28 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: Message-ID: Hi Andrew, Thanks for your review and the direct reference links! Thanks, Xiaohong Gong -----Original Message----- From: Andrew Dinn Sent: Thursday, May 14, 2020 4:49 PM To: Derek White ; Xiaohong Gong ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: Re: RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option Hi Xiaohong, Just for references a direct link to the webrev, issue and CSR are: https://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8243339 https://bugs.openjdk.java.net/browse/JDK-8243456 The webrev looks fine to me. Nice work, thank you! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill On 13/05/2020 21:20, Derek White wrote: > Hi Xiaohong, > > This looks good to me (not a (R)eviewer). Thanks for including the patch for ThunderX ! > > This is a nice cleanup of the code and especially the volatile tests. > > I did NOT check that the removal of the Compiler Interface declarations does or doesn't impact compilation of the Graal compiler. Did you check that side? > > Thanks, > - Derek > > -----Original Message----- > From: hotspot-compiler-dev On Behalf Of Xiaohong Gong > Sent: Thursday, May 7, 2020 11:39 PM > To: aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Cc: nd > Subject: [EXT] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option > > External Email > > ---------------------------------------------------------------------- > Hi, > > Please help to review this patch which obsoletes the product flag "-XX:UseBarrierssForVolatile" and its related code: > Webrev: > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Exgong_rfr_8243339_webrev.00_&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=oI-OcgRUa25GiBZaU5V4OmuS8aewSxBaMLbKw3A7lnA&e= > JBS: > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243339&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=T-oDfXrBvQorUBzFZq7Omb17P5yqQjg_q3dBo4EExCA&e= > https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8243456&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=MDMAqUQRO_kmBtmTodGJ2wNuaVy-u_Y_jykpMmyMQwI&e= (CSR) > > As described in the CSR, using "-XX:+UseBarriersForVolatile" might have memory consistent issue like that mentioned in [1]. It needs more effort to fix the issue and maintain the memory consistency in future. Since "ldar/stlr" has worked well for a long time, and so does "ldaxr/stlxr" for unsafe atomics, we'd better simplify things by removing this option and the alternative implementation for the volatile access. > > Since its only one signifcant usage on a kind of CPU would also like to be removed (See [2]), it can work well without this option. So we directly obsolete this option and remove the code, rather than deprecate it firstly. > > Besides obsoleting this option, this patch also removes an AArch64 CPU feature "CPU_DMB_ATOMICS" together. It is a workaround while not an AArch64 official feature, which is not required anymore (See [2]). > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8241137&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=XQwo26nMgDENOKN5U4pW2EunOEt2UtLycucN1BCScaU&e= > [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8242469&d=DwIFAg&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=OT2KWgejq1kc_YJt_NWWZBKwYqCqlRvzSlfRO04igpk&s=ChT4b4Jj_TkXozuRs6HIqUVPn1iap0DzKvB-2dKYf0g&e= > > Testing: > Jtreg hotspot::hotspot_all_no_apps, jdk::jdk_core, langtools::tier1 > JCStress: tests-all > > Thanks, > Xiaohong Gong > > From aph at redhat.com Thu May 14 09:37:09 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 May 2020 10:37:09 +0100 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: Message-ID: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> On 5/14/20 9:48 AM, Andrew Dinn wrote: > Just for references a direct link to the webrev, issue and CSR are: > > https://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8243339 > https://bugs.openjdk.java.net/browse/JDK-8243456 > > The webrev looks fine to me. Nice work, thank you! There's a problem with C1: we generate unnecessary DMBs if we're using TieredStopAtLevel=1 or if we only have the client compiler. This is a performance regression, so I reject this patch. -- 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 May 14 09:44:41 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 May 2020 10:44:41 +0100 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> Message-ID: <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> On 5/14/20 10:37 AM, Andrew Haley wrote: > On 5/14/20 9:48 AM, Andrew Dinn wrote: >> Just for references a direct link to the webrev, issue and CSR are: >> >> https://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ >> https://bugs.openjdk.java.net/browse/JDK-8243339 >> https://bugs.openjdk.java.net/browse/JDK-8243456 >> >> The webrev looks fine to me. Nice work, thank you! > > There's a problem with C1: we generate unnecessary DMBs if we're using > TieredStopAtLevel=1 or if we only have the client compiler. This is a > performance regression, so I reject this patch. There are similar regressoins in the interpreter. -- 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 Xiaohong.Gong at arm.com Thu May 14 10:07:35 2020 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Thu, 14 May 2020 10:07:35 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> Message-ID: Hi Andrew, Thanks for having a look at it! > On 5/14/20 10:37 AM, Andrew Haley wrote: > > On 5/14/20 9:48 AM, Andrew Dinn wrote: > >> Just for references a direct link to the webrev, issue and CSR > are: > >> > >> https://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ > >> https://bugs.openjdk.java.net/browse/JDK-8243339 > >> https://bugs.openjdk.java.net/browse/JDK-8243456 > >> > >> The webrev looks fine to me. Nice work, thank you! > > > > There's a problem with C1: we generate unnecessary DMBs if we're > using > > TieredStopAtLevel=1 or if we only have the client compiler. This > is a > > performance regression, so I reject this patch. > > There are similar regressoins in the interpreter. Yes, I agree with you that regressions exist for interpreter and client compiler. So do you think if it's better to add the conditions to add DMBs for C1 and interpreter? How about just excluding the scenario like "interpreter only", "client compiler only" and "TieredStopAtLevel=1" ? Thanks, Xiaohong Gong From aph at redhat.com Thu May 14 10:15:26 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 May 2020 11:15:26 +0100 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> Message-ID: On 5/14/20 11:07 AM, Xiaohong Gong wrote: > Hi Andrew, > > Thanks for having a look at it! > > > On 5/14/20 10:37 AM, Andrew Haley wrote: > > > On 5/14/20 9:48 AM, Andrew Dinn wrote: > > >> Just for references a direct link to the webrev, issue and CSR > > are: > > >> > > >> https://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ > > >> https://bugs.openjdk.java.net/browse/JDK-8243339 > > >> https://bugs.openjdk.java.net/browse/JDK-8243456 > > >> > > >> The webrev looks fine to me. Nice work, thank you! > > > > > > There's a problem with C1: we generate unnecessary DMBs if > > > we're using TieredStopAtLevel=1 or if we only have the client > > > compiler. This is a performance regression, so I reject this > > > patch. > > > > There are similar regressoins in the interpreter. > > Yes, I agree with you that regressions exist for interpreter and > client compiler. So do you think if it's better to add the > conditions to add DMBs for C1 and interpreter? How about just > excluding the scenario like "interpreter only", "client compiler > only" and "TieredStopAtLevel=1" ? Yes, I think so. Is there some way simply to ask the question "Are we using C2 or JVMCI compilers?" That's what we need to know. -- 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 May 14 10:39:06 2020 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 14 May 2020 11:39:06 +0100 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> Message-ID: On 14/05/2020 11:15, Andrew Haley wrote: > On 5/14/20 11:07 AM, Xiaohong Gong wrote: >> Hi Andrew, >> >> Thanks for having a look at it! >> >> > On 5/14/20 10:37 AM, Andrew Haley wrote: >> > > On 5/14/20 9:48 AM, Andrew Dinn wrote: >> > >> Just for references a direct link to the webrev, issue and CSR >> > are: >> > >> >> > >> https://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ >> > >> https://bugs.openjdk.java.net/browse/JDK-8243339 >> > >> https://bugs.openjdk.java.net/browse/JDK-8243456 >> > >> >> > >> The webrev looks fine to me. Nice work, thank you! >> > > >> > > There's a problem with C1: we generate unnecessary DMBs if >> > > we're using TieredStopAtLevel=1 or if we only have the client >> > > compiler. This is a performance regression, so I reject this >> > > patch. >> > >> > There are similar regressoins in the interpreter. >> >> Yes, I agree with you that regressions exist for interpreter and >> client compiler. So do you think if it's better to add the >> conditions to add DMBs for C1 and interpreter? How about just >> excluding the scenario like "interpreter only", "client compiler >> only" and "TieredStopAtLevel=1" ? > > Yes, I think so. Is there some way simply to ask the question "Are we > using C2 or JVMCI compilers?" That's what we need to know. This can be done using build time conditionality. Elsewhere in the code base we have: #ifdef COMPILER2 . . . #if INCLUDE_JVMCI . . . #if COMPILER2_OR_JVMCI . . . regards, Andrew Dinn ----------- From aph at redhat.com Thu May 14 10:46:54 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 14 May 2020 11:46:54 +0100 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> Message-ID: On 5/14/20 11:39 AM, Andrew Dinn wrote: > On 14/05/2020 11:15, Andrew Haley wrote: >> On 5/14/20 11:07 AM, Xiaohong Gong wrote: >>> Hi Andrew, >>> >>> Thanks for having a look at it! >>> >>> > On 5/14/20 10:37 AM, Andrew Haley wrote: >>> > > On 5/14/20 9:48 AM, Andrew Dinn wrote: >>> > >> Just for references a direct link to the webrev, issue and CSR >>> > are: >>> > >> >>> > >> https://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ >>> > >> https://bugs.openjdk.java.net/browse/JDK-8243339 >>> > >> https://bugs.openjdk.java.net/browse/JDK-8243456 >>> > >> >>> > >> The webrev looks fine to me. Nice work, thank you! >>> > > >>> > > There's a problem with C1: we generate unnecessary DMBs if >>> > > we're using TieredStopAtLevel=1 or if we only have the client >>> > > compiler. This is a performance regression, so I reject this >>> > > patch. >>> > >>> > There are similar regressoins in the interpreter. >>> >>> Yes, I agree with you that regressions exist for interpreter and >>> client compiler. So do you think if it's better to add the >>> conditions to add DMBs for C1 and interpreter? How about just >>> excluding the scenario like "interpreter only", "client compiler >>> only" and "TieredStopAtLevel=1" ? >> >> Yes, I think so. Is there some way simply to ask the question "Are we >> using C2 or JVMCI compilers?" That's what we need to know. > This can be done using build time conditionality. Not entirely, because this is also switchable at runtime. > Elsewhere in the code > base we have: > > #ifdef COMPILER2 > . . . > > #if INCLUDE_JVMCI > . . . > > #if COMPILER2_OR_JVMCI > . . . > > > regards, > > > Andrew Dinn > ----------- > -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Thu May 14 19:24:13 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Thu, 14 May 2020 19:24:13 +0000 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: Hi, I have prepared a change to use SIGTRAP on PPC64 for stop functions etc. I'll test it and post a separate RFR at a later point of time. Just for you upfront in case you would like to take a look: https://bugs.openjdk.java.net/browse/JDK-8244949 http://cr.openjdk.java.net/~mdoerr/8244949_ppc64_asm_stop/webrev.00/ @lx: Btw. Please use bug id in subject line of RFR emails. Best regards, Martin > -----Original Message----- > From: Andrew Haley > Sent: Donnerstag, 7. Mai 2020 19:48 > To: Doerr, Martin ; Derek White > ; Ningsheng Jian ; Liu, > Xin ; hotspot-compiler-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information > when hitting a HaltNode for architectures other than x86 > > On 5/7/20 9:11 AM, Andrew Haley wrote: > > On 5/6/20 9:45 PM, Doerr, Martin wrote: > >> I had also thought about using a trap based implementation. > >> Maybe it makes sense to add a feature to shared code for that. > >> E.g. we could emit an illegal instruction (which raises SIGILL) followed by > some kind of index into a descriptor array. > >> PPC64 would also benefit from a more compact solution. > > > > Most of the stuff to handle this would be in the back end, I would > > have thought. I'll have a look. > > This attached patch does the job for Linux/AArch64. It has two > disadvantages: > > 1. It corrupts R8, rscratch1. This doesn't really matter for AArch64. > > 2. If we execute stop() in the context of a signal handler triggered > by another trap, we'll have a double fault and the OS will kill our > process. > > 1 is fixable by pushing rscratch1 before executing the trap. I'm not > sure it's worth doing; I'd rather have a tiny implementation of stop() > that we can use guilt-free in release code. > > I don't think 2 is an issue because we never call out to generated > code from a signal handler. > > -- > 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 May 15 08:57:26 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 15 May 2020 09:57:26 +0100 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: On 5/14/20 8:24 PM, Doerr, Martin wrote: > Just for you upfront in case you would like to take a look: > https://bugs.openjdk.java.net/browse/JDK-8244949 > http://cr.openjdk.java.net/~mdoerr/8244949_ppc64_asm_stop/webrev.00/ That's nice: it's a lot more full-featured than what I did. and AFAICS you'll get the registers printed in the VM error log. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Fri May 15 10:37:28 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Fri, 15 May 2020 10:37:28 +0000 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: Exactly, we get stop type + stop message + registers + instructions (unfortunately not disassembled for some reason) + nice stack trace. Best regards, Martin > -----Original Message----- > From: Andrew Haley > Sent: Freitag, 15. Mai 2020 10:57 > To: Doerr, Martin ; Derek White > ; Ningsheng Jian ; Liu, > Xin ; hotspot-compiler-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information > when hitting a HaltNode for architectures other than x86 > > On 5/14/20 8:24 PM, Doerr, Martin wrote: > > Just for you upfront in case you would like to take a look: > > https://bugs.openjdk.java.net/browse/JDK-8244949 > > > http://cr.openjdk.java.net/~mdoerr/8244949_ppc64_asm_stop/webrev.00/ > > That's nice: it's a lot more full-featured than what I did. and AFAICS > you'll get the registers printed in the VM error log. > > -- > 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 coleen.phillimore at oracle.com Fri May 15 22:26:25 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 May 2020 18:26:25 -0400 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: Message-ID: Hi, This looks good. The code motion makes sense so this is an improvement. On 5/7/20 10:21 AM, Thomas St?fe wrote: > Hi all, > > please take a look at the third iteration of this change: > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ > > Changes in this version: > > - at the request of Coleen (sorry I did not see your post earlier) I > removed all platform dependent?files and put the platform dependent > coding back to metaspace.cpp and compressedOops.cpp to ease the review > pain. I used plain platform defines though (#ifdef AARCH64) instead of > hiding them behind another macro to make things clearer. Note that I > still intent to put this code away into the platform corners but will > do so in a follow up RFE. Oh, please don't, especially since most platforms are just a ReservedSpace(size, align, false, NULL);? The AARCH64 code isn't a big intrusion in this code.? Thank you for putting it back. It is easier to follow how it is. > > - I reinstated, in a fashion, the special handling of reservations on > Windows. On all platforms we reserve address space to map the archive > files in with a subsequent mapping operation. However, on Windows, we > cannot use MapViewOfFile() into an existing mapping. So I remove the > mapping again before mapping the archives - see comment in code for > details. I missed this windows part of the change, where is it? http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/virtualSpaceList.cpp.udiff.html Why did you make this change?? Shouldn't the caller align it? Looks good to me. Coleen > > All CI tests at SAP run through without problems, including on Win64 > and aarch64, but I would be happy if others were to run test too. > > Thank you, Thomas > > On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe > wrote: > > Hi all, > > Could I have reviews for the following proposal of reworking > cds/class space reservation? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 > > Webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ > > (Many thanks to Ioi Lam for so patiently explaining CDS internals > to me, and to Andrew Haley and Nick Gasson for help with aarch64!) > > Reservation of the compressed class space is needlessly > complicated and has some minor issues. It can be simplified and > made clearer. > > The complexity stems from the fact that this area lives at the > intersection of two to three sub systems, depending on how one > counts. Metaspace, CDS, and the platform which may or may not its > own view of how to reserve class space. And this code has been > growing organically over time. > > One small example: > > ReservedSpace Metaspace::reserve_preferred_space(size_t size, > size_t alignment, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bool large_pages, > char *requested_addr, > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?bool > use_requested_addr) > > which I spent hours decoding, resulting in a very confused mail to > hs-runtime and aarch64-port-dev [2]. > > This patch attempts to simplify cds and metaspace setup a bit; to > comment implicit knowledge which is not immediately clear; to > cleanly abstract platform concerns like optimized class space > placement; and to disentangle cds from metaspace to solve issues > which may bite us later with Elastic Metaspace [4]. > > --- > > The main change is the reworked reservation mechanism. This is > based on Ioi's proposal [5]. > > When reserving class space, three things must happen: > > 1) reservation of the space obviously. If cds is active that space > must be in the vicinity of cds archives to be covered by > compressed class pointer encoding. > 2) setting up the internal Metaspace structures atop of that space > 3) setting up compressed class pointer encoding. > > In its current form, Metaspace may or may not do some or all of > that in one function > (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace > metaspace_rs, char* requested_addr, address cds_base);) - if cds > is active, it will reserve the space for Metaspace and hand it in, > otherwise it will create it itself. > > When discussing this in [2], Ioi proposed to move the reservation > of the class space completely out of Metaspace and make it a > responsibility of the caller always. This would reduce some > complexity, and this patch follows the proposal. > > I removed > Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace > metaspace_rs, char* requested_addr, address cds_base); and all its > sub functions. > > (1) now has to always be done outside - a ReservedSpace for class > space has to be provided by the caller. However, Metaspace now > offers a utility function for reserving space at a "nice" > location, and explicitly doing nothing else: > > ReservedSpace > Metaspace::reserve_address_space_for_compressed_classes(size_t size); > > this function can be redefined on a platform level for platform > optimized reservation, see below for details. > > (2) is taken care of by a new function, > Metaspace::initialize_class_space(ReservedSpace rs) > > (3) is taken care of a new function > CompressedKlassPointers::initialize(), see below for details. > > > So, class space now is set up three explicit steps: > > - First, reserve a suitable space by however means you want. For > convenience you may use > Metaspace::reserve_address_space_for_compressed_classes(), or you > may roll your own reservation. > - Next, tell Metaspace to use that range as backing storage for > class space: Metaspace::initialize_class_space(ReservedSpace rs) > - Finally, set up encoding. Encoding is independent from the > concept of a ReservedSpace, it just gets an address range, see > below for details. > > Separating these steps and moving them out of the responsibility > of Metaspace makes this whole thing more flexible; it also removes > unnecessary knowledge (e.g. Metaspace does not need to know > anything about either ccp encoding or cds). > > --- > > How it comes together: > > If CDS is off, we just reserve a space using > Metaspace::reserve_address_space_for_compressed_classes(), > initialize it with Metaspace::initialize_class_space(ReservedSpace > rs), then set up compressed class pointer encoding covering the > range of this class space. > > If CDS is on (dump time), we reserve large 4G space, either at > SharedBaseAddress or using > Metaspace::reserve_address_space_for_compressed_classes(); we then > split that into 3G archive space and 1G class space; we set up > that space with Metaspace as class space; then we set > up?compressed class pointer encoding covering both archive space > and cds. > > If CDS is on (run time), we reserve a large space, split it into > archive space (large enough to hold both archives) and class > space, then basically proceed as above. > > Note that this is almost exactly how things worked before (modulo > some minor fixes, e.g. alignment issues), only the code is > reformed and made more explicit. > > --- > > I moved compressed class pointer setup over to > CompressedKlassPointers and changed the interface: > > -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace > metaspace_rs, address cds_base) > +void CompressedKlassPointers::initialize(address addr, size_t len); > > Instead of feeding it a single ReservedSpace, which is supposed to > represent class space, and an optional alternate base if cds is > on, now we give it just an numeric address range. That range marks > the limits to where Klass structures are to be expected, and is > the implicit promise that outside that range no Klass structures > will exist, so encoding has to cover only this range. > > This range may contain just the class space; or class space+cds; > or whatever allocation scheme we come up with in the future. > Encoding does not really care how the memory is organized as long > as the input range covers all possible Klass locations. That way > we remove knowledge about class space/cds from compressed class > pointer encoding. > > Moving it away from metaspace.cpp into the CompressedKlassPointers > class also mirrors CompressedOops::initialize(). > > --- > > I renamed _narrow_klass_range to just _range, because strictly > speaking this is the range un-narrow Klass pointers can have. > > As for the implementation of > CompressedKlassPointers::initialize(address addr, size_t len), I > mimicked very closely what happened before, so there should be > almost no differences. Since "almost no differences" sounds scary > :) here are the differences: > > - When CDS is active (dump or run time) we now always, > unconditionally, set the encoding range to 4G. This fixes a > theoretical bug discussed on aarch64-port-dev [1]. > > - When CDS is not active, we set the encoding range to the minimum > required length. Before, it was left at its default value of 4G. > > Both differences only affect aarch64, since they are currently the > only one using the range field in CompressedKlassPointers. > > I wanted to add an assert somewhere to test encoding of the very > last address of the CompressedKlassPointers range, again to > prevent errors like [3]. But I did not come up with a good place > for this assert which would cover also the encoding done by C1/C2. > > For the same reason I thought about introducing a mode where Klass > structures would be allocated in reverse order, starting at the > end of the ccs, but again left it out as too big a change. > > --- > > OS abstraction: platforms may have restrictions of what > constitutes a valid compressed class pointer encoding base. Or if > not, they may have at least preferences. There was logic like this > in metaspace.cpp, which I removed and cleanly factored out into > platform dependent files, giving each platform the option to add > special logic. > > These are two new methods: > > - bool CompressedKlassPointers::is_valid_base(address p) > > to let the platform tell you whether it considers p to be a valid > encoding base. The only platform having these restrictions > currently is aarch64. > > - ReservedSpace > Metaspace::reserve_address_space_for_compressed_classes(size_t size); > > this hands over the process of allocating a range suitable for > compressed class pointer encoding to the platform. Most platforms > will allocate just anywhere, but some platforms may have a better > strategy (e.g. trying low memory first, trying only correctly > aligned addresses and so on). > > Beforehand, this coding existed in a similar form in metaspace.cpp > for aarch64 and AIX. For now, I left the AIX part out - it seems > only half done, and I want to check further if we even need it, if > yes why not on Linux ppc, and C1 does not seem to support anything > other than base+offset with shift either, but I may be mistaken. > > These two methods should give the platform enough control to > implement their own scheme for optimized class space placement > without bothering any shared code about it. > > Note about the form, I introduced two new platform dependent > files, "metaspace_.cpp" and "compressedOops_.cpp". I am > not happy about this but this seems to be what we generally do in > hotspot, right? > > --- > > Metaspace reserve alignment vs cds alignment > > CDS was using Metaspace reserve alignment for CDS internal > purposes. I guess this was just a copy paste issue. It never > caused problems since Metaspace reserve alignment == page size, > but that is not true anymore in the upcoming Elastic Metaspace > where reserve alignment will be larger. This causes a number of > issues. > > I separated those two cleanly. CDS now uses > os::vm_allocation_granularity. Metaspace::reserve_alignment is > only used in those two places where it is needed, when CDS creates > the address space for class space on behalf of the Metaspace. > > --- > > Windows special handling in CDS > > To simplify coding I removed the windows specific handling which > left out reservation of the archive. This was needed because > windows cannot mmap files into reserved regions. But fallback code > exists in filemap.cpp for this case which just reads in the region > instead of mapping?it. > > Should that turn out to be a performance problem, I will reinstate > the feature. But a simpler way would be reserve the archive and > later just before mmapping?the archive file to release the archive > space. That would not only be simpler but give us the best > guarantee that that address space is actually available. But I'd > be happy to leave that part out completely if we do not see any > performance problems on windows x64. > > --- > > NMT cannot deal with spaces which are split. This problem > manifests in that bookkeeping for class space is done under > "Shared Classes", not "Classes" as it should. This problem exists > today too at dump?time and randomly at run time. But since I > simplified the reservation, this problem now shows up always, > whether or not we map at the SharedBaseAddress. > While I could work around this problem, I'd prefer this problem to > be solved at the core, and NMT to have an option to recognize > reservation splits. So I'd rather not put a workaround for this > into the patch but leave it for fixing as a separate issue. I > opened this issue to track it [6]. > > --- > > Jtreg tests: > > I expanded the CompressedOops/CompressedClassPointers.java. I also > extended them to Windows. The tests now optionally omit strict > class space placement tests, since these tests heavily depend on > ASLR and were the reason they were excluded on Windows. However I > think even without checking for class space placement they make > sense, just to see that the VM comes up and lives with the many > different settings we can run in. > > --- > > Tests: > > - I ran the patch through Oracles submit repo > - I ran tests manually for aarch64, zero, linux 32bit and windows x64 > - The whole battery of nightly tests at SAP, including ppc, ppcle > and aarch64, unfortunately excluding windows because of unrelated > errors. Windows x64 tests will be redone tonight. > > > Thank you, > > Thomas > > [1] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html > [2] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html > [3] https://bugs.openjdk.java.net/browse/JDK-8193266 > [4] https://bugs.openjdk.java.net/browse/JDK-8221173 > [5] > https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html > [6] https://bugs.openjdk.java.net/browse/JDK-8243535 > From coleen.phillimore at oracle.com Fri May 15 22:34:21 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 15 May 2020 18:34:21 -0400 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> Message-ID: <1108ac1a-f693-cfc7-9f86-1a84508b1487@oracle.com> One more in-context comment. On 5/8/20 3:33 AM, Thomas St?fe wrote: > Hi Ioi, > > thanks for taking the time to look at this! > > On Fri, May 8, 2020 at 7:37 AM Ioi Lam > wrote: > > Hi Thomas, > > I am running your patch in out CI pipeline now. Some comments: > > [1] Do we still need to use _class_space_list? It looks like we > just have a single range. Is > _class_space_list->current_virtual_space() always the same VS? > > ? if (_class_space_list != NULL) { > ??? address base = > (address)_class_space_list->current_virtual_space()->bottom(); > ??? address top = base + compressed_class_space_size(); > ??? st->print("Compressed class space mapped at: " PTR_FORMAT "-" > PTR_FORMAT ", size: " SIZE_FORMAT, > ?????????????? p2i(base), p2i(top), top - base); > > > Yes it is. Has been bugging me for years too. With ccs, the > VirtualSpaceList is degenerated and only contains one node. It still > makes some sense code wise. But maybe VirtualSpace*List* is a misnomer. > > It also ties in into the question whether Metaspace reservations > should be able to grow on demand. Oracle folks I talk to tend to say > yes. I personally think the "Metaspace is infinite don't worry" meme > was broken since ccs was a thing, since CompressedClassSpaceSize is an > absolute limit already. > > I may tweak and simplify the code a bit with Elastic Metaspace. Maybe, > as you say, with ccs we can get rid of VirtualSpaceList and deal with > the range directly. Have to check. Yes, this could be an improvement for a later time.? The compressed class space isn't a list.? I think that was the least amount of special code place to hook it in at the time.? It makes sense for it to be a single VirtualSpaceNode. CompressedClassSpace + Data (the rest of Metaspace) has a complicated relationship for determining high water mark for starting GC, and for reporting LowMemory thresholds.? I'd have to look up what was decided there. Data (the rest of Metaspace) does grow on demand unless someone uses -XX:MaxMetaspaceSize and then class metaspace size is factored in (maybe just committed space not the whole 1G). HTH. Coleen > > [2] Does JDK-8243535 exist with the current jdk/jdk repo? > > ? // This does currently not work because rs may be the result of > a split operation > ? // and NMT seems not to be able to handle splits. > ? // See JDK-8243535. > ? // MemTracker::record_virtual_memory_type((address)rs.base(), > mtClass); > > > Yes. It shows up more rarely. With this patch, it will show up always. > I had a conversation with Zhengyu about this. I think there may be > workarounds, like removing the original mapping in NMT and replacing > it with the two new ones for archive and ccs. But it seems iffy, I'd > rather have this fixed in NMT. > > I also think it is not such a big deal, but if you think otherwise, I > can integrate a workaround into this patch. > > > [3] I think this can be put in header file. > > bool Metaspace::class_space_is_initialized() { > ? return _class_space_list != NULL; > } > > > Will do. > > [4] Why does the CCS need to follow UseLargePagesInMetaspace? This > is the reason for the > ??? gap in the following chart: > > ??? // We do this by reserving space for the ccs behind the > archives. Note however that > ??? //? ccs follows a different alignment > (Metaspace::reserve_alignment), so there may > ??? //? be a gap between ccs and cds. > ??? // We use a similar layout at runtime, see > reserve_address_space_for_archives(). > ??? // > ??? //????????????????????????????? +-- SharedBaseAddress (default > = 0x800000000) > ??? //????????????????????????????? v > ??? // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > ??? // |??? Heap??? | Archive |???? | MC | RW | RO | [gap]? |??? > class space???? | > ??? // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > ??? // |<--?? MaxHeapSize? -->|???? |<-- UnscaledClassSpaceMax = > 4GB -->| > > > No, nothing to do with large pages. CCS does not have large pages. > > The gap can result from different alignment rules between metaspace > and cds. With Elastic Metaspace, metaspace reservations will be > aligned to 4M. So, ccs will have to start at a 4M aligned border. > > > _reserve_alignment is determined here: > > void Metaspace::ergo_initialize() { > ? if (DumpSharedSpaces) { > ??? // Using large pages when dumping the shared archive is > currently not implemented. > ??? FLAG_SET_ERGO(UseLargePagesInMetaspace, false); > ? } > > ? size_t page_size = os::vm_page_size(); > ? if (UseLargePages && UseLargePagesInMetaspace) { > ??? page_size = os::large_page_size(); > ? } > > ? _commit_alignment? = page_size; > ? _reserve_alignment = MAX2(page_size, > (size_t)os::vm_allocation_granularity()); > > But when CDS is enabled, the RS is reserved without large pages, > so it should be possible to incrementally commit the CCS using > just os::vm_allocation_granularity(). > > > Absolutely. CCS does not use large pages for that reason. As I wrote, > this is about the new reservation granularity of 4M. > > [5] I see the aarch64 code in > Metaspace::reserve_address_space_for_compressed_classes has been > changed. Is this necessary for this RFE, or is it a separate > improvement that can be done in a different RFE? > > > Well, it had to be changed somewhat, since the prototype differs. I > swapped Metaspace::reserve_preferred_space() for > Metaspace::reserve_address_space_for_compressed_classes(), which > follows a somewhat different protocol. > > That aside, the functionality for AARCH64 should be as unchanged?as > possible. I removed the AIX specific coding, since it was > subtly?wrong, but that's fine since we are AIX/ppc maintainers. > > > [6] For AARCH64, should we skip the part that reserves it right > above the heap? Or does AARCH64 always allocate the heap such that > it's a preferable address? > > > Yes and yes :) > > We do skip that for aarch64 (at least if the address is wrong): > > 1157 // Try right above the Java heap... 1158 address base = > align_up(CompressedOops::end(), Metaspace::reserve_alignment()); 1159 > assert(base != NULL, "Sanity"); 1160 1161 const size_t size = > align_up(CompressedClassSpaceSize, Metaspace::reserve_alignment()); > 1162 if (CompressedKlassPointers::is_valid_base(base)) { 1163 rs = > ReservedSpace(size, Metaspace::reserve_alignment(), false /* large */, > (char*)base); 1164 } > At 1162, we check if the attach address would be valid for this > platform. If aarch64 says no, we won't reserve there but go straight > to the "attach wherever you think is good" part. Which is implemented > by?Metaspace::reserve_address_space_for_compressed_classes(), which on > aarch64 does search a suitable address. > > ??? // case (b) > ??? ReservedSpace rs; > > ??? // Try right above the Java heap... > ??? address base = align_up(CompressedOops::end(), > Metaspace::reserve_alignment()); > ??? assert(base != NULL, "Sanity"); > > ??? const size_t size = align_up(CompressedClassSpaceSize, > Metaspace::reserve_alignment()); > ??? if (CompressedKlassPointers::is_valid_base(base)) { > ????? rs = ReservedSpace(size, Metaspace::reserve_alignment(), > false /* large */, (char*)base); > ??? } > > ??? // ...failing that, reserve anywhere, but let platform do > optimized placement: > ??? if (!rs.is_reserved()) { > ????? rs = > Metaspace::reserve_address_space_for_compressed_classes(size); > ??? } > > [7] argument.cpp checks this: > > ? if (UseSharedSpaces || DumpSharedSpaces) { > ??? if > (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) > { > ????? log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is > invalid for this platform, option will be ignored.", > ?????????????????????? p2i((address)SharedBaseAddress)); > ????? FLAG_SET_DEFAULT(SharedBaseAddress, > default_SharedBaseAddress()); > ??? } > ? } > > but initialize_dumptime_shared_and_meta_spaces aligns up the > SharedBaseAddress before doing the assert. > > ? void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { > ??? assert(DumpSharedSpaces, "should be called for dump time only"); > > ??? const size_t reserve_alignment = > MetaspaceShared::reserved_space_alignment(); > ??? char* shared_base = (char*)align_up((char*)SharedBaseAddress, > reserve_alignment); > > ? #ifdef _LP64 > assert(CompressedKlassPointers::is_valid_base((address)shared_base), > "Sanity"); > > So theoretically shared_base may no longer be is_valid_base after > the align_up. It probably won't happen, but I think the code will > be much clearer tofirst to align_up, then check for is_valid_base > and reset to default, and finally assert. > > > Okay, I'll change that. > > [8] In > MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the > following block can be simplified: > > ? if (!_shared_rs.is_reserved()) { > ??? // Get a reserved space anywhere if attaching at the > SharedBaseAddress fails: > ??? if (UseCompressedClassPointers) { > ????? // If we need a compressed class space too, let the platform > handle the reservation. > ????? _shared_rs = > Metaspace::reserve_address_space_for_compressed_classes(cds_total); > ??? } else { > ????? // anywhere is fine. > ????? _shared_rs = ReservedSpace(cds_total, reserve_alignment, > false /* large */, (char*)NULL); > ??? } > ? } > > ?? ... if you change the declaration to: > > ? static ReservedSpace > reserve_address_space_for_compressed_classes(size_t size) > NOT_LP64({ return ReservedSpace();}); > > [9] I think the #ifdef _LP64 is not necessary: > > #ifdef _LP64 > ??? // Some sanity checks after reserving address spaces for > archives and class space. > ??? assert(archive_space_rs.is_reserved(), "Sanity"); > ??? if (Metaspace::using_class_space()) { > ????? // Class space must closely follow the archive space. Both > spaces must be aligned correctly. > ????? assert(class_space_rs.is_reserved(), "A class space should > have been reserved"); > ????? assert(class_space_rs.base() >= archive_space_rs.end(), > "class space should follow the cds archive space"); > ????? assert(is_aligned(archive_space_rs.base(), > MetaspaceShared::reserved_space_alignment()), "Archive space > misaligned"); > ????? assert(is_aligned(class_space_rs.base(), > Metaspace::reserve_alignment()), "class space misaligned"); > ??? } > #endif > > > I'll take a look. > > The rest of the code looks OK to me, but I may take a look at it > again after getting more sleep :-) > > > Sure. Thanks man! :) > > ..Thomas > > Thanks > - Ioi > > > > > On 5/7/20 7:21 AM, Thomas St?fe wrote: >> Hi all, >> >> please take a look at the third iteration of this change: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >> >> Changes in this version: >> >> - at the request of Coleen (sorry I did not see your post >> earlier) I removed all platform dependent?files and put the >> platform dependent coding back to metaspace.cpp and >> compressedOops.cpp to ease the review pain. I used plain platform >> defines though (#ifdef AARCH64) instead of hiding them behind >> another macro to make things clearer. Note that I still intent to >> put this code away into the platform corners but will do so in a >> follow up RFE. >> >> - I reinstated, in a fashion, the special handling of >> reservations on Windows. On all platforms we reserve address >> space to map the archive files in with a subsequent mapping >> operation. However, on Windows, we cannot use MapViewOfFile() >> into an existing mapping. So I remove the mapping again before >> mapping the archives - see comment in code for details. >> >> All CI tests at SAP run through without problems, including on >> Win64 and aarch64, but I would be happy if others were to run >> test too. >> >> Thank you, Thomas >> >> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >> > wrote: >> >> Hi all, >> >> Could I have reviews for the following proposal of reworking >> cds/class space reservation? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >> >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >> >> (Many thanks to Ioi Lam for so patiently explaining CDS >> internals to me, and to Andrew Haley and Nick Gasson for help >> with aarch64!) >> >> Reservation of the compressed class space is needlessly >> complicated and has some minor issues. It can be simplified >> and made clearer. >> >> The complexity stems from the fact that this area lives at >> the intersection of two to three sub systems, depending on >> how one counts. Metaspace, CDS, and the platform which may or >> may not its own view of how to reserve class space. And this >> code has been growing organically over time. >> >> One small example: >> >> ReservedSpace Metaspace::reserve_preferred_space(size_t size, >> size_t alignment, >> ?bool large_pages, char *requested_addr, >> ?bool use_requested_addr) >> >> which I spent hours decoding, resulting in a very confused >> mail to hs-runtime and aarch64-port-dev [2]. >> >> This patch attempts to simplify cds and metaspace setup a >> bit; to comment implicit knowledge which is not immediately >> clear; to cleanly abstract platform concerns like optimized >> class space placement; and to disentangle cds from metaspace >> to solve issues which may bite us later with Elastic >> Metaspace [4]. >> >> --- >> >> The main change is the reworked reservation mechanism. This >> is based on Ioi's proposal [5]. >> >> When reserving class space, three things must happen: >> >> 1) reservation of the space obviously. If cds is active that >> space must be in the vicinity of cds archives to be covered >> by compressed class pointer encoding. >> 2) setting up the internal Metaspace structures atop of that >> space >> 3) setting up compressed class pointer encoding. >> >> In its current form, Metaspace may or may not do some or all >> of that in one function >> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base);) - if >> cds is active, it will reserve the space for Metaspace and >> hand it in, otherwise it will create it itself. >> >> When discussing this in [2], Ioi proposed to move the >> reservation of the class space completely out of Metaspace >> and make it a responsibility of the caller always. This would >> reduce some complexity, and this patch follows the proposal. >> >> I removed >> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base); and >> all its sub functions. >> >> (1) now has to always be done outside - a ReservedSpace for >> class space has to be provided by the caller. However, >> Metaspace now offers a utility function for reserving space >> at a "nice" location, and explicitly doing nothing else: >> >> ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t >> size); >> >> this function can be redefined on a platform level for >> platform optimized reservation, see below for details. >> >> (2) is taken care of by a new function, >> Metaspace::initialize_class_space(ReservedSpace rs) >> >> (3) is taken care of a new function >> CompressedKlassPointers::initialize(), see below for details. >> >> >> So, class space now is set up three explicit steps: >> >> - First, reserve a suitable space by however means you want. >> For convenience you may use >> Metaspace::reserve_address_space_for_compressed_classes(), or >> you may roll your own reservation. >> - Next, tell Metaspace to use that range as backing storage >> for class space: >> Metaspace::initialize_class_space(ReservedSpace rs) >> - Finally, set up encoding. Encoding is independent from the >> concept of a ReservedSpace, it just gets an address range, >> see below for details. >> >> Separating these steps and moving them out of the >> responsibility of Metaspace makes this whole thing more >> flexible; it also removes unnecessary knowledge (e.g. >> Metaspace does not need to know anything about either ccp >> encoding or cds). >> >> --- >> >> How it comes together: >> >> If CDS is off, we just reserve a space using >> Metaspace::reserve_address_space_for_compressed_classes(), >> initialize it with >> Metaspace::initialize_class_space(ReservedSpace rs), then set >> up compressed class pointer encoding covering the range of >> this class space. >> >> If CDS is on (dump time), we reserve large 4G space, either >> at SharedBaseAddress or using >> Metaspace::reserve_address_space_for_compressed_classes(); we >> then split that into 3G archive space and 1G class space; we >> set up that space with Metaspace as class space; then we set >> up?compressed class pointer encoding covering both archive >> space and cds. >> >> If CDS is on (run time), we reserve a large space, split it >> into archive space (large enough to hold both archives) and >> class space, then basically proceed as above. >> >> Note that this is almost exactly how things worked before >> (modulo some minor fixes, e.g. alignment issues), only the >> code is reformed and made more explicit. >> >> --- >> >> I moved compressed class pointer setup over to >> CompressedKlassPointers and changed the interface: >> >> -void >> Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >> metaspace_rs, address cds_base) >> +void CompressedKlassPointers::initialize(address addr, >> size_t len); >> >> Instead of feeding it a single ReservedSpace, which is >> supposed to represent class space, and an optional alternate >> base if cds is on, now we give it just an numeric address >> range. That range marks the limits to where Klass structures >> are to be expected, and is the implicit promise that outside >> that range no Klass structures will exist, so encoding has to >> cover only this range. >> >> This range may contain just the class space; or class >> space+cds; or whatever allocation scheme we come up with in >> the future. Encoding does not really care how the memory is >> organized as long as the input range covers all possible >> Klass locations. That way we remove knowledge about class >> space/cds from compressed class pointer encoding. >> >> Moving it away from metaspace.cpp into the >> CompressedKlassPointers class also mirrors >> CompressedOops::initialize(). >> >> --- >> >> I renamed _narrow_klass_range to just _range, because >> strictly speaking this is the range un-narrow Klass pointers >> can have. >> >> As for the implementation of >> CompressedKlassPointers::initialize(address addr, size_t >> len), I mimicked very closely what happened before, so there >> should be almost no differences. Since "almost no >> differences" sounds scary :) here are the differences: >> >> - When CDS is active (dump or run time) we now always, >> unconditionally, set the encoding range to 4G. This fixes a >> theoretical bug discussed on aarch64-port-dev [1]. >> >> - When CDS is not active, we set the encoding range to the >> minimum required length. Before, it was left at its default >> value of 4G. >> >> Both differences only affect aarch64, since they are >> currently the only one using the range field in >> CompressedKlassPointers. >> >> I wanted to add an assert somewhere to test encoding of the >> very last address of the CompressedKlassPointers range, again >> to prevent errors like [3]. But I did not come up with a good >> place for this assert which would cover also the encoding >> done by C1/C2. >> >> For the same reason I thought about introducing a mode where >> Klass structures would be allocated in reverse order, >> starting at the end of the ccs, but again left it out as too >> big a change. >> >> --- >> >> OS abstraction: platforms may have restrictions of what >> constitutes a valid compressed class pointer encoding base. >> Or if not, they may have at least preferences. There was >> logic like this in metaspace.cpp, which I removed and cleanly >> factored out into platform dependent files, giving each >> platform the option to add special logic. >> >> These are two new methods: >> >> - bool CompressedKlassPointers::is_valid_base(address p) >> >> to let the platform tell you whether it considers p to be a >> valid encoding base. The only platform having these >> restrictions currently is aarch64. >> >> - ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t >> size); >> >> this hands over the process of allocating a range suitable >> for compressed class pointer encoding to the platform. Most >> platforms will allocate just anywhere, but some platforms may >> have a better strategy (e.g. trying low memory first, trying >> only correctly aligned addresses and so on). >> >> Beforehand, this coding existed in a similar form in >> metaspace.cpp for aarch64 and AIX. For now, I left the AIX >> part out - it seems only half done, and I want to check >> further if we even need it, if yes why not on Linux ppc, and >> C1 does not seem to support anything other than base+offset >> with shift either, but I may be mistaken. >> >> These two methods should give the platform enough control to >> implement their own scheme for optimized class space >> placement without bothering any shared code about it. >> >> Note about the form, I introduced two new platform dependent >> files, "metaspace_.cpp" and "compressedOops_.cpp". >> I am not happy about this but this seems to be what we >> generally do in hotspot, right? >> >> --- >> >> Metaspace reserve alignment vs cds alignment >> >> CDS was using Metaspace reserve alignment for CDS internal >> purposes. I guess this was just a copy paste issue. It never >> caused problems since Metaspace reserve alignment == page >> size, but that is not true anymore in the upcoming Elastic >> Metaspace where reserve alignment will be larger. This causes >> a number of issues. >> >> I separated those two cleanly. CDS now uses >> os::vm_allocation_granularity. Metaspace::reserve_alignment >> is only used in those two places where it is needed, when CDS >> creates the address space for class space on behalf of the >> Metaspace. >> >> --- >> >> Windows special handling in CDS >> >> To simplify coding I removed the windows specific handling >> which left out reservation of the archive. This was needed >> because windows cannot mmap files into reserved regions. But >> fallback code exists in filemap.cpp for this case which just >> reads in the region instead of mapping?it. >> >> Should that turn out to be a performance problem, I will >> reinstate the feature. But a simpler way would be reserve the >> archive and later just before mmapping?the archive file to >> release the archive space. That would not only be simpler but >> give us the best guarantee that that address space is >> actually available. But I'd be happy to leave that part out >> completely if we do not see any performance problems on >> windows x64. >> >> --- >> >> NMT cannot deal with spaces which are split. This problem >> manifests in that bookkeeping for class space is done under >> "Shared Classes", not "Classes" as it should. This problem >> exists today too at dump?time and randomly at run time. But >> since I simplified the reservation, this problem now shows up >> always, whether or not we map at the SharedBaseAddress. >> While I could work around this problem, I'd prefer this >> problem to be solved at the core, and NMT to have an option >> to recognize reservation splits. So I'd rather not put a >> workaround for this into the patch but leave it for fixing as >> a separate issue. I opened this issue to track it [6]. >> >> --- >> >> Jtreg tests: >> >> I expanded the CompressedOops/CompressedClassPointers.java. I >> also extended them to Windows. The tests now optionally omit >> strict class space placement tests, since these tests heavily >> depend on ASLR and were the reason they were excluded on >> Windows. However I think even without checking for class >> space placement they make sense, just to see that the VM >> comes up and lives with the many different settings we can >> run in. >> >> --- >> >> Tests: >> >> - I ran the patch through Oracles submit repo >> - I ran tests manually for aarch64, zero, linux 32bit and >> windows x64 >> - The whole battery of nightly tests at SAP, including ppc, >> ppcle and aarch64, unfortunately excluding windows because of >> unrelated errors. Windows x64 tests will be redone tonight. >> >> >> Thank you, >> >> Thomas >> >> [1] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >> [2] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >> [5] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >> > From xxinliu at amazon.com Sat May 16 00:25:00 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Sat, 16 May 2020 00:25:00 +0000 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: <55D731CD-5C89-47E5-B61A-83304E5123ED@amazon.com> Hi, Martin, It's my fault. I should associate with the bug id in the subject. I will double check the email subject before sending. Now this thread becomes an RFR for JDK-8244949. So, you just try it out in ppc? If it works well, we will apply this approach to both 390 and aarch64? I am not reviewer. just my 2 cents. 1. nativeInst_ppc.hpp. I think the return type of get_stop_type() should be 'int' here. bool get_stop_type() { return MacroAssembler::tdi_get_si16(long_at(0), Assembler::traptoUnconditional, 0); } 2. nativeInst_ppc.cpp NativeInstruction::is_sigill_zombie_not_entrant_at() comment still says "iff !UseSIGTRAP". 3. TrapBasedNotEntrantChecks is a product option. Is it too abrupt to drop it? This wiki defines the lifecycle of a Jvm option, but I believe this one is special. It's ppc only. https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command-line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process Thanks, --lx ?On 5/15/20, 3:38 AM, "Doerr, Martin" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Exactly, we get stop type + stop message + registers + instructions (unfortunately not disassembled for some reason) + nice stack trace. Best regards, Martin > -----Original Message----- > From: Andrew Haley > Sent: Freitag, 15. Mai 2020 10:57 > To: Doerr, Martin ; Derek White > ; Ningsheng Jian ; Liu, > Xin ; hotspot-compiler-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information > when hitting a HaltNode for architectures other than x86 > > On 5/14/20 8:24 PM, Doerr, Martin wrote: > > Just for you upfront in case you would like to take a look: > > https://bugs.openjdk.java.net/browse/JDK-8244949 > > > http://cr.openjdk.java.net/~mdoerr/8244949_ppc64_asm_stop/webrev.00/ > > That's nice: it's a lot more full-featured than what I did. and AFAICS > you'll get the registers printed in the VM error log. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Sat May 16 08:12:28 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 16 May 2020 10:12:28 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: Message-ID: Hi, On Sat, May 16, 2020 at 12:26 AM wrote: > > Hi, This looks good. The code motion makes sense so this is an improvement. > > thanks! > On 5/7/20 10:21 AM, Thomas St?fe wrote: > > Hi all, > > please take a look at the third iteration of this change: > > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ > > Changes in this version: > > - at the request of Coleen (sorry I did not see your post earlier) I > removed all platform dependent files and put the platform dependent coding > back to metaspace.cpp and compressedOops.cpp to ease the review pain. I > used plain platform defines though (#ifdef AARCH64) instead of hiding them > behind another macro to make things clearer. Note that I still intent to > put this code away into the platform corners but will do so in a follow up > RFE. > > > Oh, please don't, especially since most platforms are just a > ReservedSpace(size, align, false, NULL); The AARCH64 code isn't a big > intrusion in this code. Thank you for putting it back. It is easier to > follow how it is. > > Okay. We'll see how quickly the coding deteriorates again though. We may want to put extra stuff for ppc64 in too, and/or just AIX. See also: https://bugs.openjdk.java.net/browse/JDK-8244943 . I'll keep this off for now to a later point. > > - I reinstated, in a fashion, the special handling of reservations on > Windows. On all platforms we reserve address space to map the archive files > in with a subsequent mapping operation. However, on Windows, we cannot use > MapViewOfFile() into an existing mapping. So I remove the mapping again > before mapping the archives - see comment in code for details. > > > I missed this windows part of the change, where is it? > Follow the trail Ioi led with "MetaspaceShared::use_windows_memory_mapping()". In original coding this is a complicated dance between MetaspaceShared::reserve_address_space_for_archives and FileMapInfo::map_region, the implicit knowledge here is that these functions are called twice, first time trying to attach to the archive base address (which is the nice fast case, no relocation) and the second time trying to attach anywhere. In MetaspaceShared::reserve_address_space_for_archives, we want to reserve space for archive and ccs laying one beside the other; later we plan to map the archive file into the prereserved archive space. But that does not work on Windows, you cannot map into pre-reserved space; so the first time we do this we explicitly do *not* reserve the archive space (windows only), just the class space. Then we attempt to map the archive space into that region which is not reserved yet but hopefully unpopulated. Since that may not work, we call MetaspaceShared::reserve_address_space_for_archives a second time, this time reserving both archive space and css, and this time around instead of mapping the archive file in Ioi just reads it sequentially. This is slower than mapping the file, but his reasoning is that this does not matter since he needs to relocate anyway - different base address - so the sequential read does not hurt performance. I think this all makes sense. Its the fastest way of doing this. In my first attempt at this patch I wanted to simplify things and just always read sequentially; but that hurt startup time on WIndows when the cds was big. So I just tried to make the code a bit simpler and more faultproof: in my version of MetaspaceShared::reserve_address_space_for_archives, I always unconditionally reserve space for both archive and ccs. Then, returning from that function, in MetaspaceShared::map_archives(), I unreserve the archive again on windows, so subsequent mappings to this address can succeed. I think this makes the code a bit clearer, and an additional advantage is that since we were able to reserve at that address already once the chance is very high that mapping of the files some milliseconds later will succeed. Not guaranteed though, that is why the second time around we use the original sequential read logic. > > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/virtualSpaceList.cpp.udiff.html > > Why did you make this change? Shouldn't the caller align it? > Probably yes. I'll remove this again. > > Looks good to me. > Coleen > > Thanks! I'll post an update in the next days to incorporate yours and Iois feedback and rebase the patch. Cheers, Thomas > > All CI tests at SAP run through without problems, including on Win64 and > aarch64, but I would be happy if others were to run test too. > > Thank you, Thomas > > On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe > wrote: > >> Hi all, >> >> Could I have reviews for the following proposal of reworking cds/class >> space reservation? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >> >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >> >> (Many thanks to Ioi Lam for so patiently explaining CDS internals to me, >> and to Andrew Haley and Nick Gasson for help with aarch64!) >> >> Reservation of the compressed class space is needlessly complicated and >> has some minor issues. It can be simplified and made clearer. >> >> The complexity stems from the fact that this area lives at the >> intersection of two to three sub systems, depending on how one counts. >> Metaspace, CDS, and the platform which may or may not its own view of how >> to reserve class space. And this code has been growing organically over >> time. >> >> One small example: >> >> ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t >> alignment, >> bool large_pages, char >> *requested_addr, >> bool use_requested_addr) >> >> which I spent hours decoding, resulting in a very confused mail to >> hs-runtime and aarch64-port-dev [2]. >> >> This patch attempts to simplify cds and metaspace setup a bit; to comment >> implicit knowledge which is not immediately clear; to cleanly abstract >> platform concerns like optimized class space placement; and to disentangle >> cds from metaspace to solve issues which may bite us later with Elastic >> Metaspace [4]. >> >> --- >> >> The main change is the reworked reservation mechanism. This is based on >> Ioi's proposal [5]. >> >> When reserving class space, three things must happen: >> >> 1) reservation of the space obviously. If cds is active that space must >> be in the vicinity of cds archives to be covered by compressed class >> pointer encoding. >> 2) setting up the internal Metaspace structures atop of that space >> 3) setting up compressed class pointer encoding. >> >> In its current form, Metaspace may or may not do some or all of that in >> one function >> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, >> it will reserve the space for Metaspace and hand it in, otherwise it will >> create it itself. >> >> When discussing this in [2], Ioi proposed to move the reservation of the >> class space completely out of Metaspace and make it a responsibility of the >> caller always. This would reduce some complexity, and this patch follows >> the proposal. >> >> I removed >> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base); and all its sub >> functions. >> >> (1) now has to always be done outside - a ReservedSpace for class space >> has to be provided by the caller. However, Metaspace now offers a utility >> function for reserving space at a "nice" location, and explicitly doing >> nothing else: >> >> ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >> >> this function can be redefined on a platform level for platform optimized >> reservation, see below for details. >> >> (2) is taken care of by a new function, >> Metaspace::initialize_class_space(ReservedSpace rs) >> >> (3) is taken care of a new function >> CompressedKlassPointers::initialize(), see below for details. >> >> >> So, class space now is set up three explicit steps: >> >> - First, reserve a suitable space by however means you want. For >> convenience you may use >> Metaspace::reserve_address_space_for_compressed_classes(), or you may roll >> your own reservation. >> - Next, tell Metaspace to use that range as backing storage for class >> space: Metaspace::initialize_class_space(ReservedSpace rs) >> - Finally, set up encoding. Encoding is independent from the concept of a >> ReservedSpace, it just gets an address range, see below for details. >> >> Separating these steps and moving them out of the responsibility of >> Metaspace makes this whole thing more flexible; it also removes unnecessary >> knowledge (e.g. Metaspace does not need to know anything about either ccp >> encoding or cds). >> >> --- >> >> How it comes together: >> >> If CDS is off, we just reserve a space using >> Metaspace::reserve_address_space_for_compressed_classes(), initialize it >> with Metaspace::initialize_class_space(ReservedSpace rs), then set up >> compressed class pointer encoding covering the range of this class space. >> >> If CDS is on (dump time), we reserve large 4G space, either at >> SharedBaseAddress or using >> Metaspace::reserve_address_space_for_compressed_classes(); we then split >> that into 3G archive space and 1G class space; we set up that space with >> Metaspace as class space; then we set up compressed class pointer encoding >> covering both archive space and cds. >> >> If CDS is on (run time), we reserve a large space, split it into archive >> space (large enough to hold both archives) and class space, then basically >> proceed as above. >> >> Note that this is almost exactly how things worked before (modulo some >> minor fixes, e.g. alignment issues), only the code is reformed and made >> more explicit. >> >> --- >> >> I moved compressed class pointer setup over to CompressedKlassPointers >> and changed the interface: >> >> -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >> metaspace_rs, address cds_base) >> +void CompressedKlassPointers::initialize(address addr, size_t len); >> >> Instead of feeding it a single ReservedSpace, which is supposed to >> represent class space, and an optional alternate base if cds is on, now we >> give it just an numeric address range. That range marks the limits to where >> Klass structures are to be expected, and is the implicit promise that >> outside that range no Klass structures will exist, so encoding has to cover >> only this range. >> >> This range may contain just the class space; or class space+cds; or >> whatever allocation scheme we come up with in the future. Encoding does not >> really care how the memory is organized as long as the input range covers >> all possible Klass locations. That way we remove knowledge about class >> space/cds from compressed class pointer encoding. >> >> Moving it away from metaspace.cpp into the CompressedKlassPointers class >> also mirrors CompressedOops::initialize(). >> >> --- >> >> I renamed _narrow_klass_range to just _range, because strictly speaking >> this is the range un-narrow Klass pointers can have. >> >> As for the implementation of CompressedKlassPointers::initialize(address >> addr, size_t len), I mimicked very closely what happened before, so there >> should be almost no differences. Since "almost no differences" sounds scary >> :) here are the differences: >> >> - When CDS is active (dump or run time) we now always, unconditionally, >> set the encoding range to 4G. This fixes a theoretical bug discussed on >> aarch64-port-dev [1]. >> >> - When CDS is not active, we set the encoding range to the minimum >> required length. Before, it was left at its default value of 4G. >> >> Both differences only affect aarch64, since they are currently the only >> one using the range field in CompressedKlassPointers. >> >> I wanted to add an assert somewhere to test encoding of the very last >> address of the CompressedKlassPointers range, again to prevent errors like >> [3]. But I did not come up with a good place for this assert which would >> cover also the encoding done by C1/C2. >> >> For the same reason I thought about introducing a mode where Klass >> structures would be allocated in reverse order, starting at the end of the >> ccs, but again left it out as too big a change. >> >> --- >> >> OS abstraction: platforms may have restrictions of what constitutes a >> valid compressed class pointer encoding base. Or if not, they may have at >> least preferences. There was logic like this in metaspace.cpp, which I >> removed and cleanly factored out into platform dependent files, giving each >> platform the option to add special logic. >> >> These are two new methods: >> >> - bool CompressedKlassPointers::is_valid_base(address p) >> >> to let the platform tell you whether it considers p to be a valid >> encoding base. The only platform having these restrictions currently is >> aarch64. >> >> - ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >> >> this hands over the process of allocating a range suitable for compressed >> class pointer encoding to the platform. Most platforms will allocate just >> anywhere, but some platforms may have a better strategy (e.g. trying low >> memory first, trying only correctly aligned addresses and so on). >> >> Beforehand, this coding existed in a similar form in metaspace.cpp for >> aarch64 and AIX. For now, I left the AIX part out - it seems only half >> done, and I want to check further if we even need it, if yes why not on >> Linux ppc, and C1 does not seem to support anything other than base+offset >> with shift either, but I may be mistaken. >> >> These two methods should give the platform enough control to implement >> their own scheme for optimized class space placement without bothering any >> shared code about it. >> >> Note about the form, I introduced two new platform dependent files, >> "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about >> this but this seems to be what we generally do in hotspot, right? >> >> --- >> >> Metaspace reserve alignment vs cds alignment >> >> CDS was using Metaspace reserve alignment for CDS internal purposes. I >> guess this was just a copy paste issue. It never caused problems since >> Metaspace reserve alignment == page size, but that is not true anymore in >> the upcoming Elastic Metaspace where reserve alignment will be larger. This >> causes a number of issues. >> >> I separated those two cleanly. CDS now uses >> os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in >> those two places where it is needed, when CDS creates the address space for >> class space on behalf of the Metaspace. >> >> --- >> >> Windows special handling in CDS >> >> To simplify coding I removed the windows specific handling which left out >> reservation of the archive. This was needed because windows cannot mmap >> files into reserved regions. But fallback code exists in filemap.cpp for >> this case which just reads in the region instead of mapping it. >> >> Should that turn out to be a performance problem, I will reinstate the >> feature. But a simpler way would be reserve the archive and later just >> before mmapping the archive file to release the archive space. That would >> not only be simpler but give us the best guarantee that that address space >> is actually available. But I'd be happy to leave that part out completely >> if we do not see any performance problems on windows x64. >> >> --- >> >> NMT cannot deal with spaces which are split. This problem manifests in >> that bookkeeping for class space is done under "Shared Classes", not >> "Classes" as it should. This problem exists today too at dump time and >> randomly at run time. But since I simplified the reservation, this problem >> now shows up always, whether or not we map at the SharedBaseAddress. >> While I could work around this problem, I'd prefer this problem to be >> solved at the core, and NMT to have an option to recognize reservation >> splits. So I'd rather not put a workaround for this into the patch but >> leave it for fixing as a separate issue. I opened this issue to track it >> [6]. >> >> --- >> >> Jtreg tests: >> >> I expanded the CompressedOops/CompressedClassPointers.java. I also >> extended them to Windows. The tests now optionally omit strict class space >> placement tests, since these tests heavily depend on ASLR and were the >> reason they were excluded on Windows. However I think even without checking >> for class space placement they make sense, just to see that the VM comes up >> and lives with the many different settings we can run in. >> >> --- >> >> Tests: >> >> - I ran the patch through Oracles submit repo >> - I ran tests manually for aarch64, zero, linux 32bit and windows x64 >> - The whole battery of nightly tests at SAP, including ppc, ppcle and >> aarch64, unfortunately excluding windows because of unrelated errors. >> Windows x64 tests will be redone tonight. >> >> >> Thank you, >> >> Thomas >> >> [1] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >> [2] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >> [5] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >> >> > From thomas.stuefe at gmail.com Sat May 16 08:22:21 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Sat, 16 May 2020 10:22:21 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: <1108ac1a-f693-cfc7-9f86-1a84508b1487@oracle.com> References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> <1108ac1a-f693-cfc7-9f86-1a84508b1487@oracle.com> Message-ID: On Sat, May 16, 2020 at 12:34 AM wrote: > > One more in-context comment. > > On 5/8/20 3:33 AM, Thomas St?fe wrote: > > Hi Ioi, > > thanks for taking the time to look at this! > > On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: > >> Hi Thomas, >> >> I am running your patch in out CI pipeline now. Some comments: >> >> [1] Do we still need to use _class_space_list? It looks like we just have >> a single range. Is _class_space_list->current_virtual_space() always the >> same VS? >> >> if (_class_space_list != NULL) { >> address base = >> (address)_class_space_list->current_virtual_space()->bottom(); >> address top = base + compressed_class_space_size(); >> st->print("Compressed class space mapped at: " PTR_FORMAT "-" >> PTR_FORMAT ", size: " SIZE_FORMAT, >> p2i(base), p2i(top), top - base); >> >> > Yes it is. Has been bugging me for years too. With ccs, the > VirtualSpaceList is degenerated and only contains one node. It still makes > some sense code wise. But maybe VirtualSpace*List* is a misnomer. > > It also ties in into the question whether Metaspace reservations should be > able to grow on demand. Oracle folks I talk to tend to say yes. I > personally think the "Metaspace is infinite don't worry" meme was broken > since ccs was a thing, since CompressedClassSpaceSize is an absolute limit > already. > > I may tweak and simplify the code a bit with Elastic Metaspace. Maybe, as > you say, with ccs we can get rid of VirtualSpaceList and deal with the > range directly. Have to check. > > > Yes, this could be an improvement for a later time. The compressed class > space isn't a list. I think that was the least amount of special code > place to hook it in at the time. It makes sense for it to be a single > VirtualSpaceNode. > > CompressedClassSpace + Data (the rest of Metaspace) has a complicated > relationship for determining high water mark for starting GC, and for > reporting LowMemory thresholds. I'd have to look up what was decided there. > Data (the rest of Metaspace) does grow on demand unless someone uses > -XX:MaxMetaspaceSize and then class metaspace size is factored in (maybe > just committed space not the whole 1G). HTH. > > We stop growing when [committed class space]+[committed data] >= MaxMetaspaceSize. CompressedClassSpaceSize is actually completely uninteresting for calculating limits, it is just an additional, technical limit on the growth of [committed class space]. Even this equation: MaxMetaspaceSize = CompressedClassSpaceSize+data is actually not correct, even though the code treats it that way. We could set CompressedClassSpaceSize much higher than MaxMetaspaceSize, we only would not be able to commit the whole class space then, but it still would work. I simplified all this in Elastic Metaspace. GC threshold calculation is unaffected though. ..Thomas > Coleen > > From kim.barrett at oracle.com Sat May 16 17:39:03 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Sat, 16 May 2020 13:39:03 -0400 Subject: [aarch64-port-dev ] RFR[xs]: 8245137: aarch64 ICache flush depends on enabling gnu extensions Message-ID: <67FA9401-05A9-40CC-95EE-549317EA218A@oracle.com> Please review this small change to the aarch64 implementation of ICache::invalidate_word ICache::invalidate_range. Rather than calling __clear_cache directly, they are changed to use __builtin___clear_cache. The direct call to __clear_cache requires either providing a declaration for that function or enabling gnu extensions. Using the builtin requires neither. CR: https://bugs.openjdk.java.net/browse/JDK-8245137 Webrev: https://cr.openjdk.java.net/~kbarrett/8245137/open.00/ Testing: mach5 tier1-5 with -std=c++14 as part of experimental C++14 support. mach5 tier1 Note that there are unrelated build failures with -std=c++98. Among other things, we use va_copy in shared code, which is not available until C++11 (because it's a C99 feature), but is made available as a gnu extension with -std=gnu++98. From aph at redhat.com Sun May 17 11:02:45 2020 From: aph at redhat.com (Andrew Haley) Date: Sun, 17 May 2020 12:02:45 +0100 Subject: [aarch64-port-dev ] RFR[xs]: 8245137: aarch64 ICache flush depends on enabling gnu extensions In-Reply-To: <67FA9401-05A9-40CC-95EE-549317EA218A@oracle.com> References: <67FA9401-05A9-40CC-95EE-549317EA218A@oracle.com> Message-ID: <7f5b5fb8-2825-2395-d833-655be7aea36e@redhat.com> On 5/16/20 6:39 PM, Kim Barrett wrote: > Please review this small change to the aarch64 implementation of > ICache::invalidate_word ICache::invalidate_range. Rather than calling > __clear_cache directly, they are changed to use __builtin___clear_cache. > The direct call to __clear_cache requires either providing a > declaration for that function or enabling gnu extensions. Using the > builtin requires neither. > > CR: > https://bugs.openjdk.java.net/browse/JDK-8245137 > > Webrev: > https://cr.openjdk.java.net/~kbarrett/8245137/open.00/ Sure, it all ends up in libgcc's __aarch64_sync_cache_range anyway. I've been a little wary of __builtin___clear_cache for a while, given that we need to be certain exactly what it does in order to ensure the correctness of HotSpot, but the code in libgcc is fine. 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 ci_notify at linaro.org Sun May 17 15:19:55 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 17 May 2020 15:19:55 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 14 on AArch64 Message-ID: <1634191078.505.1589728795928.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/openjdk-jtreg-nightly-tests/summary/2020/136/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 5,773; fail: 45 Build 1: aarch64/2020/jan/30 pass: 5,773; fail: 45 Build 2: aarch64/2020/feb/06 pass: 5,773; fail: 46 Build 3: aarch64/2020/feb/09 pass: 5,775; fail: 44 Build 4: aarch64/2020/apr/07 pass: 5,781; fail: 45 Build 5: aarch64/2020/may/05 pass: 5,762; fail: 45 Build 6: aarch64/2020/may/07 pass: 5,763; fail: 44 Build 7: aarch64/2020/may/12 pass: 5,761; fail: 46 Build 8: aarch64/2020/may/15 pass: 5,784; fail: 46 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 8,831; fail: 524; error: 18 Build 1: aarch64/2020/jan/30 pass: 8,839; fail: 518; error: 17 Build 2: aarch64/2020/feb/06 pass: 8,838; fail: 517; error: 18 Build 3: aarch64/2020/feb/09 pass: 8,832; fail: 523; error: 18 Build 4: aarch64/2020/apr/07 pass: 8,844; fail: 505; error: 20 Build 5: aarch64/2020/may/05 pass: 8,839; fail: 515; error: 18 Build 6: aarch64/2020/may/07 pass: 8,835; fail: 517; error: 20 Build 7: aarch64/2020/may/12 pass: 8,836; fail: 517; error: 19 Build 8: aarch64/2020/may/15 pass: 8,845; fail: 509; error: 18 6 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 4,031 Build 1: aarch64/2020/jan/30 pass: 4,031 Build 2: aarch64/2020/feb/03 pass: 4,031 Build 3: aarch64/2020/feb/06 pass: 4,031 Build 4: aarch64/2020/feb/09 pass: 4,031 Build 5: aarch64/2020/apr/07 pass: 4,031 Build 6: aarch64/2020/may/05 pass: 4,031 Build 7: aarch64/2020/may/07 pass: 4,031 Build 8: aarch64/2020/may/12 pass: 4,031 Build 9: aarch64/2020/may/15 pass: 4,031 Previous results can be found here: http://openjdk.linaro.org/jdk14/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.63x Relative performance: Server critical-jOPS (nc): 9.13x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/023/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/037/results/ 2020-02-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/040/results/ 2020-04-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/098/results/ 2020-05-06 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/126/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/128/results/ 2020-05-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/133/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/136/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/ From ci_notify at linaro.org Sun May 17 15:23:05 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sun, 17 May 2020 15:23:05 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 11u on AArch64 Message-ID: <213451510.507.1589728985926.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/summary/2020/136/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/09 pass: 5,773; fail: 3 Build 1: aarch64/2019/nov/16 pass: 5,775; fail: 1 Build 2: aarch64/2019/nov/21 pass: 5,775; fail: 1 Build 3: aarch64/2019/dec/05 pass: 5,775; fail: 1 Build 4: aarch64/2019/dec/08 pass: 5,775; fail: 1 Build 5: aarch64/2019/dec/14 pass: 5,775; fail: 1 Build 6: aarch64/2019/dec/17 pass: 5,775; fail: 1 Build 7: aarch64/2019/dec/21 pass: 5,775; fail: 1 Build 8: aarch64/2020/jan/16 pass: 5,775; fail: 1 Build 9: aarch64/2020/jan/30 pass: 5,791; fail: 1 Build 10: aarch64/2020/feb/06 pass: 5,791; fail: 1 Build 11: aarch64/2020/feb/13 pass: 5,792; fail: 1 Build 12: aarch64/2020/apr/30 pass: 5,813; fail: 1 Build 13: aarch64/2020/may/07 pass: 5,813; fail: 2 Build 14: aarch64/2020/may/15 pass: 5,814; fail: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/09 pass: 8,487; fail: 470; error: 16 Build 1: aarch64/2019/nov/16 pass: 8,475; fail: 484; error: 15 Build 2: aarch64/2019/nov/21 pass: 8,489; fail: 497; error: 13 Build 3: aarch64/2019/dec/05 pass: 8,492; fail: 501; error: 11 Build 4: aarch64/2019/dec/08 pass: 8,482; fail: 505; error: 17 Build 5: aarch64/2019/dec/14 pass: 8,512; fail: 481; error: 12 Build 6: aarch64/2019/dec/17 pass: 8,485; fail: 505; error: 15 Build 7: aarch64/2019/dec/21 pass: 8,499; fail: 496; error: 10 Build 8: aarch64/2020/jan/16 pass: 8,513; fail: 474; error: 17 Build 9: aarch64/2020/jan/30 pass: 8,513; fail: 501; error: 13 Build 10: aarch64/2020/feb/06 pass: 8,496; fail: 517; error: 14 Build 11: aarch64/2020/feb/13 pass: 8,509; fail: 507; error: 14 Build 12: aarch64/2020/apr/30 pass: 8,534; fail: 519; error: 15 Build 13: aarch64/2020/may/07 pass: 8,540; fail: 515; error: 12 Build 14: aarch64/2020/may/15 pass: 8,558; fail: 498; error: 11 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/09 pass: 3,910 Build 1: aarch64/2019/nov/16 pass: 3,910 Build 2: aarch64/2019/nov/21 pass: 3,910 Build 3: aarch64/2019/dec/05 pass: 3,910 Build 4: aarch64/2019/dec/08 pass: 3,910 Build 5: aarch64/2019/dec/14 pass: 3,910 Build 6: aarch64/2019/dec/17 pass: 3,910 Build 7: aarch64/2019/dec/21 pass: 3,910 Build 8: aarch64/2020/jan/16 pass: 3,910 Build 9: aarch64/2020/jan/30 pass: 3,913 Build 10: aarch64/2020/feb/06 pass: 3,913 Build 11: aarch64/2020/feb/13 pass: 3,913 Build 12: aarch64/2020/apr/30 pass: 3,913 Build 13: aarch64/2020/may/07 pass: 3,913 Build 14: aarch64/2020/may/15 pass: 3,913 Previous results can be found here: http://openjdk.linaro.org/jdk11u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.21x Relative performance: Server critical-jOPS (nc): 7.76x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk11u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-11-01 pass rate: 10489/10489, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/304/results/ 2019-11-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/313/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/320/results/ 2019-11-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/325/results/ 2019-12-07 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/339/results/ 2019-12-09 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/342/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/348/results/ 2019-12-18 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/351/results/ 2019-12-22 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2019/355/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/037/results/ 2020-02-14 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/044/results/ 2020-05-01 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/121/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/128/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/2020/136/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk11u/jcstress-nightly-runs/ From Yang.Zhang at arm.com Mon May 18 05:51:03 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Mon, 18 May 2020 05:51:03 +0000 Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs In-Reply-To: References: Message-ID: Hi all Re-ping. If anyone has bandwidth, would he be able to review this patch? Regards Yang -----Original Message----- From: aarch64-port-dev On Behalf Of Yang Zhang Sent: Wednesday, May 6, 2020 4:46 PM To: aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: [aarch64-port-dev ] RFR(S): 8243597: AArch64: Add support for integer vector abs Hi, Could you please help to review this patch? JBS: https://bugs.openjdk.java.net/browse/JDK-8243597 Webrev: http://cr.openjdk.java.net/~yzhang/8243597/webrev.00/ In JDK-8222074 [1], x86 enables auto vectorization for integer vector abs, and jtreg tests are also added. In this patch, the missing AbsVB/S/I/L support for AArch64 is added. Testing: Full jtreg test Vector API tests which cover vector abs Test case: public static void absvs(short[] a, short[] b, short[] c) { for (int i = 0; i < a.length; i++) { c[i] = (short)Math.abs((a[i] + b[i])); } } Assembly code generated by C2: 0x0000ffffaca3f3ac: ldr q17, [x16, #16] 0x0000ffffaca3f3b0: ldr q16, [x15, #16] 0x0000ffffaca3f3b4: add v16.8h, v16.8h, v17.8h 0x0000ffffaca3f3b8: abs v16.8h, v16.8h 0x0000ffffaca3f3c0: str q16, [x12, #16] Similar test cases for byte/int/long are also tested and NEON abs instruction is generated by C2. Performance: JMH tests are uploaded. http://cr.openjdk.java.net/~yzhang/8243597/TestScalar.java http://cr.openjdk.java.net/~yzhang/8243597/TestVect.java Vector abs: Before: Benchmark (size) Mode Cnt Score Error Units TestVect.testVectAbsVB 1024 avgt 5 1041.720 ? 2.606 us/op TestVect.testVectAbsVI 1024 avgt 5 659.788 ? 2.057 us/op TestVect.testVectAbsVL 1024 avgt 5 711.043 ? 5.489 us/op TestVect.testVectAbsVS 1024 avgt 5 659.157 ? 2.531 us/op After Benchmark (size) Mode Cnt Score Error Units TestVect.testVectAbsVB 1024 avgt 5 88.821 ? 1.886 us/op TestVect.testVectAbsVI 1024 avgt 5 199.081 ? 2.539 us/op TestVect.testVectAbsVL 1024 avgt 5 447.536 ? 1.195 us/op TestVect.testVectAbsVS 1024 avgt 5 119.172 ? 0.340 us/op Scalar abs: Before: Benchmark (size) Mode Cnt Score Error Units TestScalar.testAbsI 1024 avgt 5 3770.345 ? 6.760 us/op TestScalar.testAbsL 1024 avgt 5 3767.570 ? 9.097 us/op After: Benchmark (size) Mode Cnt Score Error Units TestScalar.testAbsI 1024 avgt 5 3141.312 ? 2.000 us/op TestScalar.testAbsL 1024 avgt 5 3103.143 ? 8.989 us/op [1] https://bugs.openjdk.java.net/browse/JDK-8222074 Regards Yang From nick.gasson at arm.com Mon May 18 07:10:57 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Mon, 18 May 2020 15:10:57 +0800 Subject: [aarch64-port-dev ] AArch64: Neoverse N1 atomic operations and -moutline-atomics In-Reply-To: References: <3a5e43e7-2039-8574-7470-5827267fb88d@redhat.com> Message-ID: <854ksd3egu.fsf@arm.com> On 05/05/20 19:40 pm, Andrew Haley wrote: > On 5/5/20 12:32 PM, Andrew Haley wrote: >> This is, as you can see, horrible, but but thankfully we don't have to >> change AArch64 HotSpot because we use GCC's atomic builtins everywhere >> in C++ code. All we'll have to do is compile HotSpot with a new GCC >> and we'll be done. > > Having said that, we should fix the AArch64 HotSpot build so that we > use the -moutline-atomics option whenever it's available. I've done some profiling of SPECjbb on N1. Building with -moutline-atomics gives around +4% on critical-jOPS and +0.2% on max-jOPS averaged over several runs. However enabling this globally will cause a slight regression on machines that don't support the LSE extension due to the overhead of the function call and branch (~1% for critical-jOPS on one machine). Question is whether it's best to enable this by default in OpenJDK or leave it to downstream distributions to decide? -- Nick From rahul.v.raghavan at oracle.com Mon May 18 08:29:24 2020 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Mon, 18 May 2020 13:59:24 +0530 Subject: [aarch64-port-dev ] Fwd: RFR(XXS):8244170: correct instruction typo for dcps1/2/3 In-Reply-To: <3F8C4202-6810-4CC6-BB77-656A6D71E9D3@amazon.com> References: <3F8C4202-6810-4CC6-BB77-656A6D71E9D3@amazon.com> Message-ID: <738cd983-e991-dad9-5e6c-8bddb2a8951a@oracle.com> -------- Forwarded Message -------- Subject: RFR(XXS):8244170: correct instruction typo for dcps1/2/3 Date: Thu, 30 Apr 2020 08:11:32 +0000 From: Liu, Xin To: hotspot-compiler-dev at openjdk.java.net Hi, Please review the typo correction change for aarch64. The change is trivial. It just makes the instruction name dcps same as armv8 manual. JBS: https://cr.openjdk.java.net/~xliu/8244170/webrev/ webrev: https://bugs.openjdk.java.net/browse/JDK-8244170 I ran hotspot-tier1 and no regression found for fastdebug build on aarch64. Thanks, --lx From adinn at redhat.com Mon May 18 09:37:39 2020 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 18 May 2020 10:37:39 +0100 Subject: [aarch64-port-dev ] RFR(XXS):8244170: correct instruction typo for dcps1/2/3 In-Reply-To: <3F8C4202-6810-4CC6-BB77-656A6D71E9D3@amazon.com> References: <3F8C4202-6810-4CC6-BB77-656A6D71E9D3@amazon.com> Message-ID: On 30/04/2020 09:11, Liu, Xin wrote: > Please review the typo correction change for aarch64. > The change is trivial. It just makes the instruction name dcps same as armv8 manual. > > JBS: https://cr.openjdk.java.net/~xliu/8244170/webrev/ > webrev: https://bugs.openjdk.java.net/browse/JDK-8244170 > > I ran hotspot-tier1 and no regression found for fastdebug build on aarch64. Reviewed! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Mon May 18 09:53:25 2020 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 May 2020 10:53:25 +0100 Subject: [aarch64-port-dev ] AArch64: Neoverse N1 atomic operations and -moutline-atomics In-Reply-To: <854ksd3egu.fsf@arm.com> References: <3a5e43e7-2039-8574-7470-5827267fb88d@redhat.com> <854ksd3egu.fsf@arm.com> Message-ID: <280d2657-7997-1dac-f370-8ff41a0b3035@redhat.com> On 5/18/20 8:10 AM, Nick Gasson wrote: > I've done some profiling of SPECjbb on N1. Building with > -moutline-atomics gives around +4% on critical-jOPS and +0.2% on > max-jOPS averaged over several runs. However enabling this globally will > cause a slight regression on machines that don't support the LSE > extension due to the overhead of the function call and branch (~1% for > critical-jOPS on one machine). Mmm. That's not a nice decision to have to make. > Question is whether it's best to enable this by default in OpenJDK or > leave it to downstream distributions to decide? I don't really understand why there is a conditional branch there. They could just do the test at startup and patch the code. Maybe it'd hurt DSO startup time or something? Maybe they don't like the idea of temporarily enabling exec privilege on a page of writable 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 martin.doerr at sap.com Mon May 18 14:31:24 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Mon, 18 May 2020 14:31:24 +0000 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: <55D731CD-5C89-47E5-B61A-83304E5123ED@amazon.com> References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> <55D731CD-5C89-47E5-B61A-83304E5123ED@amazon.com> Message-ID: Hi lx, > It's my fault. I should associate with the bug id in the subject. I will double > check the email subject before sending. Thanks and no problem. > Now this thread becomes an RFR for JDK-8244949. So, you just try it out in > ppc? JDK-8244949 is just for PPC64. I think it's large enough to keep it separate. I've left out the addition of the HaltNode message which is subject of your change which is still wanted. I don't know if Andrew wants to integrate his aarch64 part into your change or push it separately. It would be nice to do it also for s390, but I have limited time for this platform. We could live without my enhancement or do it later. > I am not reviewer. just my 2 cents. Your review is appreciated. > 1. nativeInst_ppc.hpp. > I think the return type of get_stop_type() should be 'int' here. > > bool get_stop_type() { > return MacroAssembler::tdi_get_si16(long_at(0), > Assembler::traptoUnconditional, 0); > } > > 2. nativeInst_ppc.cpp > NativeInstruction::is_sigill_zombie_not_entrant_at() comment still says "iff > !UseSIGTRAP". Thanks a lot for reviewing my preliminary version. I'll update the webrev in place before sending a RFR email. > 3. TrapBasedNotEntrantChecks is a product option. Is it too abrupt to drop it? > This wiki defines the lifecycle of a Jvm option, but I believe this one is special. > It's ppc only. The point is "It's ppc only". We don't apply the strict rules as the PPC flags are not properly categorized (product, diagnostic, develop, ...) and we don't expect anyone to set this flag in production. Best regards, Martin > -----Original Message----- > From: Liu, Xin > Sent: Samstag, 16. Mai 2020 02:25 > To: Doerr, Martin ; Andrew Haley > ; Derek White ; Ningsheng Jian > ; hotspot-compiler-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information > when hitting a HaltNode for architectures other than x86 > > Hi, Martin, > It's my fault. I should associate with the bug id in the subject. I will double > check the email subject before sending. > > Now this thread becomes an RFR for JDK-8244949. So, you just try it out in > ppc? > If it works well, we will apply this approach to both 390 and aarch64? > > I am not reviewer. just my 2 cents. > 1. nativeInst_ppc.hpp. > I think the return type of get_stop_type() should be 'int' here. > > bool get_stop_type() { > return MacroAssembler::tdi_get_si16(long_at(0), > Assembler::traptoUnconditional, 0); > } > > 2. nativeInst_ppc.cpp > NativeInstruction::is_sigill_zombie_not_entrant_at() comment still says "iff > !UseSIGTRAP". > > 3. TrapBasedNotEntrantChecks is a product option. Is it too abrupt to drop it? > This wiki defines the lifecycle of a Jvm option, but I believe this one is special. > It's ppc only. > https://wiki.openjdk.java.net/display/HotSpot/Hotspot+Command- > line+Flags%3A+Kinds%2C+Lifecycle+and+the+CSR+Process > > Thanks, > --lx > > > > ?On 5/15/20, 3:38 AM, "Doerr, Martin" wrote: > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > Exactly, we get stop type + stop message + registers + instructions > (unfortunately not disassembled for some reason) + nice stack trace. > > Best regards, > Martin > > > > -----Original Message----- > > From: Andrew Haley > > Sent: Freitag, 15. Mai 2020 10:57 > > To: Doerr, Martin ; Derek White > > ; Ningsheng Jian ; > Liu, > > Xin ; hotspot-compiler-dev at openjdk.java.net > > Cc: aarch64-port-dev at openjdk.java.net > > Subject: Re: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information > > when hitting a HaltNode for architectures other than x86 > > > > On 5/14/20 8:24 PM, Doerr, Martin wrote: > > > Just for you upfront in case you would like to take a look: > > > https://bugs.openjdk.java.net/browse/JDK-8244949 > > > > > > http://cr.openjdk.java.net/~mdoerr/8244949_ppc64_asm_stop/webrev.00/ > > > > That's nice: it's a lot more full-featured than what I did. and AFAICS > > you'll get the registers printed in the VM error log. > > > > -- > > Andrew Haley (he/him) > > Java Platform Lead Engineer > > Red Hat UK Ltd. > > https://keybase.io/andrewhaley > > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From thomas.stuefe at gmail.com Mon May 18 14:37:30 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 18 May 2020 16:37:30 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> Message-ID: Hi all, fourth webrev: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ I rebased atop of changeset: 59325:1ba9a9a3f948 summary: 8244433: Remove saving of RSP in Assembler::pusha_uncached() so, atop of "8241825: Make compressed oops and compressed class pointers independent (x86_64, PPC, S390)". The changes are very small this time, see notes below: @Ioi: >Hi Thomas, >I am running your patch in out CI pipeline now. Some comments: >[2] Does JDK-8243535 exist with the current jdk/jdk repo? I assigned JDK-8243535 to me and I'm working on a patch. But I would like to keep that separate from this work, since this patch is already large. And I would like to fix JDK-8243535 after this remodel patch has been pushed, which makes some minor things easier. That would leave a small time window where NMT does mis-track class space as shared class space, but that is not a big issue, it does not even disturb any test. Which in itself is something we may want to fix, come to think about it. > [3] I think this can be put in header file. > > bool Metaspace::class_space_is_initialized() { > return _class_space_list != NULL; > } Done. > [7] argument.cpp checks this: > > if (UseSharedSpaces || DumpSharedSpaces) { > if (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { > log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for this platform, option will be ignored.", > p2i((address)SharedBaseAddress)); > FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); > } > } > > but initialize_dumptime_shared_and_meta_spaces aligns up the SharedBaseAddress before doing the assert. > > void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { > assert(DumpSharedSpaces, "should be called for dump time only"); > > const size_t reserve_alignment = MetaspaceShared::reserved_space_alignment(); > char* shared_base = (char*)align_up((char*)SharedBaseAddress, reserve_alignment); > > #ifdef _LP64 > assert(CompressedKlassPointers::is_valid_base((address)shared_base), "Sanity"); > > So theoretically shared_base may no longer be is_valid_base after the align_up. It probably won't happen, but I think the code will be > much clearer tofirst to align_up, then check for is_valid_base and reset to default, and finally assert. The problem with that is that at the time this coding runs os::init() did not yet run and we do not know yet allocation granularity. So I changed verification of SharedBaseAddress: I added the alignment as you suggested and moved it to a later time in VM initialization, to CDS initialization. >[8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the following block can be simplified: > > if (!_shared_rs.is_reserved()) { > // Get a reserved space anywhere if attaching at the SharedBaseAddress fails: > if (UseCompressedClassPointers) { > // If we need a compressed class space too, let the platform handle the reservation. > _shared_rs = Metaspace::reserve_address_space_for_compressed_classes(cds_total); > } else { > // anywhere is fine. > _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* large */, (char*)NULL); > } > } > > ... if you change the declaration to: > > static ReservedSpace reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return ReservedSpace();}); I'd like to avoid keep the method LP64 only, but I rewrote the section somewhat to be more clearer. > [9] I think the #ifdef _LP64 is not necessary: > > #ifdef _LP64 > // Some sanity checks after reserving address spaces for archives and class space. > assert(archive_space_rs.is_reserved(), "Sanity"); > if (Metaspace::using_class_space()) { > // Class space must closely follow the archive space. Both spaces must be aligned correctly. > assert(class_space_rs.is_reserved(), "A class space should have been reserved"); > assert(class_space_rs.base() >= archive_space_rs.end(), "class space should follow the cds archive space"); > assert(is_aligned(archive_space_rs.base(), MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); > assert(is_aligned(class_space_rs.base(), Metaspace::reserve_alignment()), "class space misaligned"); > } > #endif I removed the #ifdef, but replaced it with an #ifdef ASSERT. Which is also not needed, technically, but makes it clear that this section is debugging checks only. ---- @Coleen: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/ >virtualSpaceList.cpp.udiff.html > >Why did you make this change? Shouldn't the caller align it? You are right, I removed the assert. --- Thanks all for your review work, ..Thomas On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: > Hi Thomas, > > I am running your patch in out CI pipeline now. Some comments: > > [1] Do we still need to use _class_space_list? It looks like we just have > a single range. Is _class_space_list->current_virtual_space() always the > same VS? > > if (_class_space_list != NULL) { > address base = > (address)_class_space_list->current_virtual_space()->bottom(); > address top = base + compressed_class_space_size(); > st->print("Compressed class space mapped at: " PTR_FORMAT "-" > PTR_FORMAT ", size: " SIZE_FORMAT, > p2i(base), p2i(top), top - base); > > [2] Does JDK-8243535 exist with the current jdk/jdk repo? > > // This does currently not work because rs may be the result of a split > operation > // and NMT seems not to be able to handle splits. > // See JDK-8243535. > // MemTracker::record_virtual_memory_type((address)rs.base(), mtClass); > > > [3] I think this can be put in header file. > > bool Metaspace::class_space_is_initialized() { > return _class_space_list != NULL; > } > > [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is the > reason for the > gap in the following chart: > > // We do this by reserving space for the ccs behind the archives. Note > however that > // ccs follows a different alignment (Metaspace::reserve_alignment), > so there may > // be a gap between ccs and cds. > // We use a similar layout at runtime, see > reserve_address_space_for_archives(). > // > // +-- SharedBaseAddress (default = > 0x800000000) > // v > // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > // | Heap | Archive | | MC | RW | RO | [gap] | class > space | > // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > // |<-- MaxHeapSize -->| |<-- UnscaledClassSpaceMax = 4GB -->| > > > _reserve_alignment is determined here: > > void Metaspace::ergo_initialize() { > if (DumpSharedSpaces) { > // Using large pages when dumping the shared archive is currently not > implemented. > FLAG_SET_ERGO(UseLargePagesInMetaspace, false); > } > > size_t page_size = os::vm_page_size(); > if (UseLargePages && UseLargePagesInMetaspace) { > page_size = os::large_page_size(); > } > > _commit_alignment = page_size; > _reserve_alignment = MAX2(page_size, > (size_t)os::vm_allocation_granularity()); > > But when CDS is enabled, the RS is reserved without large pages, so it > should be possible to incrementally commit the CCS using just > os::vm_allocation_granularity(). > > [5] I see the aarch64 code in > Metaspace::reserve_address_space_for_compressed_classes has been changed. > Is this necessary for this RFE, or is it a separate improvement that can be > done in a different RFE? > > [6] For AARCH64, should we skip the part that reserves it right above the > heap? Or does AARCH64 always allocate the heap such that it's a preferable > address? > > // case (b) > ReservedSpace rs; > > // Try right above the Java heap... > address base = align_up(CompressedOops::end(), > Metaspace::reserve_alignment()); > assert(base != NULL, "Sanity"); > > const size_t size = align_up(CompressedClassSpaceSize, > Metaspace::reserve_alignment()); > if (CompressedKlassPointers::is_valid_base(base)) { > rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* > large */, (char*)base); > } > > // ...failing that, reserve anywhere, but let platform do optimized > placement: > if (!rs.is_reserved()) { > rs = Metaspace::reserve_address_space_for_compressed_classes(size); > } > > [7] argument.cpp checks this: > > if (UseSharedSpaces || DumpSharedSpaces) { > if > (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { > log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for > this platform, option will be ignored.", > p2i((address)SharedBaseAddress)); > FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); > } > } > > but initialize_dumptime_shared_and_meta_spaces aligns up the > SharedBaseAddress before doing the assert. > > void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { > assert(DumpSharedSpaces, "should be called for dump time only"); > > const size_t reserve_alignment = > MetaspaceShared::reserved_space_alignment(); > char* shared_base = (char*)align_up((char*)SharedBaseAddress, > reserve_alignment); > > #ifdef _LP64 > assert(CompressedKlassPointers::is_valid_base((address)shared_base), > "Sanity"); > > So theoretically shared_base may no longer be is_valid_base after the > align_up. It probably won't happen, but I think the code will be much > clearer tofirst to align_up, then check for is_valid_base and reset to > default, and finally assert. > > [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the > following block can be simplified: > > if (!_shared_rs.is_reserved()) { > // Get a reserved space anywhere if attaching at the SharedBaseAddress > fails: > if (UseCompressedClassPointers) { > // If we need a compressed class space too, let the platform handle > the reservation. > _shared_rs = > Metaspace::reserve_address_space_for_compressed_classes(cds_total); > } else { > // anywhere is fine. > _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* > large */, (char*)NULL); > } > } > > ... if you change the declaration to: > > static ReservedSpace reserve_address_space_for_compressed_classes(size_t > size) NOT_LP64({ return ReservedSpace();}); > > [9] I think the #ifdef _LP64 is not necessary: > > #ifdef _LP64 > // Some sanity checks after reserving address spaces for archives and > class space. > assert(archive_space_rs.is_reserved(), "Sanity"); > if (Metaspace::using_class_space()) { > // Class space must closely follow the archive space. Both spaces > must be aligned correctly. > assert(class_space_rs.is_reserved(), "A class space should have been > reserved"); > assert(class_space_rs.base() >= archive_space_rs.end(), "class space > should follow the cds archive space"); > assert(is_aligned(archive_space_rs.base(), > MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); > assert(is_aligned(class_space_rs.base(), > Metaspace::reserve_alignment()), "class space misaligned"); > } > #endif > > The rest of the code looks OK to me, but I may take a look at it again > after getting more sleep :-) > > Thanks > - Ioi > > > > > On 5/7/20 7:21 AM, Thomas St?fe wrote: > > Hi all, > > please take a look at the third iteration of this change: > > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ > > Changes in this version: > > - at the request of Coleen (sorry I did not see your post earlier) I > removed all platform dependent files and put the platform dependent coding > back to metaspace.cpp and compressedOops.cpp to ease the review pain. I > used plain platform defines though (#ifdef AARCH64) instead of hiding them > behind another macro to make things clearer. Note that I still intent to > put this code away into the platform corners but will do so in a follow up > RFE. > > - I reinstated, in a fashion, the special handling of reservations on > Windows. On all platforms we reserve address space to map the archive files > in with a subsequent mapping operation. However, on Windows, we cannot use > MapViewOfFile() into an existing mapping. So I remove the mapping again > before mapping the archives - see comment in code for details. > > All CI tests at SAP run through without problems, including on Win64 and > aarch64, but I would be happy if others were to run test too. > > Thank you, Thomas > > On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe > wrote: > >> Hi all, >> >> Could I have reviews for the following proposal of reworking cds/class >> space reservation? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >> >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >> >> (Many thanks to Ioi Lam for so patiently explaining CDS internals to me, >> and to Andrew Haley and Nick Gasson for help with aarch64!) >> >> Reservation of the compressed class space is needlessly complicated and >> has some minor issues. It can be simplified and made clearer. >> >> The complexity stems from the fact that this area lives at the >> intersection of two to three sub systems, depending on how one counts. >> Metaspace, CDS, and the platform which may or may not its own view of how >> to reserve class space. And this code has been growing organically over >> time. >> >> One small example: >> >> ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t >> alignment, >> bool large_pages, char >> *requested_addr, >> bool use_requested_addr) >> >> which I spent hours decoding, resulting in a very confused mail to >> hs-runtime and aarch64-port-dev [2]. >> >> This patch attempts to simplify cds and metaspace setup a bit; to comment >> implicit knowledge which is not immediately clear; to cleanly abstract >> platform concerns like optimized class space placement; and to disentangle >> cds from metaspace to solve issues which may bite us later with Elastic >> Metaspace [4]. >> >> --- >> >> The main change is the reworked reservation mechanism. This is based on >> Ioi's proposal [5]. >> >> When reserving class space, three things must happen: >> >> 1) reservation of the space obviously. If cds is active that space must >> be in the vicinity of cds archives to be covered by compressed class >> pointer encoding. >> 2) setting up the internal Metaspace structures atop of that space >> 3) setting up compressed class pointer encoding. >> >> In its current form, Metaspace may or may not do some or all of that in >> one function >> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, >> it will reserve the space for Metaspace and hand it in, otherwise it will >> create it itself. >> >> When discussing this in [2], Ioi proposed to move the reservation of the >> class space completely out of Metaspace and make it a responsibility of the >> caller always. This would reduce some complexity, and this patch follows >> the proposal. >> >> I removed >> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base); and all its sub >> functions. >> >> (1) now has to always be done outside - a ReservedSpace for class space >> has to be provided by the caller. However, Metaspace now offers a utility >> function for reserving space at a "nice" location, and explicitly doing >> nothing else: >> >> ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >> >> this function can be redefined on a platform level for platform optimized >> reservation, see below for details. >> >> (2) is taken care of by a new function, >> Metaspace::initialize_class_space(ReservedSpace rs) >> >> (3) is taken care of a new function >> CompressedKlassPointers::initialize(), see below for details. >> >> >> So, class space now is set up three explicit steps: >> >> - First, reserve a suitable space by however means you want. For >> convenience you may use >> Metaspace::reserve_address_space_for_compressed_classes(), or you may roll >> your own reservation. >> - Next, tell Metaspace to use that range as backing storage for class >> space: Metaspace::initialize_class_space(ReservedSpace rs) >> - Finally, set up encoding. Encoding is independent from the concept of a >> ReservedSpace, it just gets an address range, see below for details. >> >> Separating these steps and moving them out of the responsibility of >> Metaspace makes this whole thing more flexible; it also removes unnecessary >> knowledge (e.g. Metaspace does not need to know anything about either ccp >> encoding or cds). >> >> --- >> >> How it comes together: >> >> If CDS is off, we just reserve a space using >> Metaspace::reserve_address_space_for_compressed_classes(), initialize it >> with Metaspace::initialize_class_space(ReservedSpace rs), then set up >> compressed class pointer encoding covering the range of this class space. >> >> If CDS is on (dump time), we reserve large 4G space, either at >> SharedBaseAddress or using >> Metaspace::reserve_address_space_for_compressed_classes(); we then split >> that into 3G archive space and 1G class space; we set up that space with >> Metaspace as class space; then we set up compressed class pointer encoding >> covering both archive space and cds. >> >> If CDS is on (run time), we reserve a large space, split it into archive >> space (large enough to hold both archives) and class space, then basically >> proceed as above. >> >> Note that this is almost exactly how things worked before (modulo some >> minor fixes, e.g. alignment issues), only the code is reformed and made >> more explicit. >> >> --- >> >> I moved compressed class pointer setup over to CompressedKlassPointers >> and changed the interface: >> >> -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >> metaspace_rs, address cds_base) >> +void CompressedKlassPointers::initialize(address addr, size_t len); >> >> Instead of feeding it a single ReservedSpace, which is supposed to >> represent class space, and an optional alternate base if cds is on, now we >> give it just an numeric address range. That range marks the limits to where >> Klass structures are to be expected, and is the implicit promise that >> outside that range no Klass structures will exist, so encoding has to cover >> only this range. >> >> This range may contain just the class space; or class space+cds; or >> whatever allocation scheme we come up with in the future. Encoding does not >> really care how the memory is organized as long as the input range covers >> all possible Klass locations. That way we remove knowledge about class >> space/cds from compressed class pointer encoding. >> >> Moving it away from metaspace.cpp into the CompressedKlassPointers class >> also mirrors CompressedOops::initialize(). >> >> --- >> >> I renamed _narrow_klass_range to just _range, because strictly speaking >> this is the range un-narrow Klass pointers can have. >> >> As for the implementation of CompressedKlassPointers::initialize(address >> addr, size_t len), I mimicked very closely what happened before, so there >> should be almost no differences. Since "almost no differences" sounds scary >> :) here are the differences: >> >> - When CDS is active (dump or run time) we now always, unconditionally, >> set the encoding range to 4G. This fixes a theoretical bug discussed on >> aarch64-port-dev [1]. >> >> - When CDS is not active, we set the encoding range to the minimum >> required length. Before, it was left at its default value of 4G. >> >> Both differences only affect aarch64, since they are currently the only >> one using the range field in CompressedKlassPointers. >> >> I wanted to add an assert somewhere to test encoding of the very last >> address of the CompressedKlassPointers range, again to prevent errors like >> [3]. But I did not come up with a good place for this assert which would >> cover also the encoding done by C1/C2. >> >> For the same reason I thought about introducing a mode where Klass >> structures would be allocated in reverse order, starting at the end of the >> ccs, but again left it out as too big a change. >> >> --- >> >> OS abstraction: platforms may have restrictions of what constitutes a >> valid compressed class pointer encoding base. Or if not, they may have at >> least preferences. There was logic like this in metaspace.cpp, which I >> removed and cleanly factored out into platform dependent files, giving each >> platform the option to add special logic. >> >> These are two new methods: >> >> - bool CompressedKlassPointers::is_valid_base(address p) >> >> to let the platform tell you whether it considers p to be a valid >> encoding base. The only platform having these restrictions currently is >> aarch64. >> >> - ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >> >> this hands over the process of allocating a range suitable for compressed >> class pointer encoding to the platform. Most platforms will allocate just >> anywhere, but some platforms may have a better strategy (e.g. trying low >> memory first, trying only correctly aligned addresses and so on). >> >> Beforehand, this coding existed in a similar form in metaspace.cpp for >> aarch64 and AIX. For now, I left the AIX part out - it seems only half >> done, and I want to check further if we even need it, if yes why not on >> Linux ppc, and C1 does not seem to support anything other than base+offset >> with shift either, but I may be mistaken. >> >> These two methods should give the platform enough control to implement >> their own scheme for optimized class space placement without bothering any >> shared code about it. >> >> Note about the form, I introduced two new platform dependent files, >> "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about >> this but this seems to be what we generally do in hotspot, right? >> >> --- >> >> Metaspace reserve alignment vs cds alignment >> >> CDS was using Metaspace reserve alignment for CDS internal purposes. I >> guess this was just a copy paste issue. It never caused problems since >> Metaspace reserve alignment == page size, but that is not true anymore in >> the upcoming Elastic Metaspace where reserve alignment will be larger. This >> causes a number of issues. >> >> I separated those two cleanly. CDS now uses >> os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in >> those two places where it is needed, when CDS creates the address space for >> class space on behalf of the Metaspace. >> >> --- >> >> Windows special handling in CDS >> >> To simplify coding I removed the windows specific handling which left out >> reservation of the archive. This was needed because windows cannot mmap >> files into reserved regions. But fallback code exists in filemap.cpp for >> this case which just reads in the region instead of mapping it. >> >> Should that turn out to be a performance problem, I will reinstate the >> feature. But a simpler way would be reserve the archive and later just >> before mmapping the archive file to release the archive space. That would >> not only be simpler but give us the best guarantee that that address space >> is actually available. But I'd be happy to leave that part out completely >> if we do not see any performance problems on windows x64. >> >> --- >> >> NMT cannot deal with spaces which are split. This problem manifests in >> that bookkeeping for class space is done under "Shared Classes", not >> "Classes" as it should. This problem exists today too at dump time and >> randomly at run time. But since I simplified the reservation, this problem >> now shows up always, whether or not we map at the SharedBaseAddress. >> While I could work around this problem, I'd prefer this problem to be >> solved at the core, and NMT to have an option to recognize reservation >> splits. So I'd rather not put a workaround for this into the patch but >> leave it for fixing as a separate issue. I opened this issue to track it >> [6]. >> >> --- >> >> Jtreg tests: >> >> I expanded the CompressedOops/CompressedClassPointers.java. I also >> extended them to Windows. The tests now optionally omit strict class space >> placement tests, since these tests heavily depend on ASLR and were the >> reason they were excluded on Windows. However I think even without checking >> for class space placement they make sense, just to see that the VM comes up >> and lives with the many different settings we can run in. >> >> --- >> >> Tests: >> >> - I ran the patch through Oracles submit repo >> - I ran tests manually for aarch64, zero, linux 32bit and windows x64 >> - The whole battery of nightly tests at SAP, including ppc, ppcle and >> aarch64, unfortunately excluding windows because of unrelated errors. >> Windows x64 tests will be redone tonight. >> >> >> Thank you, >> >> Thomas >> >> [1] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >> [2] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >> [5] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >> >> > From kim.barrett at oracle.com Mon May 18 14:44:47 2020 From: kim.barrett at oracle.com (Kim Barrett) Date: Mon, 18 May 2020 10:44:47 -0400 Subject: [aarch64-port-dev ] RFR[xs]: 8245137: aarch64 ICache flush depends on enabling gnu extensions In-Reply-To: <7f5b5fb8-2825-2395-d833-655be7aea36e@redhat.com> References: <67FA9401-05A9-40CC-95EE-549317EA218A@oracle.com> <7f5b5fb8-2825-2395-d833-655be7aea36e@redhat.com> Message-ID: > On May 17, 2020, at 7:02 AM, Andrew Haley wrote: > > On 5/16/20 6:39 PM, Kim Barrett wrote: >> Please review this small change to the aarch64 implementation of >> ICache::invalidate_word ICache::invalidate_range. Rather than calling >> __clear_cache directly, they are changed to use __builtin___clear_cache. >> The direct call to __clear_cache requires either providing a >> declaration for that function or enabling gnu extensions. Using the >> builtin requires neither. >> >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8245137 >> >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8245137/open.00/ > > Sure, it all ends up in libgcc's __aarch64_sync_cache_range anyway. > > I've been a little wary of __builtin___clear_cache for a while, given > that we need to be certain exactly what it does in order to ensure the > correctness of HotSpot, but the code in libgcc is fine. > > OK, thanks. Thanks. From xxinliu at amazon.com Mon May 18 21:43:21 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Mon, 18 May 2020 21:43:21 +0000 Subject: [aarch64-port-dev ] RFR(XXS):8244170: correct instruction typo for dcps1/2/3 In-Reply-To: References: <3F8C4202-6810-4CC6-BB77-656A6D71E9D3@amazon.com> Message-ID: <47B6CB94-62D9-4E66-A9C1-0055A43FFA24@amazon.com> Hi, Andrew and Rahul, Thank you to review it. Here is the new revision, which can apply to TIP. It's almost same, I just resolve a merge conflict with JDK-8022574. http://cr.openjdk.java.net/~xliu/8244170/01/webrev/ I ran test on "hotspot:tier1" on aarch64. thanks, --lx ?On 5/18/20, 2:38 AM, "Andrew Dinn" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 30/04/2020 09:11, Liu, Xin wrote: > Please review the typo correction change for aarch64. > The change is trivial. It just makes the instruction name dcps same as armv8 manual. > > JBS: https://cr.openjdk.java.net/~xliu/8244170/webrev/ > webrev: https://bugs.openjdk.java.net/browse/JDK-8244170 > > I ran hotspot-tier1 and no regression found for fastdebug build on aarch64. Reviewed! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From gnu.andrew at redhat.com Tue May 19 01:52:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Tue, 19 May 2020 02:52:22 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b02 Upstream Sync In-Reply-To: <9ddc978f-3863-1970-9829-7546c1d90dc2@redhat.com> References: <5964076f-9adf-8d73-0263-887ae1a7a165@redhat.com> <9ddc978f-3863-1970-9829-7546c1d90dc2@redhat.com> Message-ID: <915d9339-87f2-5834-0094-e42be31f2eaf@redhat.com> On 14/05/2020 06:59, Aleksey Shipilev wrote: > On 5/14/20 12:26 AM, Andrew Hughes wrote: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/corba/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxp/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jaxws/merge.changeset > > Look trivially good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/jdk/merge.changeset > > Looks good. (Ok, this is a fun "" one). > Definitely. >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/hotspot/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/langtools/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/nashorn/merge.changeset >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b02/root/merge.changeset > > Look trivially good. > >> Ok to push? > > Yes. > Thanks, pushed. -- Andrew :) Senior Free Java Software Engineer 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 May 19 01:48:23 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 19 May 2020 01:48:23 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 3 new changesets Message-ID: <202005190148.04J1mN1S021185@aojmv0008.oracle.com> Changeset: 493a0176587e Author: andrew Date: 2020-05-05 18:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/493a0176587e Added tag jdk8u262-b02 for changeset 041cb274be12 ! .hgtags Changeset: f467b0bb09af Author: andrew Date: 2020-05-11 00:07 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/f467b0bb09af Merge jdk8u262-b02 ! .hgtags Changeset: 11b25e3e8d53 Author: andrew Date: 2020-05-11 00:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/11b25e3e8d53 Added tag aarch64-shenandoah-jdk8u262-b02 for changeset f467b0bb09af ! .hgtags From gnu.andrew at redhat.com Tue May 19 01:48:30 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 19 May 2020 01:48:30 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets Message-ID: <202005190148.04J1mUKG021257@aojmv0008.oracle.com> Changeset: e86f6f0db020 Author: andrew Date: 2020-05-05 18:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/e86f6f0db020 Added tag jdk8u262-b02 for changeset 43f43d941996 ! .hgtags Changeset: 23a644b6986b Author: andrew Date: 2020-05-11 00:07 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/23a644b6986b Merge jdk8u262-b02 ! .hgtags Changeset: 65b269fd33bc Author: andrew Date: 2020-05-11 00:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/65b269fd33bc Added tag aarch64-shenandoah-jdk8u262-b02 for changeset 23a644b6986b ! .hgtags From gnu.andrew at redhat.com Tue May 19 01:49:00 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Tue, 19 May 2020 01:49:00 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 3 new changesets Message-ID: <202005190149.04J1n0T1021634@aojmv0008.oracle.com> Changeset: 4ac8eb3eb609 Author: andrew Date: 2020-05-05 18:39 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/4ac8eb3eb609 Added tag jdk8u262-b02 for changeset 60239ecaefa2 ! .hgtags Changeset: f8e07e6cdcab Author: andrew Date: 2020-05-11 00:07 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/f8e07e6cdcab Merge jdk8u262-b02 ! .hgtags Changeset: 02edca7706c6 Author: andrew Date: 2020-05-11 00:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/02edca7706c6 Added tag aarch64-shenandoah-jdk8u262-b02 for changeset f8e07e6cdcab ! .hgtags From ci_notify at linaro.org Tue May 19 03:15:54 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Tue, 19 May 2020 03:15:54 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <285124858.869.1589858154999.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2020/138/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/22 pass: 5,776; fail: 44 Build 1: aarch64/2020/jan/24 pass: 5,775; fail: 45 Build 2: aarch64/2020/jan/27 pass: 5,776; fail: 44 Build 3: aarch64/2020/jan/29 pass: 5,776; fail: 44 Build 4: aarch64/2020/feb/01 pass: 5,777; fail: 46 Build 5: aarch64/2020/feb/03 pass: 5,777; fail: 46 Build 6: aarch64/2020/feb/05 pass: 5,778; fail: 46 Build 7: aarch64/2020/feb/10 pass: 5,781; fail: 46 Build 8: aarch64/2020/feb/12 pass: 5,786; fail: 46 Build 9: aarch64/2020/mar/06 pass: 5,797; fail: 46 Build 10: aarch64/2020/mar/16 pass: 5,796; fail: 47 Build 11: aarch64/2020/apr/08 pass: 5,816; fail: 46; error: 2 Build 12: aarch64/2020/may/09 pass: 5,835; fail: 46 Build 13: aarch64/2020/may/11 pass: 5,835; fail: 46 Build 14: aarch64/2020/may/17 pass: 5,837; fail: 47 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/22 pass: 8,829; fail: 528; error: 19 Build 1: aarch64/2020/jan/24 pass: 8,832; fail: 537; error: 16 Build 2: aarch64/2020/jan/27 pass: 8,846; fail: 523; error: 17 Build 3: aarch64/2020/jan/29 pass: 8,844; fail: 522; error: 19 Build 4: aarch64/2020/feb/01 pass: 8,848; fail: 523; error: 18 Build 5: aarch64/2020/feb/03 pass: 8,851; fail: 525; error: 15 Build 6: aarch64/2020/feb/05 pass: 8,851; fail: 526; error: 15 Build 7: aarch64/2020/feb/10 pass: 8,858; fail: 518; error: 20 Build 8: aarch64/2020/feb/12 pass: 8,849; fail: 525; error: 17 Build 9: aarch64/2020/mar/06 pass: 8,870; fail: 526; error: 17 Build 10: aarch64/2020/mar/16 pass: 8,872; fail: 525; error: 16 Build 11: aarch64/2020/apr/08 pass: 8,891; fail: 532; error: 13 Build 12: aarch64/2020/may/09 pass: 8,929; fail: 543; error: 15 Build 13: aarch64/2020/may/11 pass: 8,929; fail: 544; error: 14 Build 14: aarch64/2020/may/17 pass: 8,934; fail: 542; error: 12 6 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/20 pass: 4,033 Build 1: aarch64/2020/jan/22 pass: 4,033 Build 2: aarch64/2020/jan/24 pass: 4,033 Build 3: aarch64/2020/jan/27 pass: 4,033 Build 4: aarch64/2020/feb/01 pass: 4,036 Build 5: aarch64/2020/feb/03 pass: 4,036 Build 6: aarch64/2020/feb/05 pass: 4,036 Build 7: aarch64/2020/feb/10 pass: 4,037 Build 8: aarch64/2020/feb/12 pass: 4,037 Build 9: aarch64/2020/mar/06 pass: 4,039 Build 10: aarch64/2020/mar/16 pass: 4,039 Build 11: aarch64/2020/apr/08 pass: 4,042 Build 12: aarch64/2020/may/09 pass: 4,052 Build 13: aarch64/2020/may/11 pass: 4,052 Build 14: aarch64/2020/may/17 pass: 4,055 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.83x Relative performance: Server critical-jOPS (nc): 12.14x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 128.32 Server 128.32 / Server 2014-04-01 (71.00): 1.81x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-21 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/020/results/ 2020-01-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/022/results/ 2020-01-25 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/024/results/ 2020-01-28 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/027/results/ 2020-02-02 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/032/results/ 2020-02-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/034/results/ 2020-02-06 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/036/results/ 2020-02-11 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/041/results/ 2020-02-13 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/043/results/ 2020-03-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/066/results/ 2020-03-19 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/076/results/ 2020-04-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/099/results/ 2020-05-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/130/results/ 2020-05-12 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/132/results/ 2020-05-19 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/138/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From thomas.stuefe at gmail.com Tue May 19 04:42:51 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 May 2020 06:42:51 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> Message-ID: Hi Ioi, On Tue, May 19, 2020 at 6:38 AM Ioi Lam wrote: > > > On 5/18/20 7:37 AM, Thomas St?fe wrote: > > Hi all, > > fourth webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ > > I rebased atop of > > changeset: 59325:1ba9a9a3f948 > summary: 8244433: Remove saving of RSP in Assembler::pusha_uncached() > > so, atop of "8241825: Make compressed oops and compressed class pointers > independent (x86_64, PPC, S390)". > > The changes are very small this time, see notes below: > > @Ioi: > > >Hi Thomas, > > >I am running your patch in out CI pipeline now. Some comments: > > >[2] Does JDK-8243535 exist with the current jdk/jdk repo? > > I assigned JDK-8243535 to me and I'm working on a patch. But I would like > to keep that separate from this work, since this patch is already large. > And I would like to fix JDK-8243535 after this remodel patch has been > pushed, which makes some minor things easier. That would leave a small time > window where NMT does mis-track class space as shared class space, but that > is not a big issue, it does not even disturb any test. Which in itself is > something we may want to fix, come to think about it. > > > > [3] I think this can be put in header file. > > > > bool Metaspace::class_space_is_initialized() { > > return _class_space_list != NULL; > > } > > Done. > > > [7] argument.cpp checks this: > > > > if (UseSharedSpaces || DumpSharedSpaces) { > > if > (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { > > log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for > this platform, option will be ignored.", > > p2i((address)SharedBaseAddress)); > > FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); > > } > > } > > > > but initialize_dumptime_shared_and_meta_spaces aligns up the > SharedBaseAddress before doing the assert. > > > > void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { > > assert(DumpSharedSpaces, "should be called for dump time only"); > > > > const size_t reserve_alignment = > MetaspaceShared::reserved_space_alignment(); > > char* shared_base = (char*)align_up((char*)SharedBaseAddress, > reserve_alignment); > > > > #ifdef _LP64 > > assert(CompressedKlassPointers::is_valid_base((address)shared_base), > "Sanity"); > > > > So theoretically shared_base may no longer be is_valid_base after the > align_up. It probably won't happen, but I think the code will be > much > clearer tofirst to align_up, then check for is_valid_base and reset to > default, and finally assert. > > The problem with that is that at the time this coding runs os::init() did > not yet run and we do not know yet allocation granularity. > > So I changed verification of SharedBaseAddress: I added the alignment as > you suggested and moved it to a later time in VM initialization, to CDS > initialization. > > > Is the call to check_SharedBaseAddress() necessary inside > MetaspaceShared::initialize_runtime_shared_and_meta_spaces()? > SharedBaseAddress is currently ignored at run time. Does your patch change > that behavior? > > No, you are right. I'll remove the call. > >[8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the > following block can be simplified: > > > > if (!_shared_rs.is_reserved()) { > > // Get a reserved space anywhere if attaching at the > SharedBaseAddress fails: > > if (UseCompressedClassPointers) { > > // If we need a compressed class space too, let the platform handle > the reservation. > > _shared_rs = > Metaspace::reserve_address_space_for_compressed_classes(cds_total); > > } else { > > // anywhere is fine. > > _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* > large */, (char*)NULL); > > } > > } > > > > ... if you change the declaration to: > > > > static ReservedSpace > reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return > ReservedSpace();}); > > I'd like to avoid keep the method LP64 only, but I rewrote the section > somewhat to be more clearer. > > The new code looks good. > > > [9] I think the #ifdef _LP64 is not necessary: > > > > #ifdef _LP64 > > // Some sanity checks after reserving address spaces for archives > and class space. > > assert(archive_space_rs.is_reserved(), "Sanity"); > > if (Metaspace::using_class_space()) { > > // Class space must closely follow the archive space. Both spaces > must be aligned correctly. > > assert(class_space_rs.is_reserved(), "A class space should have > been reserved"); > > assert(class_space_rs.base() >= archive_space_rs.end(), "class > space should follow the cds archive space"); > > assert(is_aligned(archive_space_rs.base(), > MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); > > assert(is_aligned(class_space_rs.base(), > Metaspace::reserve_alignment()), "class space misaligned"); > > } > > #endif > > I removed the #ifdef, but replaced it with an #ifdef ASSERT. Which is also > not needed, technically, but makes it clear that this section is debugging > checks only. > > > OK. > > The rest of the code looks good to me. I am going to run your latest patch > in our CI and will report the results. > > Thanks > - Ioi > > Thanks a lot! ..Thomas > ---- > > @Coleen: > > > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/ > >virtualSpaceList.cpp.udiff.html > > > >Why did you make this change? Shouldn't the caller align it? > > > You are right, I removed the assert. > > --- > > Thanks all for your review work, > > ..Thomas > > > > > > > > > > > > > On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: > >> Hi Thomas, >> >> I am running your patch in out CI pipeline now. Some comments: >> >> [1] Do we still need to use _class_space_list? It looks like we just have >> a single range. Is _class_space_list->current_virtual_space() always the >> same VS? >> >> if (_class_space_list != NULL) { >> address base = >> (address)_class_space_list->current_virtual_space()->bottom(); >> address top = base + compressed_class_space_size(); >> st->print("Compressed class space mapped at: " PTR_FORMAT "-" >> PTR_FORMAT ", size: " SIZE_FORMAT, >> p2i(base), p2i(top), top - base); >> >> [2] Does JDK-8243535 exist with the current jdk/jdk repo? >> >> // This does currently not work because rs may be the result of a split >> operation >> // and NMT seems not to be able to handle splits. >> // See JDK-8243535. >> // MemTracker::record_virtual_memory_type((address)rs.base(), mtClass); >> >> >> [3] I think this can be put in header file. >> >> bool Metaspace::class_space_is_initialized() { >> return _class_space_list != NULL; >> } >> >> [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is the >> reason for the >> gap in the following chart: >> >> // We do this by reserving space for the ccs behind the archives. >> Note however that >> // ccs follows a different alignment (Metaspace::reserve_alignment), >> so there may >> // be a gap between ccs and cds. >> // We use a similar layout at runtime, see >> reserve_address_space_for_archives(). >> // >> // +-- SharedBaseAddress (default = >> 0x800000000) >> // v >> // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> // | Heap | Archive | | MC | RW | RO | [gap] | class >> space | >> // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> // |<-- MaxHeapSize -->| |<-- UnscaledClassSpaceMax = 4GB -->| >> >> >> _reserve_alignment is determined here: >> >> void Metaspace::ergo_initialize() { >> if (DumpSharedSpaces) { >> // Using large pages when dumping the shared archive is currently not >> implemented. >> FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >> } >> >> size_t page_size = os::vm_page_size(); >> if (UseLargePages && UseLargePagesInMetaspace) { >> page_size = os::large_page_size(); >> } >> >> _commit_alignment = page_size; >> _reserve_alignment = MAX2(page_size, >> (size_t)os::vm_allocation_granularity()); >> >> But when CDS is enabled, the RS is reserved without large pages, so it >> should be possible to incrementally commit the CCS using just >> os::vm_allocation_granularity(). >> >> [5] I see the aarch64 code in >> Metaspace::reserve_address_space_for_compressed_classes has been changed. >> Is this necessary for this RFE, or is it a separate improvement that can be >> done in a different RFE? >> >> [6] For AARCH64, should we skip the part that reserves it right above the >> heap? Or does AARCH64 always allocate the heap such that it's a preferable >> address? >> >> // case (b) >> ReservedSpace rs; >> >> // Try right above the Java heap... >> address base = align_up(CompressedOops::end(), >> Metaspace::reserve_alignment()); >> assert(base != NULL, "Sanity"); >> >> const size_t size = align_up(CompressedClassSpaceSize, >> Metaspace::reserve_alignment()); >> if (CompressedKlassPointers::is_valid_base(base)) { >> rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* >> large */, (char*)base); >> } >> >> // ...failing that, reserve anywhere, but let platform do optimized >> placement: >> if (!rs.is_reserved()) { >> rs = Metaspace::reserve_address_space_for_compressed_classes(size); >> } >> >> [7] argument.cpp checks this: >> >> if (UseSharedSpaces || DumpSharedSpaces) { >> if >> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >> log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for >> this platform, option will be ignored.", >> p2i((address)SharedBaseAddress)); >> FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >> } >> } >> >> but initialize_dumptime_shared_and_meta_spaces aligns up the >> SharedBaseAddress before doing the assert. >> >> void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >> assert(DumpSharedSpaces, "should be called for dump time only"); >> >> const size_t reserve_alignment = >> MetaspaceShared::reserved_space_alignment(); >> char* shared_base = (char*)align_up((char*)SharedBaseAddress, >> reserve_alignment); >> >> #ifdef _LP64 >> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >> "Sanity"); >> >> So theoretically shared_base may no longer be is_valid_base after the >> align_up. It probably won't happen, but I think the code will be much >> clearer tofirst to align_up, then check for is_valid_base and reset to >> default, and finally assert. >> >> [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >> following block can be simplified: >> >> if (!_shared_rs.is_reserved()) { >> // Get a reserved space anywhere if attaching at the >> SharedBaseAddress fails: >> if (UseCompressedClassPointers) { >> // If we need a compressed class space too, let the platform handle >> the reservation. >> _shared_rs = >> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >> } else { >> // anywhere is fine. >> _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >> large */, (char*)NULL); >> } >> } >> >> ... if you change the declaration to: >> >> static ReservedSpace >> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >> ReservedSpace();}); >> >> [9] I think the #ifdef _LP64 is not necessary: >> >> #ifdef _LP64 >> // Some sanity checks after reserving address spaces for archives and >> class space. >> assert(archive_space_rs.is_reserved(), "Sanity"); >> if (Metaspace::using_class_space()) { >> // Class space must closely follow the archive space. Both spaces >> must be aligned correctly. >> assert(class_space_rs.is_reserved(), "A class space should have >> been reserved"); >> assert(class_space_rs.base() >= archive_space_rs.end(), "class >> space should follow the cds archive space"); >> assert(is_aligned(archive_space_rs.base(), >> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >> assert(is_aligned(class_space_rs.base(), >> Metaspace::reserve_alignment()), "class space misaligned"); >> } >> #endif >> >> The rest of the code looks OK to me, but I may take a look at it again >> after getting more sleep :-) >> >> Thanks >> - Ioi >> >> >> >> >> On 5/7/20 7:21 AM, Thomas St?fe wrote: >> >> Hi all, >> >> please take a look at the third iteration of this change: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >> >> Changes in this version: >> >> - at the request of Coleen (sorry I did not see your post earlier) I >> removed all platform dependent files and put the platform dependent coding >> back to metaspace.cpp and compressedOops.cpp to ease the review pain. I >> used plain platform defines though (#ifdef AARCH64) instead of hiding them >> behind another macro to make things clearer. Note that I still intent to >> put this code away into the platform corners but will do so in a follow up >> RFE. >> >> - I reinstated, in a fashion, the special handling of reservations on >> Windows. On all platforms we reserve address space to map the archive files >> in with a subsequent mapping operation. However, on Windows, we cannot use >> MapViewOfFile() into an existing mapping. So I remove the mapping again >> before mapping the archives - see comment in code for details. >> >> All CI tests at SAP run through without problems, including on Win64 and >> aarch64, but I would be happy if others were to run test too. >> >> Thank you, Thomas >> >> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >> wrote: >> >>> Hi all, >>> >>> Could I have reviews for the following proposal of reworking cds/class >>> space reservation? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >>> >>> (Many thanks to Ioi Lam for so patiently explaining CDS internals to me, >>> and to Andrew Haley and Nick Gasson for help with aarch64!) >>> >>> Reservation of the compressed class space is needlessly complicated and >>> has some minor issues. It can be simplified and made clearer. >>> >>> The complexity stems from the fact that this area lives at the >>> intersection of two to three sub systems, depending on how one counts. >>> Metaspace, CDS, and the platform which may or may not its own view of how >>> to reserve class space. And this code has been growing organically over >>> time. >>> >>> One small example: >>> >>> ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t >>> alignment, >>> bool large_pages, char >>> *requested_addr, >>> bool >>> use_requested_addr) >>> >>> which I spent hours decoding, resulting in a very confused mail to >>> hs-runtime and aarch64-port-dev [2]. >>> >>> This patch attempts to simplify cds and metaspace setup a bit; to >>> comment implicit knowledge which is not immediately clear; to cleanly >>> abstract platform concerns like optimized class space placement; and to >>> disentangle cds from metaspace to solve issues which may bite us later with >>> Elastic Metaspace [4]. >>> >>> --- >>> >>> The main change is the reworked reservation mechanism. This is based on >>> Ioi's proposal [5]. >>> >>> When reserving class space, three things must happen: >>> >>> 1) reservation of the space obviously. If cds is active that space must >>> be in the vicinity of cds archives to be covered by compressed class >>> pointer encoding. >>> 2) setting up the internal Metaspace structures atop of that space >>> 3) setting up compressed class pointer encoding. >>> >>> In its current form, Metaspace may or may not do some or all of that in >>> one function >>> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>> metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, >>> it will reserve the space for Metaspace and hand it in, otherwise it will >>> create it itself. >>> >>> When discussing this in [2], Ioi proposed to move the reservation of the >>> class space completely out of Metaspace and make it a responsibility of the >>> caller always. This would reduce some complexity, and this patch follows >>> the proposal. >>> >>> I removed >>> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>> metaspace_rs, char* requested_addr, address cds_base); and all its sub >>> functions. >>> >>> (1) now has to always be done outside - a ReservedSpace for class space >>> has to be provided by the caller. However, Metaspace now offers a utility >>> function for reserving space at a "nice" location, and explicitly doing >>> nothing else: >>> >>> ReservedSpace >>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>> >>> this function can be redefined on a platform level for platform >>> optimized reservation, see below for details. >>> >>> (2) is taken care of by a new function, >>> Metaspace::initialize_class_space(ReservedSpace rs) >>> >>> (3) is taken care of a new function >>> CompressedKlassPointers::initialize(), see below for details. >>> >>> >>> So, class space now is set up three explicit steps: >>> >>> - First, reserve a suitable space by however means you want. For >>> convenience you may use >>> Metaspace::reserve_address_space_for_compressed_classes(), or you may roll >>> your own reservation. >>> - Next, tell Metaspace to use that range as backing storage for class >>> space: Metaspace::initialize_class_space(ReservedSpace rs) >>> - Finally, set up encoding. Encoding is independent from the concept of >>> a ReservedSpace, it just gets an address range, see below for details. >>> >>> Separating these steps and moving them out of the responsibility of >>> Metaspace makes this whole thing more flexible; it also removes unnecessary >>> knowledge (e.g. Metaspace does not need to know anything about either ccp >>> encoding or cds). >>> >>> --- >>> >>> How it comes together: >>> >>> If CDS is off, we just reserve a space using >>> Metaspace::reserve_address_space_for_compressed_classes(), initialize it >>> with Metaspace::initialize_class_space(ReservedSpace rs), then set up >>> compressed class pointer encoding covering the range of this class space. >>> >>> If CDS is on (dump time), we reserve large 4G space, either at >>> SharedBaseAddress or using >>> Metaspace::reserve_address_space_for_compressed_classes(); we then split >>> that into 3G archive space and 1G class space; we set up that space with >>> Metaspace as class space; then we set up compressed class pointer encoding >>> covering both archive space and cds. >>> >>> If CDS is on (run time), we reserve a large space, split it into archive >>> space (large enough to hold both archives) and class space, then basically >>> proceed as above. >>> >>> Note that this is almost exactly how things worked before (modulo some >>> minor fixes, e.g. alignment issues), only the code is reformed and made >>> more explicit. >>> >>> --- >>> >>> I moved compressed class pointer setup over to CompressedKlassPointers >>> and changed the interface: >>> >>> -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >>> metaspace_rs, address cds_base) >>> +void CompressedKlassPointers::initialize(address addr, size_t len); >>> >>> Instead of feeding it a single ReservedSpace, which is supposed to >>> represent class space, and an optional alternate base if cds is on, now we >>> give it just an numeric address range. That range marks the limits to where >>> Klass structures are to be expected, and is the implicit promise that >>> outside that range no Klass structures will exist, so encoding has to cover >>> only this range. >>> >>> This range may contain just the class space; or class space+cds; or >>> whatever allocation scheme we come up with in the future. Encoding does not >>> really care how the memory is organized as long as the input range covers >>> all possible Klass locations. That way we remove knowledge about class >>> space/cds from compressed class pointer encoding. >>> >>> Moving it away from metaspace.cpp into the CompressedKlassPointers class >>> also mirrors CompressedOops::initialize(). >>> >>> --- >>> >>> I renamed _narrow_klass_range to just _range, because strictly speaking >>> this is the range un-narrow Klass pointers can have. >>> >>> As for the implementation of CompressedKlassPointers::initialize(address >>> addr, size_t len), I mimicked very closely what happened before, so there >>> should be almost no differences. Since "almost no differences" sounds scary >>> :) here are the differences: >>> >>> - When CDS is active (dump or run time) we now always, unconditionally, >>> set the encoding range to 4G. This fixes a theoretical bug discussed on >>> aarch64-port-dev [1]. >>> >>> - When CDS is not active, we set the encoding range to the minimum >>> required length. Before, it was left at its default value of 4G. >>> >>> Both differences only affect aarch64, since they are currently the only >>> one using the range field in CompressedKlassPointers. >>> >>> I wanted to add an assert somewhere to test encoding of the very last >>> address of the CompressedKlassPointers range, again to prevent errors like >>> [3]. But I did not come up with a good place for this assert which would >>> cover also the encoding done by C1/C2. >>> >>> For the same reason I thought about introducing a mode where Klass >>> structures would be allocated in reverse order, starting at the end of the >>> ccs, but again left it out as too big a change. >>> >>> --- >>> >>> OS abstraction: platforms may have restrictions of what constitutes a >>> valid compressed class pointer encoding base. Or if not, they may have at >>> least preferences. There was logic like this in metaspace.cpp, which I >>> removed and cleanly factored out into platform dependent files, giving each >>> platform the option to add special logic. >>> >>> These are two new methods: >>> >>> - bool CompressedKlassPointers::is_valid_base(address p) >>> >>> to let the platform tell you whether it considers p to be a valid >>> encoding base. The only platform having these restrictions currently is >>> aarch64. >>> >>> - ReservedSpace >>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>> >>> this hands over the process of allocating a range suitable for >>> compressed class pointer encoding to the platform. Most platforms will >>> allocate just anywhere, but some platforms may have a better strategy (e.g. >>> trying low memory first, trying only correctly aligned addresses and so >>> on). >>> >>> Beforehand, this coding existed in a similar form in metaspace.cpp for >>> aarch64 and AIX. For now, I left the AIX part out - it seems only half >>> done, and I want to check further if we even need it, if yes why not on >>> Linux ppc, and C1 does not seem to support anything other than base+offset >>> with shift either, but I may be mistaken. >>> >>> These two methods should give the platform enough control to implement >>> their own scheme for optimized class space placement without bothering any >>> shared code about it. >>> >>> Note about the form, I introduced two new platform dependent files, >>> "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about >>> this but this seems to be what we generally do in hotspot, right? >>> >>> --- >>> >>> Metaspace reserve alignment vs cds alignment >>> >>> CDS was using Metaspace reserve alignment for CDS internal purposes. I >>> guess this was just a copy paste issue. It never caused problems since >>> Metaspace reserve alignment == page size, but that is not true anymore in >>> the upcoming Elastic Metaspace where reserve alignment will be larger. This >>> causes a number of issues. >>> >>> I separated those two cleanly. CDS now uses >>> os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in >>> those two places where it is needed, when CDS creates the address space for >>> class space on behalf of the Metaspace. >>> >>> --- >>> >>> Windows special handling in CDS >>> >>> To simplify coding I removed the windows specific handling which left >>> out reservation of the archive. This was needed because windows cannot mmap >>> files into reserved regions. But fallback code exists in filemap.cpp for >>> this case which just reads in the region instead of mapping it. >>> >>> Should that turn out to be a performance problem, I will reinstate the >>> feature. But a simpler way would be reserve the archive and later just >>> before mmapping the archive file to release the archive space. That would >>> not only be simpler but give us the best guarantee that that address space >>> is actually available. But I'd be happy to leave that part out completely >>> if we do not see any performance problems on windows x64. >>> >>> --- >>> >>> NMT cannot deal with spaces which are split. This problem manifests in >>> that bookkeeping for class space is done under "Shared Classes", not >>> "Classes" as it should. This problem exists today too at dump time and >>> randomly at run time. But since I simplified the reservation, this problem >>> now shows up always, whether or not we map at the SharedBaseAddress. >>> While I could work around this problem, I'd prefer this problem to be >>> solved at the core, and NMT to have an option to recognize reservation >>> splits. So I'd rather not put a workaround for this into the patch but >>> leave it for fixing as a separate issue. I opened this issue to track it >>> [6]. >>> >>> --- >>> >>> Jtreg tests: >>> >>> I expanded the CompressedOops/CompressedClassPointers.java. I also >>> extended them to Windows. The tests now optionally omit strict class space >>> placement tests, since these tests heavily depend on ASLR and were the >>> reason they were excluded on Windows. However I think even without checking >>> for class space placement they make sense, just to see that the VM comes up >>> and lives with the many different settings we can run in. >>> >>> --- >>> >>> Tests: >>> >>> - I ran the patch through Oracles submit repo >>> - I ran tests manually for aarch64, zero, linux 32bit and windows x64 >>> - The whole battery of nightly tests at SAP, including ppc, ppcle and >>> aarch64, unfortunately excluding windows because of unrelated errors. >>> Windows x64 tests will be redone tonight. >>> >>> >>> Thank you, >>> >>> Thomas >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >>> [2] >>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >>> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >>> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >>> [5] >>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >>> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >>> >>> >> > From aph at redhat.com Tue May 19 09:26:36 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 May 2020 10:26:36 +0100 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: Message-ID: <7362f008-ed11-eca3-4b2e-d0c38a531e1d@redhat.com> Hi, In general, please wrap comment lines at 80 characters. Some of these lines are too long to read. On 5/7/20 3:21 PM, Thomas St?fe wrote: + // Note: on AARCH64, if the code above does not find any good placement, we + // have no recurse. We return an empty space and the VM will exit. return ReservedSpace(); Spelling: "we have no recourse" + // We do this by reserving space for the ccs behind the archives. Note however that Should be "below the archives", surely? Or is that "above"? Which is it? + bool use_requested_base = true; // Whether to use SharedBaseAddress as attach point. What exactly is an "attach point" ? The phrase is used few times in comments but never defined. +// class space according to CompressedClassSpaceSize. Its start address will be aligned to etaspace::reserve_alignment "Metaspace" -- 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 ioi.lam at oracle.com Tue May 19 04:37:48 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Mon, 18 May 2020 21:37:48 -0700 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> Message-ID: <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> On 5/18/20 7:37 AM, Thomas St?fe wrote: > Hi all, > > fourth webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ > > I rebased atop of > > changeset: ? 59325:1ba9a9a3f948 > summary: ? ? 8244433: Remove saving of RSP in Assembler::pusha_uncached() > > so, atop of "8241825: Make compressed oops and compressed class > pointers independent (x86_64, PPC, S390)". > > The changes are very small this time, see notes below: > > @Ioi: > > >Hi Thomas, > > >I am running your patch in out CI pipeline now. Some comments: > > >[2] Does JDK-8243535 exist with the current jdk/jdk repo? > > I assigned JDK-8243535 to me and I'm working on a patch. But I would > like to keep that separate from this work, since this patch is already > large. And I would like to fix JDK-8243535 after this remodel patch > has been pushed, which makes some minor things easier. That would > leave a small time window where NMT does mis-track class space as > shared class space, but that is not a big issue, it does not even > disturb any test. Which in itself is something we may want to fix, > come to think about it. > > > > [3] I think this can be put in header file. > > > > bool Metaspace::class_space_is_initialized() { > > ? return _class_space_list != NULL; > > } > > Done. > > > [7] argument.cpp checks this: > > > > ? if (UseSharedSpaces || DumpSharedSpaces) { > > ? ? if > (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { > > ? ? ? log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid > for this platform, option will be ignored.", > > ? ? ? ? ? ? ? ? ? ? ? ?p2i((address)SharedBaseAddress)); > > ? ? ? FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); > > ? ? } > > ? } > > > > but initialize_dumptime_shared_and_meta_spaces aligns up the > SharedBaseAddress before doing the assert. > > > > ? void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { > > ? ? assert(DumpSharedSpaces, "should be called for dump time only"); > > > > ? ? const size_t reserve_alignment = > MetaspaceShared::reserved_space_alignment(); > > ? ? char* shared_base = (char*)align_up((char*)SharedBaseAddress, > reserve_alignment); > > > > ? #ifdef _LP64 > > assert(CompressedKlassPointers::is_valid_base((address)shared_base), > "Sanity"); > > > > So theoretically shared_base may no longer be is_valid_base after > the align_up. It probably won't happen, but I think the code will be > > much clearer tofirst to align_up, then check for is_valid_base and > reset to default, and finally assert. > > The problem with that is that at the time this coding runs os::init() > did not yet run and we do not know yet allocation granularity. > > So I changed verification of SharedBaseAddress: I added the alignment > as you suggested and moved it to a later time in VM initialization, to > CDS initialization. > Is the call to? check_SharedBaseAddress() necessary inside MetaspaceShared::initialize_runtime_shared_and_meta_spaces()? SharedBaseAddress is currently ignored at run time. Does your patch change that behavior? > >[8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, > the following block can be simplified: > > > > ?if (!_shared_rs.is_reserved()) { > > ? ?// Get a reserved space anywhere if attaching at the > SharedBaseAddress fails: > > ? ?if (UseCompressedClassPointers) { > > ? ? ?// If we need a compressed class space too, let the platform > handle the reservation. > > ? ? ?_shared_rs = > Metaspace::reserve_address_space_for_compressed_classes(cds_total); > > ? ?} else { > > ? ? ?// anywhere is fine. > > ? ? ?_shared_rs = ReservedSpace(cds_total, reserve_alignment, false > /* large */, (char*)NULL); > > ? ?} > > ?} > > > > ? ... if you change the declaration to: > > > > ?static ReservedSpace > reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ > return ReservedSpace();}); > > I'd like to avoid keep the method LP64 only, but I rewrote the section > somewhat to be more clearer. > The new code looks good. > > [9] I think the #ifdef _LP64 is not necessary: > > > > #ifdef _LP64 > > ? ? // Some sanity checks after reserving address spaces for > archives and class space. > > ? ? assert(archive_space_rs.is_reserved(), "Sanity"); > > ? ? if (Metaspace::using_class_space()) { > > ? ? ? // Class space must closely follow the archive space. Both > spaces must be aligned correctly. > > ? ? ? assert(class_space_rs.is_reserved(), "A class space should > have been reserved"); > > ? ? ? assert(class_space_rs.base() >= archive_space_rs.end(), "class > space should follow the cds archive space"); > > ? ? ? assert(is_aligned(archive_space_rs.base(), > MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); > > ? ? ? assert(is_aligned(class_space_rs.base(), > Metaspace::reserve_alignment()), "class space misaligned"); > > ? ? } > > #endif > > I removed the #ifdef, but replaced it with an #ifdef ASSERT. Which is > also not needed, technically, but makes it clear that this section is > debugging checks only. > OK. The rest of the code looks good to me. I am going to run your latest patch in our CI and will report the results. Thanks - Ioi > ---- > > @Coleen: > > >http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/>virtualSpaceList.cpp.udiff.html > > > >Why did you make this change?? Shouldn't the caller align it? > > > You are right, I removed the assert. > > --- > > Thanks all for your review work, > > ..Thomas > > > > > > > > > > > > > On Fri, May 8, 2020 at 7:37 AM Ioi Lam > wrote: > > Hi Thomas, > > I am running your patch in out CI pipeline now. Some comments: > > [1] Do we still need to use _class_space_list? It looks like we > just have a single range. Is > _class_space_list->current_virtual_space() always the same VS? > > ? if (_class_space_list != NULL) { > ??? address base = > (address)_class_space_list->current_virtual_space()->bottom(); > ??? address top = base + compressed_class_space_size(); > ??? st->print("Compressed class space mapped at: " PTR_FORMAT "-" > PTR_FORMAT ", size: " SIZE_FORMAT, > ?????????????? p2i(base), p2i(top), top - base); > > [2] Does JDK-8243535 exist with the current jdk/jdk repo? > > ? // This does currently not work because rs may be the result of > a split operation > ? // and NMT seems not to be able to handle splits. > ? // See JDK-8243535. > ? // MemTracker::record_virtual_memory_type((address)rs.base(), > mtClass); > > > [3] I think this can be put in header file. > > bool Metaspace::class_space_is_initialized() { > ? return _class_space_list != NULL; > } > > [4] Why does the CCS need to follow UseLargePagesInMetaspace? This > is the reason for the > ??? gap in the following chart: > > ??? // We do this by reserving space for the ccs behind the > archives. Note however that > ??? //? ccs follows a different alignment > (Metaspace::reserve_alignment), so there may > ??? //? be a gap between ccs and cds. > ??? // We use a similar layout at runtime, see > reserve_address_space_for_archives(). > ??? // > ??? //????????????????????????????? +-- SharedBaseAddress (default > = 0x800000000) > ??? //????????????????????????????? v > ??? // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > ??? // |??? Heap??? | Archive |???? | MC | RW | RO | [gap]? |??? > class space???? | > ??? // +-..---------+---------+ ... > +----+----+----+--------+--------------------+ > ??? // |<--?? MaxHeapSize? -->|???? |<-- UnscaledClassSpaceMax = > 4GB -->| > > > _reserve_alignment is determined here: > > void Metaspace::ergo_initialize() { > ? if (DumpSharedSpaces) { > ??? // Using large pages when dumping the shared archive is > currently not implemented. > ??? FLAG_SET_ERGO(UseLargePagesInMetaspace, false); > ? } > > ? size_t page_size = os::vm_page_size(); > ? if (UseLargePages && UseLargePagesInMetaspace) { > ??? page_size = os::large_page_size(); > ? } > > ? _commit_alignment? = page_size; > ? _reserve_alignment = MAX2(page_size, > (size_t)os::vm_allocation_granularity()); > > But when CDS is enabled, the RS is reserved without large pages, > so it should be possible to incrementally commit the CCS using > just os::vm_allocation_granularity(). > > [5] I see the aarch64 code in > Metaspace::reserve_address_space_for_compressed_classes has been > changed. Is this necessary for this RFE, or is it a separate > improvement that can be done in a different RFE? > > [6] For AARCH64, should we skip the part that reserves it right > above the heap? Or does AARCH64 always allocate the heap such that > it's a preferable address? > > ??? // case (b) > ??? ReservedSpace rs; > > ??? // Try right above the Java heap... > ??? address base = align_up(CompressedOops::end(), > Metaspace::reserve_alignment()); > ??? assert(base != NULL, "Sanity"); > > ??? const size_t size = align_up(CompressedClassSpaceSize, > Metaspace::reserve_alignment()); > ??? if (CompressedKlassPointers::is_valid_base(base)) { > ????? rs = ReservedSpace(size, Metaspace::reserve_alignment(), > false /* large */, (char*)base); > ??? } > > ??? // ...failing that, reserve anywhere, but let platform do > optimized placement: > ??? if (!rs.is_reserved()) { > ????? rs = > Metaspace::reserve_address_space_for_compressed_classes(size); > ??? } > > [7] argument.cpp checks this: > > ? if (UseSharedSpaces || DumpSharedSpaces) { > ??? if > (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) > { > ????? log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is > invalid for this platform, option will be ignored.", > ?????????????????????? p2i((address)SharedBaseAddress)); > ????? FLAG_SET_DEFAULT(SharedBaseAddress, > default_SharedBaseAddress()); > ??? } > ? } > > but initialize_dumptime_shared_and_meta_spaces aligns up the > SharedBaseAddress before doing the assert. > > ? void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { > ??? assert(DumpSharedSpaces, "should be called for dump time only"); > > ??? const size_t reserve_alignment = > MetaspaceShared::reserved_space_alignment(); > ??? char* shared_base = (char*)align_up((char*)SharedBaseAddress, > reserve_alignment); > > ? #ifdef _LP64 > assert(CompressedKlassPointers::is_valid_base((address)shared_base), > "Sanity"); > > So theoretically shared_base may no longer be is_valid_base after > the align_up. It probably won't happen, but I think the code will > be much clearer tofirst to align_up, then check for is_valid_base > and reset to default, and finally assert. > > [8] In > MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the > following block can be simplified: > > ? if (!_shared_rs.is_reserved()) { > ??? // Get a reserved space anywhere if attaching at the > SharedBaseAddress fails: > ??? if (UseCompressedClassPointers) { > ????? // If we need a compressed class space too, let the platform > handle the reservation. > ????? _shared_rs = > Metaspace::reserve_address_space_for_compressed_classes(cds_total); > ??? } else { > ????? // anywhere is fine. > ????? _shared_rs = ReservedSpace(cds_total, reserve_alignment, > false /* large */, (char*)NULL); > ??? } > ? } > > ?? ... if you change the declaration to: > > ? static ReservedSpace > reserve_address_space_for_compressed_classes(size_t size) > NOT_LP64({ return ReservedSpace();}); > > [9] I think the #ifdef _LP64 is not necessary: > > #ifdef _LP64 > ??? // Some sanity checks after reserving address spaces for > archives and class space. > ??? assert(archive_space_rs.is_reserved(), "Sanity"); > ??? if (Metaspace::using_class_space()) { > ????? // Class space must closely follow the archive space. Both > spaces must be aligned correctly. > ????? assert(class_space_rs.is_reserved(), "A class space should > have been reserved"); > ????? assert(class_space_rs.base() >= archive_space_rs.end(), > "class space should follow the cds archive space"); > ????? assert(is_aligned(archive_space_rs.base(), > MetaspaceShared::reserved_space_alignment()), "Archive space > misaligned"); > ????? assert(is_aligned(class_space_rs.base(), > Metaspace::reserve_alignment()), "class space misaligned"); > ??? } > #endif > > The rest of the code looks OK to me, but I may take a look at it > again after getting more sleep :-) > > Thanks > - Ioi > > > > > On 5/7/20 7:21 AM, Thomas St?fe wrote: >> Hi all, >> >> please take a look at the third iteration of this change: >> >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >> >> Changes in this version: >> >> - at the request of Coleen (sorry I did not see your post >> earlier) I removed all platform dependent?files and put the >> platform dependent coding back to metaspace.cpp and >> compressedOops.cpp to ease the review pain. I used plain platform >> defines though (#ifdef AARCH64) instead of hiding them behind >> another macro to make things clearer. Note that I still intent to >> put this code away into the platform corners but will do so in a >> follow up RFE. >> >> - I reinstated, in a fashion, the special handling of >> reservations on Windows. On all platforms we reserve address >> space to map the archive files in with a subsequent mapping >> operation. However, on Windows, we cannot use MapViewOfFile() >> into an existing mapping. So I remove the mapping again before >> mapping the archives - see comment in code for details. >> >> All CI tests at SAP run through without problems, including on >> Win64 and aarch64, but I would be happy if others were to run >> test too. >> >> Thank you, Thomas >> >> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >> > wrote: >> >> Hi all, >> >> Could I have reviews for the following proposal of reworking >> cds/class space reservation? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >> >> Webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >> >> (Many thanks to Ioi Lam for so patiently explaining CDS >> internals to me, and to Andrew Haley and Nick Gasson for help >> with aarch64!) >> >> Reservation of the compressed class space is needlessly >> complicated and has some minor issues. It can be simplified >> and made clearer. >> >> The complexity stems from the fact that this area lives at >> the intersection of two to three sub systems, depending on >> how one counts. Metaspace, CDS, and the platform which may or >> may not its own view of how to reserve class space. And this >> code has been growing organically over time. >> >> One small example: >> >> ReservedSpace Metaspace::reserve_preferred_space(size_t size, >> size_t alignment, >> ?bool large_pages, char *requested_addr, >> ?bool use_requested_addr) >> >> which I spent hours decoding, resulting in a very confused >> mail to hs-runtime and aarch64-port-dev [2]. >> >> This patch attempts to simplify cds and metaspace setup a >> bit; to comment implicit knowledge which is not immediately >> clear; to cleanly abstract platform concerns like optimized >> class space placement; and to disentangle cds from metaspace >> to solve issues which may bite us later with Elastic >> Metaspace [4]. >> >> --- >> >> The main change is the reworked reservation mechanism. This >> is based on Ioi's proposal [5]. >> >> When reserving class space, three things must happen: >> >> 1) reservation of the space obviously. If cds is active that >> space must be in the vicinity of cds archives to be covered >> by compressed class pointer encoding. >> 2) setting up the internal Metaspace structures atop of that >> space >> 3) setting up compressed class pointer encoding. >> >> In its current form, Metaspace may or may not do some or all >> of that in one function >> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base);) - if >> cds is active, it will reserve the space for Metaspace and >> hand it in, otherwise it will create it itself. >> >> When discussing this in [2], Ioi proposed to move the >> reservation of the class space completely out of Metaspace >> and make it a responsibility of the caller always. This would >> reduce some complexity, and this patch follows the proposal. >> >> I removed >> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >> metaspace_rs, char* requested_addr, address cds_base); and >> all its sub functions. >> >> (1) now has to always be done outside - a ReservedSpace for >> class space has to be provided by the caller. However, >> Metaspace now offers a utility function for reserving space >> at a "nice" location, and explicitly doing nothing else: >> >> ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t >> size); >> >> this function can be redefined on a platform level for >> platform optimized reservation, see below for details. >> >> (2) is taken care of by a new function, >> Metaspace::initialize_class_space(ReservedSpace rs) >> >> (3) is taken care of a new function >> CompressedKlassPointers::initialize(), see below for details. >> >> >> So, class space now is set up three explicit steps: >> >> - First, reserve a suitable space by however means you want. >> For convenience you may use >> Metaspace::reserve_address_space_for_compressed_classes(), or >> you may roll your own reservation. >> - Next, tell Metaspace to use that range as backing storage >> for class space: >> Metaspace::initialize_class_space(ReservedSpace rs) >> - Finally, set up encoding. Encoding is independent from the >> concept of a ReservedSpace, it just gets an address range, >> see below for details. >> >> Separating these steps and moving them out of the >> responsibility of Metaspace makes this whole thing more >> flexible; it also removes unnecessary knowledge (e.g. >> Metaspace does not need to know anything about either ccp >> encoding or cds). >> >> --- >> >> How it comes together: >> >> If CDS is off, we just reserve a space using >> Metaspace::reserve_address_space_for_compressed_classes(), >> initialize it with >> Metaspace::initialize_class_space(ReservedSpace rs), then set >> up compressed class pointer encoding covering the range of >> this class space. >> >> If CDS is on (dump time), we reserve large 4G space, either >> at SharedBaseAddress or using >> Metaspace::reserve_address_space_for_compressed_classes(); we >> then split that into 3G archive space and 1G class space; we >> set up that space with Metaspace as class space; then we set >> up?compressed class pointer encoding covering both archive >> space and cds. >> >> If CDS is on (run time), we reserve a large space, split it >> into archive space (large enough to hold both archives) and >> class space, then basically proceed as above. >> >> Note that this is almost exactly how things worked before >> (modulo some minor fixes, e.g. alignment issues), only the >> code is reformed and made more explicit. >> >> --- >> >> I moved compressed class pointer setup over to >> CompressedKlassPointers and changed the interface: >> >> -void >> Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >> metaspace_rs, address cds_base) >> +void CompressedKlassPointers::initialize(address addr, >> size_t len); >> >> Instead of feeding it a single ReservedSpace, which is >> supposed to represent class space, and an optional alternate >> base if cds is on, now we give it just an numeric address >> range. That range marks the limits to where Klass structures >> are to be expected, and is the implicit promise that outside >> that range no Klass structures will exist, so encoding has to >> cover only this range. >> >> This range may contain just the class space; or class >> space+cds; or whatever allocation scheme we come up with in >> the future. Encoding does not really care how the memory is >> organized as long as the input range covers all possible >> Klass locations. That way we remove knowledge about class >> space/cds from compressed class pointer encoding. >> >> Moving it away from metaspace.cpp into the >> CompressedKlassPointers class also mirrors >> CompressedOops::initialize(). >> >> --- >> >> I renamed _narrow_klass_range to just _range, because >> strictly speaking this is the range un-narrow Klass pointers >> can have. >> >> As for the implementation of >> CompressedKlassPointers::initialize(address addr, size_t >> len), I mimicked very closely what happened before, so there >> should be almost no differences. Since "almost no >> differences" sounds scary :) here are the differences: >> >> - When CDS is active (dump or run time) we now always, >> unconditionally, set the encoding range to 4G. This fixes a >> theoretical bug discussed on aarch64-port-dev [1]. >> >> - When CDS is not active, we set the encoding range to the >> minimum required length. Before, it was left at its default >> value of 4G. >> >> Both differences only affect aarch64, since they are >> currently the only one using the range field in >> CompressedKlassPointers. >> >> I wanted to add an assert somewhere to test encoding of the >> very last address of the CompressedKlassPointers range, again >> to prevent errors like [3]. But I did not come up with a good >> place for this assert which would cover also the encoding >> done by C1/C2. >> >> For the same reason I thought about introducing a mode where >> Klass structures would be allocated in reverse order, >> starting at the end of the ccs, but again left it out as too >> big a change. >> >> --- >> >> OS abstraction: platforms may have restrictions of what >> constitutes a valid compressed class pointer encoding base. >> Or if not, they may have at least preferences. There was >> logic like this in metaspace.cpp, which I removed and cleanly >> factored out into platform dependent files, giving each >> platform the option to add special logic. >> >> These are two new methods: >> >> - bool CompressedKlassPointers::is_valid_base(address p) >> >> to let the platform tell you whether it considers p to be a >> valid encoding base. The only platform having these >> restrictions currently is aarch64. >> >> - ReservedSpace >> Metaspace::reserve_address_space_for_compressed_classes(size_t >> size); >> >> this hands over the process of allocating a range suitable >> for compressed class pointer encoding to the platform. Most >> platforms will allocate just anywhere, but some platforms may >> have a better strategy (e.g. trying low memory first, trying >> only correctly aligned addresses and so on). >> >> Beforehand, this coding existed in a similar form in >> metaspace.cpp for aarch64 and AIX. For now, I left the AIX >> part out - it seems only half done, and I want to check >> further if we even need it, if yes why not on Linux ppc, and >> C1 does not seem to support anything other than base+offset >> with shift either, but I may be mistaken. >> >> These two methods should give the platform enough control to >> implement their own scheme for optimized class space >> placement without bothering any shared code about it. >> >> Note about the form, I introduced two new platform dependent >> files, "metaspace_.cpp" and "compressedOops_.cpp". >> I am not happy about this but this seems to be what we >> generally do in hotspot, right? >> >> --- >> >> Metaspace reserve alignment vs cds alignment >> >> CDS was using Metaspace reserve alignment for CDS internal >> purposes. I guess this was just a copy paste issue. It never >> caused problems since Metaspace reserve alignment == page >> size, but that is not true anymore in the upcoming Elastic >> Metaspace where reserve alignment will be larger. This causes >> a number of issues. >> >> I separated those two cleanly. CDS now uses >> os::vm_allocation_granularity. Metaspace::reserve_alignment >> is only used in those two places where it is needed, when CDS >> creates the address space for class space on behalf of the >> Metaspace. >> >> --- >> >> Windows special handling in CDS >> >> To simplify coding I removed the windows specific handling >> which left out reservation of the archive. This was needed >> because windows cannot mmap files into reserved regions. But >> fallback code exists in filemap.cpp for this case which just >> reads in the region instead of mapping?it. >> >> Should that turn out to be a performance problem, I will >> reinstate the feature. But a simpler way would be reserve the >> archive and later just before mmapping?the archive file to >> release the archive space. That would not only be simpler but >> give us the best guarantee that that address space is >> actually available. But I'd be happy to leave that part out >> completely if we do not see any performance problems on >> windows x64. >> >> --- >> >> NMT cannot deal with spaces which are split. This problem >> manifests in that bookkeeping for class space is done under >> "Shared Classes", not "Classes" as it should. This problem >> exists today too at dump?time and randomly at run time. But >> since I simplified the reservation, this problem now shows up >> always, whether or not we map at the SharedBaseAddress. >> While I could work around this problem, I'd prefer this >> problem to be solved at the core, and NMT to have an option >> to recognize reservation splits. So I'd rather not put a >> workaround for this into the patch but leave it for fixing as >> a separate issue. I opened this issue to track it [6]. >> >> --- >> >> Jtreg tests: >> >> I expanded the CompressedOops/CompressedClassPointers.java. I >> also extended them to Windows. The tests now optionally omit >> strict class space placement tests, since these tests heavily >> depend on ASLR and were the reason they were excluded on >> Windows. However I think even without checking for class >> space placement they make sense, just to see that the VM >> comes up and lives with the many different settings we can >> run in. >> >> --- >> >> Tests: >> >> - I ran the patch through Oracles submit repo >> - I ran tests manually for aarch64, zero, linux 32bit and >> windows x64 >> - The whole battery of nightly tests at SAP, including ppc, >> ppcle and aarch64, unfortunately excluding windows because of >> unrelated errors. Windows x64 tests will be redone tonight. >> >> >> Thank you, >> >> Thomas >> >> [1] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >> [2] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >> [5] >> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >> > From adinn at redhat.com Tue May 19 09:42:06 2020 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 19 May 2020 10:42:06 +0100 Subject: [aarch64-port-dev ] RFR(XXS):8244170: correct instruction typo for dcps1/2/3 In-Reply-To: <47B6CB94-62D9-4E66-A9C1-0055A43FFA24@amazon.com> References: <3F8C4202-6810-4CC6-BB77-656A6D71E9D3@amazon.com> <47B6CB94-62D9-4E66-A9C1-0055A43FFA24@amazon.com> Message-ID: On 18/05/2020 22:43, Liu, Xin wrote: > Hi, Andrew and Rahul, > > Thank you to review it. Here is the new revision, which can apply to TIP. > It's almost same, I just resolve a merge conflict with JDK-8022574. > http://cr.openjdk.java.net/~xliu/8244170/01/webrev/ > > I ran test on "hotspot:tier1" on aarch64. Still reviewed! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From thomas.stuefe at gmail.com Tue May 19 10:06:25 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 May 2020 12:06:25 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: <7362f008-ed11-eca3-4b2e-d0c38a531e1d@redhat.com> References: <7362f008-ed11-eca3-4b2e-d0c38a531e1d@redhat.com> Message-ID: On Tue, May 19, 2020 at 11:26 AM Andrew Haley wrote: > Hi, > > In general, please wrap comment lines at 80 characters. Some of these lines > are too long to read. > okay. > > On 5/7/20 3:21 PM, Thomas St?fe wrote: > > > + // Note: on AARCH64, if the code above does not find any good > placement, we > + // have no recurse. We return an empty space and the VM will exit. > return ReservedSpace(); > > Spelling: "we have no recourse" > > Will fix. > + // We do this by reserving space for the ccs behind the archives. > Note however that > > Should be "below the archives", surely? Or is that "above"? Which is it? > Above. Will fix. > > + bool use_requested_base = true; // Whether to use SharedBaseAddress as > attach point. > > What exactly is an "attach point" ? The phrase is used few times in > comments but never defined. > > Attach address. I'll clarify the comments. > +// class space according to CompressedClassSpaceSize. Its start > address will be aligned to etaspace::reserve_alignment > > "Metaspace" > > Thanks for looking this over Andrew. I'll wait for Coleens feedback and will post an update. ..Thomas > -- > 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 Tue May 19 10:45:40 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Tue, 19 May 2020 18:45:40 +0800 Subject: [aarch64-port-dev ] AArch64: Neoverse N1 atomic operations and -moutline-atomics In-Reply-To: <280d2657-7997-1dac-f370-8ff41a0b3035@redhat.com> References: <3a5e43e7-2039-8574-7470-5827267fb88d@redhat.com> <854ksd3egu.fsf@arm.com> <280d2657-7997-1dac-f370-8ff41a0b3035@redhat.com> Message-ID: On 05/18/20 17:53 PM, Andrew Haley wrote: > >> Question is whether it's best to enable this by default in OpenJDK or >> leave it to downstream distributions to decide? > > I don't really understand why there is a conditional branch there. > They could just do the test at startup and patch the code. Maybe it'd > hurt DSO startup time or something? Maybe they don't like the idea of > temporarily enabling exec privilege on a page of writable data. I asked internally and it's basically the reasons you mention above, plus patching could cause excessive copy-on-writes of the code pages. The other way to do it is to build one libjvm.so without LSE support and then a separate atomics/libjvm.so with -march set to enable the LSE instructions. Then ld.so will load the appropriate library based on the hwcaps. This should give the best performance but the build time and package size balloons. -- Nick From coleen.phillimore at oracle.com Tue May 19 10:50:21 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 May 2020 06:50:21 -0400 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <7362f008-ed11-eca3-4b2e-d0c38a531e1d@redhat.com> Message-ID: Hi, I have no more comments.? It all looks good to me.? I think we're waiting for Ioi to run through CI and he might have a comment on the check_SharedBaseAddress change which seems reasonable to me. I like that it's not in arguments.cpp.? Too much dispersion of knowledge to arguments.cpp. http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/src/hotspot/share/runtime/arguments.cpp.udiff.html You may not need this change anymore. Thanks, Coleen On 5/19/20 6:06 AM, Thomas St?fe wrote: > > > On Tue, May 19, 2020 at 11:26 AM Andrew Haley > wrote: > > Hi, > > In general, please wrap comment lines at 80 characters. Some of > these lines > are too long to read. > > > okay. > > > On 5/7/20 3:21 PM, Thomas St?fe wrote: > > > +? // Note: on AARCH64, if the code above does not find any good > placement, we > +? // have no recurse. We return an empty space and the VM will exit. > ? ?return ReservedSpace(); > > Spelling: "we have no recourse" > > > Will fix. > > +? ? // We do this by reserving space for the ccs behind the > archives. Note however that > > Should be "below the archives", surely? Or is that "above"? Which > is it? > > > Above. Will fix. > > > +? bool use_requested_base = true; // Whether to use > SharedBaseAddress as attach point. > > What exactly is an "attach point" ? The phrase is used few times in > comments but never defined. > > > Attach address. I'll clarify the comments. > > +//? ? ? class space according to CompressedClassSpaceSize. Its > start address will be aligned to etaspace::reserve_alignment > > "Metaspace" > > > Thanks for looking this over Andrew. I'll wait for Coleens feedback > and will post an update. > > ..Thomas > > -- > 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 Yang.Zhang at arm.com Tue May 19 10:55:09 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Tue, 19 May 2020 10:55:09 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes Message-ID: Hi, Following up on review requests of API [0], Java implementation and test [1], General Hotspot changes[2] for Vector API and x86 backend changes [3]. Here's a request for review of AArch64 backend changes required for supporting the Vector API: JEP: https://openjdk.java.net/jeps/338 JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.01/ Complete implementation resides in vector-unstable branch of panama/dev repository [4]. Looking forward to your feedback. Best Regards, Yang [0] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html [1] https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-April/065587.html [2] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037798.html [3] https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-April/037801.html [4] https://openjdk.java.net/projects/panama/ $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable From coleen.phillimore at oracle.com Tue May 19 11:00:46 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Tue, 19 May 2020 07:00:46 -0400 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <7362f008-ed11-eca3-4b2e-d0c38a531e1d@redhat.com> Message-ID: <51605673-b784-e4aa-0ac8-08b99f19e6f4@oracle.com> Hi, I have no more comments.? It all looks good to me.? I think we're waiting for Ioi to run through CI and he might have a comment on the check_SharedBaseAddress change which seems reasonable to me. I like that it's not in arguments.cpp.? Too much dispersion of knowledge to arguments.cpp. http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/src/hotspot/share/runtime/arguments.cpp.udiff.html You may not need this change anymore. Thanks, Coleen On 5/19/20 6:06 AM, Thomas St?fe wrote: > > > On Tue, May 19, 2020 at 11:26 AM Andrew Haley > wrote: > > Hi, > > In general, please wrap comment lines at 80 characters. Some of > these lines > are too long to read. > > > okay. > > > On 5/7/20 3:21 PM, Thomas St?fe wrote: > > > +? // Note: on AARCH64, if the code above does not find any good > placement, we > +? // have no recurse. We return an empty space and the VM will exit. > ? ?return ReservedSpace(); > > Spelling: "we have no recourse" > > > Will fix. > > +? ? // We do this by reserving space for the ccs behind the > archives. Note however that > > Should be "below the archives", surely? Or is that "above"? Which > is it? > > > Above. Will fix. > > > +? bool use_requested_base = true; // Whether to use > SharedBaseAddress as attach point. > > What exactly is an "attach point" ? The phrase is used few times in > comments but never defined. > > > Attach address. I'll clarify the comments. > > +//? ? ? class space according to CompressedClassSpaceSize. Its > start address will be aligned to etaspace::reserve_alignment > > "Metaspace" > > > Thanks for looking this over Andrew. I'll wait for Coleens feedback > and will post an update. > > ..Thomas > > -- > 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 May 19 14:27:48 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 19 May 2020 15:27:48 +0100 Subject: [aarch64-port-dev ] AArch64: Neoverse N1 atomic operations and -moutline-atomics In-Reply-To: References: <3a5e43e7-2039-8574-7470-5827267fb88d@redhat.com> <854ksd3egu.fsf@arm.com> <280d2657-7997-1dac-f370-8ff41a0b3035@redhat.com> Message-ID: <760f4899-1235-2699-ca45-58a68e2dcc0a@redhat.com> On 5/19/20 11:45 AM, Nick Gasson wrote: > On 05/18/20 17:53 PM, Andrew Haley wrote: >> >>> Question is whether it's best to enable this by default in OpenJDK or >>> leave it to downstream distributions to decide? >> >> I don't really understand why there is a conditional branch there. >> They could just do the test at startup and patch the code. Maybe it'd >> hurt DSO startup time or something? Maybe they don't like the idea of >> temporarily enabling exec privilege on a page of writable data. > > I asked internally and it's basically the reasons you mention above, > plus patching could cause excessive copy-on-writes of the code pages. > > The other way to do it is to build one libjvm.so without LSE support and > then a separate atomics/libjvm.so with -march set to enable the LSE > instructions. Then ld.so will load the appropriate library based on the > hwcaps. This should give the best performance but the build time and > package size balloons. Hmm, no. :-) I think we'd better leave it as it is. I've done a few experiments with the Neoverse N1 and it's all rather murky: it's not clear to me that LSE atomics are an overall win in the Java context. We don't make heavy use of pthread mutexes except when we've decided to block, in which case the execution time is completely dominated by the cost of a system call. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Tue May 19 14:40:06 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 19 May 2020 16:40:06 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> Message-ID: Hi guys, new webrev: full: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ delta: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ Mostly format changes, breaking up at column 80 as Andrew requested. The only changes which matter is the removal of the unnecessary include in arguments.cpp as Coleen suggested; and to not validate SharedBaseAddress anymore at runtime, as Ioi requested. Also rebased to head. Thanks, Thomas On Tue, May 19, 2020 at 6:38 AM Ioi Lam wrote: > > > On 5/18/20 7:37 AM, Thomas St?fe wrote: > > Hi all, > > fourth webrev: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ > > I rebased atop of > > changeset: 59325:1ba9a9a3f948 > summary: 8244433: Remove saving of RSP in Assembler::pusha_uncached() > > so, atop of "8241825: Make compressed oops and compressed class pointers > independent (x86_64, PPC, S390)". > > The changes are very small this time, see notes below: > > @Ioi: > > >Hi Thomas, > > >I am running your patch in out CI pipeline now. Some comments: > > >[2] Does JDK-8243535 exist with the current jdk/jdk repo? > > I assigned JDK-8243535 to me and I'm working on a patch. But I would like > to keep that separate from this work, since this patch is already large. > And I would like to fix JDK-8243535 after this remodel patch has been > pushed, which makes some minor things easier. That would leave a small time > window where NMT does mis-track class space as shared class space, but that > is not a big issue, it does not even disturb any test. Which in itself is > something we may want to fix, come to think about it. > > > > [3] I think this can be put in header file. > > > > bool Metaspace::class_space_is_initialized() { > > return _class_space_list != NULL; > > } > > Done. > > > [7] argument.cpp checks this: > > > > if (UseSharedSpaces || DumpSharedSpaces) { > > if > (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { > > log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for > this platform, option will be ignored.", > > p2i((address)SharedBaseAddress)); > > FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); > > } > > } > > > > but initialize_dumptime_shared_and_meta_spaces aligns up the > SharedBaseAddress before doing the assert. > > > > void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { > > assert(DumpSharedSpaces, "should be called for dump time only"); > > > > const size_t reserve_alignment = > MetaspaceShared::reserved_space_alignment(); > > char* shared_base = (char*)align_up((char*)SharedBaseAddress, > reserve_alignment); > > > > #ifdef _LP64 > > assert(CompressedKlassPointers::is_valid_base((address)shared_base), > "Sanity"); > > > > So theoretically shared_base may no longer be is_valid_base after the > align_up. It probably won't happen, but I think the code will be > much > clearer tofirst to align_up, then check for is_valid_base and reset to > default, and finally assert. > > The problem with that is that at the time this coding runs os::init() did > not yet run and we do not know yet allocation granularity. > > So I changed verification of SharedBaseAddress: I added the alignment as > you suggested and moved it to a later time in VM initialization, to CDS > initialization. > > > Is the call to check_SharedBaseAddress() necessary inside > MetaspaceShared::initialize_runtime_shared_and_meta_spaces()? > SharedBaseAddress is currently ignored at run time. Does your patch change > that behavior? > > >[8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the > following block can be simplified: > > > > if (!_shared_rs.is_reserved()) { > > // Get a reserved space anywhere if attaching at the > SharedBaseAddress fails: > > if (UseCompressedClassPointers) { > > // If we need a compressed class space too, let the platform handle > the reservation. > > _shared_rs = > Metaspace::reserve_address_space_for_compressed_classes(cds_total); > > } else { > > // anywhere is fine. > > _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* > large */, (char*)NULL); > > } > > } > > > > ... if you change the declaration to: > > > > static ReservedSpace > reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return > ReservedSpace();}); > > I'd like to avoid keep the method LP64 only, but I rewrote the section > somewhat to be more clearer. > > The new code looks good. > > > [9] I think the #ifdef _LP64 is not necessary: > > > > #ifdef _LP64 > > // Some sanity checks after reserving address spaces for archives > and class space. > > assert(archive_space_rs.is_reserved(), "Sanity"); > > if (Metaspace::using_class_space()) { > > // Class space must closely follow the archive space. Both spaces > must be aligned correctly. > > assert(class_space_rs.is_reserved(), "A class space should have > been reserved"); > > assert(class_space_rs.base() >= archive_space_rs.end(), "class > space should follow the cds archive space"); > > assert(is_aligned(archive_space_rs.base(), > MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); > > assert(is_aligned(class_space_rs.base(), > Metaspace::reserve_alignment()), "class space misaligned"); > > } > > #endif > > I removed the #ifdef, but replaced it with an #ifdef ASSERT. Which is also > not needed, technically, but makes it clear that this section is debugging > checks only. > > > OK. > > The rest of the code looks good to me. I am going to run your latest patch > in our CI and will report the results. > > Thanks > - Ioi > > ---- > > @Coleen: > > > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/ > >virtualSpaceList.cpp.udiff.html > > > >Why did you make this change? Shouldn't the caller align it? > > > You are right, I removed the assert. > > --- > > Thanks all for your review work, > > ..Thomas > > > > > > > > > > > > > On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: > >> Hi Thomas, >> >> I am running your patch in out CI pipeline now. Some comments: >> >> [1] Do we still need to use _class_space_list? It looks like we just have >> a single range. Is _class_space_list->current_virtual_space() always the >> same VS? >> >> if (_class_space_list != NULL) { >> address base = >> (address)_class_space_list->current_virtual_space()->bottom(); >> address top = base + compressed_class_space_size(); >> st->print("Compressed class space mapped at: " PTR_FORMAT "-" >> PTR_FORMAT ", size: " SIZE_FORMAT, >> p2i(base), p2i(top), top - base); >> >> [2] Does JDK-8243535 exist with the current jdk/jdk repo? >> >> // This does currently not work because rs may be the result of a split >> operation >> // and NMT seems not to be able to handle splits. >> // See JDK-8243535. >> // MemTracker::record_virtual_memory_type((address)rs.base(), mtClass); >> >> >> [3] I think this can be put in header file. >> >> bool Metaspace::class_space_is_initialized() { >> return _class_space_list != NULL; >> } >> >> [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is the >> reason for the >> gap in the following chart: >> >> // We do this by reserving space for the ccs behind the archives. >> Note however that >> // ccs follows a different alignment (Metaspace::reserve_alignment), >> so there may >> // be a gap between ccs and cds. >> // We use a similar layout at runtime, see >> reserve_address_space_for_archives(). >> // >> // +-- SharedBaseAddress (default = >> 0x800000000) >> // v >> // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> // | Heap | Archive | | MC | RW | RO | [gap] | class >> space | >> // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> // |<-- MaxHeapSize -->| |<-- UnscaledClassSpaceMax = 4GB -->| >> >> >> _reserve_alignment is determined here: >> >> void Metaspace::ergo_initialize() { >> if (DumpSharedSpaces) { >> // Using large pages when dumping the shared archive is currently not >> implemented. >> FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >> } >> >> size_t page_size = os::vm_page_size(); >> if (UseLargePages && UseLargePagesInMetaspace) { >> page_size = os::large_page_size(); >> } >> >> _commit_alignment = page_size; >> _reserve_alignment = MAX2(page_size, >> (size_t)os::vm_allocation_granularity()); >> >> But when CDS is enabled, the RS is reserved without large pages, so it >> should be possible to incrementally commit the CCS using just >> os::vm_allocation_granularity(). >> >> [5] I see the aarch64 code in >> Metaspace::reserve_address_space_for_compressed_classes has been changed. >> Is this necessary for this RFE, or is it a separate improvement that can be >> done in a different RFE? >> >> [6] For AARCH64, should we skip the part that reserves it right above the >> heap? Or does AARCH64 always allocate the heap such that it's a preferable >> address? >> >> // case (b) >> ReservedSpace rs; >> >> // Try right above the Java heap... >> address base = align_up(CompressedOops::end(), >> Metaspace::reserve_alignment()); >> assert(base != NULL, "Sanity"); >> >> const size_t size = align_up(CompressedClassSpaceSize, >> Metaspace::reserve_alignment()); >> if (CompressedKlassPointers::is_valid_base(base)) { >> rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* >> large */, (char*)base); >> } >> >> // ...failing that, reserve anywhere, but let platform do optimized >> placement: >> if (!rs.is_reserved()) { >> rs = Metaspace::reserve_address_space_for_compressed_classes(size); >> } >> >> [7] argument.cpp checks this: >> >> if (UseSharedSpaces || DumpSharedSpaces) { >> if >> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >> log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for >> this platform, option will be ignored.", >> p2i((address)SharedBaseAddress)); >> FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >> } >> } >> >> but initialize_dumptime_shared_and_meta_spaces aligns up the >> SharedBaseAddress before doing the assert. >> >> void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >> assert(DumpSharedSpaces, "should be called for dump time only"); >> >> const size_t reserve_alignment = >> MetaspaceShared::reserved_space_alignment(); >> char* shared_base = (char*)align_up((char*)SharedBaseAddress, >> reserve_alignment); >> >> #ifdef _LP64 >> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >> "Sanity"); >> >> So theoretically shared_base may no longer be is_valid_base after the >> align_up. It probably won't happen, but I think the code will be much >> clearer tofirst to align_up, then check for is_valid_base and reset to >> default, and finally assert. >> >> [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >> following block can be simplified: >> >> if (!_shared_rs.is_reserved()) { >> // Get a reserved space anywhere if attaching at the >> SharedBaseAddress fails: >> if (UseCompressedClassPointers) { >> // If we need a compressed class space too, let the platform handle >> the reservation. >> _shared_rs = >> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >> } else { >> // anywhere is fine. >> _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >> large */, (char*)NULL); >> } >> } >> >> ... if you change the declaration to: >> >> static ReservedSpace >> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >> ReservedSpace();}); >> >> [9] I think the #ifdef _LP64 is not necessary: >> >> #ifdef _LP64 >> // Some sanity checks after reserving address spaces for archives and >> class space. >> assert(archive_space_rs.is_reserved(), "Sanity"); >> if (Metaspace::using_class_space()) { >> // Class space must closely follow the archive space. Both spaces >> must be aligned correctly. >> assert(class_space_rs.is_reserved(), "A class space should have >> been reserved"); >> assert(class_space_rs.base() >= archive_space_rs.end(), "class >> space should follow the cds archive space"); >> assert(is_aligned(archive_space_rs.base(), >> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >> assert(is_aligned(class_space_rs.base(), >> Metaspace::reserve_alignment()), "class space misaligned"); >> } >> #endif >> >> The rest of the code looks OK to me, but I may take a look at it again >> after getting more sleep :-) >> >> Thanks >> - Ioi >> >> >> >> >> On 5/7/20 7:21 AM, Thomas St?fe wrote: >> >> Hi all, >> >> please take a look at the third iteration of this change: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >> >> Changes in this version: >> >> - at the request of Coleen (sorry I did not see your post earlier) I >> removed all platform dependent files and put the platform dependent coding >> back to metaspace.cpp and compressedOops.cpp to ease the review pain. I >> used plain platform defines though (#ifdef AARCH64) instead of hiding them >> behind another macro to make things clearer. Note that I still intent to >> put this code away into the platform corners but will do so in a follow up >> RFE. >> >> - I reinstated, in a fashion, the special handling of reservations on >> Windows. On all platforms we reserve address space to map the archive files >> in with a subsequent mapping operation. However, on Windows, we cannot use >> MapViewOfFile() into an existing mapping. So I remove the mapping again >> before mapping the archives - see comment in code for details. >> >> All CI tests at SAP run through without problems, including on Win64 and >> aarch64, but I would be happy if others were to run test too. >> >> Thank you, Thomas >> >> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >> wrote: >> >>> Hi all, >>> >>> Could I have reviews for the following proposal of reworking cds/class >>> space reservation? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >>> >>> (Many thanks to Ioi Lam for so patiently explaining CDS internals to me, >>> and to Andrew Haley and Nick Gasson for help with aarch64!) >>> >>> Reservation of the compressed class space is needlessly complicated and >>> has some minor issues. It can be simplified and made clearer. >>> >>> The complexity stems from the fact that this area lives at the >>> intersection of two to three sub systems, depending on how one counts. >>> Metaspace, CDS, and the platform which may or may not its own view of how >>> to reserve class space. And this code has been growing organically over >>> time. >>> >>> One small example: >>> >>> ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t >>> alignment, >>> bool large_pages, char >>> *requested_addr, >>> bool >>> use_requested_addr) >>> >>> which I spent hours decoding, resulting in a very confused mail to >>> hs-runtime and aarch64-port-dev [2]. >>> >>> This patch attempts to simplify cds and metaspace setup a bit; to >>> comment implicit knowledge which is not immediately clear; to cleanly >>> abstract platform concerns like optimized class space placement; and to >>> disentangle cds from metaspace to solve issues which may bite us later with >>> Elastic Metaspace [4]. >>> >>> --- >>> >>> The main change is the reworked reservation mechanism. This is based on >>> Ioi's proposal [5]. >>> >>> When reserving class space, three things must happen: >>> >>> 1) reservation of the space obviously. If cds is active that space must >>> be in the vicinity of cds archives to be covered by compressed class >>> pointer encoding. >>> 2) setting up the internal Metaspace structures atop of that space >>> 3) setting up compressed class pointer encoding. >>> >>> In its current form, Metaspace may or may not do some or all of that in >>> one function >>> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>> metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, >>> it will reserve the space for Metaspace and hand it in, otherwise it will >>> create it itself. >>> >>> When discussing this in [2], Ioi proposed to move the reservation of the >>> class space completely out of Metaspace and make it a responsibility of the >>> caller always. This would reduce some complexity, and this patch follows >>> the proposal. >>> >>> I removed >>> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>> metaspace_rs, char* requested_addr, address cds_base); and all its sub >>> functions. >>> >>> (1) now has to always be done outside - a ReservedSpace for class space >>> has to be provided by the caller. However, Metaspace now offers a utility >>> function for reserving space at a "nice" location, and explicitly doing >>> nothing else: >>> >>> ReservedSpace >>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>> >>> this function can be redefined on a platform level for platform >>> optimized reservation, see below for details. >>> >>> (2) is taken care of by a new function, >>> Metaspace::initialize_class_space(ReservedSpace rs) >>> >>> (3) is taken care of a new function >>> CompressedKlassPointers::initialize(), see below for details. >>> >>> >>> So, class space now is set up three explicit steps: >>> >>> - First, reserve a suitable space by however means you want. For >>> convenience you may use >>> Metaspace::reserve_address_space_for_compressed_classes(), or you may roll >>> your own reservation. >>> - Next, tell Metaspace to use that range as backing storage for class >>> space: Metaspace::initialize_class_space(ReservedSpace rs) >>> - Finally, set up encoding. Encoding is independent from the concept of >>> a ReservedSpace, it just gets an address range, see below for details. >>> >>> Separating these steps and moving them out of the responsibility of >>> Metaspace makes this whole thing more flexible; it also removes unnecessary >>> knowledge (e.g. Metaspace does not need to know anything about either ccp >>> encoding or cds). >>> >>> --- >>> >>> How it comes together: >>> >>> If CDS is off, we just reserve a space using >>> Metaspace::reserve_address_space_for_compressed_classes(), initialize it >>> with Metaspace::initialize_class_space(ReservedSpace rs), then set up >>> compressed class pointer encoding covering the range of this class space. >>> >>> If CDS is on (dump time), we reserve large 4G space, either at >>> SharedBaseAddress or using >>> Metaspace::reserve_address_space_for_compressed_classes(); we then split >>> that into 3G archive space and 1G class space; we set up that space with >>> Metaspace as class space; then we set up compressed class pointer encoding >>> covering both archive space and cds. >>> >>> If CDS is on (run time), we reserve a large space, split it into archive >>> space (large enough to hold both archives) and class space, then basically >>> proceed as above. >>> >>> Note that this is almost exactly how things worked before (modulo some >>> minor fixes, e.g. alignment issues), only the code is reformed and made >>> more explicit. >>> >>> --- >>> >>> I moved compressed class pointer setup over to CompressedKlassPointers >>> and changed the interface: >>> >>> -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >>> metaspace_rs, address cds_base) >>> +void CompressedKlassPointers::initialize(address addr, size_t len); >>> >>> Instead of feeding it a single ReservedSpace, which is supposed to >>> represent class space, and an optional alternate base if cds is on, now we >>> give it just an numeric address range. That range marks the limits to where >>> Klass structures are to be expected, and is the implicit promise that >>> outside that range no Klass structures will exist, so encoding has to cover >>> only this range. >>> >>> This range may contain just the class space; or class space+cds; or >>> whatever allocation scheme we come up with in the future. Encoding does not >>> really care how the memory is organized as long as the input range covers >>> all possible Klass locations. That way we remove knowledge about class >>> space/cds from compressed class pointer encoding. >>> >>> Moving it away from metaspace.cpp into the CompressedKlassPointers class >>> also mirrors CompressedOops::initialize(). >>> >>> --- >>> >>> I renamed _narrow_klass_range to just _range, because strictly speaking >>> this is the range un-narrow Klass pointers can have. >>> >>> As for the implementation of CompressedKlassPointers::initialize(address >>> addr, size_t len), I mimicked very closely what happened before, so there >>> should be almost no differences. Since "almost no differences" sounds scary >>> :) here are the differences: >>> >>> - When CDS is active (dump or run time) we now always, unconditionally, >>> set the encoding range to 4G. This fixes a theoretical bug discussed on >>> aarch64-port-dev [1]. >>> >>> - When CDS is not active, we set the encoding range to the minimum >>> required length. Before, it was left at its default value of 4G. >>> >>> Both differences only affect aarch64, since they are currently the only >>> one using the range field in CompressedKlassPointers. >>> >>> I wanted to add an assert somewhere to test encoding of the very last >>> address of the CompressedKlassPointers range, again to prevent errors like >>> [3]. But I did not come up with a good place for this assert which would >>> cover also the encoding done by C1/C2. >>> >>> For the same reason I thought about introducing a mode where Klass >>> structures would be allocated in reverse order, starting at the end of the >>> ccs, but again left it out as too big a change. >>> >>> --- >>> >>> OS abstraction: platforms may have restrictions of what constitutes a >>> valid compressed class pointer encoding base. Or if not, they may have at >>> least preferences. There was logic like this in metaspace.cpp, which I >>> removed and cleanly factored out into platform dependent files, giving each >>> platform the option to add special logic. >>> >>> These are two new methods: >>> >>> - bool CompressedKlassPointers::is_valid_base(address p) >>> >>> to let the platform tell you whether it considers p to be a valid >>> encoding base. The only platform having these restrictions currently is >>> aarch64. >>> >>> - ReservedSpace >>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>> >>> this hands over the process of allocating a range suitable for >>> compressed class pointer encoding to the platform. Most platforms will >>> allocate just anywhere, but some platforms may have a better strategy (e.g. >>> trying low memory first, trying only correctly aligned addresses and so >>> on). >>> >>> Beforehand, this coding existed in a similar form in metaspace.cpp for >>> aarch64 and AIX. For now, I left the AIX part out - it seems only half >>> done, and I want to check further if we even need it, if yes why not on >>> Linux ppc, and C1 does not seem to support anything other than base+offset >>> with shift either, but I may be mistaken. >>> >>> These two methods should give the platform enough control to implement >>> their own scheme for optimized class space placement without bothering any >>> shared code about it. >>> >>> Note about the form, I introduced two new platform dependent files, >>> "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about >>> this but this seems to be what we generally do in hotspot, right? >>> >>> --- >>> >>> Metaspace reserve alignment vs cds alignment >>> >>> CDS was using Metaspace reserve alignment for CDS internal purposes. I >>> guess this was just a copy paste issue. It never caused problems since >>> Metaspace reserve alignment == page size, but that is not true anymore in >>> the upcoming Elastic Metaspace where reserve alignment will be larger. This >>> causes a number of issues. >>> >>> I separated those two cleanly. CDS now uses >>> os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in >>> those two places where it is needed, when CDS creates the address space for >>> class space on behalf of the Metaspace. >>> >>> --- >>> >>> Windows special handling in CDS >>> >>> To simplify coding I removed the windows specific handling which left >>> out reservation of the archive. This was needed because windows cannot mmap >>> files into reserved regions. But fallback code exists in filemap.cpp for >>> this case which just reads in the region instead of mapping it. >>> >>> Should that turn out to be a performance problem, I will reinstate the >>> feature. But a simpler way would be reserve the archive and later just >>> before mmapping the archive file to release the archive space. That would >>> not only be simpler but give us the best guarantee that that address space >>> is actually available. But I'd be happy to leave that part out completely >>> if we do not see any performance problems on windows x64. >>> >>> --- >>> >>> NMT cannot deal with spaces which are split. This problem manifests in >>> that bookkeeping for class space is done under "Shared Classes", not >>> "Classes" as it should. This problem exists today too at dump time and >>> randomly at run time. But since I simplified the reservation, this problem >>> now shows up always, whether or not we map at the SharedBaseAddress. >>> While I could work around this problem, I'd prefer this problem to be >>> solved at the core, and NMT to have an option to recognize reservation >>> splits. So I'd rather not put a workaround for this into the patch but >>> leave it for fixing as a separate issue. I opened this issue to track it >>> [6]. >>> >>> --- >>> >>> Jtreg tests: >>> >>> I expanded the CompressedOops/CompressedClassPointers.java. I also >>> extended them to Windows. The tests now optionally omit strict class space >>> placement tests, since these tests heavily depend on ASLR and were the >>> reason they were excluded on Windows. However I think even without checking >>> for class space placement they make sense, just to see that the VM comes up >>> and lives with the many different settings we can run in. >>> >>> --- >>> >>> Tests: >>> >>> - I ran the patch through Oracles submit repo >>> - I ran tests manually for aarch64, zero, linux 32bit and windows x64 >>> - The whole battery of nightly tests at SAP, including ppc, ppcle and >>> aarch64, unfortunately excluding windows because of unrelated errors. >>> Windows x64 tests will be redone tonight. >>> >>> >>> Thank you, >>> >>> Thomas >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >>> [2] >>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >>> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >>> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >>> [5] >>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >>> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >>> >>> >> > From hohensee at amazon.com Tue May 19 17:39:51 2020 From: hohensee at amazon.com (Hohensee, Paul) Date: Tue, 19 May 2020 17:39:51 +0000 Subject: [aarch64-port-dev ] RFR(XXS):8244170: correct instruction typo for dcps1/2/3 Message-ID: Lgtm too. Pushed. Paul ?On 5/19/20, 2:43 AM, "aarch64-port-dev on behalf of Andrew Dinn" wrote: On 18/05/2020 22:43, Liu, Xin wrote: > Hi, Andrew and Rahul, > > Thank you to review it. Here is the new revision, which can apply to TIP. > It's almost same, I just resolve a merge conflict with JDK-8022574. > http://cr.openjdk.java.net/~xliu/8244170/01/webrev/ > > I ran test on "hotspot:tier1" on aarch64. Still reviewed! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From thomas.stuefe at gmail.com Wed May 20 03:54:53 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 20 May 2020 05:54:53 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: <8bf736b3-9ab1-86b7-fd22-230e449b1b9f@oracle.com> References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> <8bf736b3-9ab1-86b7-fd22-230e449b1b9f@oracle.com> Message-ID: Great, Ioi, thanks a lot for your help! On Wed, May 20, 2020 at 1:43 AM Ioi Lam wrote: > Hi Thomas, > > The testing took a little longer than I expected. I've run your previous > version: > > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ > > In our CI tiers 1/4. No failures. > > I didn't run your latest version. I would suggesting testing it with your > own CI as well as in jdk-submit before pushing (after you get OKs from > other reviewers). > > Thumbs up. > - Ioi > > > On 5/19/20 7:40 AM, Thomas St?fe wrote: > > Hi guys, > > new webrev: > > full: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ > delta: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ > > Mostly format changes, breaking up at column 80 as Andrew requested. > > The only changes which matter is the removal of the unnecessary include in > arguments.cpp as Coleen suggested; and to not validate SharedBaseAddress > anymore at runtime, as Ioi requested. > > Also rebased to head. > > Thanks, Thomas > > > > > On Tue, May 19, 2020 at 6:38 AM Ioi Lam wrote: > >> >> >> On 5/18/20 7:37 AM, Thomas St?fe wrote: >> >> Hi all, >> >> fourth webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ >> >> I rebased atop of >> >> changeset: 59325:1ba9a9a3f948 >> summary: 8244433: Remove saving of RSP in Assembler::pusha_uncached() >> >> so, atop of "8241825: Make compressed oops and compressed class pointers >> independent (x86_64, PPC, S390)". >> >> The changes are very small this time, see notes below: >> >> @Ioi: >> >> >Hi Thomas, >> >> >I am running your patch in out CI pipeline now. Some comments: >> >> >[2] Does JDK-8243535 exist with the current jdk/jdk repo? >> >> I assigned JDK-8243535 to me and I'm working on a patch. But I would like >> to keep that separate from this work, since this patch is already large. >> And I would like to fix JDK-8243535 after this remodel patch has been >> pushed, which makes some minor things easier. That would leave a small time >> window where NMT does mis-track class space as shared class space, but that >> is not a big issue, it does not even disturb any test. Which in itself is >> something we may want to fix, come to think about it. >> >> >> > [3] I think this can be put in header file. >> > >> > bool Metaspace::class_space_is_initialized() { >> > return _class_space_list != NULL; >> > } >> >> Done. >> >> > [7] argument.cpp checks this: >> > >> > if (UseSharedSpaces || DumpSharedSpaces) { >> > if >> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >> > log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for >> this platform, option will be ignored.", >> > p2i((address)SharedBaseAddress)); >> > FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >> > } >> > } >> > >> > but initialize_dumptime_shared_and_meta_spaces aligns up the >> SharedBaseAddress before doing the assert. >> > >> > void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >> > assert(DumpSharedSpaces, "should be called for dump time only"); >> > >> > const size_t reserve_alignment = >> MetaspaceShared::reserved_space_alignment(); >> > char* shared_base = (char*)align_up((char*)SharedBaseAddress, >> reserve_alignment); >> > >> > #ifdef _LP64 >> > >> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >> "Sanity"); >> > >> > So theoretically shared_base may no longer be is_valid_base after the >> align_up. It probably won't happen, but I think the code will be > much >> clearer tofirst to align_up, then check for is_valid_base and reset to >> default, and finally assert. >> >> The problem with that is that at the time this coding runs os::init() did >> not yet run and we do not know yet allocation granularity. >> >> So I changed verification of SharedBaseAddress: I added the alignment as >> you suggested and moved it to a later time in VM initialization, to CDS >> initialization. >> >> >> Is the call to check_SharedBaseAddress() necessary inside >> MetaspaceShared::initialize_runtime_shared_and_meta_spaces()? >> SharedBaseAddress is currently ignored at run time. Does your patch change >> that behavior? >> >> >[8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >> following block can be simplified: >> > >> > if (!_shared_rs.is_reserved()) { >> > // Get a reserved space anywhere if attaching at the >> SharedBaseAddress fails: >> > if (UseCompressedClassPointers) { >> > // If we need a compressed class space too, let the platform >> handle the reservation. >> > _shared_rs = >> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >> > } else { >> > // anywhere is fine. >> > _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >> large */, (char*)NULL); >> > } >> > } >> > >> > ... if you change the declaration to: >> > >> > static ReservedSpace >> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >> ReservedSpace();}); >> >> I'd like to avoid keep the method LP64 only, but I rewrote the section >> somewhat to be more clearer. >> >> The new code looks good. >> >> > [9] I think the #ifdef _LP64 is not necessary: >> > >> > #ifdef _LP64 >> > // Some sanity checks after reserving address spaces for archives >> and class space. >> > assert(archive_space_rs.is_reserved(), "Sanity"); >> > if (Metaspace::using_class_space()) { >> > // Class space must closely follow the archive space. Both spaces >> must be aligned correctly. >> > assert(class_space_rs.is_reserved(), "A class space should have >> been reserved"); >> > assert(class_space_rs.base() >= archive_space_rs.end(), "class >> space should follow the cds archive space"); >> > assert(is_aligned(archive_space_rs.base(), >> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >> > assert(is_aligned(class_space_rs.base(), >> Metaspace::reserve_alignment()), "class space misaligned"); >> > } >> > #endif >> >> I removed the #ifdef, but replaced it with an #ifdef ASSERT. Which is >> also not needed, technically, but makes it clear that this section is >> debugging checks only. >> >> >> OK. >> >> The rest of the code looks good to me. I am going to run your latest >> patch in our CI and will report the results. >> >> Thanks >> - Ioi >> >> ---- >> >> @Coleen: >> >> > >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/ >> >virtualSpaceList.cpp.udiff.html >> > >> >Why did you make this change? Shouldn't the caller align it? >> >> >> You are right, I removed the assert. >> >> --- >> >> Thanks all for your review work, >> >> ..Thomas >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: >> >>> Hi Thomas, >>> >>> I am running your patch in out CI pipeline now. Some comments: >>> >>> [1] Do we still need to use _class_space_list? It looks like we just >>> have a single range. Is _class_space_list->current_virtual_space() always >>> the same VS? >>> >>> if (_class_space_list != NULL) { >>> address base = >>> (address)_class_space_list->current_virtual_space()->bottom(); >>> address top = base + compressed_class_space_size(); >>> st->print("Compressed class space mapped at: " PTR_FORMAT "-" >>> PTR_FORMAT ", size: " SIZE_FORMAT, >>> p2i(base), p2i(top), top - base); >>> >>> [2] Does JDK-8243535 exist with the current jdk/jdk repo? >>> >>> // This does currently not work because rs may be the result of a >>> split operation >>> // and NMT seems not to be able to handle splits. >>> // See JDK-8243535. >>> // MemTracker::record_virtual_memory_type((address)rs.base(), mtClass); >>> >>> >>> [3] I think this can be put in header file. >>> >>> bool Metaspace::class_space_is_initialized() { >>> return _class_space_list != NULL; >>> } >>> >>> [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is >>> the reason for the >>> gap in the following chart: >>> >>> // We do this by reserving space for the ccs behind the archives. >>> Note however that >>> // ccs follows a different alignment >>> (Metaspace::reserve_alignment), so there may >>> // be a gap between ccs and cds. >>> // We use a similar layout at runtime, see >>> reserve_address_space_for_archives(). >>> // >>> // +-- SharedBaseAddress (default = >>> 0x800000000) >>> // v >>> // +-..---------+---------+ ... >>> +----+----+----+--------+--------------------+ >>> // | Heap | Archive | | MC | RW | RO | [gap] | class >>> space | >>> // +-..---------+---------+ ... >>> +----+----+----+--------+--------------------+ >>> // |<-- MaxHeapSize -->| |<-- UnscaledClassSpaceMax = 4GB -->| >>> >>> >>> _reserve_alignment is determined here: >>> >>> void Metaspace::ergo_initialize() { >>> if (DumpSharedSpaces) { >>> // Using large pages when dumping the shared archive is currently >>> not implemented. >>> FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >>> } >>> >>> size_t page_size = os::vm_page_size(); >>> if (UseLargePages && UseLargePagesInMetaspace) { >>> page_size = os::large_page_size(); >>> } >>> >>> _commit_alignment = page_size; >>> _reserve_alignment = MAX2(page_size, >>> (size_t)os::vm_allocation_granularity()); >>> >>> But when CDS is enabled, the RS is reserved without large pages, so it >>> should be possible to incrementally commit the CCS using just >>> os::vm_allocation_granularity(). >>> >>> [5] I see the aarch64 code in >>> Metaspace::reserve_address_space_for_compressed_classes has been changed. >>> Is this necessary for this RFE, or is it a separate improvement that can be >>> done in a different RFE? >>> >>> [6] For AARCH64, should we skip the part that reserves it right above >>> the heap? Or does AARCH64 always allocate the heap such that it's a >>> preferable address? >>> >>> // case (b) >>> ReservedSpace rs; >>> >>> // Try right above the Java heap... >>> address base = align_up(CompressedOops::end(), >>> Metaspace::reserve_alignment()); >>> assert(base != NULL, "Sanity"); >>> >>> const size_t size = align_up(CompressedClassSpaceSize, >>> Metaspace::reserve_alignment()); >>> if (CompressedKlassPointers::is_valid_base(base)) { >>> rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* >>> large */, (char*)base); >>> } >>> >>> // ...failing that, reserve anywhere, but let platform do optimized >>> placement: >>> if (!rs.is_reserved()) { >>> rs = Metaspace::reserve_address_space_for_compressed_classes(size); >>> } >>> >>> [7] argument.cpp checks this: >>> >>> if (UseSharedSpaces || DumpSharedSpaces) { >>> if >>> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >>> log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for >>> this platform, option will be ignored.", >>> p2i((address)SharedBaseAddress)); >>> FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >>> } >>> } >>> >>> but initialize_dumptime_shared_and_meta_spaces aligns up the >>> SharedBaseAddress before doing the assert. >>> >>> void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >>> assert(DumpSharedSpaces, "should be called for dump time only"); >>> >>> const size_t reserve_alignment = >>> MetaspaceShared::reserved_space_alignment(); >>> char* shared_base = (char*)align_up((char*)SharedBaseAddress, >>> reserve_alignment); >>> >>> #ifdef _LP64 >>> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >>> "Sanity"); >>> >>> So theoretically shared_base may no longer be is_valid_base after the >>> align_up. It probably won't happen, but I think the code will be much >>> clearer tofirst to align_up, then check for is_valid_base and reset to >>> default, and finally assert. >>> >>> [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >>> following block can be simplified: >>> >>> if (!_shared_rs.is_reserved()) { >>> // Get a reserved space anywhere if attaching at the >>> SharedBaseAddress fails: >>> if (UseCompressedClassPointers) { >>> // If we need a compressed class space too, let the platform >>> handle the reservation. >>> _shared_rs = >>> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >>> } else { >>> // anywhere is fine. >>> _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >>> large */, (char*)NULL); >>> } >>> } >>> >>> ... if you change the declaration to: >>> >>> static ReservedSpace >>> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >>> ReservedSpace();}); >>> >>> [9] I think the #ifdef _LP64 is not necessary: >>> >>> #ifdef _LP64 >>> // Some sanity checks after reserving address spaces for archives >>> and class space. >>> assert(archive_space_rs.is_reserved(), "Sanity"); >>> if (Metaspace::using_class_space()) { >>> // Class space must closely follow the archive space. Both spaces >>> must be aligned correctly. >>> assert(class_space_rs.is_reserved(), "A class space should have >>> been reserved"); >>> assert(class_space_rs.base() >= archive_space_rs.end(), "class >>> space should follow the cds archive space"); >>> assert(is_aligned(archive_space_rs.base(), >>> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >>> assert(is_aligned(class_space_rs.base(), >>> Metaspace::reserve_alignment()), "class space misaligned"); >>> } >>> #endif >>> >>> The rest of the code looks OK to me, but I may take a look at it again >>> after getting more sleep :-) >>> >>> Thanks >>> - Ioi >>> >>> >>> >>> >>> On 5/7/20 7:21 AM, Thomas St?fe wrote: >>> >>> Hi all, >>> >>> please take a look at the third iteration of this change: >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >>> >>> Changes in this version: >>> >>> - at the request of Coleen (sorry I did not see your post earlier) I >>> removed all platform dependent files and put the platform dependent coding >>> back to metaspace.cpp and compressedOops.cpp to ease the review pain. I >>> used plain platform defines though (#ifdef AARCH64) instead of hiding them >>> behind another macro to make things clearer. Note that I still intent to >>> put this code away into the platform corners but will do so in a follow up >>> RFE. >>> >>> - I reinstated, in a fashion, the special handling of reservations on >>> Windows. On all platforms we reserve address space to map the archive files >>> in with a subsequent mapping operation. However, on Windows, we cannot use >>> MapViewOfFile() into an existing mapping. So I remove the mapping again >>> before mapping the archives - see comment in code for details. >>> >>> All CI tests at SAP run through without problems, including on Win64 and >>> aarch64, but I would be happy if others were to run test too. >>> >>> Thank you, Thomas >>> >>> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >>> wrote: >>> >>>> Hi all, >>>> >>>> Could I have reviews for the following proposal of reworking cds/class >>>> space reservation? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >>>> >>>> (Many thanks to Ioi Lam for so patiently explaining CDS internals to >>>> me, and to Andrew Haley and Nick Gasson for help with aarch64!) >>>> >>>> Reservation of the compressed class space is needlessly complicated and >>>> has some minor issues. It can be simplified and made clearer. >>>> >>>> The complexity stems from the fact that this area lives at the >>>> intersection of two to three sub systems, depending on how one counts. >>>> Metaspace, CDS, and the platform which may or may not its own view of how >>>> to reserve class space. And this code has been growing organically over >>>> time. >>>> >>>> One small example: >>>> >>>> ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t >>>> alignment, >>>> bool large_pages, char >>>> *requested_addr, >>>> bool >>>> use_requested_addr) >>>> >>>> which I spent hours decoding, resulting in a very confused mail to >>>> hs-runtime and aarch64-port-dev [2]. >>>> >>>> This patch attempts to simplify cds and metaspace setup a bit; to >>>> comment implicit knowledge which is not immediately clear; to cleanly >>>> abstract platform concerns like optimized class space placement; and to >>>> disentangle cds from metaspace to solve issues which may bite us later with >>>> Elastic Metaspace [4]. >>>> >>>> --- >>>> >>>> The main change is the reworked reservation mechanism. This is based on >>>> Ioi's proposal [5]. >>>> >>>> When reserving class space, three things must happen: >>>> >>>> 1) reservation of the space obviously. If cds is active that space must >>>> be in the vicinity of cds archives to be covered by compressed class >>>> pointer encoding. >>>> 2) setting up the internal Metaspace structures atop of that space >>>> 3) setting up compressed class pointer encoding. >>>> >>>> In its current form, Metaspace may or may not do some or all of that in >>>> one function >>>> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>> metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, >>>> it will reserve the space for Metaspace and hand it in, otherwise it will >>>> create it itself. >>>> >>>> When discussing this in [2], Ioi proposed to move the reservation of >>>> the class space completely out of Metaspace and make it a responsibility of >>>> the caller always. This would reduce some complexity, and this patch >>>> follows the proposal. >>>> >>>> I removed >>>> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>> metaspace_rs, char* requested_addr, address cds_base); and all its sub >>>> functions. >>>> >>>> (1) now has to always be done outside - a ReservedSpace for class space >>>> has to be provided by the caller. However, Metaspace now offers a utility >>>> function for reserving space at a "nice" location, and explicitly doing >>>> nothing else: >>>> >>>> ReservedSpace >>>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>>> >>>> this function can be redefined on a platform level for platform >>>> optimized reservation, see below for details. >>>> >>>> (2) is taken care of by a new function, >>>> Metaspace::initialize_class_space(ReservedSpace rs) >>>> >>>> (3) is taken care of a new function >>>> CompressedKlassPointers::initialize(), see below for details. >>>> >>>> >>>> So, class space now is set up three explicit steps: >>>> >>>> - First, reserve a suitable space by however means you want. For >>>> convenience you may use >>>> Metaspace::reserve_address_space_for_compressed_classes(), or you may roll >>>> your own reservation. >>>> - Next, tell Metaspace to use that range as backing storage for class >>>> space: Metaspace::initialize_class_space(ReservedSpace rs) >>>> - Finally, set up encoding. Encoding is independent from the concept of >>>> a ReservedSpace, it just gets an address range, see below for details. >>>> >>>> Separating these steps and moving them out of the responsibility of >>>> Metaspace makes this whole thing more flexible; it also removes unnecessary >>>> knowledge (e.g. Metaspace does not need to know anything about either ccp >>>> encoding or cds). >>>> >>>> --- >>>> >>>> How it comes together: >>>> >>>> If CDS is off, we just reserve a space using >>>> Metaspace::reserve_address_space_for_compressed_classes(), initialize it >>>> with Metaspace::initialize_class_space(ReservedSpace rs), then set up >>>> compressed class pointer encoding covering the range of this class space. >>>> >>>> If CDS is on (dump time), we reserve large 4G space, either at >>>> SharedBaseAddress or using >>>> Metaspace::reserve_address_space_for_compressed_classes(); we then split >>>> that into 3G archive space and 1G class space; we set up that space with >>>> Metaspace as class space; then we set up compressed class pointer encoding >>>> covering both archive space and cds. >>>> >>>> If CDS is on (run time), we reserve a large space, split it into >>>> archive space (large enough to hold both archives) and class space, then >>>> basically proceed as above. >>>> >>>> Note that this is almost exactly how things worked before (modulo some >>>> minor fixes, e.g. alignment issues), only the code is reformed and made >>>> more explicit. >>>> >>>> --- >>>> >>>> I moved compressed class pointer setup over to CompressedKlassPointers >>>> and changed the interface: >>>> >>>> -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >>>> metaspace_rs, address cds_base) >>>> +void CompressedKlassPointers::initialize(address addr, size_t len); >>>> >>>> Instead of feeding it a single ReservedSpace, which is supposed to >>>> represent class space, and an optional alternate base if cds is on, now we >>>> give it just an numeric address range. That range marks the limits to where >>>> Klass structures are to be expected, and is the implicit promise that >>>> outside that range no Klass structures will exist, so encoding has to cover >>>> only this range. >>>> >>>> This range may contain just the class space; or class space+cds; or >>>> whatever allocation scheme we come up with in the future. Encoding does not >>>> really care how the memory is organized as long as the input range covers >>>> all possible Klass locations. That way we remove knowledge about class >>>> space/cds from compressed class pointer encoding. >>>> >>>> Moving it away from metaspace.cpp into the CompressedKlassPointers >>>> class also mirrors CompressedOops::initialize(). >>>> >>>> --- >>>> >>>> I renamed _narrow_klass_range to just _range, because strictly speaking >>>> this is the range un-narrow Klass pointers can have. >>>> >>>> As for the implementation of >>>> CompressedKlassPointers::initialize(address addr, size_t len), I mimicked >>>> very closely what happened before, so there should be almost no >>>> differences. Since "almost no differences" sounds scary :) here are the >>>> differences: >>>> >>>> - When CDS is active (dump or run time) we now always, unconditionally, >>>> set the encoding range to 4G. This fixes a theoretical bug discussed on >>>> aarch64-port-dev [1]. >>>> >>>> - When CDS is not active, we set the encoding range to the minimum >>>> required length. Before, it was left at its default value of 4G. >>>> >>>> Both differences only affect aarch64, since they are currently the only >>>> one using the range field in CompressedKlassPointers. >>>> >>>> I wanted to add an assert somewhere to test encoding of the very last >>>> address of the CompressedKlassPointers range, again to prevent errors like >>>> [3]. But I did not come up with a good place for this assert which would >>>> cover also the encoding done by C1/C2. >>>> >>>> For the same reason I thought about introducing a mode where Klass >>>> structures would be allocated in reverse order, starting at the end of the >>>> ccs, but again left it out as too big a change. >>>> >>>> --- >>>> >>>> OS abstraction: platforms may have restrictions of what constitutes a >>>> valid compressed class pointer encoding base. Or if not, they may have at >>>> least preferences. There was logic like this in metaspace.cpp, which I >>>> removed and cleanly factored out into platform dependent files, giving each >>>> platform the option to add special logic. >>>> >>>> These are two new methods: >>>> >>>> - bool CompressedKlassPointers::is_valid_base(address p) >>>> >>>> to let the platform tell you whether it considers p to be a valid >>>> encoding base. The only platform having these restrictions currently is >>>> aarch64. >>>> >>>> - ReservedSpace >>>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>>> >>>> this hands over the process of allocating a range suitable for >>>> compressed class pointer encoding to the platform. Most platforms will >>>> allocate just anywhere, but some platforms may have a better strategy (e.g. >>>> trying low memory first, trying only correctly aligned addresses and so >>>> on). >>>> >>>> Beforehand, this coding existed in a similar form in metaspace.cpp for >>>> aarch64 and AIX. For now, I left the AIX part out - it seems only half >>>> done, and I want to check further if we even need it, if yes why not on >>>> Linux ppc, and C1 does not seem to support anything other than base+offset >>>> with shift either, but I may be mistaken. >>>> >>>> These two methods should give the platform enough control to implement >>>> their own scheme for optimized class space placement without bothering any >>>> shared code about it. >>>> >>>> Note about the form, I introduced two new platform dependent files, >>>> "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about >>>> this but this seems to be what we generally do in hotspot, right? >>>> >>>> --- >>>> >>>> Metaspace reserve alignment vs cds alignment >>>> >>>> CDS was using Metaspace reserve alignment for CDS internal purposes. I >>>> guess this was just a copy paste issue. It never caused problems since >>>> Metaspace reserve alignment == page size, but that is not true anymore in >>>> the upcoming Elastic Metaspace where reserve alignment will be larger. This >>>> causes a number of issues. >>>> >>>> I separated those two cleanly. CDS now uses >>>> os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in >>>> those two places where it is needed, when CDS creates the address space for >>>> class space on behalf of the Metaspace. >>>> >>>> --- >>>> >>>> Windows special handling in CDS >>>> >>>> To simplify coding I removed the windows specific handling which left >>>> out reservation of the archive. This was needed because windows cannot mmap >>>> files into reserved regions. But fallback code exists in filemap.cpp for >>>> this case which just reads in the region instead of mapping it. >>>> >>>> Should that turn out to be a performance problem, I will reinstate the >>>> feature. But a simpler way would be reserve the archive and later just >>>> before mmapping the archive file to release the archive space. That would >>>> not only be simpler but give us the best guarantee that that address space >>>> is actually available. But I'd be happy to leave that part out completely >>>> if we do not see any performance problems on windows x64. >>>> >>>> --- >>>> >>>> NMT cannot deal with spaces which are split. This problem manifests in >>>> that bookkeeping for class space is done under "Shared Classes", not >>>> "Classes" as it should. This problem exists today too at dump time and >>>> randomly at run time. But since I simplified the reservation, this problem >>>> now shows up always, whether or not we map at the SharedBaseAddress. >>>> While I could work around this problem, I'd prefer this problem to be >>>> solved at the core, and NMT to have an option to recognize reservation >>>> splits. So I'd rather not put a workaround for this into the patch but >>>> leave it for fixing as a separate issue. I opened this issue to track it >>>> [6]. >>>> >>>> --- >>>> >>>> Jtreg tests: >>>> >>>> I expanded the CompressedOops/CompressedClassPointers.java. I also >>>> extended them to Windows. The tests now optionally omit strict class space >>>> placement tests, since these tests heavily depend on ASLR and were the >>>> reason they were excluded on Windows. However I think even without checking >>>> for class space placement they make sense, just to see that the VM comes up >>>> and lives with the many different settings we can run in. >>>> >>>> --- >>>> >>>> Tests: >>>> >>>> - I ran the patch through Oracles submit repo >>>> - I ran tests manually for aarch64, zero, linux 32bit and windows x64 >>>> - The whole battery of nightly tests at SAP, including ppc, ppcle and >>>> aarch64, unfortunately excluding windows because of unrelated errors. >>>> Windows x64 tests will be redone tonight. >>>> >>>> >>>> Thank you, >>>> >>>> Thomas >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >>>> [2] >>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >>>> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >>>> [5] >>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >>>> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >>>> >>>> >>> >> > From ci_notify at linaro.org Wed May 20 14:59:06 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 20 May 2020 14:59:06 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK JDK on AArch64 Message-ID: <1574497172.1098.1589986746955.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/summary/2020/140/summary.html ------------------------------------------------------------------------------- client-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,780; fail: 19; not run: 90 ------------------------------------------------------------------------------- client-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,495; fail: 670; error: 23 ------------------------------------------------------------------------------- client-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/24 pass: 5,775; fail: 45 Build 1: aarch64/2020/jan/27 pass: 5,776; fail: 44 Build 2: aarch64/2020/jan/29 pass: 5,776; fail: 44 Build 3: aarch64/2020/feb/01 pass: 5,777; fail: 46 Build 4: aarch64/2020/feb/03 pass: 5,777; fail: 46 Build 5: aarch64/2020/feb/05 pass: 5,778; fail: 46 Build 6: aarch64/2020/feb/10 pass: 5,781; fail: 46 Build 7: aarch64/2020/feb/12 pass: 5,786; fail: 46 Build 8: aarch64/2020/mar/06 pass: 5,797; fail: 46 Build 9: aarch64/2020/mar/16 pass: 5,796; fail: 47 Build 10: aarch64/2020/apr/08 pass: 5,816; fail: 46; error: 2 Build 11: aarch64/2020/may/09 pass: 5,835; fail: 46 Build 12: aarch64/2020/may/11 pass: 5,835; fail: 46 Build 13: aarch64/2020/may/17 pass: 5,837; fail: 47 Build 14: aarch64/2020/may/19 pass: 5,836; fail: 48 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/24 pass: 8,832; fail: 537; error: 16 Build 1: aarch64/2020/jan/27 pass: 8,846; fail: 523; error: 17 Build 2: aarch64/2020/jan/29 pass: 8,844; fail: 522; error: 19 Build 3: aarch64/2020/feb/01 pass: 8,848; fail: 523; error: 18 Build 4: aarch64/2020/feb/03 pass: 8,851; fail: 525; error: 15 Build 5: aarch64/2020/feb/05 pass: 8,851; fail: 526; error: 15 Build 6: aarch64/2020/feb/10 pass: 8,858; fail: 518; error: 20 Build 7: aarch64/2020/feb/12 pass: 8,849; fail: 525; error: 17 Build 8: aarch64/2020/mar/06 pass: 8,870; fail: 526; error: 17 Build 9: aarch64/2020/mar/16 pass: 8,872; fail: 525; error: 16 Build 10: aarch64/2020/apr/08 pass: 8,891; fail: 532; error: 13 Build 11: aarch64/2020/may/09 pass: 8,929; fail: 543; error: 15 Build 12: aarch64/2020/may/11 pass: 8,929; fail: 544; error: 14 Build 13: aarch64/2020/may/17 pass: 8,934; fail: 542; error: 12 Build 14: aarch64/2020/may/19 pass: 8,951; fail: 524; error: 19 4 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/22 pass: 4,033 Build 1: aarch64/2020/jan/24 pass: 4,033 Build 2: aarch64/2020/jan/27 pass: 4,033 Build 3: aarch64/2020/feb/01 pass: 4,036 Build 4: aarch64/2020/feb/03 pass: 4,036 Build 5: aarch64/2020/feb/05 pass: 4,036 Build 6: aarch64/2020/feb/10 pass: 4,037 Build 7: aarch64/2020/feb/12 pass: 4,037 Build 8: aarch64/2020/mar/06 pass: 4,039 Build 9: aarch64/2020/mar/16 pass: 4,039 Build 10: aarch64/2020/apr/08 pass: 4,042 Build 11: aarch64/2020/may/09 pass: 4,052 Build 12: aarch64/2020/may/11 pass: 4,052 Build 13: aarch64/2020/may/17 pass: 4,055 Build 14: aarch64/2020/may/19 pass: 4,055 ------------------------------------------------------------------------------- server-release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 5,787; fail: 18; not run: 90 ------------------------------------------------------------------------------- server-release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 8,476; fail: 686; error: 27 ------------------------------------------------------------------------------- server-release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2018/oct/15 pass: 3,970; fail: 5 Previous results can be found here: http://openjdk.linaro.org/jdkX/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.95x Relative performance: Server critical-jOPS (nc): 12.00x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 133.16 Server 133.16 / Server 2014-04-01 (71.00): 1.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdkX/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-23 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/022/results/ 2020-01-25 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/024/results/ 2020-01-28 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/027/results/ 2020-02-02 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/032/results/ 2020-02-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/034/results/ 2020-02-06 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/036/results/ 2020-02-11 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/041/results/ 2020-02-13 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/043/results/ 2020-03-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/066/results/ 2020-03-19 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/076/results/ 2020-04-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/099/results/ 2020-05-10 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/130/results/ 2020-05-12 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/132/results/ 2020-05-19 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/138/results/ 2020-05-20 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/2020/140/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdkX/jcstress-nightly-runs/ From ci_notify at linaro.org Wed May 20 15:03:37 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Wed, 20 May 2020 15:03:37 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 8u on AArch64 Message-ID: <775186660.1102.1589987018077.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/summary/2020/140/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/21 pass: 838; fail: 13; error: 1 Build 1: aarch64/2019/nov/02 pass: 843; fail: 9; error: 1 Build 2: aarch64/2019/nov/14 pass: 843; fail: 9; error: 1 Build 3: aarch64/2019/dec/16 pass: 843; fail: 10; error: 1 Build 4: aarch64/2019/dec/17 pass: 846; fail: 10; error: 2 Build 5: aarch64/2019/dec/19 pass: 846; fail: 10; error: 2 Build 6: aarch64/2019/dec/21 pass: 848; fail: 10; error: 2 Build 7: aarch64/2020/jan/09 pass: 848; fail: 10; error: 1 Build 8: aarch64/2020/jan/11 pass: 848; fail: 10; error: 1 Build 9: aarch64/2020/jan/20 pass: 848; fail: 10; error: 1 Build 10: aarch64/2020/jan/25 pass: 848; fail: 10; error: 1 Build 11: aarch64/2020/may/06 pass: 885; fail: 12; error: 1 Build 12: aarch64/2020/may/10 pass: 885; fail: 12; error: 1 Build 13: aarch64/2020/may/12 pass: 885; fail: 12; error: 1 Build 14: aarch64/2020/may/19 pass: 886; fail: 12; error: 1 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/nov/02 pass: 5,956; fail: 278; error: 18 Build 1: aarch64/2019/nov/14 pass: 5,956; fail: 275; error: 21 Build 2: aarch64/2019/dec/16 pass: 5,964; fail: 267; error: 21 Build 3: aarch64/2019/dec/17 pass: 5,963; fail: 267; error: 22 Build 4: aarch64/2019/dec/19 pass: 5,959; fail: 272; error: 21 Build 5: aarch64/2019/dec/21 pass: 5,970; fail: 262; error: 21 Build 6: aarch64/2020/jan/09 pass: 5,963; fail: 276; error: 20 Build 7: aarch64/2020/jan/11 pass: 5,959; fail: 279; error: 21 Build 8: aarch64/2020/jan/20 pass: 5,987; fail: 256; error: 24 Build 9: aarch64/2020/jan/25 pass: 5,962; fail: 285; error: 22 Build 10: aarch64/2020/feb/03 pass: 5,976; fail: 278; error: 19 Build 11: aarch64/2020/may/06 pass: 5,998; fail: 281; error: 21 Build 12: aarch64/2020/may/10 pass: 6,025; fail: 695; error: 21 Build 13: aarch64/2020/may/12 pass: 6,011; fail: 709; error: 21 Build 14: aarch64/2020/may/19 pass: 6,009; fail: 712; error: 22 ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/sep/21 pass: 3,116; fail: 2 Build 1: aarch64/2019/nov/02 pass: 3,116; fail: 2 Build 2: aarch64/2019/nov/14 pass: 3,116; fail: 2 Build 3: aarch64/2019/dec/16 pass: 3,116; fail: 2 Build 4: aarch64/2019/dec/17 pass: 3,117; fail: 2 Build 5: aarch64/2019/dec/19 pass: 3,117; fail: 2 Build 6: aarch64/2019/dec/21 pass: 3,117; fail: 2 Build 7: aarch64/2020/jan/09 pass: 3,117; fail: 2 Build 8: aarch64/2020/jan/11 pass: 3,117; fail: 2 Build 9: aarch64/2020/jan/20 pass: 3,117; fail: 2 Build 10: aarch64/2020/jan/25 pass: 3,117; fail: 2 Build 11: aarch64/2020/may/06 pass: 3,117; fail: 2 Build 12: aarch64/2020/may/10 pass: 3,117; fail: 2 Build 13: aarch64/2020/may/12 pass: 3,117; fail: 2 Build 14: aarch64/2020/may/19 pass: 3,117; fail: 2 Previous results can be found here: http://openjdk.linaro.org/jdk8u/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 6.73x Relative performance: Server critical-jOPS (nc): 8.89x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 176.44 Server 176.44 / Server 2014-04-01 (71.00): 2.49x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk8u/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-09-22 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/264/results/ 2019-11-02 pass rate: 8230/8230, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/306/results/ 2019-11-15 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/318/results/ 2019-12-16 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/350/results/ 2019-12-18 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/351/results/ 2019-12-19 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/353/results/ 2019-12-22 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2019/355/results/ 2020-01-09 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/009/results/ 2020-01-11 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/011/results/ 2020-01-20 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/020/results/ 2020-01-25 pass rate: 8231/8231, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/025/results/ 2020-05-06 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/127/results/ 2020-05-10 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/131/results/ 2020-05-14 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/133/results/ 2020-05-20 pass rate: 7443/7443, results: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/2020/140/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk8u/jcstress-nightly-runs/ From shade at redhat.com Wed May 20 16:17:51 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 18:17:51 +0200 Subject: [aarch64-port-dev ] RFR: 2020-05-20, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah Message-ID: <6aa656e7-437a-a9dc-7c00-a8833e8cef9d@redhat.com> https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200520/webrev.01/ This is a huge (sorry!) integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It was generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge. While the webrev is large, it contains lots of removals and refactorings in Shenandoah parts of the code. The actual changes to shared code are small and limited only to Shenandoah codepaths. There should be no changes to shared parts outside Shenandoah paths. Feel free to ignore the changes to Shenandoah code, we (Shenandoah devs) vouch for those parts :) I tagged the merge with aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20. Changes: [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings [backport] 8240749: Shenandoah: refactor ShenandoahUtils [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation [backport] 8240873: Shenandoah: Short-cut arraycopy barriers [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently [backport] 8241534: Shenandoah: region status should include update watermark [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 [backport] 8241351: Shenandoah: fragmentation metrics overhaul [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation [backport] 8241520: Shenandoah: simplify region sequence numbers handling [backport] 8241583: Shenandoah: turn heap lock asserts into macros [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace [backport] 8241673: Shenandoah: refactor anti-false-sharing padding [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods [backport] 8241838: Shenandoah: no need to trash cset during final mark [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() [backport] 8241093: Shenandoah: editorial changes in flag descriptions [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it [backport] 8241985: Shenandoah: simplify collectable garbage logging [backport] 8241983: Shenandoah: simplify FreeSet logging [backport] 8242040: Shenandoah: print allocation failure type [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged [backport] 8242082: Shenandoah: Purge Traversal mode [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods Fix slowdebug build after JDK-8230853 backport [backport] 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata [backport] 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java [backport] 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier [backport] 8242130: Shenandoah: Simplify arraycopy-barrier dispatching [backport] 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name [backport] 8242054: Shenandoah: New incremental-update mode [backport] 8242271: Shenandoah: add test to verify GC mode unlock [backport] 8242273: Shenandoah: accept either SATB or IU barriers, but not both [backport] 8242301: Shenandoah: Inline LRB runtime call [backport] 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry [backport] 8242353: Shenandoah: micro-optimize region liveness handling [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end [backport] 8244551: Shenandoah: Fix racy update of update_watermark [backport] 8243463: Shenandoah: ditch total_pause counters [backport] 8243464: Shenandoah: print statistic counters in time order [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters [backport] 8243487: Shenandoah: make _num_phases illegal phase type [backport] 8244200: Shenandoah: build breakages after JDK-8241743 [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods [backport] 8221435: Shenandoah should not mark through weak roots [backport] 8221629: Shenandoah: Cleanup class unloading logic [backport] 8222992: Shenandoah: Pre-evacuate all roots [backport] 8223215: Shenandoah: Support verifying subset of roots [backport] 8223774: Shenandoah: Refactor ShenandoahRootProcessor and family [backport] 8224210: Shenandoah: Refactor ShenandoahRootScanner to support scanning CSet codecache roots [backport] 8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with --disable-precompiled-headers [backport] 8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable [backport] 8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle [backport] 8225014: Separate ShenandoahRootScanner method for object_iterate [backport] 8225573: Shenandoah: Enhance ShenandoahVerifier to ensure roots to-space invariant [backport] 8225590: Shenandoah: Refactor ShenandoahClassLoaderDataRoots API [backport] 8226413: Shenandoah: Separate root scanner for SH::object_iterate() [backport] 8231198: Shenandoah: heap walking should visit all roots most of the time [backport] 8231244: Shenandoah: all-roots heap walking misses some weak roots [backport] 8243494: Shenandoah: set counters once per cycle [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah [backport] 8239786: Shenandoah: print per-cycle statistics [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 [backport] 8243573: Shenandoah: rename GCParPhases and related code [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles [backport] 8244326: Shenandoah: global statistics should not accept bogus samples Shenandoah: add root statistics for string dedup table/queues Shenandoah: specialize String Table scans for better pause performance [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify the heuristics [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 quite extensively -- Thanks, -Aleksey From gnu.andrew at redhat.com Wed May 20 16:30:55 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Wed, 20 May 2020 17:30:55 +0100 Subject: [aarch64-port-dev ] RFR: 2020-05-20, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: <6aa656e7-437a-a9dc-7c00-a8833e8cef9d@redhat.com> References: <6aa656e7-437a-a9dc-7c00-a8833e8cef9d@redhat.com> Message-ID: On 20/05/2020 17:17, Aleksey Shipilev wrote: > https://cr.openjdk.java.net/~shade/shenandoah/merges/aarch64-port-8u-20200520/webrev.01/ > > This is a huge (sorry!) integration of Shenandoah 8u from our shenandoah/jdk8 staging repository. It > was generated by plain pull from shenandoah/jdk8/hotspot repository and automatic merge. > > While the webrev is large, it contains lots of removals and refactorings in Shenandoah parts of the > code. The actual changes to shared code are small and limited only to Shenandoah codepaths. There > should be no changes to shared parts outside Shenandoah paths. > > Feel free to ignore the changes to Shenandoah code, we (Shenandoah devs) vouch for those parts :) > > I tagged the merge with aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20. > > Changes: > [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings > [backport] 8240749: Shenandoah: refactor ShenandoahUtils > [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker > [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts > [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles > [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks > [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation > [backport] 8240873: Shenandoah: Short-cut arraycopy barriers > [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently > [backport] 8241534: Shenandoah: region status should include update watermark > [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 > [backport] 8241351: Shenandoah: fragmentation metrics overhaul > [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" > [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation > [backport] 8241520: Shenandoah: simplify region sequence numbers handling > [backport] 8241583: Shenandoah: turn heap lock asserts into macros > [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace > [backport] 8241673: Shenandoah: refactor anti-false-sharing padding > [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved > [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() > [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap > [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods > [backport] 8241838: Shenandoah: no need to trash cset during final mark > [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion > [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number > [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number > [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines > [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() > [backport] 8241093: Shenandoah: editorial changes in flag descriptions > [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it > [backport] 8241985: Shenandoah: simplify collectable garbage logging > [backport] 8241983: Shenandoah: simplify FreeSet logging > [backport] 8242040: Shenandoah: print allocation failure type > [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target > [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold > [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag > [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters > [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged > [backport] 8242082: Shenandoah: Purge Traversal mode > [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared > [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses > [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc > [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly > [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset > [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set > [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods > Fix slowdebug build after JDK-8230853 backport > [backport] 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata > [backport] 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with > java/util/Collections/FindSubList.java > [backport] 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier > [backport] 8242130: Shenandoah: Simplify arraycopy-barrier dispatching > [backport] 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name > [backport] 8242054: Shenandoah: New incremental-update mode > [backport] 8242271: Shenandoah: add test to verify GC mode unlock > [backport] 8242273: Shenandoah: accept either SATB or IU barriers, but not both > [backport] 8242301: Shenandoah: Inline LRB runtime call > [backport] 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry > [backport] 8242353: Shenandoah: micro-optimize region liveness handling > [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache > [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread > [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically > [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle > [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data > [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs > [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end > [backport] 8244551: Shenandoah: Fix racy update of update_watermark > [backport] 8243463: Shenandoah: ditch total_pause counters > [backport] 8243464: Shenandoah: print statistic counters in time order > [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters > [backport] 8243487: Shenandoah: make _num_phases illegal phase type > [backport] 8244200: Shenandoah: build breakages after JDK-8241743 > [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods > [backport] 8221435: Shenandoah should not mark through weak roots > [backport] 8221629: Shenandoah: Cleanup class unloading logic > [backport] 8222992: Shenandoah: Pre-evacuate all roots > [backport] 8223215: Shenandoah: Support verifying subset of roots > [backport] 8223774: Shenandoah: Refactor ShenandoahRootProcessor and family > [backport] 8224210: Shenandoah: Refactor ShenandoahRootScanner to support scanning CSet codecache roots > [backport] 8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with > --disable-precompiled-headers > [backport] 8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable > [backport] 8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current > GC cycle > [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update > cycle > [backport] 8225014: Separate ShenandoahRootScanner method for object_iterate > [backport] 8225573: Shenandoah: Enhance ShenandoahVerifier to ensure roots to-space invariant > [backport] 8225590: Shenandoah: Refactor ShenandoahClassLoaderDataRoots API > [backport] 8226413: Shenandoah: Separate root scanner for SH::object_iterate() > [backport] 8231198: Shenandoah: heap walking should visit all roots most of the time > [backport] 8231244: Shenandoah: all-roots heap walking misses some weak roots > [backport] 8243494: Shenandoah: set counters once per cycle > [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah > [backport] 8239786: Shenandoah: print per-cycle statistics > [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 > [backport] 8243573: Shenandoah: rename GCParPhases and related code > [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly > [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles > [backport] 8244326: Shenandoah: global statistics should not accept bogus samples > Shenandoah: add root statistics for string dedup table/queues > Shenandoah: specialize String Table scans for better pause performance > [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection > [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify > the heuristics > [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics > [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode > [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode > [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode > [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR > > Testing: hotspot_gc_shenandoah {fastdebug,release}; it was also tested in sh/jdk8 quite extensively > Shared code changes look ok and mostly restricted to Shenandoah-specific blocks AFAICS. Let's get this in, and then I'll test it once merged with the b03 work I have. Thanks, -- Andrew :) Senior Free Java Software Engineer 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 Wed May 20 18:22:25 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Wed, 20 May 2020 20:22:25 +0200 Subject: [aarch64-port-dev ] RFR: 2020-05-20, Bulk integration of Shenandoah 8u to aarch64-port/jdk8u-shenandoah In-Reply-To: References: <6aa656e7-437a-a9dc-7c00-a8833e8cef9d@redhat.com> Message-ID: <5d54bc62-9ed4-f6e9-ae13-fc8aea7562c1@redhat.com> On 5/20/20 6:30 PM, Andrew Hughes wrote: > Let's get this in, and then I'll test it once merged with the b03 work I > have. Thank you, pushed. -- Thanks, -Aleksey From shade at redhat.com Wed May 20 18:22:13 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 20 May 2020 18:22:13 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 107 new changesets Message-ID: <202005201822.04KIMEob010849@aojmv0008.oracle.com> Changeset: f5c426d7e4bd Author: shade Date: 2020-03-06 17:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f5c426d7e4bd [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings Reviewed-by: rkennke, zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp Changeset: d888701f7768 Author: shade Date: 2020-03-09 22:40 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d888701f7768 [backport] 8240749: Shenandoah: refactor ShenandoahUtils Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp Changeset: b616c66d4705 Author: shade Date: 2020-03-09 22:41 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b616c66d4705 [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker Reviewed-by: rkennke - src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: 3018d88de54d Author: shade Date: 2020-01-24 21:11 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3018d88de54d [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts [backport] 8237821: Shenandoah: build broken after JDK-8237637 (Remove dubious type conversions from oop) Reviewed-by: shade Contributed-by: Aditya Mandaleeka ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.inline.hpp Changeset: 87f21873fa4c Author: shade Date: 2020-03-11 14:17 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/87f21873fa4c [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles Reviewed-by: rkennke, zgu ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/runtime/vm_operations.hpp ! test/gc/shenandoah/TestStringDedupStress.java Changeset: f0b8ba0570c6 Author: zgu Date: 2020-03-12 09:25 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f0b8ba0570c6 [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: d4e4d6a6df74 Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d4e4d6a6df74 [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: 0bf1ade02c1f Author: rkennke Date: 2020-03-12 17:52 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0bf1ade02c1f [backport] 8240873: Shenandoah: Short-cut arraycopy barriers Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp Changeset: 2c18c8e5bf02 Author: rkennke Date: 2020-03-17 11:49 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2c18c8e5bf02 [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: f0797ef4bec1 Author: shade Date: 2020-03-24 18:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f0797ef4bec1 [backport] 8241534: Shenandoah: region status should include update watermark Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp Changeset: 658223db05f0 Author: shade Date: 2020-03-12 18:50 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/658223db05f0 [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: ca49b44f5563 Author: shade Date: 2020-03-23 19:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ca49b44f5563 [backport] 8241351: Shenandoah: fragmentation metrics overhaul Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMetrics.hpp Changeset: 2a5e8bcd0faa Author: shade Date: 2020-03-23 19:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2a5e8bcd0faa [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp Changeset: 880e0f80a226 Author: shade Date: 2020-03-23 19:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/880e0f80a226 [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.hpp Changeset: ea592ef76c80 Author: shade Date: 2020-03-24 18:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ea592ef76c80 [backport] 8241520: Shenandoah: simplify region sequence numbers handling Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: be98ad3bab74 Author: shade Date: 2020-03-25 17:20 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/be98ad3bab74 [backport] 8241583: Shenandoah: turn heap lock asserts into macros Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahLock.hpp Changeset: e0569518bb86 Author: shade Date: 2020-03-26 19:08 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e0569518bb86 [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace Reviewed-by: rkennke ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeap.java ! agent/src/share/classes/sun/jvm/hotspot/gc_implementation/shenandoah/ShenandoahHeapRegion.java ! agent/src/share/classes/sun/jvm/hotspot/oops/ObjectHeap.java ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp Changeset: 884ad772f981 Author: shade Date: 2020-03-26 19:09 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/884ad772f981 [backport] 8241673: Shenandoah: refactor anti-false-sharing padding Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahLock.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPacer.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahPadding.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSharedVariables.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahTaskqueue.hpp Changeset: 96e4bff82c32 Author: shade Date: 2020-03-27 15:33 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/96e4bff82c32 [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved Reviewed-by: zgu, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: d9eec907873f Author: shade Date: 2020-03-27 15:33 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d9eec907873f [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetC1.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahEvacOOMHandler.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMonitoringSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupQueue.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/services/memoryService.cpp Changeset: 31c41ebe76e2 Author: shade Date: 2020-03-27 15:33 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/31c41ebe76e2 [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 8633642b8b06 Author: shade Date: 2020-03-27 15:33 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8633642b8b06 [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.inline.hpp Changeset: bbc16cd00817 Author: shade Date: 2020-03-30 19:37 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bbc16cd00817 [backport] 8241838: Shenandoah: no need to trash cset during final mark Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: b7573cb9b63f Author: shade Date: 2020-03-30 19:37 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b7573cb9b63f [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 9d021b2d8b61 Author: shade Date: 2020-03-30 19:38 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9d021b2d8b61 [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp Changeset: 28c2f637f1ea Author: shade Date: 2020-03-30 19:38 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/28c2f637f1ea [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkingContext.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/vmStructs_shenandoah.hpp Changeset: d642b661ae7f Author: shade Date: 2020-03-31 08:42 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d642b661ae7f [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPadding.hpp Changeset: ae8ef4c2a966 Author: shade Date: 2020-04-07 14:32 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ae8ef4c2a966 [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() Reviewed-by: rkennke, stuefe ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: c421e23d75ca Author: shade Date: 2020-03-18 06:28 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c421e23d75ca [backport] 8241093: Shenandoah: editorial changes in flag descriptions Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 7e913eee7872 Author: shade Date: 2020-04-01 19:50 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7e913eee7872 [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 812520907321 Author: shade Date: 2020-04-01 19:50 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/812520907321 [backport] 8241985: Shenandoah: simplify collectable garbage logging Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! test/gc/shenandoah/options/TestVerboseGC.java Changeset: 1e12f73bb1ec Author: shade Date: 2020-04-01 19:50 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1e12f73bb1ec [backport] 8241983: Shenandoah: simplify FreeSet logging Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp Changeset: 927ad3007678 Author: shade Date: 2020-04-02 20:10 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/927ad3007678 [backport] 8242040: Shenandoah: print allocation failure type Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahAllocRequest.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: bcda4294d29f Author: shade Date: 2020-04-02 20:11 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bcda4294d29f [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp Changeset: 167834f91182 Author: shade Date: 2020-04-03 11:33 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/167834f91182 [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 353b051a0933 Author: shade Date: 2020-04-03 11:33 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/353b051a0933 [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/options/TestRegionSizeArgs.java Changeset: ced89cdab2fb Author: shade Date: 2020-04-03 13:58 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ced89cdab2fb [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: e461491ccbf6 Author: shade Date: 2020-04-03 13:58 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e461491ccbf6 [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: b69ee541d07f Author: rkennke Date: 2020-04-03 15:06 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b69ee541d07f [backport] 8242082: Shenandoah: Purge Traversal mode Reviewed-by: shade ! src/cpu/x86/vm/macroAssembler_x86.cpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.cpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.hpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.inline.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/gc_implementation/shenandoah/shenandoahTraversalGC.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.inline.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVMOperations.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahWorkerPolicy.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/gc_interface/gcCause.hpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/runtime/vm_operations.hpp ! test/gc/shenandoah/TestAllocHumongousFragment.java ! test/gc/shenandoah/TestAllocIntArrays.java ! test/gc/shenandoah/TestAllocObjectArrays.java ! test/gc/shenandoah/TestAllocObjects.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestHeapUncommit.java ! test/gc/shenandoah/TestLotsOfCycles.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRefprocSanity.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestRetainObjects.java ! test/gc/shenandoah/TestSieveObjects.java ! test/gc/shenandoah/TestStringDedup.java ! test/gc/shenandoah/TestStringDedupStress.java ! test/gc/shenandoah/TestStringInternCleanup.java ! test/gc/shenandoah/TestVerifyJCStress.java ! test/gc/shenandoah/TestWrongArrayMember.java ! test/gc/shenandoah/jni/TestCriticalNativeArgs.sh ! test/gc/shenandoah/jni/TestCriticalNativeStress.sh ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/options/TestExplicitGC.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: 9aa4806955e3 Author: shade Date: 2020-04-06 10:31 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9aa4806955e3 [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp Changeset: 49eef2be235e Author: shade Date: 2020-04-03 16:13 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/49eef2be235e [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: 007f7948edaf Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/007f7948edaf [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: 0e4f9e6c01f1 Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0e4f9e6c01f1 [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: 821efb155848 Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/821efb155848 [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp Changeset: bb3767ea183a Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bb3767ea183a [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set 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/shenandoahHeuristics.cpp Changeset: b49cd4f04b3c Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b49cd4f04b3c [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp Changeset: ce1281b3e5aa Author: shade Date: 2020-04-22 11:48 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ce1281b3e5aa Fix slowdebug build after JDK-8230853 backport ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: df62c177841e Author: zgu Date: 2020-02-25 12:01 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/df62c177841e [backport] 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata Reviewed-by: rkennke, shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp Changeset: c30b6a2e27c4 Author: roland Date: 2020-03-24 10:31 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c30b6a2e27c4 [backport] 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp Changeset: f33666b9f05e Author: rkennke Date: 2020-03-27 12:47 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f33666b9f05e [backport] 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier Reviewed-by: shade ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiGetLoadedClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/jniHandles.cpp ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: fcf19e0cd2c1 Author: rkennke Date: 2020-04-06 13:45 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fcf19e0cd2c1 [backport] 8242130: Shenandoah: Simplify arraycopy-barrier dispatching Reviewed-by: shade ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.hpp ! src/share/vm/oops/objArrayKlass.cpp Changeset: fb9ff8b01d3a Author: rkennke Date: 2020-04-06 16:29 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/fb9ff8b01d3a [backport] 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.hpp Changeset: a222813e5654 Author: rkennke Date: 2020-04-06 17:08 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a222813e5654 [backport] 8242054: Shenandoah: New incremental-update mode Reviewed-by: shade ! src/cpu/aarch64/vm/shenandoahBarrierSetAssembler_aarch64.cpp ! src/cpu/x86/vm/shenandoahBarrierSetAssembler_x86.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSetClone.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahIUMode.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahIUMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahSupport.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! src/share/vm/prims/jvm.cpp ! test/gc/shenandoah/TestAllocHumongousFragment.java ! test/gc/shenandoah/TestAllocIntArrays.java ! test/gc/shenandoah/TestAllocObjectArrays.java ! test/gc/shenandoah/TestAllocObjects.java ! test/gc/shenandoah/TestGCThreadGroups.java ! test/gc/shenandoah/TestHeapUncommit.java ! test/gc/shenandoah/TestLotsOfCycles.java ! test/gc/shenandoah/TestPeriodicGC.java ! test/gc/shenandoah/TestRefprocSanity.java ! test/gc/shenandoah/TestRegionSampling.java ! test/gc/shenandoah/TestRetainObjects.java ! test/gc/shenandoah/TestSieveObjects.java ! test/gc/shenandoah/TestStringDedup.java ! test/gc/shenandoah/TestStringDedupStress.java ! test/gc/shenandoah/TestStringInternCleanup.java ! test/gc/shenandoah/TestVerifyJCStress.java ! test/gc/shenandoah/TestWrongArrayMember.java ! test/gc/shenandoah/mxbeans/TestChurnNotifications.java ! test/gc/shenandoah/mxbeans/TestPauseNotifications.java ! test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/options/TestExplicitGC.java ! test/gc/shenandoah/options/TestHeuristicsUnlock.java ! test/gc/shenandoah/options/TestSelectiveBarrierFlags.java ! test/gc/shenandoah/options/TestWrongBarrierDisable.java Changeset: 2c1c49f2dc23 Author: shade Date: 2020-04-07 13:18 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/2c1c49f2dc23 [backport] 8242271: Shenandoah: add test to verify GC mode unlock Reviewed-by: rkennke + test/gc/shenandoah/options/TestModeUnlock.java Changeset: 3bfbc781e7ab Author: shade Date: 2020-04-07 13:18 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3bfbc781e7ab [backport] 8242273: Shenandoah: accept either SATB or IU barriers, but not both Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahIUMode.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp ! test/gc/shenandoah/options/TestWrongBarrierDisable.java + test/gc/shenandoah/options/TestWrongBarrierEnable.java Changeset: 3705749eb8c2 Author: rkennke Date: 2020-04-07 22:31 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3705749eb8c2 [backport] 8242301: Shenandoah: Inline LRB runtime call Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp Changeset: b78de392a7a4 Author: rkennke Date: 2020-04-08 11:26 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b78de392a7a4 [backport] 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry Reviewed-by: zgu, shade ! src/share/vm/gc_implementation/shenandoah/shenandoahRuntime.cpp Changeset: 63ff28e2d3db Author: shade Date: 2020-04-08 13:44 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/63ff28e2d3db [backport] 8242353: Shenandoah: micro-optimize region liveness handling Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 7de7d252e64f Author: shade Date: 2020-04-08 13:44 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7de7d252e64f [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.hpp Changeset: cbd180202301 Author: shade Date: 2020-04-14 21:17 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cbd180202301 [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread Reviewed-by: shade Contributed-by: Aditya Mandaleeka ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: ef326d11c8b4 Author: shade Date: 2020-04-14 22:18 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ef326d11c8b4 [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: f07807b7dc60 Author: shade Date: 2020-04-21 11:20 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f07807b7dc60 [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.hpp Changeset: 086d50a5013a Author: shade Date: 2020-04-22 11:45 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/086d50a5013a [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.hpp Changeset: 48ab5ac81f0e Author: shade Date: 2020-04-22 15:19 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/48ab5ac81f0e [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahFreeSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp Changeset: 79650d2d34d5 Author: shade Date: 2020-04-22 15:19 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/79650d2d34d5 [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp Changeset: 9f3d048ba5d8 Author: rkennke Date: 2020-05-07 08:00 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9f3d048ba5d8 [backport] 8244551: Shenandoah: Fix racy update of update_watermark Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 200762661cb6 Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/200762661cb6 [backport] 8243463: Shenandoah: ditch total_pause counters Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: 504e60fe3333 Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/504e60fe3333 [backport] 8243464: Shenandoah: print statistic counters in time order 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/shenandoahHeap.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: 8dd67cec673e Author: shade Date: 2020-04-23 13:48 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8dd67cec673e [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: bd0bd7315464 Author: shade Date: 2020-04-23 18:37 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bd0bd7315464 [backport] 8243487: Shenandoah: make _num_phases illegal phase type Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 788b5b02f9b9 Author: shade Date: 2020-05-04 19:09 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/788b5b02f9b9 [backport] 8244200: Shenandoah: build breakages after JDK-8241743 Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp Changeset: 6092e5747287 Author: shade Date: 2020-04-06 20:35 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6092e5747287 [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectionSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegion.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeapRegionCounters.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: d6d6f75e8846 Author: zgu Date: 2019-03-26 12:12 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d6d6f75e8846 [backport] 8221435: Shenandoah should not mark through weak roots Reviewed-by: rkennke, shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: ea85b9f806dd Author: zgu Date: 2019-03-28 13:53 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ea85b9f806dd [backport] 8221629: Shenandoah: Cleanup class unloading logic Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: 66b77641ff2f Author: zgu Date: 2019-05-02 09:49 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/66b77641ff2f [backport] 8222992: Shenandoah: Pre-evacuate all roots Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahClosures.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahClosures.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: ef9359829812 Author: zgu Date: 2019-05-15 08:58 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/ef9359829812 [backport] 8223215: Shenandoah: Support verifying subset of roots Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp + src/share/vm/gc_implementation/shenandoah/shenandoahRootVerifier.cpp + src/share/vm/gc_implementation/shenandoah/shenandoahRootVerifier.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: 7f61117d045d Author: zgu Date: 2019-05-17 09:52 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/7f61117d045d [backport] 8223774: Shenandoah: Refactor ShenandoahRootProcessor and family Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.cpp Changeset: d7d16a57f850 Author: zgu Date: 2019-05-20 09:42 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d7d16a57f850 [backport] 8224210: Shenandoah: Refactor ShenandoahRootScanner to support scanning CSet codecache roots Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: 62b195431e49 Author: shade Date: 2019-05-22 10:48 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/62b195431e49 [backport] 8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with --disable-precompiled-headers Reviewed-by: shade Contributed-by: Ao Qi ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: 618baef15581 Author: zgu Date: 2019-05-24 09:23 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/618baef15581 [backport] 8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable Reviewed-by: rkennke, shade ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCodeRoots.hpp Changeset: 1512786c06f1 Author: zgu Date: 2019-05-27 14:34 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1512786c06f1 [backport] 8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootVerifier.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp Changeset: 875f898f4cb2 Author: zgu Date: 2019-05-22 07:12 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/875f898f4cb2 [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 457f6000509d Author: zgu Date: 2019-05-30 21:12 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/457f6000509d [backport] 8225014: Separate ShenandoahRootScanner method for object_iterate Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp + test/gc/shenandoah/TestObjItrWithHeapDump.java Changeset: dc0e98c18dda Author: zgu Date: 2019-06-18 17:58 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dc0e98c18dda [backport] 8225573: Shenandoah: Enhance ShenandoahVerifier to ensure roots to-space invariant Reviewed-by: shade ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahVerifier.hpp Changeset: 0a4cfc8c6720 Author: zgu Date: 2019-06-20 18:29 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/0a4cfc8c6720 [backport] 8225590: Shenandoah: Refactor ShenandoahClassLoaderDataRoots API Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: 5221e4fc112a Author: zgu Date: 2019-06-20 10:12 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5221e4fc112a [backport] 8226413: Shenandoah: Separate root scanner for SH::object_iterate() Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp Changeset: f48e88392ce2 Author: shade Date: 2019-09-19 20:26 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/f48e88392ce2 [backport] 8231198: Shenandoah: heap walking should visit all roots most of the time Reviewed-by: zgu, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp Changeset: 3ed179b5d3f6 Author: shade Date: 2019-09-19 20:26 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3ed179b5d3f6 [backport] 8231244: Shenandoah: all-roots heap walking misses some weak roots Reviewed-by: zgu, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: 68cc9a481bb2 Author: shade Date: 2020-04-23 21:24 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/68cc9a481bb2 [backport] 8243494: Shenandoah: set counters once per cycle Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: b72f1a596694 Author: shade Date: 2020-03-12 06:47 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/b72f1a596694 [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah Reviewed-by: shade Contributed-by: Kelvin Nilsen ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp Changeset: 6f4856c1bb18 Author: shade Date: 2020-04-24 11:45 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6f4856c1bb18 [backport] 8239786: Shenandoah: print per-cycle statistics 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/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: cb47534ba437 Author: zgu Date: 2020-04-28 12:20 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cb47534ba437 [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 Reviewed-by: rkennke, stuefe ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: cb521bac2bb1 Author: shade Date: 2020-04-30 10:02 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/cb521bac2bb1 [backport] 8243573: Shenandoah: rename GCParPhases and related code Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: 18ecf24fe35c Author: shade Date: 2020-04-30 18:05 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/18ecf24fe35c [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly Reviewed-by: zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.hpp Changeset: 1cb67ad216cc Author: shade Date: 2020-05-01 16:03 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1cb67ad216cc [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp Changeset: e3fc6fda6035 Author: shade Date: 2020-05-05 11:44 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e3fc6fda6035 [backport] 8244326: Shenandoah: global statistics should not accept bogus samples Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp Changeset: 48e051e27c4d Author: shade Date: 2020-05-19 14:48 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/48e051e27c4d Shenandoah: add root statistics for string dedup table/queues Reviewed-by: rkennke, zgu ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahStringDedup.hpp Changeset: c7919527fc2b Author: shade Date: 2020-05-19 15:03 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c7919527fc2b Shenandoah: specialize String Table scans for better pause performance Reviewed-by: rkennke, zgu ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/classfile/symbolTable.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp Changeset: 6210243cfe5f Author: shade Date: 2020-05-13 20:19 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6210243cfe5f [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection Reviewed-by: shade Contributed-by: Kelvin Nilsen ! src/share/vm/gc_implementation/shenandoah/shenandoahAsserts.hpp Changeset: a9679b2bdd50 Author: shade Date: 2020-05-11 18:33 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a9679b2bdd50 [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify the heuristics Reviewed-by: rkennke ! test/gc/shenandoah/options/TestHeuristicsUnlock.java Changeset: 178ebe5138f1 Author: shade Date: 2020-05-19 16:01 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/178ebe5138f1 [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahAggressiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahCompactHeuristics.hpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahHeuristics.cpp + src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahPassiveHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahStaticHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahCollectorPolicy.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahControlThread.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahMarkCompact.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahPhaseTimings.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahUtils.cpp Changeset: dffa79140528 Author: shade Date: 2020-05-19 16:14 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/dffa79140528 [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode Reviewed-by: rkennke + src/share/vm/gc_implementation/shenandoah/mode/shenandoahIUMode.cpp + src/share/vm/gc_implementation/shenandoah/mode/shenandoahIUMode.hpp + src/share/vm/gc_implementation/shenandoah/mode/shenandoahMode.hpp + src/share/vm/gc_implementation/shenandoah/mode/shenandoahNormalMode.cpp + src/share/vm/gc_implementation/shenandoah/mode/shenandoahNormalMode.hpp + src/share/vm/gc_implementation/shenandoah/mode/shenandoahPassiveMode.cpp + src/share/vm/gc_implementation/shenandoah/mode/shenandoahPassiveMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahIUMode.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahIUMode.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahMode.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.hpp Changeset: a5c7ff8107c4 Author: shade Date: 2020-05-11 18:33 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/a5c7ff8107c4 [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode Reviewed-by: rkennke ! src/share/vm/gc_implementation/shenandoah/mode/shenandoahIUMode.cpp ! src/share/vm/gc_implementation/shenandoah/mode/shenandoahIUMode.hpp ! src/share/vm/gc_implementation/shenandoah/mode/shenandoahPassiveMode.hpp Changeset: 49f365bf3eb8 Author: shade Date: 2020-05-11 18:33 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/49f365bf3eb8 [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode Reviewed-by: rkennke - src/share/vm/gc_implementation/shenandoah/mode/shenandoahNormalMode.cpp - src/share/vm/gc_implementation/shenandoah/mode/shenandoahNormalMode.hpp + src/share/vm/gc_implementation/shenandoah/mode/shenandoahSATBMode.cpp + src/share/vm/gc_implementation/shenandoah/mode/shenandoahSATBMode.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoah_globals.hpp ! test/gc/shenandoah/TestObjItrWithHeapDump.java ! test/gc/shenandoah/oom/TestClassLoaderLeak.java ! test/gc/shenandoah/options/TestModeUnlock.java Changeset: 6cb89922d316 Author: zgu Date: 2020-02-26 15:32 -0500 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/6cb89922d316 [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR Reviewed-by: shade, rkennke ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahBarrierSet.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahForwarding.inline.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahHeap.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.cpp ! src/share/vm/gc_implementation/shenandoah/shenandoahRootProcessor.hpp Changeset: eaee3264e9de Author: shade Date: 2020-05-20 16:52 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/eaee3264e9de Merge ! src/cpu/aarch64/vm/sharedRuntime_aarch64.cpp ! src/cpu/aarch64/vm/templateInterpreter_aarch64.cpp ! src/share/vm/c1/c1_Runtime1.cpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.cpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalAggressiveHeuristics.hpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.cpp - src/share/vm/gc_implementation/shenandoah/heuristics/shenandoahTraversalHeuristics.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahAllocTracker.hpp ! src/share/vm/gc_implementation/shenandoah/shenandoahGCTraceTime.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahHeuristics.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahMode.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahNormalMode.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahOopClosures.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahPassiveMode.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTimingTracker.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalGC.inline.hpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.cpp - src/share/vm/gc_implementation/shenandoah/shenandoahTraversalMode.hpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/unsafe.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/vm_operations.hpp Changeset: 541aec94edc5 Author: shade Date: 2020-05-20 17:59 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/541aec94edc5 Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset eaee3264e9de ! .hgtags From shade at redhat.com Wed May 20 18:50:18 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 20 May 2020 18:50:18 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset ed9df0d7db35 Message-ID: <202005201850.04KIoIJC025236@aojmv0008.oracle.com> Changeset: cd8fdbea1e81 Author: shade Date: 2020-05-20 20:46 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/cd8fdbea1e81 Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset ed9df0d7db35 ! .hgtags From shade at redhat.com Wed May 20 18:50:23 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 20 May 2020 18:50:23 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset 321ac97143cb Message-ID: <202005201850.04KIoNDs025406@aojmv0008.oracle.com> Changeset: e9c33bf08c2d Author: shade Date: 2020-05-20 20:46 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/e9c33bf08c2d Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset 321ac97143cb ! .hgtags From shade at redhat.com Wed May 20 18:50:20 2020 From: shade at redhat.com (shade at redhat.com) Date: Wed, 20 May 2020 18:50:20 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset 3defd1827494 Message-ID: <202005201850.04KIoKbc025368@aojmv0008.oracle.com> Changeset: 66e34278c58b Author: shade Date: 2020-05-20 20:46 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/66e34278c58b Added tag aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 for changeset 3defd1827494 ! .hgtags From ioi.lam at oracle.com Tue May 19 23:41:03 2020 From: ioi.lam at oracle.com (Ioi Lam) Date: Tue, 19 May 2020 16:41:03 -0700 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> Message-ID: <8bf736b3-9ab1-86b7-fd22-230e449b1b9f@oracle.com> Hi Thomas, The testing took a little longer than I expected. I've run your previous version: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ In our CI tiers 1/4. No failures. I didn't run your latest version. I would suggesting testing it with your own CI as well as in jdk-submit before pushing (after you get OKs from other reviewers). Thumbs up. - Ioi On 5/19/20 7:40 AM, Thomas St?fe wrote: > Hi guys, > > new webrev: > > full: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ > delta: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ > > Mostly format changes, breaking up at column 80 as Andrew requested. > > The only changes which matter is the removal of the unnecessary > include in arguments.cpp as Coleen suggested; and to not validate > SharedBaseAddress anymore at runtime, as Ioi requested. > > Also rebased to head. > > Thanks, Thomas > > > > > On Tue, May 19, 2020 at 6:38 AM Ioi Lam > wrote: > > > > On 5/18/20 7:37 AM, Thomas St?fe wrote: >> Hi all, >> >> fourth webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ >> >> I rebased atop of >> >> changeset: ? 59325:1ba9a9a3f948 >> summary: ? ? 8244433: Remove saving of RSP in >> Assembler::pusha_uncached() >> >> so, atop of "8241825: Make compressed oops and compressed class >> pointers independent (x86_64, PPC, S390)". >> >> The changes are very small this time, see notes below: >> >> @Ioi: >> >> >Hi Thomas, >> >> >I am running your patch in out CI pipeline now. Some comments: >> >> >[2] Does JDK-8243535 exist with the current jdk/jdk repo? >> >> I assigned JDK-8243535 to me and I'm working on a patch. But I >> would like to keep that separate from this work, since this patch >> is already large. And I would like to fix JDK-8243535 after this >> remodel patch has been pushed, which makes some minor things >> easier. That would leave a small time window where NMT does >> mis-track class space as shared class space, but that is not a >> big issue, it does not even disturb any test. Which in itself is >> something we may want to fix, come to think about it. >> >> >> > [3] I think this can be put in header file. >> > >> > bool Metaspace::class_space_is_initialized() { >> > ? return _class_space_list != NULL; >> > } >> >> Done. >> >> > [7] argument.cpp checks this: >> > >> > ? if (UseSharedSpaces || DumpSharedSpaces) { >> > ? ? if >> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) >> { >> > ? ? ? log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is >> invalid for this platform, option will be ignored.", >> > ?p2i((address)SharedBaseAddress)); >> > ? ? ? FLAG_SET_DEFAULT(SharedBaseAddress, >> default_SharedBaseAddress()); >> > ? ? } >> > ? } >> > >> > but initialize_dumptime_shared_and_meta_spaces aligns up the >> SharedBaseAddress before doing the assert. >> > >> > ? void >> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >> > ? ? assert(DumpSharedSpaces, "should be called for dump time >> only"); >> > >> > ? ? const size_t reserve_alignment = >> MetaspaceShared::reserved_space_alignment(); >> > ? ? char* shared_base = >> (char*)align_up((char*)SharedBaseAddress, reserve_alignment); >> > >> > ? #ifdef _LP64 >> > >> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >> "Sanity"); >> > >> > So theoretically shared_base may no longer be is_valid_base >> after the align_up. It probably won't happen, but I think the >> code will be > much clearer tofirst to align_up, then check for >> is_valid_base and reset to default, and finally assert. >> >> The problem with that is that at the time this coding runs >> os::init() did not yet run and we do not know yet allocation >> granularity. >> >> So I changed verification of SharedBaseAddress: I added the >> alignment as you suggested and moved it to a later time in VM >> initialization, to CDS initialization. >> > > Is the call to? check_SharedBaseAddress() necessary inside > MetaspaceShared::initialize_runtime_shared_and_meta_spaces()? > SharedBaseAddress is currently ignored at run time. Does your > patch change that behavior? > >> >[8] In >> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >> following block can be simplified: >> > >> > ?if (!_shared_rs.is_reserved()) { >> > ? ?// Get a reserved space anywhere if attaching at the >> SharedBaseAddress fails: >> > ? ?if (UseCompressedClassPointers) { >> > ? ? ?// If we need a compressed class space too, let the >> platform handle the reservation. >> > ? ? ?_shared_rs = >> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >> > ? ?} else { >> > ? ? ?// anywhere is fine. >> > ? ? ?_shared_rs = ReservedSpace(cds_total, reserve_alignment, >> false /* large */, (char*)NULL); >> > ? ?} >> > ?} >> > >> > ? ... if you change the declaration to: >> > >> > ?static ReservedSpace >> reserve_address_space_for_compressed_classes(size_t size) >> NOT_LP64({ return ReservedSpace();}); >> >> I'd like to avoid keep the method LP64 only, but I rewrote the >> section somewhat to be more clearer. >> > The new code looks good. > >> > [9] I think the #ifdef _LP64 is not necessary: >> > >> > #ifdef _LP64 >> > ? ? // Some sanity checks after reserving address spaces for >> archives and class space. >> > ? ? assert(archive_space_rs.is_reserved(), "Sanity"); >> > ? ? if (Metaspace::using_class_space()) { >> > ? ? ? // Class space must closely follow the archive space. >> Both spaces must be aligned correctly. >> > ? ? ? assert(class_space_rs.is_reserved(), "A class space >> should have been reserved"); >> > ? ? ? assert(class_space_rs.base() >= archive_space_rs.end(), >> "class space should follow the cds archive space"); >> > assert(is_aligned(archive_space_rs.base(), >> MetaspaceShared::reserved_space_alignment()), "Archive space >> misaligned"); >> > assert(is_aligned(class_space_rs.base(), >> Metaspace::reserve_alignment()), "class space misaligned"); >> > ? ? } >> > #endif >> >> I removed the #ifdef, but replaced it with an #ifdef ASSERT. >> Which is also not needed, technically, but makes it clear that >> this section is debugging checks only. >> > > OK. > > The rest of the code looks good to me. I am going to run your > latest patch in our CI and will report the results. > > Thanks > - Ioi >> ---- >> >> @Coleen: >> >> >http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/>virtualSpaceList.cpp.udiff.html >> > >> >Why did you make this change?? Shouldn't the caller align it? >> >> >> You are right, I removed the assert. >> >> --- >> >> Thanks all for your review work, >> >> ..Thomas >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, May 8, 2020 at 7:37 AM Ioi Lam > > wrote: >> >> Hi Thomas, >> >> I am running your patch in out CI pipeline now. Some comments: >> >> [1] Do we still need to use _class_space_list? It looks like >> we just have a single range. Is >> _class_space_list->current_virtual_space() always the same VS? >> >> ? if (_class_space_list != NULL) { >> ??? address base = >> (address)_class_space_list->current_virtual_space()->bottom(); >> ??? address top = base + compressed_class_space_size(); >> ??? st->print("Compressed class space mapped at: " PTR_FORMAT >> "-" PTR_FORMAT ", size: " SIZE_FORMAT, >> ?????????????? p2i(base), p2i(top), top - base); >> >> [2] Does JDK-8243535 exist with the current jdk/jdk repo? >> >> ? // This does currently not work because rs may be the >> result of a split operation >> ? // and NMT seems not to be able to handle splits. >> ? // See JDK-8243535. >> ? // >> MemTracker::record_virtual_memory_type((address)rs.base(), >> mtClass); >> >> >> [3] I think this can be put in header file. >> >> bool Metaspace::class_space_is_initialized() { >> ? return _class_space_list != NULL; >> } >> >> [4] Why does the CCS need to follow UseLargePagesInMetaspace? >> This is the reason for the >> ??? gap in the following chart: >> >> ??? // We do this by reserving space for the ccs behind the >> archives. Note however that >> ??? //? ccs follows a different alignment >> (Metaspace::reserve_alignment), so there may >> ??? //? be a gap between ccs and cds. >> ??? // We use a similar layout at runtime, see >> reserve_address_space_for_archives(). >> ??? // >> ??? //????????????????????????????? +-- SharedBaseAddress >> (default = 0x800000000) >> ??? //????????????????????????????? v >> ??? // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> ??? // |??? Heap??? | Archive |???? | MC | RW | RO | [gap]? >> |??? class space???? | >> ??? // +-..---------+---------+ ... >> +----+----+----+--------+--------------------+ >> ??? // |<--?? MaxHeapSize? -->|???? |<-- >> UnscaledClassSpaceMax = 4GB -->| >> >> >> _reserve_alignment is determined here: >> >> void Metaspace::ergo_initialize() { >> ? if (DumpSharedSpaces) { >> ??? // Using large pages when dumping the shared archive is >> currently not implemented. >> ??? FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >> ? } >> >> ? size_t page_size = os::vm_page_size(); >> ? if (UseLargePages && UseLargePagesInMetaspace) { >> ??? page_size = os::large_page_size(); >> ? } >> >> ? _commit_alignment? = page_size; >> ? _reserve_alignment = MAX2(page_size, >> (size_t)os::vm_allocation_granularity()); >> >> But when CDS is enabled, the RS is reserved without large >> pages, so it should be possible to incrementally commit the >> CCS using just os::vm_allocation_granularity(). >> >> [5] I see the aarch64 code in >> Metaspace::reserve_address_space_for_compressed_classes has >> been changed. Is this necessary for this RFE, or is it a >> separate improvement that can be done in a different RFE? >> >> [6] For AARCH64, should we skip the part that reserves it >> right above the heap? Or does AARCH64 always allocate the >> heap such that it's a preferable address? >> >> ??? // case (b) >> ??? ReservedSpace rs; >> >> ??? // Try right above the Java heap... >> ??? address base = align_up(CompressedOops::end(), >> Metaspace::reserve_alignment()); >> ??? assert(base != NULL, "Sanity"); >> >> ??? const size_t size = align_up(CompressedClassSpaceSize, >> Metaspace::reserve_alignment()); >> ??? if (CompressedKlassPointers::is_valid_base(base)) { >> ????? rs = ReservedSpace(size, >> Metaspace::reserve_alignment(), false /* large */, (char*)base); >> ??? } >> >> ??? // ...failing that, reserve anywhere, but let platform do >> optimized placement: >> ??? if (!rs.is_reserved()) { >> ????? rs = >> Metaspace::reserve_address_space_for_compressed_classes(size); >> ??? } >> >> [7] argument.cpp checks this: >> >> ? if (UseSharedSpaces || DumpSharedSpaces) { >> ??? if >> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) >> { >> ????? log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is >> invalid for this platform, option will be ignored.", >> p2i((address)SharedBaseAddress)); >> ????? FLAG_SET_DEFAULT(SharedBaseAddress, >> default_SharedBaseAddress()); >> ??? } >> ? } >> >> but initialize_dumptime_shared_and_meta_spaces aligns up the >> SharedBaseAddress before doing the assert. >> >> ? void >> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >> ??? assert(DumpSharedSpaces, "should be called for dump time >> only"); >> >> ??? const size_t reserve_alignment = >> MetaspaceShared::reserved_space_alignment(); >> ??? char* shared_base = >> (char*)align_up((char*)SharedBaseAddress, reserve_alignment); >> >> ? #ifdef _LP64 >> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >> "Sanity"); >> >> So theoretically shared_base may no longer be is_valid_base >> after the align_up. It probably won't happen, but I think the >> code will be much clearer tofirst to align_up, then check for >> is_valid_base and reset to default, and finally assert. >> >> [8] In >> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, >> the following block can be simplified: >> >> ? if (!_shared_rs.is_reserved()) { >> ??? // Get a reserved space anywhere if attaching at the >> SharedBaseAddress fails: >> ??? if (UseCompressedClassPointers) { >> ????? // If we need a compressed class space too, let the >> platform handle the reservation. >> ????? _shared_rs = >> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >> ??? } else { >> ????? // anywhere is fine. >> ????? _shared_rs = ReservedSpace(cds_total, >> reserve_alignment, false /* large */, (char*)NULL); >> ??? } >> ? } >> >> ?? ... if you change the declaration to: >> >> ? static ReservedSpace >> reserve_address_space_for_compressed_classes(size_t size) >> NOT_LP64({ return ReservedSpace();}); >> >> [9] I think the #ifdef _LP64 is not necessary: >> >> #ifdef _LP64 >> ??? // Some sanity checks after reserving address spaces for >> archives and class space. >> ??? assert(archive_space_rs.is_reserved(), "Sanity"); >> ??? if (Metaspace::using_class_space()) { >> ????? // Class space must closely follow the archive space. >> Both spaces must be aligned correctly. >> ????? assert(class_space_rs.is_reserved(), "A class space >> should have been reserved"); >> ????? assert(class_space_rs.base() >= archive_space_rs.end(), >> "class space should follow the cds archive space"); >> ????? assert(is_aligned(archive_space_rs.base(), >> MetaspaceShared::reserved_space_alignment()), "Archive space >> misaligned"); >> ????? assert(is_aligned(class_space_rs.base(), >> Metaspace::reserve_alignment()), "class space misaligned"); >> ??? } >> #endif >> >> The rest of the code looks OK to me, but I may take a look at >> it again after getting more sleep :-) >> >> Thanks >> - Ioi >> >> >> >> >> On 5/7/20 7:21 AM, Thomas St?fe wrote: >>> Hi all, >>> >>> please take a look at the third iteration of this change: >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >>> >>> Changes in this version: >>> >>> - at the request of Coleen (sorry I did not see your post >>> earlier) I removed all platform dependent?files and put the >>> platform dependent coding back to metaspace.cpp and >>> compressedOops.cpp to ease the review pain. I used plain >>> platform defines though (#ifdef AARCH64) instead of hiding >>> them behind another macro to make things clearer. Note that >>> I still intent to put this code away into the platform >>> corners but will do so in a follow up RFE. >>> >>> - I reinstated, in a fashion, the special handling of >>> reservations on Windows. On all platforms we reserve address >>> space to map the archive files in with a subsequent mapping >>> operation. However, on Windows, we cannot use >>> MapViewOfFile() into an existing mapping. So I remove the >>> mapping again before mapping the archives - see comment in >>> code for details. >>> >>> All CI tests at SAP run through without problems, including >>> on Win64 and aarch64, but I would be happy if others were to >>> run test too. >>> >>> Thank you, Thomas >>> >>> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >>> > >>> wrote: >>> >>> Hi all, >>> >>> Could I have reviews for the following proposal of >>> reworking cds/class space reservation? >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >>> >>> (Many thanks to Ioi Lam for so patiently explaining CDS >>> internals to me, and to Andrew Haley and Nick Gasson for >>> help with aarch64!) >>> >>> Reservation of the compressed class space is needlessly >>> complicated and has some minor issues. It can be >>> simplified and made clearer. >>> >>> The complexity stems from the fact that this area lives >>> at the intersection of two to three sub systems, >>> depending on how one counts. Metaspace, CDS, and the >>> platform which may or may not its own view of how to >>> reserve class space. And this code has been growing >>> organically over time. >>> >>> One small example: >>> >>> ReservedSpace Metaspace::reserve_preferred_space(size_t >>> size, size_t alignment, >>> ? ? ? ?bool large_pages, char *requested_addr, >>> ? ? ? ?bool use_requested_addr) >>> >>> which I spent hours decoding, resulting in a very >>> confused mail to hs-runtime and aarch64-port-dev [2]. >>> >>> This patch attempts to simplify cds and metaspace setup >>> a bit; to comment implicit knowledge which is not >>> immediately clear; to cleanly abstract platform concerns >>> like optimized class space placement; and to disentangle >>> cds from metaspace to solve issues which may bite us >>> later with Elastic Metaspace [4]. >>> >>> --- >>> >>> The main change is the reworked reservation mechanism. >>> This is based on Ioi's proposal [5]. >>> >>> When reserving class space, three things must happen: >>> >>> 1) reservation of the space obviously. If cds is active >>> that space must be in the vicinity of cds archives to be >>> covered by compressed class pointer encoding. >>> 2) setting up the internal Metaspace structures atop of >>> that space >>> 3) setting up compressed class pointer encoding. >>> >>> In its current form, Metaspace may or may not do some or >>> all of that in one function >>> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>> metaspace_rs, char* requested_addr, address cds_base);) >>> - if cds is active, it will reserve the space for >>> Metaspace and hand it in, otherwise it will create it >>> itself. >>> >>> When discussing this in [2], Ioi proposed to move the >>> reservation of the class space completely out of >>> Metaspace and make it a responsibility of the caller >>> always. This would reduce some complexity, and this >>> patch follows the proposal. >>> >>> I removed >>> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>> metaspace_rs, char* requested_addr, address cds_base); >>> and all its sub functions. >>> >>> (1) now has to always be done outside - a ReservedSpace >>> for class space has to be provided by the caller. >>> However, Metaspace now offers a utility function for >>> reserving space at a "nice" location, and explicitly >>> doing nothing else: >>> >>> ReservedSpace >>> Metaspace::reserve_address_space_for_compressed_classes(size_t >>> size); >>> >>> this function can be redefined on a platform level for >>> platform optimized reservation, see below for details. >>> >>> (2) is taken care of by a new function, >>> Metaspace::initialize_class_space(ReservedSpace rs) >>> >>> (3) is taken care of a new function >>> CompressedKlassPointers::initialize(), see below for >>> details. >>> >>> >>> So, class space now is set up three explicit steps: >>> >>> - First, reserve a suitable space by however means you >>> want. For convenience you may use >>> Metaspace::reserve_address_space_for_compressed_classes(), >>> or you may roll your own reservation. >>> - Next, tell Metaspace to use that range as backing >>> storage for class space: >>> Metaspace::initialize_class_space(ReservedSpace rs) >>> - Finally, set up encoding. Encoding is independent from >>> the concept of a ReservedSpace, it just gets an address >>> range, see below for details. >>> >>> Separating these steps and moving them out of the >>> responsibility of Metaspace makes this whole thing more >>> flexible; it also removes unnecessary knowledge (e.g. >>> Metaspace does not need to know anything about either >>> ccp encoding or cds). >>> >>> --- >>> >>> How it comes together: >>> >>> If CDS is off, we just reserve a space using >>> Metaspace::reserve_address_space_for_compressed_classes(), >>> initialize it with >>> Metaspace::initialize_class_space(ReservedSpace rs), >>> then set up compressed class pointer encoding covering >>> the range of this class space. >>> >>> If CDS is on (dump time), we reserve large 4G space, >>> either at SharedBaseAddress or using >>> Metaspace::reserve_address_space_for_compressed_classes(); >>> we then split that into 3G archive space and 1G class >>> space; we set up that space with Metaspace as class >>> space; then we set up?compressed class pointer encoding >>> covering both archive space and cds. >>> >>> If CDS is on (run time), we reserve a large space, split >>> it into archive space (large enough to hold both >>> archives) and class space, then basically proceed as above. >>> >>> Note that this is almost exactly how things worked >>> before (modulo some minor fixes, e.g. alignment issues), >>> only the code is reformed and made more explicit. >>> >>> --- >>> >>> I moved compressed class pointer setup over to >>> CompressedKlassPointers and changed the interface: >>> >>> -void >>> Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >>> metaspace_rs, address cds_base) >>> +void CompressedKlassPointers::initialize(address addr, >>> size_t len); >>> >>> Instead of feeding it a single ReservedSpace, which is >>> supposed to represent class space, and an optional >>> alternate base if cds is on, now we give it just an >>> numeric address range. That range marks the limits to >>> where Klass structures are to be expected, and is the >>> implicit promise that outside that range no Klass >>> structures will exist, so encoding has to cover only >>> this range. >>> >>> This range may contain just the class space; or class >>> space+cds; or whatever allocation scheme we come up with >>> in the future. Encoding does not really care how the >>> memory is organized as long as the input range covers >>> all possible Klass locations. That way we remove >>> knowledge about class space/cds from compressed class >>> pointer encoding. >>> >>> Moving it away from metaspace.cpp into the >>> CompressedKlassPointers class also mirrors >>> CompressedOops::initialize(). >>> >>> --- >>> >>> I renamed _narrow_klass_range to just _range, because >>> strictly speaking this is the range un-narrow Klass >>> pointers can have. >>> >>> As for the implementation of >>> CompressedKlassPointers::initialize(address addr, size_t >>> len), I mimicked very closely what happened before, so >>> there should be almost no differences. Since "almost no >>> differences" sounds scary :) here are the differences: >>> >>> - When CDS is active (dump or run time) we now always, >>> unconditionally, set the encoding range to 4G. This >>> fixes a theoretical bug discussed on aarch64-port-dev [1]. >>> >>> - When CDS is not active, we set the encoding range to >>> the minimum required length. Before, it was left at its >>> default value of 4G. >>> >>> Both differences only affect aarch64, since they are >>> currently the only one using the range field in >>> CompressedKlassPointers. >>> >>> I wanted to add an assert somewhere to test encoding of >>> the very last address of the CompressedKlassPointers >>> range, again to prevent errors like [3]. But I did not >>> come up with a good place for this assert which would >>> cover also the encoding done by C1/C2. >>> >>> For the same reason I thought about introducing a mode >>> where Klass structures would be allocated in reverse >>> order, starting at the end of the ccs, but again left it >>> out as too big a change. >>> >>> --- >>> >>> OS abstraction: platforms may have restrictions of what >>> constitutes a valid compressed class pointer encoding >>> base. Or if not, they may have at least preferences. >>> There was logic like this in metaspace.cpp, which I >>> removed and cleanly factored out into platform dependent >>> files, giving each platform the option to add special logic. >>> >>> These are two new methods: >>> >>> - bool CompressedKlassPointers::is_valid_base(address p) >>> >>> to let the platform tell you whether it considers p to >>> be a valid encoding base. The only platform having these >>> restrictions currently is aarch64. >>> >>> - ReservedSpace >>> Metaspace::reserve_address_space_for_compressed_classes(size_t >>> size); >>> >>> this hands over the process of allocating a range >>> suitable for compressed class pointer encoding to the >>> platform. Most platforms will allocate just anywhere, >>> but some platforms may have a better strategy (e.g. >>> trying low memory first, trying only correctly aligned >>> addresses and so on). >>> >>> Beforehand, this coding existed in a similar form in >>> metaspace.cpp for aarch64 and AIX. For now, I left the >>> AIX part out - it seems only half done, and I want to >>> check further if we even need it, if yes why not on >>> Linux ppc, and C1 does not seem to support anything >>> other than base+offset with shift either, but I may be >>> mistaken. >>> >>> These two methods should give the platform enough >>> control to implement their own scheme for optimized >>> class space placement without bothering any shared code >>> about it. >>> >>> Note about the form, I introduced two new platform >>> dependent files, "metaspace_.cpp" and >>> "compressedOops_.cpp". I am not happy about this >>> but this seems to be what we generally do in hotspot, right? >>> >>> --- >>> >>> Metaspace reserve alignment vs cds alignment >>> >>> CDS was using Metaspace reserve alignment for CDS >>> internal purposes. I guess this was just a copy paste >>> issue. It never caused problems since Metaspace reserve >>> alignment == page size, but that is not true anymore in >>> the upcoming Elastic Metaspace where reserve alignment >>> will be larger. This causes a number of issues. >>> >>> I separated those two cleanly. CDS now uses >>> os::vm_allocation_granularity. >>> Metaspace::reserve_alignment is only used in those two >>> places where it is needed, when CDS creates the address >>> space for class space on behalf of the Metaspace. >>> >>> --- >>> >>> Windows special handling in CDS >>> >>> To simplify coding I removed the windows specific >>> handling which left out reservation of the archive. This >>> was needed because windows cannot mmap files into >>> reserved regions. But fallback code exists in >>> filemap.cpp for this case which just reads in the region >>> instead of mapping?it. >>> >>> Should that turn out to be a performance problem, I will >>> reinstate the feature. But a simpler way would be >>> reserve the archive and later just before mmapping?the >>> archive file to release the archive space. That would >>> not only be simpler but give us the best guarantee that >>> that address space is actually available. But I'd be >>> happy to leave that part out completely if we do not see >>> any performance problems on windows x64. >>> >>> --- >>> >>> NMT cannot deal with spaces which are split. This >>> problem manifests in that bookkeeping for class space is >>> done under "Shared Classes", not "Classes" as it should. >>> This problem exists today too at dump?time and randomly >>> at run time. But since I simplified the reservation, >>> this problem now shows up always, whether or not we map >>> at the SharedBaseAddress. >>> While I could work around this problem, I'd prefer this >>> problem to be solved at the core, and NMT to have an >>> option to recognize reservation splits. So I'd rather >>> not put a workaround for this into the patch but leave >>> it for fixing as a separate issue. I opened this issue >>> to track it [6]. >>> >>> --- >>> >>> Jtreg tests: >>> >>> I expanded the >>> CompressedOops/CompressedClassPointers.java. I also >>> extended them to Windows. The tests now optionally omit >>> strict class space placement tests, since these tests >>> heavily depend on ASLR and were the reason they were >>> excluded on Windows. However I think even without >>> checking for class space placement they make sense, just >>> to see that the VM comes up and lives with the many >>> different settings we can run in. >>> >>> --- >>> >>> Tests: >>> >>> - I ran the patch through Oracles submit repo >>> - I ran tests manually for aarch64, zero, linux 32bit >>> and windows x64 >>> - The whole battery of nightly tests at SAP, including >>> ppc, ppcle and aarch64, unfortunately excluding windows >>> because of unrelated errors. Windows x64 tests will be >>> redone tonight. >>> >>> >>> Thank you, >>> >>> Thomas >>> >>> [1] >>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >>> [2] >>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >>> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >>> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >>> [5] >>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >>> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >>> >> > From thomas.stuefe at gmail.com Thu May 21 06:26:31 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 21 May 2020 08:26:31 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: <8bf736b3-9ab1-86b7-fd22-230e449b1b9f@oracle.com> References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> <8bf736b3-9ab1-86b7-fd22-230e449b1b9f@oracle.com> Message-ID: Hi all, tests went through successfully at SAP two nights in a row. Ioi gave his okay, and I would like to push today or tomorrow. Any remaining objections`? The current, final version is: full: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ delta: http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ Thank you, Thomas On Wed, May 20, 2020 at 1:43 AM Ioi Lam wrote: > Hi Thomas, > > The testing took a little longer than I expected. I've run your previous > version: > > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ > > In our CI tiers 1/4. No failures. > > I didn't run your latest version. I would suggesting testing it with your > own CI as well as in jdk-submit before pushing (after you get OKs from > other reviewers). > > Thumbs up. > - Ioi > > > On 5/19/20 7:40 AM, Thomas St?fe wrote: > > Hi guys, > > new webrev: > > full: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ > delta: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ > > Mostly format changes, breaking up at column 80 as Andrew requested. > > The only changes which matter is the removal of the unnecessary include in > arguments.cpp as Coleen suggested; and to not validate SharedBaseAddress > anymore at runtime, as Ioi requested. > > Also rebased to head. > > Thanks, Thomas > > > > > On Tue, May 19, 2020 at 6:38 AM Ioi Lam wrote: > >> >> >> On 5/18/20 7:37 AM, Thomas St?fe wrote: >> >> Hi all, >> >> fourth webrev: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ >> >> I rebased atop of >> >> changeset: 59325:1ba9a9a3f948 >> summary: 8244433: Remove saving of RSP in Assembler::pusha_uncached() >> >> so, atop of "8241825: Make compressed oops and compressed class pointers >> independent (x86_64, PPC, S390)". >> >> The changes are very small this time, see notes below: >> >> @Ioi: >> >> >Hi Thomas, >> >> >I am running your patch in out CI pipeline now. Some comments: >> >> >[2] Does JDK-8243535 exist with the current jdk/jdk repo? >> >> I assigned JDK-8243535 to me and I'm working on a patch. But I would like >> to keep that separate from this work, since this patch is already large. >> And I would like to fix JDK-8243535 after this remodel patch has been >> pushed, which makes some minor things easier. That would leave a small time >> window where NMT does mis-track class space as shared class space, but that >> is not a big issue, it does not even disturb any test. Which in itself is >> something we may want to fix, come to think about it. >> >> >> > [3] I think this can be put in header file. >> > >> > bool Metaspace::class_space_is_initialized() { >> > return _class_space_list != NULL; >> > } >> >> Done. >> >> > [7] argument.cpp checks this: >> > >> > if (UseSharedSpaces || DumpSharedSpaces) { >> > if >> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >> > log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for >> this platform, option will be ignored.", >> > p2i((address)SharedBaseAddress)); >> > FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >> > } >> > } >> > >> > but initialize_dumptime_shared_and_meta_spaces aligns up the >> SharedBaseAddress before doing the assert. >> > >> > void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >> > assert(DumpSharedSpaces, "should be called for dump time only"); >> > >> > const size_t reserve_alignment = >> MetaspaceShared::reserved_space_alignment(); >> > char* shared_base = (char*)align_up((char*)SharedBaseAddress, >> reserve_alignment); >> > >> > #ifdef _LP64 >> > >> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >> "Sanity"); >> > >> > So theoretically shared_base may no longer be is_valid_base after the >> align_up. It probably won't happen, but I think the code will be > much >> clearer tofirst to align_up, then check for is_valid_base and reset to >> default, and finally assert. >> >> The problem with that is that at the time this coding runs os::init() did >> not yet run and we do not know yet allocation granularity. >> >> So I changed verification of SharedBaseAddress: I added the alignment as >> you suggested and moved it to a later time in VM initialization, to CDS >> initialization. >> >> >> Is the call to check_SharedBaseAddress() necessary inside >> MetaspaceShared::initialize_runtime_shared_and_meta_spaces()? >> SharedBaseAddress is currently ignored at run time. Does your patch change >> that behavior? >> >> >[8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >> following block can be simplified: >> > >> > if (!_shared_rs.is_reserved()) { >> > // Get a reserved space anywhere if attaching at the >> SharedBaseAddress fails: >> > if (UseCompressedClassPointers) { >> > // If we need a compressed class space too, let the platform >> handle the reservation. >> > _shared_rs = >> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >> > } else { >> > // anywhere is fine. >> > _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >> large */, (char*)NULL); >> > } >> > } >> > >> > ... if you change the declaration to: >> > >> > static ReservedSpace >> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >> ReservedSpace();}); >> >> I'd like to avoid keep the method LP64 only, but I rewrote the section >> somewhat to be more clearer. >> >> The new code looks good. >> >> > [9] I think the #ifdef _LP64 is not necessary: >> > >> > #ifdef _LP64 >> > // Some sanity checks after reserving address spaces for archives >> and class space. >> > assert(archive_space_rs.is_reserved(), "Sanity"); >> > if (Metaspace::using_class_space()) { >> > // Class space must closely follow the archive space. Both spaces >> must be aligned correctly. >> > assert(class_space_rs.is_reserved(), "A class space should have >> been reserved"); >> > assert(class_space_rs.base() >= archive_space_rs.end(), "class >> space should follow the cds archive space"); >> > assert(is_aligned(archive_space_rs.base(), >> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >> > assert(is_aligned(class_space_rs.base(), >> Metaspace::reserve_alignment()), "class space misaligned"); >> > } >> > #endif >> >> I removed the #ifdef, but replaced it with an #ifdef ASSERT. Which is >> also not needed, technically, but makes it clear that this section is >> debugging checks only. >> >> >> OK. >> >> The rest of the code looks good to me. I am going to run your latest >> patch in our CI and will report the results. >> >> Thanks >> - Ioi >> >> ---- >> >> @Coleen: >> >> > >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/ >> >virtualSpaceList.cpp.udiff.html >> > >> >Why did you make this change? Shouldn't the caller align it? >> >> >> You are right, I removed the assert. >> >> --- >> >> Thanks all for your review work, >> >> ..Thomas >> >> >> >> >> >> >> >> >> >> >> >> >> On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: >> >>> Hi Thomas, >>> >>> I am running your patch in out CI pipeline now. Some comments: >>> >>> [1] Do we still need to use _class_space_list? It looks like we just >>> have a single range. Is _class_space_list->current_virtual_space() always >>> the same VS? >>> >>> if (_class_space_list != NULL) { >>> address base = >>> (address)_class_space_list->current_virtual_space()->bottom(); >>> address top = base + compressed_class_space_size(); >>> st->print("Compressed class space mapped at: " PTR_FORMAT "-" >>> PTR_FORMAT ", size: " SIZE_FORMAT, >>> p2i(base), p2i(top), top - base); >>> >>> [2] Does JDK-8243535 exist with the current jdk/jdk repo? >>> >>> // This does currently not work because rs may be the result of a >>> split operation >>> // and NMT seems not to be able to handle splits. >>> // See JDK-8243535. >>> // MemTracker::record_virtual_memory_type((address)rs.base(), mtClass); >>> >>> >>> [3] I think this can be put in header file. >>> >>> bool Metaspace::class_space_is_initialized() { >>> return _class_space_list != NULL; >>> } >>> >>> [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is >>> the reason for the >>> gap in the following chart: >>> >>> // We do this by reserving space for the ccs behind the archives. >>> Note however that >>> // ccs follows a different alignment >>> (Metaspace::reserve_alignment), so there may >>> // be a gap between ccs and cds. >>> // We use a similar layout at runtime, see >>> reserve_address_space_for_archives(). >>> // >>> // +-- SharedBaseAddress (default = >>> 0x800000000) >>> // v >>> // +-..---------+---------+ ... >>> +----+----+----+--------+--------------------+ >>> // | Heap | Archive | | MC | RW | RO | [gap] | class >>> space | >>> // +-..---------+---------+ ... >>> +----+----+----+--------+--------------------+ >>> // |<-- MaxHeapSize -->| |<-- UnscaledClassSpaceMax = 4GB -->| >>> >>> >>> _reserve_alignment is determined here: >>> >>> void Metaspace::ergo_initialize() { >>> if (DumpSharedSpaces) { >>> // Using large pages when dumping the shared archive is currently >>> not implemented. >>> FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >>> } >>> >>> size_t page_size = os::vm_page_size(); >>> if (UseLargePages && UseLargePagesInMetaspace) { >>> page_size = os::large_page_size(); >>> } >>> >>> _commit_alignment = page_size; >>> _reserve_alignment = MAX2(page_size, >>> (size_t)os::vm_allocation_granularity()); >>> >>> But when CDS is enabled, the RS is reserved without large pages, so it >>> should be possible to incrementally commit the CCS using just >>> os::vm_allocation_granularity(). >>> >>> [5] I see the aarch64 code in >>> Metaspace::reserve_address_space_for_compressed_classes has been changed. >>> Is this necessary for this RFE, or is it a separate improvement that can be >>> done in a different RFE? >>> >>> [6] For AARCH64, should we skip the part that reserves it right above >>> the heap? Or does AARCH64 always allocate the heap such that it's a >>> preferable address? >>> >>> // case (b) >>> ReservedSpace rs; >>> >>> // Try right above the Java heap... >>> address base = align_up(CompressedOops::end(), >>> Metaspace::reserve_alignment()); >>> assert(base != NULL, "Sanity"); >>> >>> const size_t size = align_up(CompressedClassSpaceSize, >>> Metaspace::reserve_alignment()); >>> if (CompressedKlassPointers::is_valid_base(base)) { >>> rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* >>> large */, (char*)base); >>> } >>> >>> // ...failing that, reserve anywhere, but let platform do optimized >>> placement: >>> if (!rs.is_reserved()) { >>> rs = Metaspace::reserve_address_space_for_compressed_classes(size); >>> } >>> >>> [7] argument.cpp checks this: >>> >>> if (UseSharedSpaces || DumpSharedSpaces) { >>> if >>> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >>> log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for >>> this platform, option will be ignored.", >>> p2i((address)SharedBaseAddress)); >>> FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >>> } >>> } >>> >>> but initialize_dumptime_shared_and_meta_spaces aligns up the >>> SharedBaseAddress before doing the assert. >>> >>> void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >>> assert(DumpSharedSpaces, "should be called for dump time only"); >>> >>> const size_t reserve_alignment = >>> MetaspaceShared::reserved_space_alignment(); >>> char* shared_base = (char*)align_up((char*)SharedBaseAddress, >>> reserve_alignment); >>> >>> #ifdef _LP64 >>> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >>> "Sanity"); >>> >>> So theoretically shared_base may no longer be is_valid_base after the >>> align_up. It probably won't happen, but I think the code will be much >>> clearer tofirst to align_up, then check for is_valid_base and reset to >>> default, and finally assert. >>> >>> [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >>> following block can be simplified: >>> >>> if (!_shared_rs.is_reserved()) { >>> // Get a reserved space anywhere if attaching at the >>> SharedBaseAddress fails: >>> if (UseCompressedClassPointers) { >>> // If we need a compressed class space too, let the platform >>> handle the reservation. >>> _shared_rs = >>> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >>> } else { >>> // anywhere is fine. >>> _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >>> large */, (char*)NULL); >>> } >>> } >>> >>> ... if you change the declaration to: >>> >>> static ReservedSpace >>> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >>> ReservedSpace();}); >>> >>> [9] I think the #ifdef _LP64 is not necessary: >>> >>> #ifdef _LP64 >>> // Some sanity checks after reserving address spaces for archives >>> and class space. >>> assert(archive_space_rs.is_reserved(), "Sanity"); >>> if (Metaspace::using_class_space()) { >>> // Class space must closely follow the archive space. Both spaces >>> must be aligned correctly. >>> assert(class_space_rs.is_reserved(), "A class space should have >>> been reserved"); >>> assert(class_space_rs.base() >= archive_space_rs.end(), "class >>> space should follow the cds archive space"); >>> assert(is_aligned(archive_space_rs.base(), >>> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >>> assert(is_aligned(class_space_rs.base(), >>> Metaspace::reserve_alignment()), "class space misaligned"); >>> } >>> #endif >>> >>> The rest of the code looks OK to me, but I may take a look at it again >>> after getting more sleep :-) >>> >>> Thanks >>> - Ioi >>> >>> >>> >>> >>> On 5/7/20 7:21 AM, Thomas St?fe wrote: >>> >>> Hi all, >>> >>> please take a look at the third iteration of this change: >>> >>> >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >>> >>> Changes in this version: >>> >>> - at the request of Coleen (sorry I did not see your post earlier) I >>> removed all platform dependent files and put the platform dependent coding >>> back to metaspace.cpp and compressedOops.cpp to ease the review pain. I >>> used plain platform defines though (#ifdef AARCH64) instead of hiding them >>> behind another macro to make things clearer. Note that I still intent to >>> put this code away into the platform corners but will do so in a follow up >>> RFE. >>> >>> - I reinstated, in a fashion, the special handling of reservations on >>> Windows. On all platforms we reserve address space to map the archive files >>> in with a subsequent mapping operation. However, on Windows, we cannot use >>> MapViewOfFile() into an existing mapping. So I remove the mapping again >>> before mapping the archives - see comment in code for details. >>> >>> All CI tests at SAP run through without problems, including on Win64 and >>> aarch64, but I would be happy if others were to run test too. >>> >>> Thank you, Thomas >>> >>> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >>> wrote: >>> >>>> Hi all, >>>> >>>> Could I have reviews for the following proposal of reworking cds/class >>>> space reservation? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >>>> >>>> (Many thanks to Ioi Lam for so patiently explaining CDS internals to >>>> me, and to Andrew Haley and Nick Gasson for help with aarch64!) >>>> >>>> Reservation of the compressed class space is needlessly complicated and >>>> has some minor issues. It can be simplified and made clearer. >>>> >>>> The complexity stems from the fact that this area lives at the >>>> intersection of two to three sub systems, depending on how one counts. >>>> Metaspace, CDS, and the platform which may or may not its own view of how >>>> to reserve class space. And this code has been growing organically over >>>> time. >>>> >>>> One small example: >>>> >>>> ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t >>>> alignment, >>>> bool large_pages, char >>>> *requested_addr, >>>> bool >>>> use_requested_addr) >>>> >>>> which I spent hours decoding, resulting in a very confused mail to >>>> hs-runtime and aarch64-port-dev [2]. >>>> >>>> This patch attempts to simplify cds and metaspace setup a bit; to >>>> comment implicit knowledge which is not immediately clear; to cleanly >>>> abstract platform concerns like optimized class space placement; and to >>>> disentangle cds from metaspace to solve issues which may bite us later with >>>> Elastic Metaspace [4]. >>>> >>>> --- >>>> >>>> The main change is the reworked reservation mechanism. This is based on >>>> Ioi's proposal [5]. >>>> >>>> When reserving class space, three things must happen: >>>> >>>> 1) reservation of the space obviously. If cds is active that space must >>>> be in the vicinity of cds archives to be covered by compressed class >>>> pointer encoding. >>>> 2) setting up the internal Metaspace structures atop of that space >>>> 3) setting up compressed class pointer encoding. >>>> >>>> In its current form, Metaspace may or may not do some or all of that in >>>> one function >>>> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>> metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, >>>> it will reserve the space for Metaspace and hand it in, otherwise it will >>>> create it itself. >>>> >>>> When discussing this in [2], Ioi proposed to move the reservation of >>>> the class space completely out of Metaspace and make it a responsibility of >>>> the caller always. This would reduce some complexity, and this patch >>>> follows the proposal. >>>> >>>> I removed >>>> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>> metaspace_rs, char* requested_addr, address cds_base); and all its sub >>>> functions. >>>> >>>> (1) now has to always be done outside - a ReservedSpace for class space >>>> has to be provided by the caller. However, Metaspace now offers a utility >>>> function for reserving space at a "nice" location, and explicitly doing >>>> nothing else: >>>> >>>> ReservedSpace >>>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>>> >>>> this function can be redefined on a platform level for platform >>>> optimized reservation, see below for details. >>>> >>>> (2) is taken care of by a new function, >>>> Metaspace::initialize_class_space(ReservedSpace rs) >>>> >>>> (3) is taken care of a new function >>>> CompressedKlassPointers::initialize(), see below for details. >>>> >>>> >>>> So, class space now is set up three explicit steps: >>>> >>>> - First, reserve a suitable space by however means you want. For >>>> convenience you may use >>>> Metaspace::reserve_address_space_for_compressed_classes(), or you may roll >>>> your own reservation. >>>> - Next, tell Metaspace to use that range as backing storage for class >>>> space: Metaspace::initialize_class_space(ReservedSpace rs) >>>> - Finally, set up encoding. Encoding is independent from the concept of >>>> a ReservedSpace, it just gets an address range, see below for details. >>>> >>>> Separating these steps and moving them out of the responsibility of >>>> Metaspace makes this whole thing more flexible; it also removes unnecessary >>>> knowledge (e.g. Metaspace does not need to know anything about either ccp >>>> encoding or cds). >>>> >>>> --- >>>> >>>> How it comes together: >>>> >>>> If CDS is off, we just reserve a space using >>>> Metaspace::reserve_address_space_for_compressed_classes(), initialize it >>>> with Metaspace::initialize_class_space(ReservedSpace rs), then set up >>>> compressed class pointer encoding covering the range of this class space. >>>> >>>> If CDS is on (dump time), we reserve large 4G space, either at >>>> SharedBaseAddress or using >>>> Metaspace::reserve_address_space_for_compressed_classes(); we then split >>>> that into 3G archive space and 1G class space; we set up that space with >>>> Metaspace as class space; then we set up compressed class pointer encoding >>>> covering both archive space and cds. >>>> >>>> If CDS is on (run time), we reserve a large space, split it into >>>> archive space (large enough to hold both archives) and class space, then >>>> basically proceed as above. >>>> >>>> Note that this is almost exactly how things worked before (modulo some >>>> minor fixes, e.g. alignment issues), only the code is reformed and made >>>> more explicit. >>>> >>>> --- >>>> >>>> I moved compressed class pointer setup over to CompressedKlassPointers >>>> and changed the interface: >>>> >>>> -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >>>> metaspace_rs, address cds_base) >>>> +void CompressedKlassPointers::initialize(address addr, size_t len); >>>> >>>> Instead of feeding it a single ReservedSpace, which is supposed to >>>> represent class space, and an optional alternate base if cds is on, now we >>>> give it just an numeric address range. That range marks the limits to where >>>> Klass structures are to be expected, and is the implicit promise that >>>> outside that range no Klass structures will exist, so encoding has to cover >>>> only this range. >>>> >>>> This range may contain just the class space; or class space+cds; or >>>> whatever allocation scheme we come up with in the future. Encoding does not >>>> really care how the memory is organized as long as the input range covers >>>> all possible Klass locations. That way we remove knowledge about class >>>> space/cds from compressed class pointer encoding. >>>> >>>> Moving it away from metaspace.cpp into the CompressedKlassPointers >>>> class also mirrors CompressedOops::initialize(). >>>> >>>> --- >>>> >>>> I renamed _narrow_klass_range to just _range, because strictly speaking >>>> this is the range un-narrow Klass pointers can have. >>>> >>>> As for the implementation of >>>> CompressedKlassPointers::initialize(address addr, size_t len), I mimicked >>>> very closely what happened before, so there should be almost no >>>> differences. Since "almost no differences" sounds scary :) here are the >>>> differences: >>>> >>>> - When CDS is active (dump or run time) we now always, unconditionally, >>>> set the encoding range to 4G. This fixes a theoretical bug discussed on >>>> aarch64-port-dev [1]. >>>> >>>> - When CDS is not active, we set the encoding range to the minimum >>>> required length. Before, it was left at its default value of 4G. >>>> >>>> Both differences only affect aarch64, since they are currently the only >>>> one using the range field in CompressedKlassPointers. >>>> >>>> I wanted to add an assert somewhere to test encoding of the very last >>>> address of the CompressedKlassPointers range, again to prevent errors like >>>> [3]. But I did not come up with a good place for this assert which would >>>> cover also the encoding done by C1/C2. >>>> >>>> For the same reason I thought about introducing a mode where Klass >>>> structures would be allocated in reverse order, starting at the end of the >>>> ccs, but again left it out as too big a change. >>>> >>>> --- >>>> >>>> OS abstraction: platforms may have restrictions of what constitutes a >>>> valid compressed class pointer encoding base. Or if not, they may have at >>>> least preferences. There was logic like this in metaspace.cpp, which I >>>> removed and cleanly factored out into platform dependent files, giving each >>>> platform the option to add special logic. >>>> >>>> These are two new methods: >>>> >>>> - bool CompressedKlassPointers::is_valid_base(address p) >>>> >>>> to let the platform tell you whether it considers p to be a valid >>>> encoding base. The only platform having these restrictions currently is >>>> aarch64. >>>> >>>> - ReservedSpace >>>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>>> >>>> this hands over the process of allocating a range suitable for >>>> compressed class pointer encoding to the platform. Most platforms will >>>> allocate just anywhere, but some platforms may have a better strategy (e.g. >>>> trying low memory first, trying only correctly aligned addresses and so >>>> on). >>>> >>>> Beforehand, this coding existed in a similar form in metaspace.cpp for >>>> aarch64 and AIX. For now, I left the AIX part out - it seems only half >>>> done, and I want to check further if we even need it, if yes why not on >>>> Linux ppc, and C1 does not seem to support anything other than base+offset >>>> with shift either, but I may be mistaken. >>>> >>>> These two methods should give the platform enough control to implement >>>> their own scheme for optimized class space placement without bothering any >>>> shared code about it. >>>> >>>> Note about the form, I introduced two new platform dependent files, >>>> "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about >>>> this but this seems to be what we generally do in hotspot, right? >>>> >>>> --- >>>> >>>> Metaspace reserve alignment vs cds alignment >>>> >>>> CDS was using Metaspace reserve alignment for CDS internal purposes. I >>>> guess this was just a copy paste issue. It never caused problems since >>>> Metaspace reserve alignment == page size, but that is not true anymore in >>>> the upcoming Elastic Metaspace where reserve alignment will be larger. This >>>> causes a number of issues. >>>> >>>> I separated those two cleanly. CDS now uses >>>> os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in >>>> those two places where it is needed, when CDS creates the address space for >>>> class space on behalf of the Metaspace. >>>> >>>> --- >>>> >>>> Windows special handling in CDS >>>> >>>> To simplify coding I removed the windows specific handling which left >>>> out reservation of the archive. This was needed because windows cannot mmap >>>> files into reserved regions. But fallback code exists in filemap.cpp for >>>> this case which just reads in the region instead of mapping it. >>>> >>>> Should that turn out to be a performance problem, I will reinstate the >>>> feature. But a simpler way would be reserve the archive and later just >>>> before mmapping the archive file to release the archive space. That would >>>> not only be simpler but give us the best guarantee that that address space >>>> is actually available. But I'd be happy to leave that part out completely >>>> if we do not see any performance problems on windows x64. >>>> >>>> --- >>>> >>>> NMT cannot deal with spaces which are split. This problem manifests in >>>> that bookkeeping for class space is done under "Shared Classes", not >>>> "Classes" as it should. This problem exists today too at dump time and >>>> randomly at run time. But since I simplified the reservation, this problem >>>> now shows up always, whether or not we map at the SharedBaseAddress. >>>> While I could work around this problem, I'd prefer this problem to be >>>> solved at the core, and NMT to have an option to recognize reservation >>>> splits. So I'd rather not put a workaround for this into the patch but >>>> leave it for fixing as a separate issue. I opened this issue to track it >>>> [6]. >>>> >>>> --- >>>> >>>> Jtreg tests: >>>> >>>> I expanded the CompressedOops/CompressedClassPointers.java. I also >>>> extended them to Windows. The tests now optionally omit strict class space >>>> placement tests, since these tests heavily depend on ASLR and were the >>>> reason they were excluded on Windows. However I think even without checking >>>> for class space placement they make sense, just to see that the VM comes up >>>> and lives with the many different settings we can run in. >>>> >>>> --- >>>> >>>> Tests: >>>> >>>> - I ran the patch through Oracles submit repo >>>> - I ran tests manually for aarch64, zero, linux 32bit and windows x64 >>>> - The whole battery of nightly tests at SAP, including ppc, ppcle and >>>> aarch64, unfortunately excluding windows because of unrelated errors. >>>> Windows x64 tests will be redone tonight. >>>> >>>> >>>> Thank you, >>>> >>>> Thomas >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >>>> [2] >>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >>>> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >>>> [5] >>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >>>> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >>>> >>>> >>> >> > From Xiaohong.Gong at arm.com Thu May 21 10:24:44 2020 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Thu, 21 May 2020 10:24:44 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> Message-ID: Hi Andrew, > On 5/14/20 11:39 AM, Andrew Dinn wrote: > > On 14/05/2020 11:15, Andrew Haley wrote: > >> On 5/14/20 11:07 AM, Xiaohong Gong wrote: > >>> Hi Andrew, > >>> > >>> Thanks for having a look at it! > >>> > >>> > On 5/14/20 10:37 AM, Andrew Haley wrote: > >>> > > On 5/14/20 9:48 AM, Andrew Dinn wrote: > >>> > >> Just for references a direct link to the webrev, issue > and CSR > >>> > are: > >>> > >> > >>> > >> https://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.00/ > >>> > >> https://bugs.openjdk.java.net/browse/JDK-8243339 > >>> > >> https://bugs.openjdk.java.net/browse/JDK-8243456 > >>> > >> > >>> > >> The webrev looks fine to me. Nice work, thank you! > >>> > > > >>> > > There's a problem with C1: we generate unnecessary DMBs if > > > > >>> we're using TieredStopAtLevel=1 or if we only have the client > > > > >>> compiler. This is a performance regression, so I reject this > > > > >>> patch. > >>> > > >>> > There are similar regressoins in the interpreter. > >>> > >>> Yes, I agree with you that regressions exist for interpreter > and > >>> client compiler. So do you think if it's better to add the > >>> conditions to add DMBs for C1 and interpreter? How about just > >>> excluding the scenario like "interpreter only", "client > compiler > >>> only" and "TieredStopAtLevel=1" ? > >> > >> Yes, I think so. Is there some way simply to ask the question > "Are we > >> using C2 or JVMCI compilers?" That's what we need to know. > > This can be done using build time conditionality. > > Not entirely, because this is also switchable at runtime. I'v created a new patch to add the condition when inserting "DMBs" before volatile load for C1/Interpreter. The updated webrev: http://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.01/ It adds a new function "is_c1_or_interpreter_only()" , which can decide whether C2/JVMCI is used. Besides, since AOT also uses Graal compiler as the codegen, it always return false if AOT mode is enabled. Tests: Tested jtreg hotspot::hotspot_all_no_apps,jdk::jdk_core,langtools::tier1 and jcstress:tests-all, and all tests pass without new failure. Besides the tests with default configuration, different compile modes (client mode, c2 disabled mode) with different vm option groups (-XX:CompilationMode="quick-only", -XX:-TieredCompilation, -XX:TieredStopAtLevel=1) are also tested. Could you please take a look at it? Thank you! Thanks, Xiaohong From shade at redhat.com Thu May 21 12:20:19 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 14:20:19 +0200 Subject: [aarch64-port-dev ] RFR (XS): Shenandoah: fix build failures after JDK-8244737 backport Message-ID: <9e7058d4-7db7-2ca8-f456-efff6b0a503b@redhat.com> Hi, Surprising to me, after integration to aarch64-port/jdk8u-shenandoah [1], CI suddenly started reporting failures in Linux minimal1 and Windows builds. This is the fix: https://cr.openjdk.java.net/~shade/shenandoah/8u-fix-8244737.patch This is 8u-speficic trouble. I would prefer to push it to aarch64-port/jdk8u-shenandoah/hotspot directly to unbreak the integration repository. I would then pull it to shenandoah/jdk8. Testing: windows-x86_64-server-fastdebug, linux-x86-minimal1-fastdebug builds -- Thanks, -Aleksey [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008970.html From aph at redhat.com Thu May 21 14:06:07 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 21 May 2020 15:06:07 +0100 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> Message-ID: <71630bf9-1cde-69b4-c376-6318957ea672@redhat.com> On 5/21/20 11:24 AM, Xiaohong Gong wrote: > I'v created a new patch to add the condition when inserting "DMBs" before volatile > load for C1/Interpreter. > The updated webrev: http://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.01/ > > It adds a new function "is_c1_or_interpreter_only()" , which can decide whether > C2/JVMCI is used. Besides, since AOT also uses Graal compiler as the codegen, it > always return false if AOT mode is enabled. Looks good to me, thanks. As far as I remember, Graal does optimize volatile accesses to use ldar/stlr, or at least it will do so in the future, so if we're using AOT or JVMCI the safe thing to do is add the DMBs. -- 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 gnu.andrew at redhat.com Thu May 21 16:24:14 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 21 May 2020 17:24:14 +0100 Subject: [aarch64-port-dev ] RFR (XS): Shenandoah: fix build failures after JDK-8244737 backport In-Reply-To: <9e7058d4-7db7-2ca8-f456-efff6b0a503b@redhat.com> References: <9e7058d4-7db7-2ca8-f456-efff6b0a503b@redhat.com> Message-ID: <00809f91-a8eb-45e6-12a1-913425cf1157@redhat.com> On 21/05/2020 13:20, Aleksey Shipilev wrote: > Hi, > > Surprising to me, after integration to aarch64-port/jdk8u-shenandoah [1], CI suddenly started > reporting failures in Linux minimal1 and Windows builds. This is the fix: > https://cr.openjdk.java.net/~shade/shenandoah/8u-fix-8244737.patch > > This is 8u-speficic trouble. I would prefer to push it to aarch64-port/jdk8u-shenandoah/hotspot > directly to unbreak the integration repository. I would then pull it to shenandoah/jdk8. > > Testing: windows-x86_64-server-fastdebug, linux-x86-minimal1-fastdebug builds > Ah, the old HotSpot build... Don't you just love it? Changes look good to me and I'm glad you caught it before I hit it. Push the fix and I'll include it in the tag of the merge with the b03 work. Thanks, -- Andrew :) Senior Free Java Software Engineer 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 May 21 16:25:53 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 21 May 2020 18:25:53 +0200 Subject: [aarch64-port-dev ] RFR (XS): Shenandoah: fix build failures after JDK-8244737 backport In-Reply-To: <00809f91-a8eb-45e6-12a1-913425cf1157@redhat.com> References: <9e7058d4-7db7-2ca8-f456-efff6b0a503b@redhat.com> <00809f91-a8eb-45e6-12a1-913425cf1157@redhat.com> Message-ID: <776a79f2-c464-ddf7-888c-02040c314cb2@redhat.com> On 5/21/20 6:24 PM, Andrew Hughes wrote: > Ah, the old HotSpot build... Don't you just love it? Yes, my everything explode with delight! > Changes look good to me and I'm glad you caught it before I hit it. Push > the fix and I'll include it in the tag of the merge with the b03 work. Thanks, pushed. -- -Aleksey From shade at redhat.com Thu May 21 16:28:09 2020 From: shade at redhat.com (shade at redhat.com) Date: Thu, 21 May 2020 16:28:09 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: Shenandoah: fix build failures after JDK-8244737 backport Message-ID: <202005211628.04LGS9AJ028640@aojmv0008.oracle.com> Changeset: 4fd7bc699d62 Author: shade Date: 2020-05-21 18:25 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/4fd7bc699d62 Shenandoah: fix build failures after JDK-8244737 backport Reviewed-by: andrew ! make/excludeSrc.make ! make/windows/create_obj_files.sh ! make/windows/makefiles/vm.make From thomas.stuefe at gmail.com Thu May 21 17:35:37 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 21 May 2020 19:35:37 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> <8bf736b3-9ab1-86b7-fd22-230e449b1b9f@oracle.com> Message-ID: p.s. Just noted today that this patch will solve https://bugs.openjdk.java.net/browse/JDK-8245514 , so it has some real benefits beside being just a code cleanup. ..Thomas On Thu, May 21, 2020 at 8:26 AM Thomas St?fe wrote: > Hi all, > > tests went through successfully at SAP two nights in a row. Ioi gave his > okay, and I would like to push today or tomorrow. Any remaining objections`? > > The current, final version is: > > full: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ > delta: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ > > Thank you, > > Thomas > > On Wed, May 20, 2020 at 1:43 AM Ioi Lam wrote: > >> Hi Thomas, >> >> The testing took a little longer than I expected. I've run your previous >> version: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ >> >> In our CI tiers 1/4. No failures. >> >> I didn't run your latest version. I would suggesting testing it with your >> own CI as well as in jdk-submit before pushing (after you get OKs from >> other reviewers). >> >> Thumbs up. >> - Ioi >> >> >> On 5/19/20 7:40 AM, Thomas St?fe wrote: >> >> Hi guys, >> >> new webrev: >> >> full: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ >> delta: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ >> >> Mostly format changes, breaking up at column 80 as Andrew requested. >> >> The only changes which matter is the removal of the unnecessary include >> in arguments.cpp as Coleen suggested; and to not validate SharedBaseAddress >> anymore at runtime, as Ioi requested. >> >> Also rebased to head. >> >> Thanks, Thomas >> >> >> >> >> On Tue, May 19, 2020 at 6:38 AM Ioi Lam wrote: >> >>> >>> >>> On 5/18/20 7:37 AM, Thomas St?fe wrote: >>> >>> Hi all, >>> >>> fourth webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ >>> >>> I rebased atop of >>> >>> changeset: 59325:1ba9a9a3f948 >>> summary: 8244433: Remove saving of RSP in Assembler::pusha_uncached() >>> >>> so, atop of "8241825: Make compressed oops and compressed class pointers >>> independent (x86_64, PPC, S390)". >>> >>> The changes are very small this time, see notes below: >>> >>> @Ioi: >>> >>> >Hi Thomas, >>> >>> >I am running your patch in out CI pipeline now. Some comments: >>> >>> >[2] Does JDK-8243535 exist with the current jdk/jdk repo? >>> >>> I assigned JDK-8243535 to me and I'm working on a patch. But I would >>> like to keep that separate from this work, since this patch is already >>> large. And I would like to fix JDK-8243535 after this remodel patch has >>> been pushed, which makes some minor things easier. That would leave a small >>> time window where NMT does mis-track class space as shared class space, but >>> that is not a big issue, it does not even disturb any test. Which in itself >>> is something we may want to fix, come to think about it. >>> >>> >>> > [3] I think this can be put in header file. >>> > >>> > bool Metaspace::class_space_is_initialized() { >>> > return _class_space_list != NULL; >>> > } >>> >>> Done. >>> >>> > [7] argument.cpp checks this: >>> > >>> > if (UseSharedSpaces || DumpSharedSpaces) { >>> > if >>> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >>> > log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid >>> for this platform, option will be ignored.", >>> > p2i((address)SharedBaseAddress)); >>> > FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >>> > } >>> > } >>> > >>> > but initialize_dumptime_shared_and_meta_spaces aligns up the >>> SharedBaseAddress before doing the assert. >>> > >>> > void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >>> > assert(DumpSharedSpaces, "should be called for dump time only"); >>> > >>> > const size_t reserve_alignment = >>> MetaspaceShared::reserved_space_alignment(); >>> > char* shared_base = (char*)align_up((char*)SharedBaseAddress, >>> reserve_alignment); >>> > >>> > #ifdef _LP64 >>> > >>> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >>> "Sanity"); >>> > >>> > So theoretically shared_base may no longer be is_valid_base after the >>> align_up. It probably won't happen, but I think the code will be > much >>> clearer tofirst to align_up, then check for is_valid_base and reset to >>> default, and finally assert. >>> >>> The problem with that is that at the time this coding runs os::init() >>> did not yet run and we do not know yet allocation granularity. >>> >>> So I changed verification of SharedBaseAddress: I added the alignment as >>> you suggested and moved it to a later time in VM initialization, to CDS >>> initialization. >>> >>> >>> Is the call to check_SharedBaseAddress() necessary inside >>> MetaspaceShared::initialize_runtime_shared_and_meta_spaces()? >>> SharedBaseAddress is currently ignored at run time. Does your patch change >>> that behavior? >>> >>> >[8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >>> following block can be simplified: >>> > >>> > if (!_shared_rs.is_reserved()) { >>> > // Get a reserved space anywhere if attaching at the >>> SharedBaseAddress fails: >>> > if (UseCompressedClassPointers) { >>> > // If we need a compressed class space too, let the platform >>> handle the reservation. >>> > _shared_rs = >>> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >>> > } else { >>> > // anywhere is fine. >>> > _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >>> large */, (char*)NULL); >>> > } >>> > } >>> > >>> > ... if you change the declaration to: >>> > >>> > static ReservedSpace >>> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >>> ReservedSpace();}); >>> >>> I'd like to avoid keep the method LP64 only, but I rewrote the section >>> somewhat to be more clearer. >>> >>> The new code looks good. >>> >>> > [9] I think the #ifdef _LP64 is not necessary: >>> > >>> > #ifdef _LP64 >>> > // Some sanity checks after reserving address spaces for archives >>> and class space. >>> > assert(archive_space_rs.is_reserved(), "Sanity"); >>> > if (Metaspace::using_class_space()) { >>> > // Class space must closely follow the archive space. Both >>> spaces must be aligned correctly. >>> > assert(class_space_rs.is_reserved(), "A class space should have >>> been reserved"); >>> > assert(class_space_rs.base() >= archive_space_rs.end(), "class >>> space should follow the cds archive space"); >>> > assert(is_aligned(archive_space_rs.base(), >>> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >>> > assert(is_aligned(class_space_rs.base(), >>> Metaspace::reserve_alignment()), "class space misaligned"); >>> > } >>> > #endif >>> >>> I removed the #ifdef, but replaced it with an #ifdef ASSERT. Which is >>> also not needed, technically, but makes it clear that this section is >>> debugging checks only. >>> >>> >>> OK. >>> >>> The rest of the code looks good to me. I am going to run your latest >>> patch in our CI and will report the results. >>> >>> Thanks >>> - Ioi >>> >>> ---- >>> >>> @Coleen: >>> >>> > >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/ >>> >virtualSpaceList.cpp.udiff.html >>> > >>> >Why did you make this change? Shouldn't the caller align it? >>> >>> >>> You are right, I removed the assert. >>> >>> --- >>> >>> Thanks all for your review work, >>> >>> ..Thomas >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: >>> >>>> Hi Thomas, >>>> >>>> I am running your patch in out CI pipeline now. Some comments: >>>> >>>> [1] Do we still need to use _class_space_list? It looks like we just >>>> have a single range. Is _class_space_list->current_virtual_space() always >>>> the same VS? >>>> >>>> if (_class_space_list != NULL) { >>>> address base = >>>> (address)_class_space_list->current_virtual_space()->bottom(); >>>> address top = base + compressed_class_space_size(); >>>> st->print("Compressed class space mapped at: " PTR_FORMAT "-" >>>> PTR_FORMAT ", size: " SIZE_FORMAT, >>>> p2i(base), p2i(top), top - base); >>>> >>>> [2] Does JDK-8243535 exist with the current jdk/jdk repo? >>>> >>>> // This does currently not work because rs may be the result of a >>>> split operation >>>> // and NMT seems not to be able to handle splits. >>>> // See JDK-8243535. >>>> // MemTracker::record_virtual_memory_type((address)rs.base(), >>>> mtClass); >>>> >>>> >>>> [3] I think this can be put in header file. >>>> >>>> bool Metaspace::class_space_is_initialized() { >>>> return _class_space_list != NULL; >>>> } >>>> >>>> [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is >>>> the reason for the >>>> gap in the following chart: >>>> >>>> // We do this by reserving space for the ccs behind the archives. >>>> Note however that >>>> // ccs follows a different alignment >>>> (Metaspace::reserve_alignment), so there may >>>> // be a gap between ccs and cds. >>>> // We use a similar layout at runtime, see >>>> reserve_address_space_for_archives(). >>>> // >>>> // +-- SharedBaseAddress (default = >>>> 0x800000000) >>>> // v >>>> // +-..---------+---------+ ... >>>> +----+----+----+--------+--------------------+ >>>> // | Heap | Archive | | MC | RW | RO | [gap] | class >>>> space | >>>> // +-..---------+---------+ ... >>>> +----+----+----+--------+--------------------+ >>>> // |<-- MaxHeapSize -->| |<-- UnscaledClassSpaceMax = 4GB >>>> -->| >>>> >>>> >>>> _reserve_alignment is determined here: >>>> >>>> void Metaspace::ergo_initialize() { >>>> if (DumpSharedSpaces) { >>>> // Using large pages when dumping the shared archive is currently >>>> not implemented. >>>> FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >>>> } >>>> >>>> size_t page_size = os::vm_page_size(); >>>> if (UseLargePages && UseLargePagesInMetaspace) { >>>> page_size = os::large_page_size(); >>>> } >>>> >>>> _commit_alignment = page_size; >>>> _reserve_alignment = MAX2(page_size, >>>> (size_t)os::vm_allocation_granularity()); >>>> >>>> But when CDS is enabled, the RS is reserved without large pages, so it >>>> should be possible to incrementally commit the CCS using just >>>> os::vm_allocation_granularity(). >>>> >>>> [5] I see the aarch64 code in >>>> Metaspace::reserve_address_space_for_compressed_classes has been changed. >>>> Is this necessary for this RFE, or is it a separate improvement that can be >>>> done in a different RFE? >>>> >>>> [6] For AARCH64, should we skip the part that reserves it right above >>>> the heap? Or does AARCH64 always allocate the heap such that it's a >>>> preferable address? >>>> >>>> // case (b) >>>> ReservedSpace rs; >>>> >>>> // Try right above the Java heap... >>>> address base = align_up(CompressedOops::end(), >>>> Metaspace::reserve_alignment()); >>>> assert(base != NULL, "Sanity"); >>>> >>>> const size_t size = align_up(CompressedClassSpaceSize, >>>> Metaspace::reserve_alignment()); >>>> if (CompressedKlassPointers::is_valid_base(base)) { >>>> rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* >>>> large */, (char*)base); >>>> } >>>> >>>> // ...failing that, reserve anywhere, but let platform do optimized >>>> placement: >>>> if (!rs.is_reserved()) { >>>> rs = >>>> Metaspace::reserve_address_space_for_compressed_classes(size); >>>> } >>>> >>>> [7] argument.cpp checks this: >>>> >>>> if (UseSharedSpaces || DumpSharedSpaces) { >>>> if >>>> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >>>> log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for >>>> this platform, option will be ignored.", >>>> p2i((address)SharedBaseAddress)); >>>> FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >>>> } >>>> } >>>> >>>> but initialize_dumptime_shared_and_meta_spaces aligns up the >>>> SharedBaseAddress before doing the assert. >>>> >>>> void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >>>> assert(DumpSharedSpaces, "should be called for dump time only"); >>>> >>>> const size_t reserve_alignment = >>>> MetaspaceShared::reserved_space_alignment(); >>>> char* shared_base = (char*)align_up((char*)SharedBaseAddress, >>>> reserve_alignment); >>>> >>>> #ifdef _LP64 >>>> >>>> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >>>> "Sanity"); >>>> >>>> So theoretically shared_base may no longer be is_valid_base after the >>>> align_up. It probably won't happen, but I think the code will be much >>>> clearer tofirst to align_up, then check for is_valid_base and reset to >>>> default, and finally assert. >>>> >>>> [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >>>> following block can be simplified: >>>> >>>> if (!_shared_rs.is_reserved()) { >>>> // Get a reserved space anywhere if attaching at the >>>> SharedBaseAddress fails: >>>> if (UseCompressedClassPointers) { >>>> // If we need a compressed class space too, let the platform >>>> handle the reservation. >>>> _shared_rs = >>>> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >>>> } else { >>>> // anywhere is fine. >>>> _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >>>> large */, (char*)NULL); >>>> } >>>> } >>>> >>>> ... if you change the declaration to: >>>> >>>> static ReservedSpace >>>> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >>>> ReservedSpace();}); >>>> >>>> [9] I think the #ifdef _LP64 is not necessary: >>>> >>>> #ifdef _LP64 >>>> // Some sanity checks after reserving address spaces for archives >>>> and class space. >>>> assert(archive_space_rs.is_reserved(), "Sanity"); >>>> if (Metaspace::using_class_space()) { >>>> // Class space must closely follow the archive space. Both spaces >>>> must be aligned correctly. >>>> assert(class_space_rs.is_reserved(), "A class space should have >>>> been reserved"); >>>> assert(class_space_rs.base() >= archive_space_rs.end(), "class >>>> space should follow the cds archive space"); >>>> assert(is_aligned(archive_space_rs.base(), >>>> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >>>> assert(is_aligned(class_space_rs.base(), >>>> Metaspace::reserve_alignment()), "class space misaligned"); >>>> } >>>> #endif >>>> >>>> The rest of the code looks OK to me, but I may take a look at it again >>>> after getting more sleep :-) >>>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> >>>> >>>> On 5/7/20 7:21 AM, Thomas St?fe wrote: >>>> >>>> Hi all, >>>> >>>> please take a look at the third iteration of this change: >>>> >>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >>>> >>>> Changes in this version: >>>> >>>> - at the request of Coleen (sorry I did not see your post earlier) I >>>> removed all platform dependent files and put the platform dependent coding >>>> back to metaspace.cpp and compressedOops.cpp to ease the review pain. I >>>> used plain platform defines though (#ifdef AARCH64) instead of hiding them >>>> behind another macro to make things clearer. Note that I still intent to >>>> put this code away into the platform corners but will do so in a follow up >>>> RFE. >>>> >>>> - I reinstated, in a fashion, the special handling of reservations on >>>> Windows. On all platforms we reserve address space to map the archive files >>>> in with a subsequent mapping operation. However, on Windows, we cannot use >>>> MapViewOfFile() into an existing mapping. So I remove the mapping again >>>> before mapping the archives - see comment in code for details. >>>> >>>> All CI tests at SAP run through without problems, including on Win64 >>>> and aarch64, but I would be happy if others were to run test too. >>>> >>>> Thank you, Thomas >>>> >>>> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Could I have reviews for the following proposal of reworking cds/class >>>>> space reservation? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >>>>> >>>>> (Many thanks to Ioi Lam for so patiently explaining CDS internals to >>>>> me, and to Andrew Haley and Nick Gasson for help with aarch64!) >>>>> >>>>> Reservation of the compressed class space is needlessly complicated >>>>> and has some minor issues. It can be simplified and made clearer. >>>>> >>>>> The complexity stems from the fact that this area lives at the >>>>> intersection of two to three sub systems, depending on how one counts. >>>>> Metaspace, CDS, and the platform which may or may not its own view of how >>>>> to reserve class space. And this code has been growing organically over >>>>> time. >>>>> >>>>> One small example: >>>>> >>>>> ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t >>>>> alignment, >>>>> bool large_pages, >>>>> char *requested_addr, >>>>> bool >>>>> use_requested_addr) >>>>> >>>>> which I spent hours decoding, resulting in a very confused mail to >>>>> hs-runtime and aarch64-port-dev [2]. >>>>> >>>>> This patch attempts to simplify cds and metaspace setup a bit; to >>>>> comment implicit knowledge which is not immediately clear; to cleanly >>>>> abstract platform concerns like optimized class space placement; and to >>>>> disentangle cds from metaspace to solve issues which may bite us later with >>>>> Elastic Metaspace [4]. >>>>> >>>>> --- >>>>> >>>>> The main change is the reworked reservation mechanism. This is based >>>>> on Ioi's proposal [5]. >>>>> >>>>> When reserving class space, three things must happen: >>>>> >>>>> 1) reservation of the space obviously. If cds is active that space >>>>> must be in the vicinity of cds archives to be covered by compressed class >>>>> pointer encoding. >>>>> 2) setting up the internal Metaspace structures atop of that space >>>>> 3) setting up compressed class pointer encoding. >>>>> >>>>> In its current form, Metaspace may or may not do some or all of that >>>>> in one function >>>>> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>>> metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, >>>>> it will reserve the space for Metaspace and hand it in, otherwise it will >>>>> create it itself. >>>>> >>>>> When discussing this in [2], Ioi proposed to move the reservation of >>>>> the class space completely out of Metaspace and make it a responsibility of >>>>> the caller always. This would reduce some complexity, and this patch >>>>> follows the proposal. >>>>> >>>>> I removed >>>>> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>>> metaspace_rs, char* requested_addr, address cds_base); and all its sub >>>>> functions. >>>>> >>>>> (1) now has to always be done outside - a ReservedSpace for class >>>>> space has to be provided by the caller. However, Metaspace now offers a >>>>> utility function for reserving space at a "nice" location, and explicitly >>>>> doing nothing else: >>>>> >>>>> ReservedSpace >>>>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>>>> >>>>> this function can be redefined on a platform level for platform >>>>> optimized reservation, see below for details. >>>>> >>>>> (2) is taken care of by a new function, >>>>> Metaspace::initialize_class_space(ReservedSpace rs) >>>>> >>>>> (3) is taken care of a new function >>>>> CompressedKlassPointers::initialize(), see below for details. >>>>> >>>>> >>>>> So, class space now is set up three explicit steps: >>>>> >>>>> - First, reserve a suitable space by however means you want. For >>>>> convenience you may use >>>>> Metaspace::reserve_address_space_for_compressed_classes(), or you may roll >>>>> your own reservation. >>>>> - Next, tell Metaspace to use that range as backing storage for class >>>>> space: Metaspace::initialize_class_space(ReservedSpace rs) >>>>> - Finally, set up encoding. Encoding is independent from the concept >>>>> of a ReservedSpace, it just gets an address range, see below for details. >>>>> >>>>> Separating these steps and moving them out of the responsibility of >>>>> Metaspace makes this whole thing more flexible; it also removes unnecessary >>>>> knowledge (e.g. Metaspace does not need to know anything about either ccp >>>>> encoding or cds). >>>>> >>>>> --- >>>>> >>>>> How it comes together: >>>>> >>>>> If CDS is off, we just reserve a space using >>>>> Metaspace::reserve_address_space_for_compressed_classes(), initialize it >>>>> with Metaspace::initialize_class_space(ReservedSpace rs), then set up >>>>> compressed class pointer encoding covering the range of this class space. >>>>> >>>>> If CDS is on (dump time), we reserve large 4G space, either at >>>>> SharedBaseAddress or using >>>>> Metaspace::reserve_address_space_for_compressed_classes(); we then split >>>>> that into 3G archive space and 1G class space; we set up that space with >>>>> Metaspace as class space; then we set up compressed class pointer encoding >>>>> covering both archive space and cds. >>>>> >>>>> If CDS is on (run time), we reserve a large space, split it into >>>>> archive space (large enough to hold both archives) and class space, then >>>>> basically proceed as above. >>>>> >>>>> Note that this is almost exactly how things worked before (modulo some >>>>> minor fixes, e.g. alignment issues), only the code is reformed and made >>>>> more explicit. >>>>> >>>>> --- >>>>> >>>>> I moved compressed class pointer setup over to CompressedKlassPointers >>>>> and changed the interface: >>>>> >>>>> -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >>>>> metaspace_rs, address cds_base) >>>>> +void CompressedKlassPointers::initialize(address addr, size_t len); >>>>> >>>>> Instead of feeding it a single ReservedSpace, which is supposed to >>>>> represent class space, and an optional alternate base if cds is on, now we >>>>> give it just an numeric address range. That range marks the limits to where >>>>> Klass structures are to be expected, and is the implicit promise that >>>>> outside that range no Klass structures will exist, so encoding has to cover >>>>> only this range. >>>>> >>>>> This range may contain just the class space; or class space+cds; or >>>>> whatever allocation scheme we come up with in the future. Encoding does not >>>>> really care how the memory is organized as long as the input range covers >>>>> all possible Klass locations. That way we remove knowledge about class >>>>> space/cds from compressed class pointer encoding. >>>>> >>>>> Moving it away from metaspace.cpp into the CompressedKlassPointers >>>>> class also mirrors CompressedOops::initialize(). >>>>> >>>>> --- >>>>> >>>>> I renamed _narrow_klass_range to just _range, because strictly >>>>> speaking this is the range un-narrow Klass pointers can have. >>>>> >>>>> As for the implementation of >>>>> CompressedKlassPointers::initialize(address addr, size_t len), I mimicked >>>>> very closely what happened before, so there should be almost no >>>>> differences. Since "almost no differences" sounds scary :) here are the >>>>> differences: >>>>> >>>>> - When CDS is active (dump or run time) we now always, >>>>> unconditionally, set the encoding range to 4G. This fixes a theoretical bug >>>>> discussed on aarch64-port-dev [1]. >>>>> >>>>> - When CDS is not active, we set the encoding range to the minimum >>>>> required length. Before, it was left at its default value of 4G. >>>>> >>>>> Both differences only affect aarch64, since they are currently the >>>>> only one using the range field in CompressedKlassPointers. >>>>> >>>>> I wanted to add an assert somewhere to test encoding of the very last >>>>> address of the CompressedKlassPointers range, again to prevent errors like >>>>> [3]. But I did not come up with a good place for this assert which would >>>>> cover also the encoding done by C1/C2. >>>>> >>>>> For the same reason I thought about introducing a mode where Klass >>>>> structures would be allocated in reverse order, starting at the end of the >>>>> ccs, but again left it out as too big a change. >>>>> >>>>> --- >>>>> >>>>> OS abstraction: platforms may have restrictions of what constitutes a >>>>> valid compressed class pointer encoding base. Or if not, they may have at >>>>> least preferences. There was logic like this in metaspace.cpp, which I >>>>> removed and cleanly factored out into platform dependent files, giving each >>>>> platform the option to add special logic. >>>>> >>>>> These are two new methods: >>>>> >>>>> - bool CompressedKlassPointers::is_valid_base(address p) >>>>> >>>>> to let the platform tell you whether it considers p to be a valid >>>>> encoding base. The only platform having these restrictions currently is >>>>> aarch64. >>>>> >>>>> - ReservedSpace >>>>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>>>> >>>>> this hands over the process of allocating a range suitable for >>>>> compressed class pointer encoding to the platform. Most platforms will >>>>> allocate just anywhere, but some platforms may have a better strategy (e.g. >>>>> trying low memory first, trying only correctly aligned addresses and so >>>>> on). >>>>> >>>>> Beforehand, this coding existed in a similar form in metaspace.cpp for >>>>> aarch64 and AIX. For now, I left the AIX part out - it seems only half >>>>> done, and I want to check further if we even need it, if yes why not on >>>>> Linux ppc, and C1 does not seem to support anything other than base+offset >>>>> with shift either, but I may be mistaken. >>>>> >>>>> These two methods should give the platform enough control to implement >>>>> their own scheme for optimized class space placement without bothering any >>>>> shared code about it. >>>>> >>>>> Note about the form, I introduced two new platform dependent files, >>>>> "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about >>>>> this but this seems to be what we generally do in hotspot, right? >>>>> >>>>> --- >>>>> >>>>> Metaspace reserve alignment vs cds alignment >>>>> >>>>> CDS was using Metaspace reserve alignment for CDS internal purposes. I >>>>> guess this was just a copy paste issue. It never caused problems since >>>>> Metaspace reserve alignment == page size, but that is not true anymore in >>>>> the upcoming Elastic Metaspace where reserve alignment will be larger. This >>>>> causes a number of issues. >>>>> >>>>> I separated those two cleanly. CDS now uses >>>>> os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in >>>>> those two places where it is needed, when CDS creates the address space for >>>>> class space on behalf of the Metaspace. >>>>> >>>>> --- >>>>> >>>>> Windows special handling in CDS >>>>> >>>>> To simplify coding I removed the windows specific handling which left >>>>> out reservation of the archive. This was needed because windows cannot mmap >>>>> files into reserved regions. But fallback code exists in filemap.cpp for >>>>> this case which just reads in the region instead of mapping it. >>>>> >>>>> Should that turn out to be a performance problem, I will reinstate the >>>>> feature. But a simpler way would be reserve the archive and later just >>>>> before mmapping the archive file to release the archive space. That would >>>>> not only be simpler but give us the best guarantee that that address space >>>>> is actually available. But I'd be happy to leave that part out completely >>>>> if we do not see any performance problems on windows x64. >>>>> >>>>> --- >>>>> >>>>> NMT cannot deal with spaces which are split. This problem manifests in >>>>> that bookkeeping for class space is done under "Shared Classes", not >>>>> "Classes" as it should. This problem exists today too at dump time and >>>>> randomly at run time. But since I simplified the reservation, this problem >>>>> now shows up always, whether or not we map at the SharedBaseAddress. >>>>> While I could work around this problem, I'd prefer this problem to be >>>>> solved at the core, and NMT to have an option to recognize reservation >>>>> splits. So I'd rather not put a workaround for this into the patch but >>>>> leave it for fixing as a separate issue. I opened this issue to track it >>>>> [6]. >>>>> >>>>> --- >>>>> >>>>> Jtreg tests: >>>>> >>>>> I expanded the CompressedOops/CompressedClassPointers.java. I also >>>>> extended them to Windows. The tests now optionally omit strict class space >>>>> placement tests, since these tests heavily depend on ASLR and were the >>>>> reason they were excluded on Windows. However I think even without checking >>>>> for class space placement they make sense, just to see that the VM comes up >>>>> and lives with the many different settings we can run in. >>>>> >>>>> --- >>>>> >>>>> Tests: >>>>> >>>>> - I ran the patch through Oracles submit repo >>>>> - I ran tests manually for aarch64, zero, linux 32bit and windows x64 >>>>> - The whole battery of nightly tests at SAP, including ppc, ppcle and >>>>> aarch64, unfortunately excluding windows because of unrelated errors. >>>>> Windows x64 tests will be redone tonight. >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> Thomas >>>>> >>>>> [1] >>>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >>>>> [2] >>>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >>>>> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >>>>> [5] >>>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >>>>> >>>>> >>>> >>> >> From Xiaohong.Gong at arm.com Fri May 22 02:36:36 2020 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Fri, 22 May 2020 02:36:36 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: <71630bf9-1cde-69b4-c376-6318957ea672@redhat.com> References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> <71630bf9-1cde-69b4-c376-6318957ea672@redhat.com> Message-ID: Hi Andrew, > On 5/21/20 11:24 AM, Xiaohong Gong wrote: > > I'v created a new patch to add the condition when inserting > "DMBs" > > before volatile load for C1/Interpreter. > > The updated webrev: > > http://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.01/ > > > > It adds a new function "is_c1_or_interpreter_only()" , which can > > decide whether C2/JVMCI is used. Besides, since AOT also uses > Graal > > compiler as the codegen, it always return false if AOT mode is > enabled. > > Looks good to me, thanks. > > As far as I remember, Graal does optimize volatile accesses to use > ldar/stlr, or at least it will do so in the future, so if we're > using AOT or JVMCI the safe thing to do is add the DMBs. Yes, exactly! It has a patch in Graal github to do this optimization (https://github.com/oracle/graal/pull/1772). Thanks, Xiaohong -----Original Message----- From: Andrew Haley Sent: Thursday, May 21, 2020 10:06 PM To: Xiaohong Gong ; Andrew Dinn ; Derek White ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: Re: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option On 5/21/20 11:24 AM, Xiaohong Gong wrote: > I'v created a new patch to add the condition when inserting "DMBs" > before volatile load for C1/Interpreter. > The updated webrev: > http://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.01/ > > It adds a new function "is_c1_or_interpreter_only()" , which can > decide whether C2/JVMCI is used. Besides, since AOT also uses Graal > compiler as the codegen, it always return false if AOT mode is enabled. Looks good to me, thanks. As far as I remember, Graal does optimize volatile accesses to use ldar/stlr, or at least it will do so in the future, so if we're using AOT or JVMCI the safe thing to do is add the DMBs. -- 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 coleen.phillimore at oracle.com Fri May 22 12:14:58 2020 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Fri, 22 May 2020 08:14:58 -0400 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> <8bf736b3-9ab1-86b7-fd22-230e449b1b9f@oracle.com> Message-ID: <2cb02a62-954d-c261-2553-02b7e2ab4efb@oracle.com> On 5/21/20 2:26 AM, Thomas St?fe wrote: > Hi all, > > tests went through successfully at SAP two nights in a row. Ioi gave > his okay, and I would like to push today or tomorrow. Any remaining > objections`? None from me.? Ship it! Coleen > > The current, final version is: > > full: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ > delta: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ > > Thank you, > > Thomas > > On Wed, May 20, 2020 at 1:43 AM Ioi Lam > wrote: > > Hi Thomas, > > The testing took a little longer than I expected. I've run your > previous version: > > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ > > In our CI tiers 1/4. No failures. > > I didn't run your latest version. I would suggesting testing it > with your own CI as well as in jdk-submit before pushing (after > you get OKs from other reviewers). > > Thumbs up. > - Ioi > > > On 5/19/20 7:40 AM, Thomas St?fe wrote: >> Hi guys, >> >> new webrev: >> >> full: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ >> delta: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ >> >> Mostly format changes, breaking up at column 80 as Andrew requested. >> >> The only changes which matter is the removal of the unnecessary >> include in arguments.cpp as Coleen suggested; and to not validate >> SharedBaseAddress anymore at runtime, as Ioi requested. >> >> Also rebased to head. >> >> Thanks, Thomas >> >> >> >> >> On Tue, May 19, 2020 at 6:38 AM Ioi Lam > > wrote: >> >> >> >> On 5/18/20 7:37 AM, Thomas St?fe wrote: >>> Hi all, >>> >>> fourth webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ >>> >>> I rebased atop of >>> >>> changeset: ? 59325:1ba9a9a3f948 >>> summary: ? ? 8244433: Remove saving of RSP in >>> Assembler::pusha_uncached() >>> >>> so, atop of "8241825: Make compressed oops and compressed >>> class pointers independent (x86_64, PPC, S390)". >>> >>> The changes are very small this time, see notes below: >>> >>> @Ioi: >>> >>> >Hi Thomas, >>> >>> >I am running your patch in out CI pipeline now. Some comments: >>> >>> >[2] Does JDK-8243535 exist with the current jdk/jdk repo? >>> >>> I assigned JDK-8243535 to me and I'm working on a patch. But >>> I would like to keep that separate from this work, since >>> this patch is already large. And I would like to fix >>> JDK-8243535 after this remodel patch has been pushed, which >>> makes some minor things easier. That would leave a small >>> time window where NMT does mis-track class space as shared >>> class space, but that is not a big issue, it does not even >>> disturb any test. Which in itself is something we may want >>> to fix, come to think about it. >>> >>> >>> > [3] I think this can be put in header file. >>> > >>> > bool Metaspace::class_space_is_initialized() { >>> > ? return _class_space_list != NULL; >>> > } >>> >>> Done. >>> >>> > [7] argument.cpp checks this: >>> > >>> > ? if (UseSharedSpaces || DumpSharedSpaces) { >>> > ? ? if >>> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) >>> { >>> > ? ? ? log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " >>> is invalid for this platform, option will be ignored.", >>> > ?p2i((address)SharedBaseAddress)); >>> > ? ? ? FLAG_SET_DEFAULT(SharedBaseAddress, >>> default_SharedBaseAddress()); >>> > ? ? } >>> > ? } >>> > >>> > but initialize_dumptime_shared_and_meta_spaces aligns up >>> the SharedBaseAddress before doing the assert. >>> > >>> > ? void >>> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >>> > ? ? assert(DumpSharedSpaces, "should be called for dump >>> time only"); >>> > >>> > ? ? const size_t reserve_alignment = >>> MetaspaceShared::reserved_space_alignment(); >>> > ? ? char* shared_base = >>> (char*)align_up((char*)SharedBaseAddress, reserve_alignment); >>> > >>> > ? #ifdef _LP64 >>> > >>> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >>> "Sanity"); >>> > >>> > So theoretically shared_base may no longer be >>> is_valid_base after the align_up. It probably won't happen, >>> but I think the code will be > much clearer tofirst to >>> align_up, then check for is_valid_base and reset to default, >>> and finally assert. >>> >>> The problem with that is that at the time this coding runs >>> os::init() did not yet run and we do not know yet allocation >>> granularity. >>> >>> So I changed verification of SharedBaseAddress: I added the >>> alignment as you suggested and moved it to a later time in >>> VM initialization, to CDS initialization. >>> >> >> Is the call to? check_SharedBaseAddress() necessary inside >> MetaspaceShared::initialize_runtime_shared_and_meta_spaces()? >> SharedBaseAddress is currently ignored at run time. Does your >> patch change that behavior? >> >>> >[8] In >>> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, >>> the following block can be simplified: >>> > >>> > ?if (!_shared_rs.is_reserved()) { >>> > ? ?// Get a reserved space anywhere if attaching at the >>> SharedBaseAddress fails: >>> > ? ?if (UseCompressedClassPointers) { >>> > ? ? ?// If we need a compressed class space too, let the >>> platform handle the reservation. >>> > ? ? ?_shared_rs = >>> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >>> > ? ?} else { >>> > ? ? ?// anywhere is fine. >>> > ? ? ?_shared_rs = ReservedSpace(cds_total, >>> reserve_alignment, false /* large */, (char*)NULL); >>> > ? ?} >>> > ?} >>> > >>> > ? ... if you change the declaration to: >>> > >>> > ?static ReservedSpace >>> reserve_address_space_for_compressed_classes(size_t size) >>> NOT_LP64({ return ReservedSpace();}); >>> >>> I'd like to avoid keep the method LP64 only, but I rewrote >>> the section somewhat to be more clearer. >>> >> The new code looks good. >> >>> > [9] I think the #ifdef _LP64 is not necessary: >>> > >>> > #ifdef _LP64 >>> > ? ? // Some sanity checks after reserving address spaces >>> for archives and class space. >>> > assert(archive_space_rs.is_reserved(), "Sanity"); >>> > ? ? if (Metaspace::using_class_space()) { >>> > ? ? ? // Class space must closely follow the archive >>> space. Both spaces must be aligned correctly. >>> > assert(class_space_rs.is_reserved(), "A class space should >>> have been reserved"); >>> > ? ? ? assert(class_space_rs.base() >= >>> archive_space_rs.end(), "class space should follow the cds >>> archive space"); >>> > assert(is_aligned(archive_space_rs.base(), >>> MetaspaceShared::reserved_space_alignment()), "Archive space >>> misaligned"); >>> > assert(is_aligned(class_space_rs.base(), >>> Metaspace::reserve_alignment()), "class space misaligned"); >>> > ? ? } >>> > #endif >>> >>> I removed the #ifdef, but replaced it with an #ifdef ASSERT. >>> Which is also not needed, technically, but makes it clear >>> that this section is debugging checks only. >>> >> >> OK. >> >> The rest of the code looks good to me. I am going to run your >> latest patch in our CI and will report the results. >> >> Thanks >> - Ioi >>> ---- >>> >>> @Coleen: >>> >>> >http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/>virtualSpaceList.cpp.udiff.html >>> > >>> >Why did you make this change? Shouldn't the caller align it? >>> >>> >>> You are right, I removed the assert. >>> >>> --- >>> >>> Thanks all for your review work, >>> >>> ..Thomas >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, May 8, 2020 at 7:37 AM Ioi Lam >> > wrote: >>> >>> Hi Thomas, >>> >>> I am running your patch in out CI pipeline now. Some >>> comments: >>> >>> [1] Do we still need to use _class_space_list? It looks >>> like we just have a single range. Is >>> _class_space_list->current_virtual_space() always the >>> same VS? >>> >>> ? if (_class_space_list != NULL) { >>> ??? address base = >>> (address)_class_space_list->current_virtual_space()->bottom(); >>> ??? address top = base + compressed_class_space_size(); >>> ??? st->print("Compressed class space mapped at: " >>> PTR_FORMAT "-" PTR_FORMAT ", size: " SIZE_FORMAT, >>> ?????????????? p2i(base), p2i(top), top - base); >>> >>> [2] Does JDK-8243535 exist with the current jdk/jdk repo? >>> >>> ? // This does currently not work because rs may be the >>> result of a split operation >>> ? // and NMT seems not to be able to handle splits. >>> ? // See JDK-8243535. >>> ? // >>> MemTracker::record_virtual_memory_type((address)rs.base(), >>> mtClass); >>> >>> >>> [3] I think this can be put in header file. >>> >>> bool Metaspace::class_space_is_initialized() { >>> ? return _class_space_list != NULL; >>> } >>> >>> [4] Why does the CCS need to follow >>> UseLargePagesInMetaspace? This is the reason for the >>> ??? gap in the following chart: >>> >>> ??? // We do this by reserving space for the ccs behind >>> the archives. Note however that >>> ??? //? ccs follows a different alignment >>> (Metaspace::reserve_alignment), so there may >>> ??? //? be a gap between ccs and cds. >>> ??? // We use a similar layout at runtime, see >>> reserve_address_space_for_archives(). >>> ??? // >>> ??? //????????????????????????????? +-- >>> SharedBaseAddress (default = 0x800000000) >>> ??? //????????????????????????????? v >>> ??? // +-..---------+---------+ ... >>> +----+----+----+--------+--------------------+ >>> ??? // |??? Heap??? | Archive |???? | MC | RW | RO | >>> [gap]? |??? class space???? | >>> ??? // +-..---------+---------+ ... >>> +----+----+----+--------+--------------------+ >>> ??? // |<--?? MaxHeapSize? -->| |<-- >>> UnscaledClassSpaceMax = 4GB -->| >>> >>> >>> _reserve_alignment is determined here: >>> >>> void Metaspace::ergo_initialize() { >>> ? if (DumpSharedSpaces) { >>> ??? // Using large pages when dumping the shared archive >>> is currently not implemented. >>> FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >>> ? } >>> >>> ? size_t page_size = os::vm_page_size(); >>> ? if (UseLargePages && UseLargePagesInMetaspace) { >>> ??? page_size = os::large_page_size(); >>> ? } >>> >>> ? _commit_alignment? = page_size; >>> ? _reserve_alignment = MAX2(page_size, >>> (size_t)os::vm_allocation_granularity()); >>> >>> But when CDS is enabled, the RS is reserved without >>> large pages, so it should be possible to incrementally >>> commit the CCS using just os::vm_allocation_granularity(). >>> >>> [5] I see the aarch64 code in >>> Metaspace::reserve_address_space_for_compressed_classes >>> has been changed. Is this necessary for this RFE, or is >>> it a separate improvement that can be done in a >>> different RFE? >>> >>> [6] For AARCH64, should we skip the part that reserves >>> it right above the heap? Or does AARCH64 always allocate >>> the heap such that it's a preferable address? >>> >>> ??? // case (b) >>> ??? ReservedSpace rs; >>> >>> ??? // Try right above the Java heap... >>> ??? address base = align_up(CompressedOops::end(), >>> Metaspace::reserve_alignment()); >>> ??? assert(base != NULL, "Sanity"); >>> >>> ??? const size_t size = >>> align_up(CompressedClassSpaceSize, >>> Metaspace::reserve_alignment()); >>> ??? if (CompressedKlassPointers::is_valid_base(base)) { >>> ????? rs = ReservedSpace(size, >>> Metaspace::reserve_alignment(), false /* large */, >>> (char*)base); >>> ??? } >>> >>> ??? // ...failing that, reserve anywhere, but let >>> platform do optimized placement: >>> ??? if (!rs.is_reserved()) { >>> ????? rs = >>> Metaspace::reserve_address_space_for_compressed_classes(size); >>> ??? } >>> >>> [7] argument.cpp checks this: >>> >>> ? if (UseSharedSpaces || DumpSharedSpaces) { >>> ??? if >>> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) >>> { >>> log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is >>> invalid for this platform, option will be ignored.", >>> p2i((address)SharedBaseAddress)); >>> ????? FLAG_SET_DEFAULT(SharedBaseAddress, >>> default_SharedBaseAddress()); >>> ??? } >>> ? } >>> >>> but initialize_dumptime_shared_and_meta_spaces aligns up >>> the SharedBaseAddress before doing the assert. >>> >>> ? void >>> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() >>> { >>> ??? assert(DumpSharedSpaces, "should be called for dump >>> time only"); >>> >>> ??? const size_t reserve_alignment = >>> MetaspaceShared::reserved_space_alignment(); >>> ??? char* shared_base = >>> (char*)align_up((char*)SharedBaseAddress, >>> reserve_alignment); >>> >>> ? #ifdef _LP64 >>> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >>> "Sanity"); >>> >>> So theoretically shared_base may no longer be >>> is_valid_base after the align_up. It probably won't >>> happen, but I think the code will be much clearer >>> tofirst to align_up, then check for is_valid_base and >>> reset to default, and finally assert. >>> >>> [8] In >>> MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, >>> the following block can be simplified: >>> >>> ? if (!_shared_rs.is_reserved()) { >>> ??? // Get a reserved space anywhere if attaching at the >>> SharedBaseAddress fails: >>> ??? if (UseCompressedClassPointers) { >>> ????? // If we need a compressed class space too, let >>> the platform handle the reservation. >>> ????? _shared_rs = >>> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >>> ??? } else { >>> ????? // anywhere is fine. >>> ????? _shared_rs = ReservedSpace(cds_total, >>> reserve_alignment, false /* large */, (char*)NULL); >>> ??? } >>> ? } >>> >>> ?? ... if you change the declaration to: >>> >>> ? static ReservedSpace >>> reserve_address_space_for_compressed_classes(size_t >>> size) NOT_LP64({ return ReservedSpace();}); >>> >>> [9] I think the #ifdef _LP64 is not necessary: >>> >>> #ifdef _LP64 >>> ??? // Some sanity checks after reserving address spaces >>> for archives and class space. >>> ??? assert(archive_space_rs.is_reserved(), "Sanity"); >>> ??? if (Metaspace::using_class_space()) { >>> ????? // Class space must closely follow the archive >>> space. Both spaces must be aligned correctly. >>> ????? assert(class_space_rs.is_reserved(), "A class >>> space should have been reserved"); >>> ????? assert(class_space_rs.base() >= >>> archive_space_rs.end(), "class space should follow the >>> cds archive space"); >>> assert(is_aligned(archive_space_rs.base(), >>> MetaspaceShared::reserved_space_alignment()), "Archive >>> space misaligned"); >>> assert(is_aligned(class_space_rs.base(), >>> Metaspace::reserve_alignment()), "class space misaligned"); >>> ??? } >>> #endif >>> >>> The rest of the code looks OK to me, but I may take a >>> look at it again after getting more sleep :-) >>> >>> Thanks >>> - Ioi >>> >>> >>> >>> >>> On 5/7/20 7:21 AM, Thomas St?fe wrote: >>>> Hi all, >>>> >>>> please take a look at the third iteration of this change: >>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >>>> >>>> Changes in this version: >>>> >>>> - at the request of Coleen (sorry I did not see your >>>> post earlier) I removed all platform dependent?files >>>> and put the platform dependent coding back to >>>> metaspace.cpp and compressedOops.cpp to ease the review >>>> pain. I used plain platform defines though (#ifdef >>>> AARCH64) instead of hiding them behind another macro to >>>> make things clearer. Note that I still intent to put >>>> this code away into the platform corners but will do so >>>> in a follow up RFE. >>>> >>>> - I reinstated, in a fashion, the special handling of >>>> reservations on Windows. On all platforms we reserve >>>> address space to map the archive files in with a >>>> subsequent mapping operation. However, on Windows, we >>>> cannot use MapViewOfFile() into an existing mapping. So >>>> I remove the mapping again before mapping the archives >>>> - see comment in code for details. >>>> >>>> All CI tests at SAP run through without problems, >>>> including on Win64 and aarch64, but I would be happy if >>>> others were to run test too. >>>> >>>> Thank you, Thomas >>>> >>>> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >>>> >>> > wrote: >>>> >>>> Hi all, >>>> >>>> Could I have reviews for the following proposal of >>>> reworking cds/class space reservation? >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >>>> >>>> (Many thanks to Ioi Lam for so patiently explaining >>>> CDS internals to me, and to Andrew Haley and Nick >>>> Gasson for help with aarch64!) >>>> >>>> Reservation of the compressed class space is >>>> needlessly complicated and has some minor issues. >>>> It can be simplified and made clearer. >>>> >>>> The complexity stems from the fact that this area >>>> lives at the intersection of two to three sub >>>> systems, depending on how one counts. Metaspace, >>>> CDS, and the platform which may or may not its own >>>> view of how to reserve class space. And this code >>>> has been growing organically over time. >>>> >>>> One small example: >>>> >>>> ReservedSpace >>>> Metaspace::reserve_preferred_space(size_t size, >>>> size_t alignment, >>>> ? ? ? ? ? ? ? ?bool large_pages, char *requested_addr, >>>> ? ? ? ? ? ? ? ?bool use_requested_addr) >>>> >>>> which I spent hours decoding, resulting in a very >>>> confused mail to hs-runtime and aarch64-port-dev [2]. >>>> >>>> This patch attempts to simplify cds and metaspace >>>> setup a bit; to comment implicit knowledge which is >>>> not immediately clear; to cleanly abstract platform >>>> concerns like optimized class space placement; and >>>> to disentangle cds from metaspace to solve issues >>>> which may bite us later with Elastic Metaspace [4]. >>>> >>>> --- >>>> >>>> The main change is the reworked reservation >>>> mechanism. This is based on Ioi's proposal [5]. >>>> >>>> When reserving class space, three things must happen: >>>> >>>> 1) reservation of the space obviously. If cds is >>>> active that space must be in the vicinity of cds >>>> archives to be covered by compressed class pointer >>>> encoding. >>>> 2) setting up the internal Metaspace structures >>>> atop of that space >>>> 3) setting up compressed class pointer encoding. >>>> >>>> In its current form, Metaspace may or may not do >>>> some or all of that in one function >>>> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>> metaspace_rs, char* requested_addr, address >>>> cds_base);) - if cds is active, it will reserve the >>>> space for Metaspace and hand it in, otherwise it >>>> will create it itself. >>>> >>>> When discussing this in [2], Ioi proposed to move >>>> the reservation of the class space completely out >>>> of Metaspace and make it a responsibility of the >>>> caller always. This would reduce some complexity, >>>> and this patch follows the proposal. >>>> >>>> I removed >>>> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>> metaspace_rs, char* requested_addr, address >>>> cds_base); and all its sub functions. >>>> >>>> (1) now has to always be done outside - a >>>> ReservedSpace for class space has to be provided by >>>> the caller. However, Metaspace now offers a utility >>>> function for reserving space at a "nice" location, >>>> and explicitly doing nothing else: >>>> >>>> ReservedSpace >>>> Metaspace::reserve_address_space_for_compressed_classes(size_t >>>> size); >>>> >>>> this function can be redefined on a platform level >>>> for platform optimized reservation, see below for >>>> details. >>>> >>>> (2) is taken care of by a new function, >>>> Metaspace::initialize_class_space(ReservedSpace rs) >>>> >>>> (3) is taken care of a new function >>>> CompressedKlassPointers::initialize(), see below >>>> for details. >>>> >>>> >>>> So, class space now is set up three explicit steps: >>>> >>>> - First, reserve a suitable space by however means >>>> you want. For convenience you may use >>>> Metaspace::reserve_address_space_for_compressed_classes(), >>>> or you may roll your own reservation. >>>> - Next, tell Metaspace to use that range as backing >>>> storage for class space: >>>> Metaspace::initialize_class_space(ReservedSpace rs) >>>> - Finally, set up encoding. Encoding is independent >>>> from the concept of a ReservedSpace, it just gets >>>> an address range, see below for details. >>>> >>>> Separating these steps and moving them out of the >>>> responsibility of Metaspace makes this whole thing >>>> more flexible; it also removes unnecessary >>>> knowledge (e.g. Metaspace does not need to know >>>> anything about either ccp encoding or cds). >>>> >>>> --- >>>> >>>> How it comes together: >>>> >>>> If CDS is off, we just reserve a space using >>>> Metaspace::reserve_address_space_for_compressed_classes(), >>>> initialize it with >>>> Metaspace::initialize_class_space(ReservedSpace >>>> rs), then set up compressed class pointer encoding >>>> covering the range of this class space. >>>> >>>> If CDS is on (dump time), we reserve large 4G >>>> space, either at SharedBaseAddress or using >>>> Metaspace::reserve_address_space_for_compressed_classes(); >>>> we then split that into 3G archive space and 1G >>>> class space; we set up that space with Metaspace as >>>> class space; then we set up?compressed class >>>> pointer encoding covering both archive space and cds. >>>> >>>> If CDS is on (run time), we reserve a large space, >>>> split it into archive space (large enough to hold >>>> both archives) and class space, then basically >>>> proceed as above. >>>> >>>> Note that this is almost exactly how things worked >>>> before (modulo some minor fixes, e.g. alignment >>>> issues), only the code is reformed and made more >>>> explicit. >>>> >>>> --- >>>> >>>> I moved compressed class pointer setup over to >>>> CompressedKlassPointers and changed the interface: >>>> >>>> -void >>>> Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >>>> metaspace_rs, address cds_base) >>>> +void CompressedKlassPointers::initialize(address >>>> addr, size_t len); >>>> >>>> Instead of feeding it a single ReservedSpace, which >>>> is supposed to represent class space, and an >>>> optional alternate base if cds is on, now we give >>>> it just an numeric address range. That range marks >>>> the limits to where Klass structures are to be >>>> expected, and is the implicit promise that outside >>>> that range no Klass structures will exist, so >>>> encoding has to cover only this range. >>>> >>>> This range may contain just the class space; or >>>> class space+cds; or whatever allocation scheme we >>>> come up with in the future. Encoding does not >>>> really care how the memory is organized as long as >>>> the input range covers all possible Klass >>>> locations. That way we remove knowledge about class >>>> space/cds from compressed class pointer encoding. >>>> >>>> Moving it away from metaspace.cpp into the >>>> CompressedKlassPointers class also mirrors >>>> CompressedOops::initialize(). >>>> >>>> --- >>>> >>>> I renamed _narrow_klass_range to just _range, >>>> because strictly speaking this is the range >>>> un-narrow Klass pointers can have. >>>> >>>> As for the implementation of >>>> CompressedKlassPointers::initialize(address addr, >>>> size_t len), I mimicked very closely what happened >>>> before, so there should be almost no differences. >>>> Since "almost no differences" sounds scary :) here >>>> are the differences: >>>> >>>> - When CDS is active (dump or run time) we now >>>> always, unconditionally, set the encoding range to >>>> 4G. This fixes a theoretical bug discussed on >>>> aarch64-port-dev [1]. >>>> >>>> - When CDS is not active, we set the encoding range >>>> to the minimum required length. Before, it was left >>>> at its default value of 4G. >>>> >>>> Both differences only affect aarch64, since they >>>> are currently the only one using the range field in >>>> CompressedKlassPointers. >>>> >>>> I wanted to add an assert somewhere to test >>>> encoding of the very last address of the >>>> CompressedKlassPointers range, again to prevent >>>> errors like [3]. But I did not come up with a good >>>> place for this assert which would cover also the >>>> encoding done by C1/C2. >>>> >>>> For the same reason I thought about introducing a >>>> mode where Klass structures would be allocated in >>>> reverse order, starting at the end of the ccs, but >>>> again left it out as too big a change. >>>> >>>> --- >>>> >>>> OS abstraction: platforms may have restrictions of >>>> what constitutes a valid compressed class pointer >>>> encoding base. Or if not, they may have at least >>>> preferences. There was logic like this in >>>> metaspace.cpp, which I removed and cleanly factored >>>> out into platform dependent files, giving each >>>> platform the option to add special logic. >>>> >>>> These are two new methods: >>>> >>>> - bool >>>> CompressedKlassPointers::is_valid_base(address p) >>>> >>>> to let the platform tell you whether it considers p >>>> to be a valid encoding base. The only platform >>>> having these restrictions currently is aarch64. >>>> >>>> - ReservedSpace >>>> Metaspace::reserve_address_space_for_compressed_classes(size_t >>>> size); >>>> >>>> this hands over the process of allocating a range >>>> suitable for compressed class pointer encoding to >>>> the platform. Most platforms will allocate just >>>> anywhere, but some platforms may have a better >>>> strategy (e.g. trying low memory first, trying only >>>> correctly aligned addresses and so on). >>>> >>>> Beforehand, this coding existed in a similar form >>>> in metaspace.cpp for aarch64 and AIX. For now, I >>>> left the AIX part out - it seems only half done, >>>> and I want to check further if we even need it, if >>>> yes why not on Linux ppc, and C1 does not seem to >>>> support anything other than base+offset with shift >>>> either, but I may be mistaken. >>>> >>>> These two methods should give the platform enough >>>> control to implement their own scheme for optimized >>>> class space placement without bothering any shared >>>> code about it. >>>> >>>> Note about the form, I introduced two new platform >>>> dependent files, "metaspace_.cpp" and >>>> "compressedOops_.cpp". I am not happy about >>>> this but this seems to be what we generally do in >>>> hotspot, right? >>>> >>>> --- >>>> >>>> Metaspace reserve alignment vs cds alignment >>>> >>>> CDS was using Metaspace reserve alignment for CDS >>>> internal purposes. I guess this was just a copy >>>> paste issue. It never caused problems since >>>> Metaspace reserve alignment == page size, but that >>>> is not true anymore in the upcoming Elastic >>>> Metaspace where reserve alignment will be larger. >>>> This causes a number of issues. >>>> >>>> I separated those two cleanly. CDS now uses >>>> os::vm_allocation_granularity. >>>> Metaspace::reserve_alignment is only used in those >>>> two places where it is needed, when CDS creates the >>>> address space for class space on behalf of the >>>> Metaspace. >>>> >>>> --- >>>> >>>> Windows special handling in CDS >>>> >>>> To simplify coding I removed the windows specific >>>> handling which left out reservation of the archive. >>>> This was needed because windows cannot mmap files >>>> into reserved regions. But fallback code exists in >>>> filemap.cpp for this case which just reads in the >>>> region instead of mapping?it. >>>> >>>> Should that turn out to be a performance problem, I >>>> will reinstate the feature. But a simpler way would >>>> be reserve the archive and later just before >>>> mmapping?the archive file to release the archive >>>> space. That would not only be simpler but give us >>>> the best guarantee that that address space is >>>> actually available. But I'd be happy to leave that >>>> part out completely if we do not see any >>>> performance problems on windows x64. >>>> >>>> --- >>>> >>>> NMT cannot deal with spaces which are split. This >>>> problem manifests in that bookkeeping for class >>>> space is done under "Shared Classes", not "Classes" >>>> as it should. This problem exists today too at >>>> dump?time and randomly at run time. But since I >>>> simplified the reservation, this problem now shows >>>> up always, whether or not we map at the >>>> SharedBaseAddress. >>>> While I could work around this problem, I'd prefer >>>> this problem to be solved at the core, and NMT to >>>> have an option to recognize reservation splits. So >>>> I'd rather not put a workaround for this into the >>>> patch but leave it for fixing as a separate issue. >>>> I opened this issue to track it [6]. >>>> >>>> --- >>>> >>>> Jtreg tests: >>>> >>>> I expanded the >>>> CompressedOops/CompressedClassPointers.java. I also >>>> extended them to Windows. The tests now optionally >>>> omit strict class space placement tests, since >>>> these tests heavily depend on ASLR and were the >>>> reason they were excluded on Windows. However I >>>> think even without checking for class space >>>> placement they make sense, just to see that the VM >>>> comes up and lives with the many different settings >>>> we can run in. >>>> >>>> --- >>>> >>>> Tests: >>>> >>>> - I ran the patch through Oracles submit repo >>>> - I ran tests manually for aarch64, zero, linux >>>> 32bit and windows x64 >>>> - The whole battery of nightly tests at SAP, >>>> including ppc, ppcle and aarch64, unfortunately >>>> excluding windows because of unrelated errors. >>>> Windows x64 tests will be redone tonight. >>>> >>>> >>>> Thank you, >>>> >>>> Thomas >>>> >>>> [1] >>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >>>> [2] >>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >>>> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >>>> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >>>> [5] >>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >>>> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >>>> >>> >> > From aph at redhat.com Fri May 22 13:00:58 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 May 2020 14:00:58 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: Message-ID: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> On 5/19/20 11:55 AM, Yang Zhang wrote: > Following up on review requests of API [0], Java implementation and > test [1], General Hotspot changes[2] for Vector API and x86 backend > changes [3]. Here's a request for review of AArch64 backend changes > required for supporting the Vector API: > > JEP: https://openjdk.java.net/jeps/338 > JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 > Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.01/ > > Complete implementation resides in vector-unstable branch of panama/dev > repository [4]. This looks great, and it's very impressive. Unfortunately, there are few of us sufficiently knowledgeable about Panama to review it in the detail that perhaps it deserves. I'm happy with it. However, we need tests for the new assembly instructions, so please add some to aarch64_asmtest.py and update macroassemler.cpp. Also, aarch64.ad is getting to be far too large, and perhaps all the vector stuff should be moved into a new file. 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 paul.sandoz at oracle.com Fri May 22 16:12:03 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 May 2020 09:12:03 -0700 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> Message-ID: <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> HI Andrew, Thanks for looking. I am not terribly familiar with the AArch64 code, but I would note the Vector API comes with a bunch of unit tests should exercise the code gen, just not as directly as I presume you would like. To what extent do you feel we can follow up with additional issues and fix them after the initial integration? Paul. > On May 22, 2020, at 6:00 AM, Andrew Haley wrote: > > On 5/19/20 11:55 AM, Yang Zhang wrote: >> Following up on review requests of API [0], Java implementation and >> test [1], General Hotspot changes[2] for Vector API and x86 backend >> changes [3]. Here's a request for review of AArch64 backend changes >> required for supporting the Vector API: >> >> JEP: https://openjdk.java.net/jeps/338 >> JBS: https://bugs.openjdk.java.net/browse/JDK-8223347 >> Webrev: http://cr.openjdk.java.net/~yzhang/vectorapi/vectorapi.rfr/aarch64_webrev/webrev.01/ >> >> Complete implementation resides in vector-unstable branch of panama/dev >> repository [4]. > > This looks great, and it's very impressive. Unfortunately, there are few > of us sufficiently knowledgeable about Panama to review it in the detail > that perhaps it deserves. I'm happy with it. > > However, we need tests for the new assembly instructions, so please add some > to aarch64_asmtest.py and update macroassemler.cpp. > > Also, aarch64.ad is getting to be far too large, and perhaps all the vector > stuff should be moved into a new file. 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 thomas.stuefe at gmail.com Fri May 22 17:02:13 2020 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 22 May 2020 19:02:13 +0200 Subject: [aarch64-port-dev ] RFR(M): 8243392: Remodel CDS/Metaspace storage reservation In-Reply-To: <2cb02a62-954d-c261-2553-02b7e2ab4efb@oracle.com> References: <525df209-5bb6-47b5-474a-f0c0c44ca65e@oracle.com> <4e911098-ebdc-3222-5b6d-970a612b3884@oracle.com> <8bf736b3-9ab1-86b7-fd22-230e449b1b9f@oracle.com> <2cb02a62-954d-c261-2553-02b7e2ab4efb@oracle.com> Message-ID: Thank you Coleen! I wait until tomorrow, if I do not hear any objections I will push. ..Thomas On Fri, May 22, 2020 at 2:17 PM wrote: > > > On 5/21/20 2:26 AM, Thomas St?fe wrote: > > Hi all, > > tests went through successfully at SAP two nights in a row. Ioi gave his > okay, and I would like to push today or tomorrow. Any remaining objections`? > > > None from me. Ship it! > Coleen > > > The current, final version is: > > full: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ > delta: > http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ > > Thank you, > > Thomas > > On Wed, May 20, 2020 at 1:43 AM Ioi Lam wrote: > >> Hi Thomas, >> >> The testing took a little longer than I expected. I've run your previous >> version: >> >> >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ >> >> In our CI tiers 1/4. No failures. >> >> I didn't run your latest version. I would suggesting testing it with your >> own CI as well as in jdk-submit before pushing (after you get OKs from >> other reviewers). >> >> Thumbs up. >> - Ioi >> >> >> On 5/19/20 7:40 AM, Thomas St?fe wrote: >> >> Hi guys, >> >> new webrev: >> >> full: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.04/webrev/ >> delta: >> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev_delta.04/webrev/ >> >> Mostly format changes, breaking up at column 80 as Andrew requested. >> >> The only changes which matter is the removal of the unnecessary include >> in arguments.cpp as Coleen suggested; and to not validate SharedBaseAddress >> anymore at runtime, as Ioi requested. >> >> Also rebased to head. >> >> Thanks, Thomas >> >> >> >> >> On Tue, May 19, 2020 at 6:38 AM Ioi Lam wrote: >> >>> >>> >>> On 5/18/20 7:37 AM, Thomas St?fe wrote: >>> >>> Hi all, >>> >>> fourth webrev: >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.03/webrev/ >>> >>> I rebased atop of >>> >>> changeset: 59325:1ba9a9a3f948 >>> summary: 8244433: Remove saving of RSP in Assembler::pusha_uncached() >>> >>> so, atop of "8241825: Make compressed oops and compressed class pointers >>> independent (x86_64, PPC, S390)". >>> >>> The changes are very small this time, see notes below: >>> >>> @Ioi: >>> >>> >Hi Thomas, >>> >>> >I am running your patch in out CI pipeline now. Some comments: >>> >>> >[2] Does JDK-8243535 exist with the current jdk/jdk repo? >>> >>> I assigned JDK-8243535 to me and I'm working on a patch. But I would >>> like to keep that separate from this work, since this patch is already >>> large. And I would like to fix JDK-8243535 after this remodel patch has >>> been pushed, which makes some minor things easier. That would leave a small >>> time window where NMT does mis-track class space as shared class space, but >>> that is not a big issue, it does not even disturb any test. Which in itself >>> is something we may want to fix, come to think about it. >>> >>> >>> > [3] I think this can be put in header file. >>> > >>> > bool Metaspace::class_space_is_initialized() { >>> > return _class_space_list != NULL; >>> > } >>> >>> Done. >>> >>> > [7] argument.cpp checks this: >>> > >>> > if (UseSharedSpaces || DumpSharedSpaces) { >>> > if >>> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >>> > log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid >>> for this platform, option will be ignored.", >>> > p2i((address)SharedBaseAddress)); >>> > FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >>> > } >>> > } >>> > >>> > but initialize_dumptime_shared_and_meta_spaces aligns up the >>> SharedBaseAddress before doing the assert. >>> > >>> > void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >>> > assert(DumpSharedSpaces, "should be called for dump time only"); >>> > >>> > const size_t reserve_alignment = >>> MetaspaceShared::reserved_space_alignment(); >>> > char* shared_base = (char*)align_up((char*)SharedBaseAddress, >>> reserve_alignment); >>> > >>> > #ifdef _LP64 >>> > >>> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >>> "Sanity"); >>> > >>> > So theoretically shared_base may no longer be is_valid_base after the >>> align_up. It probably won't happen, but I think the code will be > much >>> clearer tofirst to align_up, then check for is_valid_base and reset to >>> default, and finally assert. >>> >>> The problem with that is that at the time this coding runs os::init() >>> did not yet run and we do not know yet allocation granularity. >>> >>> So I changed verification of SharedBaseAddress: I added the alignment as >>> you suggested and moved it to a later time in VM initialization, to CDS >>> initialization. >>> >>> >>> Is the call to check_SharedBaseAddress() necessary inside >>> MetaspaceShared::initialize_runtime_shared_and_meta_spaces()? >>> SharedBaseAddress is currently ignored at run time. Does your patch change >>> that behavior? >>> >>> >[8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >>> following block can be simplified: >>> > >>> > if (!_shared_rs.is_reserved()) { >>> > // Get a reserved space anywhere if attaching at the >>> SharedBaseAddress fails: >>> > if (UseCompressedClassPointers) { >>> > // If we need a compressed class space too, let the platform >>> handle the reservation. >>> > _shared_rs = >>> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >>> > } else { >>> > // anywhere is fine. >>> > _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >>> large */, (char*)NULL); >>> > } >>> > } >>> > >>> > ... if you change the declaration to: >>> > >>> > static ReservedSpace >>> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >>> ReservedSpace();}); >>> >>> I'd like to avoid keep the method LP64 only, but I rewrote the section >>> somewhat to be more clearer. >>> >>> The new code looks good. >>> >>> > [9] I think the #ifdef _LP64 is not necessary: >>> > >>> > #ifdef _LP64 >>> > // Some sanity checks after reserving address spaces for archives >>> and class space. >>> > assert(archive_space_rs.is_reserved(), "Sanity"); >>> > if (Metaspace::using_class_space()) { >>> > // Class space must closely follow the archive space. Both >>> spaces must be aligned correctly. >>> > assert(class_space_rs.is_reserved(), "A class space should have >>> been reserved"); >>> > assert(class_space_rs.base() >= archive_space_rs.end(), "class >>> space should follow the cds archive space"); >>> > assert(is_aligned(archive_space_rs.base(), >>> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >>> > assert(is_aligned(class_space_rs.base(), >>> Metaspace::reserve_alignment()), "class space misaligned"); >>> > } >>> > #endif >>> >>> I removed the #ifdef, but replaced it with an #ifdef ASSERT. Which is >>> also not needed, technically, but makes it clear that this section is >>> debugging checks only. >>> >>> >>> OK. >>> >>> The rest of the code looks good to me. I am going to run your latest >>> patch in our CI and will report the results. >>> >>> Thanks >>> - Ioi >>> >>> ---- >>> >>> @Coleen: >>> >>> > >>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/src/hotspot/share/memory/metaspace/ >>> >virtualSpaceList.cpp.udiff.html >>> > >>> >Why did you make this change? Shouldn't the caller align it? >>> >>> >>> You are right, I removed the assert. >>> >>> --- >>> >>> Thanks all for your review work, >>> >>> ..Thomas >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Fri, May 8, 2020 at 7:37 AM Ioi Lam wrote: >>> >>>> Hi Thomas, >>>> >>>> I am running your patch in out CI pipeline now. Some comments: >>>> >>>> [1] Do we still need to use _class_space_list? It looks like we just >>>> have a single range. Is _class_space_list->current_virtual_space() always >>>> the same VS? >>>> >>>> if (_class_space_list != NULL) { >>>> address base = >>>> (address)_class_space_list->current_virtual_space()->bottom(); >>>> address top = base + compressed_class_space_size(); >>>> st->print("Compressed class space mapped at: " PTR_FORMAT "-" >>>> PTR_FORMAT ", size: " SIZE_FORMAT, >>>> p2i(base), p2i(top), top - base); >>>> >>>> [2] Does JDK-8243535 exist with the current jdk/jdk repo? >>>> >>>> // This does currently not work because rs may be the result of a >>>> split operation >>>> // and NMT seems not to be able to handle splits. >>>> // See JDK-8243535. >>>> // MemTracker::record_virtual_memory_type((address)rs.base(), >>>> mtClass); >>>> >>>> >>>> [3] I think this can be put in header file. >>>> >>>> bool Metaspace::class_space_is_initialized() { >>>> return _class_space_list != NULL; >>>> } >>>> >>>> [4] Why does the CCS need to follow UseLargePagesInMetaspace? This is >>>> the reason for the >>>> gap in the following chart: >>>> >>>> // We do this by reserving space for the ccs behind the archives. >>>> Note however that >>>> // ccs follows a different alignment >>>> (Metaspace::reserve_alignment), so there may >>>> // be a gap between ccs and cds. >>>> // We use a similar layout at runtime, see >>>> reserve_address_space_for_archives(). >>>> // >>>> // +-- SharedBaseAddress (default = >>>> 0x800000000) >>>> // v >>>> // +-..---------+---------+ ... >>>> +----+----+----+--------+--------------------+ >>>> // | Heap | Archive | | MC | RW | RO | [gap] | class >>>> space | >>>> // +-..---------+---------+ ... >>>> +----+----+----+--------+--------------------+ >>>> // |<-- MaxHeapSize -->| |<-- UnscaledClassSpaceMax = 4GB >>>> -->| >>>> >>>> >>>> _reserve_alignment is determined here: >>>> >>>> void Metaspace::ergo_initialize() { >>>> if (DumpSharedSpaces) { >>>> // Using large pages when dumping the shared archive is currently >>>> not implemented. >>>> FLAG_SET_ERGO(UseLargePagesInMetaspace, false); >>>> } >>>> >>>> size_t page_size = os::vm_page_size(); >>>> if (UseLargePages && UseLargePagesInMetaspace) { >>>> page_size = os::large_page_size(); >>>> } >>>> >>>> _commit_alignment = page_size; >>>> _reserve_alignment = MAX2(page_size, >>>> (size_t)os::vm_allocation_granularity()); >>>> >>>> But when CDS is enabled, the RS is reserved without large pages, so it >>>> should be possible to incrementally commit the CCS using just >>>> os::vm_allocation_granularity(). >>>> >>>> [5] I see the aarch64 code in >>>> Metaspace::reserve_address_space_for_compressed_classes has been changed. >>>> Is this necessary for this RFE, or is it a separate improvement that can be >>>> done in a different RFE? >>>> >>>> [6] For AARCH64, should we skip the part that reserves it right above >>>> the heap? Or does AARCH64 always allocate the heap such that it's a >>>> preferable address? >>>> >>>> // case (b) >>>> ReservedSpace rs; >>>> >>>> // Try right above the Java heap... >>>> address base = align_up(CompressedOops::end(), >>>> Metaspace::reserve_alignment()); >>>> assert(base != NULL, "Sanity"); >>>> >>>> const size_t size = align_up(CompressedClassSpaceSize, >>>> Metaspace::reserve_alignment()); >>>> if (CompressedKlassPointers::is_valid_base(base)) { >>>> rs = ReservedSpace(size, Metaspace::reserve_alignment(), false /* >>>> large */, (char*)base); >>>> } >>>> >>>> // ...failing that, reserve anywhere, but let platform do optimized >>>> placement: >>>> if (!rs.is_reserved()) { >>>> rs = >>>> Metaspace::reserve_address_space_for_compressed_classes(size); >>>> } >>>> >>>> [7] argument.cpp checks this: >>>> >>>> if (UseSharedSpaces || DumpSharedSpaces) { >>>> if >>>> (!CompressedKlassPointers::is_valid_base((address)SharedBaseAddress)) { >>>> log_warning(cds)("SharedBaseAddress=" PTR_FORMAT " is invalid for >>>> this platform, option will be ignored.", >>>> p2i((address)SharedBaseAddress)); >>>> FLAG_SET_DEFAULT(SharedBaseAddress, default_SharedBaseAddress()); >>>> } >>>> } >>>> >>>> but initialize_dumptime_shared_and_meta_spaces aligns up the >>>> SharedBaseAddress before doing the assert. >>>> >>>> void MetaspaceShared::initialize_dumptime_shared_and_meta_spaces() { >>>> assert(DumpSharedSpaces, "should be called for dump time only"); >>>> >>>> const size_t reserve_alignment = >>>> MetaspaceShared::reserved_space_alignment(); >>>> char* shared_base = (char*)align_up((char*)SharedBaseAddress, >>>> reserve_alignment); >>>> >>>> #ifdef _LP64 >>>> >>>> assert(CompressedKlassPointers::is_valid_base((address)shared_base), >>>> "Sanity"); >>>> >>>> So theoretically shared_base may no longer be is_valid_base after the >>>> align_up. It probably won't happen, but I think the code will be much >>>> clearer tofirst to align_up, then check for is_valid_base and reset to >>>> default, and finally assert. >>>> >>>> [8] In MetaspaceShared::initialize_dumptime_shared_and_meta_spaces, the >>>> following block can be simplified: >>>> >>>> if (!_shared_rs.is_reserved()) { >>>> // Get a reserved space anywhere if attaching at the >>>> SharedBaseAddress fails: >>>> if (UseCompressedClassPointers) { >>>> // If we need a compressed class space too, let the platform >>>> handle the reservation. >>>> _shared_rs = >>>> Metaspace::reserve_address_space_for_compressed_classes(cds_total); >>>> } else { >>>> // anywhere is fine. >>>> _shared_rs = ReservedSpace(cds_total, reserve_alignment, false /* >>>> large */, (char*)NULL); >>>> } >>>> } >>>> >>>> ... if you change the declaration to: >>>> >>>> static ReservedSpace >>>> reserve_address_space_for_compressed_classes(size_t size) NOT_LP64({ return >>>> ReservedSpace();}); >>>> >>>> [9] I think the #ifdef _LP64 is not necessary: >>>> >>>> #ifdef _LP64 >>>> // Some sanity checks after reserving address spaces for archives >>>> and class space. >>>> assert(archive_space_rs.is_reserved(), "Sanity"); >>>> if (Metaspace::using_class_space()) { >>>> // Class space must closely follow the archive space. Both spaces >>>> must be aligned correctly. >>>> assert(class_space_rs.is_reserved(), "A class space should have >>>> been reserved"); >>>> assert(class_space_rs.base() >= archive_space_rs.end(), "class >>>> space should follow the cds archive space"); >>>> assert(is_aligned(archive_space_rs.base(), >>>> MetaspaceShared::reserved_space_alignment()), "Archive space misaligned"); >>>> assert(is_aligned(class_space_rs.base(), >>>> Metaspace::reserve_alignment()), "class space misaligned"); >>>> } >>>> #endif >>>> >>>> The rest of the code looks OK to me, but I may take a look at it again >>>> after getting more sleep :-) >>>> >>>> Thanks >>>> - Ioi >>>> >>>> >>>> >>>> >>>> On 5/7/20 7:21 AM, Thomas St?fe wrote: >>>> >>>> Hi all, >>>> >>>> please take a look at the third iteration of this change: >>>> >>>> >>>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.02/webrev/ >>>> >>>> Changes in this version: >>>> >>>> - at the request of Coleen (sorry I did not see your post earlier) I >>>> removed all platform dependent files and put the platform dependent coding >>>> back to metaspace.cpp and compressedOops.cpp to ease the review pain. I >>>> used plain platform defines though (#ifdef AARCH64) instead of hiding them >>>> behind another macro to make things clearer. Note that I still intent to >>>> put this code away into the platform corners but will do so in a follow up >>>> RFE. >>>> >>>> - I reinstated, in a fashion, the special handling of reservations on >>>> Windows. On all platforms we reserve address space to map the archive files >>>> in with a subsequent mapping operation. However, on Windows, we cannot use >>>> MapViewOfFile() into an existing mapping. So I remove the mapping again >>>> before mapping the archives - see comment in code for details. >>>> >>>> All CI tests at SAP run through without problems, including on Win64 >>>> and aarch64, but I would be happy if others were to run test too. >>>> >>>> Thank you, Thomas >>>> >>>> On Tue, Apr 28, 2020 at 4:54 PM Thomas St?fe >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Could I have reviews for the following proposal of reworking cds/class >>>>> space reservation? >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8243392 >>>>> >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~stuefe/webrevs/rework-cds-ccs-reservation/webrev.00/webrev/ >>>>> >>>>> (Many thanks to Ioi Lam for so patiently explaining CDS internals to >>>>> me, and to Andrew Haley and Nick Gasson for help with aarch64!) >>>>> >>>>> Reservation of the compressed class space is needlessly complicated >>>>> and has some minor issues. It can be simplified and made clearer. >>>>> >>>>> The complexity stems from the fact that this area lives at the >>>>> intersection of two to three sub systems, depending on how one counts. >>>>> Metaspace, CDS, and the platform which may or may not its own view of how >>>>> to reserve class space. And this code has been growing organically over >>>>> time. >>>>> >>>>> One small example: >>>>> >>>>> ReservedSpace Metaspace::reserve_preferred_space(size_t size, size_t >>>>> alignment, >>>>> bool large_pages, >>>>> char *requested_addr, >>>>> bool >>>>> use_requested_addr) >>>>> >>>>> which I spent hours decoding, resulting in a very confused mail to >>>>> hs-runtime and aarch64-port-dev [2]. >>>>> >>>>> This patch attempts to simplify cds and metaspace setup a bit; to >>>>> comment implicit knowledge which is not immediately clear; to cleanly >>>>> abstract platform concerns like optimized class space placement; and to >>>>> disentangle cds from metaspace to solve issues which may bite us later with >>>>> Elastic Metaspace [4]. >>>>> >>>>> --- >>>>> >>>>> The main change is the reworked reservation mechanism. This is based >>>>> on Ioi's proposal [5]. >>>>> >>>>> When reserving class space, three things must happen: >>>>> >>>>> 1) reservation of the space obviously. If cds is active that space >>>>> must be in the vicinity of cds archives to be covered by compressed class >>>>> pointer encoding. >>>>> 2) setting up the internal Metaspace structures atop of that space >>>>> 3) setting up compressed class pointer encoding. >>>>> >>>>> In its current form, Metaspace may or may not do some or all of that >>>>> in one function >>>>> (Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>>> metaspace_rs, char* requested_addr, address cds_base);) - if cds is active, >>>>> it will reserve the space for Metaspace and hand it in, otherwise it will >>>>> create it itself. >>>>> >>>>> When discussing this in [2], Ioi proposed to move the reservation of >>>>> the class space completely out of Metaspace and make it a responsibility of >>>>> the caller always. This would reduce some complexity, and this patch >>>>> follows the proposal. >>>>> >>>>> I removed >>>>> Metaspace::allocate_metaspace_compressed_klass_ptrs(ReservedSpace >>>>> metaspace_rs, char* requested_addr, address cds_base); and all its sub >>>>> functions. >>>>> >>>>> (1) now has to always be done outside - a ReservedSpace for class >>>>> space has to be provided by the caller. However, Metaspace now offers a >>>>> utility function for reserving space at a "nice" location, and explicitly >>>>> doing nothing else: >>>>> >>>>> ReservedSpace >>>>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>>>> >>>>> this function can be redefined on a platform level for platform >>>>> optimized reservation, see below for details. >>>>> >>>>> (2) is taken care of by a new function, >>>>> Metaspace::initialize_class_space(ReservedSpace rs) >>>>> >>>>> (3) is taken care of a new function >>>>> CompressedKlassPointers::initialize(), see below for details. >>>>> >>>>> >>>>> So, class space now is set up three explicit steps: >>>>> >>>>> - First, reserve a suitable space by however means you want. For >>>>> convenience you may use >>>>> Metaspace::reserve_address_space_for_compressed_classes(), or you may roll >>>>> your own reservation. >>>>> - Next, tell Metaspace to use that range as backing storage for class >>>>> space: Metaspace::initialize_class_space(ReservedSpace rs) >>>>> - Finally, set up encoding. Encoding is independent from the concept >>>>> of a ReservedSpace, it just gets an address range, see below for details. >>>>> >>>>> Separating these steps and moving them out of the responsibility of >>>>> Metaspace makes this whole thing more flexible; it also removes unnecessary >>>>> knowledge (e.g. Metaspace does not need to know anything about either ccp >>>>> encoding or cds). >>>>> >>>>> --- >>>>> >>>>> How it comes together: >>>>> >>>>> If CDS is off, we just reserve a space using >>>>> Metaspace::reserve_address_space_for_compressed_classes(), initialize it >>>>> with Metaspace::initialize_class_space(ReservedSpace rs), then set up >>>>> compressed class pointer encoding covering the range of this class space. >>>>> >>>>> If CDS is on (dump time), we reserve large 4G space, either at >>>>> SharedBaseAddress or using >>>>> Metaspace::reserve_address_space_for_compressed_classes(); we then split >>>>> that into 3G archive space and 1G class space; we set up that space with >>>>> Metaspace as class space; then we set up compressed class pointer encoding >>>>> covering both archive space and cds. >>>>> >>>>> If CDS is on (run time), we reserve a large space, split it into >>>>> archive space (large enough to hold both archives) and class space, then >>>>> basically proceed as above. >>>>> >>>>> Note that this is almost exactly how things worked before (modulo some >>>>> minor fixes, e.g. alignment issues), only the code is reformed and made >>>>> more explicit. >>>>> >>>>> --- >>>>> >>>>> I moved compressed class pointer setup over to CompressedKlassPointers >>>>> and changed the interface: >>>>> >>>>> -void Metaspace::set_narrow_klass_base_and_shift(ReservedSpace >>>>> metaspace_rs, address cds_base) >>>>> +void CompressedKlassPointers::initialize(address addr, size_t len); >>>>> >>>>> Instead of feeding it a single ReservedSpace, which is supposed to >>>>> represent class space, and an optional alternate base if cds is on, now we >>>>> give it just an numeric address range. That range marks the limits to where >>>>> Klass structures are to be expected, and is the implicit promise that >>>>> outside that range no Klass structures will exist, so encoding has to cover >>>>> only this range. >>>>> >>>>> This range may contain just the class space; or class space+cds; or >>>>> whatever allocation scheme we come up with in the future. Encoding does not >>>>> really care how the memory is organized as long as the input range covers >>>>> all possible Klass locations. That way we remove knowledge about class >>>>> space/cds from compressed class pointer encoding. >>>>> >>>>> Moving it away from metaspace.cpp into the CompressedKlassPointers >>>>> class also mirrors CompressedOops::initialize(). >>>>> >>>>> --- >>>>> >>>>> I renamed _narrow_klass_range to just _range, because strictly >>>>> speaking this is the range un-narrow Klass pointers can have. >>>>> >>>>> As for the implementation of >>>>> CompressedKlassPointers::initialize(address addr, size_t len), I mimicked >>>>> very closely what happened before, so there should be almost no >>>>> differences. Since "almost no differences" sounds scary :) here are the >>>>> differences: >>>>> >>>>> - When CDS is active (dump or run time) we now always, >>>>> unconditionally, set the encoding range to 4G. This fixes a theoretical bug >>>>> discussed on aarch64-port-dev [1]. >>>>> >>>>> - When CDS is not active, we set the encoding range to the minimum >>>>> required length. Before, it was left at its default value of 4G. >>>>> >>>>> Both differences only affect aarch64, since they are currently the >>>>> only one using the range field in CompressedKlassPointers. >>>>> >>>>> I wanted to add an assert somewhere to test encoding of the very last >>>>> address of the CompressedKlassPointers range, again to prevent errors like >>>>> [3]. But I did not come up with a good place for this assert which would >>>>> cover also the encoding done by C1/C2. >>>>> >>>>> For the same reason I thought about introducing a mode where Klass >>>>> structures would be allocated in reverse order, starting at the end of the >>>>> ccs, but again left it out as too big a change. >>>>> >>>>> --- >>>>> >>>>> OS abstraction: platforms may have restrictions of what constitutes a >>>>> valid compressed class pointer encoding base. Or if not, they may have at >>>>> least preferences. There was logic like this in metaspace.cpp, which I >>>>> removed and cleanly factored out into platform dependent files, giving each >>>>> platform the option to add special logic. >>>>> >>>>> These are two new methods: >>>>> >>>>> - bool CompressedKlassPointers::is_valid_base(address p) >>>>> >>>>> to let the platform tell you whether it considers p to be a valid >>>>> encoding base. The only platform having these restrictions currently is >>>>> aarch64. >>>>> >>>>> - ReservedSpace >>>>> Metaspace::reserve_address_space_for_compressed_classes(size_t size); >>>>> >>>>> this hands over the process of allocating a range suitable for >>>>> compressed class pointer encoding to the platform. Most platforms will >>>>> allocate just anywhere, but some platforms may have a better strategy (e.g. >>>>> trying low memory first, trying only correctly aligned addresses and so >>>>> on). >>>>> >>>>> Beforehand, this coding existed in a similar form in metaspace.cpp for >>>>> aarch64 and AIX. For now, I left the AIX part out - it seems only half >>>>> done, and I want to check further if we even need it, if yes why not on >>>>> Linux ppc, and C1 does not seem to support anything other than base+offset >>>>> with shift either, but I may be mistaken. >>>>> >>>>> These two methods should give the platform enough control to implement >>>>> their own scheme for optimized class space placement without bothering any >>>>> shared code about it. >>>>> >>>>> Note about the form, I introduced two new platform dependent files, >>>>> "metaspace_.cpp" and "compressedOops_.cpp". I am not happy about >>>>> this but this seems to be what we generally do in hotspot, right? >>>>> >>>>> --- >>>>> >>>>> Metaspace reserve alignment vs cds alignment >>>>> >>>>> CDS was using Metaspace reserve alignment for CDS internal purposes. I >>>>> guess this was just a copy paste issue. It never caused problems since >>>>> Metaspace reserve alignment == page size, but that is not true anymore in >>>>> the upcoming Elastic Metaspace where reserve alignment will be larger. This >>>>> causes a number of issues. >>>>> >>>>> I separated those two cleanly. CDS now uses >>>>> os::vm_allocation_granularity. Metaspace::reserve_alignment is only used in >>>>> those two places where it is needed, when CDS creates the address space for >>>>> class space on behalf of the Metaspace. >>>>> >>>>> --- >>>>> >>>>> Windows special handling in CDS >>>>> >>>>> To simplify coding I removed the windows specific handling which left >>>>> out reservation of the archive. This was needed because windows cannot mmap >>>>> files into reserved regions. But fallback code exists in filemap.cpp for >>>>> this case which just reads in the region instead of mapping it. >>>>> >>>>> Should that turn out to be a performance problem, I will reinstate the >>>>> feature. But a simpler way would be reserve the archive and later just >>>>> before mmapping the archive file to release the archive space. That would >>>>> not only be simpler but give us the best guarantee that that address space >>>>> is actually available. But I'd be happy to leave that part out completely >>>>> if we do not see any performance problems on windows x64. >>>>> >>>>> --- >>>>> >>>>> NMT cannot deal with spaces which are split. This problem manifests in >>>>> that bookkeeping for class space is done under "Shared Classes", not >>>>> "Classes" as it should. This problem exists today too at dump time and >>>>> randomly at run time. But since I simplified the reservation, this problem >>>>> now shows up always, whether or not we map at the SharedBaseAddress. >>>>> While I could work around this problem, I'd prefer this problem to be >>>>> solved at the core, and NMT to have an option to recognize reservation >>>>> splits. So I'd rather not put a workaround for this into the patch but >>>>> leave it for fixing as a separate issue. I opened this issue to track it >>>>> [6]. >>>>> >>>>> --- >>>>> >>>>> Jtreg tests: >>>>> >>>>> I expanded the CompressedOops/CompressedClassPointers.java. I also >>>>> extended them to Windows. The tests now optionally omit strict class space >>>>> placement tests, since these tests heavily depend on ASLR and were the >>>>> reason they were excluded on Windows. However I think even without checking >>>>> for class space placement they make sense, just to see that the VM comes up >>>>> and lives with the many different settings we can run in. >>>>> >>>>> --- >>>>> >>>>> Tests: >>>>> >>>>> - I ran the patch through Oracles submit repo >>>>> - I ran tests manually for aarch64, zero, linux 32bit and windows x64 >>>>> - The whole battery of nightly tests at SAP, including ppc, ppcle and >>>>> aarch64, unfortunately excluding windows because of unrelated errors. >>>>> Windows x64 tests will be redone tonight. >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> Thomas >>>>> >>>>> [1] >>>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008804.html >>>>> [2] >>>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008757.html >>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8193266 >>>>> [4] https://bugs.openjdk.java.net/browse/JDK-8221173 >>>>> [5] >>>>> https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-April/008765.html >>>>> [6] https://bugs.openjdk.java.net/browse/JDK-8243535 >>>>> >>>>> >>>> >>> >> > From aph at redhat.com Fri May 22 17:40:12 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 22 May 2020 18:40:12 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> Message-ID: <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> On 5/22/20 5:12 PM, Paul Sandoz wrote: > I am not terribly familiar with the AArch64 code, but I would note > the Vector API comes with a bunch of unit tests should exercise the > code gen, just not as directly as I presume you would like. Yes, you've understood me: direct is what I want. The assembler tests are intended to make sure we generate exactly the right instructions, rather than having something painfully hard to debug later on. When a patch adds a lot of instructions to the assembler, that IMO is the right time to test that they generate correctly-encoded instructions. But yes, that can go into a follow-up patch, as long as it gets done fairly shortly. > To what extent do you feel we can follow up with additional issues > and fix them after the initial integration? We can do that. Note that after this patch, aarch64.ad is 21762 lines long. I know we don't have any hard-and-fast rule about this, but I'd rather it didn't get forgotten. Maybe I should do that one myself, but I guess I'd rather avoid the problem of version skew between the Panama repo and mainline. That'd make merging rather grim. Yang, against which repo is this webrev intended to be applied? -- 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 paul.sandoz at oracle.com Fri May 22 18:01:01 2020 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 22 May 2020 11:01:01 -0700 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> Message-ID: <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> > On May 22, 2020, at 10:40 AM, Andrew Haley wrote: > > On 5/22/20 5:12 PM, Paul Sandoz wrote: > >> I am not terribly familiar with the AArch64 code, but I would note >> the Vector API comes with a bunch of unit tests should exercise the >> code gen, just not as directly as I presume you would like. > > Yes, you've understood me: direct is what I want. The assembler tests > are intended to make sure we generate exactly the right instructions, > rather than having something painfully hard to debug later on. When a > patch adds a lot of instructions to the assembler, that IMO is the > right time to test that they generate correctly-encoded > instructions. But yes, that can go into a follow-up patch, as long as > it gets done fairly shortly. Ok. > >> To what extent do you feel we can follow up with additional issues >> and fix them after the initial integration? > > We can do that. Note that after this patch, aarch64.ad is 21762 lines > long. I know we don't have any hard-and-fast rule about this, but I'd > rather it didn't get forgotten. We have made changes similar in spirit to the x64 ad file (reducing in size at least), so I think it reasonable request before integration to reduce the cognitive and maintenance burden. (FWIW I don?t know to what extent some functionality is utilized by the auto vectorizer and whether that impacts its location or not.) > Maybe I should do that one myself, but > I guess I'd rather avoid the problem of version skew between the > Panama repo and mainline. That'd make merging rather grim. > > Yang, against which repo is this webrev intended to be applied? > I cannot speak for Yang but we have been generating webrevs from the Panama dev repo, branch vector-unstable (unfortunate name I know!) and doing: hg diff -r default Where the default is regularly, but manually, pulled from jdk/jdk. More specifically: - code is generally pushed to the vectorIntrinsics branch - on a manual but regular basis vectorIntrinsics is synced up to jdk/jdk (via the default branch). - on a manual but regular basis vector-unstable is synced with vectorIntrinsics - occasionally there are fixes pushed directly to vector-unstable for the purposes of integration (e.g. removal of the perf test or the x64 SVML stubs). Hth, Paul. From aph at redhat.com Sat May 23 09:16:07 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 23 May 2020 10:16:07 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> Message-ID: <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> On 5/22/20 7:01 PM, Paul Sandoz wrote: > We have made changes similar in spirit to the x64 ad file (reducing in size at least), so I think it reasonable request before integration to reduce the cognitive and maintenance burden. So here's a question: can the changes to the AArch64 back end be made to mainline now? Or is there a problem in that the C2 patterns being used don't exist? -- 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 Yang.Zhang at arm.com Mon May 25 08:26:45 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Mon, 25 May 2020 08:26:45 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> Message-ID: Hi Andrew Please check the following. >> We have made changes similar in spirit to the x64 ad file (reducing in size at least), so I think it reasonable request before integration to reduce the cognitive and maintenance burden. > So here's a question: can the changes to the AArch64 back end be made to mainline now? Or is there a problem in that the C2 patterns being used don't exist? X86 ad file has been refactored to reduce code size in a series of JBSs [1]. I also investigated how to make similar changes to AArch64 ad file in Aug 2019. In summary, these changes wouldn't have a great impact on AArch64. If making similar changes to AArch64, about ~200kb (1% of total code size) will be reduced [2]. So I don't think we need to make these changes to AArch64 for now. To reduce maintenance burden, I agree that all the vector stuff should be moved into a new file, just like AArch64 SVE has done [3]. All the SVE instructions are generated by m4 file and placed in aarch64_sve.ad. For newly added NEON instructions in Vector API, they are all generated by m4 file. In jdk master, what we need to do is that writing m4 file for existing vector instructions and placed them to a new file aarch64_neon.ad. If no question, I will do it right away. [1] https://bugs.openjdk.java.net/browse/JDK-8230015 [2] The data came from: I implement an example (merging vaddB/S/I/F) in AArch64 platform. The code size reduction in libjvm.so is ~15kb. If all the vector instructions are merged, the estimated size reduction would be ~200kb. The code size from vector support in AArch64 backend is ~450kb (2% of total size). Original libjvm.so is 20770256, while libjvm.so without vector support is 20317328. Based on the idea of generic vector operands, half of vector stuff can be removed. So the estimated size reduction is also ~200kb. [3] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2020-March/037628.html Regards Yang -----Original Message----- From: Andrew Haley Sent: Saturday, May 23, 2020 5:16 PM To: Paul Sandoz Cc: Yang Zhang ; hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; nd Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes On 5/22/20 7:01 PM, Paul Sandoz wrote: > We have made changes similar in spirit to the x64 ad file (reducing in size at least), so I think it reasonable request before integration to reduce the cognitive and maintenance burden. So here's a question: can the changes to the AArch64 back end be made to mainline now? Or is there a problem in that the C2 patterns being used don't exist? -- 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 gnu.andrew at redhat.com Mon May 25 15:48:22 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Mon, 25 May 2020 16:48:22 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b03 Upstream Sync Message-ID: Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/root/merge.changeset Changes in aarch64-shenandoah-jdk8u262-b03: - JDK-8037866: Replace the Fun class in tests with lambdas - JDK-8146612: C2: Precedence edges specification violated - JDK-8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format - JDK-8209413: AArch64: NPE in clhsdb jstack command - JDK-8216989: CardTableBarrierSetAssembler::gen_write_ref_array_post_barrier() does not check for zero length on AARCH64 - JDK-8217368: AArch64: C2 recursive stack locking optimisation not triggered - JDK-8229888: (zipfs) Updating an existing zip file does not preserve original permissions - JDK-8230597: Update GIFlib library to the 5.2.1 - JDK-8230769: BufImg_SetupICM add ReleasePrimitiveArrayCritical call in early return - JDK-8233880: Support compilers with multi-digit major version numbers - JDK-8237512: AArch64: aarch64TestHook leaks a BufferBlob - JDK-8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed - JDK-8241638: launcher time metrics always report 1 on Linux when _JAVA_LAUNCHER_DEBUG set - JDK-8243059: Build fails when --with-vendor-name contains a comma - JDK-8243474: [TESTBUG] removed three tests of 0 bytes - JDK-8244461: [JDK 8u] Build fails with glibc 2.32 - JDK-8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result Changes in aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20: - [backport] 8221435: Shenandoah should not mark through weak roots - [backport] 8221629: Shenandoah: Cleanup class unloading logic - [backport] 8222992: Shenandoah: Pre-evacuate all roots - [backport] 8223215: Shenandoah: Support verifying subset of roots - [backport] 8223774: Shenandoah: Refactor ShenandoahRootProcessor and family - [backport] 8224210: Shenandoah: Refactor ShenandoahRootScanner to support scanning CSet codecache roots - [backport] 8224508: Shenandoah: Need to update thread roots in final mark for piggyback ref update cycle - [backport] 8224579: ResourceMark not declared in shenandoahRootProcessor.inline.hpp with --disable-precompiled-headers - [backport] 8224679: Shenandoah: Make ShenandoahParallelCodeCacheIterator noncopyable - [backport] 8224751: Shenandoah: Shenandoah Verifier should select proper roots according to current GC cycle - [backport] 8225014: Separate ShenandoahRootScanner method for object_iterate - [backport] 8225216: gc/logging/TestMetaSpaceLog.java doesn't work for Shenandoah - [backport] 8225573: Shenandoah: Enhance ShenandoahVerifier to ensure roots to-space invariant - [backport] 8225590: Shenandoah: Refactor ShenandoahClassLoaderDataRoots API - [backport] 8226413: Shenandoah: Separate root scanner for SH::object_iterate() - [backport] 8230853: Shenandoah: replace leftover assert(is_in(...)) with rich asserts - [backport] 8231198: Shenandoah: heap walking should visit all roots most of the time - [backport] 8231244: Shenandoah: all-roots heap walking misses some weak roots - [backport] 8237632: Shenandoah: accept NULL fwdptr to cooperate with JVMTI and JFR - [backport] 8239786: Shenandoah: print per-cycle statistics - [backport] 8239926: Shenandoah: Shenandoah needs to mark nmethod's metadata - [backport] 8240671: Shenandoah: refactor ShenandoahPhaseTimings - [backport] 8240749: Shenandoah: refactor ShenandoahUtils - [backport] 8240750: Shenandoah: remove leftover files and mentions of ShenandoahAllocTracker - [backport] 8240868: Shenandoah: remove CM-with-UR piggybacking cycles - [backport] 8240872: Shenandoah: Avoid updating new regions from start of evacuation - [backport] 8240873: Shenandoah: Short-cut arraycopy barriers - [backport] 8240915: Shenandoah: Remove unused fields in init mark tasks - [backport] 8240948: Shenandoah: cleanup not-forwarded-objects paths after JDK-8240868 - [backport] 8241062: Shenandoah: rich asserts trigger "empty statement" inspection - [backport] 8241081: Shenandoah: Do not modify update-watermark concurrently - [backport] 8241093: Shenandoah: editorial changes in flag descriptions - [backport] 8241139: Shenandoah: distribute mark-compact work exactly to minimize fragmentation - [backport] 8241142: Shenandoah: should not use parallel reference processing with single GC thread - [backport] 8241351: Shenandoah: fragmentation metrics overhaul - [backport] 8241435: Shenandoah: avoid disabling pacing with "aggressive" - [backport] 8241520: Shenandoah: simplify region sequence numbers handling - [backport] 8241534: Shenandoah: region status should include update watermark - [backport] 8241583: Shenandoah: turn heap lock asserts into macros - [backport] 8241668: Shenandoah: make ShenandoahHeapRegion not derive from ContiguousSpace - [backport] 8241673: Shenandoah: refactor anti-false-sharing padding - [backport] 8241675: Shenandoah: assert(n->outcnt() > 0) at shenandoahSupport.cpp:2858 with java/util/Collections/FindSubList.java - [backport] 8241692: Shenandoah: remove ShenandoahHeapRegion::_reserved - [backport] 8241700: Shenandoah: Fold ShenandoahKeepAliveBarrier flag into ShenandoahSATBBarrier - [backport] 8241740: Shenandoah: remove ShenandoahHeapRegion::_heap - [backport] 8241743: Shenandoah: refactor and inline ShenandoahHeap::heap() - [backport] 8241748: Shenandoah: inline MarkingContext TAMS methods - [backport] 8241838: Shenandoah: no need to trash cset during final mark - [backport] 8241841: Shenandoah: ditch one of allocation type counters in ShenandoahHeapRegion - [backport] 8241842: Shenandoah: inline ShenandoahHeapRegion::region_number - [backport] 8241844: Shenandoah: rename ShenandoahHeapRegion::region_number - [backport] 8241845: Shenandoah: align ShenandoahHeapRegions to cache lines - [backport] 8241926: Shenandoah: only print heap changes for operations that directly affect it - [backport] 8241983: Shenandoah: simplify FreeSet logging - [backport] 8241985: Shenandoah: simplify collectable garbage logging - [backport] 8242040: Shenandoah: print allocation failure type - [backport] 8242041: Shenandoah: adaptive heuristics should account evac reserve in free target - [backport] 8242042: Shenandoah: tune down ShenandoahGarbageThreshold - [backport] 8242054: Shenandoah: New incremental-update mode - [backport] 8242075: Shenandoah: rename ShenandoahHeapRegionSize flag - [backport] 8242082: Shenandoah: Purge Traversal mode - [backport] 8242083: Shenandoah: split "Prepare Evacuation" tracking into cset/freeset counters - [backport] 8242089: Shenandoah: per-worker stats should be summed up, not averaged - [backport] 8242101: Shenandoah: coalesce and parallelise heap region walks during the pauses - [backport] 8242114: Shenandoah: remove ShenandoahHeapRegion::reset_alloc_metadata_to_shared - [backport] 8242130: Shenandoah: Simplify arraycopy-barrier dispatching - [backport] 8242211: Shenandoah: remove ShenandoahHeuristics::RegionData::_seqnum_last_alloc - [backport] 8242212: Shenandoah: initialize ShenandoahHeuristics::_region_data eagerly - [backport] 8242213: Shenandoah: remove ShenandoahHeuristics::_bytes_in_cset - [backport] 8242217: Shenandoah: Enable GC mode to be diagnostic/experimental and have a name - [backport] 8242227: Shenandoah: transit regions to cset state when adding to collection set - [backport] 8242228: Shenandoah: remove unused ShenandoahCollectionSet methods - [backport] 8242229: Shenandoah: inline ShenandoahHeapRegion liveness-related methods - [backport] 8242267: Shenandoah: regions space needs to be aligned by os::vm_allocation_granularity() - [backport] 8242271: Shenandoah: add test to verify GC mode unlock - [backport] 8242273: Shenandoah: accept either SATB or IU barriers, but not both - [backport] 8242301: Shenandoah: Inline LRB runtime call - [backport] 8242316: Shenandoah: Turn NULL-check into assert in SATB slow-path entry - [backport] 8242353: Shenandoah: micro-optimize region liveness handling - [backport] 8242365: Shenandoah: use uint16_t instead of jushort for liveness cache - [backport] 8242641: Shenandoah: clear live data and update TAMS optimistically - [backport] 8243238: Shenandoah: explicit GC request should wait for a complete GC cycle - [backport] 8243301: Shenandoah: ditch ShenandoahAllowMixedAllocs - [backport] 8243307: Shenandoah: remove ShCollectionSet::live_data - [backport] 8243395: Shenandoah: demote guarantee in ShenandoahPhaseTimings::record_workers_end - [backport] 8243463: Shenandoah: ditch total_pause counters - [backport] 8243464: Shenandoah: print statistic counters in time order - [backport] 8243465: Shenandoah: ditch unused pause_other, conc_other counters - [backport] 8243487: Shenandoah: make _num_phases illegal phase type - [backport] 8243494: Shenandoah: set counters once per cycle - [backport] 8243573: Shenandoah: rename GCParPhases and related code - [backport] 8243848: Shenandoah: Windows build fails after JDK-8239786 - [backport] 8244180: Shenandoah: carry Phase to ShWorkerTimingsTracker explicitly - [backport] 8244200: Shenandoah: build breakages after JDK-8241743 - [backport] 8244226: Shenandoah: per-cycle statistics contain worker data from previous cycles - [backport] 8244326: Shenandoah: global statistics should not accept bogus samples - [backport] 8244551: Shenandoah: Fix racy update of update_watermark - [backport] 8244730: Shenandoah: gc/shenandoah/options/TestHeuristicsUnlock.java should only verify the heuristics - [backport] 8244732: Shenandoah: move heuristics code to gc/shenandoah/heuristics - [backport] 8244737: Shenandoah: move mode code to gc/shenandoah/mode - [backport] 8244739: Shenandoah: break superclass dependency on ShenandoahNormalMode - [backport] 8244740: Shenandoah: rename ShenandoahNormalMode to ShenandoahSATBMode - Fix slowdebug build after JDK-8230853 backport - Shenandoah: add root statistics for string dedup table/queues - Shenandoah: fix build failures after JDK-8244737 backport - Shenandoah: specialize String Table scans for better pause performance Main issues of note: jdk8u262-b03 was initially merged on top of aarch64-shenandoah-jdk8u262-b02 and a number of recent AArch64 backports, without the recent Shenandoah merge. This is represented by the aarch64-shenandoah-jdk8u262-b03 tag. aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 represents the merging of these two streams of development, bringing together the b03 changes and the Shenandoah merge. It also includes "Shenandoah: fix build failures after JDK-8244737 backport", which was not part of the aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 tag. Stats below are for the b03 merge: diffstat for root b/.hgtags | 1 + b/THIRD_PARTY_README | 2 +- b/common/autoconf/generated-configure.sh | 6 +++--- b/common/autoconf/toolchain.m4 | 2 +- b/make/common/JavaCompilation.gmk | 2 +- 5 files changed, 7 insertions(+), 6 deletions(-) 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 b/.hgtags | 1 b/THIRD_PARTY_README | 2 b/make/CompileLaunchers.gmk | 2 b/src/macosx/bin/java_md_macosx.c | 2 b/src/share/bin/java.c | 12 b/src/share/demo/nio/zipfs/src/com/sun/nio/zipfs/ZipFileSystem.java | 33 + b/src/share/javavm/export/jvm.h | 8 b/src/share/native/sun/awt/giflib/dgif_lib.c | 14 b/src/share/native/sun/awt/giflib/gif_err.c | 2 b/src/share/native/sun/awt/giflib/gif_hash.h | 2 b/src/share/native/sun/awt/giflib/gif_lib.h | 15 b/src/share/native/sun/awt/giflib/gif_lib_private.h | 2 b/src/share/native/sun/awt/giflib/gifalloc.c | 2 b/src/share/native/sun/awt/giflib/openbsd-reallocarray.c | 13 b/src/share/native/sun/awt/image/BufImgSurfaceData.c | 3 b/src/solaris/bin/java_md_solinux.c | 21 b/src/solaris/bin/java_md_solinux.h | 12 b/src/solaris/native/java/net/PlainDatagramSocketImpl.c | 1 b/src/solaris/native/java/net/PlainSocketImpl.c | 1 b/test/demo/zipfs/ZipFSPermissionsTest.java | 234 ++++++++++ b/test/demo/zipfs/ZipFSPermissionsTest.policy | 5 b/test/java/lang/ProcessBuilder/Basic.java | 200 +++----- b/test/java/nio/charset/StandardCharsets/Standard.java | 9 b/test/java/util/Collection/BiggernYours.java | 9 b/test/java/util/Collection/IteratorAtEnd.java | 18 b/test/java/util/Collection/MOAT.java | 121 ++--- b/test/java/util/Collections/AsLifoQueue.java | 10 b/test/java/util/NavigableMap/LockStep.java | 58 +- b/test/java/util/PriorityQueue/ForgetMeNot.java | 10 b/test/java/util/concurrent/BlockingQueue/Interrupt.java | 40 - b/test/java/util/concurrent/CyclicBarrier/Basic.java | 10 b/test/java/util/concurrent/Executors/Throws.java | 54 +- b/test/java/util/concurrent/FutureTask/Customized.java | 19 b/test/java/util/concurrent/ThreadPoolExecutor/ConfigChanges.java | 6 b/test/java/util/concurrent/ThreadPoolExecutor/ShutdownNowExecuteRace.java | 9 b/test/sun/nio/cs/FindOneCharEncoderBugs.java | 9 36 files changed, 573 insertions(+), 396 deletions(-) diffstat for hotspot b/.hgtags | 1 b/THIRD_PARTY_README | 2 b/src/share/vm/opto/gcm.cpp | 2 b/src/share/vm/opto/lcm.cpp | 9 +- b/src/share/vm/opto/node.cpp | 43 +++++----- b/src/share/vm/opto/node.hpp | 39 ++++++++- b/src/share/vm/prims/jvm.h | 8 - b/src/share/vm/runtime/java.hpp | 6 - b/src/share/vm/runtime/vm_version.cpp | 2 b/test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java | 7 - 10 files changed, 82 insertions(+), 37 deletions(-) Both tags have been successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer 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 Mon May 25 19:10:12 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 25 May 2020 21:10:12 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b03 Upstream Sync In-Reply-To: References: Message-ID: <7a789d97-8ca7-d881-bbf5-df709d1a2e60@redhat.com> On 5/25/20 5:48 PM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/corba/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jaxp/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jaxws/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/langtools/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/nashorn/merge.changeset Look trivially good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b03/root/merge.changeset Looks good. > Ok to push? Yes, I think so. -- Thanks, -Aleksey From gnu.andrew at redhat.com Mon May 25 19:39:48 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 25 May 2020 19:39:48 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 6 new changesets Message-ID: <202005251939.04PJdmkD000353@aojmv0008.oracle.com> Changeset: 541794915ecb Author: serb Date: 2019-12-02 16:38 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/541794915ecb 8230597: Update GIFlib library to the 5.2.1 Reviewed-by: prr, psadhukhan, jdv ! THIRD_PARTY_README Changeset: 1d0763331a52 Author: andrew Date: 2020-05-19 05:11 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/1d0763331a52 Added tag jdk8u262-b03 for changeset 541794915ecb ! .hgtags Changeset: 62ed2d4cc777 Author: andrew Date: 2020-05-20 01:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/62ed2d4cc777 Merge jdk8u262-b03 ! .hgtags ! THIRD_PARTY_README Changeset: 73746b29568e Author: andrew Date: 2020-05-20 01:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/73746b29568e Added tag aarch64-shenandoah-jdk8u262-b03 for changeset 62ed2d4cc777 ! .hgtags Changeset: 760e17e3dd74 Author: andrew Date: 2020-05-24 18:50 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/760e17e3dd74 Merge shenandoah-merge-2020-05-20 ! .hgtags Changeset: 2770dbc115a5 Author: andrew Date: 2020-05-24 19:02 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/2770dbc115a5 Added tag aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 for changeset 760e17e3dd74 ! .hgtags From gnu.andrew at redhat.com Mon May 25 19:40:03 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 25 May 2020 19:40:03 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jaxws: 6 new changesets Message-ID: <202005251940.04PJe3MJ000570@aojmv0008.oracle.com> Changeset: a708c11c582d Author: serb Date: 2019-12-02 16:38 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/a708c11c582d 8230597: Update GIFlib library to the 5.2.1 Reviewed-by: prr, psadhukhan, jdv ! THIRD_PARTY_README Changeset: caa13cd34f71 Author: andrew Date: 2020-05-19 05:11 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/caa13cd34f71 Added tag jdk8u262-b03 for changeset a708c11c582d ! .hgtags Changeset: b8efdaabe444 Author: andrew Date: 2020-05-20 01:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/b8efdaabe444 Merge jdk8u262-b03 ! .hgtags ! THIRD_PARTY_README Changeset: d1d3a043b329 Author: andrew Date: 2020-05-20 01:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/d1d3a043b329 Added tag aarch64-shenandoah-jdk8u262-b03 for changeset b8efdaabe444 ! .hgtags Changeset: 794b416205fe Author: andrew Date: 2020-05-24 18:50 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/794b416205fe Merge shenandoah-merge-2020-05-20 ! .hgtags Changeset: 654c6d651801 Author: andrew Date: 2020-05-24 19:02 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jaxws/rev/654c6d651801 Added tag aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 for changeset 794b416205fe ! .hgtags From gnu.andrew at redhat.com Mon May 25 19:40:11 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 25 May 2020 19:40:11 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/langtools: 6 new changesets Message-ID: <202005251940.04PJeBZf000765@aojmv0008.oracle.com> Changeset: 6df22f7cfdf1 Author: serb Date: 2019-12-02 16:38 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/6df22f7cfdf1 8230597: Update GIFlib library to the 5.2.1 Reviewed-by: prr, psadhukhan, jdv ! THIRD_PARTY_README Changeset: 094173db293a Author: andrew Date: 2020-05-19 05:11 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/094173db293a Added tag jdk8u262-b03 for changeset 6df22f7cfdf1 ! .hgtags Changeset: 2fe1067e3d93 Author: andrew Date: 2020-05-20 01:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/2fe1067e3d93 Merge jdk8u262-b03 ! .hgtags ! THIRD_PARTY_README Changeset: 6d97a8a29d3a Author: andrew Date: 2020-05-20 01:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/6d97a8a29d3a Added tag aarch64-shenandoah-jdk8u262-b03 for changeset 2fe1067e3d93 ! .hgtags Changeset: 233f9e7a62f7 Author: andrew Date: 2020-05-24 18:50 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/233f9e7a62f7 Merge shenandoah-merge-2020-05-20 ! .hgtags Changeset: d5e52321f58f Author: andrew Date: 2020-05-24 19:02 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/langtools/rev/d5e52321f58f Added tag aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 for changeset 233f9e7a62f7 ! .hgtags From gnu.andrew at redhat.com Mon May 25 19:40:18 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 25 May 2020 19:40:18 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 6 new changesets Message-ID: <202005251940.04PJeIt1000919@aojmv0008.oracle.com> Changeset: 0b39fe441888 Author: serb Date: 2019-12-02 16:38 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/0b39fe441888 8230597: Update GIFlib library to the 5.2.1 Reviewed-by: prr, psadhukhan, jdv ! THIRD_PARTY_README Changeset: f5a3d8f60cf5 Author: andrew Date: 2020-05-19 05:11 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/f5a3d8f60cf5 Added tag jdk8u262-b03 for changeset 0b39fe441888 ! .hgtags Changeset: 4faa3f022f0c Author: andrew Date: 2020-05-20 01:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/4faa3f022f0c Merge jdk8u262-b03 ! .hgtags ! THIRD_PARTY_README Changeset: a71e6d72fe79 Author: andrew Date: 2020-05-20 01:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/a71e6d72fe79 Added tag aarch64-shenandoah-jdk8u262-b03 for changeset 4faa3f022f0c ! .hgtags Changeset: 367a20dd337f Author: andrew Date: 2020-05-24 18:50 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/367a20dd337f Merge shenandoah-merge-2020-05-20 ! .hgtags Changeset: 51b68bf696a9 Author: andrew Date: 2020-05-24 19:02 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/51b68bf696a9 Added tag aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 for changeset 367a20dd337f ! .hgtags From gnu.andrew at redhat.com Mon May 25 19:40:35 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Mon, 25 May 2020 19:40:35 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 10 new changesets Message-ID: <202005251940.04PJeZ6R001167@aojmv0008.oracle.com> Changeset: 97d09139b360 Author: mdoerr Date: 2020-03-10 10:46 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/97d09139b360 8146612: C2: Precedence edges specification violated Reviewed-by: kvn ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp Changeset: bd77de4e5e2b Author: serb Date: 2019-12-02 16:38 -0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/bd77de4e5e2b 8230597: Update GIFlib library to the 5.2.1 Reviewed-by: prr, psadhukhan, jdv ! THIRD_PARTY_README Changeset: d99632e69372 Author: chagedorn Date: 2020-02-28 15:33 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/d99632e69372 8239852: java/util/concurrent tests fail with -XX:+VerifyGraphEdges: assert(!VerifyGraphEdges) failed: verification should have failed Summary: Remove an assertion which was too strong for some valid IRs when running with -XX:+VerifyGraphEdges Reviewed-by: neliasso, thartmann ! src/share/vm/opto/gcm.cpp Changeset: 26ffadc256e1 Author: sgehwolf Date: 2020-05-06 21:03 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/26ffadc256e1 8244548: JDK 8u: sun.misc.Version.jdkUpdateVersion() returns wrong result Reviewed-by: aph, andrew ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/java.hpp ! src/share/vm/runtime/vm_version.cpp Changeset: 545fe7caa2fb Author: aeriksso Date: 2020-05-19 03:11 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/545fe7caa2fb 8150986: serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java failing because expects HPROF JAVA PROFILE 1.0.1 file format Reviewed-by: dcubed, dsamersoff, andrew ! test/serviceability/sa/jmap-hprof/JMapHProfLargeHeapTest.java Changeset: 60ba2af705dc Author: andrew Date: 2020-05-19 05:11 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/60ba2af705dc Added tag jdk8u262-b03 for changeset 545fe7caa2fb ! .hgtags Changeset: 504b65cd0a6b Author: andrew Date: 2020-05-20 01:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/504b65cd0a6b Merge jdk8u262-b03 ! .hgtags ! THIRD_PARTY_README ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/prims/jvm.h ! src/share/vm/runtime/vm_version.cpp Changeset: c60c19f910e1 Author: andrew Date: 2020-05-20 01:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/c60c19f910e1 Added tag aarch64-shenandoah-jdk8u262-b03 for changeset 504b65cd0a6b ! .hgtags Changeset: 79d36cdf6a33 Author: andrew Date: 2020-05-24 18:51 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/79d36cdf6a33 Merge shenandoah-merge-2020-05-20 ! .hgtags Changeset: 5f9cc2e08814 Author: andrew Date: 2020-05-24 19:02 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/5f9cc2e08814 Added tag aarch64-shenandoah-jdk8u262-b03-shenandoah-merge-2020-05-20 for changeset 79d36cdf6a33 ! .hgtags From aph at redhat.com Tue May 26 08:25:02 2020 From: aph at redhat.com (Andrew Haley) Date: Tue, 26 May 2020 09:25:02 +0100 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> Message-ID: <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> On 25/05/2020 09:26, Yang Zhang wrote: > In jdk master, what we need to do is that writing m4 file for existing > vector instructions and placed them to a new file aarch64_neon.ad. > If no question, I will do it right away. I'm not entirely sure that such a change is necessary now. In particular, reorganizing the existing vector instructions is IMO excessive, but I admit that it might be an improvement. But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? It'd help if this was possible. -- 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 xxinliu at amazon.com Tue May 26 22:57:34 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Tue, 26 May 2020 22:57:34 +0000 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: Hi, I make a new revision of JDK-8230552. May I ask the arm reviewers to take a look? http://cr.openjdk.java.net/~xliu/8230552/01/webrev/ I haven't made aarch64 stop() uses the trap mechanism because it deserves a standalone JBS. Another thing is I don't understand what's the benefit to use the signal handler for that. I do manage to reduce stop() code size per Ningsheng's request. It avoids from generating pusha if ShowMessageBoxOnError is off (default). It still acts as expect no matter ShowMessageBoxOnError is set or not. Since we now have got rid of the HaltNode right after Uncommon_trap callnode in release build, I don't think code bloat is an issue anymore. Thanks, --lx ?On 5/6/20, 1:19 AM, "aph at redhat.com" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 5/6/20 8:25 AM, Liu, Xin wrote: > Currently in AArch64 MacroAssembler::stop(), it will generate many > register saving instructions by pusha() before calling to debug64(). But > I think debug64() only uses the regs[] and pc arguments when > ShowMessageBoxOnError is on. Maybe we should at least only do the saving > and pc arg passing when ShowMessageBoxOnError is on in > MacroAssembler::stop(), as what x86 does in macroAssembler_x86.cpp? Maybe we should think about a better way to do it. All we have to do, after all, is put the reason into, say, r8, and execute a trap. We don't need to push and pop anything because the trap handler will do 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 Yang.Zhang at arm.com Wed May 27 02:59:11 2020 From: Yang.Zhang at arm.com (Yang Zhang) Date: Wed, 27 May 2020 02:59:11 +0000 Subject: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes In-Reply-To: <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> References: <275eb57c-51c0-675e-c32a-91b198023559@redhat.com> <719F9169-ABC4-408E-B732-F1BD9A84337F@oracle.com> <9a13f5df-d946-579d-4282-917dc7338dc8@redhat.com> <09BC0693-80E0-4F87-855E-0B38A6F5EFA2@oracle.com> <668e500e-f621-5a2c-a41e-f73536880f73@redhat.com> <1909fa9d-98bb-c2fb-45d8-540247d1ca8b@redhat.com> Message-ID: > But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? The new instructions can be classified as: 1. Instructions that can be matched with NEON instructions directly. MulVB and SqrtVF have been merged into jdk master already. The patch of AbsV is in review [1]. 2. Instructions that Jdk master has middle end support for, but they cannot be matched with NEON instructions directly. Such as AddReductionVL, MulReductionVL, And/Or/XorReductionV These new instructions can be moved into jdk master first, but for auto-vectorization, the performance might not get improved. May I have a new patch for these? 3. Panama/Vector API specific instructions Such as Load/StoreVector ( 16 bits), VectorReinterpret, VectorMaskCmp, MaxV/MinV, VectorBlend etc. These instructions cannot be moved into jdk master first because there isn't middle-end support. Regards Yang [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-May/008861.html -----Original Message----- From: Andrew Haley Sent: Tuesday, May 26, 2020 4:25 PM To: Yang Zhang ; Paul Sandoz Cc: hotspot-compiler-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; aarch64-port-dev at openjdk.java.net; nd Subject: Re: [aarch64-port-dev ] RFR (XXL): 8223347: Integration of Vector API (Incubator): AArch64 backend changes On 25/05/2020 09:26, Yang Zhang wrote: > In jdk master, what we need to do is that writing m4 file for existing > vector instructions and placed them to a new file aarch64_neon.ad. > If no question, I will do it right away. I'm not entirely sure that such a change is necessary now. In particular, reorganizing the existing vector instructions is IMO excessive, but I admit that it might be an improvement. But to my earlier question. please: can the new instructions be moved into jdk head first, and then merged into the Panama branch, or not? It'd help if this was possible. -- 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 Wed May 27 07:21:01 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 27 May 2020 15:21:01 +0800 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> <71630bf9-1cde-69b4-c376-6318957ea672@redhat.com> Message-ID: I see CSR review and submit tests are clear, so I pushed. Thanks, Ningsheng On 5/22/20 10:36 AM, Xiaohong Gong wrote: > Hi Andrew, > >> On 5/21/20 11:24 AM, Xiaohong Gong wrote: > > > I'v created a new patch to add the condition when inserting > > "DMBs" > > > before volatile load for C1/Interpreter. > > > The updated webrev: > > > http://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.01/ > > > > > > It adds a new function "is_c1_or_interpreter_only()" , which can > > > decide whether C2/JVMCI is used. Besides, since AOT also uses > > Graal > > > compiler as the codegen, it always return false if AOT mode is > > enabled. > > > > Looks good to me, thanks. > > > > As far as I remember, Graal does optimize volatile accesses to use > > ldar/stlr, or at least it will do so in the future, so if we're > > using AOT or JVMCI the safe thing to do is add the DMBs. > > Yes, exactly! It has a patch in Graal github to do this optimization (https://github.com/oracle/graal/pull/1772). > > Thanks, > Xiaohong > > -----Original Message----- > From: Andrew Haley > Sent: Thursday, May 21, 2020 10:06 PM > To: Xiaohong Gong ; Andrew Dinn ; Derek White ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net > Cc: nd > Subject: Re: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option > > On 5/21/20 11:24 AM, Xiaohong Gong wrote: >> I'v created a new patch to add the condition when inserting "DMBs" >> before volatile load for C1/Interpreter. >> The updated webrev: >> http://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.01/ >> >> It adds a new function "is_c1_or_interpreter_only()" , which can >> decide whether C2/JVMCI is used. Besides, since AOT also uses Graal >> compiler as the codegen, it always return false if AOT mode is enabled. > > Looks good to me, thanks. > > As far as I remember, Graal does optimize volatile accesses to use ldar/stlr, or at least it will do so in the future, so if we're using AOT or JVMCI the safe thing to do is add the DMBs. > > -- > 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 Wed May 27 07:23:13 2020 From: ningsheng.jian at arm.com (Ningsheng Jian) Date: Wed, 27 May 2020 15:23:13 +0800 Subject: [aarch64-port-dev ] RFR(L): 8231441: AArch64: Initial SVE backend support In-Reply-To: References: Message-ID: <42fca25d-7172-b4f3-335b-92e2b05e8195@arm.com> 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 Xiaohong.Gong at arm.com Wed May 27 07:23:10 2020 From: Xiaohong.Gong at arm.com (Xiaohong Gong) Date: Wed, 27 May 2020 07:23:10 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> <71630bf9-1cde-69b4-c376-6318957ea672@redhat.com> Message-ID: Hi Ningsheng, Thanks for the pushing! Best Regards, Xiaohong Gong -----Original Message----- From: Ningsheng Jian Sent: Wednesday, May 27, 2020 3:21 PM To: Xiaohong Gong ; Andrew Haley ; Andrew Dinn ; Derek White ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: Re: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option I see CSR review and submit tests are clear, so I pushed. Thanks, Ningsheng On 5/22/20 10:36 AM, Xiaohong Gong wrote: > Hi Andrew, > >> On 5/21/20 11:24 AM, Xiaohong Gong wrote: > > > I'v created a new patch to add the condition when inserting > > "DMBs" > > > before volatile load for C1/Interpreter. > > > The updated webrev: > > > http://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.01/ > > > > > > It adds a new function "is_c1_or_interpreter_only()" , which can > > > decide whether C2/JVMCI is used. Besides, since AOT also uses > > Graal > > > compiler as the codegen, it always return false if AOT mode is > > enabled. > > > > Looks good to me, thanks. > > > > As far as I remember, Graal does optimize volatile accesses to use > > ldar/stlr, or at least it will do so in the future, so if we're > > using AOT or JVMCI the safe thing to do is add the DMBs. > > Yes, exactly! It has a patch in Graal github to do this optimization (https://github.com/oracle/graal/pull/1772). > > Thanks, > Xiaohong > > -----Original Message----- > From: Andrew Haley > Sent: Thursday, May 21, 2020 10:06 PM > To: Xiaohong Gong ; Andrew Dinn > ; Derek White ; > aarch64-port-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net > Cc: nd > Subject: Re: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete > UseBarriersForVolatile option > > On 5/21/20 11:24 AM, Xiaohong Gong wrote: >> I'v created a new patch to add the condition when inserting "DMBs" >> before volatile load for C1/Interpreter. >> The updated webrev: >> http://cr.openjdk.java.net/~xgong/rfr/8243339/webrev.01/ >> >> It adds a new function "is_c1_or_interpreter_only()" , which can >> decide whether C2/JVMCI is used. Besides, since AOT also uses Graal >> compiler as the codegen, it always return false if AOT mode is enabled. > > Looks good to me, thanks. > > As far as I remember, Graal does optimize volatile accesses to use ldar/stlr, or at least it will do so in the future, so if we're using AOT or JVMCI the safe thing to do is add the DMBs. > > -- > 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 May 27 13:03:54 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 May 2020 14:03:54 +0100 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: On 15/05/2020 11:37, Doerr, Martin wrote: > Exactly, we get stop type + stop message + registers + instructions (unfortunately not disassembled for some reason) + nice stack trace. The "some reason" is that you're not calling VMError::report_and_die correctly. Do something like this: + VMError::report_and_die(INTERNAL_ERROR, msg, detail_msg, detail_args, thread, + pc, info, ucVoid, NULL, 0, 0); I'm working on an AArch64 version now. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Wed May 27 13:45:57 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 27 May 2020 13:45:57 +0000 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: Hi Andrew, I still see "Instructions" section in hex. But I can live with that. PPC change is already pushed: 8244949: [PPC64] Reengineer assembler stop function Thanks for taking care of the AArch64 version. Best regards, Martin > -----Original Message----- > From: Andrew Haley > Sent: Mittwoch, 27. Mai 2020 15:04 > To: Doerr, Martin ; Derek White > ; Ningsheng Jian ; Liu, > Xin ; hotspot-compiler-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information > when hitting a HaltNode for architectures other than x86 > > On 15/05/2020 11:37, Doerr, Martin wrote: > > Exactly, we get stop type + stop message + registers + instructions > (unfortunately not disassembled for some reason) + nice stack trace. > > The "some reason" is that you're not calling VMError::report_and_die > correctly. > > Do something like this: > > + VMError::report_and_die(INTERNAL_ERROR, msg, detail_msg, > detail_args, thread, > + pc, info, ucVoid, NULL, 0, 0); > > I'm working on an AArch64 version now. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > https://keybase.io/andrewhaley > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Wed May 27 14:12:07 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 27 May 2020 14:12:07 +0000 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: Hi Xin, I think Andrew's trap based version will be much better. But I'll leave the AArch64 part up to other people. > Another thing is I don't understand what's the benefit to > use the signal handler for that. Shorter code in the code cache (signal handler takes care of saving registers), better hs_err file (includes registers and instructions at the point at which the signal occurred, better stack trace: no nasty C-frames). Best regards, Martin > -----Original Message----- > From: Liu, Xin > Sent: Mittwoch, 27. Mai 2020 00:58 > To: aph at redhat.com; Ningsheng Jian ; aarch64- > port-dev at openjdk.java.net > Cc: Doerr, Martin ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(XS): Provide information when hitting a HaltNode for > architectures other than x86 > > Hi, > > I make a new revision of JDK-8230552. May I ask the arm reviewers to take a > look? > http://cr.openjdk.java.net/~xliu/8230552/01/webrev/ > > I haven't made aarch64 stop() uses the trap mechanism because it deserves > a standalone JBS. Another thing is I don't understand what's the benefit to > use the signal handler for that. > > I do manage to reduce stop() code size per Ningsheng's request. It avoids > from generating pusha if ShowMessageBoxOnError is off (default). It still acts > as expect no matter ShowMessageBoxOnError is set or not. Since we now > have got rid of the HaltNode right after Uncommon_trap callnode in release > build, I don't think code bloat is an issue anymore. > > Thanks, > --lx > > > > ?On 5/6/20, 1:19 AM, "aph at redhat.com" wrote: > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > On 5/6/20 8:25 AM, Liu, Xin wrote: > > Currently in AArch64 MacroAssembler::stop(), it will generate many > > register saving instructions by pusha() before calling to debug64(). But > > I think debug64() only uses the regs[] and pc arguments when > > ShowMessageBoxOnError is on. Maybe we should at least only do the > saving > > and pc arg passing when ShowMessageBoxOnError is on in > > MacroAssembler::stop(), as what x86 does in > macroAssembler_x86.cpp? > > Maybe we should think about a better way to do it. All we have > to do, after all, is put the reason into, say, r8, and execute > a trap. We don't need to push and pop anything because the trap > handler will do 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 derekw at marvell.com Wed May 27 14:17:28 2020 From: derekw at marvell.com (Derek White) Date: Wed, 27 May 2020 14:17:28 +0000 Subject: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option In-Reply-To: References: <5c755cf3-8c95-e224-49cf-88c7c8b54812@redhat.com> <2551a58f-bb05-b63d-b8ed-63f120a75eeb@redhat.com> <71630bf9-1cde-69b4-c376-6318957ea672@redhat.com> Message-ID: Xiaohong, thanks for including the ThunderX1 cleanup! - Derek -----Original Message----- From: Xiaohong Gong Sent: Wednesday, May 27, 2020 3:23 AM To: Ningsheng Jian ; Andrew Haley ; Andrew Dinn ; Derek White ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: [EXT] RE: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option ---------------------------------------------------------------------- Hi Ningsheng, Thanks for the pushing! Best Regards, Xiaohong Gong -----Original Message----- From: Ningsheng Jian Sent: Wednesday, May 27, 2020 3:21 PM To: Xiaohong Gong ; Andrew Haley ; Andrew Dinn ; Derek White ; aarch64-port-dev at openjdk.java.net; hotspot-compiler-dev at openjdk.java.net Cc: nd Subject: Re: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete UseBarriersForVolatile option I see CSR review and submit tests are clear, so I pushed. Thanks, Ningsheng On 5/22/20 10:36 AM, Xiaohong Gong wrote: > Hi Andrew, > >> On 5/21/20 11:24 AM, Xiaohong Gong wrote: > > > I'v created a new patch to add the condition when inserting > > "DMBs" > > > before volatile load for C1/Interpreter. > > > The updated webrev: > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Exgong_rfr_8243339_webrev.01_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=v4awzqAGspetRbA0GcI6qzWI4gEqvTZJanovmjlaOfc&s=usotLgy1ZYkvIvvmvMzZBgyVA8tbxdiENiMKxe-xqV8&e= > > > > > > It adds a new function "is_c1_or_interpreter_only()" , which can > > > decide whether C2/JVMCI is used. Besides, since AOT also uses > > Graal > > > compiler as the codegen, it always return false if AOT mode is > > enabled. > > > > Looks good to me, thanks. > > > > As far as I remember, Graal does optimize volatile accesses to use > > ldar/stlr, or at least it will do so in the future, so if we're > > using AOT or JVMCI the safe thing to do is add the DMBs. > > Yes, exactly! It has a patch in Graal github to do this optimization (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_oracle_graal_pull_1772&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=v4awzqAGspetRbA0GcI6qzWI4gEqvTZJanovmjlaOfc&s=BD3vlImO8sPL4QC9AGdC3Nrs-0FaO3hzd5uhecHCcjQ&e= ). > > Thanks, > Xiaohong > > -----Original Message----- > From: Andrew Haley > Sent: Thursday, May 21, 2020 10:06 PM > To: Xiaohong Gong ; Andrew Dinn > ; Derek White ; > aarch64-port-dev at openjdk.java.net; > hotspot-compiler-dev at openjdk.java.net > Cc: nd > Subject: Re: [aarch64-port-dev ] RFR: 8243339: AArch64: Obsolete > UseBarriersForVolatile option > > On 5/21/20 11:24 AM, Xiaohong Gong wrote: >> I'v created a new patch to add the condition when inserting "DMBs" >> before volatile load for C1/Interpreter. >> The updated webrev: >> https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.n >> et_-7Exgong_rfr_8243339_webrev.01_&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ& >> r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU97kngYUJk&m=v4awzqAGspetRbA0GcI6q >> zWI4gEqvTZJanovmjlaOfc&s=usotLgy1ZYkvIvvmvMzZBgyVA8tbxdiENiMKxe-xqV8& >> e= >> >> It adds a new function "is_c1_or_interpreter_only()" , which can >> decide whether C2/JVMCI is used. Besides, since AOT also uses Graal >> compiler as the codegen, it always return false if AOT mode is enabled. > > Looks good to me, thanks. > > As far as I remember, Graal does optimize volatile accesses to use ldar/stlr, or at least it will do so in the future, so if we're using AOT or JVMCI the safe thing to do is add the DMBs. > > -- > Andrew Haley (he/him) > Java Platform Lead Engineer > Red Hat UK Ltd. > =DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNjT0vmaU9 > 7kngYUJk&m=v4awzqAGspetRbA0GcI6qzWI4gEqvTZJanovmjlaOfc&s=FzoZCaoTBONlu > dy6T1fhIPmq8cP9SmBJZGaj8xZrN-g&e= > > https://urldefense.proofpoint.com/v2/url?u=https-3A__keybase.io_andrew > haley&d=DwIGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=gW0hANMfJfyELYt_X2mceubwzCNj > T0vmaU97kngYUJk&m=v4awzqAGspetRbA0GcI6qzWI4gEqvTZJanovmjlaOfc&s=gD2Ro- > lXyKC-MfVBk8CWQJ3SXcWYtJ3NGHDOdE9vINc&e= > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From aph at redhat.com Wed May 27 15:22:45 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 May 2020 16:22:45 +0100 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: On 27/05/2020 14:45, Doerr, Martin wrote: > I still see "Instructions" section in hex. But I can live with that. If you look further down the log, you should see the disassembly. PPC change is already pushed: 8244949: [PPC64] Reengineer assembler stop function -- 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 May 27 15:54:30 2020 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 May 2020 16:54:30 +0100 Subject: [aarch64-port-dev ] RFR: 8245986: AArch64: Provide information when hitting a HaltNode Message-ID: <92db8ab4-84e3-d425-4e9f-d6a77b0fa837@redhat.com> We need to provide a halt reason when hitting a C2 HaltNode on AArch64, and we need to do so without grossly bloating the code. http://cr.openjdk.java.net/~aph/8245986/ -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From martin.doerr at sap.com Wed May 27 15:57:02 2020 From: martin.doerr at sap.com (Doerr, Martin) Date: Wed, 27 May 2020 15:57:02 +0000 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: Indeed. Thanks for figuring this out. These variants of report_and_die are very confusing. Best regards, Martin > -----Original Message----- > From: Andrew Haley > Sent: Mittwoch, 27. Mai 2020 17:23 > To: Doerr, Martin ; Derek White > ; Ningsheng Jian ; Liu, > Xin ; hotspot-compiler-dev at openjdk.java.net > Cc: aarch64-port-dev at openjdk.java.net > Subject: Re: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information > when hitting a HaltNode for architectures other than x86 > > On 27/05/2020 14:45, Doerr, Martin wrote: > > I still see "Instructions" section in hex. But I can live with that. > > If you look further down the log, you should see the disassembly. > > > PPC change is already pushed: 8244949: [PPC64] Reengineer assembler stop > function > > > -- > 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 xxinliu at amazon.com Wed May 27 20:09:34 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Wed, 27 May 2020 20:09:34 +0000 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: Hi, Martin and Andrew, Yes, it's better. I compare two stacktraces and cframes in the previous stacktrace indeed disturb users from understanding their own problems. I reviewed Andrew's webrev. It looks good to me. I am happy to see that you solve rscratch1 clobber problem in such elegant way! Just one thing: for this instruction emit_int64((intptr_t)msg), can we safely say a pointer is always 64-bit on aarch64? According to arm document, in theory, aarch64 has the ILP32 data model, but I don't think we ever use ILP32 before on aarch64. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0490a/ar01s01.html May I ask Andrew to sponsor my patch when you push JDK-8245986? Now it become trivial. http://cr.openjdk.java.net/~xliu/8230552/02/webrev/ Thanks, --lx ?On 5/27/20, 7:13 AM, "Doerr, Martin" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi Xin, I think Andrew's trap based version will be much better. But I'll leave the AArch64 part up to other people. > Another thing is I don't understand what's the benefit to > use the signal handler for that. Shorter code in the code cache (signal handler takes care of saving registers), better hs_err file (includes registers and instructions at the point at which the signal occurred, better stack trace: no nasty C-frames). Best regards, Martin > -----Original Message----- > From: Liu, Xin > Sent: Mittwoch, 27. Mai 2020 00:58 > To: aph at redhat.com; Ningsheng Jian ; aarch64- > port-dev at openjdk.java.net > Cc: Doerr, Martin ; hotspot-compiler- > dev at openjdk.java.net > Subject: Re: RFR(XS): Provide information when hitting a HaltNode for > architectures other than x86 > > Hi, > > I make a new revision of JDK-8230552. May I ask the arm reviewers to take a > look? > http://cr.openjdk.java.net/~xliu/8230552/01/webrev/ > > I haven't made aarch64 stop() uses the trap mechanism because it deserves > a standalone JBS. Another thing is I don't understand what's the benefit to > use the signal handler for that. > > I do manage to reduce stop() code size per Ningsheng's request. It avoids > from generating pusha if ShowMessageBoxOnError is off (default). It still acts > as expect no matter ShowMessageBoxOnError is set or not. Since we now > have got rid of the HaltNode right after Uncommon_trap callnode in release > build, I don't think code bloat is an issue anymore. > > Thanks, > --lx > > > > On 5/6/20, 1:19 AM, "aph at redhat.com" wrote: > > CAUTION: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > On 5/6/20 8:25 AM, Liu, Xin wrote: > > Currently in AArch64 MacroAssembler::stop(), it will generate many > > register saving instructions by pusha() before calling to debug64(). But > > I think debug64() only uses the regs[] and pc arguments when > > ShowMessageBoxOnError is on. Maybe we should at least only do the > saving > > and pc arg passing when ShowMessageBoxOnError is on in > > MacroAssembler::stop(), as what x86 does in > macroAssembler_x86.cpp? > > Maybe we should think about a better way to do it. All we have > to do, after all, is put the reason into, say, r8, and execute > a trap. We don't need to push and pop anything because the trap > handler will do 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 gnu.andrew at redhat.com Thu May 28 06:43:38 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Thu, 28 May 2020 07:43:38 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b04 Upstream Sync Message-ID: <051aff48-3f65-8f0e-8643-c7bd5574a251@redhat.com> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/ Merge changesets: http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/corba/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxp/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxws/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04jdk/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/hotspot/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/langtools/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/nashorn/merge.changeset http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/root/merge.changeset Changes in aarch64-shenandoah-jdk8u262-b04: - JDK-8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() - JDK-8067796: (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null - JDK-8076475: Misuses of strncpy/strncat - JDK-8148886: SEGV in sun.java2d.marlin.Renderer._endRendering - JDK-8171934: ObjectSizeCalculator.getEffectiveMemoryLayoutSpecification() does not recognize OpenJDK's HotSpot VM - JDK-8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE - JDK-8243539: Copyright info (Year) should be updated for fix of 8241638 - JDK-8244777: ClassLoaderStats VM Op uses constant hash value Main issues of note: None, clean merge. 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 + b/src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java | 3 ++- 2 files changed, 3 insertions(+), 1 deletion(-) diffstat for jdk b/.hgtags | 1 b/make/CompileLaunchers.gmk | 2 b/src/macosx/bin/java_md_macosx.c | 2 b/src/share/bin/java.c | 2 b/src/share/classes/sun/java2d/ReentrantContext.java | 43 ++ b/src/share/classes/sun/java2d/ReentrantContextProvider.java | 169 ++++++++ b/src/share/classes/sun/java2d/ReentrantContextProviderCLQ.java | 89 ++++ b/src/share/classes/sun/java2d/ReentrantContextProviderTL.java | 123 ++++++ b/src/share/classes/sun/java2d/marlin/ByteArrayCache.java | 9 b/src/share/classes/sun/java2d/marlin/FloatArrayCache.java | 9 b/src/share/classes/sun/java2d/marlin/IntArrayCache.java | 9 b/src/share/classes/sun/java2d/marlin/MarlinCache.java | 6 b/src/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java | 76 +-- b/src/share/classes/sun/java2d/marlin/RendererContext.java | 31 - b/src/share/classes/sun/java2d/marlin/Version.java | 4 b/src/share/classes/sun/java2d/pipe/AAShapePipe.java | 141 +++--- b/src/share/classes/sun/security/util/DerInputStream.java | 48 +- b/src/share/classes/sun/security/util/DerValue.java | 4 b/src/share/classes/sun/security/util/ObjectIdentifier.java | 2 b/src/solaris/bin/java_md_solinux.c | 2 b/src/solaris/bin/java_md_solinux.h | 2 b/src/solaris/classes/java/lang/UNIXProcess.java | 3 b/src/windows/classes/java/lang/ProcessImpl.java | 3 b/test/java/lang/ProcessBuilder/Basic.java | 51 ++ b/test/java/security/cert/X509Certificate/X509BadCertificate.java | 5 b/test/java/security/cert/X509Certificate/bad-cert-2.pem | 21 + b/test/sun/java2d/marlin/CrashPaintTest.java | 205 ++++++++++ 27 files changed, 889 insertions(+), 173 deletions(-) diffstat for hotspot b/.hgtags | 1 b/agent/src/os/bsd/libproc_impl.c | 7 b/agent/src/os/linux/libproc_impl.c | 7 b/agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java | 7 b/src/os/bsd/dtrace/libjvm_db.c | 19 +- b/src/os/bsd/vm/decoder_machO.cpp | 1 b/src/os/solaris/dtrace/libjvm_db.c | 19 +- b/src/share/tools/hsdis/hsdis.c | 1 b/src/share/vm/classfile/classLoaderStats.hpp | 13 + b/src/share/vm/compiler/compileBroker.hpp | 3 b/src/share/vm/compiler/disassembler.cpp | 1 b/src/share/vm/runtime/arguments.cpp | 17 - b/src/share/vm/utilities/ostream.cpp | 12 - b/src/share/vm/utilities/vmError.cpp | 9 - b/test/serviceability/sa/ClhsdbJstackXcompStress.java | 107 ++++++++++++ b/test/serviceability/sa/LingeredAppWithRecComputation.java | 67 +++++++ 16 files changed, 244 insertions(+), 47 deletions(-) Successfully built on x86, x86_64, s390, s390x, ppc, ppc64, ppc64le & aarch64. Ok to push? Thanks, -- Andrew :) Senior Free Java Software Engineer 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 May 28 08:28:39 2020 From: shade at redhat.com (Aleksey Shipilev) Date: Thu, 28 May 2020 10:28:39 +0200 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b04 Upstream Sync In-Reply-To: <051aff48-3f65-8f0e-8643-c7bd5574a251@redhat.com> References: <051aff48-3f65-8f0e-8643-c7bd5574a251@redhat.com> Message-ID: <7b1b6f4b-c942-0609-5db9-80d1d4ae49c3@redhat.com> On 5/28/20 8:43 AM, Andrew Hughes wrote: > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/corba/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxp/merge.changeset Looks good. I notice separately that "jaxp" apparently has the tag: aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 ...that no other repos have? > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxws/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jdk/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/hotspot/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/langtools/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/nashorn/merge.changeset Looks good. > http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/root/merge.changeset Looks good. > Ok to push? Yes. -- Thanks, -Aleksey From aph at redhat.com Thu May 28 09:17:24 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 May 2020 10:17:24 +0100 Subject: [aarch64-port-dev ] [EXT] Re: RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> <7abc8ac0-0a1c-b306-8a62-78a94c98845a@redhat.com> Message-ID: <33bbd38d-a15c-8538-8725-ad1f1cfafead@redhat.com> On 27/05/2020 16:57, Doerr, Martin wrote: > Indeed. Thanks for figuring this out. > These variants of report_and_die are very confusing. They certainly are: any function with ten arguments is going to be hell's own confusing, but when you have overloads with different semantics and no explanation the reader is doomed. I'd add some comment but I'm worried my own lack of complete understanding might mislead people. -- 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 May 28 10:02:46 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 May 2020 11:02:46 +0100 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: On 27/05/2020 21:09, Liu, Xin wrote: > Yes, it's better. I compare two stacktraces and cframes in the previous stacktrace indeed disturb users from understanding their own problems. > I reviewed Andrew's webrev. It looks good to me. > I am happy to see that you solve rscratch1 clobber problem in such > elegant way! Great, thanks. > Just one thing: for this instruction emit_int64((intptr_t)msg), can we safely say a pointer is always 64-bit on aarch64? That's a fair point. I'll change it: there's no need for that code to depend on pointer size. > According to arm document, in theory, aarch64 has the ILP32 data > model, but I don't think we ever use ILP32 before on aarch64. If anyone ever makes IPL32 work, we'll be happy to fix HotSpot to run on it. > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0490a/ar01s01.html > > May I ask Andrew to sponsor my patch when you push JDK-8245986? > Now it become trivial. http://cr.openjdk.java.net/~xliu/8230552/02/webrev/ -- 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 zhuoren.wz at alibaba-inc.com Thu May 28 12:43:25 2020 From: zhuoren.wz at alibaba-inc.com (=?UTF-8?B?V2FuZyBaaHVvKFpodW9yZW4p?=) Date: Thu, 28 May 2020 20:43:25 +0800 Subject: [aarch64-port-dev ] =?utf-8?q?RFR=3A8246051=3A=5BAArch64=5DSIGBUS?= =?utf-8?q?_by_unaligned_Unsafe_compare=5Fand=5Fswap?= Message-ID: Hi, I found that on aarch64, SIGBUS happens when Unsafe compareAndSwapLong and compareAndSwapInt were used to access unaligned mem address in interpreter mode. In compiled code, InternalError will be thrown. We should fix the crash and throw InternalError in interpreter too. Please help review this patch. BUG: https://bugs.openjdk.java.net/browse/JDK-8246051 CR: http://cr.openjdk.java.net/~wzhuo/8246051/webrev.00/ Regards, Zhuoren From aph at redhat.com Thu May 28 16:52:26 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 May 2020 17:52:26 +0100 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: On 28/05/2020 11:02, Andrew Haley wrote: >> Just one thing: for this instruction emit_int64((intptr_t)msg), can we safely say a pointer is always 64-bit on aarch64? > That's a fair point. I'll change it: there's no need for that code to > depend on pointer size. http://cr.openjdk.java.net/~aph/8245986-2/ I'm trying to get better at not always assuming that pointers and int64_t can be freely exchanged, or that the world is little endian. I have a long way to go. -- 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 May 28 16:55:55 2020 From: aph at redhat.com (Andrew Haley) Date: Thu, 28 May 2020 17:55:55 +0100 Subject: [aarch64-port-dev ] RFR: 8245986: AArch64: Provide information when hitting a HaltNode In-Reply-To: <92db8ab4-84e3-d425-4e9f-d6a77b0fa837@redhat.com> References: <92db8ab4-84e3-d425-4e9f-d6a77b0fa837@redhat.com> Message-ID: <0c322e72-2935-ac1a-f620-54886eec7e5e@redhat.com> On 27/05/2020 16:54, Andrew Haley wrote: > We need to provide a halt reason when hitting a C2 HaltNode on > AArch64, and we need to do so without grossly bloating the code. > > http://cr.openjdk.java.net/~aph/8245986/ New webrev: http://cr.openjdk.java.net/~aph/8245986-2/ -- 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 xxinliu at amazon.com Thu May 28 19:37:48 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Thu, 28 May 2020 19:37:48 +0000 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: Hi, Andrew, Thank you to this JBS issue for aarch64. I think I understand the mechanism behind it. We always store and load 64 bits for a pointer and let type conversion do the job. You patch looks good to me. Thanks, --lx ?On 5/28/20, 9:53 AM, "Andrew Haley" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 28/05/2020 11:02, Andrew Haley wrote: >> Just one thing: for this instruction emit_int64((intptr_t)msg), can we safely say a pointer is always 64-bit on aarch64? > That's a fair point. I'll change it: there's no need for that code to > depend on pointer size. http://cr.openjdk.java.net/~aph/8245986-2/ I'm trying to get better at not always assuming that pointers and int64_t can be freely exchanged, or that the world is little endian. I have a long way to go. -- 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 Fri May 29 01:54:15 2020 From: nick.gasson at arm.com (Nick Gasson) Date: Fri, 29 May 2020 09:54:15 +0800 Subject: [aarch64-port-dev ] RFR:8246051:[AArch64]SIGBUS by unaligned Unsafe compare_and_swap In-Reply-To: References: Message-ID: On 05/28/20 20:43 PM, Wang Zhuo wrote: > I found that on aarch64, SIGBUS happens when Unsafe compareAndSwapLong and compareAndSwapInt were used to access unaligned mem address in interpreter mode. In compiled code, InternalError will be thrown. We should fix the crash and throw InternalError in interpreter too. > Please help review this patch. > > BUG: https://bugs.openjdk.java.net/browse/JDK-8246051 > CR: http://cr.openjdk.java.net/~wzhuo/8246051/webrev.00/ > Could you add a jtreg test for this? -- Nick From adinn at redhat.com Fri May 29 08:33:37 2020 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 29 May 2020 09:33:37 +0100 Subject: [aarch64-port-dev ] RFR: 8245986: AArch64: Provide information when hitting a HaltNode In-Reply-To: <0c322e72-2935-ac1a-f620-54886eec7e5e@redhat.com> References: <92db8ab4-84e3-d425-4e9f-d6a77b0fa837@redhat.com> <0c322e72-2935-ac1a-f620-54886eec7e5e@redhat.com> Message-ID: On 28/05/2020 17:55, Andrew Haley wrote: > On 27/05/2020 16:54, Andrew Haley wrote: >> We need to provide a halt reason when hitting a C2 HaltNode on >> AArch64, and we need to do so without grossly bloating the code. >> >> http://cr.openjdk.java.net/~aph/8245986/ > > New webrev: http://cr.openjdk.java.net/~aph/8245986-2/ Yes, very nice. I assume you tested it :-) Reviewed! regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill From aph at redhat.com Fri May 29 08:55:08 2020 From: aph at redhat.com (Andrew Haley) Date: Fri, 29 May 2020 09:55:08 +0100 Subject: [aarch64-port-dev ] RFR:8246051:[AArch64]SIGBUS by unaligned Unsafe compare_and_swap In-Reply-To: References: Message-ID: <02ee2fa8-b649-baf3-1158-0a62299a94b5@redhat.com> On 28/05/2020 13:43, Wang Zhuo(Zhuoren) wrote: > Hi, > I found that on aarch64, SIGBUS happens when Unsafe compareAndSwapLong and compareAndSwapInt were used to access unaligned mem address in interpreter mode. In compiled code, InternalError will be thrown. We should fix the crash and throw InternalError in interpreter too. > Please help review this patch. > > BUG: https://bugs.openjdk.java.net/browse/JDK-8246051 > CR: http://cr.openjdk.java.net/~wzhuo/8246051/webrev.00/ 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 zhuoren.wz at alibaba-inc.com Fri May 29 12:36:21 2020 From: zhuoren.wz at alibaba-inc.com (=?UTF-8?B?V2FuZyBaaHVvKFpodW9yZW4p?=) Date: Fri, 29 May 2020 20:36:21 +0800 Subject: [aarch64-port-dev ] =?utf-8?q?RFR=3A8246051=3A=5BAArch64=5DSIGBUS?= =?utf-8?q?_by_unaligned_Unsafe_compare=5Fand=5Fswap?= In-Reply-To: References: , Message-ID: Update patch. A jtreg test added http://cr.openjdk.java.net/~wzhuo/8246051/webrev.01/ Regards, Zhuoren ------------------------------------------------------------------ From:Nick Gasson Sent At:2020 May 29 (Fri.) 09:54 To:Sandler Cc:hotspot-compiler-dev\@openjdk.java.net ; aarch64-port-dev Subject:Re: [aarch64-port-dev ] RFR:8246051:[AArch64]SIGBUS by unaligned Unsafe compare_and_swap On 05/28/20 20:43 PM, Wang Zhuo wrote: > I found that on aarch64, SIGBUS happens when Unsafe compareAndSwapLong and compareAndSwapInt were used to access unaligned mem address in interpreter mode. In compiled code, InternalError will be thrown. We should fix the crash and throw InternalError in interpreter too. > Please help review this patch. > > BUG: https://bugs.openjdk.java.net/browse/JDK-8246051 > CR: http://cr.openjdk.java.net/~wzhuo/8246051/webrev.00/ > Could you add a jtreg test for this? -- Nick From gnu.andrew at redhat.com Fri May 29 18:43:10 2020 From: gnu.andrew at redhat.com (Andrew Hughes) Date: Fri, 29 May 2020 19:43:10 +0100 Subject: [aarch64-port-dev ] [RFR] [8u] 8u262-b04 Upstream Sync In-Reply-To: <7b1b6f4b-c942-0609-5db9-80d1d4ae49c3@redhat.com> References: <051aff48-3f65-8f0e-8643-c7bd5574a251@redhat.com> <7b1b6f4b-c942-0609-5db9-80d1d4ae49c3@redhat.com> Message-ID: <7eaa7483-afd2-ced8-439f-ebada44ef0fe@redhat.com> On 28/05/2020 09:28, Aleksey Shipilev wrote: > On 5/28/20 8:43 AM, Andrew Hughes wrote: >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/corba/merge.changeset > > Looks good. > >> http://cr.openjdk.java.net/~andrew/shenandoah-8/u262-b04/jaxp/merge.changeset > > Looks good. I notice separately that "jaxp" apparently has the tag: > aarch64-shenandoah-jdk8u262-b02-shenandoah-merge-2020-05-20 > > ...that no other repos have? > They all have it (it's the first tag for the recent Shenandoah merge), but it's (rightly) placed below aarch64-shenandoah-jdk8u262-b02 in the other repos. Is Mercurial the only VCS where you have to manually merge such metadata? I'll push this and fix that up in the merge of b05. Thanks, -- Andrew :) Senior Free Java Software Engineer 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 May 29 20:24:21 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 29 May 2020 20:24:21 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah: 3 new changesets Message-ID: <202005292024.04TKOLZW002960@aojmv0008.oracle.com> Changeset: ecb485e1572c Author: andrew Date: 2020-05-25 07:02 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/ecb485e1572c Added tag jdk8u262-b04 for changeset e1a42471eb39 ! .hgtags Changeset: db1fce5a01e2 Author: andrew Date: 2020-05-26 03:02 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/db1fce5a01e2 Merge jdk8u262-b04 ! .hgtags Changeset: 3c8795defc6b Author: andrew Date: 2020-05-26 03:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/rev/3c8795defc6b Added tag aarch64-shenandoah-jdk8u262-b04 for changeset db1fce5a01e2 ! .hgtags From gnu.andrew at redhat.com Fri May 29 20:24:29 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 29 May 2020 20:24:29 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/corba: 3 new changesets Message-ID: <202005292024.04TKOTnR003074@aojmv0008.oracle.com> Changeset: 61a6c87db285 Author: andrew Date: 2020-05-25 07:02 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/61a6c87db285 Added tag jdk8u262-b04 for changeset 1d0763331a52 ! .hgtags Changeset: e74f1c626071 Author: andrew Date: 2020-05-26 03:02 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/e74f1c626071 Merge jdk8u262-b04 ! .hgtags Changeset: f77fdacec841 Author: andrew Date: 2020-05-26 03:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/corba/rev/f77fdacec841 Added tag aarch64-shenandoah-jdk8u262-b04 for changeset e74f1c626071 ! .hgtags From gnu.andrew at redhat.com Fri May 29 20:24:59 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 29 May 2020 20:24:59 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/nashorn: 4 new changesets Message-ID: <202005292024.04TKOx97003519@aojmv0008.oracle.com> Changeset: eef87c0da03e Author: fyang Date: 2020-05-24 22:47 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/eef87c0da03e 8171934: ObjectSizeCalculator.getEffectiveMemoryLayoutSpecification() does not recognize OpenJDK's HotSpot VM Reviewed-by: aph, andrew Contributed-by: hedongbo at huawei.com ! src/jdk/nashorn/internal/ir/debug/ObjectSizeCalculator.java Changeset: e2a7c53cfa4d Author: andrew Date: 2020-05-25 07:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/e2a7c53cfa4d Added tag jdk8u262-b04 for changeset eef87c0da03e ! .hgtags Changeset: 04674a70f346 Author: andrew Date: 2020-05-26 03:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/04674a70f346 Merge jdk8u262-b04 ! .hgtags Changeset: 57e806de4194 Author: andrew Date: 2020-05-26 03:04 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/nashorn/rev/57e806de4194 Added tag aarch64-shenandoah-jdk8u262-b04 for changeset 04674a70f346 ! .hgtags From gnu.andrew at redhat.com Fri May 29 20:25:10 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 29 May 2020 20:25:10 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/jdk: 7 new changesets Message-ID: <202005292025.04TKPAYP003611@aojmv0008.oracle.com> Changeset: 88f31b017126 Author: lbourges Date: 2016-02-23 22:07 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/88f31b017126 8148886: SEGV in sun.java2d.marlin.Renderer._endRendering Summary: handle reentrancy in both AAShapePipe and MarlinRenderingEngine using new sun.java2d.ReentrantContextProvider implementations Reviewed-by: flar, prr + src/share/classes/sun/java2d/ReentrantContext.java + src/share/classes/sun/java2d/ReentrantContextProvider.java + src/share/classes/sun/java2d/ReentrantContextProviderCLQ.java + src/share/classes/sun/java2d/ReentrantContextProviderTL.java ! src/share/classes/sun/java2d/marlin/ByteArrayCache.java ! src/share/classes/sun/java2d/marlin/FloatArrayCache.java ! src/share/classes/sun/java2d/marlin/IntArrayCache.java ! src/share/classes/sun/java2d/marlin/MarlinCache.java ! src/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java ! src/share/classes/sun/java2d/marlin/RendererContext.java ! src/share/classes/sun/java2d/marlin/Version.java ! src/share/classes/sun/java2d/pipe/AAShapePipe.java + test/sun/java2d/marlin/CrashPaintTest.java Changeset: c36e31478c72 Author: lzang Date: 2020-04-27 12:32 +0800 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c36e31478c72 8243539: Copyright info (Year) should be updated for fix of 8241638 Reviewed-by: phh, andrew Contributed-by: Bin Liao ! make/CompileLaunchers.gmk ! src/macosx/bin/java_md_macosx.c ! src/share/bin/java.c ! src/solaris/bin/java_md_solinux.c ! src/solaris/bin/java_md_solinux.h Changeset: eb13744577fb Author: snazarki Date: 2015-03-23 10:13 -0400 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/eb13744577fb 8067796: (process) Process.waitFor(timeout, unit) doesn't throw NPE if timeout is less than, or equal to zero when unit == null Summary: Implement checking for NPE in Process implementation before other conditions Reviewed-by: martin, chegar, aph, andrew ! src/solaris/classes/java/lang/UNIXProcess.java ! src/windows/classes/java/lang/ProcessImpl.java ! test/java/lang/ProcessBuilder/Basic.java Changeset: 63cecc0bd71d Author: andrew Date: 2020-05-25 06:27 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/63cecc0bd71d 8028591: NegativeArraySizeException in sun.security.util.DerInputStream.getUnalignedBitString() Reviewed-by: mbalao ! src/share/classes/sun/security/util/DerInputStream.java ! src/share/classes/sun/security/util/DerValue.java ! src/share/classes/sun/security/util/ObjectIdentifier.java ! test/java/security/cert/X509Certificate/X509BadCertificate.java + test/java/security/cert/X509Certificate/bad-cert-2.pem Changeset: c0dd958bb895 Author: andrew Date: 2020-05-25 07:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/c0dd958bb895 Added tag jdk8u262-b04 for changeset 63cecc0bd71d ! .hgtags Changeset: a8662b1eba35 Author: andrew Date: 2020-05-26 03:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/a8662b1eba35 Merge jdk8u262-b04 ! .hgtags ! make/CompileLaunchers.gmk ! src/share/bin/java.c ! src/solaris/bin/java_md_solinux.c ! src/solaris/classes/java/lang/UNIXProcess.java Changeset: 3851e7e2d06e Author: andrew Date: 2020-05-26 03:05 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/jdk/rev/3851e7e2d06e Added tag aarch64-shenandoah-jdk8u262-b04 for changeset a8662b1eba35 ! .hgtags From gnu.andrew at redhat.com Fri May 29 20:25:18 2020 From: gnu.andrew at redhat.com (gnu.andrew at redhat.com) Date: Fri, 29 May 2020 20:25:18 +0000 Subject: [aarch64-port-dev ] hg: aarch64-port/jdk8u-shenandoah/hotspot: 6 new changesets Message-ID: <202005292025.04TKPIWE003697@aojmv0008.oracle.com> Changeset: 1848821ee85d Author: stuefe Date: 2020-05-14 08:48 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1848821ee85d 8244777: ClassLoaderStats VM Op uses constant hash value Reviewed-by: coleenp, jbachorik ! src/share/vm/classfile/classLoaderStats.hpp Changeset: e8a0af9fc1cb Author: sgehwolf Date: 2019-09-23 20:26 +0200 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/e8a0af9fc1cb 8196969: JTreg Failure: serviceability/sa/ClhsdbJstack.java causes NPE Summary: Account for serialized null scopes in NMethod Reviewed-by: aph, never, andrew ! agent/src/share/classes/sun/jvm/hotspot/code/NMethod.java + test/serviceability/sa/ClhsdbJstackXcompStress.java + test/serviceability/sa/LingeredAppWithRecComputation.java Changeset: 3a3803a0c789 Author: aph Date: 2020-04-03 14:14 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/3a3803a0c789 8076475: Misuses of strncpy/strncat Summary: Various small fixes around strncpy and strncat Reviewed-by: andrew ! agent/src/os/bsd/libproc_impl.c ! agent/src/os/linux/libproc_impl.c ! src/os/bsd/dtrace/libjvm_db.c ! src/os/bsd/vm/decoder_machO.cpp ! src/os/solaris/dtrace/libjvm_db.c ! src/share/tools/hsdis/hsdis.c ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 9cbafea410f5 Author: andrew Date: 2020-05-25 07:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/9cbafea410f5 Added tag jdk8u262-b04 for changeset 3a3803a0c789 ! .hgtags Changeset: 8f8b4e73e488 Author: andrew Date: 2020-05-26 03:03 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/8f8b4e73e488 Merge jdk8u262-b04 ! .hgtags ! src/share/tools/hsdis/hsdis.c ! src/share/vm/classfile/classLoaderStats.hpp ! src/share/vm/compiler/compileBroker.hpp ! src/share/vm/compiler/disassembler.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/vmError.cpp Changeset: 1ac56046129c Author: andrew Date: 2020-05-26 03:05 +0100 URL: https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1ac56046129c Added tag aarch64-shenandoah-jdk8u262-b04 for changeset 8f8b4e73e488 ! .hgtags From xxinliu at amazon.com Fri May 29 23:24:49 2020 From: xxinliu at amazon.com (Liu, Xin) Date: Fri, 29 May 2020 23:24:49 +0000 Subject: [aarch64-port-dev ] RFR(XS): Provide information when hitting a HaltNode for architectures other than x86 In-Reply-To: References: <92E14A43-E260-49D5-BF74-CB6331A2EB33@amazon.com> <0B03A385-BC1F-41B9-8B8F-02056BD5A706@amazon.com> <40eed1f3-27b9-5263-16c1-7563a6ff9082@arm.com> Message-ID: Hello, Since JDK-8245986(aarch64) has been resolved, may I ask a sponsor to push this change? it's like last mile of JDK-8230552. http://cr.openjdk.java.net/~xliu/8230552/02/webrev/ s390 has been reviewed by Martin. Thank Volker and OSU, I verified the new stop() mechanism on a ppc64le host. Thanks, --lx ?On 5/28/20, 3:03 AM, "Andrew Haley" wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On 27/05/2020 21:09, Liu, Xin wrote: > Yes, it's better. I compare two stacktraces and cframes in the previous stacktrace indeed disturb users from understanding their own problems. > I reviewed Andrew's webrev. It looks good to me. > I am happy to see that you solve rscratch1 clobber problem in such > elegant way! Great, thanks. > Just one thing: for this instruction emit_int64((intptr_t)msg), can we safely say a pointer is always 64-bit on aarch64? That's a fair point. I'll change it: there's no need for that code to depend on pointer size. > According to arm document, in theory, aarch64 has the ILP32 data > model, but I don't think we ever use ILP32 before on aarch64. If anyone ever makes IPL32 work, we'll be happy to fix HotSpot to run on it. > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0490a/ar01s01.html > > May I ask Andrew to sponsor my patch when you push JDK-8245986? > Now it become trivial. http://cr.openjdk.java.net/~xliu/8230552/02/webrev/ -- 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 Sat May 30 16:24:49 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 30 May 2020 16:24:49 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 14 on AArch64 Message-ID: <2122065987.648.1590855890399.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/openjdk-jtreg-nightly-tests/summary/2020/149/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 5,773; fail: 45 Build 1: aarch64/2020/jan/30 pass: 5,773; fail: 45 Build 2: aarch64/2020/feb/06 pass: 5,773; fail: 46 Build 3: aarch64/2020/feb/09 pass: 5,775; fail: 44 Build 4: aarch64/2020/apr/07 pass: 5,781; fail: 45 Build 5: aarch64/2020/may/05 pass: 5,762; fail: 45 Build 6: aarch64/2020/may/07 pass: 5,763; fail: 44 Build 7: aarch64/2020/may/12 pass: 5,761; fail: 46 Build 8: aarch64/2020/may/15 pass: 5,784; fail: 46 Build 9: aarch64/2020/may/28 pass: 5,785; fail: 45 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 8,831; fail: 524; error: 18 Build 1: aarch64/2020/jan/30 pass: 8,839; fail: 518; error: 17 Build 2: aarch64/2020/feb/06 pass: 8,838; fail: 517; error: 18 Build 3: aarch64/2020/feb/09 pass: 8,832; fail: 523; error: 18 Build 4: aarch64/2020/apr/07 pass: 8,844; fail: 505; error: 20 Build 5: aarch64/2020/may/05 pass: 8,839; fail: 515; error: 18 Build 6: aarch64/2020/may/07 pass: 8,835; fail: 517; error: 20 Build 7: aarch64/2020/may/12 pass: 8,836; fail: 517; error: 19 Build 8: aarch64/2020/may/15 pass: 8,845; fail: 509; error: 18 Build 9: aarch64/2020/may/28 pass: 8,838; fail: 516; error: 18 3 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2020/jan/23 pass: 4,031 Build 1: aarch64/2020/jan/30 pass: 4,031 Build 2: aarch64/2020/feb/03 pass: 4,031 Build 3: aarch64/2020/feb/06 pass: 4,031 Build 4: aarch64/2020/feb/09 pass: 4,031 Build 5: aarch64/2020/apr/07 pass: 4,031 Build 6: aarch64/2020/may/05 pass: 4,031 Build 7: aarch64/2020/may/07 pass: 4,031 Build 8: aarch64/2020/may/12 pass: 4,031 Build 9: aarch64/2020/may/15 pass: 4,031 Build 10: aarch64/2020/may/28 pass: 4,031 Previous results can be found here: http://openjdk.linaro.org/jdk14/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.63x Relative performance: Server critical-jOPS (nc): 9.29x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 204.57 Server 204.57 / Server 2014-04-01 (71.00): 2.88x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk14/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2020-01-24 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/023/results/ 2020-02-01 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/030/results/ 2020-02-08 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/037/results/ 2020-02-10 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/040/results/ 2020-04-08 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/098/results/ 2020-05-06 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/126/results/ 2020-05-09 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/128/results/ 2020-05-14 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/133/results/ 2020-05-17 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/136/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/2020/149/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk14/jcstress-nightly-runs/ From ci_notify at linaro.org Sat May 30 16:28:53 2020 From: ci_notify at linaro.org (ci_notify at linaro.org) Date: Sat, 30 May 2020 16:28:53 +0000 (UTC) Subject: [aarch64-port-dev ] JTREG, JCStress, SPECjbb2015 and Hadoop/Terasort results for OpenJDK 13 on AArch64 Message-ID: <1071181501.650.1590856134253.JavaMail.javamailuser@localhost> This is a summary of the JTREG test results =========================================== The build and test results are cycled every 15 days. For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/openjdk-jtreg-nightly-tests/summary/2020/149/summary.html ------------------------------------------------------------------------------- release/hotspot ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/23 pass: 5,644; fail: 3 Build 1: aarch64/2019/jul/25 pass: 5,644; fail: 3 Build 2: aarch64/2019/jul/30 pass: 5,645; fail: 2 Build 3: aarch64/2019/aug/01 pass: 5,646; fail: 1 Build 4: aarch64/2019/aug/03 pass: 5,646; fail: 1 Build 5: aarch64/2019/aug/06 pass: 5,645; fail: 2 Build 6: aarch64/2019/aug/08 pass: 5,646; fail: 1 Build 7: aarch64/2019/aug/10 pass: 5,646; fail: 1 Build 8: aarch64/2019/nov/12 pass: 5,652 Build 9: aarch64/2019/nov/14 pass: 5,650; fail: 2 Build 10: aarch64/2019/nov/16 pass: 5,652 Build 11: aarch64/2019/dec/03 pass: 5,651; fail: 1 Build 12: aarch64/2019/dec/14 pass: 5,652 Build 13: aarch64/2020/jan/16 pass: 5,652 Build 14: aarch64/2020/may/28 pass: 5,669 ------------------------------------------------------------------------------- release/jdk ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/23 pass: 8,616; fail: 525; error: 30 Build 1: aarch64/2019/jul/25 pass: 8,620; fail: 528; error: 23 Build 2: aarch64/2019/jul/30 pass: 8,610; fail: 529; error: 32 Build 3: aarch64/2019/aug/01 pass: 8,620; fail: 527; error: 24 Build 4: aarch64/2019/aug/03 pass: 8,596; fail: 552; error: 23 Build 5: aarch64/2019/aug/06 pass: 8,616; fail: 528; error: 27 Build 6: aarch64/2019/aug/08 pass: 8,649; fail: 504; error: 18 Build 7: aarch64/2019/aug/10 pass: 8,647; fail: 507; error: 17 Build 8: aarch64/2019/nov/12 pass: 8,650; fail: 513; error: 16 Build 9: aarch64/2019/nov/14 pass: 8,651; fail: 511; error: 17 Build 10: aarch64/2019/nov/16 pass: 8,663; fail: 500; error: 17 Build 11: aarch64/2019/dec/03 pass: 8,671; fail: 493; error: 18 Build 12: aarch64/2019/dec/14 pass: 8,653; fail: 516; error: 14 Build 13: aarch64/2020/jan/16 pass: 8,661; fail: 501; error: 21 Build 14: aarch64/2020/may/28 pass: 8,673; fail: 504; error: 17 2 fatal errors were detected; please follow the link above for more detail. ------------------------------------------------------------------------------- release/langtools ------------------------------------------------------------------------------- Build 0: aarch64/2019/jul/23 pass: 3,964 Build 1: aarch64/2019/jul/25 pass: 3,964 Build 2: aarch64/2019/jul/30 pass: 3,964 Build 3: aarch64/2019/aug/01 pass: 3,964 Build 4: aarch64/2019/aug/03 pass: 3,964 Build 5: aarch64/2019/aug/06 pass: 3,964 Build 6: aarch64/2019/aug/08 pass: 3,964 Build 7: aarch64/2019/aug/10 pass: 3,964 Build 8: aarch64/2019/nov/12 pass: 3,964 Build 9: aarch64/2019/nov/14 pass: 3,964 Build 10: aarch64/2019/nov/16 pass: 3,964 Build 11: aarch64/2019/dec/03 pass: 3,964 Build 12: aarch64/2019/dec/14 pass: 3,964 Build 13: aarch64/2020/jan/16 pass: 3,964 Build 14: aarch64/2020/may/28 pass: 3,964 Previous results can be found here: http://openjdk.linaro.org/jdk13/openjdk-jtreg-nightly-tests/index.html SPECjbb2015 composite regression test completed =============================================== This test measures the relative performance of the server compiler running the SPECjbb2015 composite tests and compares the performance against the baseline performance of the server compiler taken on 2016-11-21. In accordance with [1], the SPECjbb2015 tests are run on a system which is not production ready and does not meet all the requirements for publishing compliant results. The numbers below shall be treated as non-compliant (nc) and are for experimental purposes only. Relative performance: Server max-jOPS (nc): 7.54x Relative performance: Server critical-jOPS (nc): 9.14x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/SPECjbb2015-results/ [1] http://www.spec.org/fairuse.html#Academic Regression test Hadoop-Terasort completed ========================================= This test measures the performance of the server and client compilers running Hadoop sorting a 1GB file using Terasort and compares the performance against the baseline performance of the Zero interpreter and against the baseline performance of the server compiler on 2014-04-01. Relative performance: Zero: 1.0, Server: 207.57 Server 207.57 / Server 2014-04-01 (71.00): 2.92x Details of the test setup and historical results may be found here: http://openjdk.linaro.org/jdk13/hadoop-terasort-benchmark-results/ This is a summary of the jcstress test results ============================================== The build and test results are cycled every 15 days. 2019-07-21 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/201/results/ 2019-07-24 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/204/results/ 2019-07-26 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/206/results/ 2019-07-31 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/211/results/ 2019-08-02 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/213/results/ 2019-08-04 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/215/results/ 2019-08-07 pass rate: 10488/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/218/results/ 2019-08-09 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/220/results/ 2019-08-11 pass rate: 10487/10488, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/222/results/ 2019-11-12 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/316/results/ 2019-11-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/318/results/ 2019-11-17 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/320/results/ 2019-12-04 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/337/results/ 2019-12-15 pass rate: 10490/10490, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2019/348/results/ 2020-05-30 pass rate: 9702/9702, results: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/2020/149/results/ For detailed information on the test output please refer to: http://openjdk.linaro.org/jdk13/jcstress-nightly-runs/ From aph at redhat.com Sat May 30 20:14:55 2020 From: aph at redhat.com (Andrew Haley) Date: Sat, 30 May 2020 21:14:55 +0100 Subject: [aarch64-port-dev ] RFR:8246051:[AArch64]SIGBUS by unaligned Unsafe compare_and_swap In-Reply-To: References: Message-ID: <497b376c-561c-c40c-add6-a63af8736a3c@redhat.com> On 29/05/2020 13:36, Wang Zhuo(Zhuoren) wrote: > Update patch. A jtreg test added > http://cr.openjdk.java.net/~wzhuo/8246051/webrev.01/ The test is AArch64-only but the patch is to shared code. This doesn't make sense to me. -- 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