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

[Stefan Johansson]

On Mon, 14 Feb 2022 14:33:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > But we've discussed doing something like this in the past and I think it would be nice from a perf perspective. But there are some issue, say that the 2m commit above fail, then the whole reservation need to be restarted (because we can't guarantee that we still have the range reserved), and should we then try to just use fewer 2m page or directly revert down to 4k pages.
> 
> Probably the latter, with a warning. I expect in general the admin to be able to allocate enough huge pages, so error handling is rare and can be simple. Just my opinion.

Yes, deciding how much to help vs how much to expect from the configuration is not crystal clear. I know we have also discussed that one can query how many pages are in the pool and do decisions from that as well, but I think that might be over the top. 


> > There is also other things that well be affected, for example we have some code in G1 that is tracking the page size of the underlying mapping to know when regions can be truly uncommited (multiple regions sharing one underlying OS page), having the heap consist of multiple page sizes would make this more complicated.
> 
> I understand this, but I am confused too: I thought large page memory is never uncommitted because we cannot be sure it can be recommitted? When does G1 uncommit large paged heap?
> 
As you say we can't uncommit when large pages are used, but we keep track that the range of pages are dirty and need clearing if reused later. (Might be room for some concurrent clearing here)

> > This would be the simplest and cleanest approach in the code now when we support multiple page sizes. One argument I've heard against this is that an administrator might want to setup a 1G page pool for some other application, like a database, while letting the JVM only use 2M pages. So there might be usecases.
> > If we would go down this route I also think we should stop caring about what the "default" large page size is as well, and always just use the ones configured. But then there is this question about what is "configured", must a page size pass the sanity test to be considered configured (that is basically what this change proposes).
> 
> Yes, I think getting rid of default large page makes sense. And instinctively I would say "configured" means we were, at startup, able to allocate at least one page of that size.
> 
I think this would be a good way forward, to just allow use of page sizes which pass the sanity check. But I still think there might be a usecase for `LargePageSizeInBytes`, if you want to restrict the maximum used page size for the JVM. Say for example that your 1G-pool is for someother application.

> > Counter question, if we go down that route, would we still have `os::large_page_size()` or should all users always ask for a page size given the size of thier mapping?
> 
> I think the latter. If we have multiple large pages, but no concept of default, the caller needs to specify its wish size.

So do I, I'll file some enhancements.

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

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