Java OutOfMemoryError - Sanity Check
Just for my sanity, before an OutOfMemoryError is thrown, the garbage collector should do everything it can to free up more memory right? What I'm seeing now is that the JVM does a partial GC, throws an OutOfMemoryError and then decides to actually do a full GC which frees up enough RAM to get things working again.
Very annoying and I'm not sure what I can do about it. There are definitely no remaining references, but I still can't get that memory back.
May 1st, 2007 at 12:22 am
I believe this can happen when you are allocating a large amount of memory in a loop, so you’re not giving the GC chance to clean up - it does run at a lower priority than your code, usually.
You can probably fix this by calling System.gc() sometimes, although even if that works it isn’t intended to be reliable.
Are you allocating large blocks (10s of megabytes) at a time? Perhaps if you allocate smaller blocks at a time the GC would behave differently. Also, it may be worth tinkering with the command line VM options.
May 1st, 2007 at 6:02 am
Sadly, it's an applet. The simple test case allocates a lot of RAM at once, but the actual applet is just a real-world application. It winds up using a fair bit of RAM, but not all at once and there's plenty of time for the GC to catch up. Even with the simple test, the loop is actually refreshing the browser page and you can leave 10 minutes between refreshes and see the problem.
As it turns out, the problem is that the applet is not available for garbage collection because Swing's offscreen buffer holds on to a reference to it (which it shouldn't).
See http://www.symphonious.net/2007/04/26/japplet-memory-leaks/
Also, this is now Sun bug 6550586: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6550586