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 17:29:08 UTC 2015


On Feb 23, 2015, at 5:27 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:

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

Looks good.


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

I suppose one could write a jc-stress-test. But i don't wanna block the review on this aspect.


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

Those seem fine to me. Alas we cannot use direct assignments in some kind of larval phase :-)

Paul.



More information about the core-libs-dev mailing list