Hi Brent,

On 16/06/2018 1:44 AM, Brent Christian wrote:
Hi,

In JDK 9, 8029891[1] refactored java.util.Properties to store its values in an internal ConcurrentHashMap, and removed synchronization from "reader" methods in order to avoid potential hangs/deadlocks during classloading.

Claes has noticed that there is the possibility of the new 'map' field being observed with its default value (null), before being set.

After looking at the JSR 133 FAQ[2], I agree with Claes that we should make 'map' a field final.

Making it "final" to fix unsafe publication only works with actual publication after construction. You're making it "final" but then not setting it at construction time and instead using UNSAFE.putVolatile to get around the fact that it is final! The "final" serves no purpose in that regard. Further a putVolatile without corresponding getVolatile does not achieve safe publication under the JMM.

I think making the actual field(s) volatile is the only JMM compliant way to correctly address this.

David
-----

Please review my change to do this:

Webrev:
http://cr.openjdk.java.net/~bchristi/8199435/webrev/
Issue:
https://bugs.openjdk.java.net/browse/JDK-8199435

Thanks,
-Brent

1. https://bugs.openjdk.java.net/browse/JDK-8029891
2. https://www.cs.umd.edu/~pugh/java/memoryModel/jsr-133-faq.html#finalRight

Reply via email to