--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/jep-145.md	Tue Feb 28 16:15:26 2012 -0800
@@ -0,0 +1,102 @@
+JEP: 145
+Title: Cache Compiled Code
+Author: Tom Rodriguez
+Organization: Oracle
+Created: 2011/11/8
+Type: Feature
+State: Posted
+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
+
+
+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.