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/3d39bb21...1d7b2374 We redesigned a bit how the `ZVirtualMemoryManager` works. We no longer update global state while trying to find a reservation. But have created a distinct separation between when we are looking for a heap and when we have found a heap. Prior to finding a heap we do not use our heap based types `zaddress`, `zpointer`, `zoffset` etc. And if we did they would assert. Then at the point when we are satisfied with a specific heap selection, we set up our global state based on this heap selection, once and only once. We then start transferring our heap selection into our heap data structures which use these heap based types. As a consequence we had to rewrite some of the test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28161#issuecomment-3558539681
