6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization

[David Holmes]

Doug Lea said the following on 11/23/10 01:49:
> On 11/22/10 10:41, Alan Bateman wrote:
>> Brian Goetz wrote:
>>> Is it possible to coalesce the fences so that we don't incur them on 
>>> every
>>> field write?
>> I've also been concerned about performance. As I understand it, but 
>> maybe I have
>> it wrong, is that the JLS [1] doesn't allow this when changing final 
>> fields
>> after an object is constructed.
>>
> 
> In the case of volatile writes, hotspot already does
> some safe (short-horizon) coalescing at instruction generation
> time. In the case of store fences (i.e., putOrdered), it doesn't,
> but it wouldn't help on most platforms anyway.

I don't think coalescing is going to occur here as the different writes 
will be too far apart unless there is some very aggressive loop unrolling.

Brian: this was intended to be a small patch to close a hole in 
deserialization where we do not strictly comply with the JMM. It should 
have been done years ago but slipped through the cracks. Our expert 
advice (Hi Doug!) at the time was that using a volatile-write ala 
Unsafe.put*Volatile was the way to go here - though perhaps there was a 
misunderstanding between Doug and the original RE.

Alan was going to defer this but I convinced him it was a simple enough 
change to just go and do it. If it is proving to be contentious then 
we'll just let it drop as it is not worth spending significant time on 
this - and my apologies to Alan for wasting his time.

Cheers,
David