-
Enhancement
-
Resolution: Fixed
-
P2
-
9
-
b22
-
generic
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8064141 | 8u45 | Attila Szegedi | P2 | Resolved | Fixed | b01 |
JDK-8055608 | 8u40 | Attila Szegedi | P2 | Closed | Fixed | b04 |
JDK-8070378 | emb-8u47 | Attila Szegedi | P2 | Resolved | Fixed | team |
Whenever a JS function is undergoing optimistic compilation, we'll start from the most optimistic code version and gradually deoptimize it. (It's more precise to say we're doing this for every function parameter type specialization) This adds a considerable warmup time, as we generate a large number of Java classes just to discard them almost immediately. By persisting the deoptimization information (type information at deoptimizable program points in the function), a subsequent invocation of the JVM could read this information and immediately compile the last known, already partially deoptimized, steady-state code version.
Of course, we must decide where to store the persisted files. A directory for the files should be within a platform-specific cache location. On Mac, this is ~/Library/Caches/. On Windows, it is %LOCALAPPDATA%\. On all other platforms, it's ~/.cache/.
Within the platform-specific cache directory, we create com.oracle.java.NashornTypeInfo directory. This is consistent with other uses, e.g. com.oracle.java.Java-Updater is an already existing entry in cache directory where Java is installed.
Finally, within this directory we create another directory specific to the version of the nashorn code. By default, this is done by taking the URL-safe Base64 encoding of the SHA-1 of the "nashorn.jar" file. This way, any binary change in nashorn.jar will cause it to create a fresh cache, therefore we don't need to worry about type information becoming invalid between changes to the Nashorn's code.
A separate issue will be raised with a feature for periodically pruning the cache directory.
Of course, we must decide where to store the persisted files. A directory for the files should be within a platform-specific cache location. On Mac, this is ~/Library/Caches/. On Windows, it is %LOCALAPPDATA%\. On all other platforms, it's ~/.cache/.
Within the platform-specific cache directory, we create com.oracle.java.NashornTypeInfo directory. This is consistent with other uses, e.g. com.oracle.java.Java-Updater is an already existing entry in cache directory where Java is installed.
Finally, within this directory we create another directory specific to the version of the nashorn code. By default, this is done by taking the URL-safe Base64 encoding of the SHA-1 of the "nashorn.jar" file. This way, any binary change in nashorn.jar will cause it to create a fresh cache, therefore we don't need to worry about type information becoming invalid between changes to the Nashorn's code.
A separate issue will be raised with a feature for periodically pruning the cache directory.
- backported by
-
JDK-8064141 Deoptimization type information peristence
-
- Resolved
-
-
JDK-8070378 Deoptimization type information peristence
-
- Resolved
-
-
JDK-8055608 Deoptimization type information peristence
-
- Closed
-
- relates to
-
JDK-8050494 OptimisticTypesPersistence should use java.util.Date, not java.sql.Date
-
- Closed
-
-
JDK-8048009 Type info caching accidentally defeated
-
- Resolved
-
-
JDK-8062386 Different versions of nashorn use same code cache directory
-
- Resolved
-
-
JDK-8062384 Code cache was saved in current directory
-
- Closed
-
(2 relates to)