renaissance
renaissance copied to clipboard
renaissance-benchmarks
Plugin support in AOT compiled benchmarks
At this time, we cannot use plugins with AOT compiled benchmarks - the harness uses URLClassLoader to get the plugin code from the JAR, with AOT compilation the class collection agent sees this and includes the class in the compilation config, however, such classes are only available in AOT binaries through Class.forName, so the call to URLClassLoader in the AOT binary will fail.
A simple hack would be to attempt Class.forName if URLClassLoader fails - in the JIT run with the agent, the JAR would be located correctly and loaded normally, and in the AOT run, the backup loading mechanism should get the plugin instead ?
Status update. The above description was misleading where it stated that "such (dynamically loaded) classes are only available in AOT binaries through Class.forName". The native image runtime is willing to "load" classes when they were compiled into the native executable. Because URLClassLoader` will eventually invoke this machinery, the plugin class should load just fine if it were compiled into the native executable. The problem is that the native image compilation process is not aware of the location of the plugin JAR and therefore does not include the plugin class in the native executable, even though the native image configuration agent lists the class as needed.
Now looking at (1) whether it is possible to tell mx benchmark to include a class path argument to native-image, or (2) whether we can use the predefined classes support to capture the class bytecode through the agent and avoid the need for the class path argument. Either option would resolve the issue when using mx benchmark and no change to Renaissance would be needed.
When not going through mx benchmark, it is enough to add -cp plugin.jar to native-image to make things work.
@farquet Maybe you know answers to the above two points immediately ? :-)
I would recommend going for 1, since mx benchmark already does plenty of command line building. There is a place in the command line to feed JVM options, I assume extra jars to add to the classpath could go in the same location. However, it will likely require some small modifications to mx benchmark to whitelist this flag and propagate it correctly when calling native-image.
