In JVM, "stop the world" is such an amazing word, but tons of works and researches in this area to reduce it effect when doing Garbage Collection (GC).
Recently, in JVM study, several GC collectors have been designed to achieve a better performance of our java application. And there are two ways to claim whether it's a good or excellent GC collector.
Have a good throughput.
Have a short pause time.
Terminology
Throughput: means the percentage that the time of application threads running in the time of total threads running (which including the time application threads consuming and GC threads consuming).
Pause time: means the time that all application threads are paused due to GC threads running.
Relationship
In ideal world, we want GC collector to achieve a high throughput and short pause time, but throughput and pause time is like the two sides of the coin. We can't achieve the best throughput and the shortest pause time at the same time.
In simple words, GC is running in a way that they need to run when reach to the safe point, when that GC need make sure that application threads would not change the status of all objects during the time GC threads are marking and cleaning the garbage objects. But each of the GC has additional overhead, for example, the content switch, consuming in cache, and security overhead in JVM lock mechanism. These are the additional overhead to run a GC every time.
If we want to have high throughput in our JVM performance, we need try to avoid these overhead during GC. In this case, less frequent GC is the solution to improve the throughput. Since we deal more objects at time to reduce the percentage spending on these additional overhead.
However, due to the much large objects need to scan, the time to implement a GC will increase. It would increase the time of each GC, which means pause time is increased.
Therefore, throughput and pause time is contradiction in GC world. We can't hold them together, a tradeoff between them is needed in different scenario.