什么是[ DllImport (“ QCall”)] ?

中的许多方法。网络库是用本机代码实现的。那些来自框架本身的标记为 [MethodImpl(MethodImplOptions.InternalCall)]。那些来自某些非托管 DLL 的文件用 [DllImport]标记(例如 [DllImport("kernel32.dll")])。目前为止没什么异常。

但是在编写 回答另一个问题时,我发现有许多方法使用 [DllImport("QCall")]标记。他们似乎是内部执行。净值(例如 GC._Collect())。

我的问题是: [DllImport("QCall")]到底是什么意思? [DllImport("QCall")][MethodImpl(MethodImplOptions.InternalCall)]的区别是什么?

8224 次浏览

I asked some people in the .Net team about this.

QCalls are calls to native methods within the CLR runtime. They behave like other [DllImport]s, but they're faster because they make specific (undocumented) assumptions about what the native methods do, so they can skip various marshalling and GC and exception checks.

InternalCall is different; it's for calls for special reflection-style things which are generated at runtime (this wasn't very clear).

Supplementing @SLaks answer, MethodImplOptions.InternalCall is described briefly here: ThreadPoolPriority, and MethodImplAttribute.

Basically InternalCall tells the runtime to go check its own internal lookup table of named functions. That table exists due to a source file in the runtime code explicitly declaring them when the runtime is compiled. It has a list of function pointers for implementing all internal calls:

static ECFunc gGuidFuncs[] = { {FCFuncElement("CompleteGuid", NULL, (LPVOID)GuidNative::CompleteGuid)}, {NULL, NULL, NULL} };

This declaration tells the runtime that the method body for the managed Guid.CompleteGuid method is actually the native C++ GuidNative::CompleteGuid function. The article isn't very clear on how marshaling works in this place, but in general that's clearly up to the runtime implementation, since it both a) declares the function body [which depends on the marshaling format] and b) does any required marshaling.

This is an old thread. Since CoreCLR is now open-sourced on GitHub; if someone is still seeking the answer, here is the official documentation:

Calling from managed to native code

We have two techniques for calling into the CLR from managed code. FCall allows you to call directly into the CLR code, and provides a lot of flexibility in terms of manipulating objects, though it is easy to cause GC holes by not tracking object references correctly. QCall allows you to call into the CLR via the P/Invoke, and is much harder to accidentally mis-use than FCall. FCalls are identified in managed code as extern methods with the MethodImplOptions.InternalCall bit set. QCalls are static extern methods that look like regular P/Invokes, but to a library called "QCall".

There is a small variant of FCall called HCall (for Helper call) for implementing JIT helpers, for doing things like accessing multi-dimensional array elements, range checks, etc. The only difference between HCall and FCall is that HCall methods won't show up in an exception stack trace.

And then it continues in subheadings:

with examples: