2010-01-17 01:53:50 +08:00
|
|
|
/******************************************************************************/
|
|
|
|
#ifdef JEMALLOC_H_TYPES
|
|
|
|
|
|
|
|
#endif /* JEMALLOC_H_TYPES */
|
|
|
|
/******************************************************************************/
|
|
|
|
#ifdef JEMALLOC_H_STRUCTS
|
|
|
|
|
|
|
|
#endif /* JEMALLOC_H_STRUCTS */
|
|
|
|
/******************************************************************************/
|
|
|
|
#ifdef JEMALLOC_H_EXTERNS
|
|
|
|
|
2014-10-10 08:54:06 +08:00
|
|
|
void *huge_malloc(tsd_t *tsd, arena_t *arena, size_t size, bool zero,
|
2015-01-30 07:30:47 +08:00
|
|
|
tcache_t *tcache);
|
2014-10-06 08:54:10 +08:00
|
|
|
void *huge_palloc(tsd_t *tsd, arena_t *arena, size_t usize, size_t alignment,
|
2015-01-30 07:30:47 +08:00
|
|
|
bool zero, tcache_t *tcache);
|
2014-01-13 07:05:44 +08:00
|
|
|
bool huge_ralloc_no_move(void *ptr, size_t oldsize, size_t size,
|
Attempt to expand huge allocations in-place.
This adds support for expanding huge allocations in-place by requesting
memory at a specific address from the chunk allocator.
It's currently only implemented for the chunk recycling path, although
in theory it could also be done by optimistically allocating new chunks.
On Linux, it could attempt an in-place mremap. However, that won't work
in practice since the heap is grown downwards and memory is not unmapped
(in a normal build, at least).
Repeated vector reallocation micro-benchmark:
#include <string.h>
#include <stdlib.h>
int main(void) {
for (size_t i = 0; i < 100; i++) {
void *ptr = NULL;
size_t old_size = 0;
for (size_t size = 4; size < (1 << 30); size *= 2) {
ptr = realloc(ptr, size);
if (!ptr) return 1;
memset(ptr + old_size, 0xff, size - old_size);
old_size = size;
}
free(ptr);
}
}
The glibc allocator fails to do any in-place reallocations on this
benchmark once it passes the M_MMAP_THRESHOLD (default 128k) but it
elides the cost of copies via mremap, which is currently not something
that jemalloc can use.
With this improvement, jemalloc still fails to do any in-place huge
reallocations for the first outer loop, but then succeeds 100% of the
time for the remaining 99 iterations. The time spent doing allocations
and copies drops down to under 5%, with nearly all of it spent doing
purging + faulting (when huge pages are disabled) and the array memset.
An improved mremap API (MREMAP_RETAIN - #138) would be far more general
but this is a portable optimization and would still be useful on Linux
for xallocx.
Numbers with transparent huge pages enabled:
glibc (copies elided via MREMAP_MAYMOVE): 8.471s
jemalloc: 17.816s
jemalloc + no-op madvise: 13.236s
jemalloc + this commit: 6.787s
jemalloc + this commit + no-op madvise: 6.144s
Numbers with transparent huge pages disabled:
glibc (copies elided via MREMAP_MAYMOVE): 15.403s
jemalloc: 39.456s
jemalloc + no-op madvise: 12.768s
jemalloc + this commit: 15.534s
jemalloc + this commit + no-op madvise: 6.354s
Closes #137
2014-10-04 13:39:32 +08:00
|
|
|
size_t extra, bool zero);
|
2014-09-23 12:09:23 +08:00
|
|
|
void *huge_ralloc(tsd_t *tsd, arena_t *arena, void *ptr, size_t oldsize,
|
|
|
|
size_t size, size_t extra, size_t alignment, bool zero,
|
2015-01-30 07:30:47 +08:00
|
|
|
tcache_t *tcache);
|
2014-01-08 08:47:56 +08:00
|
|
|
#ifdef JEMALLOC_JET
|
|
|
|
typedef void (huge_dalloc_junk_t)(void *, size_t);
|
|
|
|
extern huge_dalloc_junk_t *huge_dalloc_junk;
|
|
|
|
#endif
|
2015-01-30 07:30:47 +08:00
|
|
|
void huge_dalloc(tsd_t *tsd, void *ptr, tcache_t *tcache);
|
2014-11-28 03:22:36 +08:00
|
|
|
arena_t *huge_aalloc(const void *ptr);
|
2010-01-17 01:53:50 +08:00
|
|
|
size_t huge_salloc(const void *ptr);
|
2014-08-19 07:22:13 +08:00
|
|
|
prof_tctx_t *huge_prof_tctx_get(const void *ptr);
|
|
|
|
void huge_prof_tctx_set(const void *ptr, prof_tctx_t *tctx);
|
2010-01-17 01:53:50 +08:00
|
|
|
|
|
|
|
#endif /* JEMALLOC_H_EXTERNS */
|
|
|
|
/******************************************************************************/
|
|
|
|
#ifdef JEMALLOC_H_INLINES
|
|
|
|
|
|
|
|
#endif /* JEMALLOC_H_INLINES */
|
|
|
|
/******************************************************************************/
|