Componentizing D's garbage collector

Rikki Cattermole alphaglosined at gmail.com
Tue Jan 14 17:55:12 PST 2014


On Tuesday, 14 January 2014 at 23:48:33 UTC, Chris Williams wrote:
> On Friday, 10 January 2014 at 08:03:03 UTC, Andrei Alexandrescu
> wrote:
>> The design at http://goo.gl/ZVCJeB seems to be a win. It works 
>> well, comprehends all major allocation tropes, someone 
>> implemented a subset of it in C++ and measured good results, 
>> and a coworker is considering adopting the design for a C++ 
>> project as well.
>
> An additional feature that I would like to suggest is the 
> concept
> of time-limited collection.
>
> The goal would be to be able to write a main loop in my
> application where I say:
>
> const auto FRAME_DUR_MS = 25;
> while (keepPlaying) {
>    auto start = Clock.currSystemTick()
>    update();
>    render();
>    GC.collectMsecs( FRAME_DUR_MS - (Clock.currSystemTick() -
> start).msecs() );
> }
>
> The idea is that the collector, conceptually, has a routine that
> it runs. I.e.
>
> 1. Point to bottom of stack, scan through.
> 2. Pop registers from each thread, check values.
> 3. Determine unreachable values amongst everything allocated.
> 4. Call destructors on objects.
> 5. Free memory.
>
> Since "unreachability" is a one-way street, I can pause anywhere
> in this process and resume from that location at a later time. I
> don't have to go through all of the steps every time I am 
> called.
> So while there's no guarantee that any one call to 
> collectMsecs()
> actually releases any memory, if the caller continues to call it
> reliably, they should be able to keep on top of their memory
> usage (or know that they need to allocate less frequently if 
> they
> see their memory continue to grow, even under this scheme).

I really love this idea. However I'm not sure how kernels would 
like no sleeping to occur at least by my understanding.
It would definitely be a big plus to anything related to gui's.


More information about the Digitalmars-d mailing list