HEADSUP: malloc changeover

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