RFR: Save/load i2c2i adapters [v2]

[Ashutosh Mehra]

On Mon, 2 Dec 2024 20:51:48 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> `is_linked()` is being set for every AdapterHandlerEntry when its code is either generated or loaded from AOT cache.
>> 
>> Regarding the original block of code that this check pertains to:
>> 
>> 
>>   // If the code cache is full, we may reenter this function for the
>>   // leftover methods that weren't linked.
>>   if (adapter() != nullptr) {
>>     return;
>>   }
>> 
>> 
>> The comment seem to indicate that we may reenter this function for a Method* for which adapter code has already been generated. However I am not able to trace the code path that may result in re-entering this function. Can you please explain under what conditions is this possible? @vnkozlov
>
> The comment was added for [JDK-7033141](https://bugs.openjdk.org/browse/JDK-7033141)
> https://hg.openjdk.org/jdk9/jdk9/hotspot/rev/d3b9f2be46ab
> 
> I think the comment is incorrect. It should talk about PermGen space based on bug's evaluation:
> 
> "If the VM runs out of permgen space while allocating the constant pool cache, it tries to reverify the bytecodes in the methods for the class. But the bytecodes have been rewritten. I'm working on a fix that un-rewrites the bytecodes so that the VM can try again to link this class. I am debugging this now - actually I'm debugging my code that forces the error condition (for testing) since this but only reproduces for a specific error condition.
> It's not very unlikely for an application to run out of permgen (or code cache as in bug 6947901) so it is probably worth fixing for jdk 7. The fix is relatively low risk once it's debugged."
> 
> [JDK-6947901](https://bugs.openjdk.org/browse/JDK-6947901) shows failure with -Xint too. 
> 
> But I imaging that full CodeCache may also cause failure to create adapters which will cause "un-rewrites" bytecode.
> 
> We don't have PermGen anymore. The only issue is space in CodeCache for adapters. Which you can check before loading adapters since you know size of adapters code in AOT cache.
> 
> I don't think we currently check that CodeCache size is the same during product run as during AOT Assembly phase. Adapters are allocated in `NonNMethod` section.

@vnkozlov I added a change to fix this by checking if adapter is shared or not. If it is not shared and is not null, we return, else we continue. This should restore the behavior of returning early if link_method() gets called again due to code cache full.

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

PR Review Comment: https://git.openjdk.org/leyden/pull/25#discussion_r1879273116