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

David Holmes 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 supportscx8 I actually have the question about this. What is the usual pattern for using AtomicLong.VMSUPPORTSLONGCAS? 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 VMSUPPORTSLONGCAS = VMSupportsCS8(); Doug? -Aleksey.

More information about the core-libs-dev mailing list