RFR: 8357175: Failure to generate or load AOT code should be handled gracefully

Vladimir Kozlov kvn at openjdk.org
Sun Jun 1 00:22:58 UTC 2025


On Sat, 31 May 2025 19:50:04 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> By default a failed AOT code should be discarded with UL message about it by request (`-Xlog:aot+codecache+*=debug`) and VM and AOT code processing should continue run.
>> 
>> Unless we hit some catastrophic failure: OOM for example. This is similar how JIT compilers behave.
>> 
>> I reordered VM configuration settings checking (`Config::verify()`) so that we switch off AOT code caching type which depends on these VM settings. For example, AOT adapters do not operate on oops - they are not affected by compressed oops settings/encoding. I removed `_objectAlignment` check because CDS already does this check when open archive.
>> 
>> The AOT relocation processing for a blob will skip this blob when corresponding address is not found instead of bailing out VM in product mode. In debug VM it will issue assert so we know about missing address. These changes are in `AOTCodeAddressTable::id_for_address()`
>> 
>> I kept `fatal()` in `AOTCodeAddressTable::for_address_for_id()` for incorrect ID we read from archive. The archive could be corrupted if ID is wrong.
>> 
>> I did small code cleanup/renaming.
>>  
>> Tested: tier1-10
>
> src/hotspot/share/code/aotCodeCache.cpp line 985:
> 
>> 983: // ------------ process code and data --------------
>> 984: 
>> 985: #define BAD_ADDRESS_ID -2
> 
> Can you please add a comment to indicate why -1 is not used.
> From the comment in `id_for_address`, I guess it is because -1 is a valid id for representing jump to itself in static call stub. Is that correct?
> 
>   int id = -1;
>   if (addr == (address)-1) { // Static call stub has jump to itself
>     return id;
>   }

Yes, it is correct. I will add the comment:

// Can't use -1. It is valid value for jump to iteself destination
// used by static call stub: see NativeJump::jump_destination().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25525#discussion_r2118454632


More information about the hotspot-compiler-dev mailing list