What good is this automatic garbage collector?

[joe]

I have a simple .NET application with two or three listViews which are
filled with icons and when the user click on the proper item, they display
the related images. I use "image = null ; " for all images that have been
used and are going to be closed. This is how ever no way to reduce the
memory consumption. I have noticed , using the task manager, that garbage
collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed anymore?

Besides, calling CG.Collect() is usually avoided for performance and speed.
What else can i do?

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

 

[Cor Ligthert]

I have noticed , using the task manager, that garbage

collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed
anymore?

Allthough it the task manager is not the good instrument to check.

I am curious, what is foolish about this, every garbaging uses processor
time.

To use a methpore "Do you empty your trash bin, everytime you have thrown in
a paper or whatever?

Cor

 

[Patrice]

Have you tried to call Dispose ?

Though the point of a garbage collector is that there is no need to reclaim
memory if you have no use for it, it's worth to keep in mind that it have
its root in the managed world and that the Dispose or Close methods should
still allows to reclaim unmanaged memory immediately...

Please let us know...

Patrice

 

[joe]

Have you tried to call Dispose ?

Dispose is not supported on all objects. In my case, calling GC.collect()
does a little help though.

Though the point of a garbage collector is that there is no need to
reclaim
memory if you have no use for it, it's worth to keep in mind that it have
its root in the managed world and that the Dispose or Close methods should
still allows to reclaim unmanaged memory immediately...

Yes, in a perfect managed world where no one wants to struggle with memory
allocation and release, this could be good suggestion. But in the same
managed world there are times when an object is used only "once", and then
thrown away forever or used after a long time or maybe in next program
launch. Why should its memory be still occupied by the program?
I mean, there should a way to have more control over this kind of memory
management. ( sth like a half-automatic GC, until the day GC becomes really
smart and intelligence)

i can also use SetProcessWorkingSetSize(-1,-1) , however it is not usually
recommended.

 

[joe]

To use a methpore "Do you empty your trash bin, everytime you have thrown

in a paper or whatever?

Can you recycle disposed objects in a programming language? If you can, then
why do you put them in the recycle bin?
just curious.

 

[Olaf Baeyens]

I have noticed , using the task manager, that garbage

collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed anymore?

Why is this foolish? Why would the GC need to use additional processing
power for dynamic cleanup?
What would the unused memory be needed for untill the system gets low on
memory?

I like the way it is implemented. It only cleans up when new memory is
needed and when there is no memory left.
This way the GC is faster, because it can do the job in one go, and your
code gets executed faster because it does not lose time to clean up every
time you release memory. and once it starts cleaning up, it can do it
faster.

The only anoying thing that could give problems is for games, that generates
a hickup because one GC takes up a little longer than a dynamic one, but
overall, a GC only during low memory will actually free up more processing
power. And I believe that it also speeds up your program since the compiled
code is smaller for that function (no code for cleanup in that function) and
thus the chance that this function could reside completely in your processor
cache could speed up dramatically.

One thing that might be implemented is to use dynamic GC when the processor
is in idle mode. But then again, you could regard this as unecesary using
processor cycles, which decreases the laptop batterie power because it needs
more power.

 

[Brian Gideon]

[snip]

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

I disagree. While some aspects of the article may be at least
partially correct, it does more harm than good. For example, the
author completely missed the point of the original claim about reduced
memory leaks. Similarly, I thought the other points were
misinterpreted as well, albiet, to a lesser degree.

Brian

 

[Patrice]

If "Dispose" is not supported you should have then only the managed object.
In most cases it shouldn't a problem (ie. the bitmap portion of an image
object is likely much more big than the members of the managed class).

Another option I can think of is for example for voluminous data structure
to change the current size (for example resizing an array to a lower size).
Could perhaps help (not sure, give this a try, let us know please).

On the other hand what is the problem with having something kept around and
that doesn't harm ? If you really want to clean up the object immediately
they would have to be back to reference counting...

For now I would start first to see if it raises an actual problem and
wouldn't bother if not...

Patrice

--

 

[Nick Malik [Microsoft]]

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

This commentary is a case of one inexperienced programmer criticizing a
feature that they do not understand, with poor understanding of the forces
that underlie the fundamental reasoning. Garbage collection is easy in
C++... if every developer were free of mistakes and if code were not
complex. This is not the case in the real world. The author of that
article completely failed to recognize the reality of memory leaks in a
production system of substantial size.

One reason for the success of BOTH Java and .Net languages like C# is that
this problem is solved for you. You may not agree with the way in which it
is solved, but it is solved for you. That is a huge step up and a major
boon for software development.

The problem isn't the computers or their languages... it is the limitations
of the humans who use them.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[joe]

Nick,
Your reasoning is respected and welcomed. I don't hate or love something
like idiots, i simply point out the weak points.

It is true that CG is a great miracle in C# and java, and help the
programmer to concentrate on more critical aspects of his work, however,
when it comes to page faults, it exhibits its weak points.

You might say that because allocation or garbage collection is done only
when the computer becomes low on memory, you gain much higher performance in
your application. This can be true for small programs, however, when some
real big programs are executed on computers with low memory ( sth like 256
MB) , then the amount of OS's page swapping and virtual memory reading and
writing really slows down the entire system. Just think, why your OS is much
faster after a clean restart than the time it is run for long hours of
application executing and playing with the virtual memory?

Well, at least there could be stricter algorithm implemented, which would
force the GC to come into play much sooner that it does now on low-memory
PCs.

 

[Willy Denoyette [MVP]]

The GC runs more often than you think - just watch the CLR Performance
counters while your program is running, but the GC isn't meant to collect
unmanaged resources like file handles, DB connections and unmanaged memory,
the GC will also not collect non garbage, that is objects that have live
references. Non managed resources can explicitly and deterministically be
released by calling Dispose or Close or whatever method there is used to do
so. the FCL used the Dispose pattern to dispose of unmanaged resources, and
the languages (C# since v1 and VB in v2.0) help you to automate this pattern
by means of the using statement. If you fail to apply this design pattern
and if you are holding references to objects alive when they should not than
there is nothing the GC can do to reclaim memory, but this is not different
from the unmanaged world.
Note, there will be no swapping because non referenced objects aren't GC
collected. The OS will trigger an event that will force the GC to collect
when there is memory pressure. Note also that the garbage collector runs
more often than you thing.


Willy.

 

[Nick Malik [Microsoft]]

Hello Joe,

I appreciate that you are taking a reasoned approach.

I also agree that a case could be made for fine-tuning the GC. That said,
Willy's comment is correct... the GC really does run more often than you
think. Also page swapping, as caused by .Net apps, is probably less than
you think. Note that a page is only swapped "in" when memory on that page
is referenced. If the page is completely empty of active objects, then it
will not swap in until the GC frees it. (This actually slows the system
down if you do this too often).

You refer to how much faster the system runs after a while. This is
completely true. However, it is also often the case that the culprit for
this kind of memory fragmentation is the use of unmanaged objects that don't
drop their references and therefore create gaps in the memory space that is
difficult for the heap allocation system to reuse.

As for low-memory systems, I would assert that you are using the OS at or
near the smallest amount of memory that it supports. Normal OS operations
will fragment the memory, all by themselves, without any help from your app.
In this case, .Net is not able to really improve the situation.

Note that the OS teams have made real strides over the years in improving
how memory is used. However, as memory has become so much less expensive,
it is not unreasonable to expect that users will occasionally upgrade their
memory when they install a new OS to get new features like better security,
better handling of multimedia, more efficient file systems and (strictly for
the non-server environments) more advanced games.

I hope this helps. I understand your frustration. (One of my systems at
home has 256M of RAM, too... I'm just too lazy to run down to Fry's and get
a memory module for it :-(.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.

 

[Olaf Baeyens]

I really love the GC.
Not because I have a lot of memory leaks in my pogram, but because my
programming gets far simpler because I do no have to keep track of which
list created the object and in what order do I need to release it to prevent
an access violation if it is referenced by another list.

This way I am guaranteed that the object is only released when bot lists are
not referencing it anymore.
In the none-GC way I have to keep track of that creating additional code
that might even be slower because the GC way is far more optimized than the
code that I would create. The closest to what is equivalent in the GC is
what COM objects does. When the reference counter reaches zero it disposes
itself. But you do not have to call the AddRef and release.

The only negative side of the GC is that it sometimes starts to collect and
for a game that means a momentarely freeze which is deadly if you were about
to kill the bad guy online. ;-) Or maybe when you have a program that must
do something real-time like capturing a video that might lose frames.

 

[Ross Presser]

I have a simple .NET application with two or three listViews which are
filled with icons and when the user click on the proper item, they display
the related images. I use "image = null ; " for all images that have been
used and are going to be closed. This is how ever no way to reduce the
memory consumption. I have noticed , using the task manager, that garbage
collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed anymore?

Besides, calling CG.Collect() is usually avoided for performance and speed.
What else can i do?

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

This might be a futile suggestion, unhelpful for your situation ... but I
have noticed that GC is more agressive when the project is compiled for
release, rather than debug.

 

[Richard Blewett [DevelopMentor]]

Have you verified the "no GC unless low memory" using the GC perf counters? Task Manager doesn't show you what the GC is doing.

And agreed, in Release build the GC's concept of object liveness is much more aggressive

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

I have a simple .NET application with two or three listViews which are
filled with icons and when the user click on the proper item, they display
the related images. I use "image = null ; " for all images that have been
used and are going to be closed. This is how ever no way to reduce the
memory consumption. I have noticed , using the task manager, that garbage
collector doesn't actually do any collections unless the computer becomes
low on memory. This is very foolish, and what good is a garbage collector
which doesn't collect the disposed objects when they aren't needed anymore?

Besides, calling CG.Collect() is usually avoided for performance and speed.
What else can i do?

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

This might be a futile suggestion, unhelpful for your situation ... but I
have noticed that GC is more agressive when the project is compiled for
release, rather than debug.

 

[butchg]

Like most things there are tradeoffs involved. One of the most
difficult parts of developing large software systems, especially among
multiple developers, is defining and maintaining an object life cycle.
You must define who creates the object, and who has the responsibility
for the storage at any time. In some applications it is fairly
straight forward, in other cases it is not.

C# and the garbage collector removes this burden (for the most part)
from the design and implementation process. However it does this at an
expense. First, there is a performance penality versus what can be
done in native C++. This penality can be relativily small and will
only come into play in the most performance critical of applications.
Second, there is a memory foot print issue. There will be a small
penality for garbage collection.

Finally, there is a point of confusion in the original post. Most
memory schemes, whether they be the garbage collection in Java or C#,
or whether it is the basic malloc/free in C, do not return memory to
the operating system. Memory that is free'ed is made available for the
next request in that process, but the process will almost never return
memory to the OS. Therefore, looking at the memory size for the
process will show the process only getting larger as the process runs
and never getting smaller. If you want to really characterize memory
usage, you need to do that within the process, with the cooperation of
the memory system. There are ways to do this in Visual C++ and C# as
well.


Just my $0.02 worth
Butch

 

[Ross Presser]

Finally, there is a point of confusion in the original post. Most
memory schemes, whether they be the garbage collection in Java or C#,
or whether it is the basic malloc/free in C, do not return memory to
the operating system. Memory that is free'ed is made available for the
next request in that process, but the process will almost never return
memory to the OS. Therefore, looking at the memory size for the
process will show the process only getting larger as the process runs
and never getting smaller.

Yes, but you can tell the difference between a lazy GC and an aggressive
GC: the process running the agressive GC will not grab as much memory from
the OS in the first place, because it will recycle memory from free'd
objects, whereas the lazy GC will just grab more memory until the system
runs low.

 

[Scott M.]

The answer is that in most cases, "No.", you can't recycle disposed objects.
You need to make a new instance of one.

 

[Scott M.]

Why exactly are you trying to reclaim memory when there is still plenty of
memory for you application to run?

 

[Guest]

GC is a big work! if u set some enviroment variable , GC can occured every
time, but is's too slowly...Of course, if u want to find some memory
problems(such as leak) ,this is a good idea.
GC.Collect() is not a good idea, u'd better NOT call this method in your code.

[snip]

PS: i wont hurt you to read this:
http://www.cs.tut.fi/~warp/MicrosoftComparingLanguages/

I disagree. While some aspects of the article may be at least
partially correct, it does more harm than good. For example, the
author completely missed the point of the original claim about reduced
memory leaks. Similarly, I thought the other points were
misinterpreted as well, albiet, to a lesser degree.

Brian