From owner-freebsd-current@FreeBSD.ORG Fri Jan 13 18:42:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07EC816A41F for ; Fri, 13 Jan 2006 18:42:00 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC4143D48 for ; Fri, 13 Jan 2006 18:41:59 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 1CD995E48DA; Fri, 13 Jan 2006 10:41:59 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 9E66F5E488A for ; Fri, 13 Jan 2006 10:41:56 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <1A89617A-5F0E-492E-8C21-10A4F679BCD2@freebsd.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Jason Evans Date: Fri, 13 Jan 2006 10:41:52 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Subject: HEADSUP: malloc changeover X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 18:42:00 -0000 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