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.

Regards,
Alex
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

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@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@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime

On 12 May 2012, at 12:59, Alex Rønne Petersen wrote:
> I'm asking since this would facilitate a nice, sort-of hack-free
> implementation of weak references.

I never looked at its implementation and thus have no idea how »clean« it is, but Tango/D1 had weak references – maybe a similar solution could also be used in this case?

David
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime