RFR: 8271195: Use largest available large page size smaller than LargePageSizeInBytes when available [v3]

[Thomas Stuefe]

On Mon, 7 Feb 2022 13:23:20 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>I think my example, that a 128m heap is aligned up to 512m if the large page size is 512m, is a case that could be considered a bug, but it is not crystal clear. Cause the user have specified both that it wants large pages but also a heap size of 128m. 

I remember us discussing this recently: https://bugs.openjdk.java.net/browse/JDK-8267475

> Which of these are more important? On the other, if we could satisfy the heap of 128m using 2m pages we would be closer to what I would see as the correct solution. This would be achieved today by setting `LargePageSizeInBytes=2m`.

I would actually like the following behavior:
- LargePageSizeInBytes is the largest page size usable by the VM. It is free to choose whatever it likes but should give preference to larger page sizes if possible
- when reserving a region and UseLargePages=true, use the largest page size possible which fulfills the size requirement (and possibly the alignment requirement if a wish address was specified).

I think this is close to what we do now.

So, `-XX:+UseLargePages -XX:LargePageSizeInBytes=1G -Xmx1536m -XX:ReservedCodeCacheSize=256m` would use
- a single 1G page and 256 2m pages for the heap
- 128 2m pages for the code cache
... and if we ever re-introduce large pages for metaspace, those smallish segments would probably use 2m pages too.

Open question would be whether we even need LargePageSizeInBytes. Why not simplify and always use the largest possible page size we find available? If there are 1G pages and they would fit into the to-be-reserved address range, we use them. Why would an administrator allow large pages in general, create a 1G page pool, but disallow them?

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

PR: https://git.openjdk.java.net/jdk/pull/7326