More radical ideas about gc and reference counting

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Mon May 12 01:45:58 PDT 2014


On 5/12/2014 12:12 AM, Manu via Digitalmars-d wrote:
> What? You've never offered me a practical solution.

I have, you've just rejected them.


> What do I do?

1. you can simply do C++ style memory management. shared_ptr<>, etc.

2. you can have the non-pausible code running in a thread that is not registered 
with the gc, so the gc won't pause it. This requires that this thread not 
allocate gc memory, but it can use gc memory allocated by other threads, as long 
as those other threads retain a root to it.

3. D allows you to create and use any memory management scheme you want. You are 
simply not locked into GC. For example, I rewrote my Empire game into D and it 
did not do any allocation at all - no GC, not even malloc. I know that you'll 
need to do allocation, I'm just pointing out that GC allocations and pauses are 
hardly inevitable.

4. for my part, I have implemented @nogc so you can track down gc usage in code. 
I have also been working towards refactoring Phobos to eliminate unnecessary GC 
allocations and provide alternatives that do not allocate GC memory. 
Unfortunately, these PR's just sit there.

5. you can divide your app into multiple processes that communicate via 
interprocess communication. One of them pausing will not pause the others. You 
can even do things like turn off the GC collections in those processes, and when 
they run out of memory just kill them and restart them. (This is not an absurd 
idea, I've heard of people doing that effectively.)

6. If you call C++ libs, they won't be allocating memory with the D GC. D code 
can call C++ code. If you run those C++ libs in separate threads, they won't get 
paused, either (see (2)).

7. The Warp program I wrote avoids GC pauses by allocating ephemeral memory with 
malloc/free, and (ironically) only using GC for persistent data structures that 
should never be free'd. Then, I just turned off GC collections, because they'd 
never free anything anyway.

8. you can disable and enable collections, and you can cause collections to be 
run at times when nothing is happening (like when the user has not input 
anything for a while).


The point is, the fact that D has 'new' that allocates GC memory simply does not 
mean you are obliged to use it. The GC is not going to pause your program if you 
don't allocate with it. Nor will it ever run a collection at uncontrollable, 
random, asynchronous times.


More information about the Digitalmars-d mailing list