Is the .NET GarbageCollector really a GarbageCollector?

Question

I am working on a project that implements the IDisposable interface. During this project, I found out my knowledge of the GarbageCollector can be best described as poorly. So I started reading some documentation and finally I found the "Fundamentals of Garbage Collection" article on MSDN.

You have to understand that at this point I always thought the GarbageCollector was the man working in the sewers who cleaned up the waste coming from the Program. Therefore I was surprised to read the following snippet:

After the garbage collector is initialized by the CLR, it allocates a segment of memory to store and manage objects.

A paragraph later, the document states:

To reserve memory, the garbage collector calls the Win32 VirtualAlloc function, and reserves one segment of memory at a time for managed applications. The garbage collector also reserves segments as needed, and releases segments back to the operating system (after clearing them of any objects) by calling the Win32 VirtualFree function.

If I understand correctly, the GarbageCollector is actually the MemoryManager of a .NET program!

I know, it still collects garbage. But isn't that like calling a singer a microphone holder? Sure, it's true, but hardly the reason you'd pay money to see them. The GarbageCollector does apparantly so much more than waste disposal, it hardly seems fair to call it just a GarbageCollector.

So in conclusion:

Did I understand correctly? Or am I way off?

And if I did understand correctly: why did the .NET developers call it a GarbageCollector?

Answer 1

It's not just .NET. Java, C++, Objective-C and other languages also use the same terminology. They do manage memory, but it's mostly to clean up the waste that is left behind.

Think about that for a moment, allocating memory is a fairly trivial task really - calling VirtualAlloc for the most part. The true hard work, and science, comes when cleaning the memory used by a process. The .NET GC is a highly tuned engine indeed, and a lot of people have spent a great deal of effort optimizing the GC when it comes to cleaning garbage e.g. dealing with pinned objects in memory, fragmented heaps, background processing so that it does not affect performance.

So yeah you could call it a MemoryManager, but to be fair, it's real star skill is collecting garbage.

Answer 2

You are correct, a garbage collector is essentially a kind of memory manager.

This makes sense if you consider that, for the garbage collection to be able to happen, the most practical way is for the garbage collecting mechanism and the memory allocation mechanism (and the reference resolving strategy, in case of a compacting garbage collector) to be very closely related.

The reason for this is that a garbage collector needs to perform a lot of bookkeeping in order to operate. To perform that bookkeeping reliably, among other things it needs to have information about the allocations that take place. The most obvious way to achieve that is for the garbage collector to offer its own memory allocation routine. That can be done either by providing a new memory allocator interface, alternative to the standard one offered by the language (and possibly leveraging it, as mentioned by Marco in the comment) or by intercepting and essentially replacing the standard memory allocator of the language with its own.

In any case, all memory managers need to offer some kind of memory allocation mechanism - so that's not something that differentiates them. However, only a few of them can actually collect garbage automatically and so that's what we focus on when naming the ones that do. In essence, garbage collector really means garbage collecting memory manager.

Now its common name might indeed sound a little bit misleading, but it's not the .NET developers that have come up with it. Such memory managers have always been called garbage collectors, probably as early as the first existence of the concept, in Lisp. It's been kept like that for historical reasons, I imagine.

Answer 3

The entity that reclaims unused memory is called garbage collector in .Net probably because that's what it had been called since the inception of the idea of automatic memory management in the 50's - 60's.

It may be that initially the problem of managing where memory should be allocated was considered separate, as this was required also for manual memory management. The deeper problem was how to detect which parts of allocated memory were no longer being used by the program,"garbage", and freeing them for reuse. Apparently this is easier if you know how the memory was allocated in the first place, so you might as well give the responsibility of allocating memory to the GC.