On Tue, 17 Sep 2024 02:04:51 GMT, Chen Liang <li...@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
