RFR: JDK-8256155: os::Linux Populate all large_page_sizes, select smallest page size in reserve_memory_special_huge_tlbfs* [v23]

Marcus G K Williams github.com+168222+mgkwill at openjdk.java.net
Tue Mar 16 18:20:09 UTC 2021


On Tue, 16 Mar 2021 09:59:34 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

> I agree that this change should not include to much refactoring. We should do that as separate changes. Some possibly have to be done before this one.
> 
> Regarding your problems:
> 
> 1. This is a somewhat known problem and we have [JDK-8261527](https://bugs.openjdk.java.net/browse/JDK-8261527) for tracking this. I hope to get this in for JDK 17. Up until your change we have always known that only one large page size can be used, so if a ReservedSpace is "special" that page size was used. With your change this has to change somehow and I think it will be hard to achieve without some other refactoring first.
> 2. Correct, this test does not yet handle mixed-mappings since none of the mappings traced has used mixed mappings before. The problem you run into is that your new code doesn't honor the request in Parallel to used 2M pages:
>    https://github.com/openjdk/jdk/blob/a31a23d5e72c4618b5b67e854ef4909110a1b5b4/src/hotspot/share/gc/parallel/parallelArguments.cpp#L120
>    
>    When deciding on a new page size we should honor the passed in alignment if it is larger than the allocation granularity. Because in such case the upper layer has made a decision that the lower layer should honor.
> 
> One other way forward (not waiting for refactoring) would be to see this change as just enabling use of multiple page sizes and then actually using them will be added later when needed refactoring has been done.

Hi Stefan ( @kstefanj ). Thanks for your review. I've addressed the specific suggestions.

>    When deciding on a new page size we should honor the passed in alignment if it is larger than the allocation granularity. Because in such case the upper layer has made a decision that the lower layer should honor.

Also, I'm looking at this today, though not sure we can do this effectively without your refactoring.

Thanks for pointing to JDK-8261527.  I knew you were looking at large pages code and refactoring but I didn't know about JDK-8261527 or the other issues and PRs. I did run into the TestTracePageSizes.java while testing and saw some of the breadcrumbs. 👍 

I would be a favor of using https://github.com/openjdk/jdk/compare/master...kstefanj:8262291-one-special-alloc as this looks like a good way forward. However, can we use my current PR as enabling of multiple page sizes and then later incorporate your refactoring? 

> One other way forward (not waiting for refactoring) would be to see this change as just enabling use of multiple page sizes and then actually using them will be added later when needed refactoring has been done.

How would we go about doing your suggestion? There are two reasons I would like to get this PR in sooner rather than waiting, there is some pressure for me to put a bow on this change and I would really appreciate getting some changes in so that I can get my authorship in OpenJDK. I am happy to continue working on incremental changes to make page_size part of the code better and if I had a username I would suggest assigning some of the JDK-Issues to me. As an example I started looking at solving JDK-8263236, but couldn't comment or assign to myself.

Anyways, let me know how we can move forward and what the best path to get this change in for JDK-17.

Thanks,
Marcus

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

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



More information about the hotspot-gc-dev mailing list