JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger
david.holmes at oracle.com
Fri Feb 21 02:28:32 UTC 2014
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>
>>>> 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
>> guarantees for final fields extends only to those fields, and objects
>> 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?
More information about the core-libs-dev