Thread overview
A question about the GC
Dec 24, 2007
Jarrod
Dec 24, 2007
Kirk McDonald
Dec 24, 2007
Jarrod
Dec 24, 2007
0ffh
December 24, 2007
Hey all,

I have a C library that takes the address to a class and stores it, associating the address of the class with a cluster of data. That way, if I try to create a second class tied to the same data, it merely passes back the address of the first class. Also, if the data is destroyed, it explicitly calls the class destructor for me.

This is all well and good, but my concern is that the garbage collector
may reallocate my class if it is a 'copying' gc (I'm not really sure what
it really is, I can't see it mentioned anywhere). If my class is moved,
what happens to the pointers in my C code? Will they be updated too? I
doubt it.
Is this a cause for concern or is D's GC of the non-moving variety? If it
does indeed move I guess I'll have to override new/delete.

Thanks,
December 24, 2007
Jarrod wrote:
> Hey all,
> 
> I have a C library that takes the address to a class and stores it, associating the address of the class with a cluster of data. That way, if I try to create a second class tied to the same data, it merely passes back the address of the first class. Also, if the data is destroyed, it explicitly calls the class destructor for me.
> 
> This is all well and good, but my concern is that the garbage collector may reallocate my class if it is a 'copying' gc (I'm not really sure what it really is, I can't see it mentioned anywhere). If my class is moved, what happens to the pointers in my C code? Will they be updated too? I doubt it.
> Is this a cause for concern or is D's GC of the non-moving variety? If it does indeed move I guess I'll have to override new/delete.
> 
> Thanks,

It is a non-moving GC. Also, the D GC won't see any pointers held by the C library, so be sure that you keep references to your GC-controlled classes in your D code, where the GC can see them.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
December 24, 2007
On Sun, 23 Dec 2007 20:27:59 -0800, Kirk McDonald wrote:

> It is a non-moving GC. Also, the D GC won't see any pointers held by the C library, so be sure that you keep references to your GC-controlled classes in your D code, where the GC can see them.

Yes, I use gc.addRoot with the class address before I pass it on..

Anyway, thanks a lot for your quick answer! I hope the GC remains non- moving, it becomes a lot more confusing otherwise.
December 24, 2007
"Jarrod" <qwerty@ytre.wq> wrote in message news:fkn8sd$sl0$1@digitalmars.com...

> This is all well and good, but my concern is that the garbage collector may reallocate my class if it is a 'copying' gc (I'm not really sure what it really is, I can't see it mentioned anywhere). If my class is moved, what happens to the pointers in my C code? Will they be updated too? I doubt it.

As Kirk pointed out, D's current collector is a non-moving collector, but in the event that a moving collector is implemented, most moving collectors provide a method to "pin" a piece of memory to disallow it from being moved.


December 24, 2007
Jarrod wrote:
> Anyway, thanks a lot for your quick answer! I hope the GC remains non-
> moving, it becomes a lot more confusing otherwise.

IIRMHOC, you have little to fear (at least for D1), because a moving
collector is not possible unless some other features are removed from
the language first (e.g. unions and void* types).

regards, frank