Reference count?

  • Thread starter Thread starter Fred Hedges
  • Start date Start date
F

Fred Hedges

I'm wondering if a tool exists that will integrate with the VS 2005
debugger, such that when I set a breakpoint I can inspect a reference and
see how many other references exist to that object. I'm sure there is an
internal reference count somewhere but have no idea how to inspect it.
 
Hi Fred,

I am not sure if such reference count exists for managed object as it did
exist for COM objects. Reference count is not needed for garbage collection;
instead, there is a list of allocated objects and the garbage collector
knows the object roots of your app and traverses them and its referenced
objects; when finished, the objects in the list that have not been reached
are considered dead and its memory subject to be reclaimed.

--

Best regards,

Carlos J. Quintero

MZ-Tools: Productivity add-ins for Visual Studio
You can code, design and document much faster:
http://www.mztools.com
 
There is absolutely no reference counting in .NET AFAIK. None! Reference
counting is the source of lots of problems (circular references, leaks,
performance, etc).

When the garbage collector kicks in, it does all sorts of magic, suspends
everything for a brief second, counts references for "newly" created objects
(because "New" objects are typically only needed briefly) and destroys them,
and puts older objects (that have survived for a while) for cleanup later
on.... all designed to lessen the impact of the garbage collection
performance hit. There may be ways to tell where a "dead" object lays in the
line to oblivion... but I don't know how. Perhaps using some of .NET
Diagnostics counters, WMI, or stuff like that.
 
Just to verify the thoughts of previous posters: There is no reference
count in .NET. The heap doesn't work that way in .NET.
 
Hmmmmm. I've firmly removed my COM hat now. Thanks for the responses.

So the Garbage Collector can walk the reference list and see if anything in
that list is pointing to something in it's set of allocated "things". Now,
I wonder.... is it possible to find out which things are pointing to a
particular interesting thing, if you see what I mean? ;).
 
So the Garbage Collector can walk the reference list and see if anything in
that list is pointing to something in it's set of allocated "things". Now,
I wonder.... is it possible to find out which things are pointing to a
particular interesting thing, if you see what I mean? ;).
Click to expand...

I believe you can do that with the Sos.dll debugger extensions.


Mattias
 
Not feasible in any garbage collected system. Note I didn't say not
possible. Its simply that the overhead to do this would be so sever that
the system performance would noticibly suffer.

In VB 6 and COM, the system increments a counter in the object header every
time a reference is added to the object. Then the counter is decremented
whenever a reference is removed. When this counter reaches zero, the object
is removed, decrementing references in any objects it points to.

In .NET the system keeps track of memory roots. These are classically the
program stack and data segment. In .NET, there are additional roots such as
a stack and data segment for each thread in a program as well as other roots
that are maintained by the garbage collector itself. When the GC runs, it
starts with each root and sets a flag that uniquley identifies this GC run.
Any objects that aren't identified on this run are eligible for removal from
memory. After the mark pass, memory is compacted by the GC so that
available memory is consolidated at the end of the heap. Microsoft has a
rather extensive technet article on the .NET garbage collector, but this is
the fundamental description of all modern garbage collection systems. Thus,
there is no way to track the number of references to an object. All the
system needs is one reference and it stops looking.

Mike Ober.
 
Back
Top