RFR 8201799: Build failures after JDK-8195099 (Concurrent safe-memory-reclamation mechanism) (original) (raw)

Erik Österlund erik.osterlund at oracle.com
Wed Apr 18 12:47:15 UTC 2018

Hi,

Please also note that the Atomic::add used in write_synchronize assumes bidirectional fencing (which is the contract provided by Atomic::add). This is however not true for the PPC backend of Atomic::add - it has acq_rel semantics instead. So this mechanism is currently not safe to use on PPC.

From globalCounter.cpp: 61 // Atomic::add must provide fence since we have storeload dependency. 62 volatile uintx gbl_cnt = Atomic::add((uintx)COUNTER_INCREMENT, &_global_counter._counter);

Might want to have a look at the safe use of this mechanism on PPC as a follow-up.

Thanks, /Erik

On 2018-04-18 14:27, David Holmes wrote:

Hi Aleksey,

On 18/04/2018 9:50 PM, Aleksey Shipilev wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8201799

Fix: diff -r bfba4712d4ff src/hotspot/share/utilities/globalCounter.inline.hpp --- a/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18 11:36:48 2018 +0200 +++ b/src/hotspot/share/utilities/globalCounter.inline.hpp Wed Apr 18 13:50:34 2018 +0200 @@ -27,6 +27,7 @@ #include "runtime/orderAccess.inline.hpp" #include "runtime/thread.hpp" The above line can be deleted now. +#include "runtime/thread.inline.hpp" Fix is good. Thanks, David #include "utilities/globalCounter.hpp" inline void GlobalCounter::criticalsectionbegin(Thread *thread) { Testing: failing aarch64 build Thanks, -Aleksey

More information about the hotspot-dev mailing list