|
|
You're in the
dotnet compact framework
group:Garbage collector behavior
dotnet compact framework:
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 [quoted text, click to view] On Jul 30, 5:14 pm, Vinz <V...@discussions.microsoft.com> 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). [quoted text, click to view] "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 <V...@discussions.microsoft.com> 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 [quoted text, click to view] "Vinz" <Vinz@discussions.microsoft.com> 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? [quoted text, click to view] "<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" <Vinz@discussions.microsoft.com> 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 [quoted text, click to view] "Vinz" <Vinz@discussions.microsoft.com> 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" <Vinz@discussions.microsoft.com> 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, >> > >> > >> > >> >> >>
[quoted text, click to view]
On 31 Jul, 13:24, Vinz <V...@discussions.microsoft.com> 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 <V...@discussions.microsoft.com> 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 [quoted text, click to view] <waynew15@yahoo.co.uk> wrote in message news:1186083667.398987.136600@d30g2000prg.googlegroups.com... > On 31 Jul, 13:24, Vinz <V...@discussions.microsoft.com> 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 <V...@discussions.microsoft.com> 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. >
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |