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.
