Second JNI extension for flattened arrays

Maurizio Cimadamore maurizio.cimadamore at
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 mailing list