What conditions would prevent the JVM from running a FULL Garbage Collection?

It depends entirely on the garbage collector algorithm that you're using in your particular JDK. About all you can guarantee about garbage collection is that if the JVM throws an OutOfMemoryError, the garbage collector made its best effort to collect every unreachable/weakly reachable object. Even System.gc() doesn't guarantee anything, a no-op is a completely legal implementation.

Hence in that light I don't know if your question has any weight. If you truly believe that you need to tweak the garbage collector, it would help if you posted the problems you're seeing, and the profiling data that leads to believe that poor GC performance is the problem.

Outside of this, the garbage collector should be treated like a black box. The logic behind its implementation is surprisingly complex, and there's a very good chance it knows better than you what it ought to be doing at any given time. 99 times out of 100, trying to force the garbage collector to behave in a particular way will lower performance, not increase it.

Let me explain more... I do NOT get OOM errors. What I have is an application that is creating a LARGE amount of objects, and uses up 70% to 97% of memory before running a FULL GC. Shallow GC's do not reclaim this memory, but once a FULL GC is run, the used memory goes back to around 40%, then starts climbing again. SO: Why would FULL GC not run at 50% used memory as stated by -XX:CMSInitiatingOccupancyFraction=50 but only run at such a HIGH level? Is this because the JVM is busy? It is not because the objects are being used, because once t

Mick Knutson 2010-08-13 17:20:37

Current settings:------------------XX:+UseConcMarkSweepGC-XX:+CMSIncrementalMode-XX:+CMSIncrementalPacing-XX:CMSIncrementalDutyCycleMin=0-XX:CMSIncrementalDutyCycle=10-XX:+UseParNewGC-XX:+CMSClassUnloadingEnabled-XX:MaxGCPauseMillis=250-XX:MaxGCMinorPauseMillis=100-XX:SurvivorRatio=128-XX:MaxTenuringThreshold=0-XX:CMSInitiatingOccupancyFraction=50-XX:NewSize=256m-XX:MaxNewSize=256m-XX:PermSize=160m-XX:MaxPermSize=160m

Mick Knutson 2010-08-13 17:21:08

I am aware that I can not force the GC to run. But I want to know why the JVM thinks it should NOT run if the used memory is at 90%+ used memory? There must be some valid reason.

Mick Knutson 2010-08-13 17:28:23

As a workaround, I created a simple app that checks the memory used. If it is **>50%** then issue a `System.gc()` which is just asking the JVM to run a GC, not forcing it.This keeps the used memory between 50% and 60% used memory and does not get to an Alert Threshold point.But, I do not want this long term.

Mick Knutson 2010-08-13 17:36:47

@Mick Knutson: Your settings make no sense. You're specifying what seems to me to be incompatible settings with UseConcMarkSweepGC and UseParNewGC, and you're also setting [CMSIncrementalMode, which will cause CMSInitiatingOccupancyFraction to be ignored](http://forums.sun.com/thread.jspa?messageID=9536408#9536408). Perhaps [this article on the available GC choices](http://blogs.sun.com/jonthecollector/entry/our_collectors) may help clarify things for you.

Daniel Pryden 2010-10-28 03:32:10

If the program deliberately threw an `OutOfMemoryException`, would that have an effect? Of course, at some point the same exception would also have to be caught to prevent it from halting the program...

FrustratedWithFormsDesigner 2010-08-13 15:44:43

@FrustratedWithFormsDesigner: No, `OutOfMemoryException` has nothing (directly) to do with the GC. If the GC runs but you've got a memory leak (ie: objects in memory the GC won't collect because you're still referencing them), you'll get a OOME. What good would running the GC again do? It already ran! OOME is something the programmer has to deal with, not the GC.

Brian S 2010-08-13 15:48:33

@FrustratedWithFormsDesigner - as Brian says, this will not achieve the desired effect. I meant solely when the *JVM* "legitimiately" throws this error due to being unable to allocate needed memory - I'll correct my answer to communicate this accordingly.

Andrzej Doyle 2010-08-13 16:33:54

+1. Even explicitly telling the GC to run is not a guarantee that it will run in Java.

Brian S 2010-08-13 15:45:54

+1 - a more succinct and elegant expression of the point I was trying to put across.

Andrzej Doyle 2010-08-13 16:35:40

ansaurus

tags:

views:

answers:

What conditions would prevent the JVM from running a FULL Garbage Collection?

related questions