RFR: 8180450: secondary_super_cache does not scale well [v14]

[Dean Long]

On Sat, 13 Apr 2024 00:50:27 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> 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());

OK, I can see now that they both compute the same thing because the "home" bit must be 1.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18309#discussion_r1563889570