[External] : Re: AArch64: loading the thread-local poll value when waking up from native with ldAr in case -XX:+UseSystemMemoryBarrier

[Dmitry Chuyko]

Andrew, Erik, thanks for responding. As the change looks legal, I'll create
an RFE then.

Erik, could you please point to the anchor change since which there is no
race concern: is it Faster safepoints, Async handshakes or something else?

-Dmitry

On Thu, Jul 25, 2024 at 10:22 PM Erik Osterlund <erik.osterlund at oracle.com>
wrote:

> Hi,
>
> A key ingredient of the race I pointed out is no longer around. The
> VMThread used to disarm the Java threads. It’s observing that disarmed
> value that required ldar.
>
> Today, Java threads always disarm themselves. That removes the need for
> ldar entirely, with or without sys_membarrier.
>
> Thanks for directing my attention to this.
>
> /Erik
>
> > On 25 Jul 2024, at 17:45, Andrew Haley <aph-open at littlepinkcloud.com>
> wrote:
> >
> > On 7/25/24 14:43, Dmitry Chuyko wrote:
> >> I wonder if it would be correct to emit the safepoint_poll with
> >> acquire=false in case UseSystemMemoryBarrier is true at least on some
> known
> >> CPUs. Regression tests don't reveal problems, but they don't produce
> eager
> >> safepoint/jni races.
> >
> > Mmm, good point. That sounds reasonable, but I'll defer to others on Cc:
> >
> > --
> > Andrew Haley  (he/him)
> > Java Platform Lead Engineer
> > Red Hat UK Ltd. <
> https://urldefense.com/v3/__https://www.redhat.com__;!!ACWV5N9M2RV99hQ!OzZDdGStquMIZXrytYV3LNK6l1u5Lg5U2nomVggyZwXZMm3JIDrJFxFYv8xDCcttK-yEKVwFTqS-P_J-ntB1LgMoAtHd$
> >
> >
> https://urldefense.com/v3/__https://keybase.io/andrewhaley__;!!ACWV5N9M2RV99hQ!OzZDdGStquMIZXrytYV3LNK6l1u5Lg5U2nomVggyZwXZMm3JIDrJFxFYv8xDCcttK-yEKVwFTqS-P_J-ntB1LriHa8IO$
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-compiler-dev/attachments/20240726/80771dcf/attachment-0001.htm>