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

[Leandro Lucarella]

Jeremie Pelletier, el 13 de septiembre a las 22:58 me escribiste:
> Tom S Wrote:
> 
> > Jeremie Pelletier wrote:
> > > Tom S Wrote:
> > > 
> > >> Jeremie Pelletier wrote:
> > >>> I myself allocate all my meshes and textures directly on the GC and I'm pretty sure its faster than C's malloc and much safer.
> > >> Hm, why would it be faster with the GC than malloc? I'm pretty sure it's 
> > >> the opposite :P Plus, I could use a specialized malloc implementation, 
> > >> like TLSF.
> > > 
> > > The D GC is already specialized, and given its being used quite a lot in D, there are good chances its already sitting in the CPU cache, its heap already having the available memory block waiting on a freelist, or if the alloc is more than 0x1000 bytes, the pages available in a pool. You'd need to use malloc quite a lot to get the same optimal performance, and mixing the two would affect the performance of both.
> > 
> > It might be specialized for _something_, but it definitely isn't 
> > real-time systems. I'd say with my use cases there's a very poor chance 
> > the GC is sitting in the CPU cache since most of the time my memory is 
> > preallocated and managed by specialized structures and/or malloc. I've 
> > found that using the GC only for the hard-to-manually-manage objects 
> > works best. The rest is handled by malloc and the GC has a very shallow 
> > vision of the world thus its collection runs are very fast. Of course 
> > there's a drawback that both the GC and malloc will have some pages 
> > cached, wasting memory, but I don't let the GC touch too much so it 
> > should be minimal. YMMV of course - all depends on the memory allocation 
> > patterns of the application.
> 
> 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 :)

-- 
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
----------------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------------
Pack and get dressed
before your father hears us,
before all hell breaks loose.