RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family
david.holmes at oracle.com
Thu Jan 10 03:24:20 UTC 2013
On 9/01/2013 9:04 PM, Aleksey Shipilev wrote:
> Thanks, David.
> 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'll fix it up - it is easier to do than explain. :) As it is, the fact
these both went in through hotspot repo at least means they appeared in
jdk8/jdk8 at the same time.
>> 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 had forgotten at what levels this operates too. As I think is now
clear(er) there is a Java level check (and fallback to locks) for the
AtomicLongFieldUpdater based on supports_cx8. Then there are further
checks of supports_cx8 in unsafe.cpp. Critically in
Unsafe_CompareAndSwapLong. (Still needed on some platforms)
Also note that Unsafe_get/setLongVolatile are also gated, unnecessarily,
on supports_cx8. We have to have atomic 64-bit read/write for direct
Java volatile accesses anyway. There's also an open CR to define
supports_atomic_long_ops so that supports_cx8 is only used for the CAS,
where it is needed, rather than simple read/write ops.
> 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