PDA

View Full Version : java.lang.OutOfMemoryError: GC overhead limit exceeded


Barry
10-09-2008, 12:14
Today I ran into an interesting error while starting my application.
The whole stacktrace would be pointless and boring to post here so I only included the first line.
Sun actually has information on this item after some Google searching: Sun page (http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html#par_gc.oom)


Excessive GC Time and OutOfMemoryError

The parallel collector will throw an OutOfMemoryError if too much time is being spent in garbage collection: if more than 98% of the total time is spent in garbage collection and less than 2% of the heap is recovered, an OutOfMemoryError will be thrown. This feature is designed to prevent applications from running for an extended period of time while making little or no progress because the heap is too small. If necessary, this feature can be disabled by adding the option -XX:-UseGCOverheadLimit to the command line.


In my case it seems to be an endless loop (my bad) which uses CopyOnWriteArrayList.
Hope this helps anybody in the future

holeinone
13-09-2008, 21:55
In triggering obscure Exceptions out of the JVM.
Nice job Barry!
Good to know our pals at SUN have this safety net build in.

kjkoster
06-11-2009, 13:54
Dear All,

I noticed that we got a link to this page from this mailing list (http://services.renderx.com/lists/xep-support/5954.html). From the response on that list I see that the poster thinks that the cause of these exceptions are infinite loops. That is not (always) the case.

The core of this issue is that you have just barely enough memory to satisfy the memory requirements of your code, but that to remain alive, the GC has to work-work-work.

On the mailing list post, the original poster says he is processing a large XML document. If that document had been smaller, the app would not have died this way. If the document were bigger, he would have gotten 'normal' out of memory errors.

Steps to revolve:

1) Optimize your code to use less memory and
2) assign more memory to the JVM to work in.

The usual order is to first do 2) and then wait for management to stop yelling at you about production issues. Once some form of (slow) normality is restored for the production systems, you proceed to implement 1).

Kees Jan