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

Paul Sandoz paul.sandoz at oracle.com
Mon Feb 23 15:59:56 UTC 2015


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. 

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.

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.

Paul.




More information about the core-libs-dev mailing list