This is the mail archive of the guile@sourceware.cygnus.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: on the topic of GC.


Mikael Djurfeldt <mdj@mdj.nada.kth.se> writes:

> I've used Guile for years on SPARCs without
> problems.  The following code form __scm.h seems to me like a
> sufficient kludge.  Why would anything more be required?

here's a relevant snippet from Boehm GC source.  it could be just
overt paranoia, of course...

/*
 * The following is a gross hack to deal with a problem that can occur
 * on machines that are sloppy about stack frame sizes, notably SPARC.
 * Bogus pointers may be written to the stack and not cleared for
 * a LONG time, because they always fall into holes in stack frames
 * that are not written.  We partially address this by clearing
 * sections of the stack whenever we get control.
 */

> > > * scanning the stack takes time.
> > 
> > peanuts, in my experience.  real peanuts.
> 
> I agree.  Also, remember that there's a whole lot of unnecessary
> registration/unregistration which we don't have to do.  I wouldn't be
> surprised if this overhead of the precise collector is greater than
> the stack scanning overhead of the conservative one.

yes.  there's not only the cycles to consider, but also cache misses,
which are very likely to be introduced when you chain your pointer to
some linked list (a-la Emacs) or increment a refcount or whatever.

--mike

-- 
I think we might have been better off with a slide rule.
                -- Zaphod Beeblebrox

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]