I have created dll in C# 3.5 which does some memory intensive matrix calculations where matrices get created and disposed a lot. Everything works fine if dll is called from .Net app but if it is called from C++ created app memory usage just climbs until the function that uses matrices is done. I guess there is a problem with a automatic garbage collection.
views:
182answers:
2
+5
A:
Most probably you are not 'Release'ing the references to the .Net object wrappers from your unmanaged app. The GC cannot collect that memory unless all references (including external ones) are released.
logicnp
2009-10-11 12:25:04
I don't get it, those new objects were created as local variables! Why are they still in the memory after the function is done? Btw, when I explicitly call .Dispose() on biggest memory hogs situation gets a lot better.
Domagoj Peharda
2009-10-12 09:08:26
The local variables may be containing references to unmanaged objects which are only released when Dispose is called or when the GC kicks in (assuming you are using the standard Dispose pattern).
logicnp
2009-10-12 11:37:21
A:
Expanding on logicnp's answer.
The CLR can only garbage collect memory that is allocated and owned by managed code. It has no view or understanding of unmanaged memory. In the case of C++ calling a .Net DLL via COM interop you have a mix of managed and unmanaged memory. Additionally you have C++ objects which are keeping managed objects alive (via COM pointers and CCW's).
The CLR will free up the managed objects properly but only when no references to them exist anymore. When C++ accesses a managed object it creates a CCW under the hood which is kept alive by the native C++ COM interface pointer. Until the ref count on that pointer reaches 0 via calls to Release and Add it will keep the CCW alive and hence the underlying managed object.
Try wrapping all of the places in C++ where you access your managed object with a CComPtr and seeing if this takes care of your problem.
JaredPar
2009-10-11 14:29:01