chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re[2]: [Chicken-users] Questions on changing Chicken runtime and som


From: felix winkelmann
Subject: Re: Re[2]: [Chicken-users] Questions on changing Chicken runtime and some other stuff
Date: Tue, 20 Dec 2005 10:34:12 +0100

On 12/20/05, Sergey Khorev <address@hidden> wrote:
> fw> > One has to distinguish between the initial garbage collector, which 
> moves
> fw> > nongarbage from the (garbage) stack to the heap, and garbage collections
> fw> > within the heap.  The first is part of the Chicken way of doing 
> business;
> fw> > the second could probably be replaced by a different GCed heap, or even
> fw> > a conservative GC such as Boehm-Demers-Weiser.
> fw> >
> fw> Yes, that would be exactly the way. All the stack-managing machinery
> fw> makes still sense in such an environment. What would have to be modified
> fw> is the write-barrier (C_mutate) and copying live stack data into the
> fw> secondary heap (which in this case would be managed differently).
> fw> Where I see problems, though are data-representation issues...
>
> Could you please elaborate more on these issues? BTW what secondary GC 
> strategy does Chicken use?
>

Chicken allocates data on the stack (the C stack, the first heap generation),
until it is full (some predetermined limit is reached). When the stack is
exhausted, all live data is copied into the secondary heap. The secondary
heap follows a normal stop-and-copy GC strategy. That's really all
there is to it.
To track stores of stack-allocated data in heap-allocated data structures,
we need a write-barrier (C_mutate), which tracks the assigned locations
for later GC.


cheers,
felix




reply via email to

[Prev in Thread] Current Thread [Next in Thread]