Прежде чем я начну с реального вопроса, позвольте мне сказать, что я мог бы ошибиться в некоторых деталях. Если это так, пожалуйста, арестуйте меня, а также, или даже вместо того, чтобы отвечать на мой вопрос.
Мой вопрос в основном касается DLL и .NET. У нас есть приложение, которое использует довольно много памяти, и мы пытаемся выяснить, как правильно это измерить, особенно когда проблема в основном возникает на клиентских компьютерах.
Одна вещь, которая поразила меня, это то, что у нас есть довольно большие сборки .NET с сгенерированным ORM-кодом.
Если бы я использовал неуправляемую (Win32) DLL, которая имела уникальный базовый адрес, несколько одновременных процессов на одной и той же машине загрузили бы DLL один раз в физическую память и просто отобразили ее в виртуальную память для всех приложений. Таким образом, физическая память будет использоваться один раз для этой DLL.
Вопрос в том, что происходит со сборкой .NET. Эта DLL содержит IL, и хотя эта ее часть может использоваться совместно приложениями, как насчет кода JITted, полученного из этого IL? Это общий? Если нет, то как мне измерить, чтобы выяснить, действительно ли это способствует проблеме или нет? (Да, я знаю, это будет способствовать, но я не собираюсь тратить на это много времени, пока это не станет самой большой проблемой).
Кроме того, я знаю, что мы не проверяли базовый адрес для всех сборок .NET в нашем решении, необходимо ли для сборок .NET это делать? И если да, то есть ли какие-то рекомендации по определению этих адресов?
Любое понимание этой области будет приветствоваться, даже если окажется, что это не большая проблема или вообще не проблема.
Редактировать : Только что нашел этот вопрос: .NET сборок и перебазирование DLL , что частично отвечает на мой вопрос, но я все еще хотел бы знать, как JITted код влияет на все это .
Из этого вопроса и принятого ответа следует, что код JITted помещается в кучу, что означает, что каждый процесс загрузит общий двоичный образ сборки и создаст частную копию кода JITted внутри своего собственного пространства памяти. .
Можно ли как-нибудь измерить это? Если это приводит к большому количеству кода, нам нужно больше посмотреть на сгенерированный код, чтобы выяснить, нужно ли его настраивать.
Редактировать : здесь добавлен более короткий список вопросов:
- Есть ли смысл удостовериться, что базовые адреса сборок .NET уникальны и не перекрываются, чтобы избежать перебазирования dll, который в основном будет использоваться для извлечения кода IL для JITting?
- Как я могу измерить, сколько памяти используется для кода JITted, чтобы выяснить, действительно ли это проблема или нет?
Ответ @ Brian Rasmussen здесь указывает, что JITting будет производить копии JITted-кода для каждого процесса, как я и ожидал, но что перебазировка сборок действительно будет иметь эффект в с уважением к уменьшенному использованию памяти. Мне придется копаться в инструментах WinDbg + SoS, о которых он упоминает, что-то, что у меня было в моем списке некоторое время, но теперь я подозреваю, что больше не могу откладывать это:)
Редактировать : Некоторые ссылки, которые я нашел на эту тему: