On Thu, 20 Nov 2025 15:04:10 GMT, Axel Boldt-Christmas <[email protected]> wrote:
>> 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/52f64ca1...1d7b2374 Build change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28161#pullrequestreview-3489100120
