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

[Vladimir Kozlov]

What is your story for GC? When an array become visible and GC happens, 
it will expect only initialized arrays.

Thanks,
Vladimir

On 2/24/16 2:43 PM, Aleksey Shipilev 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
>