JDK-8295724 : VirtualMachineError: Out of space in CodeCache for method handle intrinsic
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,20
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2022-10-20
  • Updated: 2024-08-10
  • Resolved: 2022-12-06
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 17 JDK 20
17.0.7-oracleFixed 20 b27Fixed
Related Reports
Duplicate :  
JDK-8297267 - RenaissanceStressTest.java failed with "VirtualMachineError: Out of space in CodeCache for method handle intrinsic"
Relates :  
JDK-8296334 - [Loom] continuation native intrinsic allocation failure possible
Relates :  
JDK-8305088 - SIGSEGV in Method::is_method_handle_intrinsic
Relates :  
JDK-8290025 - Remove the Sweeper
Relates :  
JDK-8296336 - Fallback for method handle intrinsic allocation failures
Relates :  
JDK-8298947 - compiler/codecache/MHIntrinsicAllocFailureTest.java fails intermittently
Description
We were testing an application with small code cache (-XX:ReservedCodeCacheSize=20000000) and enabled segmentation (-XX:+SegmentedCodeCache). The JIT compilers have filled up both, the space for non-profiled nmethods and the one for profiled nmethods, and then, the JIT compilers got switched off as intended by the test (it is a stress test for exactly this situation).
After the sweeper removal (JDK-8290025), the VM terminates with "java.lang.VirtualMachineError: Out of space in CodeCache for method handle intrinsic". Unlike normal JIT compiled Java methods, method handle intrinsics are strictly required by the VM, so we should try harder to get them created. They are allocated in the non-profiled space and alternatively in the profiled space. In the situation of the test, unloading is already requested ("_unloading_threshold_gc_requested"), but not yet done.
We could wait for the GC to do the job or reserve some space. Or allocate in NonNMethod space.
Comments
The new test has a minor issue. Fix for JDK-8298947 is integrated into the PR and has been reviewed.
30-12-2022
It looks like this caused a regression / test bug: JDK-8298947
16-12-2022
Fix Request (17u): The issue has been reported for 17u: https://issuetracker.google.com/issues/260643754 In addition, the included test fails in 17u without the fix and passes with it. Risk: The fix is relatively new, but the behavior only changes at the point at which the code cache segments for profiled and non-profiled nmethods are full and the VM needs to create a method handle intrinsic. Without this fix, the VM terminates unexpectedly. With it, it can continue running and the VM has a chance to recover. Doesn't apply cleanly, but it's not hard to resolve (see PR).
13-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/951 Date: 2022-12-13 11:58:23 +0000
13-12-2022
Changeset: cd2182a9 Author: Martin Doerr <mdoerr@openjdk.org> Date: 2022-12-06 20:56:48 +0000 URL: https://git.openjdk.org/jdk/commit/cd2182a9967917e733e486d918e9aeba3bd35ee8
06-12-2022
There is an easy way to reproduce it: jdk/bin/java -XX:ReservedCodeCacheSize=2496k -XX:+SegmentedCodeCache -version This passes when using the linked PR. (Note that this reproducer can also run into other failures like NoSuchMethodException. It's not suitable for an automatic regression test.)
24-11-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10933 Date: 2022-11-01 13:13:46 +0000
01-11-2022