RFR: 8184603: Create ObjectStreamField signature lazily when possible
chris.hegarty at oracle.com
Fri Jul 14 15:26:11 UTC 2017
> 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:
>> 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".
> 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:
This version looks good to me.
Can you please add a link to this review thread to the bug ( for future archaeologists ).
More information about the core-libs-dev