[vectorIntrinsics] ByteArray tests and fix

Paul Sandoz paul.sandoz at oracle.com
Mon Apr 20 17:22:21 UTC 2020



> On Apr 17, 2020, at 5:19 PM, Viswanathan, Sandhya <sandhya.viswanathan at intel.com> wrote:
> 
> I have an updated webrev, but I am seeing a compilation failure intermittently with it.
> 
> http://cr.openjdk.java.net/~sviswanathan/vectorIntrinsics/ByteArray/webrev.01/
> 

That’s better, but I presume the intermittent failure was always there, looks like an HS bug?

Paul.


> The compilation error shows up in Short64VectorLoadStoreTests.java, details below:
> 
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (../vint/src/hotspot/share/opto/type.hpp:1633), pid=23573, tid=23866
> #  assert(_base >= VectorS && _base <= VectorZ) failed: Not a Vector
> 
> Current CompileTask:
> C2:  42785 2000 %           Short64VectorLoadStoreTests::loadStoreByteArrayMask @ 209 (269 bytes)
> 
> Stack: [0x00007f2f5d2a1000,0x00007f2f5d3a2000],  sp=0x00007f2f5d39d580,  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+0x8cccfd]  StoreVectorNode::memory_size() const+0x8d
> V  [libjvm.so+0x1216203]  InitializeNode::can_capture_store(StoreNode*, PhaseGVN*, bool) [clone .part.201] [clone .constprop.224
> ]+0x133
> V  [libjvm.so+0x1219118]  StoreNode::Ideal(PhaseGVN*, bool)+0x168
> V  [libjvm.so+0x13d6a40]  PhaseIterGVN::transform_old(Node*)+0xb0
> V  [libjvm.so+0x13d118b]  PhaseIterGVN::optimize()+0x8b
> V  [libjvm.so+0x923265]  Compile::Optimize()+0x895
> V  [libjvm.so+0x924b32]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xe32
> V  [libjvm.so+0x799e7e]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0x2ae
> V  [libjvm.so+0x9302ef]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x38f
> V  [libjvm.so+0x9311a3]  CompileBroker::compiler_thread_loop()+0x393
> V  [libjvm.so+0x1755cea]  JavaThread::thread_main_inner()+0x17a
> V  [libjvm.so+0x175b116]  Thread::call_run()+0xf6
> V  [libjvm.so+0x134ecb1]  thread_native_entry(Thread*)+0x121
> 
> Best Regards,
> Sandhya
> 
> -----Original Message-----
> From: Paul Sandoz <paul.sandoz at oracle.com> 
> Sent: Thursday, April 16, 2020 6:07 PM
> To: Viswanathan, Sandhya <sandhya.viswanathan at intel.com>
> Cc: panama-dev at openjdk.java.net' <panama-dev at openjdk.java.net>; Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> Subject: Re: [vectorIntrinsics] ByteArray tests and fix
> 
> X-Vector.java.template
>> 
> 3196         $Type$Buffer tb = wrapper(a, offset, bo);
> 3197         return vsp.ldOp(tb, offset, (AbstractMask<$Boxtype$>)m,
> 3198 #if[byte]
> 3199                         (tb_, offset_, i)  -> tb_.get(offset_ + i));
> 3200 #else[byte]
> 3201                         (tb_, __, i)  -> tb_.get(i));
> 3202 #end[byte]
> 
> What if instead of that and other changes we change wrapper method to be:
> 
>    private static $Type$Buffer wrapper(byte[] a, int offset,
>                                        ByteOrder bo) { #if[byte]
>        return ByteBuffer.wrap(a, offset, a.length - offset)
>            .order(bo).slice();
> #else[byte]
>        return ByteBuffer.wrap(a, offset, a.length - offset)
>            .order(bo).as$Type$Buffer(); #end[byte]
>    }
> 
> ?
> 
> If correct that should be the only required change to this file.
> 
> In fact a better change would be for the byte into/fromByteArray to defer to the into/fromArray.  Perhaps a larger change than you are willing to make for this fix?
> 
> Paul. 
> 
> 
> 
> 
>> On Apr 16, 2020, at 5:20 PM, Viswanathan, Sandhya <sandhya.viswanathan at intel.com> wrote:
>> 
>> Please find below a webrev which adds tests for fromByteArray and intoByteArray methods.
>> The webrev also fixes issues found in the ByteArray API implementation.
>> 
>> http://cr.openjdk.java.net/~sviswanathan/vectorIntrinsics/ByteArray/we
>> brev.00/
>> 
>> Best Regards,
>> Sandhya
> 



More information about the panama-dev mailing list