[Gc] Patch for native support of long weakrefs

Rodrigo Kumpera kumpera at gmail.com
Fri Nov 9 08:07:28 PST 2012


The code in mono is pretty convoluted, but it never shown up in our GC
benchmark.

The common usage for weak refs that track resurrection is to implement
proper finalization when you need to free binary code.
But it's the wrong abstraction and the resulting performance is horrible. A
better abstraction are finalization queues.


On Fri, Nov 9, 2012 at 12:18 AM, Zach Saw <zach.saw at gmail.com> wrote:

> Hi guys,
>
> After looking into Mono's source code for implementing long weak refs, it
> must be said that this is one feature BoehmGC needs to support natively.
> The 'hacks' that Mono had to go through to implement this feature is both
> convoluted, bloated as well as inefficient.
>
> It is actually really simple to extend BoehmGC to add this feature. I have
> created a patch (attachment) which implements the following function:
>
> GC_API int GC_CALL GC_general_register_disappearing_link_ex(void * * link,
> const void * obj, int track_long)
>
>         /* Same as the above except allows for tracking past    */
>         /* finalization. When track_long is non-zero, link will */
>         /* only get cleared when obj is truly no longer         */
>         /* accessible.                                          */
>
> This function is similar to GC_general_register_disappearing_link except
> it allows caller to specify if we are tracking the pointer long or short. A
> short pointer is similar to the original tracking method. A long pointer
> tracks a pointer past finalization / resurrection. It only clears the link
> when the object is truly no longer accessible.
>
> If you guys are satisfied with the changes, I'd appreciate it if it were
> included into the official distribution.
>
> Thanks.
>
> Zach
>
> _______________________________________________
> Gc mailing list
> Gc at linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/gc/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20121109/8965d769/attachment-0001.htm


More information about the Gc mailing list