Advice of how to implement ahead of time compilation.

Ramón García ramon.garcia.f+java at gmail.com
Wed Dec 26 10:42:15 PST 2007


Hello,

I am interested in implementing ahead of time compilation. Testing
with Mono (a free .NET implementation) I see that ahead of time
compilation greatly improves startup time, turning about 0.7 s of a
compilation (equivalent to javac) into 0.08 s. Therefore, I think that
it would be useful to have this option for interactive applications,
that could be compiled to native during installation, and then
executed directly. This would not harm the cross platform nature of
Java, because applications would be still distributed in bytecode
format.

I need advice about what path should I follow.

- One way would be to extend the current support of class data sharing
to user supplied code, so that the virtual machine could load several
data sharing archives, one for the system classes, and another for the
current application.

- An alternative method, the virtual machine would load a shared
library containing the compiled application code. Tools must be
provided to compile a collection of classes (and JARS) into a shared
library, where all internal references are resolved.

I see that unit of compilation must be the classloader, that is,
classes intended to be loaded in the same classloader should be
compiled together. Otherwise, it would be incorrect to compile a call
to a class into a concrete call, because one cannot know if the class
referenced will be overridden by some other class earlier in the
classpath; and it seems that linking is an important part of compiling
time. In fact, the JSR 294 of Java Superpackages subtitle says
"Language extensions in support of information hiding and separate
compilation". I understand that the mechanism of superpackages, by
modifying the access rules, allow one class to be compiled knowing
which concrete classes is referenced, and thus make it possible ahead
of time compilation of the superpackage into a shared library.

Ramon



More information about the hotspot-runtime-dev mailing list