More radical ideas about gc and reference counting

[Manu via Digitalmars-d]

On 13 May 2014 04:07, Kapps via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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?

I originally thought it would... but the more I think on it, I don't
think it would make an awful lot of difference in practise.
If the stalls were 'short' (like 1-5ms on the background threads,
500µs-1ms on the realtime threads), then maybe it would be workable,
but I don't know that it would be even close to that?

Also, I think it would be very difficult to implement on a machine
without virtual memory, or much of an operating system in general?

The problem remains that with no free memory, frequency of collection
becomes so high, that it's extremely unlikely full collection so often
would be better than ARC.

> 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.

Yeah, it would probably be better, if it's possible.
Implementation needs to be considered from the perspective of embedded
systems with no OS or MMU, and as little as 64mb of ram (the smallest
modern systems).
Mid-range systems are 512mb and no MMU. 'next-gen' systems are
basically like little PC's with crappy OS's, so more likely a decent
GC is possible on a ps4/xbone... but very few have the luxury of
developing for just one system.

It occurred to me earlier that things like strings might enjoy their
own separate heap. And maybe some special logic for strings that
outlived their scope to be actively returned to their heap rather than
waiting for collection.
If the heap were successfully broken down into a suite of sub-heaps, I
have absolutely no idea how to make estimates about the performance of
this system, and if it would approach an acceptable level. I'm
skeptical it would, and it still won't decrease collection frequency.
But I'd be happy to be surprised.

> 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.

I understand the problem. The first hurdle is overcoming the hostility
against it though. There is a severe prejudice.

> 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.

Yup.