CCS/CDS placement is suboptimal.

Ideally it should be placed in a way to allow for fast narrow class pointer decoding. On most platforms this means low addresses are good (<4G for zero based without shift, <32g for zero based with shift). This is very similar to how the heap is allocated when compressed oops are enabled.

CDS off:

If +UseCompressedOops and +UseCompressedClassPointers, we attempt to place the ccs atop of the heap. The assumption is that the heap has been placed in coops-friendly territory (lower address regions allowing for zero-based or unscaled encoding) and that mapping right above it will yield us a good chance at zero based or unscaled compressed class pointer encoding.

Since JDK-8241825, if -UseCompressedOops and +UseCompressedClassPointers, we attempt to place the ccs at HeapBaseMinAddress (as in "lowest address the platform allows us to map at") for the same reason.

In both cases we try to place the ccs only once, at that exact address. If that does not work out we give up.  We do not try any other attach points.

A better strategy would be to attempt multiple attach points in lower address regions, starting at HeapBaseMinAddress and up to 4G or 32G. Also, to make the placement independent from the heap since the heap may not even be placed in lower regions despite +UseCompressedOops, e.g. if it has been too large. The heap should just be treated as a possible - rather large, maybe - obstacle like any other vma.

Complicating all this is that different architectures may have different ideas of what an optimal encoding base is. Or even restrict the encoding schemes (e.g. aarch64). See also JDK-8243392.

CDS on:

 Here, we only ever use the SharedBaseAddress, which by default lays at 0x800000000. Since CDS=on is pretty much default now, it would make sense to optimize that placement too.