#955 – C# Is a Managed Language

When you author code in C#, you’re writing managed code.  That is, you’re creating a managed application.

Managed code runs within the context of the Common Language Runtime (CLR).  The CLR is a run-time environment that executes managed code and provides basic services to your application like a standard type system, memory management, and exception handling.

Managed code can be written in a number of different languages, including (but not limited to) C#, Visual Basic, and Managed C++.  The compiler for the associated language converts the code into Microsoft Intermediate Language (MSIL), which is consumed by the CLR and then compiled by a Just in Time Compiler (JIT) into machine-specific instructions.

Managed code can execute not only within Microsoft’s CLR, running on Windows, but also on other third-party CLR implementations. (E.g. The Mono project, which implements a runtime for running managed code on Android, Linux and OS X).


#924 – You Shouldn’t Normally Worry about Memory Management

Because the Common Language Runtime (CLR) implements automatic memory management for heap-based objects, you generally don’t need to worry about memory management for objects that your code creates.  Because the Garbage Collector (GC) takes care of automatically deleting objects that are no longer being referenced, you don’t need to worry about deleting objects or removing references to them.

Your code explicitly creates objects, but doesn’t need to worry about destroying them, or about releasing memory for objects no longer in use.

Your code can freely:

  • Create objects (instances of types)
  • Create references to objects
  • Change reference-type variables to refer to other objects
  • Allow objects to contain references to other objects

Your code typically will not:

  • Dereference objects (e.g. by setting a reference-typed variable to null)
  • Keep track of whether objects have been deleted or not
  • Interact with the Garbage Collector to impact how objects are destroyed

#424 – The Garbage Collector

In C#, you don’t explicitly delete heap-based objects.  Instead, the CLR will reclaim memory from objects that are no longer used, by running a Garbage Collector.

The garbage collector (GC) can release memory only for managed objects created on the heap.  It’s only job is to release memory.  It can’t clean up or release other resources, like file handles or database connections.

The GC will typically perform garbage collection when the amount of available physical memory is becoming too low or when the amount of virtual memory consumed by your application is becoming too large.

You can’t predict when garbage collection is going to happen, or even if it’s going to happen, prior to an application terminating.

#180 – The CLR Loads Assemblies on Demand

When you execute a .NET program, the CLR (Common Language Runtime) loads the assembly located in the executable and then starts executing the code in the function defined as the entry point for that assembly.

If your assembly references a second assembly, that second assembly will only get loaded if its code is invoked at runtime.

This means that it makes sense to partition your application into assemblies, based on functionality and expected use.  If running a program typically only results in 20% of its code being executed, the most efficient partitioning would be to have the remaining 80% of the code in one or more assemblies other than the main assembly.  If code in one of these assemblies is never called, the assembly is never loaded.

Loading as few assemblies as possible is desirable, because this results in a smaller memory footprint for your program.