RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family
aleksey.shipilev at oracle.com
Wed Jan 9 11:04:57 UTC 2013
On 01/09/2013 02:55 PM, David Holmes wrote:
> Not sure where this is now but FYI you needed two CRs for this: one for
> hotspot and one for the JDK. They have different target versions (hs25
> vs 8) and depending on the path you use to integrate could end up in
> different builds - hence distinct CRs for accurate tracking purposes.
Too late, since these are already committed? I can submit another CR if
we need that.
> I have a concern that the Long versions of these methods may be used
> directly without there being any check for supports_cx8
I actually have the question about this. What is the usual pattern for
using AtomicLong.VM_SUPPORTS_LONG_CAS? AtomicLong seems to use Unsafe
directly without the checks. AtomicLongFieldUpdater does the checks.
Something is fishy about this whole thing.
I think this one tries to explain something, but I fail to grasp the intent:
* Records whether the underlying JVM supports lockless
* compareAndSwap for longs. While the Unsafe.compareAndSwapLong
* method works in either case, some constructions should be
* handled at Java level to avoid locking user-visible locks.
static final boolean VM_SUPPORTS_LONG_CAS = VMSupportsCS8();
More information about the core-libs-dev