GC vs. Manual Memory Management Real World Comparison

[Jakob Ovrum]

On Thursday, 25 October 2012 at 17:17:01 UTC, Rob T wrote:
> Yes I can build my own D shared libs, both as static PIC (.a) 
> and dynamically loadable (.so). however I cannot statically 
> link my shared libs to druntime + phobos as-is. The only way I 
> can do that, is to also compile druntime + phobos into PIC, 
> which can be done as a static PIC lib.

Sorry, I keep forgetting that this is needed on non-Windows 
systems.

> So what you are saying is that I can statically link PIC 
> compiled druntime to my own shared lib, but I cannot build 
> druntime as a dynamically loadable shared lib? I can see why 
> thatmay work, if each shared lib has it's own private compy of 
> the GC. Correct?

Yes, this is possible.

Sending references to GC memory between the D modules then has 
the same rules as when sending it to non-D code, unless the host 
(the loader module) uses druntime to load the other modules, in 
which case it can in principle share the same GC with them.

> I recall that druntime may have some ASM code that will not 
> work when compiled to PIC. I think gdc removed the offending 
> ASM code, but it may still be present in the dmd version, but I 
> don't know for sure.

I think it was relatively recently that DMD could also compile 
the runtime as PIC, but I might be remembering wrong.

> Another question is if I can link a dynamic loadable D lib to 
> C/C++ code or not? Yes I can do it, and it seems to work, but I 
> was told that the GC will not necessarily work. Am I 
> misunderstanding this part?

The GC will work the same as usual inside the D code, but you 
have to manually keep track of references you send outside the 
scope of the GC, such as references to GC memory put on the C 
heap.

This can be done with the GC.addRoot/removeRoot and 
GC.addRange/removeRange functions found in core.memory, or by 
retaining the references in global, TLS or GC memory.

It's good practice to do this for all GC references sent to 
external code, as you don't know where the reference may end up.

Of course, you have other options. You don't have to send 
references to GC memory to external code, you can always copy the 
data over to a different buffer, such as one on the C heap (i.e. 
malloc()).

If the caller (in the case of a return value) or the callee (in 
the case of a function argument) expects to be able to call 
free() on the memory referenced, then you must do it this way 
regardless.