JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

[Doug Lea]

On 02/20/2014 05:11 PM, David Holmes wrote:
> 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.

Which has turned out in practice to be the only plausible way to do
this, so the spec might as well have said so.

Paul:  If you'd like to be pedantically correct at the
expense of a lot more overhead, you could  use
AtomicXFieldUpdater.lazySet in the constructor.
But since these changes are targeting JDK9, it is very
likely that the memory model will be updated to
confirm that the current approach is legal by the time
it ships.

Or maybe David has some alternative idea that
won't slow things down a lot for no good reason :-)

-Doug