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

[Chris Hegarty]

On 09/01/2013 11:04, 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.

Since the changes to vmsymbols.hpp are already in, then I suggest we 
simply create a new bug to track the Unsafe.java changes into jdk8.

I can sponsor this change to you Aleksey.

-Chris

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