W
Willy Denoyette [MVP]
Part of your confusion stems from the fact that you think the GC is a memory
manager, while it's not, let me explain (in short).
First, let's forget about ".NET, it's a marketing term, so let's talk about
the active component that differentiates managed and unmanaged applications,
it's a runtime component called the CLR (on MS platforms).
Managed and unmanaged applications are running inside processes, managed by
the OS, the CLR is private to the process, the OS doesn't know about it at
all. So, to the OS there is only the "process".
Process memory management is a task performed by the OS. An active process
occupies a part of physical memory (RAM) , called the Process Working Set
(WS), and as all active processes must share the available RAM memory, the
OS will have to adapt the WS of individual processes to the available RAM.
Say you start a new process P2 when a running process P1 occupies all
available RAM (the OS won't let this happen though), the OS will trim P1's
WS by writing (data) pages from RAM to the paging file, until there is
sufficient space for the second process (P2) to start running.
As long as P1 remains idle, P2 can see it's WS grow until all pages of P1
are removed from RAM. Whenever P1 returns from idle state the OS will
reverse the operation and start trimming P2's WS. Note that when both P1 and
P2 are active, they will (most likely) incur a high performance penalty
because of the paging activity as a result of the WS trimming.
Now what's the role of the CLR, or more precisely, the GC in this whole
story. First, the GC is not a memory manager, it's a collector, it's role is
to free the space occupied by dead objects from the GC heap (a private per
process heap) and re-arrange the live object's locations within this heap
such that they are adjacent at the beginning of the GC heap (in an ideal
world). The GC heap is nothing more than a private process heap (there are
many more heaps in a process), The CLR's "memory allocator" reserves the GC
heap space from the Process Virtual Address Space by calling the Win32 heap
functions - see here we have the link between OS and application.
The CLR allocates(reserves) an initial heap consisting of 2 segments of 16MB
(workstation version), the first segment being used to store the
generational heaps (gen0-2) the second to store large (>85Kb) objects.
The CLR's "memory allocator" reserves a new segment whenever one of the
initial segments become full (with live objects), additional segments can be
returned to the OS when they get empty, the initial segments are never
returned to the OS (actually they are at CLR shutdown time).
It's clear that the GC heap segments become part of the process WS, and when
the OS trims the WS it will remove pages from the heap. Now, before this
happens, the CLR will call the GC in order to collect dead objects, and as
such create as much as free pages as possible.
But, how does the CLR knows that the OS needs more free memory? Well, on XP
or higher, the CLR registers for Memory Resource Notifications
(CreateMemoryResourceNotification ), whenever a certain memory threshold is
reached the OS notifies the CLR which starts a GC run (which frees pages
from it's heap) and possibly trims it's own WS by returning excess segments
to the OS.
On lower OS's the CLR queries the memory counters at regular intervals and
will initiate GC and possibly return excess segments when a certain memory
threshold has been reached.
Hope this more or less answers you questions, for more details on OS Memory
management, you'll have to search the Platform SDK docs, for more details
about the GC I would suggest http://blogs.msdn.com/maoni/default.aspx as a
must read.
Willy.