Advice of how to implement ahead of time compilation.

[Steve Bohne]

Hi Ramón,

Ramón García wrote:
> 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.

First you'd have to extend class data sharing to cache compiled system 
code, which it doesn't do.  (Maybe that was already implied in what you 
wrote.)

FWIW, a while back we did some internal experiments to determine the 
benefit of caching compiled code for client/desktop type applications. 
At the time there wasn't much benefit.  The consensus explanation was 
that the HotSpot client compiler is actually very fast to compile code, 
and the initial interpreter + compilation overhead doesn't cost all that 
much for real applications.

That is not to say that a well optimized AOT scheme couldn't have 
benefit - just some anecdotal evidence.

> 
> - 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.

It seems like the first option would be easier to port and maintain. 
The class data sharing archive file format is the same across all 
platforms we support, while shared libraries aren't.

Steve

> 
> 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