3 things you won't believe happen when you execute a print statement

#csharp #dotnet #computerscience

Heads up! This blog post is actually a reading log. I'm spending 30 minutes every day (more or less) reading C# via CLR by Jeffrey Richter and taking notes as I read it. This is tracked as a series on DevTo so you can read all parts of the series in order.

C# via CLR Reading Log 2: Chapter 1

Continuing on from the last reading log, the "Loading the Common Language Runtime" segment of the book began by covering how assemblies are loaded into the CLR.

One of the first key points highlighted in this section, in my opinion, is how distributable assemblies can be. Since they contain type-safe data managed in the DLL, they can interop across 32-bit and 64-bit versions of Windows. The book went on to discuss the different configuration and support options that exist for building assemblies that only execute on either 32-bit or 64-bit systems. To be honest, I zoned out a little bit during this section of the book. I don't find it particularly interesting.

After droning (sorry Jeff!) through a few pages on different bit-systems (note to self: I know there's a word for the bit-iness of a system, what is it though? It's on the tip of my tongue!), I finally made it to the interesting content: how assembly code is executed.

The book presented the example of an assembly that contained two print statements, like so.

static void Main() {
  Console.WriteLine("Hello!");
  Console.WriteLine("Goodbye!");
}

The Main method is the entry point for the CLR. It starts by detecting the types that are referenced in the Main method. In this case, the only object referenced is the Console object. The CLR creates a table mapping each property referenced under this object. In this case, the only property referenced is WriteLine.

Object	Properties	Reference
`Console`	`WriteLine`	To-be-compiled

When the CLR encounters a WriteLine invocation in the code, it looks for the assembly associated with the Console object. Since the assembly is a managed module, it will contain a metadata table of all its types and members. The CLR will look for the WriteLine method in this table. The book states that the IL code for the WriteLine method can be retrieved from the metadata table as well -- although it doesn't go into details about how exactly this happens. I suppose I'll find out soon enough.

Once it has retrieved the IL code from the metadata table, it compiles this IL code down to machine code is a memory block it sets aside for it. Then it updates the references in the property table above to the point to this memory block. This is all to say, the compilation happens just-in-time as the invocations are processed.

Object	Properties	Reference
`Console`	`WriteLine`	A block of memory with machine code for the `WriteLine` method

Also, since there are two WriteLine invocations in the code above, the code for the method will only be compiled once. The second time the method is invoked, we can directly use the reference stored in the table.

The book goes on to discuss the performance advantages of JIT compilation and also presents a realistic perspective on the merits of JIT compilation. In particular, more time is probably spent executing the code for the JIT-ed method than actually compiling it just-in-time.

The book also touched on some of the merits of managed code (code executed by the CLR) and unmanaged code (code not executed by the CLR). In particular, managed code run by the CLR can be translated to machine instructions optimized for the machine the code is running on. That means the CLR can take advantage of those esoteric (don't pretend they're not!) machine language-level quirks for optimizing things like numerical division.

And that's it for today's reading log. The 30 minutes sure did go by fast this time! Next time, I'll be taking a look at the section titled "IL and Verification." Vague....and intriguing...