[rfc] enabling MALLOC_PRODUCTION on -HEAD for now, until jemalloc has been taught to have some run time selectable debug options

[Jason Evans]

On Jan 19, 2013, at 10:26 PM, Adrian Chadd wrote:
> I'd like to enable MALLOC_PRODUCTION on -HEAD.
> 
> I'm currently recompiling my libc on this g4 powerbook because the
> -HEAD snapshots don't have it enabled by default; just to get some
> damned decent performance out of this thing.
> 
> I'll work with Jason and others (eg Ian) who have a vested interest in
> trying to get it to run better out of the box, but still have the
> debug options available for people who wish to debug things.

I imported jemalloc 3.3.0 last night, which I think will restore non-MALLOC_PRODUCTION performance to roughly what it has been for years.  The key change was a patch by Ian Lepore:

	http://www.canonware.com/cgi-bin/gitweb.cgi?p=jemalloc.git;a=commitdiff;h=14a2c6a698a207ac3f3825443cf3441c8842e990

In practice, the zeroed memory validation should no longer execute at all on FreeBSD due to madvise(...MADV_FREE) not guaranteeing zeroed memory.

I don't know how significant the impact will be on constrained/older systems, but for the many buildworld repetitions I did during testing it improved throughput by >1.5X.  With this change in place, I'm not keen on enabling MALLOC_PRODUCTION by default, because the assertions are useful both for detecting bugs in jemalloc (heaven forbid), and for indicating that crashes within jemalloc are application errors.  The only other significant source of overhead I'm aware of is junk filling, which we've had enabled by default on -current for ages, probably since the introduction of phkmalloc.  If you don't like it:

	ln -s 'junk:false' /etc/malloc.conf

If a substantial performance difference remains for you (MALLOC_PRODUCTION vs non-MALLOC_PRODUCTION with junk:false set), please let me know.

Thanks,
Jason