JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger
David Holmes
david.holmes at oracle.com
Thu Feb 20 22:11:16 UTC 2014
On 21/02/2014 7:20 AM, Paul Sandoz wrote:
> On Feb 20, 2014, at 9:09 PM, David Holmes <david.holmes at oracle.com> wrote:
>> In practice, because there are also final fields in these instances implementations will most likely perform a storestore barrier after construction and prior to setting the reference to the created object.
>
> Yes, that is what i was banking on.
>
> That is how hotspot behaves, right?
Yes.
> But, you are saying other VMs might not do so?
Right. A storestore at the end of construction is a simple and obvious
way to implement the final-field semantics, but there may be other ways.
The visibility guarantees for final fields extends only to those fields,
and objects accessed through them.
For illustrative purposes only: you could move all the lazy-initialized
fields into a separate State object, which is accessed via a final
field, and then they could be safely initialized and would not need to
be volatile.
David
-----
> Paul.
>
>> That would make non-volatile appear to work, but it would not be guaranteed to do so and the final-field "freeze" action only guarantees that unsafe publication will see the correct value of the final fields (and for final references anything reachable via that reference).
>>
>
>
More information about the core-libs-dev
mailing list