December 05, 2002
Solving Memory Leaks
More news from comp.lang.lisp.
Garbage collection means no more crashes because you confused the hell out of malloc/free/new/delete by freeing something that you shouldn't have. In fact, there's no freeing at all. But, as most of the world learned when they started using Java, GC doesn't necessarily put an end to memory leaks. In C/C++, I use valgrind to debug memory leaks. But what tools are available in lisp?
Lois Wolf reveals some ACL magic for figuring out what's keeping your objects from being reclaimed.
Then Eric Marsden does the same for CMUCL.
Posted by jjwiseman at December 05, 2002 12:42 AM
I would like to object to the use of "memory leak" as an identification to any memory problem. This creates more confusion and does not identify the problem. GC DOES put an end to memory leaks. It does not solves memory waste, object loitering or algorithmical deficiencies. In the languages without GC one would get all of those problems plus memory leaks.
Nice phrases get co-opted. ;)
I'm in the process of debugging (my changes to) the SBCL garbage collector at the moment. SBCL has a SAP-REF function that will look up the value at any memory address, which strictly speaking means no object is ever truly unreachable. The thought has crossed my mind a couple of times that I could therefore replace the current collector with a null GC (never frees anything) and still be technically correct. It'd probably be faster too
It's reasonable to call any accumulation of non-reusable memory a "leak". A perfect GC would free memory that would never be accessed again, not just memory that could never be accessed again.
The net effect of a "hidden root" squirreling away objects that no one needs, or even realizes is there, is just as bad as a program not freeing what it mallocs.
Good site, good blog, thank!