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

[Aleksey Shipilev]

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