is d-runtime non-gc safe?

[Walter Bright]

On 12/4/2011 5:08 AM, Norbert Nemec wrote:
> Indeed, malloc is not real-time safe. It is common wisdom that real-time audio
> code should not handle any memory allocations.
>
> To this point, D is just as safe as C++: don't do any operations that may
> allocate memory in the audio thread, so the GC will never be invoked in
> real-time critical code.
>
> Where it gets more involved, though, is that D garbage collection is not thread
> safe. When it starts, all registered threads are stopped.
>
> Note: the audio-thread is typically created externally with special settings, so
> D will not know about it and the GC will not stop it. As long as the
> audio-thread never does any pointer assignments that are relevant to the GC,
> everything should be safe.
>
> Just make sure that any garbage collected objects that the audio thread accesses
> have live pointer from areas that the GC knows about. That way it will not
> matter whether the GC scans the audio-data or not or whether this data is
> modified by the audio-thread while the GC is scanning it.

You're right, except for one point. If we ever do a moving GC, then the GC has 
to either know about all the pointers (so it can modify them) or the pointers 
must be 'pinned' (the pointed to object cannot be moved).

The way to 'pin' an object in D is to have a pointer to the object (a root) that 
the GC knows about that is not within a GC allocated object; i.e. that root is 
on the stack, in static data, or is in some other memory like malloc'd data.

Java's JNI interface requires explicit pinning, but this is incompatible with 
D's desire for easy interoperation with C.