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.

Which version of the framework are you using? There was a well documented bug in 1.0 which led to memory leaks from the large object heap

Regards

Richard Blewett - DevelopMentor

http://staff.develop.com/richardb/weblog

  nntp://news.microsoft.com/microsoft.public.dotnet.framework/<uT29z9anEHA.1248@TK2MSFTNGP09.phx.gbl>

hi all

i just finished reading Jeoffrey Richter's article:
http://msdn.microsoft.com/msdnmag/issues/1200/GCI2/default.aspx
according to which, 20,000 bytes object do not get shifted upon freeing
them.

so how am i suppose to deal with an application that constanly plays with
huge buffers,
20k being tiny!

no wonder my application seems to be leeking memory!


what am i supposed to do?


assaf





[microsoft.public.dotnet.framework]

Note that this article is four years old and isn't correct as far as the
size of the large objects being 85Kb now.
Also don't "suppose" you have memory leaks, measure your memory consumption
using perfmon counters and/or use a memory profiler if you want to be sure.
Most "memory leaks" in .NET tend to be nothing else than the result of how
.NET:
- allocates memory for the GC heap.
- the JITter allocates memory for the jitted code.
- the assembly loader allocates memory for the IL/Metadata.
- the class loader initializes it's tables (method table, interface tables
...).

Willy.