RFR: 8309034: NoClassDefFoundError when initializing Long$LongCache
David Holmes
dholmes at openjdk.org
Tue Jun 13 12:22:41 UTC 2023
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 fragile I also marked it as requiring `vm.flagless` just to be safe.
A regression test was also created for the out-of-memory condition. This test seems quite stable across all platforms, and again was tested 50 times on each.
-------------
Commit messages:
- Remove logging from test
- Add OOM test
- Adjust logging and fix test comment
- 8309034: NoClassDefFoundError when initializing Long$LongCache
Changes: https://git.openjdk.org/jdk/pull/14438/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14438&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8309034
Stats: 210 lines in 6 files changed: 202 ins; 3 del; 5 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
More information about the hotspot-runtime-dev
mailing list