Garbage Collector Reference Counting

[mdoxdo]

Hi all,

I was wondering if there is a way to get the number of references an
objects have (ie, other objects reference that object)? I know
that .Net GC uses a different mechanism than the RefCount in C++
since .Net uses managed objects. I just need to know if there is any
way possible to get this number.

Any comments would be appreciated.

 

[Chris Mullins [MVP - C#]]

Many of the debuggers / memory profilers will do it.

The ones that I use that have this feature are:
- Windbg + Son of Strike. I often use the sosex extension as well, as I like
it's commands quite a bit more than SOS's.

- Scitech Memory Profiler will give you this.

- I *think* the RedGate Memory profiler gives you this.

 

[Nicholas Paldino [.NET/C# MVP]]

Unless you hook into the CLR, the answer is effectively no.

What do you want this information for?

 

[Nicholas Paldino [.NET/C# MVP]]

I should elaborate, from within your program, you can't, but using
external tools, you can.

Which are you trying to do, get it in your program, or outside of your
program?


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Unless you hook into the CLR, the answer is effectively no.

What do you want this information for?

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi all,

I was wondering if there is a way to get the number of references an
objects have (ie, other objects reference that object)? I know
that .Net GC uses a different mechanism than the RefCount in C++
since .Net uses managed objects. I just need to know if there is any
way possible to get this number.

Any comments would be appreciated.

 

[mdoxdo]

Basically, we are building a WPF application and we are running
through performance issues, mostly memory issues. The problem resides
where objects are not being collected by the GC even after the
application have no use for it. I have tried nulling out the objects
and calling GC.Collect() but it proved futile.

One of the issues we found is with the event subscription bug where
objects that have its event handlers subscribed are not being
collected because the subscriber have a reference to it in some form.
I tried removing the subscription using (-=) operator but it didn't
seem to work.

So I am trying to locate what is referencing the object so I can know
how to remove it. Is there another way for this problem or am I going
on the wrong path?

 

[mdoxdo]

I just made another post and it didn't seem to have gone through. Here
it goes again.

Basically, we have an application written using WPF/XAML and we are
having issues where objects are not being garbaged collected long
before we stopped using it. We tried specifically nulling it out and
calling GC.Collect(). We also tried to remove any event connections
but that didn't seem to work.

See: http://paulstovell.net/blog/index.php/wpf-binding-bug-leads-to-possible-memory-issues/
for Events connection bugs.

So we're just trying to come up with ways to fix this issue. We
realized that somehow and somewhere the object we want to removed is
being referenced. We just don't know where. This is where the RefCount
comes in.

Any comments would be appreciated.

 

[Chris Mullins [MVP - C#]]

Use the SciTech memory profile, it'll make your life easy.

Run your app. Click around. Collect a heap snapshot.

Click around for a while. Collect another heap snapshop.

Compare.

It may take a while, but you'll get it.

If you're really stuck, and have a deadline, I know a guy who may be willing
to help you remotely, after hours, for an hourly fee...

I go through this the hard way (via a crash dump, and Son of Strike) here:
http://www.coversant.net/Default.aspx?tabid=88&EntryID=28

 

[Chris Nahr]

Hi all,

I was wondering if there is a way to get the number of references an
objects have (ie, other objects reference that object)? I know
that .Net GC uses a different mechanism than the RefCount in C++
since .Net uses managed objects. I just need to know if there is any
way possible to get this number.

Any comments would be appreciated.

As you said, the .NET GC does not actually use reference counting. The
references are established only during the actual garbage collection,
and I don't think they are actually counted even then -- the GC only
needs to know whether there is at least one reference or not, so it
wouldn't make sense to count them and store the count.

You would need an external tool like a profiler that maintains its own
object reference tree.

 

[Jeff Louie]

mdoxdo... It seems to me that in .NET most classes that implement the
Observable pattern use "client driven registration" where the Supplier
fires the event, but the Clients register an interest in the event. As a
result you can the see the lapsed listener memory problem.

"The “lapsed listener” problem occurs when objects subscribe to events
and subsequently fall out of scope. The problem is that the event
subscriber doesn’t get garbage collected because the event is still
holding a reference to it inside of the event’s invocation list."

I think it is possible to use "supplier driven registration" in which
the supplier fires event and registers/unregisters listeners. This
requires that each listener implement an interface with GetXXXHandler
methods that return a delegate for each XXXHandler.

Regards,
Jeff
http://paulstovell.net/blog/index.php/wpf-binding-bug-leads-to-possible-
memory-issues/
for Events connection bugs.<<

 

[Serge Baltic]

Hello,

One of the issues we found is with the event subscription bug where
objects that have its event handlers subscribed are not being
collected because the subscriber have a reference to it in some form.
I tried removing the subscription using (-=) operator but it didn't
seem to work.

You can easily check that using a memory profiling tool. I'd give more details
if you need them.

If events are the problem, there're basically two ways for fixing them:

(1) Explicit memory tracking, like in bare C++: when the object is needed
no more, you call Dispose() on it, and the object unsinks any events it used
to sink throughout its lifetime. Works in most scenarios, yet impossible
to implement in certain cases.

(2) Don't keep a strong reference from the event source to the event sink.
Technically, the event source stores a delegate that points to the class
that is to be called to handle the event, which holds the event sink on a
reference. That reference could be replaced with a “weak reference†which
does not prevent the object from being collected. See the WeakEventManager
class for details.

This (2) approach is universally applicable, but don't forget about the penalty
of managing a multitude of weak references, that does not come for free.
Use (1) wherever possible.

(H) Serge