Re^3: Tool to detect potential memory leak in code

I'll throw out my two cents worth: The term "garbage collection" implies to me that an active process (separate from the main program's flow of execution) goes over the contents of memory that've been allocated at some point (e.g. when memory is "low") and puts unused chunks back onto a free list to be handed back out. Reference counting on the other hand is part of the normal process of getting rid of a handle (when something with 0 external references is encountered it's immediately put back on the free list).

Or maybe in "reference counting" the allocated chunks play a more active part in memory management, whereas with GC it's presumed that there's an almost external actor going through behind the scenes cleaning up after everything.

The cake is a lie.
The cake is a lie.
The cake is a lie.

Comment on Re^3: Tool to detect potential memory leak in code

Replies are listed 'Best First'.
Re^4: Tool to detect potential memory leak in code by locked_user sundialsvc4 (Abbot) on Feb 02, 2009 at 15:21 UTC
“Reference counting” is a mechanism for garbage collection. It allows objects to be recognized as garbage so that they may be disposed-of. It does so in a way that allows this determination to be made while considering only the one object; the one counter. If a garbage-collection algorithm does not employ counters, the entire application memory-space must be periodically “walked,” to “flag” objects as being in-use or not. Either way, it probably involves a memory-write. The crippling characteristic of this approach is ... page faults. You must “touch” everything, hence causing it to be paged-in. A counter-based approach, per contra, doesn't increase the virtual-memory footprint unnecessarily.

Replies are listed 'Best First'.

Re^4: Tool to detect potential memory leak in code
by locked_user sundialsvc4 (Abbot) on Feb 02, 2009 at 15:21 UTC

“Reference counting” is a mechanism for garbage collection. It allows objects to be recognized as garbage so that they may be disposed-of. It does so in a way that allows this determination to be made while considering only the one object; the one counter.

If a garbage-collection algorithm does not employ counters, the entire application memory-space must be periodically “walked,” to “flag” objects as being in-use or not. Either way, it probably involves a memory-write. The crippling characteristic of this approach is ... page faults. You must “touch” everything, hence causing it to be paged-in. A counter-based approach, per contra, doesn't increase the virtual-memory footprint unnecessarily.