D on next-gen consoles and for game development

[H. S. Teoh]

On Fri, May 24, 2013 at 09:34:41AM +1000, Manu wrote:
[...]
> Just to be clear, while I've hard many have, I've NEVER argued for
> removing the GC. I think that's a hallmark of a modern language. I
> want to use the GC in games, but it needs to have performance
> characteristics that are applicable to realtime and embedded use.
> Those are:
> 1. Can't stop the world.
> 2. Needs tight controls, enable/disable, and the allocators interface
> so alternative memory sources can be used in mane places.
> 3. Needs to (somehow) run incrementally. I'm happy to budget a few
> hundred µs per frame, but not a millisecond every 10 frames, or 1
> second every 1000.
>     It can have 1-2% of overall frame time each frame, but it can't
> have 10-100% of random frames here and there. This results in
> framerate spikes.

Makes sense, so basically the GC should not cause jittery framerates,
but should distribute its workload across frames so that the framerate
is more-or-less constant?


> The GC its self can be much less efficient than the existing GC if it
> want's, it's only important that it can be halted at fine grained
> intervals, and that it will eventually complete its collect cycle over
> the long-term.
>
> I know that an incremental GC like this is very complex, but I've
> never heard of any real experiments, so maybe it's not impossible?

Is there a hard upper limit to how much time the GC can take per frame?
Is it acceptable to use, say, a millisecond every frame as long as it's
*every* frame and not every 10 frames (which causes jitter)?

For me, I'm also interested in incremental GCs -- for time-sensitive
applications (even if it's just soft realtime, not hard), long
stop-the-world pauses are really disruptive. I'd rather have the option
of a somewhat larger memory footprint and a less efficient GC (in terms
of rate of memory reclamation) if it can be incremental, rather than a
very efficient GC that introduces big pauses every now and then. I'm
even willing to settle for lower framerates if it means I don't have to
deal with framerate spikes that makes the result jittery and unpleasant.


T

-- 
"I suspect the best way to deal with procrastination is to put off the
procrastination itself until later. I've been meaning to try this, but
haven't gotten around to it yet. " -- swr