[lworld] RFR: 8354404: [lworld] compiler/startup/StartupOutput.java crashes during AdapterHandlerLibrary::initialize() due to too little CodeCacheSize

Tobias Hartmann thartmann at openjdk.org
Fri Jul 25 08:32:07 UTC 2025


On Wed, 16 Jul 2025 14:59:48 GMT, Marc Chevalier <mchevalier at openjdk.org> wrote:

> Experimentally, replacing 800 with 2000 is needed to have this test pass on all platform. Somehow, while 1300 seems ok on my Linux (while having a fair share of "CodeCache is full. Compiler has been disabled." messages), Windows boxes seems to struggle even with 1800. Not sure why: isn't the size of the things in the code cache (that is, the code), depends mostly on the encoding of instructions, that is dependent on architecture, not OS? Anyway, it happens reliably, so something had to be done!
> 
> Let's compare (with debug builds so I can use `CodeCacheMinimumUseSpace`, that is 1200k by default on debug builds), for various values of `ReservedCodeCacheSize` (in k), when running `-version`. For mainline:
> - [4, 28]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 3000 bytes. Error detail: `CodeCache: no room for StubRoutines` (continuation stubs)
>   ```
>   coming from
>   - `report_should_not_call(char const*, int)`
>   - `initialize_stubs(BlobId, int, int, char const*, char const*, char const*)`
>   - `StubRoutines::initialize_continuation_stubs()`
>   - `continuation_stubs_init()`
>   - `init_globals()`
>   
>   with `3000` being `20000` for `ReservedCodeCacheSize` between 5 and 24, and being `500` for `ReservedCodeCacheSize` = 4 (the minimum).
> 
> - [29, 32] `fatal error: Initial size of CodeCache is too small`
>   https://github.com/openjdk/jdk/blob/b787ad6f690df5c82a1efc5ccac658a9238ff201/src/hotspot/share/code/codeBlob.cpp#L579
>   coming from
>   - `RuntimeStub::new_runtime_stub(char const*, CodeBuffer*, short, int, OopMapSet*, bool, bool)`
>   - `SharedRuntime::generate_jfr_return_lease()`
>   - `SharedRuntime::generate_jfr_stubs()`
>   - `init_globals()`
> 
> - [33, 1112]
>   ```
>   # There is insufficient memory for the Java Runtime Environment to continue.
>   # Native memory allocation (malloc) failed to allocate 1108928 bytes. Error detail: CodeCache: no room for Interpreter
>   ```
>   - `...`
>   - `report_should_not_call(char const*, int)`
>   - `StubQueue::StubQueue(StubInterface*, int, Mutex*, char const*)`
>   - `TemplateInterpreter::initialize_stub()`
>   - `interpreter_init_stub()`
>   - `init_globals()`
> 
> - [1113, 1116] SIGSEGV
>   - `CodeSection::emit_int8(unsigned char)`
>   - `AbstractAssembler::emit_int8(int)`
>   - `Assembler::push(Register)`
>   - `MacroAssembler::enter()`
>   - `RegisterSaver::save_live_registers(MacroAssembler*, int, int*, bool)`
>   - `SharedRuntime::generate_resolve_blob(StubId, unsigne...

Thanks for spending time on looking into this thoroughly. The fix looks good to me for now. As we discussed offline, let's file a follow-up RFE to check again once [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209) is integrated.

-------------

Marked as reviewed by thartmann (Committer).

PR Review: https://git.openjdk.org/valhalla/pull/1509#pullrequestreview-3054577186


More information about the valhalla-dev mailing list