I’m using C# for a several years, never actually willing (until I really need to) to dig into its “deep” mechanics and to intervene in GC work, IL-compiled code and so on.
My point is if you ever need to even call GC manually (speaking general – to “help” C#’s or .NET’s mechanics and frameworks to do their job), then it is 99% probability that you doing something wrong versus 1% that you actually need this.
This is some kind of “old school” programmers’ whim – rather than study existing libraries and frameworks they will invent a bicycle again and again, flaunting with their “deep” knowledge, putting every “pattern” they heard of and producing some “masterpiece” which nobody will be able to understand (even creator himself several moths later).
However, back to the topic. GC generations is one of quite popular questions I was asked by some HRs, also I’ve read some “getting ready for the interview” articles touching this topic, but never seen anything about how you actually can deal with them yourself. I suppose, you can’t? I did some surface search and found only “understanding GC” kind of stuff. Like, you can know how compiler actually works, but do you going to “help” it to compile your program? And if not going to, then maybe better use your time to study some ASP.NET vNext kind of stuff?
So, do GC generations have any purpose (for an application programmer) other than answer to “tricky” HRs’ questions?
3
Knowledge of generational GC — the general idea, not how large exactly the young space is in Microsoft’s CLR version x.y — is much like knowledge of JIT compilation, operating system principles, assembly, hardware. You virtually never need it to produce a working product. However, it can accelerate bug hunts and optimization attempts by telling you what probably won’t work. Two examples:
Reusing/pooling objects sounds like a good idea to reduce GC work. If you don’t know a whole lot about GC internals, that is. But in a generational setting, an object that would otherwise be short-lived will be bumped up a generation or two if it goes into a pool. Deallocating it now takes a major GC, which is both rarer and more expensive, and an assortment of other small effects can also take place (depending on whether the object contain references and whether those references point at young objects).
Hence, a pool generally has to prevent many object creations to be profitable, which you now know without having to implement, profile and scrap pooling for something that probably won’t benefit from pooling.
Deeper knowledge also curbs nonsensical hypotheses. I wish I had a quarter for every confused beginner who I’ve seen hunting a (very real) bug by chasing imagined stupidity on the side of the GC. This is mostly related to reachability things, but I’ve also seen a few questions that could have jumped two edits ahead if poster had had a good grasp on generations.
Finally, don’t you think GCs are plain interesting to hear about? Maybe that’s just me, and to be honest it’s perhaps the biggest reason why I learned these things to begin with.
2
(I don’t know C# and I never coded for a Windows OS)
Read at least the wikipage on Garbage Collection, and if possible the GC handbook
A generational copying GC makes the hypothesis (generally rightly) that most young values are temporary and will die soon, and conversely that most old values will last more (and won’t die soon). So a generational GC is focusing its work on the youngest generation. Older generations are not processed often, because they contain long-living values which are likely to last more.
See also this SO question.
You might want (usually wrongly, because it does not worth the effort) to force GC when you know that a bunch of old values is becoming garbage. So generational GC are very useful (because they are efficient), but there are few cases where you want to force a GC in them (I won’t do that, unless benchmarking tells you that it is worth the effort).