RFR: 8327176: UnreferencedExecutor.java can fail on libgraal with -Xcomp

David Holmes dholmes at openjdk.org
Thu Mar 21 05:40:20 UTC 2024


On Sun, 3 Mar 2024 17:01:53 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The `java/util/concurrent/Executors/UnreferencedExecutor.java` test can fail when run on libgraal and `-Xcomp` is specified. The problem is that libgraal in `-Xcomp` temporarily causes some extra memory pressure (probably due to [JDK-8310218](https://bugs.openjdk.org/browse/JDK-8310218)) which can cause recoverable OOMEs to occur (memory is recovered when the relevant libgraal compilations complete). It also seems related to async threads used for cleaning weak references when using G1 or ZGC as I cannot reproduce the failure under `-XX:+UseSerialGC`.
> 
> Installing a global `Thread.UncaughtExceptionHandler` that ignores `OutOfMemoryError`s resolves the problem.

Changes requested by dholmes (Reviewer).

test/jdk/java/util/concurrent/Executors/UnreferencedExecutor.java line 58:

> 56:                 throw new RuntimeException(e);
> 57:             }
> 58:         }

I'm not clear exactly what you are trying to achieve with this - is it just to not print the stacktrace when OOME occurs?

A UEH should not rethrow exceptions as they are effectively ignored as we are already at the final level of handling exceptions (the VM will print a one line warning if a UEH itself throws). If I understand what you want then I think the following would be more correct:

// Ignore OOME but do default handling for any other uncaught exception.
public void uncaughtException(Thread t, Throwable e) {
    if ( ! e instanceof OutOfMemoryError) {
        System.err.print("Exception in thread "" + t.getName() + "" ");
        e.printStackTrace(System.err);
    }
}


This doesn't stop the thread from terminating of course - the OOME already caused it to unwind its stack if we get this far.

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

PR Review: https://git.openjdk.org/jdk/pull/18098#pullrequestreview-1950797938
PR Review Comment: https://git.openjdk.org/jdk/pull/18098#discussion_r1533273137


More information about the core-libs-dev mailing list