Re: guile and emacs and GC

Re: guile and emacs and GC

[Ken Raeburn]

Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se> writes:
> Ken Raeburn <raeburn@raeburn.org> writes:
> 
> > 2) he's got some "issues" with Guile's implementation decisions,
> > including the use of conservative GC.  What he's saying makes sense,
> > so I'll be looking a bit at separating further into "Lisp" vs "general
> > Scheme" vs "Guile" bits what I've done so far.  (GC will be an
> > interesting issue though; I've got some thoughts on that.)
> 
> I'm curious about what he has to say on Guile implementation
> decisions.  Could you give me a reference?

Just some personal mail, which I don't want to redistribute without
his permission.  I did ask him if he wanted to join this list, but I
haven't heard anything back since.  Maybe the mail got misplaced; I'll
check again.

He does have some stuff at
http://www-pu.informatik.uni-tuebingen.de/users/sperber/xemacs/next-generation/gc.html
regarding GC, including partial archives of a discussion on a GC
mailing list.

> Also, regarding conservative GC, making a generic interface to the
> Scheme interpreter is no solution.  If you have an interface which
> would work for both an interpreter using a conservative GC and one
> using precise GC, you could just as well take the one with precise GC.

Yes, that would be the thing to do.  My problem is, Emacs is my only
source of experience with a precise GC implementation.  If the
interface needs to look like something other than the GCPRO stuff,
I'll have to find out what....

A decision to go down the conservative GC path would be difficult to
reverse, compared to starting with precise GC and then going to
conservative GC.

If there were a way to easily indicate that some regions of the stack
needed conservative GC (default), and certain others could have all
their data precisely marked...but the C calling conventions on some
machines are just too weird for that without assembly code support.

There are other issues with the generic Scheme interface.  I'd really
love to be able to assume the existence of many of Guile's features.
Threads and modules come to mind, there may be more.  And they need to
be accessible from C.

> The major gain of conservative GC is that the interface becomes
> simpler and less bug prone.
> 
> I have only limited experience in running Guile for longer times, but
> I have had scwm running for several days without problems, and a
> friend of mine has a server application which also runs for long
> without problems.  This makes me doubt that there is a problem in
> practise with using conservative GC.

I'm inclined to think that requiring conservative GC would be easier,
but I don't want to make that into a wedge between the Emacs and
XEmacs camps.  If keeping precise GC support in for example the
subprocess code would allow XEmacs to use it, and removing it would
mean they wouldn't use it, I'd rather keep it.  Of course, testing it
while using Guile would be quite a trick.

I don't know what the chances are that we can produce a common Scheme
base for Emacs and XEmacs, but it's very tempting to try.

Ken