Garbage collector behavior

[Guest]

Hi,

I've seen a strange behavior with a C# application on Windows CE 5.0. As you
probably already know, in Windows CE 5.0 we only have 32 MB of memory. I
create multiple instance of a really big object (1 MB of Data). My free
virtual memory for the process after all these allocations is 12 MB. Then the
destructor is called for each instance of the object. I supose that it means
that the memory is freed. I should now have approximatly 30 MB of free
virtual memory for the process but I only have 12 MB.

What is the problem here? It seams that when managed code temporarly needs
more memory, it never gives that memory back to the OS. Am I right? I also
seen a lot of 64 kB commit in the memory map, does it means that when the
managed heap is full it asks for a 64 kb block to the OS?

Where can I find more information on how the memory management is done for a
manged program under Windows CE 5.0?

Thanks a lot for your help,

 

[chris-s]

As I've always understood it, just because the destructor is called,
this does not force the GC to run, it will not run until the system
deems it either necessary or some other criteria is met. Running the
GC is an intensive operation and so it is avoided unless required to
maintain performance. Whilst you can force the GC to run, it is not
recommended to do so, and assuming your app is not running out of
memory then you should just have faith and leave it do it's own
thing

Chris

 

[Guest]

In fact the application doesn't run out of memeory but this is not the real
application we use. It's only a test application to verify the garbage
collector behavior. The real application uses a lot of big DLLS and leaves
around 5 MB of virtual memory for the process heap and thread stacks. It
means that if I use more than that 5MB I run out of memory. But the real
problem is that if the managed code needs around 4 MB for a short period of
time it doesn't gives back that memory to the OS leaving the native code out
of memory. I also tried the same code under Windows XP and the behavior is
the same, the memory is never gived back to the OS. I know that there is a
function named AddMemoryPressure in the GC but it's not accessible in the
compact framework (remember that we use Windoews CE 5.0).

 

[Guest]

The finalizer running has no direct relevence on the available system
memory. GC Collection is where any actual actiuon might (or might not)
occurr.

See this WebCast:

http://msevents.microsoft.com/CUI/W...lture=en-US&EventID=1032318791&CountryCode=US


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

 

[Guest]

Thanks a lot Chris,

From what I understand, if a finalizer is defined, when the object is not
used anymore (=null or out of scope) at the next collection the finaliser is
added to the list of finaliser to execute, then when the finaliser is done,
the next collection will free the object from the managed heap. So it
actually need more than one collection to free it from the managed heap.

If there is no finaliser the object is removed from the managed heap at the
next collection.

What I'm not sure is when do the managed heap shrink? What I understand is
that EACH time the collection ends if there is more than 750k of free memory
in the managed heap there is a compaction. Then after each compaction, if
there is more thant 1 MB of free memory in the heap, the virtal memory is
given back to the OS by blocks of 1 MB.

Of course you can correct me if I'm wrong. Is this also the behavior of the
..NET framework or is it only for .NET CF?

 

[Guest]

Your understanding is accurate. No idea if that's how the desktop framework
works - I've not researched it nearly as much as I have the CF.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com

 

[waynew15]

In fact the application doesn't run out of memeory but this is not the real
application we use. It's only a test application to verify the garbage
collector behavior. The real application uses a lot of big DLLS and leaves
around 5 MB of virtual memory for the process heap and thread stacks. It
means that if I use more than that 5MB I run out of memory. But the real
problem is that if the managed code needs around 4 MB for a short period of
time it doesn't gives back that memory to the OS leaving the native code out
of memory. I also tried the same code under Windows XP and the behavior is
the same, the memory is never gived back to the OS. I know that there is a
function named AddMemoryPressure in the GC but it's not accessible in the
compact framework (remember that we use Windoews CE 5.0).





- Show quoted text -

great thread. I am embarking on a similiar project where i may need to
use large amounts of data.
Being relatively new to the .NetCF world, I have found it frustrating
to learn that my applications are limited to a 32MB virtual memory
space, I am now wondering why i bothered arguing for that 128MB RAM on
the target device.
My point to all this is - is there a way of harnessing the other 32MB
allocations (for the other potential processes) to use in conjunction
with my app?
Also, if that is not possible, is it possible to create a separate
application to run alongside my main app which handles a certain part
of the processing (e.g. UI updates), whilst the other app (in another
32MB 'slot') is processing the data? (thus splitting out the uncommon
DLLs etc). - how would the two apps communicate?

thanks.

 

[Guest]

Yes, 128MB of RAM on a CE 5.0 and earlier device provides low benefit yield
over 64MB in many cases (though in some cases it helps, such as when an app
makes large shared memory allocations like with video rendering).

There is no way to use another process' space except by creating another
process. You could communicate in a variety of ways, depending largely on
the complexity data you're transferring. I typically use a point to point
message queue (P2PMessageQueue class in the Smart Device Framework[1]) but
MessageWindows, MemoryMappedFiles and even plain old named events work.


--

Chris Tacke, Embedded MVP
OpenNETCF Consulting
Managed Code in an Embedded World
www.OpenNETCF.com



[1] www.SmartDeviceFramework.com