On Mon, 3 Jun 2024 18:00:35 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.
>>
>> This addresses issue
>
On Mon, 3 Jun 2024 18:00:35 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.
>>
>> This addresses issue
>
On Mon, 3 Jun 2024 18:00:35 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.
>>
>> This addresses issue
>
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 contains six additional
>> comm
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 contains six additional
>> comm
On Mon, 3 Jun 2024 18:00:35 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.
>>
>> This addresses issue
>
On Mon, 3 Jun 2024 18:00:35 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.
>>
>> This addresses issue
>
On Wed, 5 Jun 2024 13:45:46 GMT, Per Minborg wrote:
>> As a note, If we would have access to the contemplated `StableValue` and
>> `hash` was declared even as an _instance variable_ `StableValue` in
>> a regular class, then it would be trusted and would be eligible for constant
>> folding due
On Thu, 6 Jun 2024 06:41:48 GMT, ExE Boss 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 contains six additional
>> commits since
On Mon, 3 Jun 2024 18:00:35 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.
>>
>> This addresses issue
>
On Wed, 5 Jun 2024 13:41:10 GMT, Per Minborg wrote:
>> In order to be eligible for constant folding, the benchmark must declare the
>> `Method hashCodeMethod;` as `static final`.
>>
>> It is hard for me to understand why a `@Stable` annotation should have a
>> detrimental performance impact on
On Wed, 5 Jun 2024 13:37:15 GMT, Per Minborg wrote:
>> Interesting, don't know about hotspot internals so I can't diagnose the
>> exact cause of this regression.
>
> In order to be eligible for constant folding, the benchmark must declare the
> `Method hashCodeMethod;` as `static final`.
>
> I
On Wed, 29 May 2024 15:20:15 GMT, Chen Liang wrote:
>> This was something that I tried and I observed a performance regression on
>> the ARM platform that I was testing. From my understanding, `@Stable` tells
>> the compiler to trust the contents of this field which is only given when
>> the f
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.
>
> This addresses issue
> [JD
> 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).
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.
>
> This addresses issue
> [JD
On Wed, 29 May 2024 15:03:15 GMT, Sean Gwizdak wrote:
>> 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 `@St
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:
19 matches
Mail list logo
