A C#-Unmanaged DLL Memory Challenge
Greetings.
I am using a graphics toolkit (Altia Design) that creates a group of C source files that are compiled into a DLL. For the current project, the main codebase is in C#. We've completed all the necessary work to get the DLL into C# (DllImport etc.) and that works well. The project runs in the .NET CLR on Windows CE 5.0.
The challenge we now have is that the DLL is running out of memory. When the DLL gets to a certain point and tries to allocate more memory to store a graphic, the allocation fails. Trying to solve the issue on the Altia side has not worked yet (HeapCreate(), HeapAlloc() and so on). Is there a way to tell the CLR to allow this DLL to have more memory?
Thanx.
---Ritch
答案
I wouldn't completely rule out .NET as it is eating up some of the memory. But I would first determine why the unmanaged code is failing using regular techniques. Once you've figured that out you can start to determine whether it is because .NET is eating up too much memory, marshaling is going on or whatnot.
Remember that marshaling almost always involves allocation of memory in both spaces so any place you might be doing marshaling you need to make sure it is being cleaned up. For example if you were to call Marshal.AllocHGlobal in C# 100 times it will allocate unmanaged memory (and hence affect the unmanaged heap). However allocating an array of 100 objects in .NET will not impact the unmanaged memory heap (other than what the managed heap takes). A grep would help identify these potential issues.
Michael Taylor - 2/25/08
全部回复
.NET has no control over unmanaged memory. .NET allocates its own, separate set of memory. There is no memory sharing between managed and unmanaged code. All memory transitions have to be marshalled. That is what the Marshal class is for. Therefore if you're running out of memory in the DLL then it is no different than running out of memory in native code. You have either used up all your available memory or the heap is fragmented too much. You'll need to figure out why you are running out of memory. Examining the memory you have remaining and comparing to the amount of memory you need will help identify memory fragmentation.
Michael Taylor - 2/25/08
Excellent.
I could not find any information in the library that indicated .NET was somehow "allocating" memory to unmanaged code; but wanted to check that. I know that Marshalling is necessary when the two memory spaces have to pass/share information but that is not the case here. So we shall continue working on the C side of the house as a normal debugging exercise. And ignore what .NET is doing, correct?
Thanx.
---Ritch
I wouldn't completely rule out .NET as it is eating up some of the memory. But I would first determine why the unmanaged code is failing using regular techniques. Once you've figured that out you can start to determine whether it is because .NET is eating up too much memory, marshaling is going on or whatnot.
Remember that marshaling almost always involves allocation of memory in both spaces so any place you might be doing marshaling you need to make sure it is being cleaned up. For example if you were to call Marshal.AllocHGlobal in C# 100 times it will allocate unmanaged memory (and hence affect the unmanaged heap). However allocating an array of 100 objects in .NET will not impact the unmanaged memory heap (other than what the managed heap takes). A grep would help identify these potential issues.
Michael Taylor - 2/25/08
