SSCLI中GC源码分析(1) - EE与BCL之间的调用接口FCall

首先在SSCLI2.0源代码的/clr/src/vm/comutilnative.cpp文件中的GCInterface类的CollectGeneration方法上下个断点，该宏方法主要实现了一个调用转换：

/*==============================CollectGeneration===============================
**Action: Collects all generations <= args->generation
**Returns: void
**Arguments: args->generation:  The maximum generation to collect
**Exceptions: Argument exception if args->generation is < 0 or > GetMaxGeneration();
==============================================================================*/
FCIMPL1(void, GCInterface::CollectGeneration, INT32 generation)
{
    CONTRACTL
    {
        MODE_COOPERATIVE;
        DISABLED(GC_TRIGGERS);  // can't use this in an FCALL because we're in forbid gc mode until we setup a H_M_F.
        THROWS;
        SO_TOLERANT;
    }
    CONTRACTL_END;

    //We've already checked this in GC.cs, so we'll just assert it here.
    _ASSERTE(generation >= -1);

    //We don't need to check the top end because the GC will take care of that.
    HELPER_METHOD_FRAME_BEGIN_0();

    GCHeap::GetGCHeap()->GarbageCollect(generation);

    if (g_TrapReturningThreads)
    {
        GetThread()->PulseGCMode();
    }
    HELPER_METHOD_FRAME_END();
}
FCIMPLEND

这个方法提供了从BCL中调用SSCLI虚拟执行引擎内部功能的一个接口。在SSCLI实现版本中，这种调用转换的方式叫做FCall。

在不会被JIT的代码中，譬如一些Helper代码片段或者stubs中，经常会使用一些调用转换来协调不同功能的组件。这样在Runtime中，就不会出现是一个非常大的、包含了所有功能的Heap。

使用这种非常有效的调用转换，可以让托管高级语言，譬如C#，在用户代码中调用Runtime中的内部功能。使用这种调用，只需要给实现的方法加上MethodImplOptions.InternalCall的属性即可。

而FCall会使用sscli20/clr/src/vm/ecall.cpp中的ECFunc结构体，来完成从托管方法到Runtime内部实现的C++方法的转换：

struct ECFunc {
    UINT_PTR            m_dwFlags;

#ifndef DACCESS_COMPILE
    LPVOID              m_pImplementation;
#else
    TADDR               m_pImplementation;
#endif
    PTR_MethodDesc      m_pMD;               // for reverse mapping

    PTR_ECFunc          m_pNext;             // linked list for hash table

    LPCUTF8             m_wszMethodName;
    LPHARDCODEDMETASIG  m_wszMethodSig;      // Optional field. It is valid only if HasSignature() is set.

    bool                IsEndOfArray()  { LEAF_CONTRACT; return !!(m_dwFlags & FCFuncFlag_EndOfArray); }
    bool                HasSignature()  { LEAF_CONTRACT; return !!(m_dwFlags & FCFuncFlag_HasSignature); }
    bool                IsUnreferenced(){ LEAF_CONTRACT; return !!(m_dwFlags & FCFuncFlag_Unreferenced); }
    CorInfoIntrinsics   IntrinsicID()   { LEAF_CONTRACT; return (CorInfoIntrinsics)((INT8)(m_dwFlags >> 16)); }
    int                 DynamicID()     { LEAF_CONTRACT; return (int)              ((INT8)(m_dwFlags >> 24)); }

    ECFunc*             NextInArray()
    { 
        LEAF_CONTRACT; 
        
        return (ECFunc*)((BYTE*)this + 
            (HasSignature() ? sizeof(ECFunc) : offsetof(ECFunc, m_wszMethodSig)));
    }
};

m_wszMethodName表示的是BCL中对应的方法。m_pImplementation表示的是Runtime中对应的方法。可以看到，在这种转换中，不涉及到任何关于参数传递或者是类型检查之类的逻辑，因为FCall调用的方法，完全是Runtime内部实现的。

在Method.cpp文件中的MethodClassification枚举类型中，还列出了其他SSCLI执行引擎中对Method分类的：

// Used in MethodDesc
enum MethodClassification
{
    mcIL        = 0, // IL
    mcFCall     = 1, // FCall (also includes tlbimped ctor, Delegate ctor)
    mcNDirect   = 2, // N/Direct
    mcEEImpl    = 3, // special method; implementation provided by EE (like Delegate Invoke)
    mcArray     = 4, // Array ECall
    mcInstantiated = 5, // Instantiated generic methods, including descriptors
                        // for both shared and unshared code (see InstantiatedMethodDesc)

    mcDynamic       = 7, // for method dewsc with no metadata behind
    mcCount,
};

在SSCLI的对象内存布局中，由于MethodDesc结构是几个不同的类型的聚合体，所以这里使用一个三个bit位的flag来表示MethodDesc是使用的那种类型。在MethodClassfication中，并不表示方法是JITed或者是NON-JITed。因为是否被JIT过，只有在方法第一次被执行的时候才能够知道。同时，由于托管进程中的线程都需要修改这三个BIT位，所以这个标识被放在可以被线程同步范围的内存地址上。

MethodClassification这个结构会在MethodDesc中被使用到，来标识一个Method类型。同时，MethodDesc中有一个16bit的flag(MethodClassification)来表示一个MethodDesc所有的属性。可以参考前面章节中关于MethodDesc的介绍。

这里，还有一点需要注意的是，在调用GCHeap类中的GarbageCollect方法之前，下面的代码会在Stack中安装一个栈帧：

//We don't need to check the top end because the GC will take care of that.
HELPER_METHOD_FRAME_BEGIN_0();

GCHeap::GetGCHeap()->GarbageCollect(generation);

if (g_TrapReturningThreads)
{
    GetThread()->PulseGCMode();
}
HELPER_METHOD_FRAME_END();

在上面的方法中，HELPER_METHOD_FRAME_BEGIN_0()方法HELPER_METHOD_FRAME_END()成对使用，用来在GCHeap中放置HelperMethodFrame栈帧。这个栈帧的主要功能，是允许加入Jit Helper或者是标识FCall的相关信息到栈中，来方便程序对Stack的遍历。下面是这个Frame的构造函数：

// Lazy initialization of HelperMethodFrame.  Need to
// call InsureInit to complete initialization
// If this is an FCall, the second param is the entry point for the FCALL.
// The MethodDesc will be looked up form this (lazily), and this method
// will be used in stack reporting, if this is not an FCall pass a 0
HelperMethodFrame(void* fCallFtnEntry, struct LazyMachState* ms, unsigned attribs = 0)
{
    WRAPPER_CONTRACT;
     INDEBUG(memset(&m_Attribs, 0xCC, sizeof(HelperMethodFrame) - offsetof(HelperMethodFrame, m_Attribs));)
     m_Attribs = attribs;
     LazyInit(fCallFtnEntry, ms);
}

顺便提一下，这个地方使用了Lazy initialization技术，Lazy initialization是一种延迟初始化对象的策略，譬如说计算一个值，或者是一个Process的计算代价比较昂贵而且也不是经常使用的情况下，就在第一次使用的时候初始化。实现的方式，主要是用一个Flag来标识这个过程是否已经开始。这也算是一种设计模式。可以在Wikipedia找到关于这个技术的比较详细的说明：

http://en.wikipedia.org/wiki/Lazy_initialization

最后，在comutilnative.cpp文件中，还是实现了许多其他的BCL和Runtime之间调用的类和方法，主要包括一下类: