D GC theory
weaselcat via Digitalmars-d
digitalmars-d at puremagic.com
Mon Feb 23 14:11:47 PST 2015
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.
More information about the Digitalmars-d
mailing list