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

[Ao Qi]

On Wed, 13 Aug 2025 08:41:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> When recording adapter entries, we record _offsets_, not the actual addresses:
>> 
>> 
>>   entry_offset[3] = handler->get_c2i_no_clinit_check_entry() - i2c_entry;
>> 
>> 
>> Every platform except ARM32 and Zero have all these entries set up, so offset are always sane. But those two platforms set up `nullptr` as `c2i_no_clinit_check_entry()`, because clinit barriers are unimplemented. So the new assert added in [JDK-8364269](https://bugs.openjdk.org/browse/JDK-8364269) fails encountering effectively `nullptr - i2c_entry` "garbage".
>> 
>> This PR is the second least horrible (IMO) fix for this: relaxing assert by checking that "out of range" values are actually wrapping around back to `0`/`nullptr`. Had to do it in unsigned ints to avoid UB. For the affected platforms, we do not actually access this problematic/garbage entry offset, since we are always checking if clinit barriers are enabled. So the assert is the only place where it matters.
>> 
>> The least horrible solution would be storing the actual `address`-es instead of `int` offsets. But that likely has footprint implications.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds` still works
>>  - [x] Linux ARM32 server fastdebug, `java -version` now works
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Polish comment

src/hotspot/share/runtime/sharedRuntime.cpp line 2850:

> 2848:   address i2c_entry = handler->get_i2c_entry();
> 2849:   entry_offset[0] = 0; // i2c_entry offset
> 2850:   entry_offset[1] = (handler->get_c2i_entry() != nullptr) ?

Should we handle the Zero case? Something like:

  entry_offset[1] = (handler->get_c2i_entry() != nullptr ZERO_ONLY(&& false)) ?
                    (handler->get_c2i_entry() - i2c_entry) : -1;
  entry_offset[2] = (handler->get_c2i_unverified_entry() != nullptr ZERO_ONLY(&& false)) ?
                    (handler->get_c2i_unverified_entry() - i2c_entry) : -1;

With Zero, `handler->get_i2c_entry()`, `handler->get_c2i_entry()` and `handler->get_c2i_unverified_entry()` are same and not nullptr. The build of Zero can trigger the problem.

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

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