HEADSUP: malloc changeover
Jason Evans
jasone at freebsd.org
Fri Jan 13 10:42:00 PST 2006
libc's malloc(3) implementation has been replaced. For now, all
debugging, sanity, and statistics gathering options are enabled,
which means that you can expect your programs to run slower and take
up more memory. We can shut these pessimizations off once it looks
like the transition pains are mostly over.
If you need better performance, undefine one or more of the following
in src/lib/libc/stdlib/malloc.c:
MALLOC_DEBUG
MALLOC_STATS
MALLOC_REDZONES
All three slow programs down, and MALLOC_REDZONES also bloats memory
usage.
If you encounter runtime errors that you think are related to the
malloc changes, please look at the man page and read about the
various tuning flags, and use the relevant ones to try to narrow down
the nature of the problem. In particular, the 'A', 'J', 'Q', and 'Z'
flags may be useful for this.
The most likely types of application bugs that this malloc
implementation will uncover are:
* Bad alignment assumptions. This malloc implementation only
guarantees 16-byte alignment (for most architectures), even for very
large allocations. This is legal, but unusual. Note that phkmalloc
was very generous regarding object alignment. If you discover a bug
of this type in an application, see posix_memalign(3) when fixing the
problem.
* Buffer overruns. Since this malloc implementation uses boundary
tags, it is possible to corrupt internal malloc data structures by
writing outside the bounds of an allocation. Redzones will detect
small overruns, but not large ones.
I expect there to be numerous reports of problems as a result of this
change. Most of them will probably turn out to be application bugs,
but bugs in malloc are possible (even probable) as well. Let's all
keep open minds as to the causes of problems while diagnosing them.
Thanks,
Jason
More information about the freebsd-current
mailing list