[jdk16] RFR: 8259380: Correct pretouch chunk size to cap with actual page size

Patrick Zhang qpzhang at openjdk.java.net
Mon Jan 11 15:24:59 UTC 2021


On Mon, 11 Jan 2021 15:15:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> This is actually a regression, with regards to JVM startup time extreme slowdown, initially found at an aarch64 platform (Ampere Altra core).
>> 
>> The chunk size of pretouching should cap with the input page size which probably stands for large pages size if UseLargePages was set, otherwise processing chunks with much smaller size inside large size pages would hurt performance.
>> 
>> This issue was introduced during a refactor on chunk calculations JDK-8254972 (2c7fc85) but did not cause any problem immediately since the default PreTouchParallelChunkSize for all platforms are 1GB which can cover all popular sizes of large pages in use by most kernel variations. Later on, JDK-8254699 (805d058) set default 4MB for Linux platform, which is helpful to speed up startup time for some platforms. For example, most x64, since the popular default large page size (e.g. CentOS) is 2MB. In contrast, most default large page size with aarch64 platforms/kernels (e.g. CentOS) are 512MB, so using the 4MB chunk size to do page walk through the pages inside 512MB large page hurt performance of startup time.
>> 
>> In addition, there will be a similar problem if we set -XX:PreTouchParallelChunkSize=4k at a x64 Linux platform, the startup slowdown will show as well.
>> 
>> Tests:
>> https://bugs.openjdk.java.net/secure/attachment/92623/pretouch_chunk_size_fix_testing.txt
>> The 4 before-after comparisons show the JVM startup time go back to normal.
>> 1). 33.381s to 0.870s
>> 2). 20.333s to 2.740s
>> 3). 15.090s to 6.268s
>> 4). 38.983s to 6.709s
>> (Use the start time of pretouching the first Survivor space as a rough measurement, while \time, or GCTraceTime can generate similar results)
>
> src/hotspot/share/gc/shared/pretouchTask.cpp line 70:
> 
>> 68:   // large pages size if UseLargePages was set, otherwise processing chunks with
>> 69:   // much smaller size inside large size pages would hurt performance.
>> 70:   // Revising page_size should be placed after having decided the proper chuck_size.
> 
> Something like
> 
> `// Chunk size should be at least (unmodified) page size as using multiple threads pretouch on a single chunk can decrease performance.`
> 
> is sufficient here.

Sure I will update this accordingly, thanks

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

PR: https://git.openjdk.java.net/jdk16/pull/97



More information about the hotspot-gc-dev mailing list