DLL,内存映射,基地址,内存使用和.NET？

我的问题是关于DLL和.NET,基本上.我们有一个应用程序使用相当多的内存,我们正在努力弄清楚如何正确地测量,特别是当问题主要发生在客户端的计算机上时.

有一件事就是我们有一些比较大的.NET程序集,其中包含生成的ORM代码.

如果我使用的是具有唯一基地址的非托管(Win32)DLL,则同一台机器上的多个并发进程会将DLL加载到物理内存中,并将其映射到所有应用程序的虚拟内存中.因此,该DLL将被使用一次物理内存.

问题是.NET程序集会发生什么.此DLL包含IL,虽然这部分可能在应用程序之间共享,但是由此IL产生的JITted代码呢？是分享吗？如果没有,我如何衡量,这是否真的有助于问题？ (是的,我知道,它会有所贡献,但是我不会花太多时间在这里,直到它是最大的问题).

此外,我知道我们没有在我们的解决方案中查看所有.NET程序集的基址,.NET程序集是否需要这样做？如果是,有没有一些指导方针可以确定这些地址？

对这一领域的任何见解将是最受欢迎的,即使事实证明这不是一个大问题,甚至根本就不是问题.

编辑：刚刚发现这个问题：.NET assemblies and DLL rebasing这部分地回答了我的问题,但我仍然想知道如何将JITTED代码的因素纳入所有这一切.

从该问题及其接受的答案中可以看出,JITted代码放在堆上,这意味着每个进程将加载共享的二进制汇编映像,并在其自己的内存空间中产生一个专用的JITTED代码.

我们有办法衡量这个吗？如果这样就产生了大量代码,那么我们必须先看看生成的代码,以确定是否需要调整它.

编辑：在这里添加一个较短的问题列表：

>确保.NET程序集的基本地址是唯一的且不重叠的,以避免重新使用大部分用于仅将IL代码用于JITting的dll的任何意义？
>如何测量JITED代码使用了多少内存,以确定这是否真的是一个问题？

@Brian Rasmussen here的答案表明,JITting将按照我预期的方式生成JITTED代码的每个进程副本,但是对于减少内存使用而言,这些修订程序集实际上会产生影响.我必须挖掘他提到的WinDbg SoS工具,我在我的名单上有一段时间,但现在我怀疑我不能再把它关掉了:)

编辑：我找到的一些链接：

> Rebase all your library assemblies
> MSDN: Rebasing Win32 DLLs: The Whole Story