On Friday 10 September 2010 17:36:06 Andrej Mitrovic wrote: > This is why I'm happy to see some people (Leandro in particular) are > already working on different GC designs for D. :) > > So to evade the GC's pauses as much as possible, one would stick with > using structs or preallocate all needed data before a critical > section? I'll have to get more into that eventually, one of my future > goals (future as in years+ from now) is to make a realtime musical app > (a sequencer).
I think that realistically, most apps can do realtime just fine with full GC use (certainly with a good GC). You lack _guaranteed_ realtime performance, but you're almost certainly going to get it. I'm not really sure how you'd avoid the GC running other than avoid using the GC. So, if you heavily use structs and very few classes or dynamic arrays, then there won't be many opportunities for the GC to run a collection cycle. However, once the GC lives in its own thread (which I think that it's bound to do eventually), it could run at any time. Low use of the GC heap means that it will have less to do, so any pauses that it has will likely be shorter (assuming that it can't do what it does in O(1), but I doubt that GCs usually can, if ever), and depending on how it decides when it should do a collection cycle, it may not run the cycle as often, and so you'd get fewer pauses. But you still may get them. The reality of the matter is that in any program that uses a GC, you're at risk of the GC collection cycle running at some point whether you want it to or not. But with a good GC, odds are that it won't be a problem. Now, with D's current GC, if you never call any function that allocates or frees from the GC heap, then it's not going to run a collection cycle. So, if you have a critical section of code that _must_ be realtime, and you don't do anything that could allocate or free from the GC heap in that section, then no GC collection cycle will run. That doesn't necessarily mean restricting yourself to structs - classes will work just fine - you just can't allocate any in that section. However, once the GC is more advanced and runs in its own thread (as I assume it will eventually), such a guarantee wouldn't hold anymore (since it could run at any time). However, the fact that you don't allocate or free from the GC heap in a critical section should still reduce the odds of a GC collection cycle being done because it won't need to figure out whether it has enough memory and potentially run a cycle to recover memory. Overall, the key to minimizing the impact of the GC (other than having a good GC) is to minimize how much you do with the GC heap. But generally-speaking, you can't guarantee that a GC collection cycle isn't going to run unless you don't have a GC. - Jonathan M Davis
