What is the difference between managed heap and native heap in c# application

Question

From this http://blogs.msdn.com/b/visualstudioalm/archive/2014/04/02/diagnosing-memory-issues-with-the-new-memory-usage-tool-in-visual-studio.aspx

1. Managed: For managed applications, the profiler only collects managed heap information by default. Managed heap profiling is done by capturing a set of CLR ETW events in the profiler.
2. Native: For native applications, the profiler only collects native heap information. For collecting native heap information, we enable stack tracing and the collection of heap traces (ETW) which are very verbose and will create large diagsession files.

My question is In my c# program (I only have c# code with xaml files) what kinds of object will goes to managed heap and what kinds goes to native heap? And how can I specify the max size of each heap when my application runs? I assume GC only runs on managed heap, is that correctly?

Answer 1

When you create an object using the new operator in C# (or the corresponding operator in any other CLR language), the .NET runtime allocates memory in the "managed heap" (simply a heap managed by the .NET runtime + the garbage collector). This is, in reality, one of two heaps - one meant for objects less then 85K in size and the other for objects larger than this (large arrays and the like). Either way, when such an object is allocated, you don't get back a real pointer describing the address of the allocated space like you would in native code. What you do get back is a "handle", which represents an indirection to that memory address. This indirection exists because the actual memory location may change when the GC collects and compacts the heap.

When you want to talk to unmanaged/native code that expects a pointer, however, you need to use pointers, not handles. .NET provides two methods to convert a .NET handle to a raw pointer that can be passed in to unmanaged code.

1. Allocate memory on the NT (or native or unmanaged) heap using Marshal.AllocHGlobal or Marshal.AllocCoTaskMem and use either a fixed block or IntPtr.ToInt32/ToInt64 to get the underlying pointer. Be sure that you either call Marshal.FreeHGlobal/Marshal.FreeCoTaskMem yourself or that the unmanaged code frees the memory correctly (FreeAlloc/CoTaskMemFree on Windows).
2. If your data is blittable (which is probably the case when interoperating with native code), then you can simply pin this managed data with GCHandle.Alloc and then call into native code with the raw pointer obtained from GCHandle.AddrOfPinnedObject, releasing the pinning (using GCHandle.Free) when done. You can also get the actual underlying pointer address of a managed object and temporarily pin in inside a "fixed" block in C#.

I hope this helps!