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 src/java.base/share/classes/java/lang/reflect/Method.java line 392: > 390: .hashCode(); > 391: } > 392: return hc; The `hash` field should probably somehow be shared with the `Method.root` instance, so that it doesn’t need to be recomputed when different code gets a `Method` reference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1628860179
