> ZGC reserves a virtual address range for its heap with one high order bit set > which is referred to as the heap base. Internally we then often represent > heap addresses as offset from this heap base. > > Currently we select one specific heap base at the start based on MaxHeapSize > and the current system properties. > > With instrumented builds, or custom launchers it may be that we are unable to > reserve a usable address range using that heap base. Currently we just give > up if this happens and exits the VM. > > This is problematic when using instrumented builds such as ASAN where there > are certain address ranges it uses which often clash with the default ZGC > heap base. > > I propose that we are more flexible when selecting the heap base, and we > start as we do today at our preferred location, but are able to retry other > compatible heap bases within some broader limits. > > The implementation will now start at the recommended or required heap base > which ever is larger and try to first reserve the desired reservation size > (normally 16 * MaxHeapSize). If no heap base can accommodate this desired > size, it will attempt to find at least the required size and use that. > > On linux x86_64 we will now also probe for the heap base rather than hard > coding the max heap base as we did previously. This is beneficial when there > are address space restrictions (such as with ASAN), and when there are none, > we only do a couple of extra system calls at most. > > There are some changes to the gc+init logging. The ZAddressOffsetMax is > adjusted to always be a correct upper bound. And the exit path when > reservation fails is clean up, so that we exit early when we know that the > external virtual memory limits will prohibit the heap reservation. > > Performance testing show no significant differences. > > Testing: > * GHA > * Running ZGC tier1-8 on Oracle supported platforms
Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision: - Small fixes - Merge remote-tracking branch 'upstream_jdk/master' into stefank_review_pr_28161 - Fixes and cleanups - pr/28161_review - Merge remote-tracking branch 'upstream/master' into pr/28161 - Initial Test Implementation - Initial implementation flexible heap base - Constrain ZAddressOffsetMax correctly when multi-partition fails - Log reserved size correctly when multi-partition fails - Cleanup headers - ... and 1 more: https://git.openjdk.org/jdk/compare/168f0580...1d7b2374 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28161/files - new: https://git.openjdk.org/jdk/pull/28161/files/bf5f9550..1d7b2374 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28161&range=00-01 Stats: 263285 lines in 2103 files changed: 168784 ins; 56747 del; 37754 mod Patch: https://git.openjdk.org/jdk/pull/28161.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28161/head:pull/28161 PR: https://git.openjdk.org/jdk/pull/28161
