Test: LargeGatheringWrite failed due to OOM on test-azure-win2012r2-x64-3

[adamfarley]

Please set the title to indicate the test name and machine name where known.

To make it easy for the infrastructure team to repeat and diagnose, please answer the following questions:

• test suite/name (e.g, BUILD_LIST, TARGET, CUSTOM_TARGET)? java/nio/channels/FileChannel/LargeGatheringWrite.java
• a link into recent Test_ job on https://ci.adoptium.net which showed the failure https://ci.adoptium.net/job/Test_openjdk21_hs_extended.openjdk_x86-64_windows_testList_1/8/
• Hyperlink to re-run in Grinder: https://ci.adoptium.net/view/Test_grinder/job/Grinder/7280/console
• Is there an existing issue elsewhere covering this? Here is the root issue. Also, possibly some overlap with this.
• Which machine(s) does it work on? First time I've seen this.
• Which machine(s) does it fail on? test-azure-win2012r2-x64-3

Any other details: Please take a look and see if something else is using up the available memory.

[sxa]

Has been excluded across all platforms. Check whether it occurs on other platforms and/or the win2022 systems.

[sxa]

Testing on:

• win/x64 ✅
• win/x64 ✅
• win/x64 ✅
• Linux/x64 ✅
• AIX :❌
• Linux/riscv64 tick ✅ And some more:
• AIX 17 GA (Test does not exist)
• win/x64 21 nightly ✅
• win/x32 21 nightly 15:08:02 failed to get value for jdk.foreign.linker. 15:08:02 java.lang.UnsupportedOperationException: Unsupported os, arch, or address size: Windows Server 2022, x86, 32
• win/x32 17 GA (Test does not exist)
• An attempt to run with an arm32 nightly failed with 15:04:53 Test results: no tests selected

While the win32 and arm32 ones had different messages, they are likely the result of the test being explicitly set up n ot to run on 32-bit platforms https://github.com/openjdk/jdk21u-dev/blob/4b1365eaab151ecf5ff2c40e4292d93137499c06/test/jdk/java/nio/channels/FileChannel/LargeGatheringWrite.java#L28C1-L28C27

[sxa]

More experimentation on AIX:

• build-osuosl-aix72-ppc64-3
• test-osuosl-aix72-ppc64-5
• test-osuosl-aix73-ppc64-1
• test-osuosl-aix72-ppc64-6
• test-osuosl-aix72-ppc64-2
• All failed

@smlambert Based on the above I'm slightly tempted to re-enable this everywhere except AIX - what do you think?

Also ref AIX, we're also seeing resource issues on that platform in https://github.com/adoptium/infrastructure/issues/3513

[smlambert]

In your runs above, have you run with both compressedrefs and noncompressedrefs options? To ensure both modes pass

(tangentially related is this Slack comment, though its talking about the jdk_jfr target versus this testcase from the jdk_nio target, but still...)

[sxa]

In your runs above, have you run with both compressedrefs and noncompressedrefs options? To ensure both modes pass

No I haven't but that's an interesting thought ... It's been a while since I tried to add extra options - can I just put them in JVM_OPTIONS in the Grinder parameters? (I'm not sure what the defaults that I might overwrite are)

[smlambert]

JVM_OPTIONS overwrites, EXTRA_OPTIONS appends

[sxa]

New runs with -XX:-UseCompressedOops

• win/x64 ✅
• win/x64 ✅
• Linux/x64 ✅
• AIX ❌ Same as before: Execution failed: 'main' threw exception: java.lang.OutOfMemoryError: Unable to allocate 1073741824 bytes
• Linux/riscv64 ✅
• win/x64 21 nightly ✅

[sxa]

Further tests before excluding:

Version	OS	NoCompressedOoops	Default CompressedOops
jdk23u	Windows	Grinder 11697	Grinder 11702
jdk23u	AIX	Grinder 11718	Grinder 11719
jdk24EA	Windows	Grinder 11701	Grinder 11704
jdk24EA	AIX	Grinder 11720	Grinder 11721

Summary: All windows ones passed, all AIX ones failed, so I'm going to take the associated PR out of draft so this test is only skipped on AIX. Note that 21 and 24 also pass for macos/aarch64