[lworld+vector] RFR: 8304310: Initial compilers and runtime handling for multifield backed vectors. [v6]

[Jatin Bhateja]

On Tue, 21 Mar 2023 09:21:06 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments resolutions.
>
> src/hotspot/share/opto/vector.cpp line 520:
> 
>> 518: 
>> 519:     int elem_size = type2aelembytes(bt);
>> 520:     Node* vec_val_load = get_loaded_payload(vec_unbox);
> 
> We could also optimize the VectorUnbox to the vector node with `VectorUnbox::Identity()`. So `get_loaded_payload()` is needless?

> Thanks for the updating! So the correspond `expand_vunbox_node` can also be implemented by calling `InlineTypeNode::make_from_oop` ?

Yes, every time C2 sees an value instance it does create an InlineTypeNode IR by loading the appropriate fields from object using InlineTypeNode::make_from_oop,

> Hi @jatin-bhateja ,
> 
> I ran an unit test on a ARM NEON system, and the jvm crashes with following log:
> 
> ```
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/mnt/local/code/valhalla/src/hotspot/share/opto/loopnode.cpp:5871), pid=544741, tid=544757
> #  assert(false) failed: Bad graph detected in build_loop_late
> #
> # JRE version: OpenJDK Runtime Environment (21.0) (fastdebug build 21-internal-git-558fb2e03)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 21-internal-git-558fb2e03, mixed mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
> # Problematic frame:
> # V  [libjvm.so+0x13b395c]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x18c
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /mnt/local/code/test/vector_api/aarch64/armie/core.544741)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> ```
> 
> And here is the call stack:
> 
> ```
> ---------------  T H R E A D  ---------------
> 
> Current thread (0x0000fffe0008dc80):  JavaThread "C2 CompilerThread2" daemon [_thread_in_native, id=544757, stack(0x0000fffe24d00000,0x0000fffe24f00000)]
> 
> 
> Current CompileTask:
> C2:    377  172             jdk.incubator.vector.IntVector::fromArray0Template (39 bytes)
> 
> Stack: [0x0000fffe24d00000,0x0000fffe24f00000],  sp=0x0000fffe24ef9920,  free space=2022k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x13b395c]  PhaseIdealLoop::build_loop_late_post_work(Node*, bool)+0x18c  (loopnode.cpp:5871)
> V  [libjvm.so+0x13b4194]  PhaseIdealLoop::build_loop_late(VectorSet&, Node_List&, Node_Stack&)+0xd4  (loopnode.cpp:5775)
> V  [libjvm.so+0x13b4aa4]  PhaseIdealLoop::build_and_optimize()+0x4d0  (loopnode.cpp:4403)
> V  [libjvm.so+0xa30f28]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x1e8  (loopnode.hpp:1086)
> V  [libjvm.so+0xa2be08]  Compile::Optimize()+0x428  (compile.cpp:2828)
> V  [libjvm.so+0xa2f10c]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x11ec  (compile.cpp:842)
> V  [libjvm.so+0x829cd4]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x3f0  (c2compiler.cpp:113)
> V  [libjvm.so+0xa3c410]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xbb0  (compileBroker.cpp:2237)
> V  [libjvm.so+0xa3cd44]  CompileBroker::compiler_thread_loop()+0x3f4  (compileBroker.cpp:1916)
> V  [libjvm.so+0xf92068]  JavaThread::thread_main_inner()+0x2f4  (javaThread.cpp:710)
> V  [libjvm.so+0x1a3afb8]  Thread::call_run()+0xf8  (thread.cpp:224)
> V  [libjvm.so+0x15f6814]  thread_native_entry(Thread*)+0x100  (os_linux.cpp:739)
> C  [libc.so.6+0x7d5c8]
> ```
> 
> The unit test is:
> 
> ```
> static VectorSpecies<Integer> I_SPECIES = IntVector.SPECIES_PREFERRED;
> 
> for (int i = 0; i < LENGTH; i += vl) {
>             var av = IntVector.fromArray(I_SPECIES, ia, i);
>             var bv = IntVector.fromArray(I_SPECIES, ib, i);
>             av.lanewise(VectorOperators.ADD, bv).intoArray(ic, i);
> }
> ```
> 
> And I cannot reproduce the same issue on a X86 AVX-512 machine. But from the log, it seems not an AArch64 backend issue. So do you have any idea or met this issue before?
> 
> BTW, is it possible to split this big patch into two parts: 1) multi-field vectorization part 2) hotspot compiler support for vector intrinsification part. This patch is too big which covers several compiler/runtime support parts. It's not so easy to analysis the issue to me once it happens. And I also tried to separate it by myself. But unfortunately, I also met another JVM crash issue which may related to the register allocation to vector registers on AArch64 when testing the "multi-fields" vectorization changes. I'm not sure whether I have missed something when doing the separation. But it will be helpful to look at the issue with your help. Thanks a lot!
> 
> Best Regards, Xiaohong

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/833#discussion_r1160355296