RFR: 8357402: Crash in AdapterHandlerLibrary::lookup

[Vladimir Kozlov]

On Thu, 22 May 2025 18:58:13 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> See details in the bug report.
>> 
>> The issue is: AOT adapters table `_aot_adapter_handler_table` is accessed during "Assembly" phase when this table is not valid. It happened because the guard in `AdapterHandlerLibrary::lookup()` became invalid after we dumped and close AOT code cache. `AOTCodeCache::is_dumping_adapter()` will return `false` in such case. Instead we should use `AOTCodeCache::is_using_adapter()` check which is valid only during "Production" run when AOT adapters are loaded and `_aot_adapter_handler_table` is valid. I added this guard in all places where the table is accessed.
>> 
>> Because we can't rely on `AOTCodeCache::is_dumping_adapter()` during AOT archive creation I restored `CDSConfig::is_dumping_adapters()` to use instead. `AOTCodeCache::is_dumping_adapter()` check is only used when we  are storing adapters in AOT code cache.
>> 
>> I also noticed the hash clash for some adapters signature (we caught it by comparing recorded and actual signature) and as result we completely bailout AOT code loading. We should not do complete bail out - instead we should just skip this one blob. We are not modifying data in AOT code cache - it is still valid for other code blobs.
>> 
>> tested hs-tier1-10, jck, xcomp, stress
>
> src/hotspot/share/oops/method.cpp line 413:
> 
>> 411:   if (CDSConfig::is_dumping_adapters() && _adapter != nullptr) {
>> 412:     _adapter->remove_unshareable_info();
>> 413:     _adapter = nullptr;
> 
> We shouldn't be setting _adapter to null here. This breaks the link between Method and its adapter in the AOT cache.

Without nulling it I got issue with referencing dead memory through this field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25398#discussion_r2103235674