So, moving on, what usually happens is that a "low memory" condition triggers a GC (usually a "full" GC). When the GC runs, it needs some memory to work with. If it cannot allocate memory for itself, it will die with an OOM. If the heap hasn't increased, yet, then the GC cannot allocate more objects on the heap to do it's thing. That can explain why you get an OOM when you are way under the heap "size" in the output of ps.
Hi Christopher, I have a doubt with respect to your explanation. Is there any difference between an OOM thrown within the GC thread, and any other OOM?
I mean, if an OOM is thrown within the GC, and it dies, the JVM looses its GC, so no memory can be deallocated, and the only way is to shutdown the JVM. But what happens if the OOM is thrown in any other thread? Is the JVM state preserved in this case?
As said in another post, generally speaking, an OOM leaves the JVM in a bad state. But, can this state be detected by checking the state of any of the JVM threads? I guess the GC should run in a thread I could get a reference from. If I check this reference liveness, could I determine if the OOM has affected the GC?
I have developed some web services that can return an important amount of data. Under high load, the server memory requirements can become huge, so I added a loop into the catalina script to restart my tomcat instance automatically, and added a filter that catches OOMs and forces a JVM shutdown, after writing some logs asking for more memory. I was wondering if I could reduce the shutdown condition to only the cases when the GC has died.
Greetings, Rodrigo Ruiz
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
