Hi Chris, webrev.04 is nice an simple now. I'm ok with it.
Regards, Peter On Feb 27, 2015 11:11 AM, "Chris Hegarty" <chris.hega...@oracle.com> wrote: > Hi Peter, > > I think you are ok with this now. If so, would you mind to just taking a > quick look at the webrev, the changes are trivial, and replying to the list. > > ( I want to list you as a reviewer, but don't want to do so until I know > you are happy with the changes) . > > Thanks, > -Chris. > > On 27/02/15 09:06, Paul Sandoz wrote: > >> >> 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. >> >>
