This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Outline for Guile Generational GC


Dale Jordan <dalej@alum.mit.edu> writes:

> The documentation on smobs indicates that a new instance is allocated
> by scm_must_malloc, after which the C program must build a cell with
> the correct type tag and a pointer to the malloc-ed memory.  There is
> no mention whether an alternate means is allowed.  Unfortunately,
> scm_must_malloc is used all over Guile itself, so we couldn't use it
> directly to find smobs.  There wouldn't seem to be any restriction on
> using it for other purposes, either.

I was thinking more along the lines of having a general allocation
like scm_must_malloc that would be used by smob programmers as
necessary (scm_must_malloc just counts bytes to figure out how much
memory has been malloc'd for triggering gc's).
 
> We could try the value-added approach and provide a function defined as
> 
>    SCM *scm_make_instance(long smob_tag, scm_sizet smob_size)
> 
> that did the allocations and returned the cell pointer already set
> up.  This would let us control where the memory was allocated from.
> It would have to become the only supported way to allocate a smob
> instance.

This isn't really flexible enough for smobs... I would expect that
most won't consist of all scheme values (or areas of memory that can
contain scheme values) so it would be a waste on traps to those
regions of memory. I think it's better to put that into the hands of
the programmers. This still begs the question of what to do if someone
mallocs a chunk of memory, then memcopy's an smob over, but the most
sensible answer is "don't do that" ;)

Another thing that will be needed is a smob relocation function
(basically, just something where we can do 

smob_relocate(SCM old_cell, SCM new_cell)

for smobs that can contain pointers to themselves that aren't in the
heap).

> I haven't looked at many smobs, but the few I've defined have not kept
> pointers to scheme objects.  It might be helpful if the smob
> description provided that information.  If they don't hold pointers
> they don't have to be traced except when their header cell is collected.
> 

In this case, they can just use the current functions. What is needed
is something like scm_alloc_protected(scm_sizet foo). Even better
would be to allow the smobs to tell us where the scheme pointers can
be, to save on scanning, but it shouldn't be absolutely necessary.


-- 
Greg