[vectorIntrinsics] RFR: Refactor JVM Interface

Viswanathan, Sandhya sandhya.viswanathan at intel.com
Wed Mar 25 20:33:32 UTC 2020


HI Vladimir,

The patch fixed the PrintInlining crash that I was seeing. Thanks a lot.

Best Regards,
Sandhya

-----Original Message-----
From: Vladimir Ivanov <vladimir.x.ivanov at oracle.com> 
Sent: Wednesday, March 25, 2020 10:50 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 following patch fixes the crash:

diff --git a/src/hotspot/share/opto/compile.cpp
b/src/hotspot/share/opto/compile.cpp
--- a/src/hotspot/share/opto/compile.cpp
+++ b/src/hotspot/share/opto/compile.cpp
@@ -2283,7 +2283,6 @@
    assert(EnableVectorSupport || !has_vbox_nodes(), "sanity");
    if (EnableVectorSupport && has_vbox_nodes()) {
      TracePhase tp("", &timers[_t_vector]);
-    ResourceMark rm;
      PhaseVector pv(igvn);
      pv.optimize_vector_boxes();

I'll push it soon.

Best regards,
Vladimir Ivanov

On 25.03.2020 20:05, Viswanathan, Sandhya wrote:
> 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
>>


More information about the panama-dev mailing list