This is a side effect of the CLR, creating an assembly view of the assembly for mapping the memory card into memory. Memory mapped files are a low-level feature in Windows, also mapped in .NET 4.0 with the MemoryMappedFile class. Otherwise, this is a common function in a virtual memory operating system with a query on demand, such as Windows.
MMFs have many desirable properties. The act of “loading” the assembly becomes very simple and very fast. Actually nothing is read from the file, this happens in a lazy way. Each byte in the file has a corresponding memory address. When the CLR tries to read a byte in the assembly metadata or IL for the first time, the processor disables the page error because the page is not available in RAM. The operating system processes it by dynamically reading the contents of the file from disk. The CLR continues as if nothing is happening, it is not fully aware of what happened.
Such lazy access is great, you do not pay for what you do not use. Therefore, if you need one method from one type, for example, in a large assembly such as Microsoft.VisualBasic.dll, then you only pay for this method. Your program never reads metadata of other types or IL of other methods.
There are more. You also do not pay to commit the memory. If another process on the machine needs RAM, then pages containing assembly data can simply be discarded. Since they can simply be reloaded from the file. They do not need to back up the swap file, a cheap virtual memory that you can buy.
There are more. The fact that the collection data always needs to be reloaded from the file at any given time also means that there can never be rights so that anyone can modify the file. Since this will lead to inconsistency of the data in RAM with the data in the file. And for this, a random change from the point of view of the CLR, because it can not observe page errors. Thus, MMF places a hard file in a file, no one can do it. This is a free anti-malware feature.
There are more. A lock guarantee also means that the CLR will never deal with encoded code that no longer matches the IL in the assembly. Something that would be extremely difficult to implement, since random changes in the assembly are almost impossible for proper synchronization with code execution. And that would be terribly expensive, method calls couldn't be simple CALL instructions. And this is not limited to code; the delegate object assignment method must be dynamically enabled. Very large Persian killers. Otherwise, the problem is resolved, so the CLR supports the concept of AppDomain. Unloading appdomain destroys everything, code and data. A fundamental technique for creating shadow copies used in high-availability applications such as ASP.NET
Hans passant
source share