JEP 194: Nashorn Code Persistence

Summary

Enhance Nashorn to cache and re-use the byte code produced for repeatedly-encountered JavaScript fragments.

Goals

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.

Non-Goals

No attempt will be made to share the cache across processes.

Success Metrics

Code memory should be reduced from one unit per invocation to one unit per process.

Motivation

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.

Description

Existing Model

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.

NashornCodeManager

In the proposed model, the initialization of a NashornScriptEngine will 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) NashornCodeRequest 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.

• NashornSharedCodeManager (subclass of NashornSimpleCodeManager) runs in a separate thread and is shared by all threads in the current process. This will be the default for most applications.

NashornCodeCache

Each NashornCodeManager will also have a NashornCodeCache (interface) which is searched before attempting to compile the source. It is up to the NashornCodeCache implementation to determine search-equivalence criteria.

• NashornNullCodeCache (class) always fails, so it can be used when caching should not be done.

• NashornSharedCodeCache (subclass of NashornNullCodeCache) is an in-memory map from Source to 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

A 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

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