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