On Fri, 8 Jan 2021 12:23:36 GMT, Attila Szegedi <att...@openjdk.org> wrote:

> IIUC, your changes mostly all flow from the decision to declare the fields as 
> non-volatile; if they were still declared as volatile then it'd be impossible 
> to observe null in them, I think (correct me if I'm wrong; it seems like you 
> thought through this quite thoroughly) as then I don't see how could a 
> volatile read happen before the initial volatile writes as the writes are 
> part of the ClassValues constructor invocation and the reference to the 
> ClassValues object is unavailable externally before the constructor 
> completes. In any case, your approach definitely avoids any of these concerns 
> so I'm inclined to go with it.

It depends entirely on the guarantees of ClassValue and not on whether the 
fields are volatile or not. If ClassValue publishes the BiClassValues object 
via data race then even if the fields in BiClassValues are volatile and 
initialized in constructor, the publishing write in ClassValue could get 
reordered past the volatile writes of the fields, so you could observe the 
fields uninitialized.
I can't find in the spec of ClassValue any guarantees of ordering, but I guess 
the implementation does guarantee safe publication. So if you want to rely on 
ClassValue guaranteeing safe publication, you can pre-initialized the fields in 
constructor and code can assume they are never null even if they are not 
volatile.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1918

Reply via email to