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

[Aleksey Shipilev]

On 07/14/2017 03:40 PM, Claes Redestad wrote:
> signature is already made volatile in this patch, deliberately to ensure that
> for the private constructors we keep correctness:
> 
> in these private constructors, the signature field is initialized in the
> constructor (we can assert that it's non-null) to a value that would not
> match getClassSignature(type), but since the field is volatile it will never
> be observed as null by a call to getSignature() on an object created with
> these constructors (unless I'm mistaken, and we *do* need an added
> synchonization point here).

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

The hair-pull scenario under the race would be like this: OSF gets constructed
with Ljava/lol/ConcurrencyIsHard, published, another thread calls getSignature()
on it, eads null from $signature, regenerates it from Object $type, returns
Ljava/lang/Object as signature. Something fails not expecting j/l/Object in
signature, you go debug it, and see getSignature() returns
Ljava/lol/ConcurrencyIsHard, as if nothing had happened.

Thanks,
-Aleksey