From 38f864947bc63ff2728cf23905682612418404fb Mon Sep 17 00:00:00 2001 From: Jason Evans Date: Fri, 14 Aug 2015 00:55:44 -0700 Subject: [PATCH] Update in-place reallocation documentation. --- doc/jemalloc.xml.in | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/doc/jemalloc.xml.in b/doc/jemalloc.xml.in index dd9387f1..e12abb0d 100644 --- a/doc/jemalloc.xml.in +++ b/doc/jemalloc.xml.in @@ -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. + 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 arena.<i>.chunk_hooks). + Growth only succeeds if the trailing memory is currently available, and + additionally for huge size classes the chunk allocator must support + merging. 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 + operating system kernel do not automatically coalesce and split, e.g. + Windows. typedef void *(chunk_alloc_t)