RFR (XXL): 8223347: Integration of Vector API (Incubator): General HotSpot changes

[Vladimir Ivanov]

Hi,

Following up on review requests of API [0] and Java implementation [1] 
for Vector API (JEP 338 [2]), here's a request for review of general 
HotSpot changes (in shared code) required for supporting the API:

 
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/all.00-03/

(First of all, to set proper expectations: since the JEP is still in 
Candidate state, the intention is to initiate preliminary round(s) of 
review to inform the community and gather feedback before sending out 
final/official RFRs once the JEP is Targeted to a release.)

Vector API (being developed in Project Panama [3]) relies on JVM support 
to utilize optimal vector hardware instructions at runtime. It interacts 
with JVM through intrinsics (declared in 
jdk.internal.vm.vector.VectorSupport [4]) which expose vector operations 
support in C2 JIT-compiler.

As Paul wrote earlier: "A vector intrinsic is an internal low-level 
vector operation. The last argument to the intrinsic is fall back 
behavior in Java, implementing the scalar operation over the number of 
elements held by the vector.  Thus, If the intrinsic is not supported in 
C2 for the other arguments then the Java implementation is executed (the 
Java implementation is always executed when running in the interpreter 
or for C1)."

The rest of JVM support is about aggressively optimizing vector boxes to 
minimize (ideally eliminate) the overhead of boxing for vector values.
It's a stop-the-gap solution for vector box elimination problem until 
inline classes arrive. Vector classes are value-based and in the longer 
term will be migrated to inline classes once the support becomes available.

Vector API talk from JVMLS'18 [5] contains brief overview of JVM 
implementation and some details.

Complete implementation resides in vector-unstable branch of panama/dev 
repository [6].

Now to gory details (the patch is split in multiple "sub-webrevs"):

===========================================================

(1) 
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/00.backend.shared/

Ideal vector nodes for new operations introduced by Vector API.

(Platform-specific back end support will be posted for review separately).

===========================================================

(2) 
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/

JVM Java interface (VectorSupport) and intrinsic support in C2.

Vector instances are initially represented as VectorBox macro nodes and 
"unboxing" is represented by VectorUnbox node. It simplifies vector box 
elimination analysis and the nodes are expanded later right before EA pass.

Vectors have 2-level on-heap representation: for the vector value 
primitive array is used as a backing storage and it is encapsulated in a 
typed wrapper (e.g., Int256Vector - vector of 8 ints - contains a int[8] 
instance which is used to store vector value).

Unless VectorBox node goes away, it needs to be expanded into an 
allocation eventually, but it is a pure node and doesn't have any JVM 
state associated with it. The problem is solved by keeping JVM state 
separately in a VectorBoxAllocate node associated with VectorBox node 
and use it during expansion.

Also, to simplify vector box elimination, inlining of vector reboxing 
calls (VectorSupport::maybeRebox) is delayed until the analysis is over.

===========================================================

(3) 
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/02.vbox_elimination/

Vector box elimination analysis implementation. (Brief overview: slides 
#36-42 [5].)

The main part is devoted to scalarization across safepoints and 
rematerialization support during deoptimization. In C2-generated code 
vector operations work with raw vector values which live in registers or 
spilled on the stack and it allows to avoid boxing/unboxing when a 
vector value is alive across a safepoint. As with other values, there's 
just a location of the vector value at the safepoint and vector type 
information recorded in the relevant nmethod metadata and all the 
heavy-lifting happens only when rematerialization takes place.

The analysis preserves object identity invariants except during 
aggressive reboxing (guarded by -XX:+EnableAggressiveReboxing).

(Aggressive reboxing is crucial for cases when vectors "escape": it 
allocates a fresh instance at every escape point thus enabling original 
instance to go away.)

===========================================================

(4) 
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/03.module.hotspot/

HotSpot changes for jdk.incubator.vector module. Vector support is 
makred experimental and turned off by default. JEP 338 proposes the API 
to be released as an incubator module, so a user has to specify 
"--add-module jdk.incubator.vector" on the command line to be able to 
use it.
When user does that, JVM automatically enables Vector API support.
It improves usability (user doesn't need to separately "open" the API 
and enable JVM support) while minimizing risks of destabilitzation from 
new code when the API is not used.


That's it! Will be happy to answer any questions.

And thanks in advance for any feedback!

Best regards,
Vladimir Ivanov

[0] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-March/065345.html

[1] 
https://mail.openjdk.java.net/pipermail/hotspot-dev/2020-April/041228.html

[2] https://openjdk.java.net/jeps/338

[3] https://openjdk.java.net/projects/panama/

[4] 
http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.00/01.intrinsics/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java.html

[5] http://cr.openjdk.java.net/~vlivanov/talks/2018_JVMLS_VectorAPI.pdf

[6] http://hg.openjdk.java.net/panama/dev/shortlog/92bbd44386e9

     $ hg clone http://hg.openjdk.java.net/panama/dev/ -b vector-unstable