[armedbear-devel] Ugh! java.lang.OutOfMemoryError: PermGen space
(dotimes (i 100000) (compile 'f (lambda () 42))) abcl dies with java.lang.OutOfMemoryError: PermGen space if I use nil instead of f it doesn't die. Also with nil is noticeably faster. Adding (when (= 999 (mod i 1000)) (room)) in the loop shows that gc is performed and memory is reclaimed, but apparently there's a leak somewhere. I'll try to find out more. Later, Ale
On 9/24/09 9:21 PM, Alessio Stalla wrote:
(dotimes (i 100000) (compile 'f (lambda () 42)))
abcl dies with java.lang.OutOfMemoryError: PermGen space
if I use nil instead of f it doesn't die. Also with nil is noticeably faster.
Adding (when (= 999 (mod i 1000)) (room)) in the loop shows that gc is performed and memory is reclaimed, but apparently there's a leak somewhere.
Note that 'PermGen' space is different then running out of heap space. Among other things, 'PermGen' holds class metadata for every loaded class. Since we are compiling 10^6 new classes here (and they really are different at a JVM level) what I think is happening is that we eventually exhaust the available space. I've been able to reproduce your error running under the NetBeans 6.7 profiler, but I am unable to exactly confirm this hypothesis as I don't think it has access to information on the PermGen space (or at least I haven't found out how to access it). Creating a 'build.properties' with java.options=-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled (all on one line) should should allow garbage collection of the class instances, but it still crashes the OS X JDK6, so I don't I am necessarily on the right track here. More investigatin' -- "A screaming comes across the sky. It has happened before, but there is nothing to compare to it now."
On Sat, Sep 26, 2009 at 2:40 PM, Mark Evenson <evenson@panix.com> wrote:
On 9/24/09 9:21 PM, Alessio Stalla wrote:
(dotimes (i 100000) (compile 'f (lambda () 42)))
abcl dies with java.lang.OutOfMemoryError: PermGen space
if I use nil instead of f it doesn't die. Also with nil is noticeably faster.
Adding (when (= 999 (mod i 1000)) (room)) in the loop shows that gc is performed and memory is reclaimed, but apparently there's a leak somewhere.
Note that 'PermGen' space is different then running out of heap space. Among other things, 'PermGen' holds class metadata for every loaded class. Since we are compiling 10^6 new classes here (and they really are different at a JVM level) what I think is happening is that we eventually exhaust the available space.
I've been able to reproduce your error running under the NetBeans 6.7 profiler, but I am unable to exactly confirm this hypothesis as I don't think it has access to information on the PermGen space (or at least I haven't found out how to access it).
Yes, sorry for taking it for granted - I was aware that the "PermGen" holds compiled classes, in fact the very same error can happen on Java application servers that allow hot redeploy, when in certain circumstances classes are not properly garbage collected.
Creating a 'build.properties' with
java.options=-XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled
(all on one line) should should allow garbage collection of the class instances, but it still crashes the OS X JDK6, so I don't I am necessarily on the right track here.
It is unclear to me how this is supposed to work: I have found references to the xnoclassgc option to disable class gc (suggesting it is enabled by default) and to the options you mention (which instead suggest it is not!). However since classes are generated both in the (compile 'f) and the (compile nil) case but only the former leads to the error, I believe the culprit is in abcl's code rather than in class gc in general, specifically in the part that associates a compiled function with a symbol.
participants (2)
-
Alessio Stalla -
Mark Evenson