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

[Peter Levart]

On 02/20/2015 12:34 PM, Chris Hegarty wrote:
>
>
> Updated Webrev:
> http://cr.openjdk.java.net/~chegar/deserialFence/webrev.01/webrev/
>
> Note, the changes in this webrev are overly defensive in the face of 
> recursive calls to readObject/Unshared. This should be ok, but 
> probably not strictly necessary.
>
> -Chris.
>

Hi Chris,

This looks good now. But I wonder if issuing fences after nested calls 
to readObject() makes much sense. If cycles are present in a subgraph 
deserialized by nested call to readObject(), a field pointing back to an 
object not part of the subgraph stream will point to the object that 
will not be fully initialized yet, so nested calls to readObject() 
should not be expected to return a reference to a fully constructed 
subgraph anyway. Only top-level call is guaranteed to return a fully 
constructed graph.

If you optimize this and only issue one fence for top-level call to 
readObject(), tracking of 'requiresFence' (I would call it 
requiresFreeze to be in line with JMM terminology - the fence is just a 
way to achieve freeze) can also be micro-optimized. You currently do it 
like this:

1900             requiresFence |= slotDesc.hasFinalField();

which is a shortcut for:

requiresFence = requiresFence | slotDesc.hasFinalField();

...which means that the field is overwritten multiple times 
unnecessarily and slotDesc.hasFinalField() is called every time. You can 
write the same logic as:

if (!requiresFence && slotDesc.hasFinalField()) {
     requiresFence = true;
}

There will be at most one write to the field and potentially less calls 
to slotDesc.hasFinalField().


Regards, Peter