[trunk r143197] patch adding optional extra marking to GGC
Ian Lance Taylor
Mon Jan 12 19:10:00 GMT 2009
Basile STARYNKEVITCH <firstname.lastname@example.org> writes:
> I forgot to insist that I am talking about calling the GGC collector
> from *inside* passes. It being called from the pass manager is ok
> me, but there are situations where it is not enough. I repeat that my
> focus is the rare situations where invoking the GGC collector inside a
> pass is useful. I have no issues with the way it is called from the
> pass manager.
I think I'm confused. Memory which is allocated entirely within a
single pass, and freed by that pass, should not use the garbage
collector. I appreciate that in some cases it is easier to not bother
to keep track of your memory usage. But in C/C++ that is ultimately
sloppy coding. In fact, the reason that we use a garbage collector in
gcc itself amounts to sloppy coding. We should strive to eliminate
uses of the garbage collector, not add to them.
Within a single pass, why not just use an obstack? Does your pass
really use so much memory that you need to free in the middle, and you
are also unable to track which memory you are using and which you
should free? That seems unusually complicated for a single pass.
>> Would your
>> needs be satisfied if there were a way to dynamically add roots to the
> It would be satisfied if I can add dynamically a marking *routine*
> (not only plain struct-s static data). I believe this could be hided
> as adding an extra root [a fake structure] and providing its marking
> routine, perhaps using tricky mark_hook or if_marked GTY
> options. http://gcc.gnu.org/onlinedocs/gccint/GTY-Options.html#GTY-Options
> But I really don't think it is simpler or safer. My proposed patch
> ggc_collect_extra_marking is extremely short (most of the patch is
> documentation or comments, the real added code is 18 lines).
The patch is short but it means that people must effectively write
their own GC traversal routines. If they are doing that for
pass-specific data, I see little point to hooking into the main GC at
all. Allocate the memory in your own allocation pool instead.
In any case, a short patch doesn't mean one that is easy to use. If
it is really desirable to hook into the GC, I think it will be easier
for people to write their own traversal routine and their own root
set, and let the generic GC code handle it, than it will be for them
to understand the details of how the GC works and when their
additional traversal code will be invoked.
Your patch, although it is short, appears to me to move gcc toward
greater complexity. I'm certainly open to hearing different opinions
from other people.
More information about the Gcc-patches