JEP 194: Nashorn Code Persistence

OwnerJim Laskey
Created2013/12/13 20:00
Updated2014/10/21 20:08
TypeFeature
StatusDraft
Componentcore-libs
ScopeImplementation
Discussionnashorn dash dev at openjdk dot java dot net
EffortM
DurationM
Priority4
Issue8046184

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;

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.

Types of equivalence criteria may include;

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.