> On 14 Jul 2017, at 15:12, Claes Redestad <claes.redes...@oracle.com> wrote: > > On 2017-07-14 15:46, Aleksey Shipilev wrote: >> On 07/14/2017 03:40 PM, Claes Redestad wrote: >>> signature is already made volatile in this patch, deliberately to ensure >>> that >>> for the private constructors we keep correctness: >>> >>> in these private constructors, the signature field is initialized in the >>> constructor (we can assert that it's non-null) to a value that would not >>> match getClassSignature(type), but since the field is volatile it will never >>> be observed as null by a call to getSignature() on an object created with >>> these constructors (unless I'm mistaken, and we *do* need an added >>> synchonization point here). >> Thing is, "volatile" is not as strong as "final" for racy initializations: >> >> https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-volatiles-are-finals >> >> If that is not a concern -- e.g. if private constructor is never used to make >> shared OSFs -- then "volatile" is superfluous. If it is a concern, then >> "volatile" is not enough, and you have to keep "final". > > Gosh!
Indeed! > Seeing how it's possible to lookup ObjectStreamClass and get at > ObjectStreamField's that might have been created from the internal > constructors, I think it *is* a concern. > > Thus the only viable option that allows us to be correct *and* lazy might be > to > add a new field that is lazily initialized only when using the public > constructors: > > http://cr.openjdk.java.net/~redestad/8184603/jdk.02/ This version looks good to me. Can you please add a link to this review thread to the bug ( for future archaeologists ). -Chris.
