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

[Marcus Crestani]

>>>>>"APA" == Adrian Aichner <adrian at xemacs.org> writes:
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