Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8044616

Clients of Unsafe.compareAndSwapLong need to beware of using direct stores to the same field

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P4
    • Resolution: Duplicate
    • Affects Version/s: 8, 9
    • Fix Version/s: 9
    • Component/s: core-libs
    • Labels:

      Backports

        Description

        sun.misc.Unsafe provides a set of API's for atomic updates to fields including Java long fields. Not all platforms support the atomic compare-and-set for 64-bit values in which case Unsafe will fallback to a locking scheme. The locking scheme can not enforce atomicity with respect to direct stores to the field from Java code, so clients of this API should avoid such direct stores.

        I did an audit of j.u.c to see which classes use Unsafe.compareAndSwapLong and whether they allow direct setting of the field that is cas'd. The following classes (and any apps that use them) are potentially broken because they allow that:

        - AtomicLong
        - AbstractLongQueuedSynchronizer
        - StampedLock

        The set-style operations and any internal direct sets (eg in StampedLock) would need to be rewritten to use Unsafe.putLongVolatile. Any use of putLongVolatile should be factored and guarded by "supports_cx8" so that the JIT can inline the direct volatile store when it is available.

        NOTE this only affects platforms which do not support 64-bit CAS. None of the mainline OpenJDK platforms are affected by this.

        Also note that other j.u.c classes already take this into account, either ensuring Unsafe.xxx updates only or even using Java-level locking in the case of AtomicLongFieldUpdater.

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                Unassigned Unassigned
                Reporter:
                dholmes David Holmes
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved: