1996-10-27 10:55:05 +01:00
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
#
|
|
|
|
|
# Makefile--
|
|
|
|
|
# Makefile for utils/mmgr
|
|
|
|
|
#
|
|
|
|
|
# IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
# src/backend/utils/mmgr/Makefile
|
1996-10-27 10:55:05 +01:00
|
|
|
#
|
|
|
|
|
#-------------------------------------------------------------------------
|
|
|
|
|
|
2000-08-31 18:12:35 +02:00
|
|
|
subdir = src/backend/utils/mmgr
|
|
|
|
|
top_builddir = ../../../..
|
|
|
|
|
include $(top_builddir)/src/Makefile.global
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2019-11-05 23:41:07 +01:00
|
|
|
OBJS = \
|
Add palloc_aligned() to allow aligned memory allocations
This introduces palloc_aligned() and MemoryContextAllocAligned() which
allow callers to obtain memory which is allocated to the given size and
also aligned to the specified alignment boundary. The alignment
boundaries may be any power-of-2 value. Currently, the alignment is
capped at 2^26, however, we don't expect values anything like that large.
The primary expected use case is to align allocations to perhaps CPU
cache line size or to maybe I/O page size. Certain use cases can benefit
from having aligned memory by either having better performance or more
predictable performance.
The alignment is achieved by requesting 'alignto' additional bytes from
the underlying allocator function and then aligning the address that is
returned to the requested alignment. This obviously does waste some
memory, so alignments should be kept as small as what is required.
It's also important to note that these alignment bytes eat into the
maximum allocation size. So something like:
palloc_aligned(MaxAllocSize, 64, 0);
will not work as we cannot request MaxAllocSize + 64 bytes.
Additionally, because we're just requesting the requested size plus the
alignment requirements from the given MemoryContext, if that context is
the Slab allocator, then since slab can only provide chunks of the size
that's specified when the slab context is created, then this is not going
to work. Slab will generate an error to indicate that the requested size
is not supported.
The alignment that is requested in palloc_aligned() is stored along with
the allocated memory. This allows the alignment to remain intact through
repalloc() calls.
Author: Andres Freund, David Rowley
Reviewed-by: Maxim Orlov, Andres Freund, John Naylor
Discussion: https://postgr.es/m/CAApHDvpxLPUMV1mhxs6g7GNwCP6Cs6hfnYQL5ffJQTuFAuxt8A%40mail.gmail.com
2022-12-22 01:32:05 +01:00
|
|
|
alignedalloc.o \
|
2019-11-05 23:41:07 +01:00
|
|
|
aset.o \
|
Introduce a bump memory allocator
This introduces a bump MemoryContext type. The bump context is best
suited for short-lived memory contexts which require only allocations
of memory and never a pfree or repalloc, which are unsupported.
Memory palloc'd into a bump context has no chunk header. This makes
bump a useful context type when lots of small allocations need to be
done without any need to pfree those allocations. Allocation sizes are
rounded up to the next MAXALIGN boundary, so with this and no chunk
header, allocations are very compact indeed.
Allocations are also very fast as bump does not check any freelists to
try and make use of previously free'd chunks. It just checks if there
is enough room on the current block, and if so it bumps the freeptr
beyond this chunk and returns the value that the freeptr was previously
pointing to. Simple and fast. A new block is malloc'd when there's not
enough space in the current block.
Code using the bump allocator must take care never to call any functions
which could try to call realloc() (or variants), pfree(),
GetMemoryChunkContext() or GetMemoryChunkSpace() on a bump allocated
chunk. Due to lack of chunk headers, these operations are unsupported.
To increase the chances of catching such issues, when compiled with
MEMORY_CONTEXT_CHECKING, bump allocated chunks are given a header and
any attempt to perform an unsupported operation will result in an ERROR.
Without MEMORY_CONTEXT_CHECKING, code attempting an unsupported
operation could result in a segfault.
A follow-on commit will implement the first user of bump.
Author: David Rowley
Reviewed-by: Nathan Bossart
Reviewed-by: Matthias van de Meent
Reviewed-by: Tomas Vondra
Reviewed-by: John Naylor
Discussion: https://postgr.es/m/CAApHDvqGSpCU95TmM=Bp=6xjL_nLys4zdZOpfNyWBk97Xrdj2w@mail.gmail.com
2024-04-07 14:02:43 +02:00
|
|
|
bump.o \
|
2019-11-05 23:41:07 +01:00
|
|
|
dsa.o \
|
|
|
|
|
freepage.o \
|
|
|
|
|
generation.o \
|
|
|
|
|
mcxt.o \
|
|
|
|
|
memdebug.o \
|
|
|
|
|
portalmem.o \
|
|
|
|
|
slab.o
|
1996-10-27 10:55:05 +01:00
|
|
|
|
2008-02-19 11:30:09 +01:00
|
|
|
include $(top_srcdir)/src/backend/common.mk
|
