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