Hey There
Knowing nothing about the GC and never having the need to use it (or so i think), what is a typical use there of, and how can i / my system benefit if i up skill myself and learn more about the GC?
UPDATE ...how can i make things easier for the GC?
The typical use of the GC is to not use it at all and just let the CLR handle everything for you.
The GC isn't like the destructor you'd define in C++. That is you do not need to define it and deallocate previously allocated memory. The whole point of the GC is that it is automatic. My recommendation is give us more information about what you are trying to do / understand because this does not sound safe.
UPDATE ...how can i make things easier for the GC?
The easiest way of making things easier for the GC is to let it do it's job without interfering. It optimizes when it needs to run on it's own.
I would look into when to use a the Finalizer in C#. That is one area where you can potentially help the GC out.
Understanding the Large Object Heap may be of some benefit as well as this can potentially cause problems.
http://techiemate.blogspot.com/2009/04/garbage-collection-in-net.html
If you don't notice that you're using the GC, then you are using it, and you're using it right.
Knowing about the internals of the GC only starts to matter if you're using it wrongly.
The best way to use the Garbage Collector is...
Don't try to use it!
Let it do its own thing. Almost any time people try to play with the GC to make it "more efficient" they wind up inhibiting it and actually making it worse at its job.
To make things easier to the GC, always call Dispose() on any object the supports the IDisposable interface.
It can always be useful to understand how it works; but in most cases, you won't need to worry too much.
When you start allocating non-managed resources (or objects that do), it's worth reading up on the IDisposable pattern so that you can control when the resources are freed (or "deterministic finalisation" if you want to sound knowledgeable when talking with peers).
A few points on coding with GC in mind:
Always make sure to unregister event handlers when you're no longer using them. This is the most common way that objects are kept alive well past their intended lifetime and can also cause bugs if a Disposed object is having event handlers called.
If you're doing interop with unmanaged code, you'll need to be more cognizant of any sharing of managed memory with the unmanaged code. You may need to use pinning and/or GC.KeepAlive to help the GC understand what your unmanaged code needs. Try to keep pinning to a minimum, as it makes things harder on the GC.
You should almost never need to implement a finalizer. If the class does have a finalizer, it should also implement the same cleanup as IDisposable and call GC.SuppressFinalize(this) after disposal, as this helps the GC to efficiently clean up after your class.
In the style of memory management typically used in C, the information which tracks which areas of the heap are free or allocated is separate from the information which indicates what areas are actually used. When information on the heap is no longer needed, code must explicitly mark it as unallocated or else it may remain allocated forever.
A garbage-collection-based system regards all the heap-object references in the system as the definitive indicator for which objects are used. Because it would be impractical to scan all the object references in the system every time an object was allocated, the system effectively "batches" the work: as long as free memory space still exists on the heap, memory is simply allocated to objects sequentially. No attempt is made to reclaim any space until the heap gets too full.
An object will be considered to be "used" if any thread holds a reference to it in a local variable, or if any global variable holds a reference to it, or if object which is considered "used" holds a reference to it in any field. The compiler can usually tell if a local variable that holds a reference to an object will never actually be used, but it cannot make such determinations with global variables or object fields. If an object which is going to be useful holds an object reference which is never again actually going to be used, that reference should be set to null (Nothing in VB). If this is not done, the useless object will be "kept alive" as long as the useful object is. If the useful object is something like an application's main form, the result may be a memory leak that persists as long as the application remains open.