Count # of Instances of a Particular Class

[Stephen Barrett]

I am looking for a way to fine a definitive answer of how many instances of
a particular class are in memory. I am hoping there is a framework class
that can help me with this.

I have tried to code thsi logic into the class by creating a static variable
to hold the count and then increment it in the constructor and decrement it
in the destructor (also tried to decrement in dispose at one point). I
provided a threadsafe locking mechanism on the increment and decrement
methods.

The problem is that it doesn't seem that my destructor is actually getting
called so the decrement never happens. This class is instantiated via
remoting configured as a SingleCall action. My understanding is that the
object should be created on a call to the remoted method and as soon as the
method exits, the destructor should get called.

I want to verify that I am not doing something wrong by using a framework
method or something to get teh instances in memory of the class. I knwo
some memory profilers have this ability, but I need it to be a runtime value
I can get and log.

Any help would be appreciated.

 

[Bert Hyman]

In "Stephen Barrett"

The problem is that it doesn't seem that my destructor is actually
getting called so the decrement never happens.

As I recall, the destructor won't get called 'til garbage collection
happens.

 

[Jeroen Mostert]

I am looking for a way to fine a definitive answer of how many instances of
a particular class are in memory. I am hoping there is a framework class
that can help me with this.

Not as far as I know. You can inspect the "roots" (the objects from which
allocation trees start) from unmanaged code, but that's about it.

I have tried to code thsi logic into the class by creating a static variable
to hold the count and then increment it in the constructor and decrement it
in the destructor (also tried to decrement in dispose at one point).

C# (and .NET in general) has no destructors, it has finalizers. This
distinction is very important. There is no method in C# that will get called
when a particular object is garbage collected. After an object has
*eventually* been garbage collected, the finalizer (if there is one) will
*eventually* be called, but this could be as late as application shutdown.

..NET provides IDisposable for deterministic finalization, but parties must
agree on using it for this to work.

The problem is that it doesn't seem that my destructor is actually getting
called so the decrement never happens. This class is instantiated via
remoting configured as a SingleCall action. My understanding is that the
object should be created on a call to the remoted method and as soon as the
method exits, the destructor should get called.

Your understanding is wrong, and likely based on C++. You may be able to
leverage IDisposable in this case, though -- the framework should call
Dispose() after it's done with the instance.

I want to verify that I am not doing something wrong by using a framework
method or something to get teh instances in memory of the class. I knwo
some memory profilers have this ability, but I need it to be a runtime value
I can get and log.

It's unlikely to be of any help. If you need memory details, use the
built-in performance counters or the methods of the GC class. If you need to
debug correct use of your class, you'll need to use some method that's not
tied to memory, as the .NET framework manages memory automatically.

 

[Jeroen Mostert]

Not as far as I know. You can inspect the "roots" (the objects from
which allocation trees start) from unmanaged code, but that's about it.

Eh.

Your understanding is wrong, and likely based on C++. You may be able to
leverage IDisposable in this case, though -- the framework should call
Dispose() after it's done with the instance.

Well, I should learn to read more carefully, I guess. You did implement
IDisposable, right, not merely add a Dispose() method?

 

[Stephen Barrett]

Yes I implemented IDisposable. When I mentioned the destructor, I was
talking about the finalizer, i.e. ~{classname} method

 

[Göran Andersson]

I am looking for a way to fine a definitive answer of how many instances of
a particular class are in memory. I am hoping there is a framework class
that can help me with this.

I have tried to code thsi logic into the class by creating a static variable
to hold the count and then increment it in the constructor and decrement it
in the destructor (also tried to decrement in dispose at one point).

Well, if you had actually called the Dispose method also, it would
definitely have decremented the counter...

The Dispose method isn't called automatically. It's intended for the one
using the class to control the life cycle of the instance.

 

[Tom Dacon]

C# (and .NET in general) has no destructors, it has finalizers.

A lot of people think that, but a quick look at the C# help file will tell
you that C# does indeed have destructors. In this destructor, taken from the
help file:

 

[Tom Dacon]

Stephen Barrett wrote:

C# (and .NET in general) has no destructors, it has finalizers.

(Hit enter accidentally and didn't finish what I was saying):

A lot of people think that, but a quick look at the C# help file will tell
you that C# does indeed have destructors. In this destructor, taken from the
MSDN help file
(ms-help://MS.VSCC.v90/MS.MSDNQTR.v90.en/dv_csref/html/1ae6e46d-a4b1-4a49-abe5-b97f53d9e049.htm):

class Car
{
~ Car() // destructor
{
// cleanup statements...
}
}

the destructor (whenever it's actually executed, if ever) runs the
programmer-supplied clean-up statements, and then, so the help file tells
us, implicitly calls Finalize at the end of its processing.

Tom Dacon
Dacon Software Consulting

 

[Jeroen Mostert]

(Hit enter accidentally and didn't finish what I was saying):

A lot of people think that, but a quick look at the C# help file will tell
you that C# does indeed have destructors. In this destructor, taken from the
MSDN help file
(ms-help://MS.VSCC.v90/MS.MSDNQTR.v90.en/dv_csref/html/1ae6e46d-a4b1-4a49-abe5-b97f53d9e049.htm):

class Car
{
~ Car() // destructor
{
// cleanup statements...
}
}

the destructor (whenever it's actually executed, if ever) runs the
programmer-supplied clean-up statements, and then, so the help file tells
us, implicitly calls Finalize at the end of its processing.

Though it's correctly describing behavior, the MSDN is using outdated
terminology here. From ECMA-334, 4th edition:

"Note: In the previous version of this standard, what is now referred to as
a "finalizer" was called a "destructor". Experience has shown that the term
"destructor" caused confusion and often resulted to incorrect expectations,
especially to programmers knowing C++. In C++, a destructor is called in a
determinate manner, whereas, in C#, a finalizer is not. To get determinate
behavior from C#, one should use Dispose."

That method you get by putting a squiggly line before the class name is now
officially called a "finalizer", not a destructor, and that's a good thing
too. Unfortunately, the MSDN still seems to use "destructor". I wouldn't
keep that habit, it causes more harm than good.

 

[jmostert]

Though it's correctly describing behavior, the MSDN is using outdated  
terminology here. From ECMA-334, 4th edition: [snipped]

Um...except that in the C# 3.0 specification (which is more recent than  
ECMA-334, the 2.0 specification), they have gone back to the term  
"destructor".  The only time the word "finalizer" shows up is in code  
samples where the method GC.WaitForPendingFinalizers() is called.

ECMA or bust!

[...]
That method you get by putting a squiggly line before the class name is 
now officially called a "finalizer", not a destructor, and that's a good  
thing too. Unfortunately, the MSDN still seems to use "destructor". I  
wouldn't keep that habit, it causes more harm than good.

I personally agree with the motiviation for using only the word  
"finalizer" rather than "constructor".

Well, "constructor" can stay.

 But for better or worse, even the  
inventors of the language are not being consistent about it.

I guess we can wait for the 4.0 specification to show up and see what they  
call it this time 'round.    (Or maybe once the 3.0 specification is  
ratified by ECMA, they'll have changed it back to "finalizer" there).

I do hope the latter will be the case. The motivation in the 2.0 spec
makes eminent sense, and I'd really like to be able to talk about
finalizers vs. destructors rather than "C# destructors" vs. "C++
destructors". Personally, I think even retaining the destructor syntax
was a mistake, but that was something that should have been put right
in 1.0 and there's no sense changing it now.

 

[Kürþat]

AFAIK, the dispose pattern -even though it is used correctly- doesn't ensure
that the object is removed from memory. It is used for releasing unmanaged
resources or changing some user controlled states of managed resources. GC
is still responsible for releasing objects which implement dispose pattern
and it can do this anytime!

 

[Dan Ruehle]

Since your class is configured for SingleCall, it sounds like you are
looking to see how many clients are currently calling your method. What you
can do is in your method, increment the counter in the beginning of your
method and decrement it at the end in a try..catch..finally block. This
would essentially give you the same information, just a little delayed from
object creation and well before object finalization (destruction or whatever
you would like to call it).