Update jemalloc to 4.1.0.

Add missing Symbol.map entry for __aligned_alloc.

Add weak-->strong symbol binding for
{malloc_stats_print,mallctl,mallctlnametomib,mallctlbymib} -->
{__malloc_stats_print,__mallctl,__mallctlnametomib,__mallctlbymib}.  These
bindings complete the set necessary to allow applications to replace all
malloc-related symbols.

1 files changed, 143 insertions, 19 deletions

diff --git a/contrib/jemalloc/doc/jemalloc.3 b/contrib/jemalloc/doc/jemalloc.3
index 57e163d..c47f417 100644
--- a/contrib/jemalloc/doc/jemalloc.3
+++ b/contrib/jemalloc/doc/jemalloc.3
@@ -2,12 +2,12 @@
 .\"     Title: JEMALLOC
 .\"    Author: Jason Evans
 .\" Generator: DocBook XSL Stylesheets v1.76.1 <http://docbook.sf.net/>
-.\"      Date: 10/24/2015
+.\"      Date: 02/28/2016
 .\"    Manual: User Manual
-.\"    Source: jemalloc 4.0.4-0-g91010a9e2ebfc84b1ac1ed7fdde3bfed4f65f180
+.\"    Source: jemalloc 4.1.0-1-g994da4232621dd1210fcf39bdf0d6454cefda473
 .\"  Language: English
 .\"
-.TH "JEMALLOC" "3" "10/24/2015" "jemalloc 4.0.4-0-g91010a9e2ebf" "User Manual"
+.TH "JEMALLOC" "3" "02/28/2016" "jemalloc 4.1.0-1-g994da4232621" "User Manual"
 .\" -----------------------------------------------------------------
 .\" * Define some portability stuff
 .\" -----------------------------------------------------------------
@@ -31,7 +31,7 @@
 jemalloc \- general purpose memory allocation functions
 .SH "LIBRARY"
 .PP
-This manual describes jemalloc 4\&.0\&.4\-0\-g91010a9e2ebfc84b1ac1ed7fdde3bfed4f65f180\&. More information can be found at the
+This manual describes jemalloc 4\&.1\&.0\-1\-g994da4232621dd1210fcf39bdf0d6454cefda473\&. More information can be found at the
 \m[blue]\fBjemalloc website\fR\m[]\&\s-2\u[1]\d\s+2\&.
 .PP
 The following configuration options are enabled in libc\*(Aqs built\-in jemalloc:
@@ -244,7 +244,7 @@ function allocates at least
 bytes of memory, and returns a pointer to the base address of the allocation\&. Behavior is undefined if
 \fIsize\fR
 is
-\fB0\fR, or if request size overflows due to size class and/or alignment constraints\&.
+\fB0\fR\&.
 .PP
 The
 \fBrallocx\fR\fB\fR
@@ -255,7 +255,7 @@ to be at least
 bytes, and returns a pointer to the base address of the resulting allocation, which may or may not have moved from its original location\&. Behavior is undefined if
 \fIsize\fR
 is
-\fB0\fR, or if request size overflows due to size class and/or alignment constraints\&.
+\fB0\fR\&.
 .PP
 The
 \fBxallocx\fR\fB\fR
@@ -301,10 +301,12 @@ function allocates no memory, but it performs the same size computation as the
 \fBmallocx\fR\fB\fR
 function, and returns the real size of the allocation that would result from the equivalent
 \fBmallocx\fR\fB\fR
-function call\&. Behavior is undefined if
+function call, or
+\fB0\fR
+if the inputs exceed the maximum supported size class and/or alignment\&. Behavior is undefined if
 \fIsize\fR
 is
-\fB0\fR, or if request size overflows due to size class and/or alignment constraints\&.
+\fB0\fR\&.
 .PP
 The
 \fBmallctl\fR\fB\fR
@@ -404,7 +406,8 @@ should not be depended on, since such behavior is entirely implementation\-depen
 .PP
 Once, when the first call is made to one of the memory allocation routines, the allocator initializes its internals based in part on various options that can be specified at compile\- or run\-time\&.
 .PP
-The string pointed to by the global variable
+The string specified via
+\fB\-\-with\-malloc\-conf\fR, the string pointed to by the global variable
 \fImalloc_conf\fR, the \(lqname\(rq of the file referenced by the symbolic link named
 /etc/malloc\&.conf, and the value of the environment variable
 \fBMALLOC_CONF\fR, will be interpreted, in that order, from left to right as options\&. Note that
@@ -414,8 +417,10 @@ may be read before
 is entered, so the declaration of
 \fImalloc_conf\fR
 should specify an initializer that contains the final value to be read by jemalloc\&.
+\fB\-\-with\-malloc\-conf\fR
+and
 \fImalloc_conf\fR
-is a compile\-time setting, whereas
+are compile\-time mechanisms, whereas
 /etc/malloc\&.conf
 and
 \fBMALLOC_CONF\fR
@@ -451,11 +456,7 @@ In addition to multiple arenas, unless
 \fB\-\-disable\-tcache\fR
 is specified during configuration, this allocator supports thread\-specific caching for small and large objects, in order to make it possible to completely avoid synchronization for most allocation requests\&. Such caching allows very fast allocation in the common case, but it increases memory usage and fragmentation, since a bounded number of objects can remain allocated in each thread cache\&.
 .PP
-Memory is conceptually broken into equal\-sized chunks, where the chunk size is a power of two that is greater than the page size\&. Chunks are always aligned to multiples of the chunk size\&. This alignment makes it possible to find metadata for user objects very quickly\&.
-.PP
-User objects are broken into three categories according to size: small, large, and huge\&. Small and large objects are managed entirely by arenas; huge objects are additionally aggregated in a single data structure that is shared by all threads\&. Huge objects are typically used by applications infrequently enough that this single data structure is not a scalability issue\&.
-.PP
-Each chunk that is managed by an arena tracks its contents as runs of contiguous pages (unused, backing a set of small objects, or backing one large object)\&. The combination of chunk alignment and chunk page maps makes it possible to determine all metadata regarding small and large allocations in constant time\&.
+Memory is conceptually broken into equal\-sized chunks, where the chunk size is a power of two that is greater than the page size\&. Chunks are always aligned to multiples of the chunk size\&. This alignment makes it possible to find metadata for user objects very quickly\&. User objects are broken into three categories according to size: small, large, and huge\&. Multiple small and large objects can reside within a single chunk, whereas huge objects each have one or more chunks backing them\&. Each chunk that contains small and/or large objects tracks its contents as runs of contiguous pages (unused, backing a set of small objects, or backing one large object)\&. The combination of chunk alignment and chunk page maps makes it possible to determine all metadata regarding small and large allocations in constant time\&.
 .PP
 Small objects are managed in groups by page runs\&. Each run maintains a bitmap to track which regions are in use\&. Allocation requests that are no more than half the quantum (8 or 16, depending on architecture) are rounded up to the nearest power of two that is at least
 sizeof(\fBdouble\fR)\&. All other object size classes are multiples of the quantum, spaced such that there are four size classes for each doubling in size, which limits internal fragmentation to approximately 20% for all but the smallest size classes\&. Small size classes are smaller than four times the page size, large size classes are smaller than the chunk size (see the
@@ -703,6 +704,13 @@ was specified during build configuration\&.
 was specified during build configuration\&.
 .RE
 .PP
+"config\&.malloc_conf" (\fBconst char *\fR) r\-
+.RS 4
+Embedded configure\-time\-specified run\-time options string, empty unless
+\fB\-\-with\-malloc\-conf\fR
+was specified during build configuration\&.
+.RE
+.PP
 "config\&.munmap" (\fBbool\fR) r\-
 .RS 4
 \fB\-\-enable\-munmap\fR
@@ -788,11 +796,20 @@ is supported by the operating system; \(lqdisabled\(rq otherwise\&.
 Virtual memory chunk size (log base 2)\&. If a chunk size outside the supported size range is specified, the size is silently clipped to the minimum/maximum supported size\&. The default chunk size is 2 MiB (2^21)\&.
 .RE
 .PP
-"opt\&.narenas" (\fBsize_t\fR) r\-
+"opt\&.narenas" (\fBunsigned\fR) r\-
 .RS 4
 Maximum number of arenas to use for automatic multiplexing of threads and arenas\&. The default is four times the number of CPUs, or one if there is a single CPU\&.
 .RE
 .PP
+"opt\&.purge" (\fBconst char *\fR) r\-
+.RS 4
+Purge mode is \(lqratio\(rq (default) or \(lqdecay\(rq\&. See
+"opt\&.lg_dirty_mult"
+for details of the ratio mode\&. See
+"opt\&.decay_time"
+for details of the decay mode\&.
+.RE
+.PP
 "opt\&.lg_dirty_mult" (\fBssize_t\fR) r\-
 .RS 4
 Per\-arena minimum ratio (log base 2) of active to dirty pages\&. Some dirty unused pages may be allowed to accumulate, within the limit set by the ratio (or one chunk worth of dirty pages, whichever is greater), before informing the kernel about some of those pages via
@@ -804,6 +821,15 @@ and
 for related dynamic control options\&.
 .RE
 .PP
+"opt\&.decay_time" (\fBssize_t\fR) r\-
+.RS 4
+Approximate time in seconds from the creation of a set of unused dirty pages until an equivalent set of unused dirty pages is purged and/or reused\&. The pages are incrementally purged according to a sigmoidal decay curve that starts and ends with zero purge rate\&. A decay time of 0 causes all unused dirty pages to be purged immediately upon creation\&. A decay time of \-1 disables purging\&. The default decay time is 10 seconds\&. See
+"arenas\&.decay_time"
+and
+"arena\&.<i>\&.decay_time"
+for related dynamic control options\&.
+.RE
+.PP
 "opt\&.stats_print" (\fBbool\fR) r\-
 .RS 4
 Enable/disable statistics printing at exit\&. If enabled, the
@@ -914,7 +940,9 @@ option for final profile dumping\&. Profile output is compatible with the
 command, which is based on the
 \fBpprof\fR
 that is developed as part of the
-\m[blue]\fBgperftools package\fR\m[]\&\s-2\u[3]\d\s+2\&.
+\m[blue]\fBgperftools package\fR\m[]\&\s-2\u[3]\d\s+2\&. See
+HEAP PROFILE FORMAT
+for heap profile format documentation\&.
 .RE
 .PP
 "opt\&.prof_prefix" (\fBconst char *\fR) r\- [\fB\-\-enable\-prof\fR]
@@ -1063,7 +1091,7 @@ macro to explicitly use the specified cache rather than the automatically manage
 "tcache\&.flush" (\fBunsigned\fR) \-w [\fB\-\-enable\-tcache\fR]
 .RS 4
 Flush the specified thread\-specific cache (tcache)\&. The same considerations apply to this interface as to
-"thread\&.tcache\&.flush", except that the tcache will never be automatically be discarded\&.
+"thread\&.tcache\&.flush", except that the tcache will never be automatically discarded\&.
 .RE
 .PP
 "tcache\&.destroy" (\fBunsigned\fR) \-w [\fB\-\-enable\-tcache\fR]
@@ -1073,10 +1101,18 @@ Flush the specified thread\-specific cache (tcache) and make the identifier avai
 .PP
 "arena\&.<i>\&.purge" (\fBvoid\fR) \-\-
 .RS 4
-Purge unused dirty pages for arena <i>, or for all arenas if <i> equals
+Purge all unused dirty pages for arena <i>, or for all arenas if <i> equals
 "arenas\&.narenas"\&.
 .RE
 .PP
+"arena\&.<i>\&.decay" (\fBvoid\fR) \-\-
+.RS 4
+Trigger decay\-based purging of unused dirty pages for arena <i>, or for all arenas if <i> equals
+"arenas\&.narenas"\&. The proportion of unused dirty pages to be purged depends on the current time; see
+"opt\&.decay_time"
+for details\&.
+.RE
+.PP
 "arena\&.<i>\&.dss" (\fBconst char *\fR) rw
 .RS 4
 Set the precedence of dss allocation as related to mmap allocation for arena <i>, or for all arenas if <i> equals
@@ -1092,6 +1128,13 @@ Current per\-arena minimum ratio (log base 2) of active to dirty pages for arena
 for additional information\&.
 .RE
 .PP
+"arena\&.<i>\&.decay_time" (\fBssize_t\fR) rw
+.RS 4
+Current per\-arena approximate time in seconds from the creation of a set of unused dirty pages until an equivalent set of unused dirty pages is purged and/or reused\&. Each time this interface is set, all currently unused dirty pages are considered to have fully decayed, which causes immediate purging of all unused dirty pages unless the decay time is set to \-1 (i\&.e\&. purging disabled)\&. See
+"opt\&.decay_time"
+for additional information\&.
+.RE
+.PP
 "arena\&.<i>\&.chunk_hooks" (\fBchunk_hooks_t\fR) rw
 .RS 4
 Get or set the chunk management hook functions for arena <i>\&. The functions must be capable of operating on all extant chunks associated with arena <i>, usually by passing unknown chunks to the replaced functions\&. In practice, it is feasible to control allocation for arenas created via
@@ -1332,6 +1375,15 @@ during arena creation\&. See
 for additional information\&.
 .RE
 .PP
+"arenas\&.decay_time" (\fBssize_t\fR) rw
+.RS 4
+Current default per\-arena approximate time in seconds from the creation of a set of unused dirty pages until an equivalent set of unused dirty pages is purged and/or reused, used to initialize
+"arena\&.<i>\&.decay_time"
+during arena creation\&. See
+"opt\&.decay_time"
+for additional information\&.
+.RE
+.PP
 "arenas\&.quantum" (\fBsize_t\fR) r\-
 .RS 4
 Quantum size\&.
@@ -1511,6 +1563,13 @@ Minimum ratio (log base 2) of active to dirty pages\&. See
 for details\&.
 .RE
 .PP
+"stats\&.arenas\&.<i>\&.decay_time" (\fBssize_t\fR) r\-
+.RS 4
+Approximate time in seconds from the creation of a set of unused dirty pages until an equivalent set of unused dirty pages is purged and/or reused\&. See
+"opt\&.decay_time"
+for details\&.
+.RE
+.PP
 "stats\&.arenas\&.<i>\&.nthreads" (\fBunsigned\fR) r\-
 .RS 4
 Number of threads currently assigned to arena\&.
@@ -1712,6 +1771,71 @@ Cumulative number of allocation requests for this size class\&.
 .RS 4
 Current number of huge allocations for this size class\&.
 .RE
+.SH "HEAP PROFILE FORMAT"
+.PP
+Although the heap profiling functionality was originally designed to be compatible with the
+\fBpprof\fR
+command that is developed as part of the
+\m[blue]\fBgperftools package\fR\m[]\&\s-2\u[3]\d\s+2, the addition of per thread heap profiling functionality required a different heap profile format\&. The
+\fBjeprof\fR
+command is derived from
+\fBpprof\fR, with enhancements to support the heap profile format described here\&.
+.PP
+In the following hypothetical heap profile,
+\fB[\&.\&.\&.]\fR
+indicates elision for the sake of compactness\&.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+heap_v2/524288
+  t*: 28106: 56637512 [0: 0]
+  [\&.\&.\&.]
+  t3: 352: 16777344 [0: 0]
+  [\&.\&.\&.]
+  t99: 17754: 29341640 [0: 0]
+  [\&.\&.\&.]
+@ 0x5f86da8 0x5f5a1dc [\&.\&.\&.] 0x29e4d4e 0xa200316 0xabb2988 [\&.\&.\&.]
+  t*: 13: 6688 [0: 0]
+  t3: 12: 6496 [0: ]
+  t99: 1: 192 [0: 0]
+[\&.\&.\&.]
+
+MAPPED_LIBRARIES:
+[\&.\&.\&.]
+.fi
+.if n \{\
+.RE
+.\}
+.sp
+The following matches the above heap profile, but most tokens are replaced with
+\fB<description>\fR
+to indicate descriptions of the corresponding fields\&.
+.sp
+.if n \{\
+.RS 4
+.\}
+.nf
+<heap_profile_format_version>/<mean_sample_interval>
+  <aggregate>: <curobjs>: <curbytes> [<cumobjs>: <cumbytes>]
+  [\&.\&.\&.]
+  <thread_3_aggregate>: <curobjs>: <curbytes>[<cumobjs>: <cumbytes>]
+  [\&.\&.\&.]
+  <thread_99_aggregate>: <curobjs>: <curbytes>[<cumobjs>: <cumbytes>]
+  [\&.\&.\&.]
+@ <top_frame> <frame> [\&.\&.\&.] <frame> <frame> <frame> [\&.\&.\&.]
+  <backtrace_aggregate>: <curobjs>: <curbytes> [<cumobjs>: <cumbytes>]
+  <backtrace_thread_3>: <curobjs>: <curbytes> [<cumobjs>: <cumbytes>]
+  <backtrace_thread_99>: <curobjs>: <curbytes> [<cumobjs>: <cumbytes>]
+[\&.\&.\&.]
+
+MAPPED_LIBRARIES:
+</proc/<pid>/maps>
+.fi
+.if n \{\
+.RE
+.\}
 .SH "DEBUGGING MALLOC PROBLEMS"
 .PP
 When debugging, it is a good idea to configure/build jemalloc with the