RFR: 8338546: Speed up ConstantPoolBuilder::classEntry(ClassDesc) [v3]

[Claes Redestad]

On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Speed up `ConstantPoolBuilder::classEntry(ClassDesc)` by going through `ClassDesc` comparison and reusing descriptor hash to calculate internal name hash if possible. No suitable device to run benchmarks so need to find something to run the new benchmark to ensure things work as intended.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix build
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Buggy 2nd attempt - crashes hotspot
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - More conflicts
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/classentry-speedup
>  - Another bug in benchmark
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/996790c7...6117a5bd

Looking into this I see that `internalNameHash` (and `pow31`) shows up in startup profiles - making the change more or less neutral on bytecode counts. `pow31` seem to be a contributor to the regression in the `internalNameLookup` micro.

Since most common internal names are relatively small (`java/lang/String` etc) I wonder if a small memoized lookup table is profitable? Ran with a naive one containing pow31(0 - 63) and see a 1.08x speedup in `internalNameLookup`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20667#issuecomment-2355834197