On Fri, 11 Sep 2026 16:14:44 GMT, Ashutosh Mehra <[email protected]> wrote:
>> One partial solution: Fold the conditional flag expression into the macro >> call, and have the macro somehow incorporate logic to check or assert that >> the condition is the same for AP (as recorded in cache) and TR. >> >> To be clear about priorities here: I don't think there is a significant bug >> here. I would support separate config-hardening PRs after this PR. I predict >> we are not going to get all the config checks shaken out in one go. >> >> But, a check of extrs-length will catch bugs (or a few at different phases) >> will make a broad fence against config alignment bugs on the addrs array. So >> I recommend that for this PR. > >> So we already have this problem in the current code base. > > I am wrong here. It is not a problem because the flag > `ValueTypeReturnedAsFields` is already being recorded in the AOTCodeCache > config. The PR has several conditional `ADD_EXTERNAL_ADDRESS` guarded by flags. Those flags are recorded in Config and checked before we access this table. But I like @rose00 idea of recording _extrs_length and other AOT address table length in config fro fast check. It will catch case when guarding flag is not recorded in Config. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30778#discussion_r3993634270
