RFR: 8331725: ubsan: pc may not always be the entry point for a VtableStub
Vladimir Kozlov
kvn at openjdk.org
Tue Jul 2 19:43:19 UTC 2024
On Tue, 2 Jul 2024 19:11:07 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:
>> src/hotspot/share/code/vtableStubs.cpp line 294:
>>
>>> 292: // to generate the hash that would have been used if it was. The lookup in the
>>> 293: // _table will only succeed if there is a VtableStub with an entry point at
>>> 294: // the pc.
>>
>> This is dangerous if it is not pointing to entry. How that can happened?
>
> We only get a `VtableStub` after the call has become megamorphic. Before that it may point to the "resolver" (clean) or directly at a method entry point (monomorphic).
>
> The way we check if this is megamorphic is to check if the destination is a VtableStub. We could do a linear scan through all the buckets (like `VtableStubs::contains()` does), but instead we do a hash lookup. But how do we get the hash? we need the `VtableStub` to generate the hash. So we assume that the destination is actually a `VtableStub`, generate the hash as if it was, and do a lookup in the hash table to see if any `VtableStub`'s entry point matches our call destination. In that case we are already megamorphic and nothing needs to be fixed.
>
> So it is by design.
>
> @fisk is probably the goto guy if you want a more detailed description of how our `CompiledIC` works.
Thank you for explanation. Now I see that you are more careful loading data (in case it is not aligned). And added checks for nullptr.
And we don't need to worry about false positive since we compare `pc` will entry points here. So you don't need `VtableStubs::contains()` check.
Good.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19968#discussion_r1663069434
More information about the hotspot-compiler-dev
mailing list