On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak <d...@openjdk.org> wrote:
>> Improve the speed of Method.hashCode by caching the hashcode on first use. >> I've seen an application where Method.hashCode is a hot path, and this is a >> fairly simple speedup. The memory overhead is low. >> >> This addresses issue >> [JDK-8332249](https://bugs.openjdk.org/browse/JDK-8332249). >> >> Before: >> >> Benchmark Mode Cnt Score Error Units >> # Intel Skylake >> MethodHashCode.benchmarkHashCode avgt 5 1.843 ± 0.149 ns/op >> # Arm Neoverse N1 >> MethodHashCode.benchmarkHashCode avgt 5 2.363 ± 0.091 ns/op >> >> >> >> After: >> >> >> Benchmark Mode Cnt Score Error Units >> # Intel Skylake >> MethodHashCode.benchmarkHashCode avgt 5 1.121 ± 1.189 ns/op >> # Arm Neoverse N1 >> MethodHashCode.benchmarkHashCode avgt 5 1.001 ± 0.001 ns/op > > Sean Gwizdak has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains six additional > commits since the last revision: > > - Remove trailing whitespace. > - Move hashCode benchmark into the newly created MethodBenchmark file > - Merge branch 'master' into method-hashcode-JDK-8332249 > - Remove changes to JavaDoc per guidance. > - Fix whitespace issues pointed by the bot > - Micro-optimize Method.hashCode Now in the review of #23972, we noted that `String::hashCode` couldn't constant fold as its hash and hashIsZero fields are missing `@Stable`. If string hash code and xor (see #23089) can constant fold, would this still be necessary? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2794771005
