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

Ivan Maidanski ivmai at mail.ru
Fri Nov 16 00:57:02 PST 2012


Hi Zach,

I agree with your idea. I had no intention to deal with fo table.

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.

Regards,
Ivan

 16 11 2012 10:30:14 Zach Saw <zach.saw at gmail.com>:
>	
>
>
	
	
>
		
		
			
>Hi Ivan,
>
>
>>As for refactoring GC_finalize, I'll reply you tomorrow.
>> 
>>
>
>
>Here is what I propose:
>
>
>https://github.com/zachsaw/bdwgc/compare/7183c8d...8d13d52
>
>
>
>The fo_hashtbl loops are so different. More importantly, it has nothing to do with add-long-weakref branch. If we are going to refactor that, I would recommend creating a separate branch after finishing add-long-weakref.

>
>Zach
>
>			
		
		
	

	
>

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


More information about the Gc mailing list