RFR: 8309034: NoClassDefFoundError when initializing Long$LongCache [v2]

[David Holmes]

> 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...

David Holmes has updated the pull request incrementally with one additional commit since the last revision:

  Use try-with-resources

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14438/files
  - new: https://git.openjdk.org/jdk/pull/14438/files/4ec4c085..fc8fdc5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14438&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14438&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14438.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14438/head:pull/14438

PR: https://git.openjdk.org/jdk/pull/14438