RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space
Arno Zeller
azeller at openjdk.org
Thu Nov 6 19:36:06 UTC 2025
On Thu, 6 Nov 2025 11:17:01 GMT, SendaoYan <syan at openjdk.org> wrote:
>> Sporadic failures were observed for TestLargeObjectAlignment.java#generational. The current theory is that jtreg deafult heap size on the reporter's machines is too small, and the randomness in test just sometimes created a huge heap larger than what the test had.
>>
>> Did a calculation for the worst case (see the code snippet at the end - it removes the Random in the original test and always allocates the array to full) and the test needs at least 2g. Initiating 3g heap for safety to reduce the noise.
>>
>> Also use the test to compare between Shenandoah vs GenShen: on my laptop (Mac M3), Shen failed at 2150m Xmx, GenShen could pass Xmx2150m and failed at Xmx2050m (step: 50m), so GenShen isn't worse, it's actually better. The reported GenShen failure observation probably came from the Random.
>>
>>
>>
>> public class TestLargeObjectAlignmentDeterministic {
>>
>> static final int SLABS_COUNT = Integer.getInteger("slabs", 10000);
>> static final int NODE_COUNT = Integer.getInteger("nodes", 10000);
>> static final long TIME_NS = 1000L * 1000L * Integer.getInteger("timeMs", 5000);
>>
>> static Object[] objects;
>>
>> public static void main(String[] args) throws Exception {
>> objects = new Object[SLABS_COUNT];
>>
>> for (int i = 0; i < SLABS_COUNT; i++) {
>> objects[i] = createSome();
>> }
>> }
>>
>> public static Object createSome() {
>> List<Integer> result = new ArrayList<Integer>();
>> for (int c = 0; c < NODE_COUNT; c++) {
>> result.add(new Integer(c));
>> }
>> return result;
>> }
>>
>> }
>
> test/hotspot/jtreg/gc/shenandoah/TestLargeObjectAlignment.java line 34:
>
>> 32: * @library /test/lib
>> 33: *
>> 34: * @run main/othervm -Xms3g -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ObjectAlignmentInBytes=16 -Xint TestLargeObjectAlignment
>
> Since the initial heap memory set to 3G, maybe we should add '@requires os.maxMemory > 4g' to skip this test when the physical memory of test machine is less than 4g.
I suggest to also set -Xmx3g - otherwise the test will fail in case an -Xmx value of less than 3GB is set by a jtreg -vmoption.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/28167#discussion_r2500542446
More information about the hotspot-gc-dev
mailing list