On Fri, 17 Apr 2026 13:10:51 GMT, Quan Anh Mai <[email protected]> wrote:
>> The test `compiler/print/CompileCommandMemLimit.java` fails because we >> suddenly don't hit the expected memory limit anymore when compiling empty >> method `TestMain::method2` with `--enable-preview`. In fact, the VM is >> reporting that no memory is used for compilation at all: >> >> c1 (27) (ok) Arena usage >> compiler/print/CompileCommandMemLimit$TestMain::method2(()V): Total Usage: 0 >> >> >> I added some logging to the >> `CompilationMemoryStatistic::on_arena_chunk_allocation` path in >> `ChunkPool::allocate_chunk` and noticed that the only difference is that >> with `--enable-preview` we don't have this allocation in >> `Thread::current()->resource_area()`: >> >> V [libjvm.so+0x4bb99c] ChunkPool::allocate_chunk(Arena*, unsigned long, >> AllocFailStrategy::AllocFailEnum)+0x16c >> V [libjvm.so+0x4bc28d] Arena::grow(unsigned long, >> AllocFailStrategy::AllocFailEnum)+0x5d >> V [libjvm.so+0x7a4d83] >> DebugInformationRecorder::DebugInformationRecorder(OopRecorder*)+0x43 >> V [libjvm.so+0x58e3d1] Compilation::initialize()+0xb1 >> V [libjvm.so+0x58fe1c] Compilation::compile_method()+0x6c >> V [libjvm.so+0x590190] Compilation::Compilation(AbstractCompiler*, ciEnv*, >> ciMethod*, int, BufferBlob*, bool, DirectiveSet*)+0x1f0 >> V [libjvm.so+0x590866] Compiler::compile_method(ciEnv*, ciMethod*, int, >> bool, DirectiveSet*)+0xb6 >> >> >> The reason is that with `--enable-preview` -> `-XX:+UseFieldFlattening` we >> have a new code path `ciInstanceKlass::compute_nonstatic_fields_impl` that >> processes flat fields and creates `ciField` objects for those. We hit that >> code path very early during `ciObjectFactory::init_shared_objects` for some >> core-libs klass: >> >> >> V [libjvm.so+0x4bb99c] ChunkPool::allocate_chunk(Arena*, unsigned long, >> AllocFailStrategy::AllocFailEnum)+0x16c >> V [libjvm.so+0x4bc28d] Arena::grow(unsigned long, >> AllocFailStrategy::AllocFailEnum)+0x5d >> V [libjvm.so+0x10bfdce] Symbol::as_C_string() const+0x1e >> V [libjvm.so+0x69da5c] ciField::ciField(ciField*, ciField*)+0x7c >> V [libjvm.so+0x6a6ab8] >> ciInstanceKlass::compute_nonstatic_fields_impl(GrowableArray<ciField*> >> const*, GrowableArray<ciField*> const*)+0x1168 >> V [libjvm.so+0x6bb22c] ciObjectFactory::init_shared_objects()+0xc8c >> V [libjvm.so+0x6bcc56] ciObjectFactory::initialize()+0x96 >> V [libjvm.so+0x759535] CompileBroker::compiler_thread_loop()+0x1a5 >> ``` >> >> As a result, the `Thread::current()->resource_area()` is growing already >> before the allocation and there is no need to grow it anymore during the >> compi... > > src/hotspot/share/ci/ciField.cpp line 238: > >> 236: ResourceMark rm; >> 237: char buffer[256]; >> 238: jio_snprintf(buffer, sizeof(buffer), "%s.%s", >> declared_field->name()->as_utf8(), subfield->name()->as_utf8()); > > Instead, can we allocate 2 stack buffers for these names to be copied into? I thought about that too and one could use `Symbol::as_C_string(char* buf, int size)` to copy into the stack buffer directly. Unfortunately, that one is not available via `ciSymbol` yet, so we would need to add a wrapper just for this particular use side. That didn't feel worth it, so it went with the `ResourceMark` solution for now. I think it shouldn't make much of a difference. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2330#discussion_r3100717943
