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

[Peter Levart]

On 02/23/2015 11:31 PM, David Holmes wrote:
>> So I propose the following variant for now (including just
>> ObjectInputStream and ObjectStreamClass) that fixes 1st two issues
>> above. I suggest waiting with BigDecimal/BigInteger changes until
>> FieldAccess API is available and throw away Unsafe usage alltogether at
>> that point:
>>
>> http://cr.openjdk.java.net/~plevart/jdk9-dev/ObjectInputStream.freeze/webrev.01/ 
>>
>
> 1183             hasFinal |= d.fieldRefl.hasFinal();
>
> Didn't you suggest not using this form previously due to its 
> inefficiency.
>
> David 

Yes, in case the writes are to a field (main memory) vs. locals 
(registers typically) and when on hot-path. Here the 'hasFinal' is a 
local and not on hot-path (the result of getClassDataLayout0() is cached 
in ObjectStreamClass) so the optimization is not so important.

We would like to minimize the overhead of tracking whether 
deserialization has set any final field in object graph as much as 
possible or else it will be higher than placing the freeze fence 
unconditionally. At some point (depending on the size of deserialized 
stream) the overhead of tracking will be higher than redundant placement 
of freeze fence, but this point should be moved as high as possible. We 
should measure this. Perhaps the tracking is not needed even for the 
smallest streams.

Regards, Peter