RFR 8199435 : Unsafe publication of java.util.Properties.map
David Holmes
david.holmes at oracle.com
Tue Jun 19 05:19:24 UTC 2018
On 19/06/2018 3:08 PM, Martin Buchholz wrote:
> 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.
Thanks for clarifying.
I'm unsure why we're trying to make this particular class
unsafe-publication-proof, but I guess it's generally a good thing.
David
>
> On Mon, Jun 18, 2018 at 9:01 PM, David Holmes <david.holmes at oracle.com
> <mailto: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