Re: Garbage Collection questions

[Sam Tregar]

On 14 May 2001, Michael Livshin wrote:

> but it does seem to me that the GC got you more scared than it should
> have.  it's actually very simple to tame if you stick by a very small
> amount of very simple rules.

Ok.  What simple rules?  Are they in the docs somewhere I haven't looked?
The discussion the SMOB doc really got me worried - the difference between
the "good" code and "bad" code is very subtle.

Let me give you an example of what I'm trying to make work.  I'll allow
Perl programmers to bind Perl variables to SCMs.  As long as the Perl
variable is still "live" I don't want the SCM to be GC'd even if no Guile
code can reach it.

It's very easy to tell if a Perl variable is still live - just check to
see if it's refcount is >0.  It's also easy to attach code to object
destruction.  My first thought was to do a scm_protect on binding and an
scm_unprotect on destruction.  The problem is that more than one Perl
variable may bind to one SCM.  This could result in:

   bind $foo to SCM "bar" -> scm_protect
   bind $baz to SCM "bar" -> scm_protect
   destroy $foo           -> scm_unprotect
   SCM "bar" GC'd
   destroy $bar           -> scm_unprotect (core dump)

Ugh.  I've got a few ideas on how to address this but none of them are
pretty.

> [ hey, it's a key feature of Guile that it has maximally trouble-free
>   interaction with C code! ]

Well, that may be true, but that doesn't mean it has a reasonably
trouble-free interaction with Perl!

> the GC magically scans two areas: the C stack and the registers.  if
> `result' is a static/global variable (i.e. sits neither on the stack
> nor in the registers), then GC won't retain the result of cons, so you
> should explicitly tell the GC to spare it.

How do I know if a C variable is in the registers or not?  Isn't that
something the compiler keeps you from knowing at any given point?  Are
there some simple rules I can learn as to wether an SCM created in C needs
protection?

-sam