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