On 11/16/12, Diego Novillo <dnovi...@google.com> wrote: > On Nov 16, 2012 Basile Starynkevitch <bas...@starynkevitch.net> wrote: > > I actually disagree with the "Get rid of GC" idea, but I am not > > sure that we all understand the same thing about it (and I have > > the feeling of the opposite). I would probably agree with "Get > > rid of Gengtype+Ggc+PCH and replace it with something better" > > which might be what "Get rid of GC" mean. > > We mean get rid of it. No garbage collection, whatsoever. We both > think that it is better to structure the compiler around memory pools. > However, we also concede that we are probably in the minority and we > will need to keep GC around. > > > Thr fact that a compiler deals with a big lot of circular data > > makes me think that naive reference-counting approaches (and > > in my opinion, reference counting is just a very poor method > > of doing garbage collection, which does not work well with > > circular references) cannot work inside a compiler, why they > > do work inside graphical widget libraries ala Qt or GTK. > > > > Hence, I don't understand well how a pool-allocator would work > > in GCC without touching to a huge amount of code. > > Right. It would be a large effort to sort out. Particularly, > since GC has been around for a while and we've gotten lazy and > are probably relying on it quite a bit. For these reasons, > even if we convinced the community to go in this direction, > it would take a while to get there. > > > A big advantage of using Boehm GC is that the interface is > > familar to everyone, and that it handles very nicely local > > pointers without pain. So data inside passes could also > > be GC-ed. > > This may be the most practical approach long term. Boehm-gc is > a well supported and solid solution for GC. But we need to make > sure it works for us.
While I think memory pools are the best long-term approach, we cannot get there in the short term. My preference for the short-term strategy is to place GTY allocation in the final destination address for PCH, and use the Boehm collector to manage that allocation. If the increase in PCH file size is unacceptable, then we can ensure we zero out unused memory and write/read that memory a compressed file. (PCH compresses pretty well already.) This approach has significant advantages. First, we do not need to do GTY annotations, which eliminates a source of error. Second, consequently, we do not need to upgrade gengtype to understand C++. Third, we still have garbage collection, so the vast bulk of the existing code will work unmodified. The only disadvantage, as near as I can tell, are small performance losses during normal compilation, and possibly somewhat larger losses for PCH. -- Lawrence Crowl