JDK-8347406 : [REDO] C1/C2 don't handle allocation failure properly during initialization (RuntimeStub::new_runtime_stub fatal crash)
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 7u351,8u341,11,17,21,22,23,24,25
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86_64
  • Submitted: 2025-01-10
  • Updated: 2025-06-06
  • Resolved: 2025-03-25
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 25
25 b14Fixed
Related Reports
Causes :  
Causes :  
Cloners :  
Relates :  
Relates :  
Sub Tasks
JDK-8347407 :  
Description
compiler/startup/StartupOutput.java intermittently Internal Error (codeBlob.cpp:429) Initial size of CodeCache is too small

test command:
export test=test/hotspot/jtreg/compiler/startup/StartupOutput.java
function runJtreg() { jtreg -ea -esa -timeoutFactor:4 -v:fail,error,time,nopass -nr -w $dir/index-$1 $test &> $dir/$1.log ; if [[ 0 -ne $? ]] ; then echo -n "$1 " ; else rm -rf $dir/index-$1 $dir/$1.log ; fi ; } ; export -f runJtreg ; export dir="tmp-jtreg-"`basename ${test##* } .java | sed "s|#|_|"` ; rm -rf $dir ; mkdir -p $dir ; time seq 1000 | xargs -i -n 1 -P `nproc` bash -c "runJtreg {}" ; echo total fail number: `ls $dir/*.log 2> /dev/null | wc | awk '{print $1}'`

result:
STDERR:
 stdout: [[0.043s][warning][codecache] CodeCache is full. Compiler has been disabled.
[0.043s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize=
CodeCache: size=1200Kb used=1199Kb max_used=1199Kb free=0Kb
 bounds [0x00007f2ca0687000, 0x00007f2ca07b3000, 0x00007f2ca07b3000]
 total_blobs=285, nmethods=0, adapters=199, full_count=1
Compilation: disabled (not enough contiguous free space left), stopped_count=1, restarted_count=0
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (codeBlob.cpp:429), pid=155190, tid=155378
#  fatal error: Initial size of CodeCache is too small
#
# JRE version: OpenJDK Runtime Environment (23.0) (build 23)
# Java VM: OpenJDK 64-Bit Server VM (23, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x6495cc]  RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, int, int, OopMapSet*, bool, bool)+0x16c
#
# Core dump will be written. Default location: /var/tmp/tone/run/jtreg/jt-work/index-14/compiler/startup/StartupOutput/core.155190
#
# An error report file with more information is saved as:
# /var/tmp/tone/run/jtreg/jt-work/index-14/compiler/startup/StartupOutput/hs_err_pid155190.log

[error occurred during error reporting (), id 0xb, SIGSEGV (0xb) at pc=0x00007f2ca105c25a]
#
# If you would like to submit a bug report, please visit:
#   mailto:yansendao.ysd@alibaba-inc.com
#
];
 stderr: [OpenJDK 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
OpenJDK 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=
]
 exitValue = 134


Recurrence probability: 40/1000


cpu and enviroment infomation:
# uname -a ; cat /etc/os-release ; free -h ; lscpu | head -n 25 ; java -version ; java -Xinternalversion
Linux iZbp15rwnojzp4ihzwephwZ 5.10.134-16.1.al8.x86_64 #1 SMP Thu Dec 7 14:11:24 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
NAME="Alibaba Cloud Linux"
VERSION="3 (Soaring Falcon)"
ID="alinux"
ID_LIKE="rhel fedora centos anolis"
VERSION_ID="3"
UPDATE_ID="9"
PLATFORM_ID="platform:al8"
PRETTY_NAME="Alibaba Cloud Linux 3 (Soaring Falcon)"
ANSI_COLOR="0;31"
HOME_URL="https://www.aliyun.com/"

              total        used        free      shared  buff/cache   available
Mem:           60Gi       806Mi       3.2Gi       114Mi        56Gi        58Gi
Swap:            0B          0B          0B
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              32
On-line CPU(s) list: 0-31
Thread(s) per core:  2
Core(s) per socket:  16
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
BIOS Vendor ID:      Alibaba Cloud
CPU family:          6
Model:               106
Model name:          Intel(R) Xeon(R) Platinum 8369B CPU @ 2.70GHz
BIOS Model name:     pc-i440fx-2.1
Stepping:            6
CPU MHz:             3518.694
BogoMIPS:            5399.99
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           48K
L1i cache:           32K
L2 cache:            1280K
L3 cache:            49152K
NUMA node0 CPU(s):   0-31
openjdk version "23" 2024-09-17
OpenJDK Runtime Environment (build 23)
OpenJDK 64-Bit Server VM (build 23, mixed mode, sharing)
OpenJDK 64-Bit Server VM (23) for linux-amd64 JRE (23), built on 2024-02-24T04:59:15Z by "root" with gcc 9.3.1 20200408 (Red Hat 9.3.1-2)

Comments
Thanks for reporting it [~kvn]. I created JDK-8354119 to handle it.
09-04-2025

Actually AbstractAssembler() should have exit VM with OOM error in this case: AbstractAssembler::AbstractAssembler(CodeBuffer* code) { if (code == nullptr) return; CodeSection* cs = code->insts(); cs->clear_mark(); // new assembler kills old mark if (cs->start() == nullptr) { vm_exit_out_of_memory(0, OOM_MMAP_ERROR, "CodeCache: no room for %s", code->name()); } Why it does not?
09-04-2025

CompileBroker::handle_full_code_cache() did reported full CodeCache before crash: stdout: [[0.253s][warning][codecache] CodeCache is full. Compiler has been disabled. [0.253s][warning][codecache] Try increasing the code cache size using -XX:ReservedCodeCacheSize= CodeCache: size=1280Kb used=1278Kb max_used=1278Kb free=1Kb bounds [0x000001db79ed0000, 0x000001db7a010000, 0x000001db7a010000] total_blobs=268, nmethods=3, adapters=199, full_count=1 Compilation: disabled (not enough contiguous free space left), stopped_count=1, restarted_count=0 # # A fatal error has been detected by the Java Runtime Environment:
09-04-2025

This happens because we don't check result of buffer allocation at the beginning of code: UncommonTrapBlob* OptoRuntime::generate_uncommon_trap_blob() { // Allocate space for the code ResourceMark rm; // Setup code generation tools const char* name = OptoRuntime::stub_name(OptoStubId::uncommon_trap_id); CodeBuffer buffer(name, 2048, 1024); <<<<<<<<<<<<<<<<<<< this one. MacroAssembler* masm = new MacroAssembler(&buffer); This CodeBuffer constructor calls BufferBlob::create(const char* name, uint buffer_size) which does not check result of allocation.
09-04-2025

[~dfenacci] I hit today crash during `generate_uncommon_trap_blob()` call when running StartupOutput.java: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff8abb3500d, pid=131416, tid=46000 # # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-internal-LTS-2025-04-09-0101299.vladimir.kozlov.jdkgit) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-internal-LTS-2025-04-09-0101299.vladimir.kozlov.jdkgit, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Problematic frame: # V [jvm.dll+0x35500d] Assembler::subq+0x5d Command Line: -XX:InitialCodeCacheSize=1189K -XX:ReservedCodeCacheSize=1223k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [jvm.dll+0x35500d] Assembler::subq+0x5d (assembler_x86.cpp:16896) V [jvm.dll+0xebe356] OptoRuntime::generate_uncommon_trap_blob+0xc6 (runtime_x86_64.cpp:76) V [jvm.dll+0xeb6f84] OptoRuntime::generate+0x14 (runtime.cpp:180) V [jvm.dll+0x4c3d96] C2Compiler::initialize+0x1a6 (c2compiler.cpp:111) V [jvm.dll+0x5dab46] CompileBroker::init_compiler_runtime+0xe6 (compileBroker.cpp:1762) V [jvm.dll+0x5d8f8a] CompileBroker::compiler_thread_loop+0x11a (compileBroker.cpp:1903) V [jvm.dll+0x932622] JavaThread::thread_main_inner+0x282 (javaThread.cpp:773) CodeCache: size=1280Kb used=1280Kb max_used=1280Kb free=0Kb bounds [0x000001db79ed0000, 0x000001db7a010000, 0x000001db7a010000] total_blobs=270, nmethods=5, adapters=199, full_count=1 Compilation: disabled (not enough contiguous free space left), stopped_count=1, restarted_count=0
09-04-2025

Changeset: 48fac662 Branch: master Author: Damon Fenacci <dfenacci@openjdk.org> Date: 2025-03-25 07:10:47 +0000 URL: https://git.openjdk.org/jdk/commit/48fac6626c605f4679544e3dd24d5ad70561494a
25-03-2025

A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/23630 Date: 2025-02-14 11:04:20 +0000
20-02-2025

The same failure "fatal error: Initial size of CodeCache is too small" trigger by test compiler/startup/StartupOutput.java was observerd again.
19-01-2025

This is a short summary of what has happened up to now (with JDK-8326615 and JDK-8339700): * with the investigation of the original issue JDK-8326615 the problem seemed to be that there were 2 points in C1 and C2 where allocation failures in the code heap during initialization were not handled properly * on the other hand it seemed that increasing the minimum code cache allowed (i.e. by calculating the minimum code cache needed for interpreter+C1+C2) would avoid the issue altogether (the fix for JDK-8326615 (https://github.com/openjdk/jdk/pull/19280) was doing exactly that) * unfortunately that wasn’t really solving the issue at its root but if anything it was rather making it just less probable: if the allocation of the code cache that fails (with no space left) was happening in one of the problematic call path, the VM still crashes. * JDK-8339700 was filed for basically the same failure as the original one but it was now happening with other conditions * so, basically this REDO should is to fix the issue by making the code heap allocations in C1 and C2 always fail “gently” * the problematic call paths seem to be the 2 found in the original PR plus potentially another one, i.e.: * Compiler::init_c1_runtime -> Runtime1::initialize -> Runtime1::generate_blob_for -> Runtime1::generate_blob -> RuntimeStub::new_runtime_stub. * C2Compiler::initialize -> OptoRuntime::generate -> OptoRuntime::generate_stub -> Compile::Compile -> Compile::Code_Gen -> PhaseOutput::install -> PhaseOutput::install_stub -> RuntimeStub::new_runtime_stub * init_globals -> SharedRuntime::generate_stubs -> SharedRuntime::generate_handler_blob/generate_deopt_blob -> SafepointBlob::create
16-01-2025