Re: Out-of-Memory Handling in Long-Running / Server Applications

Jeff Kesselman wrote:

> Its also unnecessary.  By the definition of the language you will
> *never* get a OOM exception until a best effort
> has been made to reclaim the needed memory.  Trying to GC again will
> simply return the same result.

This doesn't seem to hold true.

It seems like if the memory is fragmented when a large chunk of memory
is needed (my theory there..!), so that there isn't immediately enough
continuous memory avalable, the JVM might throw an OOM even though a
full reorganization of the memory would have solved the problem. Garbage
collection does such a reorganization. So if I do just that (catch OOM,
ask for GC by System.gc(), wait a little, and then repeat), things
magically resolves.

The OOM might itself be a GC-trigger - when the JVM starts throwing OOMs
around, it'll schedule a GC for "RSN".

For non-compacting collectors, this is even obvious, and can't be
remedied: if the memory is for a long time allocated in small chunks,
and then you suddenly want 50% of the JVM's memory, there will most
probably not be a large enough chunk available, and the GCing won't fix
it either.

What you state is that as you approach the heap limit, every memory
allocation that breaks the limit shall _actually_ force a _full_ GC.
This would be noticeable on the instantiation of objects - it would
obviously become very slow, every instantiation that ends up with an OOM
would take several seconds (and due to "stop-the-world" parts of a GC
cycle, all other threads would get this too). This isn't what I see.

Endre.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com