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

Reply via email to