On Feb 26, 2015, at 12:38 PM, Chris Hegarty <chris.hega...@oracle.com> wrote:
> On 24 Feb 2015, at 15:07, Chris Hegarty <chris.hega...@oracle.com> wrote: > >> On 24 Feb 2015, at 11:45, Peter Levart <peter.lev...@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/ > A nice simplification. On Feb 26, 2015, at 12:57 PM, Chris Hegarty <chris.hega...@oracle.com> wrote: >> 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. Yes. Paul.
