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

Aleksey Shipilev 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:
>> 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!
> 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/

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()
any day.

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 mailing list