RFR: 8331341: secondary_super_cache does not scale well: C1 and interpreter [v23]

[Dean Long]

On Wed, 9 Oct 2024 23:10:57 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:
>> 
>>  - Merge from 4ff72dc57e65e99b129f0ba28196994edf402018
>>  - Fix s390
>>  - Use post-incrememnt RegSet operator.
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Fix merge
>>  - Merge branch 'clean' into JDK-8331658-work
>>  - Merge from JDK head.
>>  - Cleanup
>>  - Fix shared code
>>  - Fix shared code
>>  - ... and 51 more: https://git.openjdk.org/jdk/compare/4ff72dc5...a7612674
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 1820:
> 
>> 1818:   // mov(r_array_index, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
>> 1819:   // sub(slot, r_array_index, slot);
>> 1820:   eor(slot, slot, (u1)(Klass::SECONDARY_SUPERS_TABLE_SIZE - 1));
> 
> Should we assert SECONDARY_SUPERS_TABLE_SIZE is a power of 2 here?

If we used temp2 to store (Klass::SECONDARY_SUPERS_TABLE_SIZE - 1 - slot), then I think we could avoid the XOR at line 1863.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19989#discussion_r1794399552