GC and Dispose

  • Thread starter Thread starter Jack Wright
  • Start date Start date
J

Jack Wright

Dear All,
I have read a few articles on how to dispose objects...but would like
to know more about objects that are given by the FW...
How do I dispose them?
How can I call GC explicitly and make it collect the objects?
Is calling GC efficient?

f.e.x
How do I dispose a hashtable that contains objects?
Will it suffice if it set it to null? Will the GC dispose all the
objects that the hashtable was holding? (Provided these objects are not
being accessed by any other object)
How do I dipose a streamreader?
Is it Ok to call streamreader.close()? or setting it to NULL...

Please help...

Many Regards
Jack
 
Jack Wright said:
Dear All,
I have read a few articles on how to dispose objects...but would like
to know more about objects that are given by the FW...
How do I dispose them?

You call Dispose.
How can I call GC explicitly and make it collect the objects?

Use GC.Collect.
Is calling GC efficient?
No.

f.e.x
How do I dispose a hashtable that contains objects?

You don't dispose of the object - the GC will clean it up when it needs
to.
Will it suffice if it set it to null?

You can't set an object to null, only a variable. It's *very* important
to understand the difference between the two. In my experience, you
rarely need to set a variable to null to help the GC in well-designed
applications.
Will the GC dispose all the
objects that the hashtable was holding? (Provided these objects are not
being accessed by any other object)

Well, if by "being accessed" you mean "there is a reference to the
object" then yes.
How do I dipose a streamreader?

You call Dispose on it.
Is it Ok to call streamreader.close()? or setting it to NULL...

There's no finalizer for StreamReader, so when it's garbage collected,
nothing extra happens. If you call Dispose or Close, the underlying
stream is also closed/disposed.
 
Although technically correct that you can trigger a GC with GC.Collect() ? don?t do it?. Except in a tiny number of circumstances all you will do by trying to second guess the CLR is slow your application down with unnecessary collections. The runtime has a much more global view of your application than any particular method that happens to be running.

Regards

Richard Blewett ? DevelopMentor
http://staff.develop.com/richardb/weblog

nntp://news.microsoft.com/microsoft.public.dotnet.framework/
Jack said:
Dear All,
I have read a few articles on how to dispose objects...but would like
to know more about objects that are given by the FW...
How do I dispose them?

You call Dispose.
How can I call GC explicitly and make it collect the objects?

Use GC.Collect.
Is calling GC efficient?
No.

f.e.x
How do I dispose a hashtable that contains objects?

You don't dispose of the object - the GC will clean it up when it needs to.
Will it suffice if it set it to null?

You can't set an object to null, only a variable. It's *very* important to understand the difference between the two. In my experience, you rarely need to set a variable to null to help the GC in well-designed applications.
Will the GC dispose all the
objects that the hashtable was holding? (Provided these objects are
not being accessed by any other object)

Well, if by "being accessed" you mean "there is a reference to the object" then yes.
How do I dipose a streamreader?

You call Dispose on it.
Is it Ok to call streamreader.close()? or setting it to NULL...

There's no finalizer for StreamReader, so when it's garbage collected, nothing extra happens. If you call Dispose or Close, the underlying stream is also closed/disposed.

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

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.760 / Virus Database: 509 - Release Date: 10/09/2004

[microsoft.public.dotnet.framework]
 
Dear Jon,
How do I dispose a hashtable that contains objects?needs to.

But GC causes performance problems? Wouldn't it be nice that if I know
that I don't need an Object, I dispose it myself rather than expecting a
GC trigger?

Thanks & Regards
Jack
 
Jack Wright said:
How do I dispose a hashtable that contains objects?
needs to.

But GC causes performance problems? Wouldn't it be nice that if I know
that I don't need an Object, I dispose it myself rather than expecting a
GC trigger?

No - because it's cheaper for the garbage collector to clean up
hundreds of objects at a time than it is for it to clean up each of
those objects when you're done with them.

The way the memory allocation system works, in order to actually
benefit from "cleaning up" an object, there *must* be a garbage
collection.
 
Dear Jon,
Thanks for answering my (stupid) queries...I have one more...
Does MS expect us to derived all our classes from the IDisposable
interface?
What is a managed resource?
Is public string myName = "Jack"; a managed resource?

What is unmanaged resource? Are only handles unmanaged resources?

If the following code is executed GC will never dispose this Object. Is
this right?
// This object will be cleaned up by the Dispose method.
// Therefore, you should call GC.SupressFinalize to
// take this object off the finalization queue
// and prevent finalization code for this object
// from executing a second time.
GC.SuppressFinalize(this);

Thanks & Regards
Jack
 
Jack Wright said:
Thanks for answering my (stupid) queries...I have one more...
Does MS expect us to derived all our classes from the IDisposable
interface?
No.

What is a managed resource?

Good question. It's a little hazy. For instance, is Stream a managed
resource? Yes, but it embeds an unmanaged resource - so you still want
to dispose of it early. That means if your class contains a stream, you
should probably implement IDisposable too. The majority of the time,
well-designed classes won't hold onto unmanaged resources (directly or
by proxy) as member variables. When they do, if the resource is held by
proxy (i.e. your class contains a member variable of a type which
implements IDisposable) you only need to implement IDisposable - you
don't need a finalizer. You only usually need a finalizer if you
directly have an unmanaged resource in your class, which is very rare
IME.
Is public string myName = "Jack"; a managed resource?
Yes.

What is unmanaged resource? Are only handles unmanaged resources?

Not quite. A piece of memory the GC doesn't know about (because it's
allocated by native code) is an unmanaged resource, too. There are
doubtless other examples. For the most part, you don't need to worry.
If the following code is executed GC will never dispose this Object. Is
this right?
// This object will be cleaned up by the Dispose method.
// Therefore, you should call GC.SupressFinalize to
// take this object off the finalization queue
// and prevent finalization code for this object
// from executing a second time.
GC.SuppressFinalize(this);

That just means that the GC won't call Finalize itself. You can still
dispose of it manually, and the memory will still be cleaned up - it's
just that the finalizer which would have (presumably) released the
unmanaged resource won't get called.
 
Back
Top