RFR: 8365229: ARM32: c2i_no_clinit_check_entry assert failed after JDK-8364269 [v3]

[Aleksey Shipilev]

On Wed, 13 Aug 2025 13:03:22 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> See new commit. Zero build now passes, I am running bootcycle-images now.
>
> I don't believe this fix is correct and I'm not clear that it is even needed. Is something actually breaking with the zero code before the latest commit?
> 
> The CPU-specific shared runtime code is called to fill in entry addresses for an AdapterHandlerEntry. That does not imply that any such handler is backed by an AdapterBlob. In particular on Zero there cannot be a corresponding AdapterBlob because we have no runtime compiler capable fo generating one. There is one other case where an AdapterHandlerEntry has no corresponding AdapterBlob -- the abstract method handler's AdapterHandlerEntry is assembled usng several disparate methods that do not belong to a single generated blob.
> 
> On CPUs where a blob is created the offsets of its secondary entries must be stored in the blob in order to allow the blob to be correctly saved to and restored from the AOT cache. At restore time we populate the entry array using he offsets and then update a newly created AdapterHandlerEntry using the blob start address and this aaray. That never happens on Zero. We never have to translate entries in a Zero AdapterHandlerEntry to offsets and we never have to translate stored offsets to entry addresses.
> 
> So, I don't think there is any need to change the assignment of entry addresses in the Zero implementation of SharedRuntime::generate_i2c2i_adapters(). Unless there is something that has actually broken. Indeed, I would argue that the latest patch is not just needless but damaging as it actually removes a sanity check. The original code sets the first 3 entries to a dummy stub that catches an invalid use of the AdapterHandlerEntry. If we ony set the first entry then we have less protection against invalid calls.

Yes. In Zero entries point to the same (fake, error-throwing) stub, mostly for diagnostics. Which _also_ means their offsets are all zero, which trips the assert. I think Zero can just skip setting the entries, so that we ride on the current code that treats unset entries well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26746#discussion_r2273429175