On Tue, 28 May 2024 17:25:34 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 Also, have you considered micro-optimize Constructor.hashCode too? Given its similar status to Method. src/java.base/share/classes/java/lang/reflect/Method.java line 99: > 97: private Method root; > 98: // Hash code of this object > 99: private int hash; We can declare this field `@Stable`, like the `methodAccessor`. src/java.base/share/classes/java/lang/reflect/Method.java line 388: > 386: int hc = hash; > 387: > 388: if (hc == 0) { Should we add an extra field `hashIsZero` like in `String` to avoid repeated computation if the hash is 0? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2137679451 PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1618110657 PR Review Comment: https://git.openjdk.org/jdk/pull/19433#discussion_r1618110354
