Kotlin pointer-only FFI experiment

[bendk]

We've been discussing an "FFI v2" for a few months now with an eye towards better performance on non-C languages, like Kotlin, Python, and external JS bindings. Performance was the main goal, but we also speculated that it might improve stability on Kotlin by side-stepping some JNA issues (either in JNA itself or how we're using JNA).

However, we've recently started noticing a lot of Android crashes, especially when using the newer async code. There's also #2740. Before we implement the FFI v2, we should probably try to address the stability issues first. That way we can design the FFI v2 around the same principles and have good confidence that it will also improve stability. We should putting in a lot of work to implement a new FFI that's shiny and fast, but still has stability issues on Kotlin

As a starting point, I'd like to experiment with a pointer-only FFI. Pointers seem like one of the safer types to pass with JNA since they're always exactly 1 machine word. We can use them as a buffer to pack in other value types. Here's what I'm thinking:

• Rename the scaffolding-ffi-buffer-fns feature ffi-pointer and use that for the user function scaffolding on Kotlin. scaffolding-ffi-buffer-fns was an experiment at a new FFI that was never adopted, but it seems great for this purpose. I think ffi-pointer is a nicer name it has the same form as ffi-v2, which is the feature flag I'm hoping to use for the later one.
• Implement other functions, like rust_buffer_alloc using the pointer FFI.
• Prefix all the new FFI functions with uniffi_pointer_.

We probably shouldn't merge or release this code since the goal is experimentation. Instead we can create a branch off of 0.27.3, update the Firefox Android/application-services code to use that branch, then monitor our crash reports. We can also re-introduce our async viaduct code, which we had to back out last time because of crashes, and see if it's better with this new system. If this doesn't address crashes, then I guess we're back to the drawing board. Hopefully we learn something at least.

If other teams also want to test out this code, that's great. I'm not sure how hard it would be to rebase the changes on top of a different version, but it should be doable.

[ncalexan]

Speaking for Firefox for Android, this seems like a sensible path forward. In particular, I strongly support point b) here, namely moving away from JNA.

However, I have a concern. Experimentation that helps us understand the path to using the JNI directly is also valuable, and it seems like this -- only pointers and potentially bit-packing -- doesn't lend itself to a direct JNI future. Is that not a reasonable concern?

[bendk]

I'm definitely for moving away from JNA and towards JNI. I'm just trying to figure out how to break this up into chunks. JNI has some extra complexity, namely we need to generate Kotlin-specific Rust code which will probably require some changes to how we build things. In my perfect world, we'd get there with these steps: Implement the pointer-only FFI -> implement the FFIv2 using JNA -> switch to a JNI implementation. Who knows if that will work out in the real-world, we might need to switch to JNI in order to stop the crashes. Still, I think it's worth it to try sticking with JNA a bit more, but limiting how we use it. If we can do that and avoid crashes, I think it'll make the overall effort easier.

[bendk]

It seems like this -- only pointers and potentially bit-packing -- doesn't lend itself to a direct JNI future.

I should have addressed this in my last comment, but I do believe this helps us move towards a JNI future. Passing arguments using buffers simplifies a lot of the JNI code, since all we need to do is input a buffer and pass it to Rust. For records/enums, it's simpler and faster than managing class definitions and fetching individual fields.

[bendk]

One piece of complexity this doesn't avoid is callback interfaces. For those, we're still going to need to use JNA to adapt JVM methods to be C functions. I don't love this and could easily see this being a source of some crashes. I think we can keep the plan of introducing a smaller change and see how it affects the crash rates. However, it's very possible that the rates won't go down until we switch to JNI.