RFR: 8184603: Create ObjectStreamField signature lazily when possible
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:
>>> 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()
> 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