This is the mail archive of the
guile@sourceware.cygnus.com
mailing list for the Guile project.
Re: on the topic of GC.
- To: Michael Livshin <mlivshin at bigfoot dot com>
- Subject: Re: on the topic of GC.
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 09 Feb 2000 23:44:16 +0100
- 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
- Cc: djurfeldt at nada dot kth dot se
- References: <Pine.LNX.4.10.9909211003590.1017-100000@marvin.ida.ing.tu-bs.de> <s3ya8u8n3q.fsf@verisity.com>
Michael Livshin <mlivshin@bigfoot.com> writes:
> I am personally very interested to know of any garbage
> retention problems in long-running SCM/Guile programs on the SPARC.
> the stack handling on the SPARC is such that Boehm goes to
> considerable kludges to clean the stack whenever possible and safe.
> SCM/Guile's GC doesn't. so... any horror stories?
On the contrary: 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?
/* James Clark came up with this neat one instruction fix for
* continuations on the SPARC. It flushes the register windows so
* that all the state of the process is contained in the stack.
*/
#ifdef sparc
# define SCM_FLUSH_REGISTER_WINDOWS asm("ta 3")
#else
# define SCM_FLUSH_REGISTER_WINDOWS /* empty */
#endif
> > * 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.