RFR (S): 8165859: gcTaskThread is missing volatile qualifier and barriers for _time_stamps
erik.osterlund at oracle.com
Tue Sep 20 08:49:14 UTC 2016
I believe Kim is referring precisely to the release in the fence before
the compare-and-exchange in that comment you refer to, rather than the
membar Store* after the fence.
I would prefer to have explicit memory ordering between the linked
producer and consumer pair, as Kim suggests. This is how the JMM
implements sequential consistency - cooperatively with
release_store_fence and load_acquire pairs on the same data. It might
very well be that specific architectures might work fine without the
acquire for the consumer as the producer implementation itself is strong
enough to guarantee sequential consistency, but I don't see why it would
be wise to bet on that if we don't have to, and it does not cost us
On 2016-09-19 21:36, Carsten Varming wrote:
> Dear Kim,
> Reading a volatile field updated by cmpxchg does not need an acquire
> BTW. The specification in atomic.hpp says cmpxchg provides: "<fence>
> compare-and-exchange <membar StoreLoad|StoreStore>". The release is
> part of the fence. Are you suggesting that there is a release after
> the exchange?
> On Mon, Sep 19, 2016 at 3:18 PM, Kim Barrett <kim.barrett at oracle.com
> <mailto:kim.barrett at oracle.com>> wrote:
> > On Sep 19, 2016, at 2:26 PM, Carsten Varming <varming at gmail.com
> <mailto:varming at gmail.com>> wrote:
> > Dear Erik,
> > According to orderAccess.hpp an acquire is supposed to be paired
> with a release. It doesn't look like there is any synchronization
> on the data written to the time stamp array, so what exactly is
> going on?
> > Carsten
> _time_stamps gets written with a cmpxchg_ptr (line 63 of
> gcTaskThread.cpp), which includes release semantics for the write;
> see atomic.hpp.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev