Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8259380

Correct pretouch chunk size to cap with actual page size

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: P3 P3
    • 16
    • 16, 17
    • hotspot
    • gc
    • 16
    • b32
    • x86, aarch64
    • linux

        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 (https://github.com/openjdk/jdk/commit/2c7fc85be92c60f4262aff3bc80e704792c1e810) 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 (https://github.com/openjdk/jdk/commit/805d05812c5e831947197419d163f9c83d55634a) 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.

        The fix for this is ready, I will attach the test results, and propose a PR soon

              qpzhang Patrick Zhang
              qpzhang Patrick Zhang
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: