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.
