6647361: use Unsafe.put*Volatile methods to set final fields during default deserialization
David.Holmes at oracle.com
Tue Dec 14 15:29:00 PST 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  doesn't allow this when changing final
>> 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