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

[Thomas Schatzl]

On Tue, 29 Apr 2025 09:51:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> This may be a stupid question, but why does the heap region size factor into this decision at all? I assume that both heap base and heap max size are aligned to heap region size?

>From the calculation for max heap for compressed oops:


size_t Arguments::max_heap_for_compressed_oops() {
  // Avoid sign flip.
  assert(OopEncodingHeapMax > (uint64_t)os::vm_page_size(), "Unusual page size");
  // 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);
  NOT_LP64(ShouldNotReachHere(); return 0);
}

This conservative max heap alignment is what we change from absolute maximum (512M) to what the ergonomics would at most use (32M). At that point we can only use these conservative values, because ergonomics only later decides heap region size based on max heap size which the code may not have at this point.
(Afair)

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

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