On Tue, Aug 27, 2013 at 1:40 PM, Jan Hubicka <hubi...@ucw.cz> wrote:
>> > + while (x != xlimit)
>> > + {
>> > + /* Code common to all symtab nodes. */
>> > + gt_ggc_m_9tree_node (x->decl);
>> > + gt_ggc_mx_symtab_node_base (x->next);
>> > + gt_ggc_mx_symtab_node_base (x->previous);
>> > + gt_ggc_mx_symtab_node_base (x->next_sharing_asm_name);
>> > + gt_ggc_mx_symtab_node_base (x->previous_sharing_asm_name);
>> > + gt_ggc_mx_symtab_node_base (x->same_comdat_group);
>> > + gt_ggc_m_20vec_ipa_ref_t_va_gc_ (x->ref_list.references);
>> > + gt_ggc_m_9tree_node (x->alias_target);
>> > + gt_ggc_m_18lto_file_decl_data (x->lto_file_data);
>>
>> Don't we have template specializations so we just can do
>>
>> gt_ggc_mark (x->decl);
>> gt_ggc_mark (x->next);
> Yep, that is what I hope for.
>> ...
>> etc?
>>
>> Also all of the symbol table is reachable from the global symbol_table
>> dynamic array which is a GC root. So instead of walking ->next/previous
>> and edges you should have a custom marker for the symbol_table global
>> which does more efficient marking with loops.
>
> Indeed, good point!
> All of the pointers linking symbol table together (i.e. pointer to other
> symbol
> table entries) can be ignored for PCH mark (since we are explicitely
> allocated,
> and all we need is to mark the trees/lto data and other stuff we point to.
>
> These are annotated primarily to get PCH working, where we obviously need
> to keep them.
>
> It would be nice to progress on this patch soon :)
Oh, and with a custom marker for the symbol_table GC root the actual
symbol / edge objects need not be GC allocated at all! Just make sure
to properly mark the GC objects they refer to.
Richard.
> Honza
>>
>> Richard.
