More radical ideas about gc and reference counting

[Kapps via Digitalmars-d]

On Monday, 12 May 2014 at 16:03:28 UTC, Manu via Digitalmars-d
wrote:
> How long is a collect liable to take in the event the GC 
> threads need
> to collect? Am I likely to lose my service threads for 100s of
> milliseconds at a time?
>
> I'll think on it, but I don't think there's anything practically
> applicable here, and it really sounds like it creates a lot more
> trouble and complexity than it addresses.


Your concerns stem not as much from the speed concern of the GC,
but from the freeze-the-world aspect of it. Would a concurrent
collector not solve these issues? As
http://msdn.microsoft.com/en-us/library/ee787088%28v=vs.110%29.aspx#concurrent_garbage_collection
explains a little bit, the actual time your threads spend frozen
should be little (but I admit I don't know exactly how little),
and so long as you don't allocate too much during the collection
itself (which you say you don't), you should be able to keep
running your code during the collection. If it's not possible to
implement concurrent collection in D (and it's already been shown
it is possible), then I'd agree that ARC is very important. But
depending on how little the stop-the-world time from a concurrent
GC can get, perhaps this could work around some issues that
you're desiring ARC for. A generational collector could help in
theory with your high memory usage situations. I doubt you
allocate a gigabyte each frame, so the actual generation 0
content should be fairly low. Much of your memory usage should be
allocations that will not be freed for long periods of time,
while the per-frame and other short allocations should be fast to
collect as there aren't many of them.

Depending on how tunable the GC is, I feel like it should be
possible to get away with a GC even for soft real-time programs
like games. The problem is it's hard to tell until we get a
proper concurrent collector in D2, just like it's hard to tell
how significant the impact of ARC is until we get an optimized
implementation of it in the compiler. Neither of these is simple.
I do quite like the idea of ARC, it's just something that someone
would have to actually implement (well) in order to see how much
of an impact it really has in D. For the truly low frequency
situations, you could get away with a library type for ARC as
well, and as you mentioned, for high frequency you would get
around ARC regardless.