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

G1: UseSHM in combination with a G1HeapRegionSize > os::large_page_size() falls back to use small pages

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: hs24, hs25
    • Fix Version/s: 9
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
      gc
    • Resolved In Build:
      b120

      Backports

        Description

        JDK-8007074 fixes crashes due to incorrect alignment with G1HeapRegionSize > os::large_page_size() and UseSHM (originally tracked by JDK-8016666) has been enabled, and if allocation of SHM/huge pages has actually been successful.

        With JDK-8007074, instead of crashing, if the memory area allocated returned by SHM functions is not aligned with G1HeapRegionSize (or actually the requested alignment), the VM falls back to use small pages.

        This kind of fallback is different to the fallback to use small pages when there are no (or not enough) large pages available at all.

        See os::reserve_memory_special_shm() for details.

        This may represent a performance issue.

        Improve that by e.g. manual alignment or additional allocation of small pages at the start and end to align the heap.

          Issue Links

            Activity

            Hide
            tschatzl Thomas Schatzl added a comment - - edited
            Some reasons for setting this as a P4:

            - this current behavior is not a regression. Previous behavior has been crashes of the VM in most cases. I.e. if you did not use SHM and G1 region sizes larger than a page size, the VM used small pages always, so this behavior would exactly the same as before.

            - the impact of this (possible) performance issue is limited to when UseSHM is enabled and the G1 region size is larger than a large page size, and only if the alignment by chance does not work out, only. This is a limitation of SHM large pages provided by the OS: an application can only rely on a large page aligned memory area when requesting them.

            Further comments about the importance of this issue:
            - the fix for JDK 8007074 introduces support for transparent huge pages (which is enabled by default). This (if UseSHM is disabled) will probably give you the performance improvements that you would expect with enabling UseSHM. So the "workaround" for this issue (disabling UseSHM) will actually provide the benefits that were expected by turning on UseSHM.

            Note that transparent huge pages need a relatively recent kernel, e.g. like the Unbreakable Enterprise Linux kernel R2, see http://www.oracle.com/us/technologies/linux/ubreakable-enterprise-kernel-linux-173350.html (thanks go to StefanK to point that out).

            - I think the suggested changes, while they would work, do not play well with any future NUMA awareness support for G1. There is the question on which NUMA node to place pages that cross region boundaries.

            One other idea is to lift the restriction of having g1 regions not aligned to their natural alignment. This may not work either, but touches one of the core assumptions of the G1 collector. This means that, after actually thinking through that idea just to see if it is possible (I am not sure actually), this will require many core changes.

            When using the transparent huge pages the VM does not have that issue, as it allows the VM to ask the OS to align the returned memory properly.

            Edited: clarifications
            Show
            tschatzl Thomas Schatzl added a comment - - edited Some reasons for setting this as a P4: - this current behavior is not a regression. Previous behavior has been crashes of the VM in most cases. I.e. if you did not use SHM and G1 region sizes larger than a page size, the VM used small pages always, so this behavior would exactly the same as before. - the impact of this (possible) performance issue is limited to when UseSHM is enabled and the G1 region size is larger than a large page size, and only if the alignment by chance does not work out, only. This is a limitation of SHM large pages provided by the OS: an application can only rely on a large page aligned memory area when requesting them. Further comments about the importance of this issue: - the fix for JDK 8007074 introduces support for transparent huge pages (which is enabled by default). This (if UseSHM is disabled) will probably give you the performance improvements that you would expect with enabling UseSHM. So the "workaround" for this issue (disabling UseSHM) will actually provide the benefits that were expected by turning on UseSHM. Note that transparent huge pages need a relatively recent kernel, e.g. like the Unbreakable Enterprise Linux kernel R2, see http://www.oracle.com/us/technologies/linux/ubreakable-enterprise-kernel-linux-173350.html (thanks go to StefanK to point that out). - I think the suggested changes, while they would work, do not play well with any future NUMA awareness support for G1. There is the question on which NUMA node to place pages that cross region boundaries. One other idea is to lift the restriction of having g1 regions not aligned to their natural alignment. This may not work either, but touches one of the core assumptions of the G1 collector. This means that, after actually thinking through that idea just to see if it is possible (I am not sure actually), this will require many core changes. When using the transparent huge pages the VM does not have that issue, as it allows the VM to ask the OS to align the returned memory properly. Edited: clarifications
            Hide
            stefank Stefan Karlsson added a comment -
            This is only a problem when req_addr is NULL or if req_addr is not 'alignment' aligned.

            I intend to fix this by:

            1) Adding an assert that req_addr is 'alignment' aligned.

            2) pre-reserve aligned memory before calling shmat, when req_addr is NULL.
            Show
            stefank Stefan Karlsson added a comment - This is only a problem when req_addr is NULL or if req_addr is not 'alignment' aligned. I intend to fix this by: 1) Adding an assert that req_addr is 'alignment' aligned. 2) pre-reserve aligned memory before calling shmat, when req_addr is NULL.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/03999dd89a1b
            User: stefank
            Date: 2016-04-25 12:14:21 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/03999dd89a1b User: stefank Date: 2016-04-25 12:14:21 +0000
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/03999dd89a1b
            User: lana
            Date: 2016-05-25 17:36:48 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/03999dd89a1b User: lana Date: 2016-05-25 17:36:48 +0000

              People

              • Assignee:
                stefank Stefan Karlsson
                Reporter:
                tschatzl Thomas Schatzl
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: