Dispose then set to nothing

  • Thread starter Thread starter Guest
  • Start date Start date
Cor,
It is completely inside the method, if the dispose is not there it goes
out of scoop and will be disposed because the method ends.
Click to expand...
Yes it will eventually be disposed of. At the discretion of the GC. Which
may be in 2 milliseconds or 2 hours depending on GC pressure.

Calling Dispose directly (or indirectly via the Using statement) will ensure
that the object is disposed of immediately! Plus it may reduce GC pressure
as Disposable classes occasionally have a Finalizer. Dispose will commonly
call SuppressFinalize to avoid having the object wait in the Finalization
queue...

Hence the importance of using the Using statement...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
 
Clearing the reference will not shorten the time that the memory is in
use. It might in fact prolong the time slightly, if the clearing of the
reference would be considered the last use of the object instead of the
actual last use of the object. I don't know if the code analysis is
clever enough to distinguish between the different ways of using the
reference.
Click to expand...

Good point. It's one I hadn't originally considered. If the JIT
compiler doesn't optimize the line away and the GC isn't smart enough
to realize that it doesn't have side-effects then it would be worse
(though I can think worse things) than not having it there at all.
It's yet another reason to avoid doing it.
 
Jay,

What advantage is there on a common computer to call dispose immediately or
set things to nothing which will all be done if it is needed in the proper
time by Net.

In contrary, there is time spent to do that and it is in my idea a
disadvantage.

This seems for me always using programs in the way from far back in the past
century.

However on this I get often messages that you have to keep your desktop
cleaned up all the time. I have seen those guys often which at a moment did
nothing else until they were fired.

Cor

Jay B. Harlow said:
Cor,
It is completely inside the method, if the dispose is not there it goes
out of scoop and will be disposed because the method ends.
Click to expand...
Yes it will eventually be disposed of. At the discretion of the GC. Which
may be in 2 milliseconds or 2 hours depending on GC pressure.

Calling Dispose directly (or indirectly via the Using statement) will
ensure that the object is disposed of immediately! Plus it may reduce GC
pressure as Disposable classes occasionally have a Finalizer. Dispose will
commonly call SuppressFinalize to avoid having the object wait in the
Finalization queue...

Hence the importance of using the Using statement...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


Cor Ligthert said:
Brian,

It is completely inside the method, if the dispose is not there it goes
out of scoop and will be disposed because the method ends.

In my idea it is completely out of sense. (Not that I have the idea that
you have an opposite opinion).

Cor
Click to expand...
Click to expand...
 
Cor said:
Jay,

What advantage is there on a common computer to call dispose immediately or
set things to nothing which will all be done if it is needed in the proper
time by Net.
Click to expand...

I don't think that you fully understand how the disposable objects are
meant to work.

By always calling Dispose on object that implements IDisposable, you
make the memory management efficient.

If you call Dispose, it will remove the object from the finalizer queue,
turning it into an object that can be garbage collected as soon as there
are no references to it. This is very efficient, as all collected
objects in a heap generation is just left in it, and the entire heap
generation is recycled.

If you don't call Dispose, the garbage collector will not free the
object, but instead put it in the queue of objects to be finalized. A
background thread runs the finalizer of the objects in turn, and after
that the objects can be freed by the next garbage collection. As the
object fails the first collection, it will very likely need a move to
the next heap generation, which is done by copying the entire memory
area occupied by the object to the next heap generation.
 
Jay,

What advantage is there on a common computer to call dispose immediately or
set things to nothing which will all be done if it is needed in the proper
time by Net.

In contrary, there is time spent to do that and it is in my idea a
disadvantage.

This seems for me always using programs in the way from far back in the past
century.

However on this I get often messages that you have to keep your desktop
cleaned up all the time. I have seen those guys often which at a moment did
nothing else until they were fired.

Cor
Click to expand...

Cor,

In addition to what Goran said calling Dispose, or Close in some
cases, explicitly will release resources held by the object
immediately. This will prevent bugs like locked files held open by a
FileStream because the GC hasn't called Finalize yet.

Brian
 
Cor,

Cor Ligthert said:
What advantage is there on a common computer to call dispose immediately
or set things to nothing which will all be done if it is needed in the
proper time by Net.
Click to expand...

Imagine an unmanaged resource pool containing only a limited number of
resources of a certain type, such as connections, GDI handles, file handles,
.... By omitting the call to 'Dispose' the application may run out of these
unmanaged resources because they are still locked but not used any more.
 
Herfried,

Did I talk somewhere about resources. That effect I know, for the rest I see
two writers in this thread who mix completely up the finalizing with
disposing and have build their own mythe about that.

They think that using low memory has advantages. Probably they use a
computer with more than 2Gb computer while I am doing fine with my 512Kb
without all those things they are telling.

One of the advantage of Net is the automatic finalizing system at times that
the computer is Iddle.

But some are probably affected it so much that they need computers with more
memory to get some performance.

You know the article Jay wrote about all the discussions here, for sure is
there a big part from my ideas in that article.

Cor
 
Cor Ligthert said:
Did I talk somewhere about resources. That effect I know, for the rest I
see two writers in this thread who mix completely up the finalizing with
disposing and have build their own mythe about that.
Click to expand...

'IDisposable.Dispose' is all about releasing (unmanaged) resources. Well,
and I do not agree with Goran's advice because I believe this is a
micro-optimization. 'IDisposable.Dispose' is not intended as a mechanism to
support deterministic finalization.
They think that using low memory has advantages. Probably they use a
computer with more than 2Gb computer while I am doing fine with my 512Kb
without all those things they are telling.
Click to expand...

I agree. However, I think that 'IDisplosable.Dispose' may also be used with
managed resources such as very huge in-memory arrays which are stored inside
certain objects. Take an 1 GB array holding a dictionary in a certain
language, for example. When it's not used any more, it's IMO suitable to
implement 'IDisposable' and let 'Dispose' erase the array.
 
Herfried said:
'IDisposable.Dispose' is all about releasing (unmanaged) resources.
Well, and I do not agree with Goran's advice because I believe this is a
micro-optimization. 'IDisposable.Dispose' is not intended as a
mechanism to support deterministic finalization.
Click to expand...

What is your opinion that it's intended for, then?
I agree. However, I think that 'IDisplosable.Dispose' may also be used
with managed resources such as very huge in-memory arrays which are
stored inside certain objects. Take an 1 GB array holding a dictionary
in a certain language, for example. When it's not used any more, it's
IMO suitable to implement 'IDisposable' and let 'Dispose' erase the array.
Click to expand...

There is no reason to dereference managed resources. If an object
contains a large managed structure, just let the object go out of scope
and the entire structure that it contains is immediately eligible for
garbage collection.

Going through the work of dereferncing child objects is totally wasted,
as just letting go of the object does that for you automatically. It's
already built into the garbage collector, so there is no reason to make
another implementation of it in the class, especially as that
implementation always will be less effective.
 
Göran Andersson said:
What is your opinion that it's intended for, then?
Click to expand...

Releasing (primarily) unmanaged resources.
There is no reason to dereference managed resources. If an object contains
a large managed structure, just let the object go out of scope
Click to expand...

Well, that's not always possible. Imagine the object can still be reached
which prevents finalization by the garbage collector.
Going through the work of dereferncing child objects is totally wasted, as
just letting go of the object does that for you automatically.
Click to expand...

The GC cannot always do it automatically because it thinks the object is
still used (which it is, but it's actually not needed any more).
 
Herfried said:
Releasing (primarily) unmanaged resources.
Click to expand...

Yes, that is what you usually do when finalizing an object. As it's you
who trigger the process, and not the garbage collector, makes it
deterministic.
Well, that's not always possible. Imagine the object can still be
reached which prevents finalization by the garbage collector.
Click to expand...

Yes, if you are going to hold on to the object long after it's unusable,
then of course it won't work that way, but why would you do that? Just
remove the reference to the object, and it all goes away.
The GC cannot always do it automatically because it thinks the object is
still used (which it is, but it's actually not needed any more).
Click to expand...

Yes, it can always do that automatically.
 
Göran Andersson said:
Yes, that is what you usually do when finalizing an object. As it's you
who trigger the process, and not the garbage collector, makes it
deterministic.
Click to expand...

That's true. However, using 'IDisposable' makes perfect sense because the
unmanaged resources are not under the control of the GC and may be limited.
Yes, if you are going to hold on to the object long after it's unusable,
then of course it won't work that way, but why would you do that?
Click to expand...

Maybe it's not done in the code I have written. Normally I do not keep
track where objects are referenced because this would make maintenance and
extension of code more complicated.
Just remove the reference to the object, and it all goes away.
Click to expand...

As I said, that's not always possible.
Yes, it can always do that automatically.
Click to expand...

Only if the object cannot be reached by the program any more, which may
require removal of references a certain piece of code is not aware of.
 
As I said, that's not always possible.
Click to expand...

I think you guys must be thinking the same thing just saying it
differently.

I think what Goran is saying that it *is* that simple to just stop
referencing an object. Set a variable to Nothing, remove the object
from a Hashtable, ignore the return value of a function, etc. And I
agree with that.

I think what Herfried is saying is that there are rare scenarios where
an a newly created object referenced by a local variable will not be
eligible for collection when the variable goes out of scope and even
if you made absolutely sure that you didn't pass that reference to
another method. This can happen when the object registers itself in a
shared field without the caller's knowledge. Consider this example.

Public Sub DoSomething
Dim a As MyBigObject = New MyBigObject()
End Sub

Even in this simplistic example there's no guarentee that the object
referenced by 'a' will be eligible for collection...ever! Maybe the
class' constructor puts a reference to itself in a static field
internally. And maybe Dispose would be a good place to put code to
dereference the object or place a call to . Personally, I think this
would be better handled by a WeakReference, but I do see what Herfried
is trying to say.

Brian
 
An object will be finalized as it has itself no reference or as it has no
reference to it.

Image this

private ar as new arraylist
private sub mysub
Dim a as MyDisposableClass
ar.add(a)
a.dispose
a = nothing
end sub

a will exist as long as that it is not removed from the arraylist

Cor
 
Cor,

Cor Ligthert said:
An object will be finalized as it has itself no reference or as it has no
reference to it.

Image this

private ar as new arraylist
private sub mysub
Dim a as MyDisposableClass
ar.add(a)
a.dispose
a = nothing
end sub

a will exist as long as that it is not removed from the arraylist
Click to expand...

Yes, as long as the arraylist can be reached.

Your sample is basically showing what I am describing. Sure there are
solutions using weak references, but I like the 'IDisposable' solution more
in certain cases because it works pretty well.
 
Back
Top