On 26 Feb 2015, at 11:38, Chris Hegarty <[email protected]> wrote:
> 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. Of course, this measurement was for a hotspots post construction StoreStore, we are issuing a StoreStore|StoreLoad, but the general idea is still the same, the fence is relatively insignificant, when performed per graph, compared to the cost or re-consisituing the graph. -Chris. > 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/
