title: JEP 295 AOT: Objects compiled multiple times
body: <p>I am trying to compile an application server with <a href="http://openjdk.java.net/jeps/295" rel="nofollow noreferrer">JDK9's new AOT</a> feature, and am facing a number of challenges.</p>
  <p>The appserver consists of ~180 MB jars; compiling that together <a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8188099" rel="nofollow noreferrer">overflows integer</a> 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 <code>-J-cp -J</code><em>dependencies</em>. 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.)</p>
  <p>I was rather disappointed that <code>jaotc</code> 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.</p>
  <p>However, when running the server with AOT tracing (<code>-Xlog:aot+class+load=trace:file=/tmp/aot.txt:none</code>, not the stdout <code>-XX:+PrintAOT</code>) I have found that the libs contain some part of the dependencies as well:</p>
  <pre><code>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
  </code></pre>
  <p>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.</p>
  <p>Is it possible to strip the duplicities? What's the recommended approach to big/multi-lib projects?</p>