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?
-- Stefan Strasser