What are the problems with a Mark and Sweep Garbage Collector?::	- A mark and sweep GC has to mark all live objects on the heap during each collection cycle.<br>- This can lead to long program freezes while the collection is running<br>- Also: repeatedly marking the same objects over and over in each cycle is very inefficient.
How does a Generational Garbage Collector help reduce the problems of a Mark and Sweep Garbage Collector?::	- Generations help to reduce the number of objects in gen 0.<br>- Gen 1 and Gen 2 are collected much less frequently.<br>- The GC assumes that any object that reaches gen2 must be a long living object that does not need to be checked very often.
What are the Implicit assumptions that the garbage collector operates on?	- Objects are either short-lived or long-lived.<br>- Short-lived objects will be allocated and discarded within a single collection cycle.<br>- Objects that survive two collection cycles are long-lived.<br>- 90% of all small objects are short-lived.<br>- All large objects (85K+) are long-lived.
Which objects remain in the Gen0 list after every garbage collection cycle?	Gen 0 is completely cleared i.e. empty.
When optimizing code for GC, what are the two considerations you must look for with regards to object size and lifetime?	- Avoid large short-lived objects<br>- Avoid small long-lived objects
If you have a large short-lived object, what is the one optimization you can try?	If you have a large object like say a db connection and for some reason it is short-lived then one optimization that you can use to convert it to a long-lived object is to to pool it in an object pool and reuse it the next time.
Should a finalizer process other referenced objects?	A finalizer must only process its own object and never other referenced objects.
You have some referenced objects in your class, will you process them in a finalizer?	No. A finalizer must only process its own object and never other referenced objects.