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

[Albert Mingkun Yang]

On Tue, 29 Apr 2025 09:51:05 GMT, Thomas Stuefe <stuefe 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.

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

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