JEP 295 AOT: Objects compiled multiple times

Question

I am trying to compile an application server with JDK9's new AOT feature, and am facing a number of challenges.

The appserver consists of ~180 MB jars; compiling that together overflows integer so I've tried to compile each module to one (.so) library. These modules have dependencies on other modules, so I had to put them on classpath using -J-cp -Jdependencies. This has resulted in 4.4 GB of libs - as AOT is supposed to speed up server boot, you can imagine that loading this from the disk does not really help. (It is possible to strip those libraries of their debug info, but we're still talking about an order of scale growth compared to the jars.)

I was rather disappointed that jaotc actually class-loads compiled classes, which triggers static constructors (and this gives me errors at times). Also, the compiler cannot handle missing referenced classes, and sometimes this is just a runtime-dependency - the server operates without issues even without them. So I had to provide empty mock classes to satisfy the compiler.

However, when running the server with AOT tracing (-Xlog:aot+class+load=trace:file=/tmp/aot.txt:none, not the stdout -XX:+PrintAOT) I have found that the libs contain some part of the dependencies as well:

found  java.lang.Object  in  /home/user/aot/common/libjava.base-coop.so for classloader 0x2b5745e6ac80 tid=0x00002b574401e800
found  java.lang.Object  in  /home/user/aot/appserver/lib/libcom.example.module1.so for classloader 0x2b5745e6ac80 tid=0x00002b574401e800
found  java.lang.Object  in  /home/user/aot/appserver/lib/libcom.example.module2.so for classloader 0x2b5745e6ac80 tid=0x00002b574401e800

This confirmed my doubts that the lib contains more than just the code from the jars I gave the compiler to compile but at the very least the code for the superclasses as well. I am also unsure how the JVM behaves when it finds the same class in multiple libs.

Is it possible to strip the duplicities? What's the recommended approach to big/multi-lib projects?

Joo

Do you know about the Jet compiler excelsiorjet.com ? In our company, we are using it for years now, and it never rose any compatibility issue. – Dithyramb

Yep, I've read about that on wiki. However, I am specifically trying to test JDK's capabilities on this app server. Besides, non-opensource is a blocker. – Joo

It sounds like you didn't do a training run to get the list of "touched" methods to compile. A nice blog that documents experiences with AOT and details on how to get the list of touched methods can be found here: mjg123.github.io/2017/10/02/JVM-startup.html – Micaelamicah

No, I did not; I wanted to start with fully-compiled variant first. After all, if I didn't care about disk usage I would let everything in and JVM could pick what it needs from the libs. I'll try to grab a run using jcmd VM.print_touched_methods (I have already tried compiling all loaded classes which gave me 600 MB single lib, and no difference on startup time). – Joo

Anyway, my question was about avoiding duplicities; or is single-fat-lib the only reasonable option? – Joo

It's a bit of a stretch to refer to "JDK9's new AOT feature" since your first link bluntly states: "AOT compilation of any JDK modules, classes, or of user code, is experimental and not supported in JDK 9". I'm sure you already knew that, and it doesn't invalidate your post in the least, but it is worth bearing in mind. – Complect

@Complect Yes, I know it's experimental. That does not disqualify that as a feature. And since there's little documentation about that but the JEP page, I am looking for someone who knows how this is intended to be used. – Joo

Answer 1

This feature has been removed by JEP410. Code related to AOT are mostly removed in JDK 17, you should not be using this feature. If you still want this feature, you may consider to use GraalVM.

Cootie

Correct - see that this question was asked 4 years, 7 months ago . – Joo