При каких обстоятельствах процессы .NET и AppDomains будут совместно загружать сборки в память?

Question

Я ищу дополнительную информацию о том, когда и как приложения .NET совместно используют загруженные сборки. Я заинтересован в совместном использовании процессов ОС, но и между AppDomains в рамках одного процесса. Совместное использование сборок снижает использование системной памяти, избегая наличия нескольких копий одной и той же сборки в памяти, я полагаю, что это основное преимущество, но было бы интересно узнать, есть ли другие преимущества и/или последствия.

Резюме того, что я узнал до сих пор ...

1. Sysinternals process explorer может быть использован для отображения AppDomains процесса содержащиеся .NET в и сборок, загруженных в каждый AppDomain.

2. Процесс .NET всегда загружает сборку «ядро» в AppDomain, называемый «SharedDomain» (разумно предположить, что это совместное использование AppDomains в текущем процессе).

3. Диспетчер задач и проводник процессов сообщают незначительные номера использования памяти для «Working Set Shared» и «Working Set Shareable», но неясно, что общего. (Является ли это «базовыми» ассемблиями в рамках общего AppDomain? Также существуют общие [неядерные] сборки?

4. В простой тесте я запустил две копии автономного .NET-приложения и подключил отладчик Visual Studio для каждый. В представлении «Модули» показаны загруженные сборки и их адреса в памяти. В моем тестовом примере каждый загруженный модуль располагался по тому же адресу в двух процессах (это указывает на общий доступ или это виртуальное адресное пространство, которое не является обязательно разделяют?)

5. ASP.NET 4.5 поддерживает совместное использование сборок с помощью механизма, называемого сборки интернирование (см Look at Sharing Common Assemblies in ASP.NET 4.5, Sharing Common Assemblies, Sharing common assemblies with aspnet_intern.exe). по-видимому, работает путем создания файловой системы символические ссылки (символические ссылки), чтобы различные веб-приложения указывали на папку с общим бином, поэтому возникает вопрос о том, просто ли ASP.NET использует символические ссылки для запуска стандартного поведения совместного использования сборки в .NET или есть ли что-то более конкретное для ASP .NET и IIS AppPools продолжаются.

Примечание. На машине с Visual Studio 2013 установлена, aspnet_intern.exe можно найти в:

C: \ Program Files (x86) \ Microsoft SDKs \ Windows \ v8.1A \ Bin \ NETFX 4.5.1 Tools \

Были усовершенствованы время запуска и использования ASP.NET в более поздних версиях .NET и Windows Server; См. ASP.NET App Suspend – responsive shared .NET web hosting, Performance Improvements for ASP.NET Shared Hosting Scenarios in .Net 4.5, но я не уверен, насколько актуальны эти изменения для этого вопроса.

Совместное использование сборки ASP.NET также описано в книге Introducing .NET 4.5.

Также интересно узнать, является ли JIT-код общим или нет, поскольку загруженная сборка состоит из MSIL, ресурсов, метаданных и т. Д., И дальнейшая память должна быть выделена, когда код JITted.

Существует также эта дискуссия о разделении сборки в компактных структурах (We Believe in Sharing, MSDN Blogs, Абхинаб Бас)

--- UPDATE ---

Я использовал sysinternals VMMap tool рассмотреть два AppPools , один с asp.net сборкой интернированных настроен, другой без. Я также «коснулся» тестовой страницы aspx, чтобы заставить ASP.NET загружать все сборки (а global.asax работает с небольшим количеством кода, поэтому вызывает некоторые JITting).

Показанные значения использования памяти для двух AppPools очень похожи, рабочий набор, WS Private и WS Shareable по существу одинаковы. Однако WS Shared намного больше в «интернировании» AppPool. Это было неожиданным (для меня), поскольку нет другого процесса для совместного использования, но VMMap показывает, что блоки памяти (помечены как «.text» и с защитой Execute/Read), которые отображаются как обмен памяти в интернирующем AppPool, тогда как одна и та же сборка в другом AppPool не используется. Моя интерпретация этого состоит в том, что блоки виртуальной памяти в процессе отображаются в одну и ту же физическую память и затем сообщаются как «WS Shared».

ASLR

Что касается Ассамблеи Space Layout рандомизации. Средство VMMap показывает много блоков памяти с типом «Image (ASLR)». ASLR рандомизирует местоположение сборок в памяти, чтобы помешать вредоносному ПО, и я задался вопросом, не мешало ли это правительству работать в сборке. Отключение ASLR для машины с использованием EMET tool привело к тому, что адреса ассемблера были более регулярными, но не меняли номера зарегистрированных номеров, поэтому, похоже, это не влияет на интернационализацию сборки. Стоит отметить, что VMMap все еще показывал изображения с ASLR против них, что, как я подозреваю, просто означает, что сборка/изображение помечены как поддержка/разрешение ASLR, а не ASLR.

Answer 1

В одном случае, когда происходит совместное использование сборки, сборки скомпилированы в собственный код с помощью ngen.exe. Процитирую "CLR через C#" (Глава 1)

Инструмент Ngen.exe интересен в двух сценариях:

...

Сокращение рабочего набора приложений '- если вы считаете, что сборка будет загружаться одновременно в несколько процессов, запуск NGen.exe на этой сборке может уменьшить рабочий набор приложений. Причина в том, что инструмент NGen.exe скомпилирует IL к собственному коду и сохраняет результат в отдельном файле . Этот файл можно одновременно отображать в многопроцессорные адресные пространства , позволяя совместно использовать код; а не каждому процессу нужна своя копия кода.