Why is JVM -Xms option not simply 0?

user_425477 0
Viewed 109

Why does the JVM have an -Xms option? Why do we care about a minimum heap size? Why not just 0? It's super easy to allocate RAM, so I don't see the point of forcing a minimum heap size.

In my searching, I see that it's customary to set -Xms (minimum heap size) and -Xmx (maximum heap size) to the same value.

I am having a hard time finding a clear and rational basis for this custom or why -Xms even exists. Rather, I find a lot of communal reinforcement. On occasion, I see it justified by a flaky theory, such that the JVM is unusually slow at allocating additional RAM as it grows the heap size.

While this came up as I was optimizing Solr, it seems that fussing with the heap size is a common consideration with JVMs.

As a curious data point, you'll see two memory-usage dips here: Memory changes when I change JVMheap settings.

  • Before dip 1: -Xms14g -Xmx14g
  • Between dip 1 and 2: -Xms0g -Xmx14g
  • After dip 2: -Xmx14g

After dip 2, Solr reported to me that it was only using a couple hundred MBs of heap space even though the JVM gobbled up many GBs of RAM.

In case it matters, I am on the current release of OpenJDK.

To summarize, is there a rational and fact-based basis for:

  • Setting -Xms to something other than 0.
  • The custom of setting -Xms and -Xmx to the same value.
  • Why -Xms even exists.

I think the fact-based basis will help with a more informed basis for managing heap-size options.

heap-memory java performance
1 Answers

You have three questions.

First question:

Is there a rational and fact-based basis for setting -Xms to something other than 0?

Looking as far back as version 8, we can see (among other things) the following for -Xms:

Sets the minimum and the initial size (in bytes) of the heap.

So, setting -Xms to 0 would mean setting the heap to 0. I'm not sure what your expectation would be, but.. the JVM needs at least some amount of heap to do things (like run a garbage collector).

Second question:

Is there a rational and fact-based basis for the custom of setting -Xms and -Xmx to the same value?

Yes, if you expect to use a certain amount of memory over time, but not necessarily right away. You could allocate the full amount of memory up front so that any allocation costs are out of the way.

For example, consider an app that launches needing less than 1GB of memory, but over time it grows (normally, correctly) to 4GB. You could run that app with -Xms1g -Xmx4g – so, start with 1GB and do periodic allocations over time to reach 4GB. Or you could run with -Xms4g -Xmx4g – tell the JVM to allocate 4GB now, even if it's not going to be used right away.

Allocating memory from an underlying operating system has a cost, and might be expensive enough that you'd like to do that early in the application life, instead of some later point where that cost might be more impactful.

Third question:

Is there a rational and fact-based basis for why -Xms even exists?

Yes, it allows tuning JVM behavior. Some applications don't need to do this, but others do. It's useful to be able to set values for lower, upper, or both (lower and upper together). Way beyond this, there's a whole world of garbage collector tuning, too.

A little more detail on how -Xms is used (below) could give you some initial garbage collection topics to read about (old generation, young generation):

If you do not set this option, then the initial size will be set as the sum of the sizes allocated for the old generation and the young generation.

user_113749570
Related