Bug ID: JDK-8017629 G1: UseSHM in combination with a G1HeapRegionSize > os::large_page

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 7	JDK 8	JDK 9
7u121Fixed	8u112Fixed	9 b120Fixed

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.

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.

15-03-2016

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

27-06-2013

Duplicate :	JDK-8054108 - LargePages silently falling back to small pages with G1GC & 8GB+ heaps
Relates :	JDK-8007074 - SIGSEGV at ParMarkBitMap::verify_clear()
Relates :	JDK-8016666 - G1:UseSHM crashes the JVM if G1HeapRegionSize > os::large_page_size()