Indeterminate lifetime objects:
These are objects that may be modified and become free at any point during compilation. In our case, that is mainly trees and RTL (and also additional data structures, e.g. shared by several passes).
This class does *not* include objects that live only for a single pass, that have some determinate but long lifetime, or go through accessors in order to be freed (IE every single call that can cause one to go free goes through a single function.
These objects are garbage collected. The garbage collector (internal to GCC) is a precise GC, mark & sweep (but Boehm's GC has been experimented as GCC internal GC.). It handles only global roots (static or extern C variables), ignoring any local (to a function) pointers. It is explicitly triggered by a call to ggc_collect and not by allocations. It is implemented in files gcc/ggc.h and gcc/ggc-*.c. Pointers (variables, fields, ...) are explicited (thru the GTY(()) marker), and marking and scanning routines are generated. This also enables persistency for compiler headers file.
typed garbage collector internal to GCC
These objects should be GC alloced. See the documentation on type information (on the GTY(()) magic) and be aware that some additional C files (eg gt-tree-FOO.h or gtype-desc.c) are generated in the object (build) tree (but not in the GCC source tree).
For new middle-end header files on trees which contains GTY(()) stuff (like tree-chrec.h), add their name into the ifiles variable of gcc/gengtype.c as documented here (or if they are shared, maybe include them in tree-flow.h). This is the case when you add a new tree-FOO.h file which you #include in your new files tree-FOO1.c tree-FOO2.c implementing a new pass.
For a single middle-end new pass tree-FOO.c which contains GTY(()) (without having its specific tree-FOO.h like above) add a #include "gt-tree-FOO.h" at the end of file tree-FOO.c and edit gcc/Makefile.in to add your tree-FOO.c to GTFILES and to OBJS-common, and add a dependency for tree-FOO.o which contains gt-tree-FOO.h, etc...
Avoid removing manually the generated (gt-*.h or gtype-desc.c) files. If you happen to do that, you probably will have to remove s-* in the build directory so that gengtype is rerun.
You don't need to regenerate (thru autoconf...) any configure file when adding passes using GTY().
The magic stuff parsing GTY(()) macros (gengtype.c) does not get the source files to parse for GTY(()) thru program arguments or its stdin. Some files list are wired inside, perhaps thru the gtyp-gen.h file (also generated in the object directory).
I (Basile) suggested adding some destroyable objects here e.g. providing a limited form of finalization.
Fixed lifetime objects:
These are all other objects. They come in several categories.
Fixed size, fixed lifetime objects
These should be pool-allocated, using alloc-pools. It provides all the advantages of obstacks, and you can free and reuse individual objects without having to blow the entire thing away. Also, we have much better stat tracking and memory checking with pools.
Varying size, fixed (but short) lifetime objects
Short here means one pass, or part of one pass. These objects should be either xmalloc'd or obstack'd. Probably obstack'd if you need to blow away all of them at once, or xmalloc'd if you can blow them away one by one. Or, if we want better tracking of memory stats for these objects, or better checking, i'm happy to implement memory pools/arenas (ala apache, other compilers, etc) that provide all the familiar malloc functions, but you can blow away an entire pool at once when you want.
Varying size, fixed (but long) lifetime objects
If you can reuse individual objects, you probably want to use a memory pool/arena. But since you can't do that right now, your best bet is to xmalloc/xfree them if possible, and obstack them otherwise. If you can't reuse individual objects at all, obstack them.
gengtype & C++
See attached PDF slides presented at GCC gathering june 18th 2011 at London Google by Basile Starynkevitch