Can you use jaotc (Java Ahead-of-Time Compiler) with jlink (module assembler/optimizer to create runtime images)?

Question

The goal here is to:

1. Create a runtime image that has it's own stripped down JRE (minimize size) - this is what jlink gives us

2. Create natively executable libraries instead of using byte code (improve load times and hopefully remove the need to obfuscate) - this is what jaotc gives us

However, there isn't any good documentation that correlates the two. There seems to be a lot of contradictory ways to do things with these two flows.

Is it possible to build a runtime image with jlink that uses jaotc generated binaries?

Answer 1

Not really. Neither JEP-295 (jaotc) mentions jlink, nor JEP-282 (jlink) mentions jaotc.

However, because jlink just produces a stripped-down JRE (but it's still a JRE!) with your application code, it's possible to tell it to use the AOT-ed libraries you want.

I decided to follow the procedure to generate a native AOT lib for the java.base module as described in JEP-295, then changed the jlink-generated launcher at bin/my-app by setting the JLINK_VM_OPTIONS as follows:

JLINK_VM_OPTIONS=-XX:AOTLibrary=./libjava.base-coop.so

I then ran my launcher with time bin/my-app, which makes a HTTP request against a server on localhost (to avoid network latency), then prints the full HTTP response.

It takes around 410ms with AOT, and 210ms without it!

To confirm AOT was being picked up correctly, I added some diagnostic flags:

JLINK_VM_OPTIONS="-XX:+UnlockDiagnosticVMOptions -XX:AOTLibrary=./libjava.base-coop.so -XX:+UseAOTStrictLoading"

It did not show any errors or warnings, hence I believe I did not make some kind of mistake that could have skewed the results.

In conclusion, at least in my case, mixing jlink and jaotc does not seem to have a positive impact, but notice that in the jaotc JEP they do say that:

AOT compilation of any JDK modules, classes, or of user code,
is experimental and not supported in JDK 9

So, I would say it's too early (May 2018 as of writing) to pass judgement on this... let's give them time to perfect this mechanism and hope they can achieve more improvements.

For now, a more promising way to speed up your applications may be to use the GraalVM and its native-image command.