D on next-gen consoles and for game development

[Joseph Rushton Wakeling]

On 05/24/2013 01:34 AM, 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.
> 
> 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?

Maybe someone else can point to an example, but I can't think of any language
prior to D that has both the precision and speed to be useful for games and
embedded programming, and that also has GC built in.

So it seems to me that this might well be an entirely new problem, as no other
GC language or library has had the motivation to create something that satisfies
these use parameters.

This also seems to suggest that an ideal solution might be to have several
different GC strategies, the choice of which could be made at compile time
depending on what's most suitable for the application in question.