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

[Jim Graham]

That looks great!

Maybe I'm missing something (memory fences are not in my wheelhouse), 
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)

One issue I found confusing, the docs for loadFence() say that a 
loadloadFence is not provided and gives reasons - then 2 methods later 
we have loadloadFence() - it turns out that loadloadFence calls the full 
loadFence method, but its presence contradicts the comment in the 
earlier method, which is just confusing.  It should probably be 
deprecated and mention that it is provided for convenience and actually 
does a full loadFence() and move the reason from the other method to the 
comment on the loadload method (a caller to loadFence() wouldn't likely 
care about that issue, but a caller to loadloadFence() would need to 
know it so that documentation really belongs in the latter method). 
Perhaps the comment was added to loadFence before the convenience 
loadload method was added?

			...jim

On 2/29/2016 8:32 AM, Aleksey Shipilev wrote:
> On 27.02.2016 02:41, John Rose wrote:
>> +1 on recommending a fence op in the Java-doc.
>>
>> Also +1 on recommending keeping it in a local. That's overkill, but simple and safe to follow.
>
> Thanks Jim, John and Andrew for chiming in.
>
> Let's see if this Javadoc variant floats:
>    http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.04/
>    http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/
>
> -Aleksey
>