Why doesn't the OS have a garbage collector?

Question

I'm wondering about that because the OS is responsible for memory management. Why must programming languages implement their own garbage collectors?

Answer 1

How would the OS know what is garbage and what isn't?

Each programming language has its rules to define what a data structure is and when a data structure is referenced by another data structure. Each programming language implementation (i.e. compiler, interpreter, runtime) has its way of representing data structures in memory. The garbage collector needs to know how data is represented: it needs to know what is a pointer, and what the pointer is pointing to.

Generally, a pointer is an address in memory. But there is no way to know a priori which memory cells contain a pointer and which memory cells contain some non-pointer data which just happen to have the right bit pattern to be a valid pointer. Furthermore, additional information is needed to know the size of the datum that the pointer references.

There are conservative garbage collectors, which assume that every memory cell that can be interpreted as a pointer is a pointer. Even then, the garbage collector needs to know where the data that the pointer is pointing into starts and stops, so the garbage collector needs to be aware of the memory representation used by the programming language environment. Furthermore, the garbage collector has to assume that there are no hidden pointers (for example, written to disk, compressed, …).

If programs are allowed to contain arbitrary machine code, which is the case with most operating systems, then garbage collection has to be left to each programming environment. There are some specialized operating systems which force all programs to use the same runtime environment (for example, all programs have to run in a JVM or in .NET) and do include a garbage collector.

OSes often include specialized forms of garbage collectors, usually based on reference counting, for example to close a file when the number of processes that have it open drops to 0, or likewise for a shared memory area.

Answer 2

It does.

Garbage collection requires the operating system to know what is and is not garbage, and the easiest way to do this is some sort of type safety guarantee. Some experimental operating systems, such as Es and Singularity, provide type-safe language runtimes at the kernel level: JavaScript in Es and a C# variant in Singularity. But most kernels are designed to allow applications in popular type-unsafe languages, such as C++, to run. All a kernel can do in such a case is reclaim the memory occupied by a process that has terminated.

So most kernels delegate management of memory belonging to a particular process to the language runtime. The default installs of all major desktop operating systems include more than one garbage collected language runtime in which applications can run.

• The .NET Framework comes with all supported desktop versions of Windows.
• Python comes with OS X and popular distributions of GNU/Linux.
• Android includes the Dalvik VM, which implements the same garbage collection as Java.
• Furthermore, all desktop and mobile operating systems ship with a web browser that implements JavaScript.

Answer 3

I'm wondering about that because isn't OS the responsible for the memory management?

Only in the sense that the operating system allocates memory to programs, which then decide how to use this using their own memory managers. Centralizing memory management further in the OS is problematic, because it would be slow: programs have different memory access patterns, so giving them all the same GC would make it harder for programmers to use custom memory management patterns. E.g., different language runtimes require different garbage collectors to support the languages' idioms in an efficient way. It would also complicate OS design by requiring the OS to manage memory in programs.

Actually, in a certain sense, operating systems already provide GC: when a program exits, a typical OS will clean up its memory. But as long as the program is running, it is responsible for managing the memory the OS gives it.

EDIT: there's some discussion at the other answers about what constitutes an OS. I've considered a narrow definition where an OS is a kernel, a running program that provides scheduling and services for processes. This matches your typical Windows/Linux/Unix desktop/server OS.