The term for these 'levels' is generations. In fact there are 3 generations, numbered 0, 1, and 2. Objects in generation zero are those which were allocated after the most recent garbage collection to have completed.
What you say is true - objects that are in generation 0 that are still in use at the time a GC happens get promoted to generation 1. And even if they subsequently fall out of use, the memory won't necessarily be reclaimed at the next garbage collect. The system only bothers to collect objects from generation 1 relatively infrequently. (It depends on the memory usage characteristics of the application, but it would be fairly common to only see 1 generation 1 collection for every 10 generation 0 collections.) If a generation 1 collection happens, any objects that were already in generation 1 and are still in use get promoted to generation 2. Generation 2 collections happen even less often. So if your object is still in use when the first garbage collection happens, expect to wait for something on the order of 10 GCs to occur between the object falling out of use and the memory it occupies being reclaimed. And if it survives long enough to make it into generation 2, you might conceivably see as many as 100 garbage collections occurring before the memory is reclaimed. However, having gone through all that I don't think that's what's happening here. I believe that calling System.GC.Collect() forces a full GC, i.e. it collects all three levels now. So I don't think this is the generational GC in action. The thing that I'm not sure about is this: does the memory manager in .NET necessarily return all of the memory collected back to the OS? I'm guessing not, since GCs usually happen as a result of the program needing more memory than was available in the heap. So it needs to keep at least some memory back for itself in order to be able to allocate new objects. I'm just not sure how much it leaves. (Nor do I know what mechanisms it uses to allocate memory - there are lots of different ways to signal your requirements to the OS memory manager that it might use...) -- Ian Griffiths DevelopMentor -----Original Message----- From: Brandon Manchester [mailto:[EMAIL PROTECTED] I may be misstating this so if I am please correct me. There are 2 levels that objects are kept at in regards to garbage collection. The actual name of these "levels" evades me at this moment so I will just refer to them as level 1 and 2. With that said, the first level is where all objects are at until the GC runs. When the GC runs it checks to see if there are any references to the object in question. If there is a reference then it will not destroy and collect the object(s) at that time, what it does it pushes that object to the 2nd level. When object(s) are in the 2nd level the GC does not look at them until memory becomes an issue for other processes. I believe this is what Ian was talking about. Even though you explicitly call the GC this same process takes place. So there is not guarantee as to when an object will be taken out of memory. As I mentioned above I may be mistaken and if so please correct me =) Hope this helps. Brandon -----Original Message----- From: Paulo Jorge F. Sacramento [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 30, 2003 11:01 AM To: [EMAIL PROTECTED] Subject: Re: [ADVANCED-DOTNET] windows service memory footprint I hope that's true. I've had the same problem with my services, which are written in C#. Mine are even worse. I have one that takes up 23 MB. It's using Remoting, AppDomains, Threads, XML, some Reflection also, and other things, but nothing that I'd think would occupy so much memory. The reason I'm not so sure about your explanation is that I've tried explicitly calling the GC (with System.GC() or something like that) and it didn't do much. If what you say is right, wouldn't it be expectable that an explicit call to the GC would release a probably big chunk of memory? By the way, I've also had a case with a much simpler service that occupied about 6 or 7 MB at the beggining of execution, but that after a while would occupy only a few KBs. It was "sleeping" most of the time and did a very rare periodical check. I guess the O.S. together with the GC take care of releasing all unneeded resources. This also suggests that .Net services have an heavy "start-up penalty". Any thoughts on this? Paulo Sacramento On Wed, 30 Jul 2003, Griffiths, Ian wrote: > .NET processes will tend to grow to what looks like an alarmingly > large size unless there is a reason for them to shrink. The CLR does > actually keep track of the amount of memory being used system-wide, > and if other processes start to demand more memory, the CLR will > trigger a garbage collect in your process, reducing the amount of > memory that it is using. > > So the large-looking memory consumption isn't usually an issue. If > anything else in the system starts to need that memory, the CLR will > give it back. > > IDispose doesn't have any bearing on this. IDispose has nothing to do > with memory allocation, it's just about other resources. The fact > that your memory usage stays constant at 18MB indicates that you're > not leaking resources. > > If it was forever creeping upwards, then that would be something to > worry about. But 18MB is fairly normal. > > > -- "We live in a society exquisitely dependent on science and technology, in which hardly anyone knows anything about science and technology." Carl Sagan Notice of Confidentiality: This transmission is intended only for the use of the individual or entity named above. It may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. Further, disclosure of this information may be specifically prohibited under state or Federal law. If you are not the intended recipient, or the employee or agent of the recipient responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
