RFR(S): 8229422: Taskqueue: Outdated selection of weak memory model platforms

David Holmes david.holmes at oracle.com
Fri Aug 16 22:39:28 UTC 2019

On 17/08/2019 12:22 am, Doerr, Martin wrote:
> Hi David,
>> If you need to put a comment saying "we don't have this property" then
>> to me that means there should be something more than a comment to
>> indicate that.
> I need to think a little more about that. Especially after feedback from Derek.
> Maybe I should replace support_IRIW_for_not_multiple_copy_atomic_cpu by a macro in platform code as well.
> I can also make further changes if desired by arm/aarch64 folks.
>> Okay I refreshed my memory. Yes the fence() does relate to
>> non-multi-copy-atomic systems. But we were only using the
>> CPU_NOT_MULTIPLE_COPY_ATOMIC define to control the setting of
>> support_IRIW_for_not_multiple_copy_atomic_cpu. I don't know why we
>> added
>> the cpu-based ifdefs around the fence() rather than using
>> CPU_NOT_MULTIPLE_COPY_ATOMIC in the first place, but it use for that
>> does seem valid.
> Thanks for looking into that again and for confirming.
> Note that the cpu-based ifdefs for the task queue were discussed in 2013 while the IRIW support was introduced by JDK-8029101 in 2014.
> Nobody has cleaned these things up, yet.

Ah I see - makes more sense now. I wonder if there are other ifdef'd 
memory barriers that might need to be cleaned up ...


> Best regards,
> Martin

More information about the hotspot-gc-dev mailing list