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

[Marc Chevalier]

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

@TobiHartmann was wondering why it was so different, so I've dug in it.

There are a lot more adapters in Valhalla than in mainline right now (700 vs 300), which causes a multiple hundred kilo additional usage (between 1 and 2 per adapter). It seems that adapters for a same signature are not cached (at least in debug). But this part of the code is widely different between Valhalla and mainline, and that's because [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209) changed a lot of things there recently, and hasn't yet been merge in Valhalla it seems.

I've compared with mainline before this change, and it behaves similarly as Valhalla: a lot more adapters (very close in cardinal and set as Valhalla), same kind of weird crashes for lack of adapter space even for relatively high memory settings. Valhalla still seems to need a bit more memory, but it also needs more adapters, quite some being related to flat values in `jdk.internal.misc.Unsafe`. Nothing crazy. I think the next main -> valhalla main will change the profile of `java -version` wrt. code cache limit quite radically.

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

PR Comment: https://git.openjdk.org/valhalla/pull/1509#issuecomment-3102941360