GGC Questions

[Mike Stump]

On Oct 24, 2005, at 9:14 AM, Ranjit Mathew wrote:
>   I have a few queries on GGC, the GCC garbage collector,
> and usage of GTY markers in GCC sources. I would be grateful
> if someone could take some time out to answer these.
>
> First off, several fields are marked "skip", though the
> documents seem to strongly discourage this. For example,
> see ssa_use_operand_t in tree.h.

Was this a question?  :-)  Skipping is anti-social and decreases the  
flexibility of the software, that said, one can skip any field that  
doesn't need to be walked without any technical problems, as that  
field doesn't need to be walked.

So this devolves into, which fields don't need to be walked.  Any  
field that is not live during PCH writing it safe to skip.  The  
liveness of any particular field is deeply related to the algorithm  
that uses the field, and in general, unrelated to PCH, save for  
timing issues.  For example, if during parsing a field it set  
(DECL_SIZE for example), and later read by, say the optimizers (they  
can run post PCH loading), then that field is live.  If it is set  
during optimization, but that type of optimization _never_ runs  
before the PCH is written out (basic block info was at one time an  
example of this type of thing), then that it an example of the type  
of thing that is technical safe to skip.

Now, why avoid skipping, say in the last case.  The answer is, if  
people want to `improve' the compiler by running that sort of  
optimization sooner, then the variable is live.  Bad things will  
happen til they track down the field, and arrange for it to be walked.

> Second, some of the tree nodes ending in variable-length
> arrays do not seem to have the appropriate GTY "length"
> attributes. For example, see struct tree_string's "str"
> field in tree.h.

Can be a form of skip.  In general, only pointers need to be walked,  
data char [1] is just data and is handled by the size of the object  
as I recall.  If you walk the PCH writer, you can watch exactly how  
it does this done if you are curious.

> Lastly, on the gcjx-branch, a simple patch to
> get_output_file_with_visibility() makes it recognise
> ".hh" and ".cc" C++ source files with GTY markers.
> My question is, is this sufficient? Do people foresee
> any problems with this?

When tested, it either works, or it doesn't.  I'd rather it be tested  
and known to work, then say it looks Ok, and have it turn out to be  
incomplete.  For example, the parser knows about a subset of C, if  
those files deviate from this subset too far, they can simply fail to  
work.  Usually these failures are of a compile time nature, so it is  
safe to try it out by building the compiler.  Better of course to  
actually test that the right thing happens.