RFR: 8357449: ZGC: Multiple medium page sizes [v7]

[Axel Boldt-Christmas]

On Wed, 28 May 2025 05:33:43 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> <details><summary><b>Background</b> (expandable section)</summary>
>> ZGC uses three different types of memory regions (Small, Medium and Large) as a compromise between memory waste and relocation induced latencies.
>> 
>> The allocated object size dictates which type of memory region it ends up in. These sizes are selected such that when an object allocation fails in a memory region because that object does not fit, the waste (unused bytes at the end) is at most 1/8th or 12.5%. This property is held for both the small and medium memory regions.
>> 
>> Objects larger than medium object allocation gets placed in a large memory region, which only ever contains one object. And because all memory region sizes are multiples of 2M, we end up with a memory waste which is the difference between object size rounded up to the nearest multiple of 2M and the exact object size.
>> 
>> For max heaps (Xmx) smaller than 1GB we use reduced medium memory region sizes at the cost of worse waste guarantees for large object allocation.
>> 
>> But for max heaps 1GB or larger our current selected medium memory region size is 32M. This results in a max medium object size of 4M (32M * 12.5%), which is the max size we want an application thread to have to relocate. So we end up with a guarantee that the waste in large memory regions is at most 33%.
>> 
>> A problem with medium pages is that they may cause allocation induced latencies. To reduce allocation latencies we track (cache) memory of memory regions which has been freed by the GC, so it can be reused for new memory regions used for allocations.
>> 
>> For small memory regions, as long as there is cached memory, it can use it, because the size of a small memory region (2M) is always a multiple of any other memory region that has been freed.
>> 
>> However for medium memory regions it may be that there is enough memory available in the cache, but it is only split into regions smaller than the medium memory regions size (32M). Currently this requires the allocating thread to remap multiple of these small memory regions into a new larger one, which involves calls into the operating system.
>> 
>> In ZGC we call our memory regions pages or zpages.
>> </details>
>> 
>> ### Proposal
>> Allow for medium pages to have multiple sizes. Specifically allow all power of two sizes between the smallest size that can contain one medium object and the max medium page size. For a max medium page size of 32M the sizes ends up being {4M, 8M, 16M, 32M}.
>> 
>> And ad...
>
> 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 15 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8357449
>  - Rename _size to _requested_size
>  - Update test/hotspot/jtreg/gc/z/TestZMediumPageSizes.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Missing -XX:+UnlockDiagnosticVMOptions
>  - Revert "NumPartitions is reserved by Shenandoah"
>    
>    This reverts commit f7619fd700ec6498948e5e84e8051be145683940.
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8357449
>  - Retype ZPageSizeSmallShift to int
>  - Rename ZPageSizeMediumShift -> ZPageSizeMediumMaxShift
>  - Update is_disabled comment
>  - Apply suggestions from code review
>    
>    Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/10a8c9b6...9e1cc44a

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25381#issuecomment-2915412934