On 21/09/15 03:11, Steve Dougherty wrote: > On 09/20/2015 01:14 PM, Florent Daigniere wrote: >> On Sat, 2015-09-19 at 15:25 -0400, Steve Dougherty wrote: >>> Does anyone have benchmarks that demonstrate native acceleration >>> having >>> significant performance improvements? Keeping it around makes for >>> maintenance, and anecdotes suggest native Java performance is >>> sufficient. If it's no longer a clear benefit to have native >>> acceleration I'd like to look into removing it to lower maintenance >>> load. Thoughts? >>> >> Which part of the native code do you propose to get rid of? > Never mind, I was working under the understanding that the native code > was going to cause problems, but contrib master builds without fuss. It is still worth looking at the native code at some point... > For future reference, the native code is: > > * libjcpuid Only needed for jbigi? > * libNativeThread This appears to be necessary for good performance (prevent CPU hogs from slowing down e.g. network traffic handling). In particular it's vital if the CPU is slow e.g. on a Pi; I don't think we have an ARM build in the current jar.
It could be replaced with a more general (third party) library for doing
local system calls (I don't recall the name), which would also be
helpful for setting I/O priorities. See pull requests. It's worth
checking that the JVM still doesn't set niceness for individual threads
on Linux when setting thread priorities. It does do so on Windows, but
scheduling is different...
> * libfec (unused due to segfaults?)
Yes, this appears to have exploitable issues, needs careful review by
somebody who really understands C and JNI. In particular, it segfaults
for some {n,k} parameter pairs, and this was weaponised in a Frost DoS
some years back. However, if it works reliably and safely it could save
a lot of CPU and decode time especially on embedded systems.
> * jbigi
It is possible that this is not necessary on modern OpenJDK.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
