Non-moving generational GC [was: Template Metaprogramming Made Easy (Huh?)]

[Robert Jacques]

On Mon, 14 Sep 2009 09:39:51 -0400, Leandro Lucarella <llucax at gmail.com>  
wrote:
> Jeremie Pelletier, el 13 de septiembre a las 22:58 me escribiste:
[snip]
>> I understand your points for using a separate memory manager, and
>> I agree with you that having less active allocations make for faster
>> sweeps, no matter how little of them are scanned for pointers. However
>> I just had an idea on how to implement generational collection on
>> a non-moving GC which should solve your issues (and well, mines too)
>> with the collector not being fast enough. I need to do some hacking on
>
> I saw a paper about that. The idea was to simply have some list of
> objects/pages in each generation and modify that lists instead of moving
> objects. I can't remember the name of the paper so I can't find it now :S
>
> The problem with generational collectors (in D) is that you need
> read/write barriers to track inter-generational pointers (to be able to
> use pointers to younger generations in the older ones as roots when
> scanning), which can make the whole deal a little unpractical for
> a language that doesn't want to impose performance penalty to thing you
> wont use (I don't see a way to instrument read/writes to pointers to the
> GC only). This is why RC was always rejected as an algorithm for the GC  
> in
> D, I think.
>
>> my custom GC first, but I believe it could give yet another performance
>> boost. I'll add my memory manager to my list of code modules to make
>> public :)
>

As a counter-point, objective-c just introduced a thread-local GC.  
According to a blog post  
(http://www.sealiesoftware.com/blog/archive/2009/08/28/objc_explain_Thread-local_garbage_collection.html)  
apparently this has allowed pause times similar to the pause times of the  
previous generational GC. (Except that the former is doing a full collect,  
and the later still has work to do) On that note, it would probably be a  
good idea if core.gc.BlkAttr supported shared and immutable state flags,  
which could be used to support a thread-local GC.