On 12/29/2013 11:15 AM, "Ola Fosheim Grøstad"
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
It is probably feasible to create a real-time friendly garbage collector that
can cooperate with realtime threads, but it isn't trivial. To get good cache
coherency all cores have to "cooperate" on what memory areas they write/read to
when you enter timing critical code sections. GC jumps all over memory real fast
touching cacheline after cacheline basically invalidating the cache (the effect
depends on the GC/application/cpu/memorybus).
I'll reiterate that the GC will NEVER EVER pause your program unless you are
actually calling the GC to allocate memory. A loop that does not GC allocate
WILL NEVER PAUSE.
Secondly, you can write C code in D. You can only make calls to C's standard
library. It WILL NEVER PAUSE. You can do everything you can do in C. You can
malloc/free. You don't have to throw exceptions. You don't have to use closures.
This fear and loathing of the GC is, in my opinion, wildly overblown.
Granted, you have to know what you're doing to write performant D code. You have
to know the patterns of memory allocation happening in the code. Organizing your
data structures for best caching is required. But you need to have that
expertise to write fast C code, too.
