Native image fork support
Jonas Konrad
me at yawk.at
Fri Sep 22 09:49:38 UTC 2023
Hi,
I was wondering if anyone has made an effort to integrate native image
more closely with JMH, in particular by supporting fork.
I've talked to the native image team here at Oracle and they had some
interesting insights. It is apparently already possible to run JMH
without forking. However, unlike JIT JVMs, other test methods that
aren't even run may affect the performance of the benchmark under test
if native image can't determine they're dead code. For this reason, the
NI team has special support at the build tool level to produce a
separate native image for each benchmark method (AIUI). This means they
haven't implemented this in JMH.
However I still think it would be worthwhile to support forking at the
JMH level too. In particular, right now I am working on a startup
benchmark (10-1000ms range) that requires forking to capture method
handle initialization performance and thus produce accurate results. For
this case using JMH infrastructure to fork would be more convenient but
should still produce good enough results.
My idea is to modify the Runner to support a native image "JVM" option.
This option would instead of the standard `java -cp ... ForkedMain` just
use the native image directly. The native image would have to be
generated with the ForkedMain as the entry point. That means the build
tools need to produce the normal jar (for the JMH server) and a single
native image only, which is fairly simple to do.
Now I'm wondering if anyone has tried this before, or has other concerns
when it comes to accuracy. For example, I suspect the false sharing
prevention might not work since native image can determine the fields
are not used.
- Jonas
More information about the jmh-dev
mailing list