RFR: 8372150: Parallel: Tighten requirements around heap sizes with NUMA and Large Pages [v4]

[Joel Sikström]

On Wed, 26 Nov 2025 10:16:48 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Joel Sikström has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into JDK-8372150_parallel_minheapsize_numa_largepages
>>  - Choose large page size based on MaxHeapSize
>>  - Revert "8372150: Parallel: Tighten requirements around MinHeapSize with NUMA and Large Pages"
>>    
>>    This reverts commit c02e08ade597193d70d1eb21036845bdd0304d51.
>>  - Revert "Albert review feedback"
>>    
>>    This reverts commit 66928d22112c1ac516e4b654c28249fdedf0dba9.
>>  - Albert review feedback
>>  - 8372150: Parallel: Tighten requirements around MinHeapSize with NUMA and Large Pages
>
> This looks good to me (not that you need another review). A jtreg regression test would be nice, possibly in a separate RFE.
> 
> What do other GCs do if heap is smaller than smallest large page size?
> 
> The super-large page size issue one could also consider a user error that should result in a VM exit.

Thank you for looking at this @tstuefe. In ZGC, we only support 2MB large pages, and we can commit any number of ZPages (regions), which are also aligned to 2MB so it always works out.

I agree that super-large page sizes could be considered a configuration issue. We were a bit worried about when >=512M large page sizes are the default on the system.

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

PR Comment: https://git.openjdk.org/jdk/pull/28394#issuecomment-3580799409