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,

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


On Jul 30, 5:14 pm, Vinz  wrote:

> 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,

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).

"chris-s@mailcity.com" wrote:


> 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
> 
> 
> On Jul 30, 5:14 pm, Vinz  wrote:
> > 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,
> 
> 
> 

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/WebCastEventDetails.aspx?culture=en-US&EventID=1032318791&CountryCode=US


-- 

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


"Vinz"  wrote in message 
news:551899E7-E88B-45A5-8AC2-6EA31F173B73@microsoft.com...

> 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,
>
>
> 

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?



"<ctacke/>" wrote:


> 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/WebCastEventDetails.aspx?culture=en-US&EventID=1032318791&CountryCode=US
> 
> 
> -- 
> 
> Chris Tacke, Embedded MVP
> OpenNETCF Consulting
> Managed Code in an Embedded World
> www.OpenNETCF.com
> 
> 
> "Vinz"  wrote in message 
> news:551899E7-E88B-45A5-8AC2-6EA31F173B73@microsoft.com...
> > 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,
> >
> >
> > 
> 
> 
> 

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




"Vinz"  wrote in message 
news:27647BE8-4B0F-4FEE-B576-5752E0D1B71F@microsoft.com...

> 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?
>
>
>
> "<ctacke/>" wrote:
>
>> 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/WebCastEventDetails.aspx?culture=en-US&EventID=1032318791&CountryCode=US
>>
>>
>> -- 
>>
>> Chris Tacke, Embedded MVP
>> OpenNETCF Consulting
>> Managed Code in an Embedded World
>> www.OpenNETCF.com
>>
>>
>> "Vinz"  wrote in message
>> news:551899E7-E88B-45A5-8AC2-6EA31F173B73@microsoft.com...
>> > 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,
>> >
>> >
>> >
>>
>>
>> 

On 31 Jul, 13:24, Vinz  wrote:

> 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).
>
>
>
> "chri...@mailcity.com" wrote:
> > 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
>
> > On Jul 30, 5:14 pm, Vinz  wrote:
> > > 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,- Hide quoted text -
>
> - 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.

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

 wrote in message 
news:1186083667.398987.136600@d30g2000prg.googlegroups.com...

> On 31 Jul, 13:24, Vinz  wrote:
>> 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).
>>
>>
>>
>> "chri...@mailcity.com" wrote:
>> > 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
>>
>> > On Jul 30, 5:14 pm, Vinz  wrote:
>> > > 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,- Hide quoted text -
>>
>> - 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.
>