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

[Chris Hegarty]

On 23/02/15 15:59, Paul Sandoz wrote:
>
> On Feb 23, 2015, at 4:40 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
>
>> On 23/02/15 15:30, Vitaly Davidovich wrote:
>>> Ok Chris, sounds good.
>>>
>>>     It could be, but I omitted it as it requires a pesky explicit
>>>     assignment of false in the case where there are not final fields!
>>>
>>>
>>> You could use a local (non-final) boolean to track this state (assigned
>>> with false), and then set the field with it after the looping is over.
>>> Anyway, your call.
>>
>> That is better. Done.
>>
>
> This looks good. I think it would be useful to have a comment in the freeze method that this stamps in a storestore|storeload barrier (since that is the closest we have here) where as hotspot for construction stamps in just the necessary a storestore barrier.

Comment added.
   http://cr.openjdk.java.net/~chegar/deserialFence/webrev.02/webrev/

> Two follow ups:
>
> 1) How can we test this? Is there anything in the HotSpot-related white box class that could be used? I suspect there is probably not and it will be tricky to test.

I am not aware of any such framework in Hotspot, but I'll see if I can 
write something that may have the ability replicate this, on some platforms.

> 2) What about existing code in the JDK that uses UNSAFE.setVolatile or explicit fence calls? Such code should be updated. For example, i recall there might be stuff in BigInteger/Decimal. We can do a search for classes that are serializable with final fields.

Ah yes, BigDecimal and BigInteger can be updated now ( there are no 
doubt others too ). I've included BigDecimal and BigInteger in the 
latest in-place updated webrev, to see if we might want to update them 
as part of this change.

-Chris.

> Paul.
>