RFR (S) 8150465: Unsafe methods to produce uninitialized arrays

[Jim Graham]

Which is why these docs are important, eh?  ;)

I think I get it now.  I was worried about "loading from the array after 
storing to the array", but that's a red herring because the fence isn't 
about ordering across threads.  So the distinction is actually about 
publishing the handle, i.e. a store operation, and the real 
consideration is "making sure all of the initializing stores to the 
array elements are flushed before the publicizing store of the array 
handle", so really you want store ordering... as you said... ding!

I'm not sure if that is worth spelling out for those of us who don't 
worry about these things for a living, but adding "[or issuing a 
{storeFence}] just before executing the assignment that publishes the 
reference" might help.

Looks good then!

	...jim

(who probably now owns enough Memory Model rope to hang himself)

On 2/29/2016 11:29 AM, Andrew Haley wrote:
> On 02/29/2016 07:19 PM, Jim Graham wrote:
>> Maybe I'm missing something (memory fences are not in my wheelhouse),
>
> Sadly, they are in mine.  :-)
>
>> but is storeFence() the right fence to use?  I would think you would
>> want stores before the fence to not be reordered wrt loads after the
>> fence, but storeFence() only protects against stores after the fence
>> (according to its doc comment).  I couldn't find a storeLoadFence()
>> method...?  (and storeFence does not incorporate storeload protection)
>
> You don't need StoreLoad (which is always a full fence AFAIK) but I
> think that you do need (LoadStore|StoreStore), aka release().
>
> Andrew.
>