Due to the way each Japex driver is contained in it's own classloader it is not
always possible to create benchmarks that rely on native code.
The main problem is that the running of different drivers can result in multiple
calls to System.loadLibrary().
Japex should be able to support the following benchmark scenarios that involve
- Benchmarks that compare Java implementations that share the same native code.
- Benchmarks that compare Java implementations that contain different native
When benchmarking drivers that share the same native code you have to ensure
that System.loadLibrary() is not called multiple times in the same JVM instance.
Similarly for running tests that use different versions of a library you will
need to use a different JVM if the shared library has the same name.
The former case could be solved by having a hook in the Japex runtime that
allows you to customize the JapexClassLoader to ensure that the native library
is only loaded once but this assumes that you have control over the native
library which is not always the case: for example your benchmark could rely on a
3rd party Java library that internally calls System.loadLibrary(). Having such a
hook would not also work for the 2nd case where you want to test different
version of the same native library together.
One mechanism that could help here is if Japex supported the following:
- A japex.libraryPath property that can be set per driver instance.
- An attribute on the driver called 'fork' that would fork a new JVM.
Even if the native library could be shared across drivers, you probably still
want complete isolation to ensure micro-benchmarks are fair, so forking should
probably the recommended solution for any kind of tests that involve a native