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

Zach Saw zach.saw at gmail.com
Fri Nov 16 02:23:21 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 "}")

I don't understand what you mean by that, could you expand on it pls?

> - replace 0 with NULL where appropriate

Seems strange most part of the code uses 0 while we're converting some to

> - remove redundant parenthesis in "(dl_hashtbl -> log_size == -1 ) ? 0 :
> (1 << dl_hashtbl -> log_size)" (the order of operations is quite evident)

Evident to you or to the various different compilers? What are the
sequencing points for the above statement? Would removing parenthesis cause
some compilers to mis-evaluate? Also, I didn't introduce these parenthesis
but personally, I would not remove parenthesis without knowing 100% all
compilers supported by BoehmGC out there would evaluate it correctly.

> 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)

I split this out in preparation for long-weakref. Without that, there would
be code duplication later.

> 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)
I can change that to nolock, but what do you propose we do with code
duplication when I add long-weakref if we move code back from _inner to

> So, after you perform these changes, you'll finish refactoring and be
> ready to commit code actually adding long-ref functionality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20121116/7fb98b35/attachment.htm

More information about the Gc mailing list