.NET运行时（CLR），JIT编译器到底在哪里？ [英] Where exactly is .NET Runtime (CLR), JIT Compiler located?

问题描述

这个问题可能看起来有些愚蠢或奇怪，但是我听说过很多有关.NET CLR，JIT编译器以及它是如何工作的等等……但是现在我想知道它的确切位置或托管位置。

This question might look a bit foolish or odd but I have heard a lot of about .NET CLR, JIT compiler and how it works blah blah blah... But now I am wondering where exactly it is located or hosted.

是-

• 当我们在Windows操作系统中托管时实际安装了.NET Framework吗？

OR

• 它是某些.exe的一部分，我们可以在任务管理器中看到

我正在寻找有关此问题的详细答案。有人可能将这个问题描述为 Windows操作系统如何在.NET运行时内部触发/执行.NET可执行文件？

I am looking for the detailed answer on this. Someone might frame this question as "How Windows Operating System triggers/executes .NET Executable inside .NET Runtime?

推荐答案

确切位于或托管的位置

where exactly it is located or hosted

这只是一个普通的DLL，您会发现x86版本的它位于C：\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll中。x64版本位于Framework64目录中。.NETv2版本具有不同的名称mscorjit.dll，请查找

It is just a plain DLL, you'll find back the x86 version of it in C:\Windows\Microsoft.NET\Framework\v4.0.30319\clrjit.dll. The x64 version is in the Framework64 directory. The .NET v2 version had a different name, mscorjit.dll, find it back in the v2.0.50727 directories.

它根本不是托管的，操作系统完全不知道它的存在。CLR知道如何查找和定位它。必要时，由CLR决定何时启动程序。它只是简单地将DLL名称硬编码并使用LoadLibrary（ clrjit.dll）进行加载，而GetProcAddress（ getJit）则用于获取该文件。工厂功能，您可以在CoreCLR源代码中看到一些东西，尽管抖动不是单独的DLL anym

It is not "hosted" at all, the operating system is completely unaware that it exists. The CLR knows how to locate and load it. Necessarily so, it is the CLR that decides when to start a program. It simply has the DLL name hard-coded and use LoadLibrary("clrjit.dll") to load it, GetProcAddress("getJit") to get the factory function. Something you can see back in the CoreCLR source code, albeit that the jitter is not a separate DLL anymore in that CLR version.

您也可以看到带有资源管理器的CLR，同样只是一个普通的DLL。在v4版本中为clr.dll，在v2版本中为mscorwks.dll和mscorsvc.dll。那时有两个不同的垃圾回收器，其中有不同的垃圾收集器， wks是工作站版本， svc是服务器版本。与< gcServer> 配置文件条目进行比较。

You can see the CLR with Explorer as well, again just a plain DLL. It is clr.dll in the v4 versions, mscorwks.dll and mscorsvc.dll in the v2 versions. Two different ones back then with different garbage collectors, "wks" is the workstation version, "svc" is the server version. Compare to the <gcServer> config file entry.

问题转移到 CLR如何获得装满了？这就是c：\windows\syswow64\mscoree.dll的工作，当在EXE项目中定位x64时，将使用c：\windows\system32\mscoree.dll。每个.NET程序集都有5或9个字节的非托管代码，可直接跳转到该DLL。 _CorExeMain或_CorDllMain，取决于程序集是作为exe还是作为库构建的。 mscoree.dll会查看程序集中的元数据，并确定需要加载什么版本的CLR，以便可以正确执行该版本。

Which moves the question to "how does the CLR get loaded?" That's the job of c:\windows\syswow64\mscoree.dll, you'll use c:\windows\system32\mscoree.dll when you target x64 in your EXE project. Every .NET assembly has 5 or 9 bytes of unmanaged code, a jump into that DLL. Either _CorExeMain or _CorDllMain, depending on whether the assembly was built as an exe or a library. mscoree.dll takes a look at the metadata in the assembly and decides what version of the CLR needs to loaded so it can be properly executed.

还有很多恶作剧，我刚刚发布了您要求的10,000英尺视图。如果您对此感兴趣，那么您可能想了解有关自定义CLR托管的更多信息看到窗帘后面的那个人。

Lots more shenanigans going on, I just posted the 10,000 feet view you asked for. If this interests you then you probably want to find out more about custom CLR hosting to see the man behind the curtain.

这篇关于.NET运行时（CLR），JIT编译器到底在哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！