Smart pointers instead of GC?

[Adam Wilson]

On Sat, 01 Feb 2014 04:04:54 -0800, JR <zorael at gmail.com> wrote:

> On Saturday, 1 February 2014 at 05:36:44 UTC, Manu wrote:
>> I write realtime and memory-constrained software (console games), and  
>> for
>> me, I think the biggest issue that can never be solved is the
>> non-deterministic nature of the collect cycles, and the unknowable  
>> memory
>> footprint of the application. You can't make any guarantees or  
>> predictions
>> about the GC, which is fundamentally incompatible with realtime  
>> software.
> (tried to manually fix ugly linebreaks here, so apologies if it turns  
> out even worse.)
>
> (Maybe this would be better posted in D.learn; if so I'll crosspost.)
>
> In your opinion, of how much value would deadlining be? As in, "okay  
> handyman, you may sweep the floor now BUT ONLY FOR 6 MILLISECONDS;  
> whatever's left after that you'll have to take care of next time, your  
> pride as a professional Sweeper be damned"?
>
> It obviously doesn't address memory footprint, but you would get the  
> illusion of determinism in cases similar to where race-to-idle  
> approaches work. Inarguably, this wouldn't apply if the goal is to  
> render as many frames per second as possible, such as for non-console  
> shooters where tearing is not a concern but latency is very much so.
>
> I'm very much a layman in this field, but I'm trying to soak up as much  
> knowledge as possible, and most of it from threads like these. To my  
> uneducated eyes, an ARC collector does seem like the near-ideal solution  
> -- assuming, as always, the code is written with the GC in mind. But am  
> I right in gathering that it solves two-thirds of the problem? You don't  
> need to scan the managed heap, but when memory is actually freed is  
> still non-deterministic and may incur pauses, though not necessarily a  
> program-wide stop. Aye?
>

It would only not be a program wide stop if you had multiple threads  
running, otherwise yes, ARC can still Stop-The-World for a  
non-deterministic period of time, because you the programmer have no idea  
how long that collection cycle will last. Also note that this is just a  
shuffling of where the collection happens. In D's GC a collection can  
happen any time you attempt to allocate, whereas in ARC you eagerly  
collect when you delete, because if you don't eagerly collect you'll have  
a memory leak. Also you can't make ARC concurrent.

> At the same time, Lucarella's dconf slides were very, very attractive. I  
> gather that allocations themselves may become slower with a concurrent  
> collector, but collection times in essence become non-issues.  
> Technically parallelism doesn't equate to free CPU time; but that it  
> more or less *is* assuming there is a cores/thread to spare. Wrong?
>

Essentially yes, concurrency does get rid of MOST of the STW aspects of  
GC's. However, most modern GC's are generational and typically their are  
one or two generations that are not collected concurrently. In .NET both  
Generations 0 and 1 are not collected concurrently because they can be  
collected very quickly, more quickly than cost of enabling concurrent  
collection support on allocation.

For example, I use WPF for almost every project I do at work. WPF is a  
retained-mode GUI API based on DirectX 9, and it has a 60FPS render speed  
requirement. The only time I have seen the rendering bog down due to the  
GC is when there are a LOT of animations starting and stopping. Otherwise  
it's almost always because of WPF's horrifically naive rendering code.

> Lastly, am I right in understanding precise collectors as identical to  
> the stop-the-world collector we currently have, but with a smarter  
> allocation scheme resulting in a smaller managed heap to scan? With the  
> additional bonus of less false pointers. If so, this would seem like a  
> good improvement to the current implementation, with the next increment  
> in the same direction being a generational gc.
>

Correct, precision won't change the STW nature of the GC, just make it so  
there is much less to scan/collect in the first place, and believe it or  
not, the difference can be huge. See Rainer Schutze's for more information  
on a precise collector in D: http://dconf.org/2013/talks/schuetze.html

> I would *dearly* love to have concurrency in whatever we end up with,  
> though. For a multi-core personal computer threads are free lunches, or  
> close enough so. Concurrentgate and all that jazz.

You and me both, this is the way all GC's are headed, I can't think of a  
major GC-language that doesn't have a Concurrent-Generational-Incremental  
GC. :-)

-- 
Adam Wilson
GitHub/IRC: LightBender
Aurora Project Coordinator