Re: GC questions.

[Michael Livshin <mlivshin at bigfoot dot com>]

Han-Wen Nienhuys <hanwen@cs.uu.nl> writes:

> * I am puzzled by GUILE_NEW_GC_SCHEME. What is it? Why is it optional?
> It makes reading gc.c a pain.

it's "optional" (it's more correct to say that the old scheme is
optional) because it's new.  I don't remember any bug reports about GC
problems in last two months' CVS Guile, so perhaps it's time to
completely remove the old scheme.  what does The Gang of Four think?

> * Why does gc.c use malloc for getting more heap? Wouldn't it be
> quicker/easier to skip malloc and do a mmap("/dev/zero") directly?

presumably the system malloc knows the quickest way to get the raw
memory, and the quickest way is not always mmap.  that said, we may
still want to use mmap because it makes it easier to control large
block alignment (i.e. you can tell it the address you want the memory
to appear at, and you have some chance that the request will be
granted).  we'll see.

> * The 2nd paragraph explanation for scm_[un]protect_object is
> convoluted: there is no reference count, and the explanation does not
> explain the complexity of protecting and unprotecting an object.  I
> would scrap the 2nd paragraph.

if I remember the relevant discussions correctly, this is a case of
correct documentation and incorrect implementation.  I'll look into
fixing the implementation.

> * I understood from Greg's notes, that one of the problems with
> copying GC is how to deal with heap pointers in smobs? But isn't that
> easy?  To deal with this requires a small API change: every object has
> to be marked during GC, so how about defining a new function
> get_new_location (), like this?
> 
>   struct smobstruct
>   {
>     SCM m1;
>     SCM m2;
>   };
> 
>   mark_smob (SCM ptr)
>   {
>     smobstruct *sp = gh_cdr (ptr);
> 
>     sp->m1 = scm_get_new_location (sp->m1);
>     sp->m2 = scm_get_new_location (sp->m2);
>   }
> 
> this breaks compatibility completely. It would be possible to fix this
> up, by defining scm_gc_mark () to be an alias for the conservative
> mark function.

I'm not sure I understand.  what is the relevant place in Greg's
notes?

-- 
:FATAL ERROR -- ILLEGAL ERROR-