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

David Holmes David.Holmes at oracle.com
Tue Dec 14 23:29:00 UTC 2010

Clemens Eisserer said the following on 12/15/10 06:37:
>> 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.
> But don't we have the same overhead at object construction time?
> I remember having read somewhere the JVM issues fence/barrier
> instructions after an object has been created?

The barrier needed for "final-freeze" is a one-off barrier at the end of 
construction. Brian was asking if we could use a one-off barrier at the 
end of deserialization. Alan points out that technically that's not 
allowed as the JLS states there must be a freeze after each modification 
via "reflection or other special mechanisms". But I wonder if the JLS 
might not be being flexible enough in this case. If the object being 
deserialized is not visible until deserialization completes then you 
don't need a "freeze" until deserialization completes.

Anyway this "simple fix" is now somewhat contentious and not-simple and 
therefore not likely to proceed in the near future.


More information about the core-libs-dev mailing list