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