Wolfram Fenske <int2k@gmx.net> wrote:
+---------------
| "goose" <ruse@webmail.co.za> writes:
| > When running under cmucl, I get the following messages (repeatedly
| > with the memory size constantly increasing).
| > ; [GC threshold exceeded with 12,009,624 bytes in use. Commencing GC.]
| > ; [GC completed with 182,952 bytes retained and 11,826,672 bytes freed.]
| > ; [GC will next occur when at least 12,182,952 bytes are in use.]
...
| > What am I doing wrong here? I've tried the same code with clisp
| > and I've gotten no messages of this sort.
|
| I'm quite sure you're not doing anything wrong. What you see here is
| just CMUCL's garbage collector being a little verbose.
+---------------
Just (SETF *GC-VERBOSE* NIL) if you don't like it. Often things one
does will cons a *lot* of intermediate results that quickly becomes
garbage. A minor GC in CMUCL is quite cheap [see below], so it's common
to simply turn off those messages while you're doing exploratory coding.
Later, when you've compiled everything and added enough type declarations
that CMUCL isn't boxing all those intermediate results, you might turn
*GC-VERBOSE* back on to investigate your remaining "opportunities" for
improvement.
+---------------
| > Is this a memory leak that I should be worried about or will the
| > memory usage eventually stabilise?
|
| The memory use will stabilize at some point.
+---------------
*Very* probably! I support a persistent application server [that sits
behind Apache] written in CMUCL, and it's been up for >75 days [since
the system last rebooted for a kernel upgrade], and the "bytes retained"
has stabilized fairly quickly [less than a dozen GCs] at ~3.5 MB, with
the "threshold exceeded" being ~15.5 MB, and now it just ticks along
doing a GC every 2-3 hours when idle[1], more often when busy. So in
any reasonable application it *will* stabilize at some point, as Wolfram
notes.
+---------------
| My guess is that CMUCL uses a generational garbage collector.
+---------------
On some platforms, yes, specifically on x86.
+---------------
| This means that during a so-called /minor collection,/ a generational
| garbage collector only collects garbage in the youngest generation,
| since it's much more likely to find unused objects there than in older
| generations. To avoid memory leaks, the objects in the older
| generations have to be scanned as well, of course. This is done
| during the so-called /major collections./ But because they take
| longer, these are executed less frequently than the minor
| collections.
+---------------
Exactly.
+---------------
| What I mean to say is: memory usage will stop increasing when CMUCL's
| garbage collector finally decides to execute a major collection. It's
| up to the garbage collector to decide when exactly it's time to do that.
+---------------
Or you can force one with (GC :FULL T), per my other parallel reply.
-Rob
[1] I'm using CMUCL threads, with the scheduling interval set
fairly low, and the MP scheduler seems to generate a low but
continual background rate of garbage even when the application
server is "idle". I should look into at that someday... ;-}
-----
Rob Warnock <rpw3@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607