RFR 8199435 : Unsafe publication of java.util.Properties.map

Martin Buchholz martinrb at google.com
Tue Jun 19 05:08:33 UTC 2018


Latest version looks like this:

     public Object clone() {
         try {
             @SuppressWarnings("unchecked")
             CopyOnWriteArrayList<E> clone =
                 (CopyOnWriteArrayList<E>) super.clone();
             clone.resetLock();
+            // Unlike in readObject, here we cannot visibility-piggyback
on the
+            // volatile write in setArray().
+            VarHandle.releaseFence();
             return clone;
         } catch (CloneNotSupportedException e) {
             // this shouldn't happen, since we are Cloneable
             throw new InternalError();
         }
     }

The store we worry about is a hypothetical subsequent racy publication of
the new object, so we put the release fence at the end of the
pseudo-constructor.


On Mon, Jun 18, 2018 at 9:01 PM, David Holmes <david.holmes at oracle.com>
wrote:

> On 19/06/2018 6:01 AM, Doug Lea wrote:
>
> Hang on! A releasing store does the "release" before the store not after
> it. The whole point being if you see the result of the store then you are
> guaranteed to see all previous stores. The above can reorder the lockField
> store with whatever stores come before it.
>
> David
> -----
>
>


More information about the core-libs-dev mailing list