On Wed, 16 Sep 2026 16:45:22 GMT, John R Rose <[email protected]> wrote:
>> Done. I also cleared _extrs_addr array on allocation. Not all slots are
>> filled.
>
> Thinking more about a future failure mode – there may be future edits to
> stubs that don’t synch with config tests. If a zero ever comes from a query
> to the stubs table, will an assertion catch it before it is used in code?
>
> Partial answer, looking at `AOTCodeAddressTable::address_for_id`: The zero
> pops out with no assert or fatal error. Other error conditions are caught
> with `fatal`. It is not clear whether zero is allowed in this API, although
> `(address)-1` is a sentinel value checked for by callers, so it seems
> unlikely that a second sentinel can be there.
>
> Suggest either a debug-only assert that checks for zero (followed by
> returning the real sentinel) or better a straight `fatal` call.
>
>
> @@ -2395,15 +2395,21 @@ address AOTCodeAddressTable::address_for_id(int idx) {
> return nullptr;
> }
> uint id = (uint)idx;
> + address result = nullptr;
> // no need to compare unsigned id against 0
> if (id < _extrs_length) {
> - return _extrs_addr[id - _extrs_base];
> + result = _extrs_addr[id - _extrs_base];
> }
> + else //reflow me
> if (id >= _stubs_base && id < _c_str_base) {
> - return _stubs_addr[id - _stubs_base];
> + result = _stubs_addr[id - _stubs_base];
> }
> + else //reflow me
> if (id >= _c_str_base && id < (uint)(_c_str_base + _C_strings_count)) {
> - return address_for_C_string(id - _c_str_base);
> + result = address_for_C_string(id - _c_str_base);
> }
> + if (result != nullptr) {
> + return result; // could be sentinel (address)-1 in some cases
> + }
> fatal("Incorrect id %d for AOT Code Cache addresses table", id);
> return nullptr;
Suggested changes are reasonable. I will do that.
Note, we support independent disable stubs, adapters, code caching. We have
`aotCode/AOTCodeFlags.java` test which tests all combinations of
`AOTAdapterCaching, AOTStubCaching and AOTCodeCaching` flags in training vs
production runs. Yes, 64 combinations.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30778#discussion_r4029100108
