prior to 3.0.0 release) as contrib/jemalloc, and integrate it into libc. The code being imported by this commit diverged from lib/libc/stdlib/malloc.c in March 2010, which means that a portion of the jemalloc 1.0.0 ChangeLog entries are relevant, as are the entries for all subsequent releases.
MALLOC_OPTIONS environment variable, not JEMALLOC_OPTIONS. Reviewed by: jasone Approved by: emaste (mentor)
They have no effect when coming in pairs, or before .Bl/.Bd
Approved by: rrs (mentor)
Approved by: rrs (mentor)
* Fix a race in chunk_dealloc_dss().
* Check for allocation failure before zeroing memory in base_calloc().
Merge enhancements from a divergent version of jemalloc:
* Convert thread-specific caching from magazines to an algorithm that is
more tunable, and implement incremental GC.
* Add support for medium size classes, [4KiB..32KiB], 2KiB apart by
default.
* Add dirty page tracking for pages within active small/medium object
runs. This allows malloc to track precisely which pages are in active
use, which makes dirty page purging more effective.
* Base maximum dirty page count on proportion of active memory.
* Use optional zeroing in arena_chunk_alloc() to avoid needless zeroing
of chunks. This is useful in the context of DSS allocation, since a
long-lived application may commonly recycle chunks.
* Increase the default chunk size from 1MiB to 4MiB.
Remove feature:
* Remove the dynamic rebalancing code, since thread caching reduces its
utility.
a large page size that is greater than malloc(3)'s default chunk size but less than or equal to 4 MB, then increase the chunk size to match the large page size. Most often, using a chunk size that is less than the large page size is not a problem. However, consider a long-running application that allocates and frees significant amounts of memory. In particular, it frees enough memory at times that some of that memory is munmap()ed. Up until the first munmap(), a 1MB chunk size is just fine; it's not a problem for the virtual memory system. Two adjacent 1MB chunks that are aligned on a 2MB boundary will be promoted automatically to a superpage even though they were allocated at different times. The trouble begins with the munmap(), releasing a 1MB chunk will trigger the demotion of the containing superpage, leaving behind a half-used 2MB reservation. Now comes the real problem. Unfortunately, when the application needs to allocate more memory, and it recycles the previously munmap()ed address range, the implementation of mmap() won't be able to reuse the reservation. Basically, the coalescing rules in the virtual memory system don't allow this new range to combine with its neighbor. The effect being that superpage promotion will not reoccur for this range of addresses until both 1MB chunks are freed at some point in the future. Reviewed by: jasone MFC after: 3 weeks
potential extreme contention in the kernel for multi-threaded applications on SMP systems. Reported by: kris
This caching allows for completely lock-free allocation/deallocation in the steady state, at the expense of likely increased memory use and fragmentation. Reduce the default number of arenas to 2*ncpus, since thread-specific caching typically reduces arena contention. Modify size class spacing to include ranges of 2^n-spaced, quantum-spaced, cacheline-spaced, and subpage-spaced size classes. The advantages are: fewer size classes, reduced false cacheline sharing, and reduced internal fragmentation for allocations that are slightly over 512, 1024, etc. Increase RUN_MAX_SMALL, in order to limit fragmentation for the subpage-spaced size classes. Add a size-->bin lookup table for small sizes to simplify translating sizes to size classes. Include a hard-coded constant table that is used unless custom size class spacing is specified at run time. Add the ability to disable tiny size classes at compile time via MALLOC_TINY.