JNI roundtrips definitely do not cost 1ms per trip.
True. I did some benchmarking a while ago, and had that number in my head. Revisiting it now, it seems to be way off - more like 5 nanoseconds with -Xcheck:jni on. Code:
True of course. I just feel like many people had long since taken native off the table because of the burdens of cross platform c/c++ development. But I found Rust+JNI so easy that I think it should be a reasonable tool in every JVM optimization toolbox.
"It costs about a millisecond to do a return trip across the JNI boundary" - Do you have a source on this? Seems unlikely since most system calls would be way too slow if this were true?
> Accessing Java objects from native code is also a pain, with potential performance gotchas (pinning, mostly).
What do you mean by pinning? If you mean pinning threads to cores, how does that relate to JNI?
Probably pinning the object in memory, so that you can keep a stable reference to it without the danger of the GC moving it away under your pointer.
An approach I've seen work is to have dedicated Java and native threads, communicating via shared memory. We have some funky in-house code for this, but I think Aeron [1] should be a good open source option.
[1] https://github.com/real-logic/aeron