6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization
David.Holmes at oracle.com
Mon Nov 22 22:30:40 UTC 2010
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
>>> field write?
>> I've also been concerned about performance. As I understand it, but
>> maybe I have
>> it wrong, is that the JLS  doesn't allow this when changing final
>> 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.
More information about the core-libs-dev