Integrated: 8365229: ARM32: c2i_no_clinit_check_entry assert failed after JDK-8364269
Aleksey Shipilev
shade at openjdk.org
Wed Aug 13 20:52:19 UTC 2025
On Tue, 12 Aug 2025 14:06:35 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
> - [x] Linux x86_64 zero fastdebug, `make bootcycle-images` now works
This pull request has now been integrated.
Changeset: 9c266ae8
Author: Aleksey Shipilev <shade at openjdk.org>
URL: https://git.openjdk.org/jdk/commit/9c266ae83c047025d778da41e413701ac3b50b03
Stats: 20 lines in 3 files changed: 11 ins; 1 del; 8 mod
8365229: ARM32: c2i_no_clinit_check_entry assert failed after JDK-8364269
Reviewed-by: kvn, adinn, bulasevich, phh
-------------
PR: https://git.openjdk.org/jdk/pull/26746
More information about the hotspot-compiler-dev
mailing list