RFR: Update nmethod caching and clean up unused/duplicate methods [v9]

[Ashutosh Mehra]

On Mon, 16 Jun 2025 18:46:16 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address ADinn's review comment
>>   
>>   Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>
> An other crash happened in aotCode/AOTCodeFlags.java on linux-amd64 in `find_entry()` which looks like during end of test run:
> 
> Event: 0.085 Thread 0x00007fc79002f0d0 Before exit entered
> 
> 
> 
> #  SIGSEGV (0xb) at pc=0x00007fc79680ead8, pid=3219122, tid=3219333
> #
> # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-internal-LTS-2025-06-16-1707161.vladimir.kozlov.leyden)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-internal-LTS-2025-06-16-1707161.vladimir.kozlov.leyden, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
> # Problematic frame:
> # V  [libjvm.so+0x69cad8]  AOTCodeCache::find_entry(AOTCodeEntry::Kind, unsigned int, unsigned int, unsigned int)+0x158
> 
> Command Line: -XX:AOTCache=hello.aot -Xlog:aot -Xlog:aot+codecache* Hello
> 
> Host: AMD EPYC 7J13 64-Core Processor, 12 cores, 23G, Oracle Linux Server release 8.10
> Time: Mon Jun 16 17:40:14 2025 UTC elapsed time: 0.094271 seconds (0d 0h 0m 0s)
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x00007fc790249570):  JavaThread "Training replay thread" daemon [_thread_in_vm, id=3219333, stack(0x00007fc7701e6000,0x00007fc7702e6000) (1024K)]
> 
> Stack: [0x00007fc7701e6000,0x00007fc7702e6000],  sp=0x00007fc7702e3440,  free space=1013k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x69cad8]  AOTCodeCache::find_entry(AOTCodeEntry::Kind, unsigned int, unsigned int, unsigned int)+0x158  (aotCodeCache.cpp:1001)
> V  [libjvm.so+0x69e09f]  AOTCodeCache::find_code_entry(methodHandle const&, unsigned int)+0x22f  (aotCodeCache.cpp:955)
> V  [libjvm.so+0xb8cfc3]  CompileBroker::compile_method_base(methodHandle const&, int, int, int, CompileTask::CompileReason, bool, bool, Thread*)+0x103  (compileBroker.cpp:1428)
> V  [libjvm.so+0xb8dd68]  CompileBroker::compile_method(methodHandle const&, int, int, int, bool, CompileTask::CompileReason, DirectiveSet*, JavaThread*)+0x4b8  (compileBroker.cpp:1729)
> V  [libjvm.so+0xb8e40c]  CompileBroker::compile_method(methodHandle const&, int, int, int, bool, CompileTask::CompileReason, JavaThread*)+0xbc  (compileBroker.cpp:1614)
> V  [libjvm.so+0xb4d29c]  CompilationPolicy::maybe_compile_early(methodHandle const&, JavaThread*) [clone .part.0]+0x19c  (compilationPolicy.cpp:120)
> V  [libjvm.so+0xb4d78d]  CompilationPolicy::replay_training_at_init_impl(InstanceKlass*, JavaThread*)+0x3ad  (compilationPolicy.cpp:176)
> V  [libjvm.so+0xb5244a]  CompilationPolicy::replay_training_...

@vnkozlov 

>I submitted testing after this was integrated and one closed test crashed on MacOS-aarch64 during "product" run when GC trying to purge nmethod:

I can see how this could have happened. If the nmethod is purged after the AOT code cache has been closed, then `AOTCodeCache::is_address_in_aot_cache()` will return false. In `nmethod::purge`, this can cause the `_immutable_data` (which is part of AOTCodeCache region) to be incorrectly freed:


  if (_immutable_data != data_end() && !AOTCodeCache::is_address_in_aot_cache((address)_oop_maps)) {
    os::free(_immutable_data);
    _immutable_data = blob_end(); // Valid not null address
  }

I think I should be copying immutable data in a C heap region when loading nmethod from the AOT Code Cache.
`CodeBlob;:oop_map` also has the same problem.

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

PR Comment: https://git.openjdk.org/leyden/pull/71#issuecomment-2977719486