By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,142 Members | 1,918 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,142 IT Pros & Developers. It's quick & easy.

Array.Resize question

P: n/a
I have an array of objects. When I use Array.Resize<T>(ref Object,int
Newsize); and the newsize is smaller then what the array was
previously, are the resources allocated to the objects that are now
thown out of the array released properly by the CLI?

Sep 7 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Yes.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

"heddy" <he*******@gmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...
>I have an array of objects. When I use Array.Resize<T>(ref Object,int
Newsize); and the newsize is smaller then what the array was
previously, are the resources allocated to the objects that are now
thown out of the array released properly by the CLI?

Sep 7 '06 #2

P: n/a
Thanks, Kevin. I guess coming form a C/C++ background I tend to still
worry about memory management heh.

Sep 7 '06 #3

P: n/a
"Kevin Spencer" <uc*@ftc.govwrote in message
news:eJ**************@TK2MSFTNGP05.phx.gbl...
Yes.
Actually -- no. The objects will no longer be reachable through the array.
Only if there are no other references to those objects, will they be garbage
collected, and then only when you run low on memory. To free resources, you
still have to call Dispose() by hand on each object.

>
--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

"heddy" <he*******@gmail.comwrote in message
news:11*********************@b28g2000cwb.googlegro ups.com...
>>I have an array of objects. When I use Array.Resize<T>(ref Object,int
Newsize); and the newsize is smaller then what the array was
previously, are the resources allocated to the objects that are now
thown out of the array released properly by the CLI?


Sep 7 '06 #4

P: n/a
Actually -- no. The objects will no longer be reachable through the
array. Only if there are no other references to those objects, will they
be garbage collected, and then only when you run low on memory. To free
resources, you still have to call Dispose() by hand on each object.
Incorrect. First, the question was, "are the resources allocated to the
objects that are now thown out of the array released properly by the CLI?"
The answer is, "yes." They are "released properly by the CLI."

There are 2 distinct errors in your answer. First, your assertion that
Garbage Collection only occurs when the system is low on memory. This is not
true. Low memory is only one of several criteria used to determine when
Garbage Collection occurs. Here is a good article that explains the process:

http://www.csharphelp.com/archives2/archive297.html

The second errror is the statement "To free resources, you still have to
call Dispose() by hand on each object." First, most .Net classes do NOT
implement IDisposable, meaning, they do not HAVE a Dispose() method.
Apparently, they do not all need a Dispose() method. In fact, IDisposable is
an interface implemented for managed classes that use unmanaged resources,
or that use a lot of managed resources, and would benefit from quick Garbage
Collection. It is not implemented for most classes because .Net Garbage
Collection handles memory allocation quite well by itself in most cases.

I have written large-scale applications that allocate dozens of megabytes of
RAM at a time, and they manage memory perfectly.

As for arrays, an array can be an array of anything. So, the idea that
creating a new instance of an array (which is what resizing does) is going
to necessitate Garbage Collection is simply mistaken. An array of integers,
for example, will not need any Garbage Collection, because integers are
value types. With an array of objects, yes, if there is a reference to an
object (in the array) in the running app, that object will not be
Garbage-Collected until that reference is removed. But on the other hand, if
you are still referencing an object, you don't WANT it to be
Garbage-Collected; you are still using it.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:eg**************@TK2MSFTNGP04.phx.gbl...
"Kevin Spencer" <uc*@ftc.govwrote in message
news:eJ**************@TK2MSFTNGP05.phx.gbl...
>Yes.

Actually -- no. The objects will no longer be reachable through the
array. Only if there are no other references to those objects, will they
be garbage collected, and then only when you run low on memory. To free
resources, you still have to call Dispose() by hand on each object.

>>
--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

"heddy" <he*******@gmail.comwrote in message
news:11*********************@b28g2000cwb.googlegr oups.com...
>>>I have an array of objects. When I use Array.Resize<T>(ref Object,int
Newsize); and the newsize is smaller then what the array was
previously, are the resources allocated to the objects that are now
thown out of the array released properly by the CLI?



Sep 8 '06 #5

P: n/a
"Kevin Spencer" <uc*@ftc.govwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...
>Actually -- no. The objects will no longer be reachable through the
array. Only if there are no other references to those objects, will they
be garbage collected, and then only when you run low on memory. To free
resources, you still have to call Dispose() by hand on each object.

Incorrect. First, the question was, "are the resources allocated to the
objects that are now thown out of the array released properly by the CLI?"
The answer is, "yes." They are "released properly by the CLI."

There are 2 distinct errors in your answer. First, your assertion that
Garbage Collection only occurs when the system is low on memory. This is
not true. Low memory is only one of several criteria used to determine
when Garbage Collection occurs. Here is a good article that explains the
process:

http://www.csharphelp.com/archives2/archive297.html
A very nice discussion of what GC does when it runs, but I didn't see
anything about what triggers it. If you're running GC for any reason other
than low memory (i.e. calling GC.Collect()), something is wrong.
>
The second errror is the statement "To free resources, you still have to
call Dispose() by hand on each object." First, most .Net classes do NOT
implement IDisposable, meaning, they do not HAVE a Dispose() method.
Apparently, they do not all need a Dispose() method. In fact, IDisposable
is an interface implemented for managed classes that use unmanaged
resources, or that use a lot of managed resources, and would benefit from
quick Garbage Collection. It is not implemented for most classes because
.Net Garbage Collection handles memory allocation quite well by itself in
most cases.
So yes, you admit that Dispose() is necessary for freeing any resources
other than memory (and often memory as well, if it's allocated outside the
CLR). Usually, the word resources is used to refer to exactly the things
Dispose() is needed for, if one meant "only memory" one would say memory
rather than resources. It is clearly important to the OP based on his
wording that someone tell him that Array.Resize() won't free unmanaged
resources.
>
I have written large-scale applications that allocate dozens of megabytes
of RAM at a time, and they manage memory perfectly.

As for arrays, an array can be an array of anything. So, the idea that
creating a new instance of an array (which is what resizing does) is going
to necessitate Garbage Collection is simply mistaken. An array of
integers, for example, will not need any Garbage Collection, because
integers are value types. With an array of objects, yes, if there is a
reference to an object (in the array) in the running app, that object will
not be Garbage-Collected until that reference is removed. But on the other
hand, if you are still referencing an object, you don't WANT it to be
Garbage-Collected; you are still using it.
The OP spoke specifically of an array of objects, not structs. But in any
case when the array is resized, the old storage for the array must be freed.
The storage for the array proper is GC-tracked. For arrays of int or any
other value type, it's the only GC handle. It can be quite large and it
must be garbage collected.
>
--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:eg**************@TK2MSFTNGP04.phx.gbl...
>"Kevin Spencer" <uc*@ftc.govwrote in message
news:eJ**************@TK2MSFTNGP05.phx.gbl...
>>Yes.

Actually -- no. The objects will no longer be reachable through the
array. Only if there are no other references to those objects, will they
be garbage collected, and then only when you run low on memory. To free
resources, you still have to call Dispose() by hand on each object.

>>>
--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

"heddy" <he*******@gmail.comwrote in message
news:11*********************@b28g2000cwb.googleg roups.com...
I have an array of objects. When I use Array.Resize<T>(ref Object,int
Newsize); and the newsize is smaller then what the array was
previously, are the resources allocated to the objects that are now
thown out of the array released properly by the CLI?



Sep 8 '06 #6

P: n/a
A very nice discussion of what GC does when it runs, but I didn't see
anything about what triggers it. If you're running GC for any reason
other than low memory (i.e. calling GC.Collect()), something is wrong.
You must have overlooked the following (from the article I referenced):

"The garbage collector's optimizing engine determines the best time to
perform a collection, (the exact criteria is guarded by Microsoft) based
upon the allocations being made."

In other words, *you* don't run GC; it runs itself. A developer should
almost never have to do (and should almost never do) any manual Garbage
Collection.
So yes, you admit that Dispose() is necessary for freeing any resources
other than memory (and often memory as well, if it's allocated outside the
CLR). Usually, the word resources is used to refer to exactly the things
Dispose() is needed for, if one meant "only memory" one would say memory
rather than resources. It is clearly important to the OP based on his
wording that someone tell him that Array.Resize() won't free unmanaged
resources.
Not exactly. *Classes which implement IDisposable* should be Disposed.
Others should (and can) not. As far as the OP is concerned, resizing arrays
is exactly the same as any other operation that de-references any objects,
no more, and no less. Exiting a function that declares an instance of an
object does the same thing, since the scope of the object is the function,
which is placed on the stack and then removed from it. In other words, there
is nothing special about resizing arrays compared to other operations that
de-reference class instances.

The word "resources" is clearly defined. It refers to "A facility of a
computing system needed in order to perform an operation or task.Resources
include memory, storage, input/output units, processing units, data sets,
files, and programs." However, the most common resource used by any program
is memory, and the most common issue with regards to freeing up resources is
memory allocation/deallocation. The OP's question was specifically about
array reallocation, and the *vast* majority of classes in the CLR do not
implement IDisposable; therefore, they do not need to be disposed. The chief
purpose of Garbage Collection is memory management. Therefore, that is the
context in which I answered the question.
The OP spoke specifically of an array of objects, not structs. But in any
case when the array is resized, the old storage for the array must be
freed. The storage for the array proper is GC-tracked. For arrays of int
or any other value type, it's the only GC handle. It can be quite large
and it must be garbage collected.
Everything in .Net is an object. And I didn't mention anything about
structs. I did mention integers, and integers are objects. They are value
types, but they are objects nonetheless. In fact, a struct is an object,
because it is a value type.

At any rate, my first reply to you was in response to your assertion that my
first reply to the OP was incorrect, but in fact contained incorrect
information in itself, and would be therefore confusing to the OP:
Actually -- no. The objects will no longer be reachable through the
array. Only if there are no other references to those objects, will they
be garbage collected, and then only when you run low on memory.
The statement that Garbage Collection occurs only when memory is low is
false.
To free resources, you still have to call Dispose() by hand on each
object.
The blanket statement that "to free resources, you still have to call
Dispose() by hand on each object" is false as well. If this were the case,
all classes would implement IDisposable, and Garbage Collection would be of
no use. Since, as I mentioned, the vast majority of classes do not implement
IDisposable, the instances where Dispose must be called on de-referenced
classes are few and far between, and the subject of IDisposable is an
entirely different (and very specific) subject than the subject of whether
memory needs to be de-allocated by hand in the .Net Framework, as evidenced
by the OP's response to my answer,which was specifically about memory
allocation, from his previous experience as a C+ developer.

While one might helpfully point out the use of the IDisposable interface as
part of an answer to the question, the argument against my correct
information was both misleading and (as explained) contained false
information.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
"Kevin Spencer" <uc*@ftc.govwrote in message
news:uL**************@TK2MSFTNGP03.phx.gbl...
>>Actually -- no. The objects will no longer be reachable through the
array. Only if there are no other references to those objects, will they
be garbage collected, and then only when you run low on memory. To free
resources, you still have to call Dispose() by hand on each object.

Incorrect. First, the question was, "are the resources allocated to the
objects that are now thown out of the array released properly by the
CLI?" The answer is, "yes." They are "released properly by the CLI."

There are 2 distinct errors in your answer. First, your assertion that
Garbage Collection only occurs when the system is low on memory. This is
not true. Low memory is only one of several criteria used to determine
when Garbage Collection occurs. Here is a good article that explains the
process:

http://www.csharphelp.com/archives2/archive297.html

A very nice discussion of what GC does when it runs, but I didn't see
anything about what triggers it. If you're running GC for any reason
other than low memory (i.e. calling GC.Collect()), something is wrong.
>>
The second errror is the statement "To free resources, you still have to
call Dispose() by hand on each object." First, most .Net classes do NOT
implement IDisposable, meaning, they do not HAVE a Dispose() method.
Apparently, they do not all need a Dispose() method. In fact, IDisposable
is an interface implemented for managed classes that use unmanaged
resources, or that use a lot of managed resources, and would benefit from
quick Garbage Collection. It is not implemented for most classes because
.Net Garbage Collection handles memory allocation quite well by itself in
most cases.

So yes, you admit that Dispose() is necessary for freeing any resources
other than memory (and often memory as well, if it's allocated outside the
CLR). Usually, the word resources is used to refer to exactly the things
Dispose() is needed for, if one meant "only memory" one would say memory
rather than resources. It is clearly important to the OP based on his
wording that someone tell him that Array.Resize() won't free unmanaged
resources.
>>
I have written large-scale applications that allocate dozens of megabytes
of RAM at a time, and they manage memory perfectly.

As for arrays, an array can be an array of anything. So, the idea that
creating a new instance of an array (which is what resizing does) is
going to necessitate Garbage Collection is simply mistaken. An array of
integers, for example, will not need any Garbage Collection, because
integers are value types. With an array of objects, yes, if there is a
reference to an object (in the array) in the running app, that object
will not be Garbage-Collected until that reference is removed. But on the
other hand, if you are still referencing an object, you don't WANT it to
be Garbage-Collected; you are still using it.

The OP spoke specifically of an array of objects, not structs. But in any
case when the array is resized, the old storage for the array must be
freed. The storage for the array proper is GC-tracked. For arrays of int
or any other value type, it's the only GC handle. It can be quite large
and it must be garbage collected.
>>
--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

What You Seek Is What You Get.

"Ben Voigt" <rb*@nospam.nospamwrote in message
news:eg**************@TK2MSFTNGP04.phx.gbl...
>>"Kevin Spencer" <uc*@ftc.govwrote in message
news:eJ**************@TK2MSFTNGP05.phx.gbl...
Yes.

Actually -- no. The objects will no longer be reachable through the
array. Only if there are no other references to those objects, will they
be garbage collected, and then only when you run low on memory. To free
resources, you still have to call Dispose() by hand on each object.

Sep 8 '06 #7

P: n/a
"Kevin Spencer" <uc*@ftc.govwrote in message
news:ef**************@TK2MSFTNGP04.phx.gbl...
>A very nice discussion of what GC does when it runs, but I didn't see
anything about what triggers it. If you're running GC for any reason
other than low memory (i.e. calling GC.Collect()), something is wrong.

You must have overlooked the following (from the article I referenced):
[snip]
>
While one might helpfully point out the use of the IDisposable interface
as part of an answer to the question, the argument against my correct
information was both misleading and (as explained) contained false
information.
This seems to have degenerated into a flame war, so I'm not going to address
your most recent set of mis-statements. I'll wait for the OP or someone
else to indicate interest in further clarification.
Sep 8 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.