Recent versions of the JDK have continued to show great improvement in startup from using AppCDS (Class Data Store). Previously, there were two ways to generate this archive for a given JRuby install: manually passing the AppCDS flags to the JVM; or using the jruby-startup gem's generate-appcds command. Once generated, the existing jruby launcher script detects the archive and uses it to reduce startup:

https://gist.github.com/headius/94cb33aa2acbbaf433c2ad0fbfefcfb5

These improvements apply to larger commands as well, with diminishing returns as the overall run-time of the command increases.

We would like to make the generation and use of AppCDS archives entirely automatic, built into the launcher script, so that even users with no knowledge of this extra startup trick can benefit.

The new feature would have the following requirements:

• Lazily generate an AppCDS archive whenever an appropriate one cannot be found.
• Store the AppCDS archive somewhere local to the user, rather than in the JRuby dist directory, to ensure it can be written and controlled by the local user.
• The AppCDS archive store should be structured or keyed in such a way that if the installed JRuby changes or if the user switches to a different JDK it will not conflict with a now-stale archive.
• A given version of JRuby on a given version of JDK (where version is either numeric release or vendor) should always use AppCDS and produce no warnings.
• Optional: some mechanism for cleaning out old AppCDS archives that have not been used in some time.

The structure of the AppCDS storage could be based on real path to the JDK, which might produce false positives if upgrading a given JDK means overwriting old files, or based on actual JDK version, which may not be queriable without running at least one command line.

The bottom-line goal is to automatically produce and use AppCDS archives that are specific (enough) to the current JRuby and JDK to avoid any warnings or errors (from either JRuby or the JDK itself), and to prevent those archives from becoming stale (causing JDK to warn) or downright old (potentially just booting wrong).