[vectorIntrinsics] RFR: Refactor JVM Interface

[Vladimir Ivanov]

> The failure used to be reported as follows for VectorConversionTests.java on KNL platform. With the refactor now the test passes.

Interesting. I doubt I fixed it (even accidentally). More like it 
doesn't hit the problematic path anymore. I'll try to reproduce the failure.

Best regards,
Vladimir Ivanov

> # To suppress the following error report, specify this argument
> # after -XX: or in .hotspotrc:  SuppressErrorAt=/compile.cpp:2760
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error ( vectorIntrinsics/src/hotspot/share/opto/compile.cpp:2760), pid=268802, tid=268817
> #  Error: assert(!vbox->is_Phi()) failed
> ...
> # Problematic frame:
> # V  [libjvm.so+0x932921]  Compile::expand_vbox_node_helper(Node*, Node*, TypeInstPtr const*, TypeVect const*)+0x81
> #
> 
>  From hs_err file:
> 
> Current CompileTask:
> C2: 639330 2033 %           VectorConversionTests::conversion_kernel @ 84 (300 bytes)
> 
> Stack: [0x00007ff4680ef000,0x00007ff4681f0000],  sp=0x00007ff4681eb450,  free space=1009k
> Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x932921]  Compile::expand_vbox_node_helper(Node*, Node*, TypeInstPtr const*, TypeVect const*)+0x81
> V  [libjvm.so+0x932d84]  Compile::expand_vbox_node(VectorBoxNode*)+0x84
> V  [libjvm.so+0x942cc8]  Compile::expand_vbox_nodes()+0x128
> V  [libjvm.so+0x9437e8]  Compile::Optimize()+0x648
> V  [libjvm.so+0x945612]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0x1172
> V  [libjvm.so+0x7b55d5]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x305
> V  [libjvm.so+0x9523af]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x38f
> V  [libjvm.so+0x953263]  CompileBroker::compiler_thread_loop()+0x393
> V  [libjvm.so+0x17ce56a]  JavaThread::thread_main_inner()+0x17a
> V  [libjvm.so+0x17d3bc6]  Thread::call_run()+0xf6
> V  [libjvm.so+0x13972b5]  thread_native_entry(Thread*)+0x125
> 
> Best Regards,
> Sandhya
> 
> -----Original Message-----
> From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Sent: Wednesday, March 25, 2020 3:22 AM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; panama-dev <panama-dev at openjdk.java.net>
> Subject: Re: [vectorIntrinsics] RFR: Refactor JVM Interface
> 
> Hi Sandhya,
> 
>> The vector api tests pass on all Intel platforms with this patch.
> 
> Thank you!
> 
>> Only one minor build issue was there due to a last remaining UseVectorApiIntrinsics use in stubGenerator_x86_64.cpp.
> 
> Good catch. Fixed.
> 
>> The patch also fixes one long standing vbox related issue that we were seeing on one of our platforms.
> 
> Can you elaborate here a bit, please? Is it related to missing safepoint polls?
> 
>> Please go ahead and check in.
> 
> Pushed.
> 
> Best regards,
> Vladimir Ivanov
> 
>> -----Original Message-----
>> From: panama-dev <panama-dev-bounces at openjdk.java.net> On Behalf Of
>> Vladimir Ivanov
>> Sent: Tuesday, March 24, 2020 2:07 PM
>> To: panama-dev <panama-dev at openjdk.java.net>
>> Subject: [vectorIntrinsics] RFR: Refactor JVM Interface
>>
>> http://cr.openjdk.java.net/~vlivanov/panama/vector/new_jvm_interface/w
>> ebrev.00/
>>
>> (First cleanup pass over the JVM implementation.
>> The focus is on JVM-JDK interface.)
>>
>> New JVM interface is minimal and contains intrinsics, well-known
>> classes, and opcode declarations. It resides in java.base
>> (jdk.internal.vm.vector.VectorSupport) and exports the interface to jdk.incubator.vector module.
>>
>> JVM doesn't need to know about typed vectors anymore: VectorPayload,
>> VectorMask, and VectorShuffle are enough to represent all interesting
>> cases and provide enough information to the JVM how to handle vector
>> classes:
>>
>>      - VectorPayload class represents vector values which are amenable to aggressive box elimination transformation
>>         * vector on-heap representation remains primitive array-backed;
>>         * classes which extend VectorPayload should declare 2 static
>> fields (VLENGTH and ETYPE) which describe vector on-heap
>> representation to the JVM (array length and its element type);
>>
>>      - VectorShuffle and VectorMask mark vector shuffles and masks for
>> the JVM;
>>
>>      - VectorSpecies and Vector are there to enhance type checking of
>> JVM intrinsic usages;
>>
>>
>> Also, additional refactorings/fixes:
>>
>>      * merged reinterpret and cast intrinsics into one (convert)
>>
>>      * refactored rematerialization support
>>
>>      * don't remove unused VectorBoxAllocate nodes, but replace them
>> with safepoints
>>
>>      * VM vector support is turned off by default, but automatically
>> enabled when user adds jdk.incubator.vector incubator module to the
>> graph
>>
>>      * multiple minor fixes and cleanups along the way
>>
>> Testing: jdk/incubator/vector tests
>>
>> Best regards,
>> Vladimir Ivanov
>>