On Monday, 23 February 2015 at 21:11:23 UTC, Sativa wrote:
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.
Hi,
D's GC actually is predictable. It will not collect unless you
allocate. You can also disable it and manually collect. I use it
this way and essentially use it as a smart freelist.
