Smart pointers instead of GC?

[JR]

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?

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?

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.

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.