C++/CLI and Heap Compaction

I'm currently looking into C++/CLI that is a C++ extension developed by Microsoft which allows for writing managed code with C++ syntax.  Technically this is not an extension since there has been several new key words added to the language and these do not follow the C++ specification of how new keywords should be formatted. There was an attempt at creating a C++ extension, called managed C++, that followed the  guide lines; however the syntax became complicated and ugly and the extension was recreated as the programming language C++/CLI which was designed to produce cleaner and prettier code.

The C++/CLI language can give good insight into what happens within the CLR (Common Language Runtime). C++/CLI also allows for great managed to unmanged (that is code that does not have automatic memory handling) transitions, as well as the other way around. The reason for this is that it allows handling of both native C++ object and types as well as managed .NET objects and types.

There is a lot to write about this subject and hopefully I will produce more blog posts about this topic however in this post I will just talk a bit about the difference in managed and unmanaged objects are handled.

When an object is created in C++ using the new key word memory will be allocated on the heap and a address to the objects location on the heap will be returned. This address is the pointer that the coder must keep track of to use the object and finally call delete on when the object no longer is desired. When delete is called on an object the memory is freed up and can be used by other objects.

Managed object are always added to the managed heap when they are created. When they no longer are used they are collected by the automated GC (Garbage Collector). A big difference between the managed and unmanaged heap is that the managed heap also is compacted. This means that when the GC is running the memory addresses of objects on the heap are moved to create a continuous block of memory. 

Managed Heap Compaction

Doing this reduces the risk of heap fragmentation which can lead to out of memory errors even though there is non allocated memory left on the heap. The problem with this is that since the memory addresses are moved around you can no longer use pointers to keep track of your objects. In the managed C++/CLI (and all languages that use Microsoft's CLR) this is done by Tracking Handles, or handles for short. In most of the .NET languages this is handled behind the scenes but in C++/CLI you have to declare your handle by using a caveat, ^, which is similar to the asterisk, *, used by C++ unmanaged allocations.  The downside is that when the heap is compacting it must update all tracking handles with the new memory addresses of the allocated objects. This is one of the reasons why an unmanaged language such as C or C++ will always have a slight performance advantage over a managed language.  In many cases simplicity in the development process outweighs the need for high performance but selecting the right tool for a job is not a judgment call that should be taken lightly.