This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: on the topic of GC.
- To: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Subject: Re: on the topic of GC.
- From: Michael Livshin <mlivshin at bigfoot dot com>
- Date: 10 Feb 2000 11:25:34 +0200
- Cc: Dirk Herrmann <dirk at ida dot ing dot tu-bs dot de>, Jim Blandy <jimb at red-bean dot com>, guile at sourceware dot cygnus dot com, djurfeldt at nada dot kth dot se
- Organization: who? me?
- References: <Pine.LNX.4.10.9909211003590.1017-100000@marvin.ida.ing.tu-bs.de> <s3ya8u8n3q.fsf@verisity.com> <xy7g0v2t2rj.fsf@mdj.nada.kth.se>
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