- ppc-aix-port-dev - openjdk.org

SAPs OpenJDK 8 ppc test setup for JDK jtreg tests
by Lindenmaier, Goetz 23 Jul '21

23 Jul '21

Hi, After SAP discontinued the support of linuxppc64 and aixppc64 of OpenJDK 8 I want to share how we ran the hotspot jtreg tests, and especially which tests we excluded. Most of the test excludes could be fixed by downporting test changes. Also, issues might be fixed after we excluded them, I did not check this. We build with only mandatory configure settings, except for linuxppc64: --with-extra-cflags=-Wno-strict-aliasing aix: --with-native-debug-symbols=internal We run the jtreg tests with the following settings: -Djava.awt.headless=true -k:(!headful)&(!printer)&(!intermittent)&(!jfr) We excluded the following tests: First, tests that fail on all platforms we tested: # Uses jfr functionality, but lacks key jfr. Eventually the commands # should not be compiled into the VM if jfr is disabled in configure. com/sun/management/DiagnosticCommandMBean/DcmdMBeanPermissionsTest.java generic-all # Does not compile javax/management/remote/mandatory/connection/RMIConnector_NPETest.java generic-all # headfuld keyword exists in head, was it removed in the downport? javax/swing/JEditorPane/8195095/ImageViewTest.java generic-all javax/swing/JProgressBar/8161664/ProgressBarMemoryLeakTest.java generic-all java/awt/Container/MoveToOtherScreenTest/MoveToOtherScreenTest.java generic-all java/awt/event/SequencedEvent/MultipleContextsFunctionalTest.java generic-all java/awt/Focus/NullActiveWindowOnFocusLost/NullActiveWindowOnFocusLost.java generic-all java/awt/Mouse/EnterExitEvents/ModalDialogEnterExitEventsTest.java generic-all java/awt/ScrollPane/ScrollPaneValidateTest.java generic-all # BindException: Address already in use javax/xml/ws/publish/WSTest.java generic-all # 8237834: com/sun/jndi/ldap/LdapDnsProviderTest.java failing with LDAP response read timeout com/sun/jndi/ldap/LdapDnsProviderTest.java generic-all # Probably "8037485: Refactor java.awt.datatransfer to eliminate dependency on AWT" # is missing to run this test headless. java/awt/datatransfer/SystemFlavorMap/AddFlavorTest.java # These need regular test updates. jdk/security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java generic-all security/infra/java/security/cert/CertPathValidator/certification/BuypassCA.java generic-all security/infra/java/security/cert/CertPathValidator/certification/ComodoCA.java generic-all security/infra/java/security/cert/CertPathValidator/certification/LetsEncryptCA.java generic-all security/infra/java/security/cert/CertPathValidator/certification/QuoVadisCA.java generic-all # These fail on the listed platforms we curretly test. java/beans/Introspector/7064279/Test7064279.java windows-all,solaris-all java/beans/Introspector/Test7172865.java windows-all,solaris-all java/beans/Introspector/Test7195106.java windows-all,solaris-all java/beans/Introspector/Test8027905.java windows-all,solaris-all java/beans/Introspector/Test8027648.java generic-ppc64,solaris-all java/beans/PropertyEditor/6380849/TestPropertyEditor.java windows-all,generic-ppc64,solaris-all java/beans/PropertyEditor/TestColorClass.java windows-all,generic-ppc64,solaris-all java/beans/PropertyEditor/TestColorClassJava.java windows-all,generic-ppc64,solaris-all java/beans/PropertyEditor/TestColorClassNull.java windows-all,generic-ppc64,solaris-all java/beans/PropertyEditor/TestColorClassValue.java windows-all,generic-ppc64,solaris-all java/beans/PropertyEditor/TestFontClass.java windows-all,generic-ppc64,solaris-all java/beans/PropertyEditor/TestFontClassJava.java windows-all,generic-ppc64,solaris-all java/beans/PropertyEditor/TestFontClassNull.java windows-all,generic-ppc64,solaris-all java/beans/PropertyEditor/TestFontClassValue.java windows-all,generic-ppc64,solaris-all java/beans/XMLEncoder/java_awt_ScrollPane.java windows-all,generic-ppc64,solaris-all java/net/MulticastSocket/TestInterfaces.java solaris-all java/net/NetworkInterface/UniqueMacAddressesTest.java solaris-all java/net/URLConnection/HandleContentTypeWithAttrs.java windows-all,generic-ppc64,solaris-all java/nio/file/Files/CopyAndMove.java windows-all javax/imageio/plugins/bmp/BMP8BPPLoadTest.java windows-all,generic-ppc64,solaris-all sun/security/tools/keytool/printssl.sh windows-all # Does not work because C1 is missing in ppc64. Uses flag -client. java/awt/font/LineBreakMeasurer/FRCTest.java generic-ppc64 # Unclear. A row of test fixes are missing. Might be shell issue. java/awt/Toolkit/BadDisplayTest/BadDisplayTest.java aix-all # TestJapaneseLineBreak { # ja line break failure: failed to skip position before '?' (\\ufd3e) at 2 and bounded at 1 # Uncaught exception thrown in test method TestJapaneseLineBreak java/text/BreakIterator/BreakIteratorTest.java aix-all # Unclear. NullPointerException: null target encoding sun/awt/datatransfer/SuplementaryCharactersTransferTest.java # Might need "8196572: Tests ColConvCCMTest.java and MTColConvTest.java fail" sun/java2d/cmm/ColorConvertOp/ColConvCCMTest.java aix-all sun/java2d/cmm/ColorConvertOp/MTColConvTest.java aix-all # Unclear sun/tools/clhsdb/Basic.sh aix-all sun/tools/hsdb/Basic.sh aix-all # Exclude what fails only on our platforms java/beans/XMLEncoder/javax_swing_DefaultCellEditor.java aix-all java/beans/XMLEncoder/javax_swing_JTree.java aix-all java/beans/XMLEncoder/Test4631471.java aix-all java/beans/XMLEncoder/Test4903007.java aix-all java/lang/ClassLoader/Assert.java aix-all java/net/MulticastSocket/SetGetNetworkInterfaceTest.java aix-all java/net/MulticastSocket/SetLoopbackMode.java aix-all java/net/MulticastSocket/Test.java aix-all java/net/ServerSocket/AcceptInheritHandle.java aix-all java/net/Socket/InheritHandle.java aix-all java/nio/channels/Selector/RacyDeregister.java aix-all java/nio/channels/AsyncCloseAndInterrupt.java aix-all java/nio/file/Files/delete_on_close.sh aix-all java/nio/file/Files/SBC.java aix-all sun/security/krb5/auto/Unreachable.java aix-all sun/security/tools/jarsigner/diffend.sh aix-all tools/launcher/MultipleJRE.sh aix-all # Needs "8194869: [TESTBUG][aix, s390] Adapt tests to platforms" javax/imageio/spi/AppletContextTest/BadPluginConfigurationTest.sh aix-all java/awt/FontClass/CreateFont/fileaccess/FontFile.java aix-all java/awt/JAWT/JAWT.sh aix-all java/awt/Toolkit/AutoShutdown/EventQueuePush/EventQueuePushAutoshutdown.sh aix-all # Is it the unsolved issue in 8197797? java/awt/Graphics2D/DrawString/RotTransText.java aix-all @key headful and similar tags were added to a huge amount of tests in upstream repositories. Many of the changes adding these were contributed by us to get the ppc tests run headless green. In 8, we just added the tests of these changes to the ProblemList instead of downporting the test adaptions. I just enumerate the changes here, listing all the tests is pointless I guess. # 8207830: [aix] disable jfr in build and tests # 8183286: Some java/awt and javax/swing tests miss headful jtreg keyword # 8185500: [TESTBUG] Add keywords headful/printer in java/awt and javax tests. # 8160974: [TESTBUG] Mark more headful tests with @key headful. # 8159690: [TESTBUG] Mark headful tests with @key headful. # 8196196: Headful tests should not be run in headless mode # 8198333: ProblemList should be updated for headless mode Best regards, Goetz

1 0

SAPs OpenJDK 8 ppc test setup for HOTSPOT jtreg tests
by Lindenmaier, Goetz 23 Jul '21

23 Jul '21

Hi, After SAP discontinued the support of linuxppc64 and aixppc64 of OpenJDK 8 I want to share how we ran the hotspot jtreg tests, and especially which tests we excluded. Most of the test excludes could be fixed by downporting test changes. Also, issues might be fixed after we excluded them, I did not check this. We build with only mandatory configure settings, except for the following: linuxppc64: --with-extra-cflags=-Wno-strict-aliasing aix: --with-native-debug-symbols=internal We run jtreg with the following settings: -Djava.awt.headless=true -k:(!headful)&(!ignore)&(!stress)&(!intermittent) We excluded the following tests: First, tests that fail on all platforms we tested: # Testbug # This test copied or moved the root directory / to some subdirectory, filling up the disc compiler/ciReplay/TestSA.sh generic-all compiler/ciReplay/TestVM_no_comp_level.sh generic-all compiler/ciReplay/TestVM.sh generic-all # Fails in 8 until 8044416 will be fixed or # the test exclusion change 8044540 will be downported from jdk9 serviceability/sa/jmap-hashcode/Test8028623.java generic-all # Fixed in 11 by 8195621: JTReg failure: gc/g1/TestLargePageUseForAuxMemory.java gc/g1/TestLargePageUseForAuxMemory.java generic-all Further, tests we see failing on ppc but not on x86_64. # Class data sharing not implemented on ppc. runtime/CDSCompressedKPtrs/CDSCompressedKPtrs.java generic-ppc64 runtime/CDSCompressedKPtrs/CDSCompressedKPtrsError.java generic-ppc64 runtime/CompressedOops/CompressedClassPointers.java generic-ppc64 runtime/NMT/NMTWithCDS.java generic-ppc64 runtime/NMT/VirtualAllocCommitUncommitRecommit.java generic-ppc64 runtime/SharedArchiveFile/CdsDifferentObjectAlignment.java generic-ppc64 runtime/SharedArchiveFile/CdsSameObjectAlignment.java generic-ppc64 runtime/SharedArchiveFile/LimitSharedSizes.java generic-ppc64 runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java generic-ppc64 runtime/SharedArchiveFile/SharedArchiveFile.java generic-ppc64 runtime/SharedArchiveFile/SharedBaseAddress.java aix-ppc64 runtime/SharedArchiveFile/SpaceUtilizationCheck.java generic-ppc64 # C1 not implemented. In jdk9 these are moved to subdir /c1/. compiler/6478991/NullCheckTest.java generic_ppc64 compiler/6579789/Test6579789.java generic_ppc64 compiler/6756768/Test6756768_2.java generic_ppc64 compiler/6756768/Test6756768.java generic_ppc64 compiler/6757316/Test6757316.java generic_ppc64 compiler/6758234/Test6758234.java generic_ppc64 compiler/6769124/TestArrayCopy6769124.java generic_ppc64 compiler/6769124/TestDeoptInt6769124.java generic_ppc64 compiler/6769124/TestUnalignedLoad6769124.java generic_ppc64 compiler/6795465/Test6795465.java generic_ppc64 compiler/6849574/Test.java generic_ppc64 compiler/6855215/Test6855215.java generic_ppc64 compiler/6932496/Test6932496.java generic_ppc64 compiler/7042153/Test7042153.java generic_ppc64 compiler/7090976/Test7090976.java generic_ppc64 compiler/7103261/Test7103261.java generic_ppc64 compiler/7123108/Test7123108.java generic_ppc64 compiler/8011706/Test8011706.java generic_ppc64 compiler/8011771/Test8011771.java generic_ppc64 # tests that set -client which is currently not supported compiler/8004051/Test8004051.java generic-ppc64 gc/g1/TestHumongousCodeCacheRoots.java generic-ppc64 compiler/tiered/Level2RecompilationTest.java generic-ppc64 # Don't look at tests that will be renamed. These don't show obvious errors in the port. compiler/8004051/Test8004051.java generic-ppc64 # Fail because of 64K page size # Fixed in 9, but 8067941 not downported. compiler/exceptions/TestRecursiveReplacedException.java generic-ppc64 compiler/runtime/6865265/StackOverflowBug.java linux-ppc64 compiler/6865265/StackOverflowBug.java linux-ppc64 # In addition, this test is shaky in the amount of stack frames pushed. compiler/uncommontrap/8009761/Test8009761.java linux-ppc64,aix-ppc64,windows-all compiler/8009761/Test8009761.java linux-ppc64,aix-ppc64,windows-all compiler/uncommontrap/StackOverflowGuardPagesOff.java linux-ppc64 compiler/uncommontrap/TestStackBangMonitorOwned.java linux-ppc64 compiler/uncommontrap/TestStackBangRbp.java linux-ppc64 gc/arguments/TestMaxHeapSizeTools.java linux-ppc64 gc/g1/TestGCLogMessages.java linux-ppc64 gc/g1/TestHumongousAllocInitialMark.java linux-ppc64 runtime/whitebox/WBStackSize.java linux-ppc64 sanity/ExecuteInternalVMTests.java linux-ppc64 # These also fail because of the 64K problem. gc/arguments/TestCMSHeapSizeFlags.java linux-ppc64 gc/arguments/TestG1HeapSizeFlags.java linux-ppc64 gc/arguments/TestParallelHeapSizeFlags.java linux-ppc64 gc/arguments/TestSerialHeapSizeFlags.java linux-ppc64 # Fail on aix because OS not supported in test. # Fixed in 9, but 8068013 not downported. serviceability/dcmd/DynLibDcmdTest.java aix-ppc64 testlibrary_tests/TestMutuallyExclusivePlatformPredicates.java aix-ppc64 # Fail on aix and mac because SA not supported. # Fixed in 9, but 8068778 not downported # linux-ppc64: SA isn't downported gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java generic-all,macosx-all gc/metaspace/CompressedClassSpaceSizeInJmapHeap.jtr generic-all,macosx-all # Fail on ppc64 because tiered compilation not supported. # Test fixed in 9, but 8067941 not downported compiler/arguments/CheckCompileThresholdScaling.java generic-ppc64 # OptimizeFill is broken on ppc. compiler/6982370/Test6982370.java generic-ppc64 # These require test_env.sh-like adaptions (mention AIX in switch statement). # They are not in jdk9, so no fix to downport. compiler/6894807/IsInstanceTest.java aix-ppc64 runtime/7110720/Test7110720.java aix-ppc64 runtime/7110720/Test7110720.sh aix-ppc64 # Must add SIGTRAP in check code. runtime/memory/ReserveMemory.java aix-ppc64 # Modes don't work in 8. runtime/CompressedOops/UseCompressedOops.java aix-ppc64 Best regards, Goetz.

1 0

Resigning as PowerPC/AIX Port Project Lead
by Volker Simonis 13 May '21

13 May '21

I hereby resign as PowerPC/AIX Port Project Lead. The PowerPC/AIX Port [1] was proposed almost exactly 9 years ago [2]. It was the first externally contributed, full OpenJDK port and paved the way for subsequent porting projects like aarch64 and s390. It was also the beginning of a fruitful cooperation between SAP, IBM and Oracle who have all contributed to the success of this project. While PowerPC and especially AIX can still be seen as "niche" platforms, the presence of the PowerPC/AIX Port in the OpenJDK main line has helped to considerably improve and streamline the whole code base. I hope this mutually beneficial collaboration will continue in the future and would like to propose Martin Doerr (mdoerr [3]) as new Project Lead. Martin is a true PowerPC/Itanium expert and a real memory model wizard. He's a long term member of the SAP JVM team, an OpenJDK Reviewer and a member of the OpenJDK HotSpot and Members Groups [3]. In the end, and according to the OpenJDK Bylaws, the Lead of the sponsoring group (Dalibor Topic from the Porters Group) needs to assign a new Project Lead [4]. I for myself can't think of any better candidate and warmly recommend Martin for this position. Thank you and best regards, Volker [1] https://wiki.openjdk.java.net/display/PPCAIXPort [2] http://mail.openjdk.java.net/pipermail/announce/2012-May/000125.html [3] http://openjdk.java.net/census#mdoerr [4] http://openjdk.java.net/bylaws#project-lead

5 4

New Project Lead for PowerPC/AIX Port
by Dalibor Topic 12 May '21

12 May '21

Hi, Volker Simonis has resigned as lead of the PowerPC/AIX Port [1]. Under the bylaws for Project Roles [2], a new Project Lead may be nominated by the Group Leads of the Project's sponsoring groups. The Porters Group is sponsor of the project. In my role as Porters Group Leader, I would like to nominate Martin Doerr [3] to be the new Project Lead. The Porters Group is the only sponsoring group for this Project. As I am the only voter in this situation, the nomination is approved. Thanks to Volker for bringing the Project to this point, and thanks to Martin for coming forward to take over the role. cheers, dalibor topic [1] https://mail.openjdk.java.net/pipermail/discuss/2021-May/005806.html [2] http://openjdk.java.net/bylaws#project-lead [3] https://openjdk.java.net/census#mdoerr -- <http://www.oracle.com> Dalibor Topic Consulting Product Manager Phone: +494089091214 <tel:+494089091214>, Mobile: +491737185961 <tel:+491737185961>, Video: dalibor.topic(a)oracle.com <sip:dalibor.topic@oracle.com> Oracle Global Services Germany GmbH Hauptverwaltung: Riesstr. 25, D-80992 München Registergericht: Amtsgericht München, HRB 246209 Geschäftsführer: Ralf Herrmann

1 0

RFR: 8251926: PPC: Remove an unused variable in assembler_ppc.cpp
by Michihiro Horie 04 Sep '20

04 Sep '20

Dear all, Would you please review a small change? Bug: https://bugs.openjdk.java.net/browse/JDK-8251926 Webrev: http://cr.openjdk.java.net/~mhorie/8251926/webrev.00/ The load_const_optimized function in assembler_ppc.cpp has an unused variable named return_xd. It looks unnecessary in the current code. Best regards, Michihiro

3 4

RFR(S): [PATCH] Add HotSpotIntrinsicCandidate and API for Base64 decoding
by Corey Ashford 28 Jul '20

28 Jul '20

Currently in java.util.Base64, there is a HotSpotIntrinsicCandidate and API for encodeBlock, but none for decoding. This means that only encoding gets acceleration from the underlying CPU's vector hardware. I'd like to propose adding a new intrinsic for decodeBlock. The considerations I have for this new intrinsic's API: * Don't make any assumptions about the underlying capability of the hardware. For example, do not impose any specific block size granularity. * Don't assume the underlying intrinsic can handle isMIME or isURL modes, but also let them decide if they will process the data regardless of the settings of the two booleans. * Any remaining data that is not processed by the intrinsic will be processed by the pure Java implementation. This allows the intrinsic to process whatever block sizes it's good at without the complexity of handling the end fragments. * If any illegal character is discovered in the decoding process, the intrinsic will simply return -1, instead of requiring it to throw a proper exception from the context of the intrinsic. In the event of getting a -1 returned from the intrinsic, the Java Base64 library code simply calls the pure Java implementation to have it find the error and properly throw an exception. This is a performance trade-off in the case of an error (which I expect to be very rare). * One thought I have for a further optimization (not implemented in the current patch), is that when the intrinsic decides not to process a block because of some combination of isURL and isMIME settings it doesn't handle, it could return extra bits in the return code, encoded as a negative number. For example: Illegal_Base64_char = 0b001; isMIME_unsupported = 0b010; isURL_unsupported = 0b100; These can be OR'd together as needed and then negated (flip the sign). The Base64 library code could then cache these flags, so it will know not to call the intrinsic again when another decodeBlock is requested but with an unsupported mode. This will save the performance hit of calling the intrinsic when it is guaranteed to fail. I've tested the attached patch with an actual intrinsic coded up for Power9/Power10, but those runtime intrinsics and arch-specific patches aren't attached today. I want to get some consensus on the library-level intrinsic API first. Also attached is a simple test case to test that the new intrinsic API doesn't break anything. I'm open to any comments about this. Thanks for your consideration, - Corey Corey Ashford IBM Systems, Linux Technology Center, OpenJDK team cjashfor at us dot ibm dot com

2 3

Re: Should System.mapLibraryName(userLibName) on AIX return ".a" suffix ?
by Andrew Leonard 06 Jul '20

06 Jul '20

Hi, Does anyone have a view on whether the the default AIX suffix should change to ".a"? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard(a)uk.ibm.com From: Andrew Leonard/UK/IBM To: ppc-aix-port-dev(a)openjdk.java.net Date: 19/06/2020 10:12 Subject: Should System.mapLibraryName(userLibName) on AIX return ".a" suffix ? Hi, Currently System.mapLibraryName(userLibName)returns ".so" as the library suffix on AIX, however the default shared library suffix on AIX is actually ".a". Should the System.mapLibraryName(userLibName)default suffix be changed to align with the AIX default? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard(a)uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

2 1

Should System.mapLibraryName(userLibName) on AIX return ".a" suffix ?
by Andrew Leonard 19 Jun '20

19 Jun '20

Hi, Currently System.mapLibraryName(userLibName)returns ".so" as the library suffix on AIX, however the default shared library suffix on AIX is actually ".a". Should the System.mapLibraryName(userLibName)default suffix be changed to align with the AIX default? Thanks Andrew Andrew Leonard Java Runtimes Development IBM Hursley IBM United Kingdom Ltd internet email: andrew_m_leonard(a)uk.ibm.com Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

1 0

RFR(XS): 8245521: Remove STACK_BIAS
by Mikael Vidstedt 26 May '20

26 May '20

Please review this small change which removes the STACK_BIAS constant and its uses: JBS: https://bugs.openjdk.java.net/browse/JDK-8245521 webrev: http://cr.openjdk.java.net/~mikael/webrevs/8245521/webrev.00/open/webrev/ Background (from JBS): With Solaris/SPARC removed the STACK_BIAS definition in src/hotspot/share/utilities/globalDefinitions.hpp is now always 0 and can be removed. Testing: Tier1 Cheers, Mikael

4 4

Re: RFR: 8243961: ForceNUMA and only one available NUMA node fails assertion on Windows
by Kim Barrett 05 May '20

05 May '20

> On Apr 30, 2020, at 6:24 AM, Thomas Schatzl <thomas.schatzl(a)oracle.com> wrote: > > Hi, > > On 29.04.20 14:28, Kim Barrett wrote: >> Please review this Windows-specific change to the initialization of >> UseNUMAInterleaving. >> […] >> CR: >> https://bugs.openjdk.java.net/browse/JDK-8243961 >> Webrev: >> https://cr.openjdk.java.net/~kbarrett/8243961/open.00/ >> Testing: >> mach5 tier1-3 >> mach5 testing on Windows with explict +UseG1GC +UseNUMA +ForceNUMA and >> each of +/-/(default)UseNUMAInterleaving. >> TestUseNUMAInterleaving fails for some of those test configurations on >> non-NUMA hardware, because the test expects UseNUMAInterleaving to be >> enabled if UseNUMA is enabled. As the test failure can only happen >> with +ForceNUMA, that configuration doesn't seem to otherwise lead to >> other problems, +ForceNUMA doesn't seem to be a tested configuration, >> and ForceNUMA is going away (JDK-8243628), we'll not worry about that >> failure. > > Change is okay, but what do you think about always disabling UseNUMA regardless of ForceNUMA on Windows instead? > > There does not seem to be a code path in the windows OS files that acts on UseNUMA. For NUMA related methods it returns default values, so any path in the GCs will just do nothing or act on useless default values from the os layer and do weird things. > > UseNUMAInterleaving is completely separate from UseNUMA functionality anyway (although "UseNUMA" is misleading at least to me, but that's another discussion). > > There is the problem then that probably many people enable UseNUMA to get UseNUMAInterleaving, but that could be handled in a windows specific way too. I.e. when -XX:+UseNUMA and -XX:+/-ForceNUMA is set, disable UseNUMA and enable UseNUMAInterleaving. > > That sounds much easier to understand to me than the current change. > > Some collectors (Z, Shenandoah) will set UseNUMA, but this evaluation is before os::init_2 so above idea would do the right thing as neither have any special UseNUMA path. I.e. both actually seem to want UseNUMAInterleaving. Shenandoah explicitly says so, so actually changing them to enable UseNUMAInterleaving instead of UseNUMA would be good too imo. > > On non-Windows there will be no difference to now. > > Thomas [Added ppc-aix-port-dev, as there is a small AIX change here.] I considered just unconditionally disabling UseNUMA on Windows. That would also be sufficient to fix the bug, since the later +UseNUMA => +UseNUMAInterleaving wouldn't happen. But I felt that was leaving a booby trap for whoever gets to deal with implementing UseNUMA on Windows. To avoid that, the later +UseNUMA => +UseNUMAInterleaving needs to be suppressed anyway. In which case there's no need (for this bug) to do anything about UseNUMA/ForceNUMA. Also, that would be a behavioral change if someone is actually using -XX:+ForceNUMA (and either -XX:+UseNUMA or using a collector that implicitly turns it on (ZGC and Shenandoah)) and expecting the current behavior that -XX:+UseNUMAInterleaving will also be implicitly enabled. Not that I think that's likely, but with ForceNUMA still being a product option... For other platforms I don't want to get into second guessing whether someone said +UseNUMA but really meant +UseNUMAInterleaving. I looked at moving the defaulting of +UseNUMAInterleaving when +UseNUMA earlier. It could be done in Arguments::apply_ergo. But then if UseNUMA ends up ultimately getting disabled we should undo that defaulting. Bleh! Digging further into this, I discovered that on Linux (at least) -XX:+UseNUMAInterleaving is effectively ignored if -UseNUMA, but not really in a good way. +UseNUMAInterleaving controls whether numa_make_global gets called in a couple of places. But that calls into stuff that is setup by libnuma_init, which is only called if +UseNUMA. numa_make_global copes with that lack of setup by checking for it and (not completely trivially) doing nothing if not set up. What I've ended up doing is moving the conditional enabling of UseNUMAInterleaving into the platform-specific code, where there's enough information to consistently get it right. I've also made all the os variants be explicit about UseNUMA and UseNUMAInterleaving; those that have no support for either now unconditionally set them false. (This happens to keep TestUseNUMAInterleaving working on those platforms.) New webrev: https://cr.openjdk.java.net/~kbarrett/8243961/open.01/ (No incremental; the code change to os_windows.cpp is the same, but the rationale and commentary are entirely different.) Testing: mach5 tier1-3, normally, with -XX:+UseNUMA -XX:+ForceNUMA added. TestUseNUMAInterleaving still fails on Windows with +UseNUMA +ForceNUMA on a single-node machine, because +UseNUMAInterleaving gets turned off, which is not what the test expects. Manually verified that on Linux -XX:+UseNUMAInterleaving alone gets overridden off when libnuma_init is patched to fail.

3 6