On Sat, Nov 17, 2012 at 12:35 AM, Basile Starynkevitch <bas...@starynkevitch.net> wrote: > On Fri, Nov 16, 2012 at 07:44:12PM -0800, Xinliang David Li wrote: >> > >> > >> > My strong belief is that a compiler project as gigantic as GCC needs some >> > kind >> > of garbage collection >> >> Can you name another compiler written in C/C++ using GC ? :) > > First, C or C++ is not the best language to write a compiler in, and actually > GCC is not entirely > hand written in C or C++; As http://www.cse.iitb.ac.in/grc/ (i.e. the great > work of Uday Khedker and colleagues, India) demonstrate, GCC is a framework > with a significant amount of meta-programs, i.e. specialized C code > generators. So GCC is not entirely hand-written in C or C++ > > And several compilers or static analyzers of C programs have a garbage > collected implementation, > in particular those written in Ocaml: the frama-c.com static analyzer and the > CompCert certified compiler.
My main point is that other main open source compilers like clang/llvm, open64 and some main commercial compilers I know do not use GC, which proves that GC is not a must for a compiler to be easy to work with or to be a good open code analysis framework. > > I know people working on these projects quite well (Frama-C is developped by > my current colleagues at CEA, LIST; CompCert is leaded by Xavier Leroy, and I > worked one year in his Cristal team in 2004). > They all say that the garbage collector of Ocaml is an essential piece. > > And when I measure with -ftime-report some long, optimized, compilation by > GCC I see that GC takes > a small fraction (often less than 5 or 10%) of the whole time. For an optimized build, 5-10%, in my opinion is a lot. Besides, without explicit memory managent, the memory footprint and data working set tends to be larger and this contributes the compile time to all the other passes indirected due to increased paging activities, TLB misses, and d-dache misses. > > And if we switch to memory pool, that will take time also. Actually, if every > dynamic memory allocation > in GCC was done with malloc+free or new+delete, we may have issues in > measuring them > (because libstdc++ might not have hooks to measure that) > but they won't be free. tcmalloc (http://goog-perftools.sourceforge.net/doc/tcmalloc.html) is a very good allocator. We have measured before that it beats system malloc and other open source allocators in performance even for single threaded applications (SPEC, SPEC06). Besides it provide very good support for heap profiling and sampling, and supports heap check such leaks. David > > Regards. > > -- > Basile STARYNKEVITCH http://starynkevitch.net/Basile/ > email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359 > 8, rue de la Faiencerie, 92340 Bourg La Reine, France > *** opinions {are only mines, sont seulement les miennes} ***
