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

[Aleksey Shipilev]

On Wed, 13 Aug 2025 13:17:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> Is something actually breaking with the zero code before the latest commit?
>> 
>> 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. This readily fails even the simple `make images` on Zero.
>> 
>> I think Zero can just skip setting the entries, so that we ride on the current code that treats unset entries well.
>
> The alternative is to modify the asserts to accept zero offsets for non-i2c entries, if you think that is better? It caters for Zero, but relaxes the condition for non-Zero code. So it is like choosing where you want to open the assert gap: for Zero, or for everything else?

Oh no, it is even worse: some (all?) Zero adapters have no instructions at all, so not only we fail one side of this assert, but also the other side, since `cb->insts()->size()` is `0`. This is what is awkward about Zero code: the VM expects entry points to be _in the stub_, which implies _something_ was generated in the stub. But Zero skips any code generation, and just YOLO-es the external address as "entry point". So offset computations stop making any sense at all! In other words, Zero tries to do some diagnostics, but it does so in a way that is not compatible with the rest of VM, at least on assert side.

So I think it is fine for Zero to stop pretending there are valid entry points for c2i entries at least.

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

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