[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