On Tue, 15 Oct 2024 11:07:32 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Tue, 15 Oct 2024 11:07:32 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Tue, 15 Oct 2024 09:24:30 GMT, Roberto Castañeda Lozano
wrote:
> I will run some internal CI testing and report back in one or two days.
The test results look good. I tested the changes (up to commit 9f7ad7ab) on top
of jdk-24+19 running tier1-tier5 on all Oracle-supported platforms.
-
On Tue, 15 Oct 2024 10:02:15 GMT, Yudi Zheng wrote:
>> Aleksey Shipilev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 18 commits:
>>
>> - Simplify: just do keep alive checks
>> - Merge branch 'master' into JDK-8329597-intrinsi
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
On Tue, 15 Oct 2024 09:18:05 GMT, Aleksey Shipilev wrote:
> Thanks for review, folks. I am re-running testing locally here. Would
> appreciate if you can give this patch a spin through your CIs as well.
I will run some internal CI testing and report back in one or two days.
-
PR C
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
On Mon, 7 Oct 2024 08:15:21 GMT, Erik Österlund wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More precise bit-unmasks
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 342:
>
>> 340: }
>> 341: if (
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Sun, 6 Oct 2024 14:43:09 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
On Sun, 6 Oct 2024 14:43:09 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
>
On Thu, 3 Oct 2024 16:54:40 GMT, Aleksey Shipilev wrote:
>> test/micro/org/openjdk/bench/java/lang/ref/ReferenceClear.java line 2:
>>
>>> 1: //
>>> 2: // * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
>>
>> Drive-by comment: The `// *` format looks weird.
>
> Actually, this
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Wed, 2 Oct 2024 10:47:09 GMT, Tobias Hartmann wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also dispatch to slow-path on other arches
>
> test/micro/org/openjdk/bench/java/lang/ref/ReferenceClear.java lin
On Thu, 3 Oct 2024 12:14:08 GMT, Erik Österlund wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also dispatch to slow-path on other arches
>
> src/hotspot/share/opto/library_call.cpp line 7002:
>
>> 7000: //
On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Mon, 30 Sep 2024 16:32:48 GMT, Aleksey Shipilev wrote:
> > I think we need a new
> > ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing(oop*
> > p) and to make that the selected slow path function when
> > ZBarrierNoKeepalive is set on a StorePNode. Its implementati
On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Mon, 30 Sep 2024 16:59:16 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Mon, 30 Sep 2024 16:45:12 GMT, Aleksey Shipilev wrote:
>> src/java.base/share/classes/java/lang/ref/Reference.java line 420:
>>
>>> 418: /* Implementation of clear(), also used by enqueue(). A simple
>>> 419: * assignment of the referent field won't do for some garbage
>>> 420:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Fri, 27 Sep 2024 23:51:13 GMT, Kim Barrett wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Amend the test case for guaranteing it works under different compilation
>> regimes
>
> src/java.base/share/classes
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Mon, 30 Sep 2024 15:08:53 GMT, Erik Österlund wrote:
> I think we need a new
> ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing(oop*
> p) and to make that the selected slow path function when ZBarrierNoKeepalive
> is set on a StorePNode. Its implementation would c
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Fri, 27 Sep 2024 18:57:51 GMT, Aleksey Shipilev wrote:
> > Is ZGC affected by this? I see only G1 and Shenandoah changes.
>
> Good question.
>
> ZGC expands the GC barriers late. This is why the IR test configuration that
> tests ZGC shows the same result as with other collectors: no additi
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Fri, 27 Sep 2024 17:44:38 GMT, Vladimir Kozlov wrote:
> Is ZGC affected by this? I see only G1 and Shenandoah changes.
Good question.
ZGC expands the GC barriers late. This is why the IR test configuration that
tests ZGC shows the same result as with other collectors: no additional fluff
i
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is not on a performance
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> s
On Fri, 12 Jul 2024 13:19:31 GMT, Aleksey Shipilev wrote:
>>> > The reason we did not do this before is that this is not a strong
>>> > reference store. Strong reference stores with a SATB collector will keep
>>> > the referent alive, which is typically the exact opposite of what a user
>>> >
On Mon, 15 Jul 2024 16:09:39 GMT, Kim Barrett wrote:
> > Aw, nice usability landmine. I thought C2 barrier set would assert on me if
> > it cannot deliver. Apparently not, [...]
>
> Reference.refersTo has similar issues. See refersToImpl and refersTo0 in both
> Reference and PhantomReference.
On Fri, 12 Jul 2024 13:19:31 GMT, Aleksey Shipilev wrote:
> > The runtime use of the Access API knows how to resolve an unknown oop ref
> > strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength.
> > However, we do not have support for that in the C2 backend. In fact, it
> > doe
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> sensitive path. However, it shows up prominently on simple be
On Fri, 12 Jul 2024 11:57:56 GMT, Erik Österlund wrote:
> The runtime use of the Access API knows how to resolve an unknown oop ref
> strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength.
> However, we do not have support for that in the C2 backend. In fact, it does
> not unde
On Fri, 12 Jul 2024 10:22:42 GMT, Aleksey Shipilev wrote:
> > The reason we did not do this before is that this is not a strong reference
> > store. Strong reference stores with a SATB collector will keep the referent
> > alive, which is typically the exact opposite of what a user wants when th
On Fri, 12 Jul 2024 10:16:13 GMT, Erik Österlund wrote:
> The reason we did not do this before is that this is not a strong reference
> store. Strong reference stores with a SATB collector will keep the referent
> alive, which is typically the exact opposite of what a user wants when they
> cl
On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> s
On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a performance
> s
[JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
method for `Reference.clear`. The original patch skipped intrinsification of
this method, because we thought `Reference.clear` is not on a performance
sensitive path. However, it shows up prominently on simple benchmarks
49 matches
Mail list logo
