On 24 Feb 2015, at 15:07, Chris Hegarty <[email protected]> wrote:
> On 24 Feb 2015, at 11:45, Peter Levart <[email protected]> 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/
