java.lang.OutOfMemoryError: GC overhead limit exceeded

The OOM: "GC overhead limit exceeded", only means that Full GC is doing much work for nothing. Too much time is being spent on Garbage collection while the collection it self recover less than 2% of the heap.

Accordingly this OOM can only occurs in two different GC algorithm, such as:

• Parallel Collection: Parallel's automatic tuning, provide a maximum pause time. 

• Concurrent Collection: The concurrent collector pauses an application twice during a concurrent collection cycle.

Only collections in which application is stopped, and is due to concurrency mode failure or explicit collection request. This OOM is to prevent applications to be stopped for a long period of time while collecting on a small heap.


Possible Solutions:

• Use another GC algorithm;

• Check if your heap is too small to run Parallel or Concurrent GC. If this is the case tune your heap size accordingly;

• Turn off this feature by using: -XX:-UseGCOverheadLimit. This flag replaced the  UseGCTimeLimit, in which is referenced on the CR 6287811; 

• Try use the -XX:MaxGCPauseMillis=n, in which the GC will try its best to achieve this value. No promises made on this one. 

Bug:
      The CR 6287811, is about the log output error in which mislead many people in thinking there were an issue with the heap:

• before: "java.lang.OutOfMemoryError: Java heap space";
  
  
• now: "java.lang.OutOfMemoryError: GC overhead limit exceeded";
  
  

Doc:

-XX:+UseGCOverheadLimit

Use a policy that limits the proportion of the VM's time that is spent in GC before an OutOfMemory error is thrown. (Introduced in 6.)

ref:

• http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
• http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html
• http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6287811