RFR: jsr166 jdk10 integration wave 2

[Peter Levart]

Hi Martin,

Just a purely theoretical question...

On 08/08/2017 02:06 AM, Martin Buchholz wrote:
> Need to fix
>
>
>     1. JDK-8185830 <https://bugs.openjdk.java.net/browse/JDK-8185830>
>
> ConcurrentSkipListSet.clone() fails with UnsupportedOperationException
> http://cr.openjdk.java.net/~martin/webrevs/openjdk10/jsr166-integration/
>
> (It would be nice if we could submit a jdk9 backport now instead of waiting)

Regarding ConcurrentSkipListSet.clone()... The 'm' field is final 
presumably to allow "safe" publication of ConcurrentSkipListSet objects 
to other threads via data races.

clone() O.T.O.H. uses Field.setAccessible(true) on a final field, 
followed with Field.set(), which amounts to Unsafe.putObjectVolatile(). 
Is this equivalent to volatile write? Is it possible for a normal write 
of a reference to a cloned ConcurrentSkipListSet (i.e. publication via 
data race) to bubble up before the volatile write of 'm' field inside 
the clone and consequently allow an observer of a reference to the clone 
to modify the backing map of the original ConcurrentSkipListSet?

Regards, Peter