RFR: JDK-8312018: Improve reservation of class space and CDS

[Thomas Stuefe]

On Fri, 11 Aug 2023 03:47:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> But base can be any value. In practice it won't be zero, because the lowest narrowKlass is a very small integer, which would mean that this klass would need to be mapped at a very low address, which most OSes don't allow.

But they do. Linux allows reservation down to vm.mmap_min_addr, which is usually 64K. And that works fine, Shenandoah does it for years AFAIK for its collection sets.

MacOS allows reservation below 32 GB at least.

There is really no reason not to try and reserve in low address regions.

> CDS would be perfectly OK if the CCS starts at a low, non-zero address. But the address space below 4G is somewhat precious and scarce. So if CDS cannot take advantage of it, we shouldn't even attempt to reserve below 4G.

I'm not sure I follow you.

`strict_base`, together with `CompressedKlassPointers::initialize_for_given_encoding(..)`, only exist for the CDS runtime case. They exist because CDS needs to set the encoding base to the start of the mapped archive to make the pre-computed narrow Klass IDs match up. Once we start recalculating those IDs - like we talked about off-list - both `strict_base` and `CompressedKlassPointers::initialize_for_given_encoding(..)` can be removed.

Right now, CDS cannot take advantage of low address regions, that is correct. That is why we don't try it if `strict_base` is true: the if-block that guards low-address reservation is only executed for CDS=off or CDS=dumptime.

But if we recalculate the narrow Klass IDs of archived heap objects, we can remove the strict_base parameter and then we:

1) reserve CDS+class space, possibly in low address regions
2) call `CompressedKlassPointers::initialize`, which will take advantage of a low-address klass range and set encoding base to zero
3) re-compute the narrow Klass IDs in archived objects based on a zero encoding base.

Sounds right?

One important factor with the new API is that we always attempt to reserve the heap first. So the heap gets first dips at low-address regions. Only after that we try to reserve CDS+class space. So we will not compete with the heap, where zero encoding is somewhat more important. We come second, which I think reflects importance of zero-based narrow Klass encoding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/15041#discussion_r1290922517