On Sun, Feb 27, 2005 at 12:58:24AM +0100, Stefan Strasser wrote: > Tommy Vercetti schrieb: > > > >I don't know what's "refrubish rate" of gc, but I would say that any > >garbage collector is a pretty much cause of solid leak of memory (unless > >it frees memory when not used anymore, but I doubt they do). > > > > > gcc gc does free memory when it has not been used in the last 2 > collections. on a normal termination there are still gc roots so there > are still pages allocated, but I've done a collection with no roots and > GC says 0k allocated, and there's still a leak. > > it must come from another part of gcc. there is a pool allocator, but it > is not used at all(at least when compiling c++). > > would it help to do leak checking on libiberty alloc functions or is > than done regularily anyway?
GCC is not designed as a library, so I expect many parts of the compiler allocate data that does not need to be saved to PCH files and will live the length of the compilation with xmalloc. I'm sure a good leak checker could tell you where they are coming from. -- Daniel Jacobowitz CodeSourcery, LLC
