Garbage collector returning pointers

[Robert M. Münch via Digitalmars-d-learn]

On 2015-03-15 15:57:43 +0000, Marc Schütz said:

>> Ok. I need to dig into how the interpreter handles the returned pointer 
>> and how the stack is handled.
> 
> C usually uses manual memory management, therefore I would expect that 
> the interpreter actually documents whom the pointer belongs to, and who 
> is responsible for cleaning it up.

What I'm trying to understand is how the returned pointer is used and 
when the GC can kick in.

I tracked the return code from the DLL. The returned pointer is 
returned in EAX register (conforming to the C calling convention). Then 
the interpreter uses this pointer for some time (in my case to create a 
copy).

It than continues, and at some point the EAX register gets some other 
value. This is the point, wher no reference to the D GC allocated 
memory can anylonger be found. Hence the GC should be free to free the 
memory.

> If the interpreter takes ownership, you should just allocate the data 
> with malloc(), and the interpreter will then call free() on it when it 
> doesn't need it any longer. Not sure whether .dup is compatible with 
> that, maybe you'd need to write a small helper that copies things to 
> the C heap.

Yes, exactly. And the problem is, that it's not clear to me (yet) when 
the interpreter takes ownership and when not.

Am I right, that I can query() the D GC to check if a pointer is known 
/ can be found or not?

It would be cool if I could query D from the interpreter and ask: "Will 
this pointer be freed in the next collector run?" and get back: Yes, or 
"already has been".

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster