Hi, Barry Bond wrote:
> Pinned objects fall into two categories. First, all arguments passed > via P/Invoke (also called NDirect) are implicitly pinned. Second, > objects can be explicitly allocated as pinned via the managed > System.Runtime.InteropServices.GCHandle.Alloc(Object, GCHandleType) > method, which adds entries to the objecthandle table. what is an NDirect call? where can i find more info about this Are weak pointers also dealt in the same way ie, are they also formed similarly (via two categories etc..)? > In both cases, > pinning doesn't incur runtime overhead until the GC runs, and the GC > isn't involved with pinning until GCHeap::Promote() is called, with > GC_CALL_PINNED set in its 'flags' parameter. > > In the case of P/Invoke, this is the sequence of events as the stack is > being crawled during a GC and an NDirectMethodFrame is encountered: > gcscan.cpp's GcStackCrawlCallback() calls a pFrame->GcScanRoots. For > P/Invoke, pFrame is an NDirectMethodFrame. > frames.h's NDirectMethodFrame::GcScanRoots() calls > frames.h's FrameMethodFrame::PromoteCallerStackWithPinning() calls > frames.cpp's FramedMethodFrame::PromoteCallerStackWorker() calls > frames.cpp's FrameMethodFrame::PromoteCallerStackHelper() takes an > fPinArgs parameter which is TRUE in this code path. For each object > pointer in a jitted method's stack frame, it calls GCHeap::Promote(..., > GC_CALL_PINNED) > the Promote either copies/marks the object depending on the generation, where does the call for GCHeap::Relocate actually occur for the NDirectMethodFrame? Thank you, archana
