RFR(S): 8206003: SafepointSynchronize with TLH: StoreStore barriers should be moved out of the loop

Robbin Ehn robbin.ehn at oracle.com
Thu Jun 28 19:08:41 UTC 2018

Hi Martin,

This was on my to do list, thanks for picking it up!

On 2018-06-28 17:28, Erik Österlund wrote:
> 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.

This would be good.

Looks good thanks for fixing!


> 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