GC dont call my Dispose-Method although I implemented IDisposable

Jazper

hi

i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to test my
Dispose-Method.... but when set a breakpoint in my Dispose-Method and call
the GC nothing happend!!! my Disposemethod has never been called!! so the GC
dont call my Dispose-Method although I implemented IDisposable?

what am i doing wrong?

Regards, Jazper

---Code ---------------------------------------------------------------
private void Test()
{
for(int i=0; i < 50000; i++)
{
CEmployee oEmployee = new CEmployee();
}
GC.Collect();
}

public class CEmployee : CRootItem, IDisposable
{
protected OleDbDataAdapter _Adapter;
protected DataTable _Data;

public void Dispose()
{
this._Adapter.Dispose(); //BRAKPOINT HERE!!
this._Data.Dispose();
}

public CEmployee()
{
this._Adapter = new OleDbDataAdapter();
this._Data = new DataTable();
}
}

Nov 15 '05 #1

Follow Post Reply

7448

Cybertof

I have heard that it is not possible to predict when the real Garbage
Collection operation will occur, even when calling GC.Collect()...
But I don't know anymore about it for now.

A MVP comment on this subject would be appreciable :=)
Cybertof.
In article <e#**************@TK2MSFTNGP09.phx.gbl>, j.***@bluewin.ch
says...

hi

i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to test my
Dispose-Method.... but when set a breakpoint in my Dispose-Method and call
the GC nothing happend!!! my Disposemethod has never been called!! so the GC
dont call my Dispose-Method although I implemented IDisposable?

what am i doing wrong?

Regards, Jazper

---Code ---------------------------------------------------------------
private void Test()
{
for(int i=0; i < 50000; i++)
{
CEmployee oEmployee = new CEmployee();
}
GC.Collect();
}

public class CEmployee : CRootItem, IDisposable
{
protected OleDbDataAdapter _Adapter;
protected DataTable _Data;

public void Dispose()
{
this._Adapter.Dispose(); //BRAKPOINT HERE!!
this._Data.Dispose();
}

public CEmployee()
{
this._Adapter = new OleDbDataAdapter();
this._Data = new DataTable();
}
}

Nov 15 '05 #2

Mr.Tickle

Its easy to predict the .NET GC.

It will garbage collect when planets collide and Bush and Tony Blair tells
the truth

"Cybertof" <cy****************@gmx.net> wrote in message
news:MP************************@msnews.microsoft.c om...

I have heard that it is not possible to predict when the real Garbage
Collection operation will occur, even when calling GC.Collect()...
But I don't know anymore about it for now.

A MVP comment on this subject would be appreciable :=)
Cybertof.
In article <e#**************@TK2MSFTNGP09.phx.gbl>, j.***@bluewin.ch
says...
hi

i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to test my Dispose-Method.... but when set a breakpoint in my Dispose-Method and call the GC nothing happend!!! my Disposemethod has never been called!! so the GC dont call my Dispose-Method although I implemented IDisposable?

what am i doing wrong?

Regards, Jazper

---Code ---------------------------------------------------------------
private void Test()
{
for(int i=0; i < 50000; i++)
{
CEmployee oEmployee = new CEmployee();
}
GC.Collect();
}

public class CEmployee : CRootItem, IDisposable
{
protected OleDbDataAdapter _Adapter;
protected DataTable _Data;

public void Dispose()
{
this._Adapter.Dispose(); //BRAKPOINT HERE!!
this._Data.Dispose();
}

public CEmployee()
{
this._Adapter = new OleDbDataAdapter();
this._Data = new DataTable();
}
}

Nov 15 '05 #3

Patrick Philippot

Jazper wrote:

i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to
test my Dispose-Method.... but when set a breakpoint in my
Dispose-Method and call the GC nothing happend!!! my Disposemethod
has never been called!! so the GC dont call my Dispose-Method
although I implemented IDisposable?

The GC calls Finalize, not Dispose. Never. Implementing IDisposable and
notifying the GC that you don't want Finalize to be called by the GC (by
calling GC.SuppressFinalize()) means that you adhere to the Dispose
pattern for your object's cleanup. That is, you decide that the object
cleanup is made explicitly by the object's client, which must call
Dispose itself. To make it short, you just say "The client is in charge
of triggering the object's cleanup ASAP instead of the GC". The GC will
still take care of freeing the object's memory, though. But since the
object's client has called Dispose, the object will be cleaned up long
before it is freed.

If you call GC.SuppressFinalize, your object will be "garbage collected"
faster.

Using the IDispose interface is just the recommended way of doing this.
But you could merely implement a Cleanup method and require that your
object's clients call this method when they're done with it. IDispose is
just that.

Implementing IDispose is done for objects consuming resources that must
be freed as soon as possible and for which waiting for the call made by
the GC to Finalize is too costly.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #4

Jazper

hi Cybertof

OK, that's nice isn't it? in the meantime i'm familiar with issues like this
for Microsoft Software... :-)
so my current problem is, that my memory rises whatever i do. I could
control the memory in C++ by destructor and delete. of course it was
complexer. but the fact is I COULD CONTROL IT. with CSharp i can't!! the
memory raises and raises and there is nothing I can do against it? what kind
of Langugage and Framework should that be? why using a framework when the
GC does not its work??? typical Micro$oft!

the other possibility is that i use it the wrong way, so that it is not
working???
everytime when i create a new Form and Destroy it afterwards a few Bytes in
my memory will not be freed. the effect is that the applications memory
rises from 27MB to nearly 40MB.

Anybody any idea how i get a grip on this?
thanks Jazper

"Cybertof" <cy****************@gmx.net> schrieb im Newsbeitrag
news:MP************************@msnews.microsoft.c om...

I have heard that it is not possible to predict when the real Garbage
Collection operation will occur, even when calling GC.Collect()...
But I don't know anymore about it for now.

A MVP comment on this subject would be appreciable :=)
Cybertof.
In article <e#**************@TK2MSFTNGP09.phx.gbl>, j.***@bluewin.ch
says...
hi

i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to test my Dispose-Method.... but when set a breakpoint in my Dispose-Method and call the GC nothing happend!!! my Disposemethod has never been called!! so the GC dont call my Dispose-Method although I implemented IDisposable?

what am i doing wrong?

Regards, Jazper

---Code ---------------------------------------------------------------
private void Test()
{
for(int i=0; i < 50000; i++)
{
CEmployee oEmployee = new CEmployee();
}
GC.Collect();
}

public class CEmployee : CRootItem, IDisposable
{
protected OleDbDataAdapter _Adapter;
protected DataTable _Data;

public void Dispose()
{
this._Adapter.Dispose(); //BRAKPOINT HERE!!
this._Data.Dispose();
}

public CEmployee()
{
this._Adapter = new OleDbDataAdapter();
this._Data = new DataTable();
}
}

Nov 15 '05 #5

Mr.Tickle

Welcome to the world of managed code runtimes, you're new around here arn't
you :D

As slong as you handle unmanaged resources cleanup you are fine. If you need
something to happen at a particular point in time, call a method.

"Jazper" <j.***@bluewin.ch> wrote in message
news:OW**************@TK2MSFTNGP11.phx.gbl...

hi Cybertof

OK, that's nice isn't it? in the meantime i'm familiar with issues like this for Microsoft Software... :-)
so my current problem is, that my memory rises whatever i do. I could
control the memory in C++ by destructor and delete. of course it was
complexer. but the fact is I COULD CONTROL IT. with CSharp i can't!! the
memory raises and raises and there is nothing I can do against it? what kind of Langugage and Framework should that be? why using a framework when the
GC does not its work??? typical Micro$oft!

the other possibility is that i use it the wrong way, so that it is not
working???
everytime when i create a new Form and Destroy it afterwards a few Bytes in my memory will not be freed. the effect is that the applications memory
rises from 27MB to nearly 40MB.

Anybody any idea how i get a grip on this?
thanks Jazper

"Cybertof" <cy****************@gmx.net> schrieb im Newsbeitrag
news:MP************************@msnews.microsoft.c om...
I have heard that it is not possible to predict when the real Garbage
Collection operation will occur, even when calling GC.Collect()...
But I don't know anymore about it for now.

A MVP comment on this subject would be appreciable :=)
Cybertof.
In article <e#**************@TK2MSFTNGP09.phx.gbl>, j.***@bluewin.ch
says...
hi

i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to
test
my Dispose-Method.... but when set a breakpoint in my Dispose-Method and call the GC nothing happend!!! my Disposemethod has never been called!! so the GC dont call my Dispose-Method although I implemented IDisposable?

what am i doing wrong?

Regards, Jazper

---Code ---------------------------------------------------------------
private void Test()
{
for(int i=0; i < 50000; i++)
{
CEmployee oEmployee = new CEmployee();
}
GC.Collect();
}

public class CEmployee : CRootItem, IDisposable
{
protected OleDbDataAdapter _Adapter;
protected DataTable _Data;

public void Dispose()
{
this._Adapter.Dispose(); //BRAKPOINT HERE!!
this._Data.Dispose();
}

public CEmployee()
{
this._Adapter = new OleDbDataAdapter();
this._Data = new DataTable();
}
}

Nov 15 '05 #6

Mr.Tickle

..NET retains memory allocated , even tho it is no longer used for
performance reasons, it will only be free'd up once an external process
requires this memory. Why free up memory when there is no need and its
likely to be reallocated anyway? Its for performance reasons, you should
also read about resurection by the GC, finalised objects can be resureacted
:D fascinating read.

I believe MSDN has some good indepth articles on garbage collection under
periodicals or that other text section.

"Jazper" <j.***@bluewin.ch> wrote in message
news:OW**************@TK2MSFTNGP11.phx.gbl...

hi Cybertof

OK, that's nice isn't it? in the meantime i'm familiar with issues like this for Microsoft Software... :-)
so my current problem is, that my memory rises whatever i do. I could
control the memory in C++ by destructor and delete. of course it was
complexer. but the fact is I COULD CONTROL IT. with CSharp i can't!! the
memory raises and raises and there is nothing I can do against it? what kind of Langugage and Framework should that be? why using a framework when the
GC does not its work??? typical Micro$oft!

the other possibility is that i use it the wrong way, so that it is not
working???
everytime when i create a new Form and Destroy it afterwards a few Bytes in my memory will not be freed. the effect is that the applications memory
rises from 27MB to nearly 40MB.

Anybody any idea how i get a grip on this?
thanks Jazper

"Cybertof" <cy****************@gmx.net> schrieb im Newsbeitrag
news:MP************************@msnews.microsoft.c om...
I have heard that it is not possible to predict when the real Garbage
Collection operation will occur, even when calling GC.Collect()...
But I don't know anymore about it for now.

A MVP comment on this subject would be appreciable :=)
Cybertof.
In article <e#**************@TK2MSFTNGP09.phx.gbl>, j.***@bluewin.ch
says...
hi

i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to
test
my Dispose-Method.... but when set a breakpoint in my Dispose-Method and call the GC nothing happend!!! my Disposemethod has never been called!! so the GC dont call my Dispose-Method although I implemented IDisposable?

what am i doing wrong?

Regards, Jazper

---Code ---------------------------------------------------------------
private void Test()
{
for(int i=0; i < 50000; i++)
{
CEmployee oEmployee = new CEmployee();
}
GC.Collect();
}

public class CEmployee : CRootItem, IDisposable
{
protected OleDbDataAdapter _Adapter;
protected DataTable _Data;

public void Dispose()
{
this._Adapter.Dispose(); //BRAKPOINT HERE!!
this._Data.Dispose();
}

public CEmployee()
{
this._Adapter = new OleDbDataAdapter();
this._Data = new DataTable();
}
}

Nov 15 '05 #7

Jazper

Hi Mr.Tickle

you do it the ironic way :-D
you're right. Freeing Memory when no other is using it can be silly. but
what when my application is running on a server which will be controlled by
humans... it looks a bit freaky when only my application raises memory
regardless of the fact that the framework would/could/should/will free it
when another app memory is requesting... this looks like a memory leak for
any IT!

but that suits to microsofts reputation!

i'll have a look at MSDN as you suggested!
thank you!
regards, jazper

"Mr.Tickle" <Mr******@mrmen.com> schrieb im Newsbeitrag
news:%2***************@tk2msftngp13.phx.gbl...

.NET retains memory allocated , even tho it is no longer used for
performance reasons, it will only be free'd up once an external process
requires this memory. Why free up memory when there is no need and its
likely to be reallocated anyway? Its for performance reasons, you should
also read about resurection by the GC, finalised objects can be resureacted :D fascinating read.

I believe MSDN has some good indepth articles on garbage collection under
periodicals or that other text section.

"Jazper" <j.***@bluewin.ch> wrote in message
news:OW**************@TK2MSFTNGP11.phx.gbl...
hi Cybertof

OK, that's nice isn't it? in the meantime i'm familiar with issues like

this
for Microsoft Software... :-)
so my current problem is, that my memory rises whatever i do. I could
control the memory in C++ by destructor and delete. of course it was
complexer. but the fact is I COULD CONTROL IT. with CSharp i can't!! the
memory raises and raises and there is nothing I can do against it? what

kind
of Langugage and Framework should that be? why using a framework when the GC does not its work??? typical Micro$oft!

the other possibility is that i use it the wrong way, so that it is not
working???
everytime when i create a new Form and Destroy it afterwards a few Bytes

in
my memory will not be freed. the effect is that the applications memory
rises from 27MB to nearly 40MB.

Anybody any idea how i get a grip on this?
thanks Jazper

"Cybertof" <cy****************@gmx.net> schrieb im Newsbeitrag
news:MP************************@msnews.microsoft.c om...
I have heard that it is not possible to predict when the real Garbage
Collection operation will occur, even when calling GC.Collect()...
But I don't know anymore about it for now.

A MVP comment on this subject would be appreciable :=)
Cybertof.
In article <e#**************@TK2MSFTNGP09.phx.gbl>, j.***@bluewin.ch
says...
> hi
>
> i have this problem. i made a class deverted by CRootItem with
> implementation of IDisposable-Interface. i made a test-funktion to test
my
> Dispose-Method.... but when set a breakpoint in my Dispose-Method

and call
> the GC nothing happend!!! my Disposemethod has never been called!!
so the GC
> dont call my Dispose-Method although I implemented IDisposable?
>
> what am i doing wrong?
>
> Regards, Jazper
>

---Code ---------------------------------------------------------------
> private void Test()
> {
> for(int i=0; i < 50000; i++)
> {
> CEmployee oEmployee = new CEmployee();
> }
> GC.Collect();
> }
>
> public class CEmployee : CRootItem, IDisposable
> {
> protected OleDbDataAdapter _Adapter;
> protected DataTable _Data;
>
> public void Dispose()
> {
> this._Adapter.Dispose(); //BRAKPOINT HERE!!
> this._Data.Dispose();
> }
>
> public CEmployee()
> {
> this._Adapter = new OleDbDataAdapter();
> this._Data = new DataTable();
> }
> }
>
>
>

Nov 15 '05 #8

Jazper

Hi Patrick

OK, got it! Finalize is responsible and not IDisposable... ok!
However i made a Finalize-Method. Also this Method will NOT be called when i
call GC.Collect().
the Finalize-Method only will be called when i leave the application
completely!

any idea what i'm still doing wrong?
thanx, jazper

"Patrick Philippot" <pa***************@mainsoft.xx> schrieb im Newsbeitrag
news:u%****************@tk2msftngp13.phx.gbl...

Jazper wrote:
i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to
test my Dispose-Method.... but when set a breakpoint in my
Dispose-Method and call the GC nothing happend!!! my Disposemethod
has never been called!! so the GC dont call my Dispose-Method
although I implemented IDisposable?

The GC calls Finalize, not Dispose. Never. Implementing IDisposable and
notifying the GC that you don't want Finalize to be called by the GC (by
calling GC.SuppressFinalize()) means that you adhere to the Dispose
pattern for your object's cleanup. That is, you decide that the object
cleanup is made explicitly by the object's client, which must call
Dispose itself. To make it short, you just say "The client is in charge
of triggering the object's cleanup ASAP instead of the GC". The GC will
still take care of freeing the object's memory, though. But since the
object's client has called Dispose, the object will be cleaned up long
before it is freed.

If you call GC.SuppressFinalize, your object will be "garbage collected"
faster.

Using the IDispose interface is just the recommended way of doing this.
But you could merely implement a Cleanup method and require that your
object's clients call this method when they're done with it. IDispose is
just that.

Implementing IDispose is done for objects consuming resources that must
be freed as soon as possible and for which waiting for the call made by
the GC to Finalize is too costly.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #9

Mr.Tickle

I dispose is just a method that you call, or you can call this .Close like
in File IO. but finalise is what the GC calls.
"Jazper" <j.***@bluewin.ch> wrote in message
news:eL**************@TK2MSFTNGP12.phx.gbl...

Hi Patrick

OK, got it! Finalize is responsible and not IDisposable... ok!
However i made a Finalize-Method. Also this Method will NOT be called when i call GC.Collect().
the Finalize-Method only will be called when i leave the application
completely!

any idea what i'm still doing wrong?
thanx, jazper

"Patrick Philippot" <pa***************@mainsoft.xx> schrieb im Newsbeitrag
news:u%****************@tk2msftngp13.phx.gbl...
Jazper wrote:
i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to
test my Dispose-Method.... but when set a breakpoint in my
Dispose-Method and call the GC nothing happend!!! my Disposemethod
has never been called!! so the GC dont call my Dispose-Method
although I implemented IDisposable?

The GC calls Finalize, not Dispose. Never. Implementing IDisposable and
notifying the GC that you don't want Finalize to be called by the GC (by
calling GC.SuppressFinalize()) means that you adhere to the Dispose
pattern for your object's cleanup. That is, you decide that the object
cleanup is made explicitly by the object's client, which must call
Dispose itself. To make it short, you just say "The client is in charge
of triggering the object's cleanup ASAP instead of the GC". The GC will
still take care of freeing the object's memory, though. But since the
object's client has called Dispose, the object will be cleaned up long
before it is freed.

If you call GC.SuppressFinalize, your object will be "garbage collected"
faster.

Using the IDispose interface is just the recommended way of doing this.
But you could merely implement a Cleanup method and require that your
object's clients call this method when they're done with it. IDispose is
just that.

Implementing IDispose is done for objects consuming resources that must
be freed as soon as possible and for which waiting for the call made by
the GC to Finalize is too costly.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #10

Patrick Philippot

Mr.Tickle wrote:

Its easy to predict the .NET GC.
No :-)
It will garbage collect when planets collide and Bush and Tony Blair
tells the truth

The .Net GC is a very sophisticated mechanism. You should read articles
about it. In the MSDN, for example. It will free memory as needed
without affecting performance like other GCs. The *only* problem with
it, is that you can't predict when an object will be garbage collected.
This is not an issue *unless* the object has to be cleaned up ASAP
because of the nature of the resources it consumes.

As we say in french, "you can't have both the butter and the money for
the butter". The GC frees you of the memory management chores but
there's a (small) price to pay for this: you must trust it. By the way,
you already trust another memory-related mechanism in Windows: the VMM.
You can't change much about its behavior but it does the job rather
well.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #11

Mr.Tickle

It was a joke :P
"Patrick Philippot" <pa***************@mainsoft.xx> wrote in message
news:#H**************@tk2msftngp13.phx.gbl...

Mr.Tickle wrote:
Its easy to predict the .NET GC.

No :-)
It will garbage collect when planets collide and Bush and Tony Blair
tells the truth

The .Net GC is a very sophisticated mechanism. You should read articles
about it. In the MSDN, for example. It will free memory as needed
without affecting performance like other GCs. The *only* problem with
it, is that you can't predict when an object will be garbage collected.
This is not an issue *unless* the object has to be cleaned up ASAP
because of the nature of the resources it consumes.

As we say in french, "you can't have both the butter and the money for
the butter". The GC frees you of the memory management chores but
there's a (small) price to pay for this: you must trust it. By the way,
you already trust another memory-related mechanism in Windows: the VMM.
You can't change much about its behavior but it does the job rather
well.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #12

Patrick Philippot

Jazper wrote:

However i made a Finalize-Method. Also this Method will NOT be called
when i call GC.Collect().

No. It's OK. Read about the internals of the GC. A first Collect just
queues the calls to the Finalize methods for the objects that are
candidate to garbage collection. Only later will the GC actually call
the Finalize method. Imagine that Finalize be called immediately when
object are garbage collected: this would affect performance heavily. It
's a good choice to separate the call to Finalize from the garbage
collection process itself.

So if you implement a Dispose method, you should not use Finalize. This
is useless because the cleanup will be made in Dispose anyway. Just call
GC.SuppresFinalize in Dispose as suggested.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #13

Patrick Philippot

Mr.Tickle wrote:

It was a joke :P

Yes, but also a good opportunity to comment about the GC :-)

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #14

Mattias Sjögren

Also this Method will NOT be called when i call GC.Collect().

Add a call to GC.WaitForPendingFinalizers() if you want to see it
happen earlier.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/
Please reply only to the newsgroup.

Nov 15 '05 #15

Jon Skeet [C# MVP]

Patrick Philippot <pa***************@mainsoft.xx> wrote:

So if you implement a Dispose method, you should not use Finalize. This
is useless because the cleanup will be made in Dispose anyway. Just call
GC.SuppresFinalize in Dispose as suggested.

It's only useless if Dispose is always called. Typically there's a
finalizer which just calls a version of Dispose.

See http://tinyurl.com/2k6e for Microsoft's recommended Dispose
implementation, including a finalizer.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Nov 15 '05 #16

William Ryan

Dude... I can politely point out a few things terribly wrong with your
argument...but I'll leave it alone. Suffice to say, I don't think you could
have gotten through ONE single book on the Framework without having an
answer to your question. BTW, Microsoft does implement C++ where you can
dispose of your objects in a deterministic manner, the non-deterministic
mechanism is by design and very very well designed at that.

As the saying goes, "The best way to make a monkey out of a man is to quote
him" see below.
"Jazper" <j.***@bluewin.ch> wrote in message
news:OW**************@TK2MSFTNGP11.phx.gbl...

hi Cybertof

OK, that's nice isn't it? in the meantime i'm familiar with issues like this for Microsoft Software... :-)
so my current problem is, that my memory rises whatever i do. I could
control the memory in C++ by destructor and delete. of course it was
complexer. but the fact is I COULD CONTROL IT. with CSharp i can't!! the
memory raises and raises and there is nothing I can do against it? what kind of Langugage and Framework should that be? why using a framework when the
GC does not its work??? typical Micro$oft!

the other possibility is that i use it the wrong way, so that it is not
working???
everytime when i create a new Form and Destroy it afterwards a few Bytes in my memory will not be freed. the effect is that the applications memory
rises from 27MB to nearly 40MB.

Anybody any idea how i get a grip on this?
thanks Jazper

"Cybertof" <cy****************@gmx.net> schrieb im Newsbeitrag
news:MP************************@msnews.microsoft.c om...
I have heard that it is not possible to predict when the real Garbage
Collection operation will occur, even when calling GC.Collect()...
But I don't know anymore about it for now.

A MVP comment on this subject would be appreciable :=)
Cybertof.
In article <e#**************@TK2MSFTNGP09.phx.gbl>, j.***@bluewin.ch
says...
hi

i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to
test
my Dispose-Method.... but when set a breakpoint in my Dispose-Method and call the GC nothing happend!!! my Disposemethod has never been called!! so the GC dont call my Dispose-Method although I implemented IDisposable?

what am i doing wrong?

Regards, Jazper

---Code ---------------------------------------------------------------
private void Test()
{
for(int i=0; i < 50000; i++)
{
CEmployee oEmployee = new CEmployee();
}
GC.Collect();
}

public class CEmployee : CRootItem, IDisposable
{
protected OleDbDataAdapter _Adapter;
protected DataTable _Data;

public void Dispose()
{
this._Adapter.Dispose(); //BRAKPOINT HERE!!
this._Data.Dispose();
}

public CEmployee()
{
this._Adapter = new OleDbDataAdapter();
this._Data = new DataTable();
}
}

Nov 15 '05 #17

Empire City

> have gotten through ONE single book on the Framework without having an

Forget about a book. It's like so spelled out in VS the help index. If you don't have access to it let me know and I'll be happy to spend 30 seconds on a cut and paste job.

Programming for Garbage Collection

The .NET Framework's garbage collector manages the allocation and release of memory for your application. Each time you use the new operator to create an object, the runtime allocates memory for the object from the managed heap. As long as address space is available in the managed heap, the runtime continues to allocate space for new objects. However, memory is not infinite. Eventually the garbage collector must perform a collection in order to free some memory. The garbage collector's optimizing engine determines the best time to perform a collection, based upon the allocations being made. When the garbage collector performs a collection, it checks for objects in the managed heap that are no longer being used by the application and performs the necessary operations to reclaim their memory.

This section describes how the garbage collector automatically manages the allocation and release of memory for the managed objects in your application. In addition, it describes the recommended design pattern to use to properly clean up any unmanaged resources that your application creates.

In This Section

Developer Backgrounds in Memory Management

Describes the adjustments developers, who have traditionally used Visual Basic, C++, and COM, should make when moving to managed code.

Finalize Methods and Destructors

Describes how Finalize methods and destructors allow an object to perform necessary cleanup operations before the garbage collector automatically reclaims the object's memory.

Cleaning Up Unmanaged Resources

Describes the recommended design pattern for cleaning up unmanaged resources. This section provides code examples for the following tasks:

Implementing a Dispose Method

Overriding the Finalize Method

Using C# and Managed Extensions for C++ Destructor Syntax

Forcing a Garbage Collection

Describes how and when to force the garbage collector to perform a collection.

Related Sections

GC Class

Provides methods for interacting with the system garbage collector.

Object.Finalize Method

Allows an object to attempt to free resources and perform other cleanup operations before the garbage collector reclaims the object.

IDisposable Interface

Provides the functionality for a resource class.

Garbage Collection Technology Sample

Introduces the functionality of the .NET Framework garbage collector.

Automatic Memory Management

See Also

Programming for Garbage Collection | GC Class | Garbage Collection Technology Sample | Managed Execution Process

Automatic memory management is one of the services that the common language runtime provides during Managed Execution. The common language runtime's garbage collector manages the allocation and release of memory for an application. For developers, this means that you do not have to write code to perform memory management tasks when you develop managed applications. Automatic memory management can eliminate common problems such as forgetting to free an object and causing a memory leak, or attempting to access memory for an object that has already been freed. This section describes how the garbage collector allocates and releases memory.

Allocating Memory

When you initialize a new process, the runtime reserves a contiguous region of address space for the process. This reserved address space is called the managed heap. The managed heap maintains a pointer to the address where the next object in the heap will be allocated. Initially, this pointer is set to the managed heap's base address. All reference types are allocated on the managed heap. When an application creates the first reference type, memory is allocated for the type at the base address of the managed heap. When the application creates the next object, the garbage collector allocates memory for it in the address space immediately following the first object. As long as address space is available, the garbage collector continues to allocate space for new objects in this manner.

Allocating memory from the managed heap is faster than unmanaged memory allocation. Because the runtime allocates memory for an object by adding a value to a pointer, it is almost as fast as allocating memory from the stack. In addition, because new objects that are allocated consecutively are stored contiguously in the managed heap, an application can access the objects very quickly.

Releasing Memory

The garbage collector's optimizing engine determines the best time to perform a collection based upon the allocations being made. When the garbage collector performs a collection, it releases the memory for objects that are no longer being used by the application. It determines which objects are no longer being used by examining the application's roots. Every application has a set of roots. Each root either refers to an object on the managed heap or is set to null. An application's roots include global and static object pointers, local variables and reference object parameters on a thread's stack, and CPU registers. The garbage collector has access to the list of active roots that the just-in-time (JIT) compiler and the runtime maintain. Using this list, it examines an application's roots, and in the process creates a graph that contains all the objects that are reachable from the roots.

Objects that are not in the graph are unreachable from the application's roots. The garbage collector considers unreachable objects garbage and will release the memory allocated for them. During a collection, the garbage collector examines the managed heap, looking for the blocks of address space occupied by unreachable objects. As it discovers each unreachable object, it uses a memory-copying function to compact the reachable objects in memory, freeing up the blocks of address spaces allocated to unreachable objects. Once the memory for the reachable objects has been compacted, the garbage collector makes the necessary pointer corrections so that the application's roots point to the objects in their new locations. It also positions the managed heap's pointer after the last reachable object. Note that memory is compacted only if a collection discovers a significant number of unreachable objects. If all the objects in the managed heap survive a collection, then there is no need for memory compaction.

To improve performance, the runtime allocates memory for large objects in a separate heap. The garbage collector automatically releases the memory for large objects. However, to avoid moving large objects in memory, this memory is not compacted.

Generations and Performance

To optimize the performance of the garbage collector, the managed heap is divided into three generations: 0, 1, and 2. The runtime's garbage collection algorithm is based on several generalizations that the computer software industry has discovered to be true by experimenting with garbage collection schemes. First, it is faster to compact the memory for a portion of the managed heap than for the entire managed heap. Secondly, newer objects will have shorter lifetimes and older objects will have longer lifetimes. Lastly, newer objects tend to be related to each other and accessed by the application around the same time.

The runtime's garbage collector stores new objects in generation 0. Objects created early in the application's lifetime that survive collections are promoted and stored in generations 1 and 2. The process of object promotion is described later in this topic. Since it is faster to compact a portion of the managed heap than the entire heap, this scheme allows the garbage collector to release the memory in a specific generation rather than release the memory for the entire managed heap each time it performs a collection.

In reality, the garbage collector performs a collection when generation 0 is full. If an application attempts to create a new object when generation 0 is full, the garbage collector discovers that there is no address space remaining in generation 0 to allocate for the object. The garbage collector performs a collection in an attempt to free address space in generation 0 for the object. The garbage collector starts by examining the objects in generation 0 rather than all the objects in the managed heap. This is the most efficient approach, because new objects tend to have short lifetimes and it is expected that many of the objects in generation 0 will no longer be in use by the application when a collection is performed. In addition, a collection of generation 0 alone often reclaims enough memory to allow the application to continue creating new objects.

After the garbage collector performs a collection of generation 0, it compacts the memory for the reachable objects as explained in Releasing Memory earlier in this topic. The garbage collector then promotes these objects and considers this portion of the managed heap generation 1. Because objects that survive collections tend to have longer lifetimes, it makes sense to promote them to a higher generation. As a result, the garbage collector does not have to reexamine the objects in generations 1 and 2 each time it performs a collection of generation 0.

After the garbage collector performs its first collection of generation 0, and promotes the reachable objects to generation 1, it considers the remainder of the managed heap generation 0. It continues to allocate memory for new objects in generation 0 until generation 0 is full and it is necessary to perform another collection. At this point, the garbage collector's optimizing engine determines whether it is necessary to examine the objects in older generations. For example, if a collection of generation 0 does not reclaim enough memory for the application to successfully complete its attempt to create a new object, the garbage collector can perform a collection of generation 1, then generation 0. If this does not reclaim enough memory, the garbage collector can perform a collection of generations 2, 1, and 0. After each collection, the garbage collector compacts the reachable objects in generation 0 and promotes them to generation 1. Objects in generation 1 that survive collections are promoted to generation 2. Because the garbage collector supports only three generations, objects in generation 2 that survive a collection remain in generation 2 until they are determined to be unreachable in a future collection.

Releasing Memory for Unmanaged Resources

For the majority of the objects that your application creates, you can rely on the garbage collector to automatically perform the necessary memory management tasks. However, unmanaged resources require explicit cleanup. The most common type of unmanaged resource is an object that wraps an operating system resource, such as a file handle, window handle, or network connection. Although the garbage collector is able to track the lifetime of a managed object that encapsulates an unmanaged resource, it does not have specific knowledge about how to clean up the resource. When you create an object that encapsulates an unmanaged resource, it is recommended that you provide the necessary code to clean up the unmanaged resource in a public Dispose method. By providing a Dispose method, you enable users of your object to explicitly free its memory when they are finished with the object. When you use an object that encapsulates an unmanaged resource, you should be aware of Dispose and call it as necessary. For more information about cleaning up unmanaged resources and an example of a design pattern for implementing Dispose, see Programming for Garbage Collection.

See Also

Nov 15 '05 #18

Empire City

Nov 15 '05 #19

Patrick Philippot

Jon Skeet [C# MVP] wrote:

It's only useless if Dispose is always called. Typically there's a
finalizer which just calls a version of Dispose.

See http://tinyurl.com/2k6e for Microsoft's recommended Dispose
implementation, including a finalizer.

Good point.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #20

Patrick Philippot

Mattias Sjögren wrote:

Also this Method will NOT be called when i call GC.Collect().

Add a call to GC.WaitForPendingFinalizers() if you want to see it
happen earlier.

The call sequence should actually be:

GC.Collect
GC.WaitForPendingFinalizers
GC.Collect

However, I'd like to emphasize that calling GC.Collect is *not* the
normal way of doing things. This method is here only to solve specific
problems. The code above will force finalization but will certainly not
help the application run faster.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #21

Jazper

Dude...

that may be true what you are saying. probably there also could be some
errors in my code or some miss-using of things... i don't know. however i my
point of view, it is a bit poor that you have to read a book first to know
how to use such a mechanism. and i doupt that it should be like this.

currently i just have this little problem, that my csharp-application is
allocating memory without releasing it... i think there must be some kind of
crossreference, so that the GC is thinking that this memory is still used.
Dotnet says that the programmer does not have to take care of releasing
memory anymore because of the GC. that was excactly what i did. don't get me
wrong... i like dotnet... i like this... however it did not work because my
mem. raises and raises.

reading books over books about something which i should not care of is some
kind of a waist of time.
i dont think that's the sense of a framework like this. the framework should
reduce your work and developping time. but also there it seems to raise.
:-)

"William Ryan" <do********@nospam.comcast.net> schrieb im Newsbeitrag
news:ue**************@TK2MSFTNGP09.phx.gbl...

Dude... I can politely point out a few things terribly wrong with your
argument...but I'll leave it alone. Suffice to say, I don't think you could have gotten through ONE single book on the Framework without having an
answer to your question. BTW, Microsoft does implement C++ where you can
dispose of your objects in a deterministic manner, the non-deterministic
mechanism is by design and very very well designed at that.

As the saying goes, "The best way to make a monkey out of a man is to quote him" see below.
"Jazper" <j.***@bluewin.ch> wrote in message
news:OW**************@TK2MSFTNGP11.phx.gbl...
hi Cybertof

OK, that's nice isn't it? in the meantime i'm familiar with issues like

this
for Microsoft Software... :-)
so my current problem is, that my memory rises whatever i do. I could
control the memory in C++ by destructor and delete. of course it was
complexer. but the fact is I COULD CONTROL IT. with CSharp i can't!! the
memory raises and raises and there is nothing I can do against it? what

kind
of Langugage and Framework should that be? why using a framework when the GC does not its work??? typical Micro$oft!

the other possibility is that i use it the wrong way, so that it is not
working???
everytime when i create a new Form and Destroy it afterwards a few Bytes

in
my memory will not be freed. the effect is that the applications memory
rises from 27MB to nearly 40MB.

Anybody any idea how i get a grip on this?
thanks Jazper

"Cybertof" <cy****************@gmx.net> schrieb im Newsbeitrag
news:MP************************@msnews.microsoft.c om...
I have heard that it is not possible to predict when the real Garbage
Collection operation will occur, even when calling GC.Collect()...
But I don't know anymore about it for now.

A MVP comment on this subject would be appreciable :=)
Cybertof.
In article <e#**************@TK2MSFTNGP09.phx.gbl>, j.***@bluewin.ch
says...
> hi
>
> i have this problem. i made a class deverted by CRootItem with
> implementation of IDisposable-Interface. i made a test-funktion to test
my
> Dispose-Method.... but when set a breakpoint in my Dispose-Method

and call
> the GC nothing happend!!! my Disposemethod has never been called!!
so the GC
> dont call my Dispose-Method although I implemented IDisposable?
>
> what am i doing wrong?
>
> Regards, Jazper
>

---Code ---------------------------------------------------------------
> private void Test()
> {
> for(int i=0; i < 50000; i++)
> {
> CEmployee oEmployee = new CEmployee();
> }
> GC.Collect();
> }
>
> public class CEmployee : CRootItem, IDisposable
> {
> protected OleDbDataAdapter _Adapter;
> protected DataTable _Data;
>
> public void Dispose()
> {
> this._Adapter.Dispose(); //BRAKPOINT HERE!!
> this._Data.Dispose();
> }
>
> public CEmployee()
> {
> this._Adapter = new OleDbDataAdapter();
> this._Data = new DataTable();
> }
> }
>
>
>

Nov 15 '05 #22

Jazper

thanks for the code. however that did not work.

my finalize-method ~CEmployee() will not be called after all. i think there
must be some kind of
crossreference, so that the GC is thinking that this memory is still used.

"Patrick Philippot" <pa***************@mainsoft.xx> schrieb im Newsbeitrag
news:eY**************@tk2msftngp13.phx.gbl...

Mattias Sjögren wrote:
Also this Method will NOT be called when i call GC.Collect().

Add a call to GC.WaitForPendingFinalizers() if you want to see it
happen earlier.

The call sequence should actually be:

GC.Collect
GC.WaitForPendingFinalizers
GC.Collect

However, I'd like to emphasize that calling GC.Collect is *not* the
normal way of doing things. This method is here only to solve specific
problems. The code above will force finalization but will certainly not
help the application run faster.

--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.xx
(replace .xx with .fr when replying by e-mail)

Nov 15 '05 #23

Empire City

Hi Jazper

my finalize-method ~CEmployee() will not be called after all. i think there crossreference, so that the GC is thinking that this memory is still used.

Maybe your destructor is being called but it's not caught by the debugger.
Try making it write to some text log file if that's possible, or maybe
display a message box and don't use the debugger. Also there must be some
good reasoning you can't directly implement a finalize method in C#, so you
are more or less trying to fight city hall here. I don't know if you can see
the help index but here are some items you could look up. There are a lot
more. If you need me to cut and paste the entire thing let me know.

Programming for Garbage Collection
Forcing a Garbage Collection
Finalize Methods and Destructors
Cleaning Up Unmanaged Resources

I agree it's not that much fun to read a book and I think you'll do better
with your testing by just using the help page examples. Just keep applying
standard data processing techniques. You know analyze, code, test, analyze,
code, test, analyze, code, test, etc. and yes analyze, code, test yet again
another time...... You'll figure it out if you have the time and desire.

Nov 15 '05 #24

Jonathan

GC doesn't call the Dispose method for you because the GC no nothing
about the IDisposable interface. It is your responsibility to call
..Dispose().

GC only know about your finalizer which is ~ClassName().

public MyClass :IDisposable
{
private boolean m_AlreadyDispose = false;

public MyClass() { }
public ~MyClass() { Dispose(); }

public void Dispose()
{
if(m_AlreadyDispose == false)
{
// free up resources.
GC.SupressFinalizer(this);
m_AlreadyDispose = true;
}
}
}

The implementation is roughly like this. To be more exact, check out MSDN.
Jazper wrote:

hi

i have this problem. i made a class deverted by CRootItem with
implementation of IDisposable-Interface. i made a test-funktion to test my
Dispose-Method.... but when set a breakpoint in my Dispose-Method and call
the GC nothing happend!!! my Disposemethod has never been called!! so the GC
dont call my Dispose-Method although I implemented IDisposable?

what am i doing wrong?

Regards, Jazper

---Code ---------------------------------------------------------------
private void Test()
{
for(int i=0; i < 50000; i++)
{
CEmployee oEmployee = new CEmployee();
}
GC.Collect();
}

public class CEmployee : CRootItem, IDisposable
{
protected OleDbDataAdapter _Adapter;
protected DataTable _Data;

public void Dispose()
{
this._Adapter.Dispose(); //BRAKPOINT HERE!!
this._Data.Dispose();
}

public CEmployee()
{
this._Adapter = new OleDbDataAdapter();
this._Data = new DataTable();
}
}

Nov 15 '05 #25

GC dont call my Dispose-Method although I implemented IDisposable

This discussion thread is closed

Similar topics