Why not have a systems language with garbage collection?

From http://research.microsoft.com/pubs/52716/tr-2005-135.pdf:

  3.4	Garbage Collection
  Garbage collection is an essential component of most safe languages,
  as it prevents memory deallocation errors that can subvert safety
  guarantees. In Singularity, the kernel and processes object spaces
  are garbage collected.

I appreciate that Microsoft Research is saying "why not?" rather than "why?". Singularity is a fascinating OS and I hope it, or some derivative or something like it from someone else, eventually reaches the mainstream market.

BitC, a project started by Jonathan Shapiro of Coyotos project fame and briefly associated with Microsoft's Midori project, is a systems programming language that supports garbage collection but also allows the programming of critical sections of code in which garbage collection is not permitted to take place.

http://www.bitc-lang.org/docs/bitc/bitc-origins.html

Surely there were kernels written with garbage collecting - smalltalk xerox systems, or lisp machines come to mind.

In a talk/interview on Go Rob Pike (on infoq maybe?) explained that with "systems programming" they don't mean OS development (at least not now). GC technology will improve so that sooner or later it won't be an issue.

Garbage collection needs to go into the kernel. Providing fast, fine-grained control over virtual memory mappings gets you a read barrier on any system with virtual memory, which lets you build real-time GCs. Azul's patches to Linux show how this can be done:

http://lambda-the-ultimate.org/node/4165

They're using the VT-x for the virtualized page tables and still run the GC in userspace, but if you move the GC into the kernel you won't even need virtualized page tables.