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 compilation. As a result, no chunk allocations are detected by the `CompilationMemoryStatistic` infrastructure. The fix is to add a `ResourceMark` around the temporary allocations triggered by `declared_field->name()->as_utf8()`. That will keep the maximum size of the arena low enough for the expected growing to happen only during the compilation and brings us back to baseline behavior. Thanks, Tobias --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - JDK-8382344 Changes: https://git.openjdk.org/valhalla/pull/2330/files Webrev: https://webrevs.openjdk.org/?repo=valhalla&pr=2330&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8382344 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/valhalla/pull/2330.diff Fetch: git fetch https://git.openjdk.org/valhalla.git pull/2330/head:pull/2330 PR: https://git.openjdk.org/valhalla/pull/2330
