[10] RFR: 8184603: Create ObjectStreamField signature lazily when possible

[Chris Hegarty]

> On 14 Jul 2017, at 15:12, Claes Redestad <claes.redestad at 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.