Not so much the author's fault, but there's a bit of confusing terminology around the meaning of "pool" in memory allocator literature in general, and this article in particular.
In this article, they say:
> Pools ... involve: pre-allocating ... core resources that are frequently used in a program, which are self-managed by the program ...
This (IME) most often means some sort of "object pool," with fixed-size objects and O(1) allocation and de-allocation.
And also:
> a memory pool pre-allocates a large block of memory ... When the programmer releases the memory, it is returned to the pool ... and is merged with surrounding free memory blocks as much as possible.
This clearly is not referring to the object pool concept.
In the article, the O(1) freelist approach falls under the "bins" nomenclature.
In general, memory allocator terminology is pretty messy, varying between sources and implementations. Words like "arena allocator" and "stack allocator" seem frequently abused/blurred, made worse by the fact that one can nest allocators in each other — eg: a stack allocator which allocates from an arena, but sometimes referred to one or the other interchangeably.
I had a bit of a rollercoaster ride trying to make heads and tails of it all when I was researching these things.
Think of object pool as a specific version of more general concept of resource pooling which can be applied in many different situations.
* Requesting resource X from system Y is expensive or has a high latency
* you request a bunch of X in single operation and create a "pool" from it
* you local code manages distribution of resource without the overhead of interactions with Y
The exact details can vary depending on specific type of object and situation, but general principle is the same. What is Y, what causes overhead when requesting X from Y, and whether X is discrete object or resource that can be subdivided doesn't matter.
In case of object pools in a higher level language the X might be instances of specific class, and Y the programming language runtime.
But it if you go a layer deeper X might be bytes, and Y the operating system.
It's not just memory. Pooling is also commonly used for threads. Where X is a thread with all the associated OS resources, and Y is the operating system. Instead of asking operating system to create a thread for each task, a process might create a pool of bunch of threads and have task queue, with threads taking task from the queue. You might think of it as just another object pooling, but if you actually tried to implement it you might find that there is as much implementation specific differences compared to plain object pooling, as differences between object pooling and and the memory pools used within a memory allocator.
The name probably comes from real life manufacturing where you might have large vat or a pool with some liquid ingredient, serving as buffer closer to where it's used. Instead of requesting and transporting it in small chunks from warehouse or a supplier. This also demonstrate that resource within a pool doesn't always come in discrete chunks.
Reasons for pooling can also be different. In lower languages and the memory allocator itself you might want to avoid overhead of requesting memory from operating system, in low and medium level languages you might want to avoid overhead of memory allocator (running within the same process), in higher level languages you might want to avoid the runtime overhead of creating object instance (not the cost of plain memory allocation), at even higher level when making a game in an existing engine like Unity you might be worried about overhead added by the engine. It's turtles all the way down with each layer potentially using some kind of resource pooling to avoid interacting with next layer.
archive: http://web.archive.org/web/20231129055356/https://jackfromea...