The CDS archive is mmaped to a fixed address range (starting at SharedBaseAddress, usually 0x800000000). If this requested address range is not available (usually due to Address Space Layout Randomization (ASLR)), the JVM will give up and will load classes dynamically using class files.

To improve start-up time, especially on systems with ASLR, we should try to mmap the CDS archive to an alternate address (chosen by the OS). Here are some preliminary benchmarking results (using default CDS archive, running helloworld):

(a)       47.1ms (CDS enabled, mapped at requested addr)
(b)       53.8ms (CDS enabled, mapped at alternate addr)
(c)       86.2ms (CDS disabled)

The small degradation in (b) is caused by the relocation of absolute pointers embedded in the CDS archive. However, it is still a big improvement over case (c).
======
In our testing environment, we have a fairly small number of mapping failures (below 1%), so I don't think the performance degradation caused by relocation matters too much. However, now that we can guarantee that CDS is always enabled, we can do more optimizations. E.g., AOT-compiled code can now have references into the CDS data and can assume that it's always available. So hopefully CDS can be used as a basic building block for future optimization work.