Hi,

I know the automatic garbage collection is supposed to be "better" but
having spent my programming life looking after memory myself, I don't like
the fluffiness of it. OK, rant over.

I display a startup form, then overlay another "main run screen" when all
startup actions are complete. As part of that startup I display a bunch of
pretty images, changing on a timer tick event, in the startup screen.

I've cached those images (they're embedded into the EXE) into an array and
then cycle through the images as the startup goes on. Problem is that when I
overlay the main run screen, the memory from these images is never released.

Is there any way I can force C# to give me back the memory? There doesn't
seem to be any "delete" keyword like there is in C++ and its not going to be
simple to convert the code into a "using" clause.

Thanks,
Alain

Hallo,

On 03.02.2012 17:40, Alain Dekker wrote:
> I display a startup form, then overlay another "main run screen" when all
> startup actions are complete. As part of that startup I display a bunch of
> pretty images, changing on a timer tick event, in the startup screen.
>
> I've cached those images (they're embedded into the EXE) into an array and
> then cycle through the images as the startup goes on. Problem is that when I
> overlay the main run screen, the memory from these images is never released.

if you are sure with "never", then your program is buggy. I.e. you
accidentally hold a strong reference to the image objects.

As soon as your clear your cache and do not hold any strong reference to
the images, the items are subject to be discarded by the GC. However, it
might not happen at the time you expect it. The GC has to be triggered
first. More specifically the generation 2 collector has to be invoked,
since cached objects often propagated to generation 2. Depending on the
kind of GC you use, this might not happen unless the memory is required
for something else. The recent .NET runtime has AFAIK 3 different GC
implementations.

> Is there any way I can force C# to give me back the memory?

Yes you can force the CG to run. But it is strongly recommended NOT to
do so. You might easily confuse the GC, resulting in poor performance.
The most critical point is if you invoke the generation 0/1 GC too
frequently. This will force temporary objects to generation 2.

> There doesn't
> seem to be any "delete" keyword like there is in C++ and its not going to be
> simple to convert the code into a "using" clause.

using won't help very much unless you have external resources like open
files, database connections, COM objects or something like that. using
only call Dispose at the end of the block. It does not free any memory.


Marcel

On 2/3/2012 11:40 AM, Alain Dekker wrote:
> I know the automatic garbage collection is supposed to be "better" but
> having spent my programming life looking after memory myself, I don't like
> the fluffiness of it. OK, rant over.

It saves you some work.

So unless you have strong real time requirements it is a convenience.

> I display a startup form, then overlay another "main run screen" when all
> startup actions are complete. As part of that startup I display a bunch of
> pretty images, changing on a timer tick event, in the startup screen.
>
> I've cached those images (they're embedded into the EXE) into an array and
> then cycle through the images as the startup goes on. Problem is that when I
> overlay the main run screen, the memory from these images is never released.
>
> Is there any way I can force C# to give me back the memory? There doesn't
> seem to be any "delete" keyword like there is in C++ and its not going to be
> simple to convert the code into a "using" clause.

First a question: what are you measuring? Are you measuring how much
memory your app has allocated from .NET or how much memory .NET has
allocated from Windows (including unmanaged memory allocated by
your app)?

If it is the second then you do not have a problem. The memory is
available to your app.

If it is the first then you need to figure out where that memory is
going.

One reason could be unmanaged resources used by your app and
not properly disposed.

As an example System.Drawing.Image implements IDispose so
you need to call Dispose either explicit or implicit via
the using statement.

Another reason could be that you still have a reference
to the objects. Example: if you keep the array you mention
above around, then the objects will not be GC'ed.

Arne

On 2/3/2012 1:03 PM, Marcel Müller wrote:
> On 03.02.2012 17:40, Alain Dekker wrote:
>> I display a startup form, then overlay another "main run screen" when all
>> startup actions are complete. As part of that startup I display a
>> bunch of
>> pretty images, changing on a timer tick event, in the startup screen.
>>
>> I've cached those images (they're embedded into the EXE) into an array
>> and
>> then cycle through the images as the startup goes on. Problem is that
>> when I
>> overlay the main run screen, the memory from these images is never
>> released.
>
> if you are sure with "never", then your program is buggy. I.e. you
> accidentally hold a strong reference to the image objects.
>
> As soon as your clear your cache and do not hold any strong reference to
> the images, the items are subject to be discarded by the GC. However, it
> might not happen at the time you expect it. The GC has to be triggered
> first. More specifically the generation 2 collector has to be invoked,
> since cached objects often propagated to generation 2. Depending on the
> kind of GC you use, this might not happen unless the memory is required
> for something else. The recent .NET runtime has AFAIK 3 different GC
> implementations.
>
>> Is there any way I can force C# to give me back the memory?
>
> Yes you can force the CG to run. But it is strongly recommended NOT to
> do so. You might easily confuse the GC, resulting in poor performance.
> The most critical point is if you invoke the generation 0/1 GC too
> frequently. This will force temporary objects to generation 2.
>
>> There doesn't
>> seem to be any "delete" keyword like there is in C++ and its not going
>> to be
>> simple to convert the code into a "using" clause.
>
> using won't help very much unless you have external resources like open
> files, database connections, COM objects or something like that. using
> only call Dispose at the end of the block. It does not free any memory.

It should free all unmanaged memory allocated.

Arne

On 2/3/2012 1:59 PM, Peter Duniho wrote:
> On Fri, 3 Feb 2012 16:40:25 -0000, Alain Dekker wrote:
>> I know the automatic garbage collection is supposed to be "better" but
>> having spent my programming life looking after memory myself, I don't like
>> the fluffiness of it. OK, rant over.
>
> "Fluffiness" being a well-know technical term, of course.
>
> GC isn't uniformly "better" or "worse". It's "different". However, it
> _does_ address a particularly common type of programmer error, with little
> or no performance cost (and in fact in some cases can perform better).
>
> Back in the 90's when .NET and C# were first showing up,

Very early adapter?

(1.0 was released GA in early 2002 and the first public beta went out in
mid 2000)

> GC was my primary
> objection to .NET. But back then, GC-based systems were slow and annoying.

Really.

I do not remember GC problems in 1.x.

Arne

I've been measuring rather crudely using the "Commit Charge" metrics in Task
Manager. After caching the list of bitmaps displayed on the splash screen I
can see that the memory consumed by the system is X if I cache 10 images,
0.9X with 9 images, etc. The memory does not "return" until I fully close
the application, regardless of whether I call Dispose on the elements of the
array or even Dispose on the splash screen prior to showing the main run
screen. I really cannot see how the reference to the objects created in the
array might be non-zero.

In response to your and others helpful advice, I must admit to not fully
understanding how the GC works nor how and when I might have expected memory
to be returned. I had been under the impression that once I dropped the
reference count to zero (called Dispose on the array AND form) that I might
expect to see the memory drop after a few seconds. I now realise that the
situation is more complex than that.

Also following your notes, I checked out GC.Collect() and note that there is
general advise to not call that and just allow the GC to run in the
background and perform its tasks.

Quick question: I've read a note somewhere saying you should "Use the
performance counters to see how much processing time is spent in the GC".
How do you go about that.

Thanks again for all the advise...I'm learning a great deal about .NET and
its intricacies.
Alain

"Arne Vajhøj" <(E-Mail Removed)> wrote in message
news:4f2ddab2$0$294$(E-Mail Removed)...
> On 2/3/2012 11:40 AM, Alain Dekker wrote:
>> I know the automatic garbage collection is supposed to be "better" but
>> having spent my programming life looking after memory myself, I don't
>> like
>> the fluffiness of it. OK, rant over.
>
> It saves you some work.
>
> So unless you have strong real time requirements it is a convenience.
>
>> I display a startup form, then overlay another "main run screen" when all
>> startup actions are complete. As part of that startup I display a bunch
>> of
>> pretty images, changing on a timer tick event, in the startup screen.
>>
>> I've cached those images (they're embedded into the EXE) into an array
>> and
>> then cycle through the images as the startup goes on. Problem is that
>> when I
>> overlay the main run screen, the memory from these images is never
>> released.
> >
>> Is there any way I can force C# to give me back the memory? There doesn't
>> seem to be any "delete" keyword like there is in C++ and its not going to
>> be
>> simple to convert the code into a "using" clause.
>
> First a question: what are you measuring? Are you measuring how much
> memory your app has allocated from .NET or how much memory .NET has
> allocated from Windows (including unmanaged memory allocated by
> your app)?
>
> If it is the second then you do not have a problem. The memory is
> available to your app.
>
> If it is the first then you need to figure out where that memory is
> going.
>
> One reason could be unmanaged resources used by your app and
> not properly disposed.
>
> As an example System.Drawing.Image implements IDispose so
> you need to call Dispose either explicit or implicit via
> the using statement.
>
> Another reason could be that you still have a reference
> to the objects. Example: if you keep the array you mention
> above around, then the objects will not be GC'ed.
>
> Arne

Hi Peter,

Thanks again for an informative post. I meant by "fluffiness", "not knowing
when it will release memory" - and you're right, my term is rather
unhelpful! )

You're also right that I was just going by some of the metrics displayed in
Task Manager. I now realise this is naive of me. The GC might only return
the memory when another memory allocation occurs. Since I'm running well
below the physical amount of RAM in the system, I really haven't tested this
very well!

Thanks again...this marks another notch in my (rapidly) improving
understanding of .NET and I appreciate yours and others patience in advising
this (otherwise experienced Win32) developer!

Regards,
Alain

"Peter Duniho" <(E-Mail Removed)> wrote in message
news:1m3dwcpm2ib9$.(E-Mail Removed)...
> On Fri, 3 Feb 2012 16:40:25 -0000, Alain Dekker wrote:
>
>> Hi,
>>
>> I know the automatic garbage collection is supposed to be "better" but
>> having spent my programming life looking after memory myself, I don't
>> like
>> the fluffiness of it. OK, rant over.
>
> "Fluffiness" being a well-know technical term, of course.
>
> GC isn't uniformly "better" or "worse". It's "different". However, it
> _does_ address a particularly common type of programmer error, with little
> or no performance cost (and in fact in some cases can perform better).
>
> Back in the 90's when .NET and C# were first showing up, GC was my primary
> objection to .NET. But back then, GC-based systems were slow and
> annoying.
> They've come a long way since then, and I generally try to avoid
> programming without GC now. I spend WAY less time writing nuisance
> boilerplate code, and can focus much more efficiently on the code that
> makes each program unique.
>
>> I display a startup form, then overlay another "main run screen" when all
>> startup actions are complete. As part of that startup I display a bunch
>> of
>> pretty images, changing on a timer tick event, in the startup screen.
>>
>> I've cached those images (they're embedded into the EXE) into an array
>> and
>> then cycle through the images as the startup goes on. Problem is that
>> when I
>> overlay the main run screen, the memory from these images is never
>> released.
>
> If that's really true, you have a programming bug. GC doesn't eliminate
> _all_ kinds of bugs. It just eliminates one particular kind.
>
>> Is there any way I can force C# to give me back the memory? There doesn't
>> seem to be any "delete" keyword like there is in C++ and its not going to
>> be
>> simple to convert the code into a "using" clause.
>
> You first need to be more specific. You can't fix a problem until you've
> got a well-defined description of it.
>
> In .NET (and similar systems), GC can't handle everything. Because the
> system interfaces with the OS and other components that don't themselves
> support GC, .NET provides mechanisms such as the IDisposable interface to
> coordinate deterministic resource releasing.
>
> Image objects generally fall into this category. Because there's
> unmanaged
> data (e.g. a Windows HBITMAP object) underlying the managed type, the
> managed type implements IDisposable and you need to call the Dispose()
> when
> you are done with the object.
>
> The GC also cannot release memory until it's no longer reachable through
> any of your program's data structures. If you create an array of objects
> but never release the array (e.g. by setting the array reference variable
> to "null"), then the GC thinks you still need the memory.
>
> Finally, you need to make sure you understand whether the memory truly is
> not being released or not. Nothing in your post suggests that you've
> actually done this. A common mistake is to look at the working set or
> other memory metrics in Task Manager or Resource Monitor and assume that
> just because the process memory allocation hasn't gone down that your
> memory wasn't freed.
>
> But that's not how it works in .NET, or even native C/C++ programs. The
> memory manager can grow your heap as you allocate memory, but then when
> your program releases objects that does not necessarily mean that the heap
> will shrink in size again. It _might_, but it also might not. For a
> variety of reasons, it is often advantageous to keep holding on to memory
> allocated from Windows, even though that memory is not currently claimed
> by
> any objects maintained by the program itself.
>
> For that reason, external measures of how much memory a program is using
> are not a good indicator as to whether memory is being released or not.
>
> So for all we know, you don't even have a problem.
>
> If you are sure you do have a problem, post a concise-but-complete code
> example that reliably demonstrates that problem. Be specific about how to
> reproduce and observe the problem.
>
> Pete

On 2/5/2012 11:33 AM, Alain Dekker wrote:
> I've been measuring rather crudely using the "Commit Charge" metrics in Task
> Manager. After caching the list of bitmaps displayed on the splash screen I
> can see that the memory consumed by the system is X if I cache 10 images,
> 0.9X with 9 images, etc. The memory does not "return" until I fully close
> the application, regardless of whether I call Dispose on the elements of the
> array or even Dispose on the splash screen prior to showing the main run
> screen. I really cannot see how the reference to the objects created in the
> array might be non-zero.

You should call Dispose on anything that implements IDisposable
(have a Dispose method).

And do not worry about reference counting. .NET GC does not
use reference counting. Instead it checks what objects are reachable.
So if the array is no longer reachable then the elements are
no longer reachable and the fact that the array still references
the elements does not matter.

Arne

On 2/5/2012 11:33 AM, Alain Dekker wrote:
> In response to your and others helpful advice, I must admit to not fully
> understanding how the GC works nor how and when I might have expected memory
> to be returned. I had been under the impression that once I dropped the
> reference count to zero (called Dispose on the array AND form) that I might
> expect to see the memory drop after a few seconds. I now realise that the
> situation is more complex than that.

It is very complex.

But to get an idea of the mechanisms you can try and
play with this little program:

using System;
using System.Diagnostics;
using System.Runtime.InteropServices;

namespace E
{
public class Program
{
public static void PrintMemoryStatus()
{
Console.WriteLine("Application has allocated {0} MB from
..NET", GC.GetTotalMemory(false)/1000000);
Console.WriteLine(".NET has allocated {0} MB from Windows",
Process.GetCurrentProcess().PrivateMemorySize64/1000000);
}
private const int N = 100;
public static void Main(string[] args)
{
PrintMemoryStatus();
Console.WriteLine("Let us allocate {0} MB of managed
memory", N);
byte[] b = new Byte[N * 1000000];
PrintMemoryStatus();
b[N/2] = 0; // make sure it is not GC'ed before
PrintMemoryStatus
Console.WriteLine("Let us make it available for GC");
b = null; // never do this in real code
GC.Collect(); // never do this in real code
PrintMemoryStatus();
Console.WriteLine("Let us allocate {0} MB of unmanaged
memory", N);
IntPtr buf = Marshal.AllocHGlobal(N * 1000000);
PrintMemoryStatus();
Console.WriteLine("Let us make it available for GC");
Marshal.FreeHGlobal(buf);
// no point in doing GC for unmanaged memory
PrintMemoryStatus();
}
}
}

Arne