[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-gc-dev
Subject:    Re: RFR: 8256155: 2M large pages for code when LargePageSizeInBytes is set to 1G for heap [v2]
From:       Thomas Stuefe <stuefe () openjdk ! java ! net>
Date:       2020-11-29 8:19:56
Message-ID: qCiWzyi5c27B_cHM0A4L86Z_ceDKbtXU0ngIlU27vEY=.0f9db238-7a18-402d-b2df-900a224a7342 () github ! com
[Download RAW message or body]

On Wed, 25 Nov 2020 13:58:49 GMT, Thomas Stuefe <stuefe@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


[prev in list] [next in list] [prev in thread] [next in thread]