RFR(S): 8206003: SafepointSynchronize with TLH: StoreStore barriers should be moved out of the loop
Erik Österlund
erik.osterlund at oracle.com
Thu Jun 28 15:28:06 UTC 2018
Hi Martin,
This did catch my eye too. This looks good to me. But could you consider
having _release in the name of the setter that uses release, and no
postfix for the one using a plain store, instead of giving that one a
_no_release postfix. I don't need another webrev.
Thanks,
/Erik
On 2018-06-28 16:52, Doerr, Martin wrote:
> Hi,
>
> I have recently come across a bad placement of memory barriers in SafepointSynchronize::begin() and end() which were changed for JEP 312: Thread-Local Handshakes. They iterate over all JavaThreads and call SafepointMechanism::arm_local_poll or disarm_local_poll. Unfortunately, the release barriers are inside the latter functions.
>
> Assume we have several 1000 JavaThreads. This means the code executes several 1000 release barriers on weak memory model platforms (PPC64 and ARM/aarch64). Only one is needed.
>
> A goal of JEP 312 was to minimize latency of safepoints which gets defeated by this issue to some extend on these platforms.
>
> It could be fixed by this proposal:
> http://cr.openjdk.java.net/~mdoerr/8206003_tlh_sync_membars/webrev.00/
>
> Please review.
>
> Best regards,
> Martin
>
More information about the hotspot-runtime-dev
mailing list