[D-runtime] [GC] Object collection dependencies

[Alex Rønne Petersen]

Right, the GC guarantees nothing about the order of finalization.

The problem here is that I have a class Weak(T) which has a so-called
disappearing link (really just a pointer hidden in a size_t field).
The instance of Weak(T) must always outlive the T value that it hides
inside this field. Currently, I do an extremely dirty and evil hack
involving rt_attachDisposeEvent()/rt_detachDisposeEvent() and
GC.addRange()/GC.removeRange() to maintain this invariant, but this is
obviously less than ideal for something as lightweight as a weak
reference.

As an example, libgc (the Boehm-Demers-Weiser GC) has these functions
to deal with this:

int GC_general_register_disappearing_link(void** link, void* obj);
int GC_unregister_disappearing_link(void** link);

(See the gc.h header file for docs on these.)

In my case, the link parameter would be a pointer to my size_t field
with the hidden pointer, while obj is a pointer to the base of the
Weak(T) instance's memory block.

I need something similar to this in D's GC.

Regards,
Alex

On Sat, May 12, 2012 at 1:05 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> On Saturday, May 12, 2012 12:59:30 Alex Rønne Petersen wrote:
>> Hi,
>>
>> Given two objects A and B, I need a way to make it such that A will
>> always outlive B (i.e. A will never be collected before B is). This
>> needs to hold regardless of whether A and B have any references to
>> each other.
>>
>> I don't think there's any way to do this at present. How hard would it
>> be to implement this with D's current GC?
>>
>> I'm asking since this would facilitate a nice, sort-of hack-free
>> implementation of weak references.
>
> Isn't the language and GC specifically designed so that it's not supposed to
> care about such ordering (e.g. freeing GC memory is illegal in finalizers
> specifically because any objects referred to by that object could already have
> been freed)?
>
> - Jonathan M Davis
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime