Skip to content

Commit 58cf2e1

Browse files
committed
Update mmgr's README to mention BumpContext
Oversight in 29f6a95. In passing, since we now have 4 memory context types to choose from, provide a brief overview of the specialities of each memory context type. Reported-by: Amul Sul Author: Amul Sul, David Rowley Discussion: https://postgr.es/m/CAAJ_b94U2s9nHh--DEK=sPEZUQ+x7vQJ7529fF8UAH97QJ9NXg@mail.gmail.com
1 parent 6d2fd66 commit 58cf2e1

File tree

1 file changed

+26
-19
lines changed

1 file changed

+26
-19
lines changed

src/backend/utils/mmgr/README

+26-19
Original file line numberDiff line numberDiff line change
@@ -471,25 +471,32 @@ thrashing.
471471
Alternative Memory Context Implementations
472472
------------------------------------------
473473

474-
aset.c is our default general-purpose implementation, working fine
475-
in most situations. We also have two implementations optimized for
476-
special use cases, providing either better performance or lower memory
477-
usage compared to aset.c (or both).
478-
479-
* slab.c (SlabContext) is designed for allocations of fixed-length
480-
chunks, and does not allow allocations of chunks with different size.
481-
482-
* generation.c (GenerationContext) is designed for cases when chunks
483-
are allocated in groups with similar lifespan (generations), or
484-
roughly in FIFO order.
485-
486-
Both memory contexts aim to free memory back to the operating system
487-
(unlike aset.c, which keeps the freed chunks in a freelist, and only
488-
returns the memory when reset/deleted).
489-
490-
These memory contexts were initially developed for ReorderBuffer, but
491-
may be useful elsewhere as long as the allocation patterns match.
492-
474+
aset.c (AllocSetContext) is our default general-purpose allocator. Three other
475+
allocator types also exist which are special-purpose:
476+
477+
* slab.c (SlabContext) is designed for allocations of fixed-sized
478+
chunks. The fixed chunk size must be specified when creating the context.
479+
New chunks are allocated to the fullest block, keeping used chunks densely
480+
packed together to avoid memory fragmentation. This also increases the
481+
chances that pfree'ing a chunk will result in a block becoming empty of all
482+
chunks and allow it to be free'd back to the operating system.
483+
484+
* generation.c (GenerationContext) is best suited for cases when chunks are
485+
allocated in groups with similar lifespan (generations), or roughly in FIFO
486+
order. No attempt is made to reuse space left by pfree'd chunks. Blocks
487+
are returned to the operating system when all chunks on them have been
488+
pfree'd.
489+
490+
* bump.c (BumpContext) is best suited for use cases that require densely
491+
allocated chunks of memory that never need to be individually pfree'd or
492+
repalloc'd. These operations are unsupported due to BumpContext chunks
493+
having no chunk header. No chunk header means more densely packed chunks,
494+
which is especially useful for workloads that perform lots of small
495+
allocations. Blocks are only free'd back to the operating system when the
496+
context is reset or deleted.
497+
498+
For further details, please read the header comment in the corresponding .c
499+
file.
493500

494501
Memory Accounting
495502
-----------------

0 commit comments

Comments
 (0)