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

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Aug 5 19:18:39 UTC 2020 

On 8/5/20 12:16 PM, Vladimir Ivanov wrote:
> Thanks for the review, Vladimir.
> 
>> compile.cpp: what is next comment about?
>>
>> +  // FIXME for_igvn() is corrupted from here: new_worklist which is set_for_ignv() was allocated on stack.
> 
> It documents a bug in the preceding code which makes for_igvn() node list unusable beyond that point:
> 
> 2098   if (!failing() && RenumberLiveNodes && live_nodes() + NodeLimitFudgeFactor < unique()) {
> 2099     Compile::TracePhase tp("", &timers[_t_renumberLive]);
> 2100     initial_gvn()->replace_with(&igvn);
> 2101     for_igvn()->clear();
> 2102     Unique_Node_List new_worklist(C->comp_arena());
> 2103     {
> 2104       ResourceMark rm;
> 2105       PhaseRenumberLive prl = PhaseRenumberLive(initial_gvn(), for_igvn(), &new_worklist);
> 2106     }
> 2107     set_for_igvn(&new_worklist);
> 2108     igvn = PhaseIterGVN(initial_gvn());
> 2109     igvn.optimize();
> 2110   }
> 2111
> 2112   // FIXME for_igvn() is corrupted from here: new_worklist which is set_for_ignv() was allocated on stack.
> 
> I'm fine with removing the commend and filing a bug instead.

Yes, please.

> 
>> print_method(): NodeClassNames[] should be available in product. Node::Name() method is not, but we can move it to 
>> product. But I am fine to do that later.
> 
> Good point. I'll migrate print_method() to NodeClassNames[] for now.

Okay.

> 
>> Why VectorSupport.java does not have copyright header?
> 
> Good catch! Will fix it and incorporate into the webrev in-place shortly.

Thanks,
Vladimir K

> 
> Best regards,
> Vladimir Ivanov
> 
>> On 7/28/20 3: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

More information about the hotspot-compiler-dev mailing list