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

Claes Redestad redestad at openjdk.org
Tue Sep 17 15:08:10 UTC 2024


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

Improving `pow31` should help a little each distinct `classEntry(ClassDesc)`, no? 

Perhaps would be good with a micro variant doing what `identicalLookup` does but on a fresh `ConstantPoolBuilder.of()` each time. There'll be a lot of unrelated noise in such a variant, and we're hiding costs of `String.hashCode`, but it'll tell us something about the first-time insertion cost.

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

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


More information about the core-libs-dev mailing list