Second JNI extension for flattened arrays
maurizio.cimadamore at oracle.com
Wed Dec 18 23:51:47 UTC 2019
It's nice to see how Panama and Valhalla are trying to get at the same
result from opposite directions; in Panama, the layout API allows you to
define what you call a 'selector', from which you can then obtain a var
handle which - given a base pointer (and and one or more indices) allows
you to retrieve the desired element.
What you are doing here is kind of similar, (i) by allowing clients to
create 'selectors' and then (ii) to have API points which accept such
selectors and perform the extraction for you.
Part of me is thinking if these two approaches (the Panama way and the
Valhalla/JNI way) shouldn't share more - e.g. I wonder if we could
implement some of the primitives you have exposed using the Panama
memory access API - so that the selector could just be an opaque object
(which wraps some Panama layout + some var handle) and when you do a
get/set using a selector, you basically just end up calling the var
handle with the right type.
Perhaps not worth thinking about now, but maybe something to keep in the
back of our minds.
On 17/12/2019 16:37, Frederic Parain wrote:
> This proposal of a new JNI extension tries to avoid this burden by defining
> the notion of sub-element and sub-element selector.
> A sub-element represents either a whole element of a flattened array, or a
> field stored in an element of a flattened array. A sub-element can be at
> any level of nesting: if the array element includes flattened fields which
> themselves include flattened field, any field of any of these flattened
> fields is a sub-element. Any kind of field is a sub-element: primitive
> fields, reference fields, or flattened fields.
More information about the valhalla-dev