Re: [Chicken-users] question about garbage collector

[John Lenz]

On 12/14/04 03:39:41, felix winkelmann wrote:
> On Tue, 14 Dec 2004 07:34:14 +0000, John Lenz <address@hidden> wrote:
> > 
> > What I am doing here is creating a new symbol table, and then loading into 
> > it the type_pointer.
> > I create a memory region with C_malloc.  That memory is never freed, but 
> > instead it is reused.
> > These two functions are the only ones to access this pointer, so reusing 
> > memory should not be a
> > problem.  I first use space for the pointer, and the way C_intern_in works 
> > it does not allocate
> > data from a when the symbol is already found, so the memory from the 
> > initial call in space will
> > not be touched.
> > I can't use C_alloc since this function returns control back to some other 
> > function.
> > 
> > 1) Does this interact correctly with the garbage collector?  Since the 
> > variables stored in
> > space do not have sub-objects, we don't need to recursivly call mark on 
> > anything.  Second,
> > the memory will not be collected because the pointer will exist thoughout 
> > the life of the program.
> > This is only around 50 bytes or so, and will only be one of these per 
> > module,
> > so it isn't really a problem.
> 
> If you never store anything that must be kept alive in the symbol, then
> this should work. You can build arbitrary structures with proper
> headers that look like normal Scheme data, but exist in non-GC'd heap
> as long as you don't put references to live Scheme data into those
> structures. The collector simply ignores all pointers that point outside
> of the GC'd heap.

Well actually, you could walk from the swig_module_info pointer along the SWIG 
data
structures all the way to a bunch of scheme callback functions.  But those 
callback functions
are stored inside a CHICKEN_gc_root.  :)

> 
> > 
> > 2) Would it be better to use the code commented out there at the end, and 
> > use C_heaptop instead
> > of allocating data with C_malloc?    My concern with using C_heaptop is 
> > actually
> > the code there in C_demand and C_rereclaim.  What happens is that the 
> > swig_init function looks
> > something like this
> > 
> 
> I think you're right not to use C_heaptop, since the amount of data
> needed is bounded and relatively small, doing it the way you do
> will be more efficient and predictable.
> If I understand correctly, the SetModule call with re-use the symbol, 
> but creates a new pointer-object (but with re-used storage for that 
> pointer-object), right?
> 

Yes.  I recreate the pointer object because it might have moved somewhere else
during garbage collection?  Or does the garbage collector see the pointer inside
the symbol table to the C_intern symbol, and never actually look at either the 
C_intern
or the C_mpointer variables?  In that case, I could just do C_set_block_item to 
set the
pointer a second time (although it doesn't really matter).



struct swig_module_info {
  //other stuff
  swig_module_info *next;
};
are stored in a circularly linked list.

So the init function first calls GetModule, and if one is found adds itself to 
the linked
list.  Thus only the first module will call SetModule, I am just trying to
make sure it doesn't fail in wierd ways if for some chance it gets called twice.

John