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

Wed Aug 5 19:17:00 UTC 2020

Thanks for the review, Coleen.

Best regards,
Vladimir Ivanov

On 31.07.2020 22:38, coleen.phillimore at oracle.com wrote:
> The runtime code still looks good to me.
> Coleen
> 
> On 7/28/20 6:29 PM, Vladimir Ivanov wrote:
>> Hi,
>>
>> Thanks for the feedback on webrev.00, Remi, Coleen, Vladimir K., and 
>> Ekaterina!
>>
>> Here are the latest changes for Vector API support in HotSpot shared 
>> code:
>>
>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01 
>>
>>
>> Incremental changes (diff against webrev.00):
>>
>> http://cr.openjdk.java.net/~vlivanov/panama/vector/jep338/hotspot.shared/webrev.01_00 
>>
>>
>> I decided to post it here and not initiate a new round of reviews 
>> because the changes are mostly limited to minor cleanups / simple bug 
>> fixes.
>>
>> Detailed summary:
>>   - rebased to jdk/jdk tip;
>>   - got rid of NotV, VLShiftV, VRShiftV, VURShiftV nodes;
>>   - restore lazy cleanup logic during incremental inlining (see 
>> needs_cleanup in compile.cpp);
>>   - got rid of x86-specific changes in shared code;
>>   - fix for 8244867 [1];
>>   - fix Graal test failure: enumerate VectorSupport intrinsics in 
>> CheckGraalIntrinsics
>>   - numerous minor cleanups
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] http://hg.openjdk.java.net/panama/dev/rev/dcfc7b6e8977
>>     http://jbs.oracle.com/browse/JDK-8244867
>>     8244867: 2 vector api tests crash with 
>> assert(is_reference_type(basic_type())) failed: wrong type
>> Summary: Adding safety checks to prevent intrinsification if class 
>> arguments of non-primitive types are uninitialized.
>>
>> 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
> 