RFR (L): 8058354: SPECjvm2008-Derby -2.7% performance regression on Solaris-X64 starting with 9-b29

Stefan Karlsson stefan.karlsson at oracle.com
Thu Jan 29 12:25:40 UTC 2015


Hi Thomas,

On 2015-01-29 11:30, Thomas Schatzl wrote:
> Hi all,
>
>    can I have reviews for the following change that fixes the use of
> large pages for auxiliary data on G1?
>
> In JDK-8038423 there has been a large change in how G1 handles virtual
> memory, and overlooked that auxiliary data may use large pages. This
> caused some performance regressions after introducing that build.
>
> This change fixes this problem: G1 is now more flexible in using large
> pages: particularly auxiliary data that often is not sized to multiples
> of (large) page size suffers from that. By allowing the virtual space
> implementation to use small pages on the tail (upper) end of the virtual
> space, everything else can use large pages.
>
> There is one limitation to that: the start address of the used virtual
> spaces must be aligned to large page size to use large pages in
> auxiliary data. This is to simplify commit and uncommit within the
> regions, since very small areas in the auxiliary data can map to large
> areas in the heap (e.g. for the BOT, at 4k page size, one page maps to
> 2M of memory, 2M pages map to 1G of memory).
>
> The problem is, if the start address of such auxiliary data were not
> aligned to requested page size, we would potentially need to split
> neighbouring large pages if we tried to uncommit one.
>
> I.e. some ascii art showing the problem.
>
> AAAAAA AAAAAA AAAAAA  // heap area, each AAAAAA is a single region
>     |      |      |    // area covered by auxilary pages
>        1       2       // auxiliary data pages
>
> So if auxiliary data pages were unaligned, so that they correspond to
> uneven multiples of the heap, when uncommitting e.g. the second region
> (second set of AAAAAA), we would have to split the auxiliary data pages
> 1 and 2 into smaller ones.
>
> That does not seem to be a good tradeoff in complexity, given that the
> waste is at most one large page in reserved space (and unfortunately,
> due to the Linux large page implementation also in actually used space).
>
> Changes in detail containing some additional fixes:
>   - page selection corresponds to other collectors, i.e. if some
> auxiliary data covers at least one large page, try to use large pages if
> available.
>   - fix CMBitMap::compute_size() to align to alignment granularity (this
> has not been a real problem because the actual size is always a multiple
> of that)
>   - allow (very restricted) mixed use of small and large pages in the G1
> heap.
>   - pass on alignment hints to os::commit()
>   - some refactoring extracting out the code to reserve auxiliary memory
> structures
>
> With these changes, performance when using large pages is at least as
> good as before 9b29.
>
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8058354/webrev/
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8058354

ReservedSpace(size_t) already support the ability to map large pages in 
the middle of a memory region. Given your example:

AAAAAA AAAAAA AAAAAA

    |      |      |
       1       2

1 and 2 will use large pages.

There was a recent change that broke that, but it's supposed to be fixed 
with:
changeset:   7656:4321214d5dbc
parent:      7654:8dfd8b00c7f1
user:        ehelin
date:        Fri Jan 16 10:29:12 2015 +0100
summary:     8066875: VirtualSpace does not use large pages

Have  you rerun the performance tests with that fix?

StefanK

>
> Testing:
> jprt, specjbb*, specjvm*, vm.quick.testlist, some large benchmarks, test
> case
>
> Thanks,
>    Thomas
>
>




More information about the hotspot-gc-dev mailing list