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