I would have just commented on leppie's post, but it was getting a bit long.
I'm currently working on an experimental CLI implementation. There are many cases where a publicly exposed method (or property) can't be implemented without knowledge of how the virtual machine is implemented internally. One example is OffsetToStringData, which requires knowledge of how the memory manager allocates strings.
For cases like this, where there is no C# code to express the method, you can treat each call to the method in a special way internal to the JIT process. As an example here, replacing the call
byte code with a ldc.i4
(load constant integer) before passing it to the native code generator. The InternalCall
flag means "The body of this method is treated in a special way by the runtime itself." There may or may not be an actual implementation - in several cases in my code the call is treated as an intrinsic by the JIT.
There are other cases where the JIT may have special information available that allows heavy optimization of a method. One example is the Math
methods, where even though these can be implemented in C#, specifying InternalCall
to make them effectively intrinsics has significant performance benefits.
In C#, a method has to have a body unless it is abstract
or extern
. The extern
means a general "You can call this method from C# code, but the body of it is actually defined elsewhere.". When the JIT reaches a call to an extern
method, it looks up where to find the body and behaves in different ways per the result.
- The
DllImport
attribute instructs the JIT to make a P/Invoke stub to call a native code implementation.
- The
InternalCall
flag instructs the JIT to treat the call in a self-defined way.
- (There are some others, but I don't have examples off the top of my head for their use.)
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…