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

Claes Redestad claes.redestad at oracle.com
Fri Jul 14 15:24:02 UTC 2017

On 2017-07-14 16:22, Aleksey Shipilev wrote:
> 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.

Maybe I'm not being imaginative enough, but I've not seen any heap
dumps where #OSFs are anywhere near problematic quantities.

For 64-bit VMs with compressed oops then it appears the change is
footprint neutral due to padding (according to JOL estimates), and if we
had to really optimize for applications with a huge number of OSFs then
it appears there are other things we could examine to do as well..

> 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.

Interesting, but I think we can keep that solution in mind for if and when
there's a real need to trim down footprint.


More information about the core-libs-dev mailing list