RFR [9]: default Serialization should issue a fence after reconstructing an Object with final fields

[Chris Hegarty]

A number of years ago there was a proposal to use Unsafe.put*Volatile methods to set final fields during default deserialisation [1][2], but it never made it due to concerns about the potential negative impact of the additional fences. Now we have a, private, fences API in the platform, I think it is time to revisit this.

Webrev:
  http://cr.openjdk.java.net/~chegar/deserialFence/webrev.00/webrev/  

Note: 
  - Section 17.5.3 in the JLS [3], “Freezes of a final field occur both
    at the end of the constructor in which the final field is set, and
    immediately after each modification of a final field via reflection
    or other special mechanism.” I believe this is a consequence of
    the way in which setting of final fields is supported in the public
    API, Field.setAccessible(), ( as defined by JSR 133 ) and should
    not restrict an implementation from using a more performant
    means, as is suggested here.  The statement in the JLS should
    be revisited.
 
 - Default Serialization already has a dependency on Unsafe, and
   I don’t see this additional dependency as making that any worse. 

 - Open question, should we include volatile fields as well as final?

 - The changes in the webrev will issue a fence even if custom
   deserialization is performed. I think this is ok, as it will be more
   consuming to try to determine if a custom readObject set a final
   through reflection, or not.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-6647361
[2] http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-November/005292.html
     http://mail.openjdk.java.net/pipermail/core-libs-dev/2010-December/005456.html
[3] http://docs.oracle.com/javase/specs/jls/se8/html/jls-17.html#jls-17.5.3