Memory fragmentation is generally a problem for pets, not cattle. In 90% of use cases it’s nothing that frequently reaping processes won’t fix. This works regardless of language, as it pushes the job of garbage collection onto the os. Another nice feature of treating your processes like dirt is that you tend to get high fault tolerance and scalability as emergent properties.

Right. Just like the story of a memory leak in a missile.[1]

[1]: https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

I really think it's a good solution for many cases but I haven't seen any server-side web framework that implements a kill-the-process-often strategy.

Do you know of any? If so, when do they decide to kill the process and how do they handle client disconnect?

Some pre-forking web servers will shut down a child process after it has processed a configured number of requests.

E.g. Apache in mpm_prefork mode, MaxRequestsPerChild configuration.

C# suffers from that too. I've personally seen a prod instance experience OOM with something like 40% free virtual memory. There's a reason why ArrayPool is part of mscorlib.

All of that said, x64 greatly reduces the effects of memory fragmentation: there's always more virtual memory.

Previous discussion on this https://news.ycombinator.com/item?id=18190573