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

[Claes Redestad]

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.

/Claes