D GC theory

[Sativa via Digitalmars-d]

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.