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