changeset 54:a16daa94ba0f

145: Cache Compiled Code
author mr
date Tue, 28 Feb 2012 16:15:26 -0800
parents e70418c772da
children 6522876c0e78
diffstat 1 files changed, 102 insertions(+), 0 deletions(-) [+]
line wrap: on
line diff
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/	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
+Save and reuse compiled native code from previous runs in order to
+improve the startup time of large Java applications.
+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.
+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.
+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.
+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 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.
+This project doesn't definitely depend on the module-system project at
+this point but that could change as both projects move forward.