A
Abdolhosein Vakilzadeh Ebrahimi
Hi:
Anybody knows about object life cycle in CSharp?
Any online articles?
Please let me have.
Thanks
Anybody knows about object life cycle in CSharp?
Any online articles?
Please let me have.
Thanks
F
Frank Drebin
What are you looking for specifically??
A
Andre
Look for something on Garbage collection in the MSDN online library and
you'll find just what you're looking for.
cheers
-Andre
you'll find just what you're looking for.
cheers
-Andre
F
Fergus Cooney
Hi Abdolhosein,
In a nutshell -
An object exists and is alive and usable as soon as it is created and
for as long as there's something holding a reference to it.
When all references have been set to null, the object still exists in
memory but is NOT alive and usable. It is awaiting garbage collection.
If two objects reference each other and nothing else does, the pair will
exist and be alive but NOT usable. They will wait together for the program
to terminate. Similarly with any closed group of mutually-referencing
objects.
A freed object will continue to occupy memory until it is removed by the
garbage collector (GC) - which will happen when the GC gets around to it.
This is not guaranteed and the program may terminate before the object is
freed.
At termination, objects aren't freed per se, but the system will reclaim
all the program's memory anyway, so there's no problem.
The main consideration is when an object holds references to unmanaged
resources, eg Windows handles, bitmaps, etc. These MUST be freed (the
reference set to null) when the object has been finished with, and before it
is released. The GC doesn't know about these resources (which is partly why
they are unmanaged!).
Hope that's useful.
Regards,
Fergus.
In a nutshell -
An object exists and is alive and usable as soon as it is created and
for as long as there's something holding a reference to it.
When all references have been set to null, the object still exists in
memory but is NOT alive and usable. It is awaiting garbage collection.
If two objects reference each other and nothing else does, the pair will
exist and be alive but NOT usable. They will wait together for the program
to terminate. Similarly with any closed group of mutually-referencing
objects.
A freed object will continue to occupy memory until it is removed by the
garbage collector (GC) - which will happen when the GC gets around to it.
This is not guaranteed and the program may terminate before the object is
freed.
At termination, objects aren't freed per se, but the system will reclaim
all the program's memory anyway, so there's no problem.
The main consideration is when an object holds references to unmanaged
resources, eg Windows handles, bitmaps, etc. These MUST be freed (the
reference set to null) when the object has been finished with, and before it
is released. The GC doesn't know about these resources (which is partly why
they are unmanaged!).
Hope that's useful.
Regards,
Fergus.
R
Ron McNulty
Hi Fergus
objects.
Are you sure of this? A good garbage collector should detect this and nuke
the pair. If you are correct, I need to fix some of my code
I'm pretty sure the Java GC does this - it was improved sustantially in
V1.3. Programs that consumed memory in v1.2 no longer had a problem in v1.3.
I assumed it was because the garbage collector had become more intelligent.
Regards
Ron
objects.
Are you sure of this? A good garbage collector should detect this and nuke
the pair. If you are correct, I need to fix some of my code
I'm pretty sure the Java GC does this - it was improved sustantially in
V1.3. Programs that consumed memory in v1.2 no longer had a problem in v1.3.
I assumed it was because the garbage collector had become more intelligent.
Regards
Ron
W
Willy Denoyette [MVP]
See inline ****
Fergus Cooney wrote:
|| If two objects reference each other and nothing else does, the
|| pair will exist and be alive but NOT usable. They will wait together
|| for the program to terminate. Similarly with any closed group of
|| mutually-referencing objects.
||
**** This is totally wrong, if the pair has lost it's root it will be collected at the first GC run (or the second when there are
pending finalizers).
|| A freed object will continue to occupy memory until it is
|| removed by the garbage collector (GC) - which will happen when the
|| GC gets around to it. This is not guaranteed and the program may
|| terminate before the object is freed.
**** What do you mean here with "a freed" object?
||
|| At termination, objects aren't freed per se, but the system will
|| reclaim all the program's memory anyway, so there's no problem.
||
|| The main consideration is when an object holds references to
|| unmanaged resources, eg Windows handles, bitmaps, etc. These MUST be
|| freed (the reference set to null) when the object has been finished
**** Releasing unmanaged resources is somewhat more complicated than simply setting a reference to null.
Willy.
Fergus Cooney wrote:
|| If two objects reference each other and nothing else does, the
|| pair will exist and be alive but NOT usable. They will wait together
|| for the program to terminate. Similarly with any closed group of
|| mutually-referencing objects.
||
**** This is totally wrong, if the pair has lost it's root it will be collected at the first GC run (or the second when there are
pending finalizers).
|| A freed object will continue to occupy memory until it is
|| removed by the garbage collector (GC) - which will happen when the
|| GC gets around to it. This is not guaranteed and the program may
|| terminate before the object is freed.
**** What do you mean here with "a freed" object?
||
|| At termination, objects aren't freed per se, but the system will
|| reclaim all the program's memory anyway, so there's no problem.
||
|| The main consideration is when an object holds references to
|| unmanaged resources, eg Windows handles, bitmaps, etc. These MUST be
|| freed (the reference set to null) when the object has been finished
**** Releasing unmanaged resources is somewhat more complicated than simply setting a reference to null.
Willy.
F
Fergus Cooney
Hi Ron,
Thanks for your question.
No, I'm not certain. This was my understanding when I first learned
about it - way back. If things have changed since then, that's great.
If you're dumping "closed-loop" object groups, I reckon you should "fix"
your code anyway - it'll raise the "pride level" if nothing else?.
Regards,
Fergus
Thanks for your question.
No, I'm not certain. This was my understanding when I first learned
about it - way back. If things have changed since then, that's great.
If you're dumping "closed-loop" object groups, I reckon you should "fix"
your code anyway - it'll raise the "pride level" if nothing else?
.Regards,
Fergus
J
Jay B. Harlow [MVP - Outlook]
Abdolhosein Vakilzadeh Ebrahimi,
If by 'object life cycle', your asking how the Garbage collector works, see
the following two articles:
http://msdn.microsoft.com/msdnmag/issues/1100/gci/
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/
Hope this helps
Jay
If by 'object life cycle', your asking how the Garbage collector works, see
the following two articles:
http://msdn.microsoft.com/msdnmag/issues/1100/gci/
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/
Hope this helps
Jay
F
Fergus Cooney
Hi Willy,
I said (shortened)
|| If two objects reference each other and nothing else does,
the
|| pair will wait together for the program to terminate.
Ron asked me if I'm sure. No. I was when I first learned this stuff. If
it's now wrong - great, we have a better GC. I prefer to write my code
as if the GC is dumb in this respect - it feels cleaner.
You asked what I meant by "freed". I'm talking about managed objects and
mean that they are unreferenced. I'm not talking about system resources,
memory, etc.
You said
|| Releasing unmanaged resources is somewhat more complicated than
simply setting a reference to null.
My post starts with the line:
|| In a nutshell -
The post is introductory and intended to be read as a list of bullets -
not full-on explanations. However, it would have been better if I'd implied
that there's more to it.
The article that Michael mentioned,
http://msdn.microsoft.com/msdnmag/issues/1100/gci/, written by Jeffrey
Richter, is excellent and goes into lots of detail about garbage collection,
especially Finalization, - but suprisingly little about your point
(unmanaged resources). I think you should do a short post to explain further
and give examples, Willy. Go for it. ;-)
Regards,
Fergus
ps. In part 2 of the article there's a link to Figure 1 which uses
JavaScript. It failed on my machine. If it fails for you too, the full link
is http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/figures.asp.
I said (shortened)
|| If two objects reference each other and nothing else does,
the
|| pair will wait together for the program to terminate.
Ron asked me if I'm sure. No. I was when I first learned this stuff. If
it's now wrong - great, we have a better GC. I prefer to write my code
as if the GC is dumb in this respect - it feels cleaner.
You asked what I meant by "freed". I'm talking about managed objects and
mean that they are unreferenced. I'm not talking about system resources,
memory, etc.
You said
|| Releasing unmanaged resources is somewhat more complicated than
simply setting a reference to null.
My post starts with the line:
|| In a nutshell -
The post is introductory and intended to be read as a list of bullets -
not full-on explanations. However, it would have been better if I'd implied
that there's more to it.
The article that Michael mentioned,
http://msdn.microsoft.com/msdnmag/issues/1100/gci/, written by Jeffrey
Richter, is excellent and goes into lots of detail about garbage collection,
especially Finalization, - but suprisingly little about your point
(unmanaged resources). I think you should do a short post to explain further
and give examples, Willy. Go for it. ;-)
Regards,
Fergus
ps. In part 2 of the article there's a link to Figure 1 which uses
JavaScript. It failed on my machine. If it fails for you too, the full link
is http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/figures.asp.