Question: JNA vs JNR
bturner opened this issue · comments
I'm curious if you've considered converting from JNA to JNR (specifically jnr-ffi).
In evaluating NuProcess, we've been comparing it with (defunct?, but functional) jnr-process. jnr-process is not a very good option for us, given the project appears to be dead now, but in benchmarking the two solutions we've found that JNR appears to be significantly more memory-efficient than JNA. I've opened #80 with some optimizations that cut down on JNA-induced allocation churn, but switching to JNR might offer an even bigger improvement.
I'm not proposing anything, to be clear, or asking for any changes. I'm just interested in whether you've ever considered JNR.
@bturner Yes, in fact. I was discussing this with @lfbayer a month or so ago. I used JNR in a recent library that I created to do non-blocking native ICMP ping supporting thousands of targets.
Following that experience, I was discussing its (possible) use in NuProcess. Having said that, it still appears to create a fair amount of garbage as a side-effect.
One concern I would have is the impact on users of the switch from JNA to JNR. Not only is it a change, but users often already have other dependencies on JNA, so the addition of JNR would bloat their deployment. Facebook's buck is one example that is very size-conscious as their binary is basically the union of all dependent JARs, and their executable is already sitting at ~80MB.
@bturner Having said that, if you want to make a spike implementation on a jnr branch, it would likely be pretty trivial, as the number of native methods and structures is low (epoll_ctl, epoll_wait, read, write). And to back-track a bit on JNR memory usage, it creates garbage if used naively -- in the case of jnb-ping, because of some constraints that I imposed (single worker thread) I was able to get down to near zero allocations by reusing structures and buffers. So the possibility of benefits are there...
The factory option would be much appreciated.
@hc-codersatlas The memory and performance issues that might have been solved by an upgrade to JNR have been fixed. There is no reason to believe that JNR would provide a performance advantage, neither with respect to memory nor CPU consumption. Adding a second implementation, upon further review, would only serve to complicate the code and increase the surface area for bugs.
The original problem that resulted in this issue (memory consumption) has been fixed.