|[2 earlier articles]|
|Re: Garbage collection for system programming Martin.Ward@durham.ac.uk (Martin Ward) (2005-02-28)|
|Re: Garbage collection for system programming email@example.com (Richard Xian) (2005-03-01)|
|Re: Garbage collection for system programming firstname.lastname@example.org (2005-03-01)|
|Re: Garbage collection for system programming email@example.com (Simon) (2005-03-01)|
|Re: Garbage collection for system programming firstname.lastname@example.org (2005-03-04)|
|Re: Garbage collection for system programming email@example.com (Paul Topping) (2005-03-04)|
|Re: Garbage collection for system programming firstname.lastname@example.org (2005-03-04)|
|From:||email@example.com (Nick Maclaren)|
|Date:||4 Mar 2005 19:17:01 -0500|
|Organization:||University of Cambridge, England|
|Posted-Date:||04 Mar 2005 19:17:01 EST|
Paul Topping <firstname.lastname@example.org> wrote:
>Some of the replies to the original post seem to be assuming that GC
>would have to be used for ALL memory allocation in, say, an operating
>system and then proceed to explain why this might be a bad idea. My
>guess is that the original poster was thinking along the lines of
>using GC to manage the many lists of things (eg, running processes,
>events, critical sections, etc.) that make up a typical OS or system
>programming task. IMHO, GC might be very good for this sort of
>thing. It might not be good to, say, reserve memory space for an
>executable to be loaded into. Such large allocations may be made by
>the lower-level memory allocator on which the GC is built.
That is PRECISELY what doesn't work. I have recently spent a LOT of
time investigating problems caused by very much this sort of thing.
The eventual symptom is a stuck component or system, or dire
performance. This turns out to be due to an underlying action timing
out, failing EAGAIN, or whatever. And, further down, that turns out
to be due to the normal behaviour of some resource manager being
slightly unsuitable for what it is used for.
Return to the
Search the comp.compilers archives again.