0

When I start JVM it reserves at least {{xms}} memory, right? That means this memory is private for JVM process (it is malloced), yes? When JVM needs to increase heap at reserves (mallocs) more memory. But how much? I do not believe it reserves exactly as much as it needs, probably there is certain step (pool?) size.

How this "step size" could be configured?

And all that happens until {{xmx}} is reached and OOM is thrown, right?

When JVM starts GC? Not when it comes to xmx, but when it comes to reserved heap size (top of this pool)?

If so, it is much better to set xms close to xmx to prevent many useless GCs. I will have one huge GC instead of many little ones, bug every GC freezes my JVM, so it is better to have one, right?

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
user996142
  • 2,753
  • 3
  • 29
  • 48

2 Answers2

5

When JVM needs to increase heap at reserves (mallocs) more memory. But how much?

You shouldn't really care. It just works. Many advice using equal Xmx and Xms so that JVM allocates all the memory at startup. This is reasonable, read further.

How this "step size" could be configured?

It can't, it is completely implementation and probably OS dependant.

When JVM starts GC? Not when it comes to xmx, but when it comes to reserved heap size (top of this pool)?

GC is a bit more complicated than you think. Minor GC is executed when young generation is filled up. Major GC is called there is no more space left in old generation.

And all that happens until {{xmx}} is reached and OOM is thrown, right?

No, when Xmx is reached, JVM stabilizes and nothing wrong happens. OutOfMemoryError is thrown when, immediately after GC, JVM is unable to find enough space for new object (this is a major simplification).

If so, it is much better to set xms close to xmx to prevent many useless GCs.

Once again, you must learn how GC works. Using Xmx equal to Xms is a good choice because it avoids unnecessary allocations when application runs (everything happens on startup, no further overhead). GC has nothing to do with that.

instead of many little ones, bug every GC freezes my JVM, so it is better to have one, right?

Nope. Minor GC usualy takes tens of milliseconds and is almost invisible, unless you are working on a real-time system. Major (stop-the-world) GC might take few seconds and is certainly noticeable for end users. In a correctly tuned JVM major GC should occur very rarely.

Tomasz Nurkiewicz
  • 334,321
  • 69
  • 703
  • 674
  • regarding minor vs major collections just make sure that your -Xmn i.e. your eden to tenure heap ratio is not too small. I think default is 1:3, but I usually prefer 1:10. But this totally depends on your application. – ddd Jul 27 '12 at 21:31
0

You are correct about the meaning of the switches.

The way I remember the switches is

xm*s* = Ends with "s" like "*s*tarting memory".

xm*x* = Ends with "x" like "ma*x*imum memory"

It is up to a given JVM to decide how to move from the starting memory to the maximum memory. Assuming the two are not trivially close to each other, the allocation will happen in steps on all JVM's I'm aware of.

I'm not aware of any option to control the size of the steps in any JVM. There is certainly no standard option.

Different JVM's have different GC strategies. Some JVMs allow you to use one of multiple GC strategies, controlled by a command line switch.

Eric J.
  • 147,927
  • 63
  • 340
  • 553