JEPs proposed to target JDK 9 (2015/7/16)

[Paul Sandoz]

Hi Vitaly,

Unsafe is not being removed it is being made inaccessible by default. As such it is currently not going anywhere.

It’s not possible to replace all the use-cases where one can peek and poke at any memory address.

We have to pick off common use-cases and chip away at improving how the JIT optimizes.

One such common use-case, separate but perhaps related to VarHandles, i have been looking at is array equality and array comparison (hold your nose at all those new methods on Arrays, it’s what it is!):

  http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/

This patch separates out two implementation approaches for performance measurement purposes.

Under the covers one approach leverages an array mismatch method that views byte[]/short[]/char[] etc. as a pseudo unaligned long[] via Unsage.getLongUnaligned:

http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html

So far it seems to perform well and does not require one to dive into HotSpot and create new intrinsics. (Note: there is already a C2 intrinsic for char[] equality that performs very well so this technique is not needed in that case, but is still needed for C1.)

I have experimental support for a VarHandle that views byte[] as a pseudo unaligned long[]. While you can also do this with ByteBuffer one is in the lap of the escape analysis gods. I would like to revisit this array mismatch method to see if i can replace Unsafe with VarHandle and achieve the same performance and similar generated code (ideally the same in the unrolled loop).

In terms of JIT optimisations it would be handy if HotSpot could turn two contigious unaligned unsafe long accesses into one SIMD-based access. I don’t understand enough about the super word/vectorization support in HotSpot to know if that is feasible.

More generally if HotSpot could “naturally" optimize the ordinary array equality/comparison code even better! But i dunno if that is possible for both C1 and C2 in the near term. So i believe the array mismatch implementation technique is a good solution for the moment.

Paul.

On 17 Jul 2015, at 04:34, Vitaly Davidovich <vitalyd at gmail.com> wrote:

> Right, there will be places where programmer knows more than the JIT.  This
> is expressable with Unsafe today, and will not be quite so with
> varhandles.  The overall context here is removal of Unsafe, so we're going
> from something possible today to something that heavily relies on JIT.  It
> seems like a bit of Sufficiently Smart Compiler territory ...
> 
> Having JIT gather all array lengths and look at most restrictive is good,
> but still incurs the arguably biggest cost of this whole thing: memory
> accesses that may not otherwise be needed.  This also would work best in a
> loop context where this check could be amortized over the iterations, but
> sometimes you just have islands of code that do this type of thing and not
> all bunched in one tight loop that the JIT can easily work with.
> 
> Most languages with safety checks typically have unsafe constructs/regions
> - Unsafe serves a bit of that role on the JVM, and I'm uncertain that
> removing that escape hatch is a good thing when there's no replacement that
> works at least as well.