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