On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak 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.
>
>
On Tue, 11 Jun 2024 08:58:34 GMT, Aleksey Shipilev wrote:
>> 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 conta
On Tue, 28 May 2024 17:25:34 GMT, Sean Gwizdak 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.
>
>
.091 ns/op
>
>
>
> After:
>
>
> Benchmark Mode Cnt Score Error Units
> # Intel Skylake
> MethodHashCode.benchmarkHashCode avgt5 1.121 ± 1.189 ns/op
> # Arm Neoverse N1
> MethodHashCode.benchmarkHashCode avgt5 1.001 ± 0.001
On Wed, 29 May 2024 15:20:56 GMT, Chen Liang wrote:
> Also, have you considered micro-optimize Constructor.hashCode too? Given its
> similar status to Method.
Not at this time. This PR is motivated by observing Method.hashCode as a
hotspot in a Spring heavy application when migrating to an ARM
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:
