RFR: 8180450: secondary_super_cache does not scale well [v14]
Vladimir Ivanov
vlivanov at openjdk.org
Sat Apr 13 00:53:43 UTC 2024
On Sat, 13 Apr 2024 00:17:13 GMT, Dean Long <dlong at openjdk.org> wrote:
>> Are you asking about `if (hash > 0) {` check?
>
> No, in the asm code, when bit == SECONDARY_SUPERS_TABLE_MASK (MSB), we do popcnt on the full bitmap.
That's one of micro-optimizations performed in assembly code.
What's actually being computed is `home_index + 1`, but `r_array_base` is one word (-1) off, so first probe lands at `secondary_supers[home_index]`. It saves an instruction, because you don't need to increment `r_array_index`. `r_array_base` adjustment [2] effectively increments the index as well.
There are some comments on assembly side to make it clear [1]. I was initially confused by all those small tweaks happening in assembly as well, so added more comments. Maybe we need more.
`Klass::compute_home_slot()` is a canonical implementation to compute home slot. Comments there about what happens on assembly side would look to me irrelevant.
[1]
// NB! r_array_index is off by 1. It is compensated by keeping r_array_base off by 1 word.
[2]
// And adjust the array base to point to the data.
// NB! Effectively increments current slot index by 1.
assert(Array<Klass*>::base_offset_in_bytes() == wordSize, "");
add(r_array_base, r_array_base, Array<Klass*>::base_offset_in_bytes());
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/18309#discussion_r1563441962
More information about the hotspot-dev
mailing list