Using Compile Stashing
|
Note
|
Compile Stashing is deprecated since Zing 25.02. The feature remains functional and supported, and Zing prints a deprecation warning at startup when you set any Compile Stashing command-line option. Compile Stashing is expected to be removed in a future release, so avoid adopting it in new deployments. To reuse previously performed compilations in a supported way, use Cloud Native Compiler, which retains them in its server-side Code Cache, with Compilation Streaming to serve them to your JVMs at startup. |
Compile Stashing is an Azul Zing Builds of OpenJDK (Zing) feature that caches compilations performed in one run and reuses them in subsequent runs. Compile Stashing used with ReadyNow has mixed results but has been shown to significantly reduce compiler start time and CPU usage in some cases.
|
Note
|
Compile Stashing has been disabled by default since 23.01, even when using ReadyNow. Existing ReadyNow users that want to maintain the same compile stashing behavior as in earlier releases should ensure the -XX:+FalconUseCompileStashing flag is set.
|
Usage Recommendations
Use -XX:+FalconUseCompileStashing if you need to turn on Compile Stashing, and -XX:-FalconUseCompileStashing to turn it off. The structure of a disk cache location can change. It is safe to delete an arbitrary file from a directory.
The default configuration when all Zing JVMs use the same cache is beneficial because the JVMs can reuse each other’s compilations when all JVM instances running on the same machine use the same cache. To avoid the slowdown of the Compile Stashing read, write, and lookup functions, make sure the cache file system is fast (for example, stored locally).
Interactions with Other Compiler Features
Enabling Compile Stashing changes how the rest of the compilation pipeline behaves. Take both of the following into account before you enable it:
-
Unified Compiler frontend. Setting any of
-XX:+FalconUseCompileStashing,-XX:+FalconSaveObjectCache, or-XX:+FalconLoadObjectCachedisables-XX:+UseUnifiedCompilerFrontend, which is enabled by default since 25.03. Zing then uses the local Falcon compiler only. Zing applies this automatically and does not report it as an error, so check for it if you enable Compile Stashing and see unexpected compiler behavior. See Falcon Compiler Options. -
Cloud Native Compiler. When the remote compiler is active, that is,
-XX:+UseCNCtogether with-XX:+CNCEnableRemoteCompiler, Compile Stashing is disabled regardless of the Compile Stashing options you set.
Populating Compile Stashing
To populate the cache, use the -XX:+FalconUseCompileStashing command-line option. You can adjust the cache size using the -XX:FalconMaxCacheSize=<size in bytes> option.
Compile Stashing writes compiled code to the file system to access it again for the next run of Zing. By default, it writes up to 10 GB of data to the file system at $HOME/.zing/falcon-cache/<zvm_version>/ so you must provide enough free space in $HOME. If the home directory is smaller than 10 GB, use the -XX:FalconObjectCacheRoot=<path> command-line option to change the default location or disable Compile Stashing.
Compile Stashing can work without ReadyNow. However, if both are enabled, the startup time is significantly reduced.
Command-Line Options for Compile Stashing
For the full list of Command Line Options for Compile Stashing, see Command Line Option, Compile Stashing Options.
When printing stashing statistics is enabled, it is included in the cumulative report as shown in the sample below:
Stashing Final:
Compiles performed: 2204
Estimated compile time win: 0.0s
Estimated avg. compile time win: -nans
Biggest compile time win: 0.0s
Matches attempted: 2204 (100.0%)
Reads excluded via compile command: 0
Succeeded to match: 0 (0.0%)
Missing in cache: 408 (18.5%)
Cache found but did not match: 1796 (81.5%)
Added to cache: 0 (0.0%)
Writes excluded via compile command: 0
Lookup errors: 0
Write errors: 0