ADDITIONAL SYSTEM INFORMATION :
Linux x86_64, OpenJDK 22.0.1

A DESCRIPTION OF THE PROBLEM :
Our application server places heavy use on the CodeCache. In production, with the maximum size setting too small, we observe an exception thrown:

Caused by: java.lang.ExceptionInInitializerError:
Caused by: java.lang.NoClassDefFoundError: Could not initialize class java.time.temporal.WeekFields
Caused by: Exception java.lang.VirtualMachineError: Out of space in CodeCache for adapters
at java.base/java.time.format.DateTimeFormatterBuilder$WeekBasedFieldPrinterParser.printerParser(DateTimeFormatterBuilder.java:5264)
at java.base/java.time.format.DateTimeFormatterBuilder$WeekBasedFieldPrinterParser.format(DateTimeFormatterBuilder.java:5248)
at java.base/java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.format(DateTimeFormatterBuilder.java:2529)
at java.base/java.time.format.DateTimeFormatter.formatTo(DateTimeFormatter.java:1905)
at java.base/java.time.format.DateTimeFormatter.format(DateTimeFormatter.java:1879)
at java.base/java.time.LocalDate.format(LocalDate.java:1797)
at our.code ...

When this happens, the java.time infrastructure is left unable to be fully initialized. From here, our application crashes very badly, as even e.g. logging a timestamp can cause an exception to be thrown.

We try to set -XX:OnError= to crash the JVM in this case, but it is not effective, since the VirtualMachineError is considered "recoverable". However, there is no clear action the user code or author can take, to recover from this situation.

1) The program can not continue as normal without java.time, and cannot fix this
2) The program can not reasonably catch this error or even guarantee to shut down, as the Error could be thrown from any thread at basically any time, and there is no cross-cutting "catch on any thread" - the unhandled exception handler doesn't see it since the eventual wrapped exception is caught by a top level retry loop.

So we are left in a live-crashed state until an administrator or trained admin-bot outside the JVM detects the situation and manually terminates the process.

Obviously, we will increase the CodeCache allocation to avoid this problem, but all the same we want to make our application robust to misconfigurations.

My suggested solution is that running out of CodeCache space for adapters should be treated as irrecoverable and crash the VM - it is better to fail safe, than valiantly continue to run and exhibit unexpected behaviors. More broadly, we would happily "opt in" to all VirtualMachineErrors being treated as fatal.

(Original post: https://mail.openjdk.org/pipermail/hotspot-dev/2024-August/092046.html)