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

[David Holmes]

On 21/02/2014 9:52 AM, Doug Lea wrote:
> 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.

Hindsight is a wonderful thing. :)

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

??? The fields have to be volatile to use that. If they are volatile 
then there is no problem.

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

By "current approach" I assume you mean the non-volatile variant?

So we expect that for JDK 9 either:
a) all constructors complete with a storestore; or
b) all constructors with final field writes complete with a storestore;

?

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

volatile reads will slow things down a lot?

David
-----

> -Doug
>
>