C# Deconstructed

Mohammad Rahman

Mentioned 1

C# Deconstructed answers a seemingly simply question: Just what is going on, exactly, when you run C# code on the .NET Framework? To answer this question we will dig ever deeper into the structure of the C# language and the onion-skin abstraction layers of the .NET Framework that underpins it. We’ll follow the execution thread downwards, first to MSIL (Microsoft Intermediate Language) then down through just-in-time compilation into Machine Code before finally seeing the results executed at the hardware level. The aim of this deep-dive is to provide you with a much more rounded knowledge of the environment within which you code exists. As a managed language, it’s best-practice to let the Framework deal with device interaction but you’ll find the experience of taking the cover off once in a while a very rewarding one that will greatly enrich your appreciate of the C# language and the way in which in functions. What you’ll learn Understand how C# handles your filesystem requests and passes them down to hard disks and memory Learn how RAM works and how programs map to address spaces Discover the C# compilation sequence in detail and follow it down from abstract code to actual function See how your device’s micro-processor executes Machine Code and just-in-time compilation provides it when it’s needed Learn how the Common Language Runtime (CLR) determines the execution of your code and handles Threading and Scheduling for your instructions Who this book is for This book is ideal for anyone who works with C# and has ever wondered what happens after they press F5. Table of Contents Anatomy of the C# compilation stack Data Access, Files and Storage Understanding Memory Usage The C# Compilation Sequence From CIL to Machine Code Execution through the CLR Execution Model II

More on Amazon.com

Mentioned in questions and answers.

Programming language books explain that value types are created on the stack, and reference types are created on the heap, without explaining what these two things are. I haven't read a clear explanation of this. I understand what a stack is, but where and what are they (physically in a real computer's memory)?

  • To what extent are they controlled by the OS or language runtime?
  • What is their scope?
  • What determines the size of each of them?
  • What makes one faster?
  • Introduction

Physical memory is the range of the physical addresses of the memory cells in which an application or system stores its data, code, and so on during execution. Memory management denotes the managing of these physical addresses by swapping the data from physical memory to a storage device and then back to physical memory when needed. The OS implements the memory management services using virtual memory. As a C# application developer you do not need to write any memory management services. The CLR uses the underlying OS memory management services to provide the memory model for C# or any other high-level language targeting the CLR.

Figure 4-1 shows physical memory that has been abstracted and managed by the OS, using the virtual memory concept. Virtual memory is the abstract view of the physical memory, managed by the OS. Virtual memory is simply a series of virtual addresses, and these virtual addresses are translated by the CPU into the physical address when needed.

Figure 4-1. CLR memory abstraction enter image description here

The CLR provides the memory management abstract layer for the virtual execution environment, using the operating memory services. The abstracted concepts the CLR uses are AppDomain, thread, stack, heapmemorymapped file, and so on. The concept of the application domain (AppDomain) gives your application an isolated execution environment.

  • Memory Interaction between the CLR and OS

By looking at the stack trace while debugging the following C# application, using WinDbg, you will see how the CLR uses the underlying OS memory management services (e.g., the HeapFree method from KERNEL32.dll, the RtlpFreeHeap method from ntdll.dll) to implement its own memory model:

using System;
namespace CH_04
{
 class Program
 {
 static void Main(string[] args)
 {
 Book book = new Book();
 Console.ReadLine();
 }
 }
 public class Book
 {
 public void Print() { Console.WriteLine(ToString()); }
 }
}

The compiled assembly of the program is loaded into WinDbg to start debugging. You use the following commands to initialize the debugging session:

0:000> sxe ld clrjit

0:000> g

0:000> .loadby sos clr

0:000> .load C:\Windows\Microsoft.NET\Framework\v4.0.30319\sos.dll

Then, you set a breakpoint at the Main method of the Program class, using the !bpmd command:

0:000>!bpmd CH_04.exe CH_04.Program.Main

To continue the execution and break at the breakpoint, execute the g command:

0:000> g

When the execution breaks at the breakpoint, you use the !eestack command to view the stack trace details of all threads running for the current process. The following output shows the stack trace for all the threads running for the application CH_04.exe:

0:000> !eestack


Thread 0

Current frame: (MethodDesc 00233800 +0 CH_04.Program.Main(System.String[]))

ChildEBP RetAddr Caller, Callee

0022ed24 5faf21db clr!CallDescrWorker+0x33

/trace removed/

0022f218 77712d68 ntdll!RtlFreeHeap+0x142, calling ntdll!RtlpFreeHeap

0022f238 771df1ac KERNEL32!HeapFree+0x14, calling ntdll!RtlFreeHeap

0022f24c 5fb4c036 clr!EEHeapFree+0x36, calling KERNEL32!HeapFree

0022f260 5fb4c09d clr!EEHeapFreeInProcessHeap+0x24, calling clr!EEHeapFree

0022f274 5fb4c06d clr!operator delete[]+0x30, calling clr!EEHeapFreeInProcessHeap /trace removed/

0022f4d0 7771316f ntdll!RtlpFreeHeap+0xb7a, calling ntdll!_SEH_epilog4

0022f4d4 77712d68 ntdll!RtlFreeHeap+0x142, calling ntdll!RtlpFreeHeap

0022f4f4 771df1ac KERNEL32!HeapFree+0x14, calling ntdll!RtlFreeHeap

/trace removed/

This stack trace indicates that the CLR uses OS memory management services to implement its own memory model. Any memory operation in.NET goes via the CLR memory layer to the OS memory management layer.

Figure 4-2 illustrates a typical C# application memory model used by the CLR at runtime.

Figure 4-2. A typical C# application memory model enter image description here

The CLR memory model is tightly coupled with the OS memory management services. To understand the CLR memory model, it is important to understand the underlying OS memory model. It is also crucial to know how the physical memory address space is abstracted into the virtual memory address space, the ways the virtual address space is being used by the user application and system application, how virtual-to-physical address mapping works, how memory-mapped file works, and so on. This background knowledge will improve your grasp of CLR memory model concepts, including AppDomain, stack, and heap.

for more information refer this book: C# Deconstructed: Discover how C# works on the .NET Framework

http://www.amazon.com/Deconstructed-Discover-works-NET-Framework/dp/1430266708

this book + ClrViaC# + Windows Internals are excellent resources to known .net framework in depth and relation with OS.