RFR: 8342376: More reliable OOM handling in ExceptionDuringDumpAtObjectsInitPhase test

Ioi Lam iklam at openjdk.org
Wed Oct 16 16:49:10 UTC 2024


On Wed, 16 Oct 2024 11:51:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Found a test bug while testing [JDK-8341913](https://bugs.openjdk.org/browse/JDK-8341913) with Shenandoah. For OOM testing, the test fills out the heap with large arrays and then attempts to allocate a smaller array.
> 
> That allocation almost always succeeds with Shenandoah. Actually, it succeeds with other GCs as well, it just so happens that other GCs throw OOM with "GC overhead limit exceeded".
> 
> Plus, some allocations should be sinked to avoid dead-code elimination.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, test now passes reliably with JDK-8341913 and Shenandoah
>  - [x] Linux x86_64 server fastdebug, test with {Serial, Parallel, G1, Shenandoah}, 50 times

Can you describe which test failed with Shenandoah and how the fail? Is it this part of ExceptionDuringDumpAtObjectsInitPhase.java?


        System.out.println("2. OOM during dump");
        TestCommon.dump(appJar,
                        TestCommon.list(Hello.class.getName()),
                        "-XX:+UnlockDiagnosticVMOptions",
                        "-XX:+AllowArchivingWithJavaAgent",
                        "-javaagent:" + agentJar,
                        "-Dtest.with.oom=true",
                        "-Xlog:cds,class+load",
                        "-Xmx12M",
                        gcLog).shouldNotHaveExitValue(0)
                              .shouldContain("Out of memory. Please run with a larger Java heap, current MaxHeapSize");


> For OOM testing, the test fills out the heap with large arrays and then attempts to allocate a smaller array.

The test keeps allocating with no catch for OOM. Shouldn't this always fail?


            if (TEST_WITH_OOM) {
                // fill until OOM
                System.out.println("Fill objects until OOM");
                for (;;) {
                    waste.add(new byte[64*1024]);
                }
            }


The test does not expect an OOM from the following block. The purpose of this is just to make so allocation. When done enough times (hundreds of classes are loaded during dump time), we will have executed some GCs. The purpose is to make sure that the CDS code uses Handles correctly to avoid holding onto dead oops.


            try {
                makeGarbage();
            } catch (Throwable t) {

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

PR Comment: https://git.openjdk.org/jdk/pull/21536#issuecomment-2417379818


More information about the hotspot-runtime-dev mailing list