RFR: 8354145: G1: UseCompressedOops boundary is calculated on maximum heap region size instead of maxiumum ergonomic heap region size [v4]

[Thomas Stuefe]

On Tue, 29 Apr 2025 10:54:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > why does the heap region size factor into this decision at all?
> 
> I wonder if it's due to `Arguments::max_heap_for_compressed_oops`:
> 
> ```
>   // We need to fit both the null page and the heap into the memory budget, while
>   // keeping alignment constraints of the heap. To guarantee the latter, as the
>   // null page is located before the heap, we pad the null page to the conservative
>   // maximum alignment that the GC may ever impose upon the heap.
>   size_t displacement_due_to_null_page = align_up(os::vm_page_size(),
>                                                   _conservative_max_heap_alignment);
> 
>   LP64_ONLY(return OopEncodingHeapMax - displacement_due_to_null_page);
> ```
> 
> The actual heap starts after the null-page, and the null-page takes the heap-region size in order for heap-start to be aligned.

Thanks @albertnetymk @tbzhang, that makes sense:

- Null area must be located at encoding base (heap base)
- Heap is split into regions, regions must be pow2-sized and (I assume) start at region-size-aligned addresses.
- Null area must directly precede first region. First region follows Null area. So Null area must be sized to be region size.

In Metaspace, I do this differently: https://github.com/openjdk/jdk/blob/6a0c24f9db0b15a00ecadca6e853ed5aa3775b78/src/hotspot/share/memory/metaspace.cpp#L816

Here, the Null area is part of the first Root chunk segment. I set up class space starting at encoding base, then allocate a smaller area from that chunk, protect it, and never free it again. 

I very briefly wondered why this was not possible in the java heap (e.g. protect the first page of the first region) but that would be a worse solution for many reasons. It would mean region 0 requires special attention, would prevent it from being collected normally, would mean we had to find a separate solution for every collector etc. Rather just live with wasting a bit of address space at the front of the heap.

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

PR Comment: https://git.openjdk.org/jdk/pull/24541#issuecomment-2838548537