On Wed, 5 Nov 2025 19:19:23 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

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28161#pullrequestreview-3428202976

Reply via email to