RFR 8199435 : Unsafe publication of java.util.Properties.map

David Holmes david.holmes at oracle.com
Mon Jun 18 03:45:19 UTC 2018


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


More information about the core-libs-dev mailing list