Memory Lifetime in Interop

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Doug Semler (doug_semler_at_REMOVEMEwideopenwest.com)
Date: 03/07/04 

Date: Sun, 7 Mar 2004 10:18:21 -0500

I have a question about memory lifetimes with interop, and cannot seem to
find a definitive answer to the following problem:

We have a .NET assembly which we expose to COM. The implementation details
are irrelevent. The Results structure is a blittable structure. It is
important to know that the size of the results structure is only known to
the .NET object, and it is only known at RUNTIME.

   void GetResults(int ID, out Results[] results)
   {
       ...
       results = new Results[dynamic_value];
       ...
   }

When creating a type library for COM, as expected, a signature similar to
this is emitted:

   ...
   void GetResults([in] int, [out] SAFEARRAY(Results)** results);

When using the code from a COM client the code works as expected; in other
words the client can access the array values properly.

My questions are regarding lifetime of the returned array. From watching
the memory heap, if I set dynamic_value in the .NET code to be a rather
large value (so it allocates say a 128 Megabyte array), the memory allocated
is 256 megabytes. This is seeming to imply that there are actually two
copies of the array created, one on the managed side (which is marked for
garbage collection when the function returns control to the client) and one
on the COM side into which the data from the managed side is copied. Is
this the case? Or are these shared copies and I am being fooled? If they
are not shared copies, what must the client call to free the memory to
prevent a leak? CoTaskMemFree (which seems to be the marshaller's
allocation routines, from what I read), or should it (in this case) have to
use SafeArrayDestroy(), which will release the objects in the array? 

-- 
Doug Semler
http://home.wideopenwest.com/~doug_semler
a.a. #705, BAAWA.  EAC Guardian of the Horn of the IPU (pbuhh).
I hate spam, standard email address munging applied.
42
DNRC o-
Gur Hfrarg unf orpbzr fb shyy bs penc gurfr qnlf, uneqyl nalbar rira
erpbtavmrf fvzcyr guvatf yvxr ebg13 nalzber. Fnq, vfa'g vg?

Relevant Pages

  • Re: Memory Lifetime in Interop
    ... large value (so it allocates say a 128 Megabyte array), the memory allocated ... garbage collection when the function returns control to the client) and one ... From watching> the memory heap, if I set dynamic_value in the .NET code to be a rather> large value (so it allocates say a 128 Megabyte array), the memory> allocated ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Fast string operations
    ... Looping: I thought looping over arrays in managed code was "slow" ... array handling and such. ... The problem with TrimHelper is that it always returns a new string instance. ... The customer perceives this as a memory leak. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: High Memory Consumption of Classes and Arrays
    ... Only the array itself has overhead. ... memory as a reference type. ... > least consume 40 bytes of memory. ...
    (microsoft.public.dotnet.framework.performance)
  • Re: Fast linked list
    ... > amounts of memory rather than huge chunks of it. ... random insertions into a vector/dynamic array are not as slow ... to cause a cache miss. ... some hard numbers on speed differences between lists and arrays. ...
    (microsoft.public.vc.mfc)
  • Re: Fast linked list
    ... > amounts of memory rather than huge chunks of it. ... random insertions into a vector/dynamic array are not as slow ... to cause a cache miss. ... some hard numbers on speed differences between lists and arrays. ...
    (microsoft.public.vc.language)