Re: GC.Collect can be trusted?

<mpetrotta@xxxxxxxxx> wrote in message news:1177102510.680068.269940@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Apr 20, 1:04 pm, "Willy Denoyette [MVP]"
<willy.denoye...@xxxxxxxxxx> wrote:
<mpetro...@xxxxxxxxx> wrote in message

news:1177088290.348257.92830@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

> On Apr 20, 4:59 am, Ward Bekker <wDotbekker@RemoveThisequanimityDotnl>
> wrote:
>> 2. I want to make sure that all objects that can be garbage collected (
>> disconnected from the root object) _are_ not longer alive. The
>> documentation is not very clear that GC.Collect will actually throw out
>> the thrash.

> Seems pretty clear to me, if lacking in detail:
> "However, the Collect method does not guarantee that all inaccessible
> memory is reclaimed."

Reclaimed by who? The task of the GC is to collect the inaccessible objects and if possible
compact the heap. It's not the task of the GC to return the memory to the OS, the GC can't
even do that, it's up to the memory manager (another CLR component) to keep track of the
extra segments allocated from the process heap and (eventually) return these when they don't
contain any GC heap data (managed objects and other CLR data).
Anyway, the memory manager won't ever return the default process heap segments occupied by
the managed heap (32 MB or 64 MB ) to the OS

I don't see that it matters. The OP is using Ants Profiler (and its
"Live Objects" view) to profile his memory usage. I'm not very
familiar with that tool, so I just tried out the demo. That view
lists all objects on the managed heap (collected or not, apparently).
Once collected, objects should no longer appear in that view. Whether
the memory they consumed is still being used by the CLR is irrelevant
(for the OP, at any rate).

You have too much trust in such tools. First, collected objects should not appear in that list, note however that NO single tool is able to show in real time what's happening in the CLR, they are simply relying on the counter data provided by the CLR, these (and other info) are supplied by the CLR via a call-back interface, however, the data isn't updated in real-time fashion, more whenever you attach a profiler you are introducing side effects, the CLR behaves differently when a profiler or debugger is attached.
A profiler by the way is no means to detect memory leaks, they are meant to profile application behavior, this includes allocation patterns (what parts of the program is allocating what kind and how many objects, what's their life time etc..), but they can't show you leaked memory, debuggers are (and here I mean unmanaged debuggers not managed ones) meant to find these kind of bugs, but keep in mind they too are quite intrusive, the crate side effects the influence the behavior of the application. Only way to find a leak is by taking a snapshot dump and investigate that dump off line using the right tools for managed applications.


Willy.
..

.

Relevant Pages

  • Re: Assembly memory limit exception -WHY?
    ... Asking for 700-800 MB of continuous memory is a ... CLR DLL's and Windows system DLL's and private user ... The managed heap allocated by the CLR ... >From this 1.2GB the CLR will allocate it's Large Object heap, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: GC.Collect can be trusted?
    ... compact the heap. ... It's not the task of the GC to return the memory to the OS, ... contain any GC heap data (managed objects and other CLR data). ... the memory manager won't ever return the default process heap segments occupied by ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: virtual memory leak? in asp.net app - OutOfMemory exception
    ... I'm shocked that the CLR would not release memory back to Windows. ... HeapCreate specifies both an initial size and a maximum size for the heap. ... I don't know if the CLR uses HeapCreate or not, ...
    (microsoft.public.dotnet.framework.clr)
  • Re: What does a heap look like?
    ... What do you call that area of memory then? ... What do we mean by "heap"? ... Once you have obtained a handle to a heap, you can pass that handle to the memory allocation functions, to allocate memory from that particular heap. ... Usually objects in CLR are represented as a linked list and CLR uses Windows memory heap to allocate a new object; but then this object consiedered as a "managed" because he is a part of "virtual" adress space and JIT creates a special information table for GC. ...
    (microsoft.public.dotnet.framework.clr)
  • Re: unmanaged vs managed.
    ... Above article is based on what is found in SSCLI and does not reveal that much about the CLR memory manager's internals, nor does it include anything really useful about the GC and the JIT implementation in the commercial CLR product. ... Note that in following I denote by *Heap*, the "Heap Managers" heap, while with *GC-Heap* I denote the CLR managed heap. ... It's quite obvious that the CLR has it's own memory manager, after all the *GC-Heap* is THE CLR's private heap, no other component in the system uses/manages the GC-Heap but the CLR. ... The CLR Object Manager allocates from the GC-Heap, while the GC keeps the GC-Heap "clean" in close cooperation with the CLR Memory Allocator or an external Memory allocator like the one used when you run the CLR in the SQL Host. ...
    (microsoft.public.dotnet.languages.csharp)
Quantcast