0

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...

Rella
  • 65,003
  • 109
  • 363
  • 636
  • 3
    Why do you need a garbage collector? While there are garbage collectors for C++, most C++ code is written with the assumption that there is no garbage collection. There's not going to be a garbage collector for C++ that you can just drop into C++ code and expect it to work out of the box. – In silico Dec 07 '10 at 21:53
  • 1
    Also, this question is a possible duplicate of [Garbage collectors for C++](http://stackoverflow.com/questions/81062/garbage-collectors-for-c). – In silico Dec 07 '10 at 21:56
  • 1
    @In Silico: The OP's requirement that it runs on an arbitrary thread or process is a big deal. It's not a dupe. – Puppy Dec 07 '10 at 21:58
  • @DeadMG: Oops, I missed that. – In silico Dec 07 '10 at 22:00
  • In my opinion smart pointers are just fine grain garbage collection (that is deterministic). – Martin York Dec 07 '10 at 22:11
  • The overhead of introducing something like a garbage collector into your code vs. running a tool designed to locate memory issues, this is a no brainer for me - use valgrind (or if you have the cash, Purify). Nail the leak, and forget the complexity! – Nim Dec 07 '10 at 22:16
  • Why do you keep looking to build complex pieces of machinery to *get around* what is *obviously* a bug in your program? – John Dibling Dec 07 '10 at 22:22
  • @Kab You asked an earlier question today about using threads to reduce memory leaks, which of course didn't make any sense. The advice then is the advice now: fix your memory leak. And what's this obsession with Boost?! This is your third question today about using Boost to handle memory leaks. – chrisaycock Dec 07 '10 at 22:34

3 Answers3

5

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.

Rob K
  • 8,757
  • 2
  • 32
  • 36
1

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.

Puppy
  • 144,682
  • 38
  • 256
  • 465
  • At least this question is better than his previous one: http://stackoverflow.com/questions/4380324/having-a-function-that-returns-int-how-to-run-it-is-seprate-thread-using-boost – chrisaycock Dec 07 '10 at 22:37
1

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.

Steve Jessop
  • 273,490
  • 39
  • 460
  • 699