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

[Ivan Maidanski]

Hi Zach,

It seems we both start working on the same changes - I do it in my way (but haven't yet pushed to github). I'll merge your changes today to push.

Regards,
Ivan

Птн 16 Ноя 2012 21:23:21 от Zach Saw <zach.saw at gmail.com>:
>	
>
>
	
	
>
		
		
			
>
>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
NULL.


> - 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
GC_move_disappearing_link?


> So, after you perform these changes, you'll finish refactoring and be
> ready to commit code actually adding long-ref functionality.
>
>
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/20121116/63a0bb34/attachment.htm