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

Thu Apr 16 12:32:52 UTC 2020

Hi,

Any more reviews, please? Especially, compiler and runtime-related changes.

Thanks in advance!

Best regards,
Vladimir Ivanov

On 04.04.2020 02:12, Vladimir Ivanov wrote:
> 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