Re: VM crashes on big INBOX file ==> problem found!!!

[Richard Stallman]

    garbage collection is triggered and function mark_object() (in alloc.c)
    is recursively called about 29,885 times (see the backtrace info
    below)!!!  So many levels of mark_object() calls make the stack
    overflow, causing a segmentation fault.

I wonder if this indicates a bad choice of data structures.
mark_object calls itself recursively for many kinds of pointers,
but it is supposed to loop rather than recurse for cdr pointers.
This is so that long lists do not cause recursion.
Most data structures don't have a tremendous amount of nesting
in the car direction.

I wonder what sort of data structures made 29,885 recursive
calls necessary.  Perhaps we should change those data structures
or else change the garbage collector so it recurses less.

For instance, maybe a lot of this recursion goes thru symbols.  If so,
here is an idea.  Suppose that when mark_object finds a symbol which
is not yet marked, and is interned in the main obarray, it sets a bit
"needs to be marked" in the symbol.  Then increment a counter
which records how many symbols are in this state.

Then gc_sweep could end by scanning the main obarray over and over,
marking those symbols, until the counter goes to zero.

Depending on the nature of the problem, this might or might not
help much.  If the main data types involved are others,
a different solution might help.