How to destroy arrays

[Jon Skeet [C# MVP]]

This is the message from Scott

<snip>

I notice you haven't answered my question.

Where Scott did write about the place it was eligible for the GC?

When the method falls out of scope, it does not always mean that an (in that
method created) object is collectable for the GC, however Scott did not
write that either.

No - but he did write "There are certain circumstances though, when you
may want the object in question to fall out of scope immediately,
rather than waiting for the end of a procedure."

To me, Scott was giving the impression that he believed that local
variables ensured that the objects they had references to were not
eligible for garbage collection until the end of a procedure. That is
not the case, as my reply said.

And that was for me already clear in the explanation from Scott. Why would
it be set to nothing at the end of the procedure (method)

I wasn't talking about setting variables to nothing at the end of the
method. I was talking about setting variables to nothing in the
*middle* of the method, which is pointless if the variable is not used
after that point in the method anyway. That was not clear from Scott's
message.

 

[Cor Ligthert]

Hi Jon,

I notice you haven't answered my question.

I do not know what question however when you mean about that setting to
nothing,

When I have this

dim a as integer
a = 1
a = 2
a = 3

Where do you think a is set to 2?

So why would that be different with = nothing.
When you know how the GC works than you should know what this means. (It is
not a magical thing you know)

And to repeat, Scott only said that things can be set to nothing automaticly
when the procedure goes out of scope (and than be disposed to the GC when
there is no reference at all anymore to it, which Scott did not write).

Cor

 

[Jon Skeet [C# MVP]]

I do not know what question

The one you quoted some of but didn't answer:

<quote (from my post)>
Having read only Scott's post, when would you believe Foo was
eligible for garbage collection in the Sub below?
</quote>

(with following code, of course).

Just to clarify my meaning, I was asking when you believe the array
which the Foo variable's value was a reference to would be eligible for
garbage collection.

however when you mean about that setting to
nothing,

When I have this

dim a as integer
a = 1
a = 2
a = 3

Where do you think a is set to 2?

So why would that be different with = nothing.

Because when a is an integer, the garbage collector isn't interested in
whether or not the variable is reachable. When a is an array reference,
it is.

So, in my example, because Foo is not used after
Console.WriteLine(Foo(0))
it isn't considered a "root" for garbage collection (in release mode -
in debug mode this optimisation isn't performed as the developer may
want to look at its value.

When you know how the GC works than you should know what this means. (It is
not a magical thing you know)

It's certainly not a magical thing - but I think it works somewhat
differently to how you imagine it does.

I recommend the GC section of Jeffrey Richter's "Applied Microsoft .NET
framework programming" book - it's truly excellent.

And to repeat, Scott only said that things can be set to nothing
automaticly when the procedure goes out of scope (and than be
disposed to the GC when there is no reference at all anymore to it,
which Scott did not write).

Actually, Scott didn't write that, fortunately - because it's not
true.Variables aren't "set to nothing automatically" - they're just not
considered to be roots by the garbage collector any more. What Scott
*did* imply (IMO) is that local variables were always considered to be
"roots" by the garbage collector until the end of the method. That's
not true.

 

[Niki Estner]

"Erase x" is just a fancy syntax for "x = nothing". And neither of the
articles says anything about the GC, so, I really don't know what you were
trying to say?

However, I think you still didn't get Jon's point:
Take the following example:
{
TestClass x = new TestClass();
x.DoSomething();
GC.Collect(); // <- this will actually collect "x", although it's not
set to null!
Thread.Sleep(100000);
}

If you run that code, the object "x" will get collected BEFORE the sleep,
although there is still a valid reference!
The GC can tell that "x" is not used any more although there is still a
valid reference to it. It can actually "look down your code" and see if you
still use a variable or not.
So, there it's rarely usefull setting a local variable to null/nothing.

Niki

 

[Cor Ligthert]

Hi Jon,

Just to clarify my meaning, I was asking when you believe the array
which the Foo variable's value was a reference to would be eligible for
garbage collection.

I thought you did know that?

Because when a is an integer, the garbage collector isn't interested in
whether or not the variable is reachable. When a is an array reference,
it is.

Did you not know that as well?

So, in my example, because Foo is not used after
Console.WriteLine(Foo(0))
it isn't considered a "root" for garbage collection (in release mode -
in debug mode this optimisation isn't performed as the developer may
want to look at its value.

Why should it not be, I thought I showed you that enough I hope I made it
clear now for you?

Because when a is an integer, the garbage collector isn't interested in
whether or not the variable is reachable. When a is an array reference,
it is.

Now I see you think that the = operater is for setting objects, no it is
ment to set something, that can be 1 2 3 or nothing, depended on the kind of
receiver it acts. And when a created object has no references anymore either
way, do not make a mistake in that, (it can be also that it is referenced
itself), than it is disposable (available) to the GC.

I recommend the GC section of Jeffrey Richter's "Applied Microsoft .NET
framework programming" book - it's truly excellent.

A very good link for this to look at is.
http://msdn.microsoft.com/architecture/default.aspx?pull=/library/en-us/dnpag/html/scalenet.asp
I do not agree some things in it, as by instance they write that every
control has to be disposed by hand and some other things, however for most
things it is very clear.

Actually, Scott didn't write that, fortunately - because it's not
true.Variables aren't "set to nothing automatically" - they're just not
considered to be roots by the garbage collector any more. What Scott
*did* imply (IMO) is that local variables were always considered to be
"roots" by the garbage collector until the end of the method. That's
not true.

That was the reason of my first message to you, why are you additing to
Scotts message. I nowhere readed that implyment of Scott it was only (YMO),
however had told that, than I would not have connected a message.

Cor

 

[Cor Ligthert]

Hi Niki,

I did deny nothing you wrote; however, Scott did nowhere write something
else in my opinion.

However rarely set to nothing is (IMO) overdone, I never make decisions for
someone else who has cases where it is well used.

Cor

 

[Jon Skeet [C# MVP]]

I thought you did know that?

I know when it's eligible for garbage collection. What I was asking was
when *you* believed it would be eligible for garbage collection, and
what you'd have thought just from Scott's article.

Did you not know that as well?

Yes, I knew that before. It wasn't clear that you did, however.

Why should it not be, I thought I showed you that enough I hope I made it
clear now for you?

Um, you haven't shed any light on garbage collection in this thread, as
far as I can see. What exactly do you think you've made clear, and
where?

Now I see you think that the = operater is for setting objects, no it is
ment to set something, that can be 1 2 3 or nothing, depended on the kind of
receiver it acts. And when a created object has no references anymore either
way, do not make a mistake in that, (it can be also that it is referenced
itself), than it is disposable (available) to the GC.

Not sure what you mean by "the kind of receiver it acts" but integers
themselves are never garbage collected. (Boxed versions are, of course,
but that's different.)

The = operator is for setting the value of a variable (or property),
either to a value type value or to a reference. Never to an actual
object. I think we agree on this, but I'm afraid I didn't understand
most of what you wrote above ("it can be also that it is referenced
itself" for instance)...

That was the reason of my first message to you, why are you additing to
Scotts message. I nowhere readed that implyment of Scott it was only (YMO),
however had told that, than I would not have connected a message.

Scott implied it when he specified the "rather than waiting for the end
of a procedure" in my opinion. If he'd said "rather than waiting for
the last use of the variable in the IL code" then I wouldn't have
written anything. He seemed to imply that there was something special
about the end of the procedure - otherwise why mention it?

 

[Niki Estner]

Hi Niki,

I did deny nothing you wrote; however, Scott did nowhere write something
else in my opinion.

Then you should probably read Scott's post.

However rarely set to nothing is (IMO) overdone,

Could you write that in an English sentence too?

I never make decisions for
someone else who has cases where it is well used.

Ok, this is really getting stupid:
The OP wanted to know how to free an array, so you can be damn sure that he
does not even know "where it is well used". That's why he asked a ng in the
first place.
So, the various posts (except yours) all included information on how arrays
(or objects in general) are freed.

That fact that you did not understand parts of that information does not
imply there is no information, you know...

Niki

 

[Cor Ligthert]

Hi Nikki,

Could you write that in an English sentence too?

Can you tell what it is wrong in it; I tried to understand your sentence and
gave an answer on it.

However there it's rarely usefull setting a local variable to null/nothing,

Cor

 

[Cor Ligthert]

Hi Jon,

Scott implied it when he specified the "rather than waiting for the end
of a procedure" in my opinion. If he'd said "rather than waiting for
the last use of the variable in the IL code" then I wouldn't have
written anything. He seemed to imply that there was something special
about the end of the procedure - otherwise why mention it?

Now I see what you do not understand, there is no need to force an array to
nothing when it is only used in a method. Then it goes automatically out of
scope as Scott stated. Only when you do not want to wait to the end of the
procedure, you have to set it to nothing. For me it was completely clear.
Sorry I did not understand that it was not for you.

I hope you have notified also my text about that this is as well only when
there are no references any more to that object.

Cor

 

[Jon Skeet [C# MVP]]

Now I see what you do not understand, there is no need to force an array to
nothing when it is only used in a method. Then it goes automatically out of
scope as Scott stated. Only when you do not want to wait to the end of the
procedure, you have to set it to nothing.

<sigh>

You still don't get it, do you? You don't have to set it to nothing
*even if you don't want to wait until the end of the method*.

The variable is no longer taken into consideration after its last use
(in release mode). This can be *long* before the end of the method.
*That's* the bit which wasn't in Scott's message, and which you *still*
don't seem to understand.

For me it was completely clear.
Sorry I did not understand that it was not for you.

It was clear to me what Scott meant - and that it was wrong, as shown
above.

I hope you have notified also my text about that this is as well only when
there are no references any more to that object.

Well it wasn't exactly new to me...

 

[Cor Ligthert]

Hi Jon,

*That's* the bit which wasn't in Scott's message, and which you *still*
don't seem to understand.

That was explicitly in Scott's message; otherwise, there was no need to
mention that it would be destroyed anyway at the end of the procedure.
However, he did that implicitly.

Cor

 

[Scott M.]

Usually that's unnecessary, however, as the garbage collector can tell
when a variable is last used in the IL. Unless you're in a particularly
special case (eg where a variable is used in the first iteration of a
long loop, and not thereafter) it's best not to clutter up your code
setting variables to null/Nothing.

I said basically the same thing Jon. Another circumstance would be if an
object had code in its Dispose method and by running that code sooner,
rather than later, you could free up other resources.

 

[Jon Skeet [C# MVP]]

That was explicitly in Scott's message; otherwise, there was no need to
mention that it would be destroyed anyway at the end of the procedure.
However, he did that implicitly.

No, he didn't. Niki doesn't either - it's not just my reading of it.
Scott's message implied "If you don't set the variable to Nothing, the
array won't be eligible for garbage collection until the end of the
procedure." That's the implication which isn't true.

 

[Jon Skeet [C# MVP]]

I said basically the same thing Jon.

Mostly, yes. What I was making clear was that a variable stops
interfering with garbage collection significantly *before* the end of
the method - whereas your post implied (IMO) that unless you set the
value to Nothing, it would continue to prevent the object in question
from being garbage collected until the end of the method. We certainly
agree that it's very rare that it's worth explicitly setting a variable
to Nothing.

Another circumstance would be if an
object had code in its Dispose method and by running that code sooner,
rather than later, you could free up other resources.

Yup, although that won't free memory (hence the "other" in your post, I
know - but many people unfortunately believe that calling Dispose
actually frees the memory).

 

[Jon Skeet [C# MVP]]

No, he didn't. Niki doesn't either - it's not just my reading of it.

Sorry - typo there. It should have been "Niki clear doesn't think so
either - it's not just my reading of it."

 

[C# Learner]

I said basically the same thing Jon.

I found that your statement could've easily been misunderstood as it was
somewhat vague, and that Jon's reply to it was fair and reasonable.

Even though my opinion wasn't asked for here, I posted it anyway because
it seems that someone else is trying to hammer Jon for his reply, which
I feel is unreasonable (and getting silly).

 

[Scott M.]

Jon,

First, you and Cor have been busy little bees on this....

Second, my original reply (OR) and the "certain circumstances" that I was
referring to have more to do with an object's Dispose() method firing and
not so much about that object's eligibility for garbage collection.

My understanding on this (and please correct me if I'm wrong) is that when
an object falls out of scope, it will fire off its Dispose() method (if it
has one). Then, when the object is actually about to be removed from memory
by the GC (which we can't say with any certainty if and when that happens),
the object's Finalize method will fire.

My understanding has been that while an object may be eligible for garbage
collection, if it hasn't fallen out of scope yet, then its Dispose method
might not have fired yet. By setting the object to Nothing before the end
of the procedure, you can get the Dispose method to fire sooner, rather than
later. This can be very useful when the object is holding some expensive
resource open or locked. So by getting Dispose to fire sooner, the
resources can be cleaned up sooner.

Is this not correct?

-Scott

Is there anything equivalent to Erase in C#?

There's an equivalent to what Erase *actually* does, which is just
setting the variable to null:

object[] foo = new object[100];
...

foo = null;

This is very rarely useful, as discussed elsewhere in the thread. (See
also http://blogs.msdn.com/csharpfaq/archive/2004/03/26/97229.aspx )

Of course, setting an instance or static variable to null is slightly
different - but for instance variables, I usually find that the array
is useful for exactly the same length of time as the object itself, so
again there's rarely a point in setting the variable to null.

Note that Erase doesn't automatically make an array eligible for
garbage collection - if there's another reference to the same array, it
can't be collected until that reference has changed (to null or to a
different array) or become eligible for garbage collection itself.

 

[Jon Skeet [C# MVP]]

First, you and Cor have been busy little bees on this....


Second, my original reply (OR) and the "certain circumstances" that I was
referring to have more to do with an object's Dispose() method firing and
not so much about that object's eligibility for garbage collection.

Ah, right. Read on...

My understanding on this (and please correct me if I'm wrong) is that when
an object falls out of scope, it will fire off its Dispose() method (if it
has one).

No, that's not true. Dispose is only called if *something* calls it -
it's not automatic in most situations.

Now, C# has the "using" statement which *does* automatically call
Dispose at the end of the block, but that's basically just syntactic
sugar. Most finalizers call Dispose themselves, of course.

Then, when the object is actually about to be removed from memory
by the GC (which we can't say with any certainty if and when that happens),
the object's Finalize method will fire.

Assuming it has one, and that GC.SuppressFinalize hasn't been called
for that object, yes.

My understanding has been that while an object may be eligible for garbage
collection, if it hasn't fallen out of scope yet, then its Dispose method
might not have fired yet. By setting the object to Nothing before the end
of the procedure, you can get the Dispose method to fire sooner, rather than
later. This can be very useful when the object is holding some expensive
resource open or locked. So by getting Dispose to fire sooner, the
resources can be cleaned up sooner.

Is this not correct?

Nope - see above. It's certainly a good idea to call Dispose as soon as
you're able to (though no sooner, of course!) but that needs to be done
explicitly.

 

[C# Learner]

Sorry - typo there. It should have been "Niki clear doesn't think so
either - it's not just my reading of it."

It seems that Cor may have misinterpreted Scott's post, as I, too, don't
think so.