[Israel.pm] C#.Net Garbage Collector

Shmuel Fomberg semuelf at 012.net.il
Thu Feb 28 09:49:46 PST 2008


Hello All.

I'm studying a bit about C# and the .Net, And thought that it may interest
someone here. 

Anyway, I read about the GC (Garbage Collector) in the .Net VM, and it goes
like that:
1. Pause all threads in some safe point
2. Assume all the memory is garbage
3. Starting from every root (reference) that any of the threads holds, and
mark whatever memory that it refer as 'not garbage'. Do so until all memory
that is accessible from the running threads is marked.
4. For every garbage object that have destructor defined, add it to a list
and mark it and whatever it refer to as not garbage.
5. Compact the memory (yes, actually moving pieces on memory around)
6. End

Other points:
* the garbage object with destructors are still alive, and a background
thread runs destructors. These objects will be collected next time.
* the destructors are run without any order. Even if the objects include
other objects. 
* All this let the framework to completely ignore problems like circular
referencing and the need to keep dependencies. 
* For those reasons, sometimes the programmer have to remember to explicitly
call some 'close' function before throwing away the reference. (sucks)

Optimizations:
* The objects in the memory are divided to three 'generations'. Every GC
sweep pushes all the reminding memory to gene+1. the GC sweep itself happens
only when the allocated memory for specific generation is more then some
defined (adaptive?) value. 
* Because the GC compact the memory, there is just a pointer to the
beginning of the free memory, instead of a list of empty spaces. Makes
memory allocation much more fast and thread-safe.
* If the VM decides that it's running on a server, (donno how exactly)
instead of stopping the threads it will use some background thread that
marks the used memory.
* Every piece of code in .Net have a table associated with it, that says
which variables (memory addresses) are holding references to objects. There
can be registers in this table. Not sure if it's done in the compilation
phase or in the JIT. (on the other hand, why should we care?)

A nice MS-thinking. Don't solve difficult problems. Optimize the small
problems. 

Happy Coding.
Shmuel.





More information about the Perl mailing list