[lworld] RFR: 8354404: [lworld] compiler/startup/StartupOutput.java crashes during AdapterHandlerLibrary::initialize() due to too little CodeCacheSize [v2]
duke
duke at openjdk.org
Fri Jul 25 09:26:07 UTC 2025
On Fri, 25 Jul 2025 09:23:08 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(MacroA...
>
> Marc Chevalier has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>
> - Merge remote-tracking branch 'origin/lworld' into JDK-8354404.StartupOutput-fails
> - trying a bit more...
> - Raise limit in StartupOutput.java
@marc-chevalier
Your change (at version c27fccdb4dd4f8974b2b6a9a614178cf08763f82) is now ready to be sponsored by a Committer.
-------------
PR Comment: https://git.openjdk.org/valhalla/pull/1509#issuecomment-3117050932
More information about the valhalla-dev
mailing list