On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak <duke at 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