8309034: NoClassDefFoundError when initializing Long$LongCache

[dholmes-ora]

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

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8309034: NoClassDefFoundError when initializing Long$LongCache (Enhancement - P4)

Reviewers

• Coleen Phillimore (@coleenp - Reviewer) ⚠️ Review applies to 4ec4c085
• Frederic Parain (@fparain - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/14438/head:pull/14438
$ git checkout pull/14438

Update a local copy of the PR:
$ git checkout pull/14438
$ git pull https://git.openjdk.org/jdk.git pull/14438/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 14438

View PR using the GUI difftool:
$ git pr show -t 14438

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/14438.diff

Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back dholmes! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@dholmes-ora The following label will be automatically applied to this pull request:

• hotspot

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[dholmes-ora]

/label add hotspot-runtime
/label remove hotspot

[openjdk]

@dholmes-ora
The hotspot-runtime label was successfully added.

[openjdk]

@dholmes-ora
The hotspot label was successfully removed.

[mlbridge]

Webrevs

• 01: Full - Incremental (fc8fdc5d)
• 00: Full (4ec4c085)

[coleenp]

Ok. Looks good to me. Thanks for fixing this.

[openjdk]

@dholmes-ora This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8309034: NoClassDefFoundError when initializing Long$LongCache

Reviewed-by: coleenp, fparain

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 96 new commits pushed to the master branch:

• 4ca548f: 8310326: Incorrect position of the synthetic unnamed class
• a059576: 8310187: Improve Generational ZGC jtreg testing
• 9a68ec8: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary ResourceMark
• 0878872: 8310020: MacroAssembler::call_VM(_leaf) doesn't consistently check for conflict with C calling convention.
• 79069c5: 8310314: Misplaced "unnamed classes are a preview feature and are disabled by default" error
• 96a7db7: 8309228: Clarify EXPERIMENTAL flags comment in hotspot/share/runtime/globals.hpp
• b2e86ae: 8304478: Initial nroff manpage generation for JDK 22
• 7b45c8f: 8241800: Disable IPV6_MULTICAST_ALL to prevent interference from all multicast groups
• 137a5f7: 8310105: LoongArch64 builds are broken after JDK-8304913
• 33c6ec9: 8310019: MIPS builds are broken after JDK-8304913
• ... and 86 more: https://git.openjdk.org/jdk/compare/57fc9a3e968cafe3b618a216630e703a39d5676e...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[dholmes-ora]

Thanks @coleenp !

[fparain]

Looks good to me.
Thank you for making those initialization issues easier to investigate.

[dholmes-ora]

Thanks for the review @fparain !

/integrate

[openjdk]

Going to push as commit 4c3efb3.
Since your change was applied there have been 103 commits pushed to the master branch:

• 1120106: 8310458: Fix build failure caused by JDK-8310049
• 09174e0: 8310049: Refactor Charset tests to use JUnit
• 99d2a9a: 8310330: HttpClient: debugging interestOps/readyOps could cause exceptions and smaller cleanup
• 31b6fd7: 8309258: RISC-V: Add riscv_hwprobe syscall
• 4a9cc8a: 8309266: C2: assert(final_con == (jlong)final_int) failed: final value should be integer
• 4e4e586: 8310194: Generational ZGC: Lock-order asserts in JVMTI IterateThroughHeap
• e1906e7: 8310027: Fix -Wconversion warnings in nmethod and compiledMethod related code
• 4ca548f: 8310326: Incorrect position of the synthetic unnamed class
• a059576: 8310187: Improve Generational ZGC jtreg testing
• 9a68ec8: 8219357: G1: G1GCPhaseTimes::debug_phase uses unnecessary ResourceMark
• ... and 93 more: https://git.openjdk.org/jdk/compare/57fc9a3e968cafe3b618a216630e703a39d5676e...master

Your commit was automatically rebased without conflicts.

[openjdk]

@dholmes-ora Pushed as commit 4c3efb3.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.