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

[Marcus G K Williams]

On Thu, 3 Dec 2020 23:22:17 GMT, Marcus G K Williams <github.com+168222+mgkwill at openjdk.org> wrote:

>> One thing I stumbled upon while looking at this code is why the CodeHeap always wants to have at least 8 pages covering its range:
>> 
>>   // If large page support is enabled, align code heaps according to large
>>   // page size to make sure that code cache is covered by large pages.
>>   const size_t alignment = MAX2(page_size(false, 8), (size_t) os::vm_allocation_granularity());
>> 
>> which means that for a wish pagesize of 1G, the code cache would have to cover at least 8G. I am not even sure this is possible, isn't it limited to 4G? 
>> 
>> Anyway, they don't uncommit. And the comment in codecache.cpp indicates this is to be able to step-wise commit, but with huge pages the space is committed right from the start anyway. So I do not see what good these 8 pages do. If we allowed the CodeCache to use just one page, it could be 1G in size and use a single 1G page. 
>> 
>> Note that there are similar min_page_size requests in GC, but I did not look closer into them.
>> 
>> Also, this does not take away the usefulness of this proposal.
>
>> One thing I stumbled upon while looking at this code is why the CodeHeap always wants to have at least 8 pages covering its range:
>> 
>> ```
>>   // If large page support is enabled, align code heaps according to large
>>   // page size to make sure that code cache is covered by large pages.
>>   const size_t alignment = MAX2(page_size(false, 8), (size_t) os::vm_allocation_granularity());
>> ```
>> 
>> which means that for a wish pagesize of 1G, the code cache would have to cover at least 8G. I am not even sure this is possible, isn't it limited to 4G?
>> 
>> Anyway, they don't uncommit. And the comment in codecache.cpp indicates this is to be able to step-wise commit, but with huge pages the space is committed right from the start anyway. So I do not see what good these 8 pages do. If we allowed the CodeCache to use just one page, it could be 1G in size and use a single 1G page.
>> 
>> Note that there are similar min_page_size requests in GC, but I did not look closer into them.
>> 
>> Also, this does not take away the usefulness of this proposal.
> 
> Interesting. I'll look at min_page_size requests in GC and codecache in relation to large pages and see what kind of optimization can be done in another JDK-Issue/PR.

Recent push is dependent on and includes #1522 - when it is updated, I will update here.

Removed 2M/exec specific code. Re-wrote to take advantage of #1522. Attempted to address other comments. Please let me know if I've missed something.

My apologies this took so long to update, we had a long holiday weekend.

Thanks again for all of the review @kstefanj and @tstuefe!

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

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