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

[Chen Liang]

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

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