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

[John Rose]

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

– John

> On Feb 26, 2016, at 2:34 PM, Jim Graham <james.graham at oracle.com> wrote:
> 
> Thanks Aleksey,
> 
> As I said, I just wanted to see more objective diligence in the discussion of the risks here.
> 
> With regard to documentation, I think the changes made to the javadoc include a lot of stating the obvious, which is fine, and with some tricky points mentioned as well.  I think most engineers can handle "have I written to every element of the array" considerations, but one area where they may not have expertise would be in areas of how the compiler and/or processor cache mechanisms might reorder memory accesses in unexpected ways.  For instance, an earlier comment showed some sort of mem-fence operation that was indicated to ensure that the data was written to the array in a thread-safe manner before any external access was allowed.  (I'm guessing that the simple act of calling the method and returning the value would enforce a mem-fence in that case?)  That consideration would be a good thing to describe in the javadoc.  Also, perhaps recommending that the references be held in a local variable until the initialization phase is complete before storing the reference into a field (that might be part of stating the obvious, other than how it might interact with mem-fence considerations)?
> 
> In the end, I'm not intending to be the voice of opposition on this, just hoping to see the discussion be a little more rounded...
> 
>            ...jim
> 
>> On 2/26/2016 10:56 AM, Aleksey Shipilev wrote:
>> Hi Jim,
>> 
>> I agree with most of your points.
>> 
>> You are correct that comparing allocateMemory and
>> allocateUninitializedArray is cumbersome, and I was not trying to
>> compare these. My comment was about Unsafe at large, notably
>> peek-and-poke methods that we already have, and can already be used to
>> leak out data. This is to frame the discussion into "Unsafe is unsafe"
>> mood.
>> 
>> This is not a regular JDK method. As many other Unsafe methods, it comes
>> with caveats, and hordes of developers are not the target audience, even
>> most JDK developers are not the target audience.
>> 
>> The target audience is a tiny group of core library developers who are
>> (admittedly) well-versed in reading the labels on unsafe methods before
>> using them. As much as I would like to have a capability-based (and also
>> fingerprint/retina-scan-based) access control to internal APIs, current
>> incarnation of Unsafe requires engineering discipline from users.
>> 
>> Unsafe is "off limits" for those who do not understand low-level
>> mechanics (memory ordering, atomicity requirements, interaction with
>> runtime, you name it). Unsafe is a special -- perhaps, the only! --
>> place in JDK where the tradeoff between performance and safety is
>> heavily tilted towards performance.
>> 
>> Anyone from the huge body of engineers who does not understand this and
>> uses Unsafe as just another JDK class, could use a really good
>> talking-to, and probably lots and lots of training.
>> 
>>> On 02/26/2016 01:24 PM, Jim Graham wrote:
>>> I'm seeing a fair amount of hand waving here and not much objective
>>> analysis of the risks.  It's important to nail down the issues if for
>>> no other reason than to provide good advice on usage practices in
>>> our documentation to our internal developers...
>> 
>> Hopefully the updated Javadoc provides enough deterrent from accidental
>> use. I'd be happy to amend this with even harsher wording, if you tell
>> me the exact words :)
>> 
>> Webrevs:
>>   http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.03/
>>   http://cr.openjdk.java.net/~shade/8150465/webrev.hs.04/
>> 
>> Thanks,
>> -Aleksey
>> 
>>