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

I don't think we need to worry about the object footprint size. There are a few opportunities available, such as sharing the generic factories from the root object, or removing the unused slot field. And the hashcode cache will be required once we take parameter into account.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19433#issuecomment-2226398217