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

Tue Apr 7 21:05:55 UTC 2020

Thanks Vladimir,

Running tier1-tier4 tests and not getting any regressions is very good.
I would also recommend to run other tiers as they contain more stress tests as well as jck.
Doing it at least once before the integration would be very helpful and prevents us from
getting late issues.

Please let me know if you need any help with this.

regards,
-katya

On 4/7/20 2:39 AM, Vladimir Ivanov wrote:
> 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
>>