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

Ivan Maidanski ivmai at mail.ru
Fri Nov 9 03:16:00 PST 2012


Hi Zach,

What do you mean by "truly inaccessible"? If an object is accessible via hidden pointer, is it truly inaccessible?

This functionality could be emulated via finalizers but it is not performance efficient. As I understand, it worth adding to GC but Hans might have a different opinion.

Comments on patch:
1. I think it's better to propose a separate function instead of a parameter because:
2. it's better to use a separate table for storing "long-term" refs (otherwise GC will scan the joint table twice, or even, 3 times)
3. Is GC_clear_finalized_bit (and friends) actually needed?
4. No need to define GC_general_register_disappearing_link redirected to GC_general_register_disappearing_link_inner
5. There is some code duplication in the patch (Make disappearing links disappear), is there a way to eliminate it?
6. Please clean up your patch removing such non-functional changes from:
-                                /* Field to be cleared.         */
+                                /* Field to be cleared.                */
-        (*(curr_fo -> fo_fn))((ptr_t)(curr_fo -> fo_hidden_base),
+        real_ptr = (ptr_t)(curr_fo -> fo_hidden_base);
+        (*(curr_fo -> fo_fn))(real_ptr,

Regards,
Ivan

Fri, 9 Nov 2012 18:40:16 +1100 от Zach Saw <zach.saw at gmail.com>:
>	
>
>
	
	
>
		
		
			
>Updated patch attached. Original patch did not take into account of the case where a long weakref could be registered with an object without finalizer.
>
>Zach
>
>
>
>On Fri, Nov 9, 2012 at 4:18 PM, 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/03882969/attachment.htm


More information about the Gc mailing list