Bug? GC collects memory that references itself.

[Jeremie Pelletier]

Simen Kjaeraas wrote:
> Jeremie Pelletier <jeremiep at gmail.com> wrote:
> 
>> I need objects that may live without any references in GC memory, this 
>> is for bindings to a C++ library. Using ranges or roots would be very 
>> inneficient so my solution was to have the objects reference 
>> themselves until the C++ side of the object calls a finalizer which 
>> nullify the reference to let the GC collect the memory.
>>
>> The GC doesn't see things this way however, and collects the objects 
>> even when they reference themselves.
>>
>> I've made a simple test program, the objects should never get collected.
>>
>> ---
>>
>> import core.memory;
>> import std.stdio;
>>
>> class Foo {
>>     Foo self;
>>     this() { self = this; }
>>     ~this() { assert(!self); }
>> }
>>
>> void main() {
>>     foreach(i; 0 .. 50) new Foo;
>>     GC.collect();
>>     writeln("No object collected!");
>> }
>>
>> ---
>>
>> If its a feature of the GC to prevent objects from never being 
>> collected, how do I bypass it?
> 
> As Rayner pointed out, that's a cycle, and something the GC should ignore.
> As for how to make it work:
> 
> class Foo {
>     new( uint size ) {
>         return malloc( size ); // Use good old malloc to allocate memory
>     }
> 
>     delete( void* p ) {
>         free( p ); // And free it with good old free.
>     }
> }
> 
> This is described under http://digitalmars.com/d/1.0/class.html#allocators
> You might also need to use gc_addRoot to register the class with the GC,
> and gc_removeRoot to unregister it upon deletion.
> 
> -- 
> Simen

It would be too slow for the GC to manage hundreds or thousands of roots.

I think I'm just going to use an array of pointers and let the objects 
know their index in that array, it seems to be the fastest solution with 
the GC. The D class tree for the C++ interface can be subclassed so they 
will most likely contain references to D memory.

Thanks all for your suggestions and help!

Jeremie