RFR: 8214455: Relocate CDS archived regions to the top of the G1 heap

[Thomas Schatzl]

On Mon, 5 Apr 2021 21:48:43 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> When the runtime heap and dump time heap have different sizes, it's possible that the archived heap regions are mapped to the middle of the runtime heap. Because the archived heap regions are pinned, this could reduce the size of the largest "humongous" array allocation. In the worst case, the maximum allocatable array length may be half of the optimal value.
> 
> The fix is to relocate the archived regions to the top of the  G1 heap (currently archived regions are supported only by G1 on 64-bit JVM).
> 
> Note that usually the top of the G1 heap is placed just below the 32GB boundary. As a result, the archived heap regions are at the same location between run time and dump time, so no relocation is necessary.
> 
> In mach5 testing, we occasionally run into this problem (see https://bugs.openjdk.java.net/browse/JDK-8239089), probably because we fail to reserve the heap below 32GB due to address space layout randomization (ASLR).

Lgtm.

src/hotspot/share/memory/filemap.cpp line 1846:

> 1844:       _heap_pointers_need_patching = true;
> 1845:     } else if (header()->heap_end() != CompressedOops::end()) {
> 1846:       log_info(cds)("CDS heap data need to be relocated to the end of the runtime heap to reduce fragmentation");

s/need/needs

test/hotspot/jtreg/runtime/cds/appcds/cacheObject/HeapFragmentationTest.java line 30:

> 28:  * @bug 8214455
> 29:  * @requires vm.cds.archived.java.heap
> 30:  * @requires (sun.arch.data.model == "64"  & os.maxMemory > 4g)

additional space before the &

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

Marked as reviewed by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3349