Home/ Questions/Q 122795
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-11T04:11:06+00:00

Before I start with the real question, let me just say that I might

  • 0

Before I start with the real question, let me just say that I might get some of the details here wrong. If so, please arrest me on those as well as, or even instead of answering my question.

My question is about DLLs and .NET, basically. We have an application that is using quite a bit of memory and we’re trying to figure out how to measure this correctly, especially when the problem mainly occurs on clients’ computers.

One thing that hit me is that we have some rather large .NET assemblies with generated ORM-code.

If I were using an unmanaged (Win32) DLL that had a unique base-address, multiple simultaneous processes on the same machine would load the DLL once into physical memory, and just map it into virtual memory for all the applications. Thus, physical memory would be used once for this DLL.

The question is what happens with a .NET assembly. This DLL contains IL, and though this portion of it might be shared between the applications, what about the JITted code that results from this IL? Is it shared? If not, how do I measure to figure out of this is actually contributing to the problem or not? (Yes, I know, it will contribute, but I’m not going to spend much time on this until it is the biggest problem).

Also, I know that we haven’t looked at the base address for all the .NET assemblies in our solution, is it necessary for .NET assemblies to do so? And if so, are there some guidelines available on how to determine these addresses?

Any insight into this area would be most welcome, even if it turns out that this is not a big problem, or not even a problem at all.

Edit: Just found this question: .NET assemblies and DLL rebasing which partially answers my question, but I’d still like to know how JITted code factors into all of this.

It appears from that question and its accepted answer that the JITted code is placed on a heap, which means that each process will load up the shared binary assembly image, and produce a private JITted copy of the code inside its own memory space.

Is there any way for us to measure this? If this turns out to produce a lot of code, we’d have to look at the generated code more to figure out if we need to adjust it.

Edit: Added a shorter list of questions here:

  1. Is there any point in making sure base addresses of .NET assemblies are unique and non-overlapping to avoid rebasing a dll that will mostly be used to just get IL code out of for JITting?
  2. How can I measure how much memory is used for JITted code to figure out if this is really a problem or not?

The answer by @Brian Rasmussen here indicates that JITting will produce per-process copies of JITted code, as I expected, but that rebasing the assemblies will actually have an effect in regards of reduced memory usage. I will have to dig into the WinDbg+SoS tools he mentions, something I’ve had on my list for a while but now I suspect I can’t put it off any longer 🙂

Edit: Some links I’ve found on the subject:

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. This is for question 1)

    The jitted code is placed on a special heap. You can inspect this heap using the !eeheap command in WinDbg + SoS. Thus every process will have its own copy of the jitted code. The command will also show you the total size of the code heap.

    Let me know if you want additional details on getting this information from WinDbg.

    This is for question 2)

    According to the book Expert .NET 2.0 IL Assembly the .reloc part of a pure-IL PE file contains only one fixup entry for the CLR startup stub. So the amount of fixups needed for a managed DLL during rebasing is fairly limited.

    However, if you list any given managed process, you’ll notice that Microsoft has rebased the bulk (or maybe all) of their managed DLLs. Whether that should be viewed as an reason for rebasing or not is up to you.

    • 0