3 ms·
This is incorrect. Native calls whether it's via JNI (even with CriticalJNINatives) or Panama still have a transition cost formerly referred to as gc locker. I'
by bitcharmer 3y ago
This is incorrect. Native calls whether it's via JNI (even with CriticalJNINatives) or Panama still have a transition cost formerly referred to as gc locker. I'm in a field where performance is number one requirement. Removing unsafe is a terrible idea.
- _w1tm 3y ago> I'm in a field where performance is number one requirement. Removing unsafe is a terrible idea. Are you sure you should be using Java if your use-case is performance sensitive?
- iscoelho 3y agoJava today is used and works fine for many high performance applications.
- bitcharmer 3y agoYes, I have no doubt about it. You might be stuck in 1990s perception of Java like a good portion of HN commenters who haven't had any real experience with it in the last 10-20 years.
- kaba0 3y agoYes they have, but you can always just go a “scope” higher, and instead of doing a loop that calls out to FFI, you call out to a loop itself.
- bitcharmer 3y agoYou mean expedite whole chunks of logic to a different language, then make your build process much more complicated by having to maintain a completely new ecosystem and compiler infrastructure and make testing more cumbersome? Sorry, but this is just a bad advice.
- kaba0 3y agoIn the very very rare case you might need it, than I guess, yeah. But if it turns out to be a real problem, it might still be possible that they will add a way to disable checks with the foreign memory API. It would actually allow for a better user experience, you could do “debug” builds with extensive checking for correctness, which could be disabled via some flag.
- needusername 3y agoYou forgot that the deployment also got more complicated.