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

[Christian Thalinger]

+    public Object allocateArrayUninit(Class<?> componentType, int length) {

Can we use another name like allocateUninitializedArray?

> On Feb 24, 2016, at 12:43 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> Hi,
> 
> When instantiating arrays from Java, we have to zero the backing storage
> to match JLS requirements. In some cases, like with the subsequent
> arraycopy, compilers are able to remove zeroing. However, in a generic
> case where a complicated processing is done after the allocation,
> compilers are unable to reliably figure out the array is covered completely.
> 
> JDK-8150463 is a motivational example of this: Java level String concat
> loses to C2's OptimizeStringConcat because C2 can skip zeroing for its
> own allocations.
> 
> It might make sense to allow new Unsafe method that will return
> uninitialized arrays to trusted Java code:
>  https://bugs.openjdk.java.net/browse/JDK-8150465
> 
> Webrevs:
>  http://cr.openjdk.java.net/~shade/8150465/webrev.hs.01/
>  http://cr.openjdk.java.net/~shade/8150465/webrev.jdk.01/
> 
> It helps that we already have java.lang.reflect.Array.newArray
> intrinsic, so we can reuse a lot of code. The intrinsic code nukes the
> array allocation in the same way PhaseStringOpts::allocate_byte_array
> does it in OptimizeStringConcat. Alas, no such luck in C1, and so it
> stays untouched, falling back to normal Java allocations.
> 
> Performance data shows the promising improvements:
>  http://cr.openjdk.java.net/~shade/8150465/notes.txt
> 
> Also, using this new method brings the best Java-level-only
> concatenation strategy to OptimizeStringConcat levels, and beyond.
> 
> Testing: new test; targeted microbenchmarks; JPRT (in progress)
> 
> Thanks,
> -Aleksey
>