Feel like that's a common misconception: https://en.wikipedia.org/wiki/Midori_(operating_system)

http://programatica.cs.pdx.edu/House

Good thing rust doesn't have one.

I would argue that it actually might not matter too much:

1. In a constraint context (embedded/kernel) you want to preallocate most things anyway, since even normal malloc/free isn't deterministic. Once you preallocate objects, it doesn't matter if those are coming from a long-lived GCed heap or from somewhere else.

2. Kernels like Linux rely on the fact that some small allocations never fail. Plugging in a GC and asserting that it won't fail would have the same effect (with some impact on latencies).

What might be most important is that the language supports explicit stack allocations, which avoids the need for any kind of heap when necessary. That is given for languages like C# and Go.

Could you please expand on this. When garbage collection works in applications and webservers that handle large number of requests, why wouldn't it work in OS kernel?

GC can create noticeable pauses in the whole windows UX because windows scales vertically in a machine not horizontally in a DC. And per another comment I made, if your OOM handler needs to JIT it can be catastrophic.

It introduces indeterminism into a system that strives to have as little as possible. You could of course, but you probably shouldn’t.

maybe it would? maybe somebody could create a co-processor just for that. sadly cpu's won't actually have specific extensions to have a good way of doing garbadge collection. but I guess it would be pretty helpful.

So, LISP machines?

maybe, without the brackets, of course.

Xerox PARC, ETHZ, DEC and MSR had other opinion regarding that.