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