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

[Aleksey Shipilev]

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

>> 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.

If you are curious, this is where Zero catches fire during build:


report_vm_error(...)
AdapterBlob::AdapterBlob()
AdapterBlob::create()
AdapterHandlerLibrary::generate_adapter_code()
AdapterHandlerLibrary::create_adapter()
AdapterHandlerLibrary::initialize()
SharedRuntime::init_adapter_library()
init_globals()


So we enter that path routinely, without any AOT features enabled...

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

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