Update in-place reallocation documentation.

This commit is contained in:
Jason Evans 2015-08-14 00:55:44 -07:00
parent a5dbaef08f
commit 38f864947b

View File

@ -568,8 +568,13 @@ for (i = 0; i < nbins; i++) {
up to the same size class. No other API guarantees are made regarding
in-place resizing, but the current implementation also tries to resize large
and huge allocations in place, as long as the pre-size and post-size are
both large or both huge. In such cases shrinkage always succeeds, but
growth only succeeds if the trailing memory is currently available.</para>
both large or both huge. In such cases shrinkage always succeeds for large
size classes, but for huge size classes the chunk allocator must support
splitting (see <link
linkend="arena.i.chunk_hooks"><mallctl>arena.&lt;i&gt;.chunk_hooks</mallctl></link>).
Growth only succeeds if the trailing memory is currently available, and
additionally for huge size classes the chunk allocator must support
merging.</para>
<para>Assuming 2 MiB chunks, 4 KiB pages, and a 16-byte quantum on a
64-bit system, the size classes in each category are as shown in <xref
@ -1557,7 +1562,8 @@ typedef struct {
(and often less costly) operations. The chunk splitting and merging
operations can also be opted out of, but this is mainly intended to
support platforms on which virtual memory mappings provided by the
operating system kernel do not automatically coalesce and split.</para>
operating system kernel do not automatically coalesce and split, e.g.
Windows.</para>
<para><funcsynopsis><funcprototype>
<funcdef>typedef void *<function>(chunk_alloc_t)</function></funcdef>