Equal -Xms and -Xmx in JVM

Question

I have a Java microserive that is increasing in memory daily in production that I have just inheritted. It is currently using 80% of a 4GB heap and rising a few percent each day.

The -Xms and -Xmx values in the JVM options are both set to 4GB.

Does this mean the garbage collector wont activate until the JVM reaches its heap limit?

Answer 1

This means the JVM will always allocate 4GB of heap. It may or may not run the GC before heap is full. AFAIK this is up to the GC implementation. My experience is that it won't garbage collect before the heap is (almost) full, but that may not be true for all implementations. If you suspect a memory leak I'd suggest reducing -Xms, then monitor if heap grows beyond -Xms value. BTW: Is there a reason for this high -Xms value? All cases I have seen where -Xms was specified, this was by mistake / lack of of knowledge

Answer 2

Does this mean the garbage collector wont activate until the JVM reaches its heap limit?

No, the garbage collector will activate its collection cycles whenever the GC algorithm tells it to - which will usually be frequent incremental collections, and occasional full collections. Running out of heap can force it to perform a full collection more often and be more aggressive, but it's certainly not true (for all GC implementations I'm aware of anyway) to say it won't do anything until it's out of, or nearly out of heap space.

What could be happening (depending on the GC algorithm) is that the incremental collections are performing regularly & as intended, but is unable to clear everything properly - and the slower full collection won't be performed until you're lower on space. That's perfectly valid behaviour - you've given the VM 4GB heap, and it'll use that in the way it sees fit. If that's the case, you'd see a sudden drop when it gets closer to the 4GB limit and performs a full collection.

Alternatively, it's possible you have a memory leak in the application somewhere and it's going to run out of memory eventually, be unable to free any space, and then throw an OutOfMemoryError .

If it were me I'd profile & stress test the application under a testing environment with the same heap & GC options set to check the behaviour - that's really the only way to find out for sure.