JEP: 145
Title: Cache Compiled Code
Author: Tom Rodriguez
Organization: Oracle
Created: 2011/11/8
Type: Feature
State: Candidate
Exposure: Open
Component: vm/--
Scope: Impl
Discussion: hotspot dash dev at openjdk dot java dot net
Start: 2012/Q1
Effort: M
Duration: M
Template: 1.0
Internal-refs: Oracle:A360:696528
Endorsed-by: Mikael Vidstedt


Summary
-------

Save and reuse compiled native code from previous runs in order to
improve the startup time of large Java applications.


Non-Goals
---------

This will not provide an explicit or exposed library-like mechanism for
saving and restoring code.  For the most part this should be a black box
to the user, though controls over the size and location of the cache may
be provided.


Success Metrics
---------------

Improved startup time for large, complex Java applications.  Limited
impact on peak performance.


Motivation
----------

JIT compilers are fast but Java programs can become so large that it
takes a long time for the JVM to warm up completely.  Additionally, code
that is infrequently used might never be compiled at all.


Description
-----------

The initial goal is to keep compiled code from previous runs to be reused
by later runs.  For the most part this should be transparent to users of
the JVM.  Controls of the cache size and the location are disk will
probably have to be provided.

There are possible synergies with the forthcoming module system in terms
of managing the location of the cache on disk and validating that the
code and the classes still match.  The details of that remain to be
worked out.

Tiered compilation is coming as the default which makes this slightly
more complex.  Tiered compilation generates several different versions of
native code, so multiple copies will have to be kept if we want to get
the most benefit.

The server compiler also incorporates lots of profile information which
in practice may vary from run to run, so the ability to fall back to
local compiles when profiles appear to be inconsistent will be needed.


Alternatives
------------

The saving of profiles or compilation decisions have been discussed but
that does nothing to alleviate the time actually spent in the compiled
code.  It's possible that saving a very late copy of the low-level IR
could be done instead but that seems no less complex.


Testing
-------

Testing will have to done against JVMs running cached code in addition to
normal configurations.


Risks and Assumptions
---------------------

It's possible that the reuse of code could result is slightly less than
optimal code being used, resulting in a loss of performance.  Hopefully
this can be avoided but there are tradeoffs between the ability to reuse
code and the optimal code for each case.


Dependences
-----------

This project doesn't definitely depend on the module-system project at
this point but that could change as both projects move forward.