JEP 145: Cache Compiled Code

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