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

[Jim Graham]

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