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

Zach Saw zach.saw at gmail.com
Fri Nov 16 02:50:00 PST 2012


Hi Ivan,

Some minor decoration changes to be done:
> - ITERATE_DL_HASHTBL_BEGIN should start with "{" (so
> ITERATE_DL_HASHTBL_END needs one more "}")
> - replace 0 with NULL where appropriate
> - remove redundant parenthesis in "(dl_hashtbl -> log_size == -1 ) ? 0 :
> (1 << dl_hashtbl -> log_size)" (the order of operations is quite evident)
> - remove GC_make_disappearing_links_disappear and
> GC_remove_dangling_disappearing_links
> - remove _inner suffix of GC_make_disappearing_links_disappear_inner and
> GC_remove_dangling_disappearing_links_inner
>
> Regarding this joint commit -
> https://github.com/zachsaw/bdwgc/compare/d8e15a91c2...7183c8d
> 1. "DCL_LOCK_STATE;" should immediately follow last local variable
> declaration (without a space line) - this is because of it is itself a
> declaration
> 2. Remove GC_move_disappearing_link_inner (move its code back to
> GC_move_disappearing_link)
> 3. GC_move_disappearing_link_locked: rename back to
> GC_move_disappearing_link_inner (we use _inner suffix for routines that
> expect allocation lock to be acquired outside, see gc.h; probably it is not
> a bad idea to have some special self-descriptive suffix but "locked" seems
> to be misleading, "nolock" should be better in my opinion)
>
> So, after you perform these changes, you'll finish refactoring and be
> ready to commit code actually adding long-ref functionality.
>
>
This is my interpretation of what you said above.

https://github.com/zachsaw/bdwgc/compare/8d13d52...7730d81

If you are happy with that, I will start adding long weakref.

Zach
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20121116/b51bc4dd/attachment-0001.htm


More information about the Gc mailing list