RFR: Save/load i2c2i adapters [v2]

[Vladimir Kozlov]

On Tue, 12 Nov 2024 19:16:27 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> src/hotspot/share/oops/method.cpp line 1271:
>> 
>>> 1269:   // TODO: how to identify code cache full situation now that the adapter() can be
>>> 1270:   // non-null if AOT cache is in use
>>> 1271: #if 0
>> 
>> Can you check next (opposite to check in the following assert)?:
>> 
>>  if (adapter() != nullptr && !adapter()->is_linked()) {
>> 
>> The assumption is that we have enough CodeCache when we loading adapters from APT cache. Otherwise we should bailout (did you test such case?).
>> 
>> Is `is_linked()` is specific for adapters from AOT cache?
>
> `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.

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

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