Careful, though. It costs about a millisecond to do a return trip across the JNI boundary, so don't do that anywhere near an inner loop. Accessing Java objects from native code is also a pain, with potential performance gotchas (pinning, mostly).

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

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:

https://github.com/tomwhoiscontrary/jni-bench

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.

Do some research on GC locker.

Not necessarily true that native would be faster than jit optimized code, though.

True, it's just an option with possible downsides. Just seems to go unmentioned often.