On Monday, 23 February 2015 at 22:11:48 UTC, weaselcat wrote:
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.
That isn't the problem. The problem is that when it does collect,
the time it takes is unpredictable. It could take 1us or 10m. If
there is a cap on how long the GC can run at any particular time
interval, then it it's time complexity is simple, predicable, and
can be better used for RT applications.
Effectively I would rather the GC run every second and spend a
maximum of 1ms doing cleaning up(not necessarily finishing)
instead of running when ever and potentially taking seconds to
cleanup.
It's all about how to actually distribute the GC running in time.
As it stands now, it can run anytime and take as long as it
wants. I'd rather have it running "continuously" but not take as
long as it wants. By allowing it to run continuously, in short
bursts, one should get the same long term behavior but not have
the spikes in cpu usage which prevent its usefulness in RT
applications.
