4 ms·

If you're getting to this level of optimization, you could just consider going native. Making a shared lib in Rust that uses JNI and does everything you could d

If you're getting to this level of optimization, you could just consider going native. Making a shared lib in Rust that uses JNI and does everything you could do in Java is really really easy.

twic 9y ago
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 https://github.com/real-logic/aeron
- wging 9y ago
  > 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?
  - bennofs 9y ago
    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.
  - lamansion 9y ago
    Do some research on GC locker.
- kodablah 9y ago
  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.
- badlogic 9y ago
  JNI roundtrips definitely do not cost 1ms per trip.
  - twic 9y ago
    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 https://github.com/tomwhoiscontrary/jni-bench
- raz32dust 9y ago
  "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?
maaaats 9y ago
Not necessarily true that native would be faster than jit optimized code, though.
- kodablah 9y ago
  True, it's just an option with possible downsides. Just seems to go unmentioned often.

If you're getting to this level of optimization, you could just consider going native. Making a shared lib in Rust that uses JNI and does everything you could do in Java is really really easy.

twic 9y ago

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 https://github.com/real-logic/aeron

wging 9y ago
> 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?
- bennofs 9y ago
  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.
- lamansion 9y ago
  Do some research on GC locker.
kodablah 9y ago
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.
badlogic 9y ago
JNI roundtrips definitely do not cost 1ms per trip.
- twic 9y ago
  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 https://github.com/tomwhoiscontrary/jni-bench
raz32dust 9y ago
"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?

maaaats 9y ago

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

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