RFR (XS): CR 8004330: Add missing Unsafe entry points for addAndGet() family

[David Holmes]

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.

David
-----

>
> 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();
>
> Doug?
>
> -Aleksey.
>