Java堆分配是2MB的倍数

Question

I have noticed that Java heap allocation is in the multiples of 2 MB. For example I started the JVM with -Xmx values as 1021m, 1022m both JVMs started with the heap size of 1022m . Similarly heap sizes 1023m,1024m started with 1024m .

The output is below:

C:\Users\myuser>java -Xmx1021m -XX:+PrintFlagsFinal -version | findstr "MaxHeapSize"
    uintx MaxHeapSize                              := 1071644672
          {product}
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode)

C:\Users\myuser>java -Xmx1022m -XX:+PrintFlagsFinal -version | findstr "MaxHeapSize"
    uintx MaxHeapSize                              := 1071644672
          {product}
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode)

In both the cases it shows the MaxHeapSize as 1071644672 bytes which is 1022mb.

C:\Users\myuser>java -Xmx1023m -XX:+PrintFlagsFinal -version | findstr "MaxHeapSize"
    uintx MaxHeapSize                              := 1073741824
          {product}
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode)

C:\Users\myuser>java -Xmx1024m -XX:+PrintFlagsFinal -version | findstr "MaxHeapSize"
    uintx MaxHeapSize                              := 1073741824
          {product}
java version "1.8.0_121"
Java(TM) SE Runtime Environment (build 1.8.0_121-b13)
Java HotSpot(TM) Client VM (build 25.121-b13, mixed mode)

In both the cases it shows the MaxHeapSize as 1073741824 bytes which is 1024mb.

This behavior is similar for Xms.

Question 1: Why are heap sizes being changed from the specified values to next multiple of 2?

Question 2: Why Java does not even warn us when the JVM has actually started with a value different than the one specified

Question 3: Is there a flag or some way to force JVM to create a Heap of 1021mb?

Question 4: In hypothetical situation say I have 1023mb of free memory available on my machine and I try to create an JVM with 1023mb of heap. By the above behavior it actually tries to start with 1024mb which is not available. Will the JVM creation fail?

Answer 1

This is actually pretty interesting. So there are a couple of page sizes that are supported by the CPU at the same time , as described here .

4KB is the usual one; and the other two are called huge pages .

Looking at that, you see that one possible page size is 2MB and you could say - problem solved!

Because you know, you memory is indeed aligned in chunks of 2MB exactly from your examples. And that was actually my first reaction when I read your question. But then I decided to try on my MAC. Now the cpu I'm having is x86 that apparently support all 3 page sizes: 4KB, 2MB, 1GB.

What about the Mac OS itself? I found the sources (jdk-9) of what value is actually being read for page size, that is in hotspot/src/os/bsd/vm/os_bsd.cpp . And the actual code:

   Bsd::set_page_size(getpagesize())

I took that simple function getpagesize and run it in Xcode. Surprise, surprise! it's only 4KB , but heap is still aligned as in your example (by MB magnitude).

Then I remembered that there is alignment done on page_size here : share/vm/memory/heap.cpp . Here is the actual method:

 static size_t align_to_page_size(size_t size) {
     const size_t alignment = (size_t)os::vm_page_size();
     assert(is_power_of_2(alignment), "no kidding ???");
     return (size + alignment - 1) & ~(alignment - 1);
 }

That will make the memory grow just a bit, so that it is divisible by page_size ( 4KB in my case); which exactly what you said in the comment about being divisible by 4KB .

Now to understand the next, I did quite a few searches... jdk-9-sources|grep Xmx and I got lucky! The lucky bits that I found are here: share/vm/gc/shared/collectorPolicy.cpp and an awesome comment:

 size_t CollectorPolicy::compute_heap_alignment() {
     // The card marking array and the offset arrays for old generations are
     // committed in os pages as well. Make sure they are entirely full (to
     // avoid partial page problems), e.g. if 512 bytes heap corresponds to 1
     // byte entry and the os page size is 4096, the maximum heap size should
     // be 512*4096 = 2MB aligned.

     size_t alignment = CardTableRS::ct_max_alignment_constraint();

     if (UseLargePages) {
         // In presence of large pages we have to make sure that our
         // alignment is large page aware.
         alignment = lcm(os::large_page_size(), alignment);
     }

     return alignment;
 }

At this point I am not very sure that this is the only thing that makes the heap aligned on 2MB . This uncertainty comes from the fact that this file is full of comments on how heap can be grown to adjust some parameters. It would be fun understanding all those details, but extremly time consuming , so I gave up.

Answer 2

What you observe is a limitation imposed by your operating system, not JVM. When allocating memory for a process, operating systems usually don't operate bytes (because doing so would make allocation and especially access to memory a very slow process) - they use what's called a "memory page". You can read more about it starting from here .

So, your operating system seems to have memory page size of 2MB, which means that when process requests to allocate some memory for itself, the least it can get is 2MB, which is exactly what happens in your case.

For second part of your question, you can indeed force your JVM into having heap that is not a multiple of 2MB - by changing memory page size of your operating system (some of them do have this option). However, that may have unforeseen consequences, as it will affect all processes running inside that OS.