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.
