RFR: 8255917: runtime/cds/SharedBaseAddress.java failed "assert(reserved_rgn != 0LL) failed: No reserved region"
Thomas Stuefe
stuefe at openjdk.java.net
Mon Dec 7 11:47:12 UTC 2020
On Mon, 7 Dec 2020 05:01:27 GMT, Yumin Qi <minqi at openjdk.org> wrote:
> Hi, Please review
> Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
> The fix is the first step of two steps:
> 1) Do not split reserved memory;
> 2) Remove splitting memory.
> This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway.
>
> Tests:tier1-5,tier7
Hi Yumin,
small request wrt to commenting.
We should test this with all permutations of NativeMemoryTracking and Xshare. But I guess the standard tests do this already?
Cheers, Thomas
src/hotspot/share/memory/metaspaceShared.cpp line 1629:
> 1627: return NULL;
> 1628: }
> 1629: } else {
Could we have a comment explaining all this? I am sure I will have forgotten why we did this in two months :) Proposal:
On Windows, we cannot safely split a reserved area into two (see JDK-xxxx). Hence,
we optimistically reserve archive space and class space side-by-side. We only do this for
use_archive_base_addr=true since for the use_archive_base_addr=false case caller will
not split the combined space but read the archive data via sequential file IO.
Feel free to reformulate this.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1657
More information about the hotspot-runtime-dev
mailing list