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

Ivan Maidanski ivmai at mail.ru
Mon Nov 19 06:21:54 PST 2012


Hi Zach,

Some changes required:
1. we promised to allow to exclude this functionality if desired by GC_LONG_REFS_NOT_NEEDED (or similiar)
(for this, you could put GC_ASSERT(GC_ll_hashtbl...) and GC_push_all(GC_ll_hashtbl...) close to minimize number of ifndef GC_LONG_REFS_NOT_NEEDED, same for GC_register_long_link and GC_unregister_long_link)

2. GC_dump_finalization_links: should be STATIC instead of inline (we don't care about speed optimization of debugging code) and the argument should be pointer to const.
3. GC_register_disappearing_link_inner and GC_move_disappearing_link_inner should be STATIC (contrary to what I've said earlier, they are rather big for inlining - this is waste of memory)
4. In gc.h comments: according to the style, we use 2 spaces as a sentence delimiter:
     /* inaccessible.  An object becomes truly inaccessible  */

The rest seems to be ok.

Regards,
Ivan

19 11 2012 12:49:23 Zach Saw <zach.saw at gmail.com>:
>	
>
>
	
	
>
		
		
			
>Hi Ivan,
>
>
>>Please merge https://github.com/ivmai/bdwgc/tree/add-long-weakref to your add-long-weakref branch and go on.
>>

>>About naming: I think GC_[un]register/move_disappearing_link_long name is long (and major part of it is common with GC_X_disappearing_link). I suggest GC_..._long_link instead. Any objections or other candidates?

>
>I've added long link support.
>
>
>https://github.com/zachsaw/bdwgc/compare/df392f3...4b32351 

>
>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/20121119/5fe767db/attachment.htm


More information about the Gc mailing list