Re: [Chicken-users] Posix threading

[Peter Busser]

On Friday 11 March 2005 11:30, Julian Morrison wrote:
> felix winkelmann wrote:
> >Locking/making immobile is (AFAICT) not possible - GC is just too
> >frequent, and too much interleaved with execution.
>
> What I was thinking is basically a "move/don't move" bit on data, which
> is normally unset but gets set by a special sort of "locking" major GC.
> Locked items are treated as axiomatic reachable and are not moved in
> copying GC. This would then generate a list of locked items to be
> consumed by a corresponding unlock operation.

You don't have a choice but to move data, because the data resides on the 
stack and the stack must be cleaned when it is full. This way you have two 
generations of data. A young generation, which lives on the stack and which 
costs practially next to nothing to allocate and deallocate. And an old 
generation, which lives on the heap and which costs more to allocate and 
deallocate.

A program usually has a lot of short-lived young data and much less long-lived 
old data. The net result is that the system as a whole has much less overhead 
than when you allocate everything on the heap.

Marking data with a move/don't move bit will effectively turn the stack into a 
heap. Thereby introducing the extra cost of heap management and removing all 
the benefits of having a stack in the first place (and the stack itself too 
obviously).

> I'm curious, why in particular did you chose a copying GC?

See above. Other implemenations and languages (like e.g. Haskel) use a 
generational GC too. The PDF document at the end of my previous e-mail does a 
great job at listing all kinds of GC strategies and their strengths and 
weaknesses.

Groetjes,
Peter.