Number of CLR and GC instances running on a machine?

Question

I create 2 .NET applications and run them on a machine - how many CLR\'s and gc\'s will be there?

In addition: I would like to have some background information on ho

Answer 1

I would say that you can easily count processes that run or load the CLR by inspecting the loaded dlls. But I am not sure if you will be able to count the number of application domains running. But I do not think that is your objective.

There is only one heap per process and also one GC, which suspends all managed threads during collection. So you could iterate through the processes and check if mscorlib is loaded, if so you can assume that that is running a .NET CLR and a GC. I am sure that there should be better ways to determine if a process has CLR hosted, please check the CLR API as well.

Please try Jeffrey Richter's book CLR via C# to have a closer understanding.

The code below iterates .NET processes

// Import these namespaces
using System.Diagnostics;
using System.ComponentModel;

// Here is the code
Process[] prcs = Process.GetProcesses();
foreach (Process prc in prcs)
{
    try
    {
        foreach (ProcessModule pm in prc.Modules)
        {
            if (pm.ModuleName.Contains("mscorlib"))
            {
                Console.WriteLine(prc.ProcessName);
            }
        }
    }
    catch (Win32Exception exWin)
    {
        // Cannot detemine process modules ... some will deny access
    }
}

Answer 2

Each process will have its own copy of the CLR as a hosting process. However, since the CLR is really just a couple of DLLs Windows will be able to share the DLLs between processes. For more information see: http://msdn.microsoft.com/en-us/magazine/cc301727.aspx

Answer 3

The CLR is actually the component that transforms MSIL into native machine code. That native machine code then runs in its own process for each application.

And in the .NET world a process is closely related to an appdomain. That's why I think this is a good starting point.

Answer 4

A managed exe has an additional CLR header in addition to the Portable Executable (PE format). The OS now is able to determine if the launched exe is a "managed" exe, and hence loads the CLR behind the scenes and gives it control.

• mscoree.dll is a shim DLL (the latest version of this file is always present in the Windows/System32 folder and hence knows how to load current and older versions of the CLR.)
• mscorwks.dll is the actual implementation of the CLR. You will find multiple versions of this dll if you have multiple versions of the framework installed. The right version of this dll is loaded by the shim dll.

It follows from the above that each managed executable's process would have its own copy of the CLR (2 Dlls). ManagedExecutable1 may be using CLR v1 whereas ManagedExecutable2 may be using CLR v2. They are not shared as of now.
The Garbage collector is part of the CLR and hence is also distinct across processes for managed executables.