Garbage collector that would work outside my app?

So I'm searching for opensource, crossplatform (at least win, lin) library that would do garbage collection on some abstract C++ thread/process... So to say be seprate process for app memory management... or at least would present me with some functions for not used memory deletion looking over my process... Are there any such ones? Can boost help me with that?

My main point is to find such garbage collector that would be capable on operating on top of my normal c++ code/.. I mean no special memory allocation no special use of it in main programm code.... may be just somehow connecting to my process and monitoring it... so I am intrested in such gc which would work on top of the process and cleaning so to say wary old not used memory blocks...

So let me describe problem in a littel bit more detail: I have code that works an generally manages it all by it self. but from time to time it just puts some 2-3 mbs开发者_开发知识库 into ram and than never retrn to use tham - I know it does not - I wrote code after all... so thats why I need some on top of my app gc...

I think your time would be better spent fixing your memory leak. It might be a symptom of some other bug that's more serious.

I've never heard or seen a memory management system that plugs in at the process or thread level instead of at the source code level. Without the source, you'd never have enough program information to see what memory is still referenced and what collection of bytes happens to look like a pointer to that address.

You could try Boehm's conservative-marking garbage collector:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/

I haven't ever used it myself, but if you can get your target thread/process to link to its alloc function and a do-nothing free function, you may be in with a chance. The details of dynamic linking of course are platform-specific.

Beware that it won't just drop on top of all C++ code. If you have destructors that do anything other than free memory, then I suspect you're in for a hard time, because although the GC supports finalizers, (a) finalization is fundamentally different from destruction in the sense that it doesn't run promptly and (b) anyway it requires source changes.

It's probably better to fix the memory leaks in your C++ code ;-p Most C++ libraries and so on are written on the assumption that you will use typical C++ techniques for resource management, and they will not necessarily play nicely with GC.