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

On Saturday, 1 June 2013 at 13:25:20 UTC, Joseph Rushton Wakeling wrote:
> Someone on a Reddit thread pointed to the Nimrod GC design -- looks potentially
> interesting from your perspective: http://nimrod-code.org/gc.html

From the page:

> but it may scan the delta-subgraph of the heap that changed since its last run

Hmm, so I guess it needs write barriers?