Can I force full garbage collection?

Question

Hi, my program is memory bound , as users load more files more memory is required , if the user decides to load a very large number of files they will eventually run out of memory. So I am trying to detect when there is less 15% of heap memory left, then force garbage collection and if it cant free up more than 15% of the heap I will stop the user from loading any more files. But the problem is though I call System.gc() to try and force a full garbage collect it rarely
retrieve enough memory to get below the 15% limit. But using the Yourkit Profiler I can select the Force GarbageCollection option and this always manages to free up more memory to get the figure under the 15% limit. in support of this I found that sometimes my program stop me loading more files when there is still quite a bit available.
So my questions are.
1. I know System.gc() is only hint to garbage collect, but the docs imply it only replys after the garbage collection (if any) has been done, is this right or do I have to wait.
2. Is there any way to Force complete Garbage Collectionas profiler appears to do.
3. is there a VM option I could set instead to force the JVM to completely garbage collect at say 83% so that if I then polled that 85% of heap was being used I would know that it really was, and I wouldnt need to bother trying to garbage collect further. (Im using Suns 1.6. JVM on Windows and Linux, and Apples 1.5 or 1.6 JVM on Macs)
public static void checkMemoryWhilstLoadingFiles() throws LowMemoryException
        MemoryUsage mu = ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
        //No max defined future proofing
        if(mu.getMax()==-1)
            return;
        if (mu.getUsed() > (mu.getMax()  *  0.85f))
            MainWindow.logger.warning("Memory low:" + mu);
            System.gc();
            MainWindow.logger.warning("Memory low gc1:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage());
            System.gc();
            MainWindow.logger.warning("Memory low gc2:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage());
            System.gc();
            MainWindow.logger.warning("Memory low gc3:" + ManagementFactory.getMemoryMXBean().getHeapMemoryUsage());
            mu = ManagementFactory.getMemoryMXBean().getHeapMemoryUsage();
            if (mu.getUsed()  > (mu.getMax()  *  0.85f))
                MainWindow.logger.severe("Memory too low:" + mu);
                throw new LowMemoryException("Running out of memory:"+mu.getUsed());
            else
                 MainWindow.logger.warning("Memory usage reduced to:" + mu);   
    }thanks for any help Paul
Edited by: paultaylor on 27-Jun-2008 11:10

Answer 1

On all of the current Sun HotSpot JVM's, calling System.gc() will cause a full compacting collection. Unless you have -XX:+DisableExplicitGC on your command line, in which case the call is a noop. Or if you are running the mostly-concurrent collector (-XX:+UseConcMarkSweepGC) and have the -XX:+ExplicitGCInvokesConcurrent flag on your command line, in which case calling System.gc() will start a concurrent collection (and the calling thread will block until the cycle is finished).
But calling System.gc() isn't enough to recover all the space that might be recovered. For example, System.gc() will identify objects that are unreferenced but need to have their finalize() methods called before their space becomes available again. So one call to System.gc() won't recover their space. Those finalize() methods need some cycles to run in, so back-to-back (or back-to-back-to-back :-) calls to System.gc() won't help. If you use a lot of finalize() methods, you should leave a lot of time for the finalize() methods to run between the calls to System.gc(). (Better would be to convert your code to use WeakReferences and run your own reference processing queues, and then you could tell when you were done processing references. But that's real work.) Some people try calling System.runFinalization() and wait for that to return, but that has at least two failure modes (details left to the reader).
In addition, there are details like: if there is still 15% of the heap free, then we won't aggressively clear SoftReferences when you call System.gc(). We might if you waited until the heap was full and we collected it on our own, since we know how much free space there will be after a collection at the point where we are choosing which SoftReferences to clear, and use that to decide how aggressively to clear SoftReferences.
There is no method to force the collector to do a compacting collection at, say 85% full. There is an option to have the mostly-concurrent collector start a collection cycle that way. But there's no way to find out if a collection cycle is running.
You are skating on the edge of the qualities of service offered by the different collectors in the various JVM's available. That weakens your ability to "write once, run anywhere".