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.