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?
