Where unmanaged resources are allocated

I am not a comp science guy. Managed resources are allocated on the heap. But I would like to know where unmanaged resources are al开发者_StackOverflow社区located. If unmanaged resources are also allocated on the heap, is it the same heap used by managed resources or a different one?

Thanks in advance.

Harsha

Essentially the heap is the same speaking from the operating system view: the memory space assigned to the OS process.

The difference is that when the CLR (.net VM) loads inside a Windows process it takes a piece of this heap and turns it into a managed heap. This memory space becomes the place where all managed resources are allocated and known to the garbage collector.

For instance, you can run into a Out of Memory error if you allocate a big chunk of unmanaged memory and run out of space for your managed heap. Or the other way around.

Jeffrey Richter is the guy that better explains this stuff. I highly recommend reading his explanation:

• Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework
• Garbage Collection Part 2: Automatic Memory Management in the Microsoft .NET Framework

You can use the services of the System.InteropServices namespace, the Marshal class specifically, to copy data between the unmanaged part of the heap and the managed.

To operate with unmannaged heap use Marshal class described at MSDN

http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal(v=vs.71).aspx

Unmanaged heap doesn't controlled by GC, so all responsibility of memory usage lies on you. Essentially to release memory that allocated for unmanaged resources use IDisposable interface and release all allocated resources by yourself. All unmanaged resources like SQL connections and different IO operations are using this approach.

In memory. Like for any unmanaged process.. THe managed heap obviously is different from the managed one.

The CLR maintains its own heaps. Initially, two are created: one is simply called the managed heap (or small object heap) and the other is the large object heap (see also here). These managed heaps are physically separate from the native heaps allocated by the CRT for use with new and malloc.

You can use VMMap to inspect the different heaps allocated by a process.

To borrow a turn of phrase from a magazine article that compared linear and non-linear filters, a comparison of managed resources and unmanaged resources is like a comparison between kangaroo biology and non-kangaroo-biology.

In .net, managed resources are class objects on the managed heap. Always. It's possible for value types to hold references to managed resources, but a value-type instance cannot itself "be" a managed resource.

By contrast, an unmanaged resource can be just about anything, and can be stored just about anywhere. It need not be on the same computer, or even the same planet, as the program which owns it (I don't know that any of the probes that have been sent to Mars expose any sort of communications-socket interface which would behave as an unmanaged resource, but one could certainly design them to do so).

An object holds an unmanaged resource if some outside entity is doing something on behalf of that object, to the detriment of others, and will keep doing that something until it's told to stop (or, possibly, until it times out). There are many kinds of unmanaged resources, and they can live just about anywhere. Some of them (e.g. locks and event subscriptions) may live entirely within the managed world of .net. Some of them (e.g. server connections) may exist outside the computer that "owns" them at any given moment. Some types of unmanaged resources may encapsulate blocks of memory from the OS, separate from the unmanaged heap, but there is no general place unmanaged resources are "stored". Rather, as noted, unmanaged resources can be just about anything, and can be stored just about anywhere.