RFR: 8365229: ARM32: c2i_no_clinit_check_entry assert failed after JDK-8364269 [v3]
Aleksey Shipilev
shade at openjdk.org
Wed Aug 13 14:53:10 UTC 2025
On Wed, 13 Aug 2025 14:17:52 GMT, Andrew Dinn <adinn at openjdk.org> wrote:
>> 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.
>
> Correction - we just need to avoid creating the blob and checking the offsets when SharedRuntime::generate_i2c2i_adapters returns an empty code buffer. The nullptr checks are already in place in relocate.
>
> Aleksey, are you ok to do that?
So you want to `return false` or `return true` from `AdapterHandlerLibrary::generate_adapter_code` when, say, `buffer.insts()->size() == 0` right after `SharedRuntime::generate_i2c2i_adapters`? This does not seem to work, since `SharedRuntime` really wants to see some initial adapters generated, even in Zero case: https://github.com/openjdk/jdk/blob/001aaa1e49f2692061cad44d68c9e81a27ea3b98/src/hotspot/share/runtime/sharedRuntime.cpp#L2605-L2609
I honestly do not want to break some _other_ assumption that VM has by not generating some of the adapters for Zero, even if fake ones.
I am running out of time to spend on this, maybe you can play around with Zero yourself? `--with-jvm-variants=zero` would give you a build on x86_64 or AArch64 easily.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/26746#discussion_r2273715973
More information about the hotspot-compiler-dev
mailing list