I am still fairly new to C++/cli and am not always sure when I am writing something whether I am doing something that creates a transition between managed and unmanaged run times. For instance I cannot add a LARGE_INTEGER or a std::vector as a member of a managed class, but I can use either in the middle of a managed method, but I don’t know whether doing so creates a transition between managed and unmanaged runtimes. How can I see every point at which I am forcing a transition to be made and how can I measure the cost of those transitions?
One possibility that occurs to me is that I expect there is a “transition to unmanaged” and a “transition to managed” block of code in windows. Are there symbols for those I can put breakpoints at, e.g. with windbg so I can see each transition? Is there a way to get visual studio to show you each transition at runtime?
To measure the inpact when there are many transitions, are there corresponding event tracing for windows events that I can see with xperf, or performance counters for them I can see with perfmon?
“Unmanaged runtime” is a bit of an oxymoron. Unmanaged code doesn’t run in a virtual machine. Plus, the managed runtime is itself unmanaged code. I think you’re interested in code in general, not just the CLR and standard libraries, but ultimately everything is native code, some of it was created by the CLR JIT and some of it was created by a native compiler but it’s all native code in the end. There’s even a common exception handling model (SEH) for both .NET and native exceptions (or more precisely, .NET uses the OS-provided exception model).
After the JIT runs, there’s not much sign of managed->unmanaged transitions, since they’re just a simple function call (the debugger can tell the difference because the unmanaged code is in the address space of a native library, and the JIT-compiled managed code is in a dynamic address space owned by the JIT). The reverse direction is slightly more involved, since the call instruction was created before the code it calls, it has to be an indirect call (via function pointer). But it’s still a pointer direct to JIT-compiled code, not to some single unmanaged->managed thunk where you could put a breakpoint. Actually, the function pointer probably starts out pointing to the JIT itself, which figures out what method is being called, compiles it, updates the function pointer, and finally tail-calls to the destination just as if it had been called in the first place.
This is the magic of C++ interop. It also means that managed->unmanaged transitions are really not even worth worrying about. Profile and find out what code paths are expensive, and if it turns out to be a call between managed and unmanaged code, optimize it then. But don’t go randomly looking for managed/unmanaged transitions.
Now, there are other reasons you might want to look for all managed/unmanaged transitions. For example, the garbage collector can interrupt any thread running managed code (again, the code actually running is native code, but the GC can identify it because it’s inside the memory space used by the JIT, and the JIT produced object usage tables detailing what stack variables are reachable objects at any given instruction pointer). So if you want to guarantee that a certain thread is NEVER stopped by the garbage collection, you’d need to hunt down and eliminate all unmanaged->managed transitions in the functions which run in that thread. Breakpoint injection still wouldn’t be the right approach, even if there was a place to put the breakpoint, since that only catches transitions actually taken, not those that are conditional.