Re: Garbage Collection questions

[Michael Livshin]

Sam Tregar <address@hidden> writes:

> On Sun, 13 May 2001, Sam Tregar wrote:
> 
> >    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.
> 
> Ok, I'm a fool.  I guess this works just the way I'd hoped -
> protect/unprotect maintain a count and nest properly.

that's one of the things I planned to mention once I wake up.  I see
it isn't needed anymore.  good. ;)

the protect/unprotect solution seems to be the only one applicable to
this case, as far as I see.  that's because you have no way to hook
onto the destruction of an arbitrary Scheme object.

[ if you could (and if all Scheme objects under the dual memory
  management are so-called "smobs", you can), you could use a nicer
  solution.  I guess the current GC interfaces are not really designed
  for interaction with Perl... ]

> Of course, I did have to read gc.c to find that out!
> 
> This stuff should definitely be documented better.  I'm willing to do some
> doc-migration of useful stuff from gc.c into a relevent .texi file.  Can
> someone point me to the right file and section?

well, in the Guile Reference Manual there is a section called
"Extending Applications Using Guile".  it should have a whole chapter
on GC, but doesn't yet.

do you feel the relevant comments in gc.c are OK as documentation?

> > 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?
> 
> gc.c also had some interesting comments on this question - the
> scm_remember_upto_here functions are a very strange hack indeed!  It seems
> that a sufficiently intelligent optimisizing compiler could defeat this
> mechanism...

a sufficiently sufficiently intelligent compiler could have a
non-contiguous stack and encrypt its contents, too.  we have to make
_some_ reasonable assumptions. ;)

-- 
I am not a Church numeral!
I am a free variable!