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.