slow runtime

[Jonathan M Davis]

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