[vectorIntrinsics] ByteArray tests and fix

Viswanathan, Sandhya sandhya.viswanathan at intel.com
Fri Apr 24 20:17:46 UTC 2020


Hi Paul,

Please find below the updated webrev:
http://cr.openjdk.java.net/~sviswanathan/vectorIntrinsics/ByteArray/webrev.02/

I have added the masked ByteArray load tests. Also added ByteOrder to toByteArray. 
Added a placeholder fix for the crash that I was observing when I invoke jtreg with -avm.

Let me know if this looks good to you.

I am assuming that you will look into modifying the intoByteArray API separately.

Best Regards,
Sandhya

-----Original Message-----
From: Paul Sandoz <paul.sandoz at oracle.com> 
Sent: Friday, April 24, 2020 9:12 AM
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

Hi,

So you dropped testing of the masked fromByteArray and that resolved your crash?

I just noticed the toByteArray is using native byte order but the tests using little endian order, I think we need to be consistent even though unlikely to fail given the current supported architectures: 

 230     static byte[] toByteArray($type$[] a, IntFunction<byte[]> fb) {
 231         byte[] b = fb.apply(a.length * SPECIES.elementSize() / 8);
 232 #if[byte]
 233         $Type$Buffer bb = ByteBuffer.wrap(b, 0, b.length).order(ByteOrder.nativeOrder());
 234 #else[byte]
 235         $Type$Buffer bb = ByteBuffer.wrap(b, 0, b.length).order(ByteOrder.nativeOrder()).as$Type$Buffer();
 236 #end[byte]
 237         for ($type$ v : a) {
 238             bb.put(v);
 239         }
 240         return b;
 241     }

We are also missing a non-masked version of intoByteArray that accepts a ByteOrder argument, which is likely the reason why you are selecting little endian order.  Shall we add that method?
  
Paul.

> On Apr 23, 2020, at 7:50 PM, Viswanathan, Sandhya <sandhya.viswanathan at intel.com> wrote:
> 
> Hi Paul,
> 
> Please find below updated webrev with the changes you suggested. I also simplified the masked ByteArray tests.
> The tests all pass successfully.
> 
> http://cr.openjdk.java.net/~sviswanathan/vectorIntrinsics/ByteArray/webrev.02/
> 
> 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