[Gc] Re: Patch for native support of long weakrefs
zach.saw at gmail.com
Sun Nov 11 17:41:11 PST 2012
- **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
> **- **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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gc