RFR: 8332249: Micro-optimize Method.hashCode [v2]

[ExE Boss]

On Mon, 3 Jun 2024 18:00:35 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
>
> 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