Garbage collection, and practical strategies to avoid allocation

Joseph Rushton Wakeling joseph.wakeling at webdrake.net
Sat Jun 1 04:45:53 PDT 2013


On 06/01/2013 04:02 AM, Manu wrote:
> While I do think a sufficiently advanced GC might satisfy the realtime
> environment, the more I think about it, the more I am thinking a GC is not
> applicable to the embedded (or memory limited) environment.
> 
> So what options exist?
> 
> I'm thinking more and more that I like the idea of a ref-counting GC.
> People argue that managing ref-counts may be slower, perhaps true, it requires a
> small amount of localised overhead, but if allocation frequency is low, it
> shouldn't be much.
> I think the key advantages though are:
>  - determinism, memory will be immediately freed (or perhaps deferred by a small
> but predictable amount of time, let's say, 1 frame)
>  - elimination of full-heap scans which takes the most time
>  - the refcount table is self-contained, won't destroy the dcache like a heap scan
>  - less tendency to fragment, since transient allocations can come into and
> leave existence before something else allocates beside it

Someone on a Reddit thread pointed to the Nimrod GC design -- looks potentially
interesting from your perspective: http://nimrod-code.org/gc.html



More information about the Digitalmars-d mailing list