JVM heap parameters

JavaJvm Arguments

Java Problem Overview


After reading already asked question on the subject and a lot of googling I am still not able to have a clear view of -Xms option

My question is: what's the difference between java -Xms=512m -Xmx=512m and java -Xms=64m -Xmx=512m?

For now I have the following answer:

The only difference is in the number of garbage collections that will be run during my application's run and the number of memory allocations. Am I right ?

Here are my reasons for this answer:

Setting the -Xms option to 512m doesn't result in my application using really 512M of physical memory after startup. I guess this is related to modern OS virtual memory management and lazy pages allocations. (I noticed that setting -Xms to 512M or to 64M doesn't change at all the initial used memory reported either by top on Linux or by the task manager on windows)

Can someone help me to understand the impact of this Xms option or point me to links that will help me to understand it?

Thanks in advance

Manu

Java Solutions


Solution 1 - Java

The JVM will start with memory useage at the initial heap level. If the maxheap is higher, it will grow to the maxheap size as memory requirements exceed it's current memory.

So,

  • -Xms512m -Xmx512m

JVM starts with 512 M, never resizes.

  • -Xms64m -Xmx512m

JVM starts with 64M, grows (up to max ceiling of 512) if mem. requirements exceed 64.

Solution 2 - Java

To summarize the information found after the link: The JVM allocates the amount specified by -Xms but the OS usually does not allocate real pages until they are needed. So the JVM allocates virtual memory as specified by Xms but only allocates physical memory as is needed.

You can see this by using Process Explorer by Sysinternals instead of task manager on windows.

So there is a real difference between using -Xms64M and -Xms512M. But I think the most important difference is the one you already pointed out: the garbage collector will run more often if you really need the 512MB but only started with 64MB.

Solution 3 - Java

Apart from standard Heap parameters -Xms and -Xmx it's also good to know -XX:PermSize and -XX:MaxPermSize, which is used to specify size of Perm Gen space because even though you could have space in other generation in heap you can run out of memory if your perm gen space gets full. This link also has nice overview of some important JVM parameters.

Solution 4 - Java

The JVM resizes the heap adaptively, meaning it will attempt to find the best heap size for your application. -Xms and -Xmx simply specifies the range in which the JVM can operate and resize the heap. If -Xms and -Xmx are the same value, then the JVM's heap size will stay constant at that value.

It's typically best to just set -Xmx and let the JVM find the best heap size, unless there's a specific reason why you need to give the JVM a big heap at JVM launch.

As far as when the JVM actually requests the memory from the OS, I believe it depends on the platform and implementation of the JVM. I imagine that it wouldn't request the memory until your app actually needs it. -Xmx and -Xms just reserves the memory.

Solution 5 - Java

if you wrote: -Xms512m -Xmx512m when it start, java allocate in those moment 512m of ram for his process and cant increment.

-Xms64m -Xmx512m when it start, java allocate only 64m of ram for his process, but java can be increment his memory occupation while 512m.

I think that second thing is better because you give to java the automatic memory management.

Solution 6 - Java

I created this toy example in scala, my_file.scala:

object MyObject {
    
    def main(args: Array[String]) {
        var ab = ArrayBuffer.empty[Int]

        for (i <- 0 to 100 * 1000 * 1000) {
            ab += i
            if (i % 10000 == 0) {
                println("On : %s".format(i))
            }
        }
    }
}

I ran it with:

scala -J-Xms500m -J-Xmx7g my_file.scala

and

scala -J-Xms7g -J-Xmx7g my_file.scala

There are certainly noticeable pauses in -Xms500m version. I am positive that the short pauses are garbage collection runs, and the long ones are heap allocations.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionManuel SelvaView Question on Stackoverflow
Solution 1 - JavaSteve B.View Answer on Stackoverflow
Solution 2 - JavaTurismoView Answer on Stackoverflow
Solution 3 - JavaSeema KiranView Answer on Stackoverflow
Solution 4 - Javabajafresh4lifeView Answer on Stackoverflow
Solution 5 - JavaTommaso TaruffiView Answer on Stackoverflow
Solution 6 - JavaAkavallView Answer on Stackoverflow