(sorry for breaking threads... re. http://gcc.gnu.org/ml/gcc/2012-11/msg00304.html)
On Tue, 20 Nov 2012 09:57:35 +0100, Eric Botcazou wrote: > > I wouldn't jump to that conclusion too quickly. I think we should be > > GC free as well, and I doubt I am the only other one. > > Dropping the GC means re-introducing a whole class of bugs though. Are we > ready to divert a possibly significant part of our time to fixing memory > management bugs again? IMO it's better spent on more interesting things. I'm not so sure that dropping GC would re-introduce the same problems that existed with obstacks. GCC has moved more and more to explicit tracking of liveness of objects, and GC is more an obstacle than a tool for much of the compiler when it comes to memory management right now. For example, the CFG data structures (basic_block_def, edge_def and edge VECs) always were tracked explicitly using alloc-pools, but they had to be moved to GC space just to keep pointers around to the insns stream. Since than, things have changed to the point that almost all GIMPLE objects also have their liveness tracked explicitly (operand caches, SSA name caches, etc.). Entire translation units can be tracked explicitly now. Also, our set of tools to debug memory allocation problems has improved a lot. There was no such thing as valgrind in the obstack days, there was no memory poisoning of freed memory (the set-to-0xaf stuff in alloc-pool and ggc-page/ggc-zone), and no detailed memory usage statistics gathering. Fewer objects are lists now, which also helps reduce the risks of dangling pointers. And now we have the potential benefits of C++ over C to encapsulate things better and let memory be managed by the objects instead of explicitly in the code. I'm not saying GC is necessarily a bad thing. But what's there in GCC now is just bad memory management. There is no good method available to group related objects (except with ggc-zone, which nobody uses, and it's still got its limitations) so that the number of cache misses on e.g. FOR_EACH_BB or GC-bitmap walks is much larger than necessary. Also, there are lots of places in GCC that work around GC with free-lists (a.o. GC-bitmaps) and other rather tricky things to avoid memory scattering and excessive allocation of new objects when old objects have died but ggc_alloc can't be called (too expensive, don't want to insert explicit gcc-collects all over, etc.). Ideally there'd be a possibility to better mix GC and other memory management strategies, so that e.g. the CFG data structures but also SSA_NAME trees can live in alloc pools but objects that are harder to track can be in GGC space with more flexible roots that can be set at run-time (e.g. ggc_make_root (basic_block_il_dependent.x.head) and ggc_discard_root(...) if CFG data structures live in pools but the RTL insns stream lives in GC space). Pie in the sky...? Ciao! Steven
