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