[vectorIntrinsics] RFR: Refactor JVM Interface

[Viswanathan, Sandhya]

Hi Vladimir,

I am seeing a failure when using -XX:+PrintInlining after this checkin. The same command works successfully on a version just prior to this.

The command I used is:
cd vectorIntrinsics/test/jdk/jdk/incubator/vector
$JAVA_HOME/bin/java --add-modules=jdk.incubator.vector  -XX:+PrintCompilation  -XX:+PrintInlining AddTest
Where JAVA_HOME points to the fastdebug build.

This crashes after giving out of memory error as follows:
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 140700448411136 bytes for Chunk::new
# Possible reasons:
#   The system is out of physical RAM or swap space
#   The process is running with CompressedOops enabled, and the Java Heap may be blocking the growth of the native heap
# Possible solutions:
  ...
# This output file may be truncated or incomplete.
#
#  Out of Memory Error  (vectorIntrinsics/src/hotspot/share/memory/arena.cpp:195), pid=9986, tid=9998
 ...
Current CompileTask:
C2:    309  349       4       jdk.incubator.vector.FloatVector::bOpTemplate (66 bytes)

Stack: [0x00007ff794175000,0x00007ff794276000],  sp=0x00007ff794271030,  free space=1008k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code,
C=native code)
V  [libjvm.so+0x189dae0]  VMError::report_and_die(int, char const*, char const*, __va_list_
tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x220
V  [libjvm.so+0x189ea3b]  VMError::report_and_die(Thread*, char const*, int, unsigned long,
 VMErrorType, char const*, __va_list_tag*)+0x2b
V  [libjvm.so+0x99f0d5]  report_vm_out_of_memory(char const*, int, unsigned long, VMErrorTy
pe, char const*, ...)+0xd5
V  [libjvm.so+0x5791c8]  Arena::grow(unsigned long, AllocFailStrategy::AllocFailEnum)+0xe8
V  [libjvm.so+0x14a9c4e]  resource_allocate_bytes(unsigned long, AllocFailStrategy::AllocFa
ilEnum)+0x27e
V  [libjvm.so+0x139b829]  stringStream::as_string() const+0x19
V  [libjvm.so+0x93e21e]  Compile::process_print_inlining()+0x1fe
V  [libjvm.so+0x93f61a]  Compile::Optimize()+0x121a
V  [libjvm.so+0x94093a]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool,
bool, DirectiveSet*)+0x120a
V  [libjvm.so+0x7b5765]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+
0x305
V  [libjvm.so+0x94d72f]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x38f
V  [libjvm.so+0x94e5e3]  CompileBroker::compiler_thread_loop()+0x393
V  [libjvm.so+0x17bb92a]  JavaThread::thread_main_inner()+0x17a
V  [libjvm.so+0x17c0f86]  Thread::call_run()+0xf6
V  [libjvm.so+0x1386ef5]  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
>