title: Is "GC overhead limit exceeded" a secondary reason for failing?
body: <p>By motives of this question: <a href="https://stackoverflow.com/questions/1393486/error-java-lang-outofmemoryerror-gc-overhead-limit-exceeded">Error java.lang.OutOfMemoryError: GC overhead limit exceeded</a></p>
  
  <p>Recently I had a debate with someone about this error. </p>
  
  <p>In my understanding, this error itself can not be treated as a "primary" reason why JVM fails. </p>
  
  <p>What I mean is that an extensive garbage collection itself is not a reason for failing. The extensive garbage collection is always caused by a very little free memory amount, which causes a frequent GC invocation (and the core reason can be a memory leak). </p>
  
  <p>If I correctly understood the position of my opponent, he believes that a lot of small objects eligible for GC'ing produced in the system causes their frequent collection, what leads to this error. So the devil is not a memory leak or low memory limits, but the GC invocation frequency itself.</p>
  
  <p>Here is where we have different point of views. </p>
  
  <p>In my understanding it does not matter how many small objects eligible for GC'ing your process produces (even if it is not a good design and probably you should reduce this amount where possible). If you have enough memory, and there is no apparent memory leakage, then at some point the GC will collect big portions of such objects, so it should not be a problem. At least this will not cause a system crushing.</p>
  
  <p>To resume in brief <strong>my position</strong>: if you have <code>GC overhead limit exceeded</code>, then either you have a kind of memory leak, or you simply need to increase your memory limits. </p>
  
  <p>To resume in brief <strong>my opponent's position</strong>: if you produce a lot of small objects eligible for GC'ing, it is already a problem because this it self can cause <code>GC overhead limit exceeded</code>.</p>
  
  <p>Am I wrong and missing something?</p>