Garbage collection of working environment?

Question

Could anyone elaborate what work you are doing in garbage collection in daily corporate work?

How much your considering garbage collection in your SDLC?

Answer 1

The advantage of Garbage Collection is that you don't have too worry about it much or at all. You lower level implementations can be planned (beforehand or on the fly) easier, having more time to worry about other complicated issues, not having to take into account freeing up memory.

There are some things to keep in mind to take advantage of Garbage Collection, but they are usually easy or intuitive. A couple examples:

• You might have to change your thinking to take advantage of the fact that circular references are not really a problem any more (as long as all the resources involved are managed of course). This is pretty easy and fun to get used to!

• It's helpful to define variables in the lowest scope possible. But, you'd want to do that anyway.

So, if you're moving to .NET from someplace without managed memory, yes, read about GC a bit, but if you find yourself not thinking about it, that's the point, don't worry.

Edit: Keep in mind you can still used unmanaged resources in .NET. Even in many of the common .NET namespaces, unmanaged resources are used underneath. You must understand the .Dispose() (and corresponding Using keyword) as clues that you're stepping into unmanaged memory. (see me blab about that here.)

Answer 2

My main concerns, for daily corporate work, in terms of garbage collection is making sure we have a good janitorial service. ;)

Really, for the majority of LOB applications, you probably never need to worry about garbage collection. If you find you're having a performance issue, and profiling is showing that you have memory related performance issues or a memory leak, then looking at the GC perf is useful. This is rare in typical LOB apps.

Answer 3

For most purposes, you shouldn't have to get too concerned about GC. If you are worrying about this, it probably means you've got underlying coding problems (accidentally leaking object references, perhaps via static events etc).

So treat this as a reactive thing when you find you have a problem - and use a memory profiler to find and fix that problem.

Answer 4

The main thing to understand about GC is that it is not a panacea. It is applicable to memory and resources similar to memory, i.e. resources that you have a limited but pretty big supply of, and equivalent instances of the resource are interchangeable, i.e. any two 1 MB memory buffers are equally good for what you need to do with them.

So temporary files are like memory (you don't care which file it is), and file handles are like memory (you don't care what the specific handle value is), but files themselves, and locks on files, are not - they have a unique meaningful name that they are associated with. So you have take more care about exactly when you clean them up. You usually can't let GC close file locks or delete specific files at some random time. But you can do that with temporary files.