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

Tue Apr 7 09:39:32 UTC 2020

Hi Katya,

> what kind of testing has been done to verify these changes?
> Taking into account the changes are quite large and touch share code
> running hs compiler and perhaps runtime tiers would be very advisable.

The changes (and previous versions) were tested in 2 modes:

   * ran through tier1-tier4 with the functionality turned OFF; (also, 
some previous version went through tier1-tier6 once)

   * unit tests on Vector API were run on different x86 hardware in the 
following modes: -XX:UseAVX=[3,2,1,0] -XX:UseSSE=[4,3,2]. Arm engineers 
tested the version in vector-unstable branch on AArch64 hardware.

As of now, the only known test failure is 
compiler/graalunit/HotspotTest.java in 
org.graalvm.compiler.hotspot.test.CheckGraalIntrinsics which should be 
taught about new JVM intrinsics added.

Best regards,
Vladimir Ivanov

> On 4/3/20 4:12 PM, 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
> 