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

[SendaoYan]

On Thu, 6 Nov 2025 22:41:20 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;
>>     }
>> 
>> }
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust tag order

test/hotspot/jtreg/gc/shenandoah/TestLargeObjectAlignment.java line 32:

> 30:  * @requires vm.gc.Shenandoah
> 31:  * @requires vm.bits == "64"
> 32:  * @requires os.maxMemory > 3G

I think os.maxMemory should slightly large than max heap memory size, since heap memory is not the only memory in jvm.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28167#discussion_r2501446720