Kotlin: Consider using GetStringChars and GetStringUTFChars to avoid string copies over JNI

[Manishearth]

@mihnita did some performance investigation in unicode-org/icu4x#7258, and copying buffers across FFI seems to be a cost.

JNI has GetStringChars and GetStringUTFChars, which produce a null-terminated UTF-16 and UTF-8 string respectively from a JVM String.

There are similar functions for arrays.

Both of these functions may or may not perform a copy (they tell you if they did, via the second outparam). It's unclear how frequent that is in popular JVM implementations.

It's likely these are a faster way to produce a Diplomat slice rather than using diplomat_alloc and manually copying.

Furthermore, there is GetStringCritical, which seems to be more likely to provide a direct pointer, but comes with the restriction of not allowing any JNI code interspersed (which means we cannot call callbacks, or hold on to the returned string past the duration of the current JNI call). This is not so useful for optimizing ICU4X large-string APIs like WordSegmenter (since they take a reference to the data past multiple FFI calls), but it may still be useful to investigate.

cc @jcrist1 @sffc

[Manishearth]

Mihai says that he found to get it faster by using getChars and then working with the primitive array over JNI (https://docs.oracle.com/javase/8/docs/technotes/guides/jni/spec/functions.html#Get_PrimitiveType_ArrayElements_routine).

[Manishearth]

Some performance investigation by @mihnita in #1004 (comment)

[mihnita]

There is something I would still like to test on Android:

• The current Diplomat, as it is today. Because it is slow on desktop, but I don't know on Android. As I said, I still have some problems building :-)
• The ICU4J BreakIterator. As in "bring-your-own" (the one in min_icu4j). What I tested on Android is the OS one, android.icu, not com.ibm.icu. But what it the interesting use case for us is provide functionality that is not already available from the OS. That "bring-your-own-icu4j" would live in the app itself. I don't know if there are no extra checks and price to pay when you call a system component like android.icu

The second should be easy, I just didn't think of that.
The first, I'll figure it out, or I'll ask for help.

[jcrist1]

Would the idea be to conditionally compile with support for a JNIEnv like we do for callbacks? And then create glue code around that? It feels using jni like this we should wrap something around the rust code directly (as part of the procedural macro). But that seems like a difficult architectural change.

Could we do something like

• have a native function that wraps the mentioned functions https://docs.rs/jni/latest/jni/sys/struct.JNINativeInterface_.html#structfield.GetStringUTFChars
• a jvm object that can call that native function
• change the generated code to call this native function to get a pointer and len
• pass a slice to the actual str functions?

[Manishearth]

Would the idea be to conditionally compile with support for a JNIEnv like we do for callbacks? And then create glue code around that?

Yes

Could we do something like

...maybe? We'd need to see the exact perf

It would be ideal if diplomat_runtime did not need to depend on the jni crate.

[mihnita]

Other things I tried: direct buffers.

Java side using ByteBuffer.wrap(byte[] array) looked very promising. Same for CharBuffer.wrap(char[] array)
CharBuffer.wrap(CharSequence csq)

Native side I was hoping to be able to use JNIEnv GetDirectBufferAddress and GetDirectBufferCapacity, hoping to be able to access a Java buffer without allocation.

But GetDirectBufferAddress fails if the Java buffer is not direct. And the wrap methods don't return direct buffers.

So what I tested was:

• Java using wrap (all 3 variants mentioned above) + native copying the buffer
• allocate direct byte buffers in Java + native GetDirectBufferAddress works, but need a conversion from String to bytes java side. I tried using getBytes with UTF-8, UTF-16, UTF-16LE, UTF-16BE.

Both options were slower than String.toCharArray
At least on desktop (I didn't try Android)