It is dangerous to place too much hope in any improvement coming from just following new fashions, if we lack insight into what really went wrong before.
IMHO that is the single most important sentence in all of that.
So the kernel replaced a bad RC scheme with a proper GC:
> When a process requires a new page it simply takes a free one from the global page pool as soon as one is available. Pages are made available when processes terminate, but also by the intervention of a system process, the `pageout daemon'. There is a big array, the `core map', with one entry for each usable page of memory. The pageout daemon cycles through the array at a rate determined by some scheduling parameters. Free pages are skipped. Any other page is examined to see if it can be discarded.
> The daemon checks the page table entry for the page to see if the `page used' bit is set. If not, the page can be made available. If it has been modified, it must first be written out (asynchronously). If the page has been referenced, the daemon resets the `used' bit and proceeds to the next core map entry. If the page has not been touched the next time round, it will be freed. On systems with large memories, a complete cycle can take some time, and so recent versions have the daemon cycling two pointers through the map: one clears `used' bits; the other reclaims pages.
> In principle, this is a simple and elegant technique. It has been applied quite effectively in a controlled environment in a new implementation of file cacheing in UNIX using virtual memory.
Wonder if then people also cried wolf or just silently accepted the better memory management system.
For software applications at least there's not much of a difference between ref-counting and garbage collection, both are equally bad when memory is allocated and freed with a high frequency. A well written and tweakable GC will most likely perform better than refcounting in such situations.
The best way to improve memory management performance is to allocate and free much less frequently, not to write a better garbage collector, faster allocator or smarter shared-pointer and this is also why manual memory management is the right answer to garbage collection when performance matters, and not refcounting (again: only when memory management performance actually matters).
I'm not sure how much this also applies to virtual memory management though.
Yup, and this problem has continued unabated in all the time since.
I'm a bit more optimistic things can change, though, with things like Rust in Linux, Redox, Fuschia, shifts of various sorts are in the worst, and, more broadly but without hard evidence, I just feel like this sort of opinion has become less niche in recent years.
Unfortunately, I cannot imagine modern Linux kernel getting slimmer.
We keep adding new functionality, so the kernel keeps growing. Maintaining multiple implementations takes effort, so the more generic one (and therefore bigger) wins.
And the worst part, all of those are useful things, for someone. Hotplug, firewall, multiple routing tables, kprobes, bpf, audit, NUMA etc -- those are useful things that deserved to be written and maintained.
They could make the drivers more modular, however --- those are probably the best examples of pieces that someone definitely needs, but certainly not everyone who uses the kernel; and they also make up the bulk of the source tree.
I don't think there is any downside in having a bulky source tree -- it is the binary size which matters. And linux is pretty good at configurability -- any driver, and even many "core" kernel features, can be disabled and then they is no longer even compiled.
Interestingly enough, this was common even in 1987 -- the original post also talks about configuring kernel to reduce binary size:
> Sun kernel code was about 390 kbytes, even properly configured (as distributed it was 490k).
I suppose someone could take kernel source tree and strip out unselected drivers, but I cannot imagine a good reason to do so.
IMHO that is the single most important sentence in all of that.