RFR: 8256155: 2M large pages for code when LargePageSizeInBytes is set to 1G for heap [v3]

[Marcus G K Williams]

On Sun, 29 Nov 2020 08:17:09 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I honestly don't even know why we have UseSHM. Seems redundant, and since it uses SystemV shared memory which has a different semantics from mmap, it is subtly broken in a number of places (eg https://bugs.openjdk.java.net/browse/JDK-8257040 or https://bugs.openjdk.java.net/browse/JDK-8257041).
>
> 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.

Working on addressing comments in the code on this PR. Should have a tested change pushed later today and replies to comments.

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

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