This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GGC Questions


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]