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?


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


> 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