I
Imran Koradia
i just finished reading Jeoffrey Richter's article:
20,000 bytes in size are not compacted. The GC compacts (align objects in
contiguous memory locations) objects during a garbage collection to allow
for locality of reference and hence improved performance. Compacting is not
done for larger objects since the substantial CPU time taken to move larger
objects defeats the whole purpose of compacting. As mentioned in the
article, the larger objects are finalized and freed just like all other
objects and hence that would not be the source of your memory leak.
improve performance. You shouldn't have problems with your applications as
such since the GC will run collections whenever Gen0, Gen1 or Gen2 heap
locations get filled up. It will also dynamically allocate more memory to
the heap when it needs to depending on the requirements of your application.
Large long-lived objects or long-lived objects that have large-sized members
would be a few sources of memory leak.
objects larger than 20,000 bytes. You might want to go through your code
again or maybe run a profiler to find sources of memory leaks. Take a look
at this blog post how you could do that:
http://dotnetjunkies.com/WebLog/jpalermo/archive/2004/08/18/22491.aspx
hope that helps..
Imran.
That is incorrect - the article says that objects that are greater than
20,000 bytes in size are not compacted. The GC compacts (align objects in
contiguous memory locations) objects during a garbage collection to allow
for locality of reference and hence improved performance. Compacting is not
done for larger objects since the substantial CPU time taken to move larger
objects defeats the whole purpose of compacting. As mentioned in the
article, the larger objects are finalized and freed just like all other
objects and hence that would not be the source of your memory leak.
You could use weak referencing (which is mentioned in the same article) to
improve performance. You shouldn't have problems with your applications as
such since the GC will run collections whenever Gen0, Gen1 or Gen2 heap
locations get filled up. It will also dynamically allocate more memory to
the heap when it needs to depending on the requirements of your application.
Large long-lived objects or long-lived objects that have large-sized members
would be a few sources of memory leak.
This is definitely not because of the GC's decision to not to compact
objects larger than 20,000 bytes. You might want to go through your code
again or maybe run a profiler to find sources of memory leaks. Take a look
at this blog post how you could do that:
http://dotnetjunkies.com/WebLog/jpalermo/archive/2004/08/18/22491.aspx
hope that helps..
Imran.