This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: destruction of GTY() data
I'm not sure to understand what Daniel suggests. If he dreams of a
better memory handling than the current GGC, I certainly agree; I
actually dream of a GCC future compiler where every data is garbage
collected in a copying generational scheme (see my Qish
experiment). This would require some preprocessor or even perhaps some
language support. So I realize that it is currently inpractical. I
won't discuss details now, but suggest diving into Jones & Lins book
on garbage collection),
I've read the book before.
Also, it would require neither a prepocessor or more language support.
It has, in fact, been done twice before, but neither was ever more
than a few percent faster.
This is without generational support, since generational support
required barriers that nobody wanted to implement for a prototype :)
but I still call such futuristic memory
handling garbage collection. If Daniel means that the very idea of
garbage collection in a compiler is bad, and that every object should
be manually allocated & explicitly freed (à la malloc & free or like
C++ new/delete, I respectfully disagree with him. (BTW I must admit
here that I have some Ocaml experience).
Uh, well, you see, there are points in between these two extremes.
Most commercial compilers are not garbage collected, they rely on
allocation pools (ie multiple heap) to get sane performance and
lifetime management.
You see, we currently waste a lot of memory to avoid the fact that our
GC is very slow.
We still take it on the chin when it comes to locality. Previous
things such as moving basic blocks from alloc_pools (which are
contiguous) to gc'd space cost us 2-3% compilation time alone, because
of how bad our GC places objects.
Zack Weinberg wrote in http://gcc.gnu.org/ml/gcc/2006-12/msg00159.html
> We definitely don't have the feature you want now, and I would be
> very hesitant to try to add it - the existing sweep phase is quite
> lazy, and I'd really prefer not to do anything that made it harder
> to switch to a more efficient collector algorithm.
> On the other hand, I sympathize with your goal; I've been idly
> thinking a little myself about the sensibility of using MPFR
> throughout, instead of our bespoke REAL_VALUE_TYPE thing. [I don't
> know if this is actually a good idea yet.]
I presume that Zack refers to some comment in gcc/fold-const.c (rev
119546 of trunk) where I read
/*@@ This file should be rewritten to use an arbitrary precision @@
representation for "struct tree_int_cst" and "struct tree_real_cst".
My understanding is that constant folding is currently done in ad-hoc
(two-words) arithmetic, and that the trend is to go to arbitrary
precision arithmetic using MPFR & GMP (which seems to be needed not
only for Fortran). Since the constants are inside Gimple-like trees
(even if you represent them by tuples), I am expecting that they are
garbage collected, so need to be freed.
> So my question to you is, what do those destruction routines do, and
> is are they actually a necessary thing if the memory has been
> allocated by GGC rather than library-internal calls to malloc()?
If the libraries we are using (today MPFR & GMP, and tomorrow, on my
side, probably PPL -using only its C API interface- -- I am interested
in time-consuming static analysis) do not offer internal memory hooks
but offer only allocate & delete (or clear) routines, then I still
believe that many of us will take advantage of GTY-structure which
have a destructor.
This just isn't that big a problem. If you want to associate these
things with trees, put them in annotations, mark them GTY ((skip)) and
explicitly manage their lifetime. It is highly unlikely that they are
going to live for some indeterminate amount of time.
This is what is going to happen on the graphite branch, which will use
PPL to do polyhedral data dependence testing and high level loop
optimizations.
Maybe if you described what use pattern you think will cause you to
need to put these in GC'd objects, but not know when they are all
going to be destructed?