Количество экземпляров CLR и GC, запущенных на машине?

Я создаю 2 приложения.NET и запускаю их на компьютере - сколько будет CLR и gc?

Кроме того: я хотел бы получить некоторую справочную информацию о том, как Windows обрабатывает компоненты COM и CLR в частности. Надеюсь, кто-нибудь может подробно рассказать о том, как CLR загружается в память и что это означает, если я получу несколько экземпляров CLR, перечисленных при выполнении этой команды:

tasklist /m mscor*

Это на самом деле несколько CLR или один CLR в качестве COM-сервера для всех процессов.NET?

Источник

4 ответа

Решение

Каждый процесс будет иметь свою собственную копию CLR в качестве процесса хостинга. Однако, поскольку CLR - это всего лишь несколько библиотек DLL, Windows сможет совместно использовать библиотеки DLL между процессами. Для получения дополнительной информации см.: http://msdn.microsoft.com/en-us/magazine/cc301727.aspx

Источник

Управляемый exe-файл имеет дополнительный заголовок CLR в дополнение к Portable Executable (формат PE). ОС теперь может определить, является ли запущенный exe "управляемым" exe, и, следовательно, загружает CLR за кулисами и дает ему контроль.

  • mscoree.dll - это Shim DLL (последняя версия этого файла всегда присутствует в папке Windows/System32 и, следовательно, знает, как загрузить текущую и более ранние версии CLR.)
  • mscorwks.dll является фактической реализацией CLR. Вы найдете несколько версий этой DLL, если у вас установлено несколько версий платформы. Правильная версия этого dll загружена dll shim.

Из вышесказанного следует, что процесс каждого управляемого исполняемого файла будет иметь свою собственную копию CLR (2 DLL). ManagedExecutable1 может использовать CLR v1, тогда как ManagedExecutable2 может использовать CLR v2. Они не являются общими на данный момент.
Сборщик мусора является частью CLR и, следовательно, также различен для процессов для управляемых исполняемых файлов.

Источник

Я бы сказал, что вы можете легко подсчитать процессы, которые запускаются или загружают CLR, проверяя загруженные библиотеки DLL. Но я не уверен, что вы сможете подсчитать количество запущенных доменов приложений. Но я не думаю, что это ваша цель.

Существует только одна куча на процесс, а также один GC, который приостанавливает все управляемые потоки во время сбора. Таким образом, вы можете перебирать процессы и проверять, загружен ли mscorlib, если это так, вы можете предположить, что на нем запущены.NET CLR и GC. Я уверен, что должны быть лучшие способы определить, размещен ли процесс в CLR, пожалуйста, проверьте также CLR API.

Пожалуйста, попробуйте книгу Джеффри Рихтера CLR через C#, чтобы лучше понять.

Код ниже повторяет процессы.NET

// 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
    }
}
Источник

CLR на самом деле является компонентом, преобразующим MSIL в машинный код. Затем этот машинный код запускается в своем собственном процессе для каждого приложения.

А в мире.NET процесс тесно связан с доменом приложения. Вот почему я думаю, что это хорошая отправная точка.

Источник
Другие вопросы по тегам