Re: Is my procedure getting GCed?

[Dirk Herrmann]

On 15 May 2001, Michael Livshin wrote:

> > BTW, roots for gc would also allow us to get rid of the scm_sys_protects
> > array and thus allow to put the corresponding definitions at the places
> > where they belong.
> 
> I'll implement it, then.  (tomorrow, probably).
> 
> some questions:
> 
> should I make scm_register_root nest like scm_protect?

Hmmm.  I don't know.  At the moment, I can not think of situations where
nesting would be necessary.  Possible roots are global variables and SCM
values on the non-gc controlled heap.  For global variables, it seems
natural to register them as a root once, namely in the C file where the
variable is declared.  For non-gc controlled heap, it seems natural to
register the corresponding addresses at the place where the memory is
allocated or initialized, and to unregister them at the point where the
memory is freed.

It is a different thing with scm_protect, since you typically don't want
to protect a SCM value at the moment of its construction.  You rather
protect it at places where the reference might become invisible for the
gc.  At these places, however, you don't know whether the value might have
been protected alredy by some other function.  Thus, the need for nesting
behaviour of scm_protect is obvious, but for registering roots is isn't.

BTW:  scm_gc_register_root or something seems clearer.

> do you share my dislike of the name `scm_protect'?  I think it's not
> very clear, it should be `scm_protect_from_gc' or somesuch.

Yes, that's better.  I assume we will be able to get rid of a couple of
calls to scm_protect anyway as soon as roots are implemented.  The
remaining ones should be few, thus a renaming should be no big effort.  We
need to deprecate the old names for a while, though.

Maybe the gc related functions should use a scm_gc_ prefix?
  * scm_gc_[un]register_root
  * scm_gc_[un]protect_object
Some functions already use this prefix.

Best regards,
Dirk Herrmann