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

[Andrew Dinn]

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

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

Ah, yikes, so we are actually creating an AdapterBlob here?

Oh dear, it seems we go on to do so at line 2849 in sharedRuntime.cpp.

    int entry_offset[AdapterBlob::ENTRY_COUNT];
    assert(AdapterBlob::ENTRY_COUNT == 4, "sanity");
    address i2c_entry = handler->get_i2c_entry();
    entry_offset[0] = 0; // i2c_entry offset
    entry_offset[1] = handler->get_c2i_entry() - i2c_entry;
    entry_offset[2] = handler->get_c2i_unverified_entry() - i2c_entry;
    entry_offset[3] = handler->get_c2i_no_clinit_check_entry() - i2c_entry;

    adapter_blob = AdapterBlob::create(&buffer, entry_offset); <== oops!

Ok, so we need to avoid doing that!

A fortiori, on Zero, because the result is broken even modulo the problme this patch is trying to fix. A few lines later we do this:

    handler->relocate(adapter_blob->content_begin());

What that does is compute a delta from the handler's first entry to the blob's start address and then apply that delta to all four addresses. So, that's not going to work.

We need to fix this in two places.

1. we should bypass the blob create if we get back a buffer with length 0 i.e. if no code was generated -- that will fix Zero
2. We should tweak AdapterHandlerEntry::relocate() so that it only applies the delta when the corresponding entry address != nullptr -- that will fix arm32 i.e. will ensure that any attempt to use the invalid entry will be using a 0 address.

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

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