PDC05: Day Two (C++ Managed Object Model)

I have seen Jim Hogg give presentations in the past and they are always the same: beautiful. He manages to lay out a very complex scenario with startling clarity, leading you step by step to a real understanding of difficult material. The topic at hand today was "C++ Internals: Managed Object Model." A excellent example of this skill is his demonstration of the GC compacting the generation-0 (gen0) heap. He created a small group of temporary objects then a single long-lived object with gcnew. We looked at its location on the GC heap by walking through the handle's double-indirect pointer. and looked at its location on the gc heap. Hogg then created a large group of transient objects on the gen0 heap, which triggered the GC to compact the gc heap. We looked again through the double-indirect pointer and found that though our root pointer was the same, the pointer it pointed to had been relocated.

The next step was what make Hogg's talks so nice. He added a little tiny bit of very informative technical detail. He also told us that researched indicated that a compacting generational GC should collect gen0 frequently, since that is the site of most object lifetime churn, but collect gens1-N much less often. Addding a finalizer to your object automatically promotes it to gen1, so this leads it to collect far less often.

There was a great question about the difference between "R r;" and "R^ r;" where R is always a managed type. It turns out that since managed types are always handled as double-indirect pointers, it follows that "R^ r;" == "R r;" with the "^" being largely a notational convenience for the developer. At a core level there are really two notations:

• R ^ r - a pointer-style managed handle, it can be NULL and can be reassigned.
• R% r - a reference-style managed handle, it cannot be NULL and cannot be reassigned.

The C++/CLR replaces the common C++ lexical packing design with a more space-efficient packing design. In a single object the CLR will pack "fields" (also know as data members) from largest to smallest so that small members will live together inside 4-byte alignments. The CLR goes one step further and will look at an derived objects fields and pack them efficiently with those of the base class. A future CLR may likely change this by analyzing the code paths and packing hot, frequently used, fields together and placing cold, infrequently used, fields elsewhere.

The implementation of stub based dispatch (SVTM from Lippman's talk)