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
