- Current classlists are generated using a set of startup benchmarks and then versioned together with the VM. Generating the classlists is a time-consuming and poorly documented process, and adds a number of requirements to the performance testing infrastructure. Since the "optimal" classlist change over time but the effect of this degradation is rather innocent on a build-to-build basis, it's only been done infrequently and as late as possible in release, if ever.

- The default CDS archive is currently quite large and there's a body of evidence to suggest that on 32-bit Windows systems a larger CDS archive increasingly lead to failure to map the archive due to interactions with ASLR.

- With JDK 9, features such as Jigsaw, Compact Strings and Indify String Concat, a non-trival amount of classes will be added, which will mean the CDS archive is expected to grow further,

- The set of applications historically used to generate the classlists are outdated and biased towards AWT and Swing-based desktop applications, while mostly missing out on new libraries that we want to incentivize developers to use rather than legacy: java.time.* instead of java.util.Date/Calendar, java.nio instead of java.io.

- For JavaFX applications JEP-275 will likely render the default classlists redundant, in which case it becomes questionable to devote a large part of the CDS archive towards desktop-oriented applications

I suggest moving to a simple, build-time solution using a (set of) synthetic, headless java program(s) as the initial benchmark.