Re: Collected crash information involving kkcc_marking, gc-incremental-traversal-threshold issue?

APA> I attached the lisp and c stack information files atend. Thanks, Adrian. This will take a while, though. APA> Secondly I found setting gc-incremental-traversal-threshold 100 times APA> higher than default avoids VM jumps during memory-intensive APA> operations. APA> Does this basically bring gc-incremental closer to being a gc-full? You probably don't see one incremental GC, because the average number of living Lisp objects on the Lisp heap is about 600,000--900,000 (in my tests, currently my instance has 696,528 living objects). The GC in your configuration always processes up to 1,000,000 living objects in each cycle, so the whole heap fits in one cycle and there is no incremental collection. APA> There are still situations where XEmacs VM growths in a big jump APA> of a couple hundred MB, but the situations are a lot rarer now. In my observations I see the growth in the virtual memory (with `top') but not in the Lisp heap (`show-object-memory-usage-stats'). Can you confirm this? I got a recipe from one of my colleagues who is using gnus with nnml folders: Open an nnml summary buffer with many (>2,000) mails, the virtual memory of the XEmacs process increases 200--300MB, the Lisp heap increases only 1--2MB. Even after I kill the summary buffer and force some full garbage collections the memory footprint does not shrink. So it looks more like a problem in some finalizers that do not free large chunks of additionally allocated memory (not Lisp heap) correctly than in the incremental algorithm. -- Marcus