RFR: 8364269: Simplify code cache API by storing adapter entry offsets in blob [v2]

[Andrew Dinn]

On Thu, 31 Jul 2025 08:56:00 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> If the entry offsets are stored in `AdapterBlob`, `AdapterHandlerEntry` can then just store a pointer to the blob and get rid of the offsets. `SharedRuntime::generate_i2c2i_adapters` can be updated to return the AdapterBlob. And when storing the AdapterHandlerEntry, pointer to the blob can be cleared and restored in `AdapterHandlerLibrary::lookup_aot_cache`.
>> This assumes the AdapterBlob won't be moved around in the code cache.
>> @adinn does this make sense?
>
> @ashu-mehra 
>> If the entry offsets are stored in AdapterBlob, AdapterHandlerEntry can then just store a pointer to the blob and get rid of the offsets.
> 
> I planned that originally but it doesn't work because of one special case. Method `AdapterHandlerLibrary::create_abstract_method_handler` does this:
> 
>   address wrong_method_abstract = SharedRuntime::get_handle_wrong_method_abstract_stub();
>   _abstract_method_handler = AdapterHandlerLibrary::new_entry(AdapterFingerPrint::allocate(0, nullptr));
>   _abstract_method_handler->set_entry_points(SharedRuntime::throw_AbstractMethodError_entry(),
>                                              wrong_method_abstract,
>                                              wrong_method_abstract,
>                                              nullptr);
> 
> So, in this one case we have a Frankenstein handler assembled from 3 disparate entry  points (+ nullptr) which are not derived from an associated adapter blob.

>  I looked at how these entry points are accessed and it seems they are mostly accessed by the routines in Method. So it should be feasible to handle the case of abstract methods there and get rid of this special adapter completely. @adinn wdyt?

I think maybe in follow-up RFE ;-)

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

PR Comment: https://git.openjdk.org/jdk/pull/26532#issuecomment-3163097384