Hi Chris,
Would it be possible to track the "needsFence" flag throughout the whole
object graph deserialization, and only issue one single fence for the
whole object graph? This would minimize the number of fences issued.
Peter
On 02/19/2015 05:32 PM, Chris Hegarty wrote:
Additional note ( forgotten from original mail):
The fence is needed for "final-freeze" is a one-off barrier at the end of
deserialization, similar that of constructors . Under normal circumstances the object being
deserialized is not visible until deserialization completes, so you don't need a "freeze"
until deserialization completes.
-Chris.
On 19 Feb 2015, at 16:25, Chris Hegarty <chris.hega...@oracle.com> wrote:
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
