On 23/02/15 15:59, Paul Sandoz wrote:
On Feb 23, 2015, at 4:40 PM, Chris Hegarty <[email protected]> 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.
