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

[stephen at xemacs.org]

Marcus Crestani writes:

 > >>>>>"SJT" == Stephen J Turnbull <stephen at xemacs.org> writes:
 > SJT> If I do M-x gnus-mime-save-part-and-strip on a fairly big
 > SJT> attachment (say 5MB, IIRC) I can get a process to go from 150MB
 > SJT> to 800MB in a real hurry (in terms of the number of XEmacs
 > SJT> commands---of course on a 450MHz machine with 256MB of RAM, in
 > SJT> terms of seconds it easily goes into the 000s).  But that
 > SJT> instance does not have newgc configured.  I suspect it has
 > SJT> something to do with KKCC, but I haven't tried configuring
 > SJT> without KKCC yet.

 > Does the memory footprint shrink again?

Sometimes it will fluctuate by 1-2%, but I've never seen it drop by as
much as 5%.  What's worse is that the resident set seems to want to
grow proportionally to VSIZE, but once RSIZE hits 50% or 60%, its
growth slows while performance decreases.  Nor does the resident set
when XEmacs is active ever seem to decrease by very much.

Unfortunately this behavior tends to hit when I'm doing something
urgent for my day job (of course the worst offenders at sending
multi-megabyte files multiple times tend to have names like "Boss" or
"Boss**2").

 > Yes, everything is supposed to be allocated on the Lisp heap, but we
 > are not there yet.  We still need to convert many additionally
 > allocated objects to Lisp objects.

OK.

For (space) performance analysis and debugging, would it be possible
to just replace xmalloc with something that wraps all allocated memory
in a special opaque, maybe even with a special signature so you could
identify specific leaks?  Sort of a sledgehammer check for KKCC.