RFR: 8361339: Test gc/shenandoah/TestLargeObjectAlignment.java#generational fails on macOS aarch64 with OOM: Java heap space

[Aleksey Shipilev]

On Thu, 6 Nov 2025 00:21:55 GMT, Rui Li <duke 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;
>     }
> 
> }

Right. One node is basically an `Integer` and the reference array slot. So about 20 bytes, give or take. There are 10K nodes per slab, meaning there is 200KB per slab. There are 10K slabs, meaning they take 2GB memory. So bumping the limit to 3G makes sense.

I think you want to override `Xmx`, though -- that is the decisive factor for sizing heap regions. Sticking with `Xmx` means the test runs in the same conditions everywhere, helping reproducibility. Unless there is a strong reason to explore different heap regions sizes, which I think there is none: the test was about testing `ObjectAlignmentInBytes` first and foremost.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28167#pullrequestreview-3427215034