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

Thomas Stuefe stuefe at openjdk.java.net
Sun Nov 29 08:19:56 UTC 2020


On Wed, 25 Nov 2020 13:58:49 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> I agree with what Thomas is saying. This should be a generic thing for reservations, as I've suggested before, choosing the largest page size given the size of the mapping. I would also be good with starting with the `UseHugeTLBFS` case. 
>> 
>> When it comes to testing, we should not hard code these kind of things in the test, but add WhiteBox functions that return the correct numbers given the platform and environment. 
>> 
>>         WhiteBox wb = WhiteBox.getWhiteBox();
>>         smallPageSize = wb.getVMPageSize();
>>         smallPageSize = wb.getVMPageSize();
>>         largePageSize = wb.getVMLargePageSize();
>>         largePageSize = wb.getVMLargePageSize();
>>         largePageExecSize = 2097152;
>> So instead of hard coding this, I guess the correct approach would be to return an array of available page sizes and verify that the correct one is used.
>
> 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.

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

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


More information about the hotspot-gc-dev mailing list