Heads up! This blog post is a reading log I'm writing. I'm spending 30 minutes a day reading The Book of the Runtime.

Reading Log 2: The Book of the Runtime

It's been a while since I did my "daily" reading. Life gets in the way, you know? But I'm back reading the BotR. Today's reading log starts off at the Fundamental Features of the CLR.

This section listed the set of features that are part of the CLR. One thing that I really liked about the categorization scheme is the way it listed features on a spectrum of "affects the design of everything else" to "kind of its own thing." I felt like this was a pretty sensible model for listing off these features. This matches the way that I sometimes think about things and it is nice to see words put into this perspective.

One of the fundamental features is the garbage collector. Garbage collectors are runtime constructs that reclaim (or collect) memory that is no longer needed by a process (garbage). Garbage collectors are wonderful because they mean people have to spend less time thinking about trivial things like keeping track of pointers and more time thinking about how to build software that helps people.

The book goes on to state that garbage collector requires that the runtime have a reference to every piece of allocated memory that a program is using. Anyone who has had to herd cats knows how tough this can be.

But there's more to it than that. Technically, you only need to know the references when you are about to garbage collect. Since garbage collection is not a continuous process (AFAIK), you only need to know the references when you garbage collect. Just when you think this will simplify things, BotR crushes are dreams by reminding us of another fundamental design principle of the CLR.

The CLR supports multiple concurrent threads of execution with a single process.

This complicates things because it means that it is not feasible to predict when a garbage collection will happen (AFAIK) as any thread can require garbage collection at any time. So, bummer, we actually do need to maintain a list of references at all times.

Fooled again! The GC in the CLR does not maintain a reference at all times, just most times at the book states. I'm gonna be honest, the phrase "almost all the time" makes me a little uneasy. This seems....weird? Unpredictable? What's the reasoning behind it?

At this point, the book invites us to read the garbage collection design doc. When one sees a link, one must click it! So away we go into a new tab...

This chapter lists some recommended readings. I've jotted them down for further exploration. Onwards!

Garbage collectors have two components: an allocator and a collector. All of this is quite familiar from my programming language courses at university. But this is only the first sentence of the chapter, so I won't get too cocky just yet!

The book stats that the allocator gets called by the Execution Engine. Note that the E's are intentionally capitalized. We're in the big leagues now. I have no idea what the execution engine exactly is but I'm going to use context clues and assume it is the component responsible for the execution lifecycle of code.

This component passes information about allocated memory to the allocator. Specifically, it lets the allocator know how many bytes were allocated, the "thread allocation context", and whether or not the object is finalizable.

The first piece of information makes sense to me. Knowing the number of bytes allocated is useful for the collection process.

The second is also generally clear, although me being me, I want to know exactly what the heck a thread allocation context looks like. I'm vaguely familiar with it from my time spent debugging C# code.

The last detail is interesting. I'm familiar with finalizable objects but didn't know why it would be important to pass a flag about the objects state. Thankfully, the universe is kind and there is a StackOverflow post for this. It made some references to implementation details of the garbage collector that I am not yet familiar with -- so I'll set it aside for now and parse it more completely once I've finished reading the garbage collector chapter...

...which will happen in the next reading log because my 30 minutes are up. Time flies when you are having fun!