Re: GC changes

[Tim Josling <tej at melbpc dot org dot au>]

Geoff,

Hopefully you will provide good documentation on the changes. I
had a lot of unnecessary work due to the paucity of documentation
on the GC when I originally implemented it.

By the way, a question on gc...

I see a lot of code like this:

maintree->x=build_x(build_y(build_z("foo")));

Here is a real example in c-decl.c:
  array_domain_type = build_index_type (build_int_2 (200, 0));

Another:
  ptr_ftype_ptr
    = build_function_type (ptr_type_node,
                           tree_cons (NULL_TREE, ptr_type_node,
endlink));

Here we are building a GCable structure. Once it is all linked
into the main trees under the roots and visible to the mark
routines, it will not disappear during GC. But until then, it is
vulnerable to GC, which can be triggered on any memory
allocation. Here there seem to be several memory allocations and
the early ones are unprotected.

Two things:

1. Have I missed something here? If I have and it is OK this
makes life easier but I would like to understand how it works.

2. What is a good way to make things GC proof for a while until
they get into the main tree structure? At the moment I define
various roots to handle the intermediate allocations. 
  
Thanks,
Tim Josling