RFR: 8357402: Crash in AdapterHandlerLibrary::lookup

[Aleksey Shipilev]

On Thu, 22 May 2025 17:13:05 GMT, Vladimir Kozlov <kvn 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

So looks like `!AOTCodeCache::is_dumping_adapter()` and `AOTCodeCache::is_using_adapter()` are not complementary then, right? This is what gets us into the problem?

Predicating AOT adapter handler table accesses on `AOTCodeCache::is_using_adapter()` makes sense.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25398#pullrequestreview-2862119568