Re: gh_enter reconsidered

[John Jannotti <jj@lcs.mit.edu>]

> Did your message get cut off? 

Yes, I had put '.' on a line by itself making a vertical ellipsis.
smtp says that's end of message....

I was trying to say:

Since I claimed the Boehm collector already went through the trouble
of finding the start of the stack on many architectures, I decided to
see how.

http://reality.sgi.com/employees/boehm_mti/gc_source/gc.tar.Z

>From config.h:

/*
 * For each architecture and OS, the following need to be defined:
 *
 * (some elided)
 *
 * DATASTART is the beginning of the data segment.
 * On UNIX systems, the collector will scan the area between DATASTART
 * and DATAEND for root pointers.
 *
 * DATAEND, if not &end.
 *
 * (some elided)
 *
 * STACKBOTTOM is the cool end of the stack, which is usually the
 * highest address in the stack.
 * Under PCR or OS/2, we have other ways of finding thread stacks.
 * For each machine, the following should:
 * 1) define STACK_GROWS_UP if the stack grows toward higher addresses, and
 * 2) define exactly one of
 *      STACKBOTTOM (should be defined to be an expression)
 *      HEURISTIC1
 *      HEURISTIC2
 * If either of the last two macros are defined, then STACKBOTTOM is computed
 * during collector startup using one of the following two heuristics:
 * HEURISTIC1: Take an address inside GC_init's frame, and round it up to
 *             the next multiple of STACK_GRAN.
 * HEURISTIC2: Take an address inside GC_init's frame, increment it repeatedly
 *             in small steps (decrement if STACK_GROWS_UP), and read the value
 *             at each location.  Remember the value when the first
 *             Segmentation violation or Bus error is signalled.  Round that
 *             to the nearest plausible page boundary, and use that instead
 *             of STACKBOTTOM.
 *
 * If no expression for STACKBOTTOM can be found, and neither of the above
 * heuristics are usable, the collector can still be used with all of the above
 * undefined, provided one of the following is done:
 * 1) GC_mark_roots can be changed to somehow mark from the correct stack(s)
 *    without reference to STACKBOTTOM.  This is appropriate for use in
 *    conjunction with thread packages, since there will be multiple stacks.
 *    (Allocating thread stacks in the heap, and treating them as ordinary
 *    heap data objects is also possible as a last resort.  However, this is
 *    likely to introduce significant amounts of excess storage retention
 *    unless the dead parts of the thread stacks are periodically cleared.)
 * 2) Client code may set GC_stackbottom before calling any GC_ routines.
 *    If the author of the client code controls the main program, this is
 *    easily accomplished by introducing a new main program, setting
 *    GC_stackbottom to the address of a local variable, and then calling
 *    the original main program.  The new main program would read something
 *    like:
 *
 *              # include "gc_private.h"
 *
 *              main(argc, argv, envp)
 *              int argc;
 *              char **argv, **envp;
 *              {
 *                  int dummy;
 *
 *                  GC_stackbottom = (ptr_t)(&dummy);
 *                  return(real_main(argc, argv, envp));
 *              }
 */

This is followed by a slew of ifdef, define define define, endif
clauses, one for each architecture.

I don't know guile too well, except by lurking on the list, but it
sound like that last bit is essentially equivalent to the gh_enter()
mechanism.  But for most architectures, they do much better.

It would be nice to keep in mind a point that this comment makes.
Since the collector is conservative, it suffices to have a
conservative estimate of STACKBOTTOM.  If the collector scan an extra
page or something, no big deal.

I think HEURISTIC2 is particularly snazzy, in a sick, disgusting way.

  jj