Thread-local compacting GCs already handle this. Requests tend to be served by a single thread and the GC dishes out memory from a thread-local pool to avoid co

Thread-local compacting GCs already handle this. Requests tend to be served by a single thread and the GC dishes out memory from a thread-local pool to avoid contention. Server-side GCs can also be concurrent and avoid suspending threads as much as possible. If you aren't generating garbage that escapes the nursery generation they may basically never suspend threads or block at all. Arenas are a similar concept that work well in non-GC environments if you don't let objects allocated during a request escape to live beyond the request. Thread-local pools to satisfy allocations are also a well-known technique used in various allocators so your system's malloc might be doing this for you. It might also be able to efficiently collapse free lists which more or less behaves like an arena allocator when your request pipeline doesn't let allocations escape. In practical terms: most approaches generalize well enough that if you follow the rules you'd need to follow anyway you get the benefits without the drawbacks. In most of the remaining edge cases you get even better benefits by adopting other strategies. For example Unity uses C# which has a GC... but games shouldn't allocate on the game loop _anyway_ so GC vs ref counts vs malloc isn't very important compared to avoiding allocations altogether. Or if you already obey the rules you'd need for an arena allocator in your server then letting the GC or allocator deal with it might mean you can coalesce cleanup across multiple requests which may actually be better for performance anyway. And without manual arena management you don't risk problems if some esoteric edge case in the code needs to allocate something that will outlive that specific request.