Direct Memory API

[mahesh-hegde]

Status Quo:

We map JNI Arrays into a subscript-indexed linear dart type.

I wish JNI memory access is just as simple. But it's full of nuances.

Look at this FAQ on android developers page.

Ideally, there should be ways to utilize the primitives JNI gives us to maximum efficiency.

The idea

Map JNI arrays into implementations corresponding typed_data list interfaces. For example, intArray.getRegion() should return a typed list of int32s.

We also want easier API for manipulating DirectByteBuffer, for reasons outlined in above link.

However, this is not so simple complicated for few reasons.

• We can't implement or extend types like Int32List which clutters the API.

• There are times where region calls are more appropriate and where getArrayElements is more appropriate. Exposing both of these in a coherent API is hard.

We can probably create view classes (eg JIntArrayView), which

• are returned by region calls, getArrayElements calls, and byte-buffer calls.
• Upon mutation, provide an explicit call to write the results back. (flush).
  • Not applicable in case of byte buffer, however. flush could be no-op here.
• Expose an interface similar to typed lists (While we can't subclass them, we can still wrap over their methods).

[mahesh-hegde]

Also interesting: https://developer.android.com/reference/java/nio/CharBuffer

In APIs which accept CharSequence instead of String, this will be useful to pass text data without having to convert it into java string first.

[HosseinYousefi]

Map JNI arrays into implementations corresponding typed_data list interface

Will be closed by #1095.

We also want easier API for manipulating DirectByteBuffer.

This is done #563.

We can probably create view classes

I don't like having to flush and making sure that we release the elements afterwards.

Some Arena.use-esque API that gets a callback which will release resources automatically at the end might be a better design.

All in all, it's not guaranteed that Get<type>ArrayElements allows direct access to the native memory and it might copy it anyways, so providing array.getRange that returns a typed data might just be enough for users.

Closing this.