JEP 194: Nashorn Code Persistence
|Discussion||nashorn dash dev at openjdk dot java dot net|
Cache code so that it can be reused in the same process. This will lead to a reduction in memory usage and start up time.
No attempt will be made to share the cache across processes.
Code memory should be reduced from one unit per invocation to one unit per process.
Nashorn is being used in several server-side applications. There is a concern that the lack of code reuse can affect startup time and memory usage.
Nashorn's existing model is simply to compile on demand. Each thread gets a separate compiler for each compilation. There is no communication across threads or contexts. An attempt is made to cache byte code based upon source URLs, but this is insufficient.
In the proposed model, the initialization of a
include the starting of a
NashornCodeManager (interface). This
NashornCodeManager will be responsible for the fetching of all code
used by an instance of the
NashornScriptEngine. In general, the
NashornCodeManager will take a queued (concurrent)
with a Nashorn
Source and map the
Source to code. Each
NashornCodeManager is responsible for queuing these requests and
issuing responses when the code is available. Code is made available by
searching for existing code or by compiling the request source.
It is conceived that different versions of
NashornCodeManager will be
used, depending upon the application;
NashornSimpleCodeManager(class) duplicates how code is managed in the existing per-thread version of Nashorn. This will be a requirement for non-threading (embedded) versions of the JVM.
NashornSimpleCodeManager) runs in a separate thread and is shared by all threads in the current process. This will be the default for most applications.
NashornCodeManager will also have a
which is searched before attempting to compile the source. It is up to
NashornCodeCache implementation to determine search-equivalence
NashornNullCodeCache(class) always fails, so it can be used when caching should not be done.
NashornNullCodeCache) is an in-memory map from
Sourceto code. This is the default for most applications.
Types of equivalence criteria may include;
Source URL or URL + context base;
Source itself (in case of
eval), in which case testing would be helped by using hash codes;
Range of characters in source (lazy compilation); and
Function signature (optimistic typing).
NashornCodeRequest (class) will be created by the Nashorn runtime
with all information needed to search for code and, if necessary, to
compile the code. This information will include
Source (URL and source
text), runtime context, and compilation context.
NashornCodeResponse (class) will be created by the
NashornCodeManager with all information necessary to execute the code
(class and method.) A
NashornCodeResponse may include an error
condition indicating that compilation failed or code was no available.