D GC theory

[Sativa via Digitalmars-d]

How hard would it be to modify D's GC to do the following two 
things:

1. Scan the heap in the BG on another thread/cpu for 
compactification.

2. Move blocks of memory in predictable(timewise) chunks that 
prevents locking the main thread for any period of time.

e.g., in the first step the GC finds some blocks of memory that 
need to be freed/compacted. In the 2nd step it starts 
freeing/compacting it in predictable pieces by limiting the time 
it takes while working.

The point is, that maybe the GC is ran more often but in smaller 
and predictable steps.

That is, the GC should be able to calculate how long it will take 
to free/compact a block. If it takes too long then it simply does 
it in stages.

This way, there is essentially a very predictable and consistent 
cpu usage with the GC running but never any major lag spikes that 
are going to throw real time behavior out the window.

It would seem that such a "Feature" would be easy to implement by 
modifying the existing GC code to be "incremental".

I'd prefer a constant 1-5% cpu usage given to the GC if it didn't 
blow up for no reason. This way, it being very predictable, just 
mean one has to get a slightly faster cpu to compensate or 
optimize the code slightly.

It would be analogous to game programming.

1. We can have the GC steal, say, 1 fps to do it's work...

2. Or we can keep the GC asleep doing nothing until it gets so 
much work it has pause the entire engine for a 1/2 second 
dropping the fps down by half momentarily. This might happen 
every 1 minute or so.... but still unacceptable for most gamers. 
(assuming 30-60 fps)


I'd prefer the first case.