[vector] Intrinsics for fromByteArray, fromByteBuffer, intoByteArray, intoByteBuffer

[Lupusoru, Razvan A]

Hi Al,

I am not quite certain of the answer to your question but I’d like to explain why that node is used in implementation.

Basically, VectorReinterpretNode is intended to allow “type conversion” of vectors while keeping contents unmodified. It also allows for compiler to keep track of appropriate types. It does not have anything to do with whether an access is on heap or off heap.

So let us say we have a node of TypeVect “#vectory[8]:{float}”. Since when using ByteBuffer and byte arrays we explicitly check that we have a byte array, we mark that the “address” of the array is of type “@byte[int:>=0]:exact+any *”. Thus the VectorReinterpret node is used as a transition node to convert from “#vectory[8]:{float}” to type “#vectory[32]:{byte}”. Thus now we have checkable strong typing in place where we do not mix and allow store to memory that does not match the type of what we are storing.

I am not very familiar with the type of unsafe memory and whether compiler will complain if your vector type is not consistent with your memory type. My guess is that there is special marking used for unsafe accesses - and thus it would seem to me that VectorReinterpret node is not necessarily needed. That said, the node itself does not add any overheads (as long as input and output type have same size), and thus it’s not a problem to keep it.

Hopefully my answer is somewhat helpful in answering your question.

Thanks,
Razvan

From: Al K [mailto:someusername3 at gmail.com]
Sent: Monday, May 07, 2018 12:51 PM
To: Lupusoru, Razvan A <razvan.a.lupusoru at intel.com>
Cc: Paul Sandoz <paul.sandoz at oracle.com>; John Rose <john.r.rose at oracle.com>; panama-dev at openjdk.java.net
Subject: Re: [vector] Intrinsics for fromByteArray, fromByteBuffer, intoByteArray, intoByteBuffer

Is VectorReinterpretNode required when loading from/storing to off-heap buffer? Wondering
if it's sufficient enough to just invoke make_unsafe_address() with the base and offset, and
continue on, or if there's more complications associated with it.

On Fri, May 4, 2018 at 1:54 PM, Lupusoru, Razvan A <razvan.a.lupusoru at intel.com<mailto:razvan.a.lupusoru at intel.com>> wrote:
Paul and John,

I just merged the patch with the following changes which stemmed from your discussion:

-          No longer allow writing to a read only buffer

-          No longer intrinsify if bytebuffer endianness does not match native order

o   There is no silent conversion taking place.

Thanks for your reviews in finding the various issues. I agree that a worthy improvement would be to allow writing to buffers that do not have backing array by using the Unsafe mechanism you recommended.

Thanks!

--Razvan

From: Paul Sandoz [mailto:paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>]
Sent: Thursday, May 03, 2018 8:52 AM
To: John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>>
Cc: Lupusoru, Razvan A <razvan.a.lupusoru at intel.com<mailto:razvan.a.lupusoru at intel.com>>; panama-dev at openjdk.java.net<mailto:panama-dev at openjdk.java.net>
Subject: Re: [vector] Intrinsics for fromByteArray, fromByteBuffer, intoByteArray, intoByteBuffer



On May 3, 2018, at 8:48 AM, John Rose <john.r.rose at oracle.com<mailto:john.r.rose at oracle.com><mailto:john.r.rose at oracle.com<mailto:john.r.rose at oracle.com>>> wrote:

On May 3, 2018, at 8:40 AM, Paul Sandoz <paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com><mailto:paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>>> wrote:

stick to native endianness for the moment to keep things simpler initially

I suggest throwing an exception if the buffer is in the wrong endianness.
We have regretted silently converting to native on other occasions.

A good point, it will remind us to fix it and revisit the specification. I will add placeholder in the load/store tests.

Paul.