Bug ID: JDK-8023905 Failing to initialize VM with small initial heap when NUMA and large pages are enabled

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 10
10 b21Fixed

While investigating another NUMA isseu I ran into this problem while running some jtreg-tests. It turns out that the test doesn't have anything to do with it, since it is reproducible simply by running:
java -XX:+UseNUMA -XX:+UseLargePages -Xms8m -version

When running this I get:
Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000607600000, 3145728, 0) failed; error='Cannot allocate memory' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (malloc) failed to allocate 3145728 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /localhome/sjohanss/jpg/bugs/jbs8016155/c-repro/hs_err_pid3647.log

I've investigated the issue and the problem seems to be that when using large pages and eden is small we can end up in a situation where we use mmap with MAP_FIXED but without MAP_HUGETLB on an address that is already mapped with MAP_HUGETLB. If the size of the MAP_FIXED mapping isn't a multiple of 2MB (huge page size) this will fail with errno ENOMEM (strange errno since we are not really out of memory). This will in turn lead to failing to initialize the VM even though there is memory left on the system.

During testing, I also saw below message so filed JDK-8163796. mbind: Invalid argument
10-08-2016
The error message is thrown as we are trying to commit memory which is not expected to do for pin region. (from os::free_memory) If we try to use large pages and os::can_commit_large_page_memory() returns false, we try to use 'pin region'. And with this configuration, we will not commit from os::pd_free_memory() by the condition of 'if (alignment_hint <= (size_t)os::vm_page_size() \|\| can_commit_large_page_memory()) {'. However, if the heap size is small, current NUMA code reverts page size to the default size. mutableNUMASpace.cpp: line 580 if (base_space_size_pages / lgrp_spaces()->length() == 0 && page_size() > (size_t)os::vm_page_size()) { set_page_size(os::vm_page_size()); So when we bias region, we call commit_memory() which is not designed to. Since all memory reservation is done at that point, VM exit seems the right choice. Adding an exception for the small heap seems not good as the small heap seems not practical for NUMA + large page case.
09-08-2016
This is still present in 9, but only with ParallelGC which is no longer the default. Reproduce on a system with large pages and numa support with: java -XX:+UseNUMA -XX:+UseHugeTLBFS -Xms4m -Xmx8m -version
12-02-2016
Attached a jtreg test to trigger the issue. Requires the system to have NUMA support to fail. Fixing this issue will be affected by the changes made when fixing JDK-8016309 and JDK-8010722, so leaving this as is for now. One way to guarantee that this issue won't happen is to force the eden size to be a multiple of the page size and the minimum number of pages used must be at least the number of NUMA nodes.
04-09-2013
Remember to write jtreg test to it. The right place may be test/gc/arguments.
29-08-2013
The thing is the problem occurs when both large pages and NUMA is enabled. So as long as UseLargePages is true by default, we will encounter the problem with "java -XX:+UseNUMA -Xms8m -version" as well. But to be clear I added both flags to highlight that both are enabled.
29-08-2013
Stefan, can you confirm running a flag at a time works fine with the same configuration? java -XX:+UseNUMA -Xms8m -version java -XX:+UseLargePages -Xms8m -version
28-08-2013