title: Is compaction really inevitable for all JVM GC implementations?
body: <p>On this <a href="http://www.azulsystems.com/technology/c4-garbage-collector" rel="nofollow">link</a> it is said that:</p>
  
  <blockquote>
    <p>These pauses are the result of an inevitable requirement to compact
    the heap to free up space. Collectors use different strategies to
    delay these events, but <strong>compaction is inevitable</strong> for all commercial
    available collectors.</p>
  </blockquote>
  
  <p>I was under the impression that if you keep the memory footprint of your application constant then there is no need for GC compaction to occur, in other words, it will only happen if you keep adding and collecting objects. If you have a big enough heap with enough free space, why would you ever need to compact when you are not creating any holes (i.e. not generating any trash) ?</p>
  
  <p>I understand that keeping a constant memory footprint for a Java application is not easy, but it is possible with the right profiling tools, bootstrapping and discipline.</p>
  
  <p>So isn't it reasonable to assume that with a constant memory footprint a Java application can run without any GC-introduced latencies, in other words, with no GC pauses?</p>
  
  <p><strong>EDIT:</strong> By constant memory footprint I mean a <code>steady state</code> as mentioned by Ajay George, when no more objects are created or de-referenced. If you keep creating objects you will eventually run out of memory and if you keep de-referencing objects you will eventually trigger the GC. So the ultimate goal is to startup, warmup, force a full GC and then enter steady state for production time.</p>