JEP 194: Nashorn Code PersistenceJEP 194: Nashorn Code PersistenceOwnerJim LaskeyTypeFeatureScopeImplementationStatusClosed / WithdrawnComponentcore-libsDiscussionnashorn dash dev at openjdk dot java dot netEffortMDurationMCreated2013/12/13 20:00Updated2015/01/06 20:02Issue8046184Summary
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.
InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
