Question

Page 6 of the the document Memory Management in the Java
HotSpot™ Virtual Machine contains the following paragraphs:

Young generation collections occur relatively frequently and are
efficient and fast because the young generation space is usually small
and likely to contain a lot of objects that are no longer referenced.

Objects that survive some number of young generation collections are
eventually promoted, or tenured, to the
old generation. See Figure 1. This generation is typically larger than the young generation and its occupancy
grows more slowly. As a result, old generation collections are infrequent, but take significantly longer to
complete

Could someone please define what “frequent” and “infrequent” mean in the statements above? Are we talking microseconds, milliseconds, minutes, days?

Answer 1

It is not possible to give a definite answer to this. It really depends on a lot of factors, including the platform (JVM version, settings, etc), the application, and the workload.

At one extreme, it is possible for an application to never trigger a garbage collector. It might simply sit there doing nothing, or it might perform an extremely long computation in which no objects are created after the JVM initialization and application startup.

At the other extreme it is theoretically possible for one garbage collection end and another one to start within few nanoseconds. For example, this could happen if your application is in the last stages of dying from a full heap, or if it is allocating pathologically large arrays.

So:

Are we talking microseconds, milliseconds, minutes, days?

Possibly all of the above, though the first two would definitely be troubling if you observed them in practice.

A well behaved application should not run the GC too often. If your application is triggering a young space collection more than once or twice a second, then this could lead to performance problems. And too frequent “full” collections is worse because their impact is greater. However, it is certainly plausible for a poorly designed / implemented application to behave like this.

---

There is also the issue that the interval between GC runs is not always meaningful. For instance some of the HotSpot GCs actually have GC threads running concurrently with normal application threads. If you have enough cores, enough RAM and enough memory bus bandwidth, then a constantly running concurrent GC may not appreciably affect application performance.

Terminology note:

• Strictly speaking a concurrent GC is one where the GC can run at the same time as the application threads.
• Strictly speaking a parallel GC is one where the GC itself uses multiple threads.
• A GC can be concurrent without being parallel, and vice versa.