Most kernels do have a heap and they work fine for this purpose, as the article advocates. After all, they need a page allocator to respond to requests from use

Most kernels do have a heap and they work fine for this purpose, as the article advocates. After all, they need a page allocator to respond to requests from userspace programs for dynamic allocation (unless it's an extremely embedded OS where memory is allocated to tasks at design / compile time - think Apollo Guidance Computer, not QNX). So they may as well allocate pages for their own use, if they want. If you want string-handling on the heap, you probably also want some sort of a malloc implementation, so you can handle allocation requests that are less than one page, but that's just an algorithm that sits on top of the page allocator. You don't want to overuse it, though. Page allocation can fail, and more interestingly, it can require blocking - maybe you're not out of memory, exactly, but you've got dirty buffers that need to be flushed to disk (or worse, to NFS). If you're handling a system call from a userspace program, blocking is probably fine. But the kernel runs in more contexts than that. One problem is that the code that handles flushing dirty buffers, and any code that it calls, cannot block; otherwise, you might deadlock, because you're trying to allocate a new page so you can finish free a page. (And in the case of NFS, that includes basically all of the socket code in the kernel.) You also don't want to block inside interrupt handlers, even if the thing the interrupt handler is doing is putting some data on a queue and letting a kernel thread pick it up. Those buffers need to be allocated in advance, or at least come from a special pool of ready-to-use pages that can always be allocated without blocking. In a kernel that supports swap, you can choose to swap out basically anything to make more room, but that has its own deadlock problem too. Code used by any disk handler (and any filesystem, if you support swap files) cannot allocate memory that can be swapped out; otherwise you might not be able to swap that memory back in. One common approach, which Linux takes, is to say that memory allocated by the kernel simply cannot swap. But that means that you can't allocate too much inside the kernel. NT actually has a swappable kernel pool, and the infamous IRQL_NOT_LESS_OR_EQUAL blue screen means that a kernel driver tried to access data that was swapped out in a context where it wasn't allowed to swap. Here's the Linux kernel's documentation on its various allocation options: https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html https://www.kernel.org/doc/html/latest/core-api/memory-alloc... https://www.kernel.org/doc/html/latest/core-api/mm-api.html#watermark-modifiers-controls-access-to-emergency-reserves https://www.kernel.org/doc/html/latest/core-api/mm-api.html#...