[Gc] Re: Patch for native support of long weakrefs

[Zach Saw]

Hi Hans,

-          **The comment for GC_general_register_disappearing_link_ex (or
> preferably a separate replacement function as Ivan suggested) needs to be
> much more careful in describing the functionality.  I’m not sure I
> understand yet.  You want to remove links if objects are no longer
> reachable from anything, including from finalizable objects?  Isn’t that
> easier to determine after all finalizable objects have been traced?
>
> **
>
Not only from the finalizable object. The finalizer callback of an object
could potentially resurrect the object itself by assigning its pointer to a
global variable. In this case, a long weakref won't be cleared.

-          ** The comment describing the _*hb*_finalized array needs to be
> fixed.****
>
> **-          **This patch seems to unconditionally add significant space
> overhead (1/8 or 1/16th of the heap) to support an esoteric feature that
> is unlikely to be used by non-Mono clients, and is probably rarely used by
> Mono.  I think that’s not acceptable.  I share Ivan’s doubts about whether
> it’s actually needed.  If so, we would at least  need a way to allocate
> these bits only conditionally.
>
> I have made a new patch from scratch to avoid this problem completely. It
should no longer have any performance impacts or memory overheads. The
concept is pretty simple actually -- if an object does not have a
finalizer, a long weakref can be cleared immediately since there's no
possibility of it being resurrected. This is the only condition we need to
detect when to clear a long weakref link. With that in mind, all we need to
do then is lookup the fo hash list for a particular object for every
registered long weakref. It is slower when checking whether to clear a long
weakref but it only affects long weakrefs so if you don't use it, you don't
pay any performance penalty at all.

Zach

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20121112/3176bed1/attachment.htm