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

Aleksey Shipilev aleksey.shipilev at oracle.com
Wed Jan 9 03:04:57 PST 2013


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 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.



More information about the hotspot-compiler-dev mailing list