RFR: 8184603: Create ObjectStreamField signature lazily when possible
shade at redhat.com
Fri Jul 14 14:22:45 UTC 2017
On 07/14/2017 04:12 PM, Claes Redestad wrote:
>> 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:
I think this is fine from concurrency standpoint. Not sure how safe it is to
increase OSF footprint, that's your call! I also think the largest improvement
would be from avoiding the intern() call in constructor -- I frequently observed
it on the OSF hot paths. I would trade excess field for avoiding String.intern()
As Doug Lea mentions offlist, another alternative would be to do fullFence at
the end of OSF private constructor. But, this is low-level, and relies on
hardware that handles data-dependent loads fine on reader side (which is true
for all arches OpenJDK targets, I think). If there is no pressing need to keep
OSF footprint minimal, I'd avoid doing explicit fences.
More information about the core-libs-dev