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

Paul Sandoz paul.sandoz at oracle.com
Fri Feb 27 09:06:59 UTC 2015


On Feb 26, 2015, at 12:38 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

> 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/
> 

A nice simplification.


On Feb 26, 2015, at 12:57 PM, Chris Hegarty <chris.hegarty at 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.



More information about the core-libs-dev mailing list