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.
