RFR: 8309034: NoClassDefFoundError when initializing Long$LongCache

[ExE Boss]

On Tue, 13 Jun 2023 06:43:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

> When a class fails to initialize we try to preserve information about the original cause of the failure in a constructed `ExceptionInInitializerError` so that the EIIE can be attached to subsequent `NoClassDefFoundError`s thrown when an erroneous class is later accessed. If construction of the EIIE itself throws an exception we presently do nothing and the original problem is lost. The main reasons we would fail to create the EIIE are because we throw `OutOfMemoryError` or `StackOverflowError`. If the original class initialization failed due to stackoverflow then it is very likely the attempt to create the EIIE will as well. This leads to a situation, as per the obscure message in the bug synopsis, where you get totally unexpected failure modes with nothing to tell that the stackoverflow was the original cause. You would need to enable VM exception logging to try and determine that.
> 
> This enhancement improves the current situation by setting the cause of the class initialization failure to be a `StackOverflowError` or `OutOfMemoryError`, if the original failure was the same, and the attempt to create the EIIE fails. We cannot create these dynamically of course (else we'd have created the EIIE) so these are pre-allocated, stackless shared instances, created a VM startup. The preallocated `OutOfMemoryError` already exists so we just added a pre-allocated `StackOverflowError`. Now when we get the `NoClassDefFoundError` instead of the obscure and uninformative:
> 
> java.lang.NoClassDefFoundError: Could not initialize class java.lang.Long$LongCache
> 	at java.base/java.lang.Long.valueOf(Long.java:1202)
> 	at a.<init>(Test_545.java:10)
> 	at Test_545.j(Test_545.java:38)
> 	at Test_545.main(Test_545.java:25)
> 
> we now see an additional piece of information to shed light on the original issue:
> 
> java.lang.NoClassDefFoundError: Could not initialize class java.lang.Long$LongCache
> 	at java.base/java.lang.Long.valueOf(Long.java:1202)
> 	at a.<init>(Test_545.java:10)
> 	at Test_545.j(Test_545.java:38)
> 	at Test_545.main(Test_545.java:25)
> Caused by: java.lang.StackOverflowError
> 
> Testing:
> 
> Tiers 1-3 sanity testing
> 
> The original reproducer was adapted into a regression test, but it was discovered that the failure mode was only observed on x64 systems (not unexpected as different architectures have different stack requirements and so will exhibit different stackoverflow behaviour). This was run 50 times on each x64 platform to check for intermittent failures. As we know this test could be fr...

test/hotspot/jtreg/runtime/ClassInitErrors/TestOutOfMemoryDuringInit.java line 76:

> 74:         PrintStream printStream = new PrintStream(byteOS);
> 75:         e.printStackTrace(printStream);
> 76:         printStream.close();

`PrintStream` implements `AutoCloseable`, so this can use `try‑with‑resources`:
Suggestion:

        try(PrintStream printStream = new PrintStream(byteOS)) {
            e.printStackTrace(printStream);
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14438#discussion_r1230105991