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

[Paul Sandoz]

On Feb 23, 2015, at 10:08 PM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> - We have to be careful with "loosening" of volatile writes to final fields in custom readObject() methods (BigDecimal.intCompact for example) especialy if they are writes to fields that are not serial fields in ObjectStreamClass (either they are transient or not listed in serialPersistentFields). By doing that, you are relying on the fact that default deserialization (defaultReadObject() call in case of BigDecimal) tracks at least one other final field that is also serial field.

Yes, but i would presume that the reasons for using volatile writes is almost always to stamp in the required barrier?


> This is the case with BigDecimal and BigInteger, but in general it is not. It will be interesting how tracking will be implemented most efficiently when FieldAccess API appears, but that's another story...
> 

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

Why wait? These are simple and beneficial changes, and can be revisited if/when a new API is available.

--

Actually... given the performance analysis Alexey did on "All fields are final" [1], we might be able to get away with always stamping in the barrier (and we could expose another method in Unsafe if necessary just to do the storestore). We at least need to revisit if the JMM is revised to this effect.

Paul.

[1] http://shipilev.net/blog/2014/all-fields-are-final/