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

[Chris Hegarty]

On 24 Feb 2015, at 15:07, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> On 24 Feb 2015, at 11:45, Peter Levart <peter.levart at gmail.com> wrote:
> ...
>> That's better now. Let me just try to measure the overhead of tracking on simple objects to see if it actually pays off or is contra-productive in any case.
> 
> Thanks. I’ll see if I can get some measurements also.

I created a very simple benchmark [1] that deserializes a single object with no fields. Run with JDK 9 b52, on a reasonably fast machine ( results [2] ), we can see the time taken to reconstitute the simple object is relatively large compared to the measured 5ns [3] for the fence on a, slower, ARM processor. The fence should be a noop on x86 and SPARC.  When you start adding fields to object being deserialized [4] the time increases significantly. 

Result: 2176.895 ±(99.9%) 72.194 ns/op [Average]
  Statistics: (min, avg, max) = (2131.529, 2176.895, 2287.482), stdev = 47.752
  Confidence interval (99.9%): [2104.701, 2249.089]

Given this, I think we should issue the fence unconditionally. A nice property of this is that custom readObjects, using Unsafe, no longer need to reason about transient final fields, they can simply use putXXX for any field.

Updated, and greatly simplified, webrev:
  http://cr.openjdk.java.net/~chegar/deserialFence/webrev.04/webrev/

-Chris.

[1] http://cr.openjdk.java.net/~chegar/deserialFence/benchmark/DeserialBenchmark.java
[2] http://cr.openjdk.java.net/~chegar/deserialFence/benchmark/results.txt
[3] http://shipilev.net/blog/2014/all-fields-are-final/
[4] http://cr.openjdk.java.net/~chegar/deserialFence/benchmark/moreFields/