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

[Marcus G K Williams]

On Sun, 29 Nov 2020 08:17:09 GMT, Thomas Stuefe <stuefe 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.

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.

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

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