From owner-freebsd-hackers Tue Oct 22 1:27:31 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 027EC37B401 for ; Tue, 22 Oct 2002 01:27:29 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 903FE43E4A for ; Tue, 22 Oct 2002 01:27:28 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0084.cvx21-bradley.dialup.earthlink.net ([209.179.192.84] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 183uNg-0002Wd-00; Tue, 22 Oct 2002 01:27:17 -0700 Message-ID: <3DB50A5A.F87EDA78@mindspring.com> Date: Tue, 22 Oct 2002 01:20:42 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Danny Braniss Cc: Poul-Henning Kamp , freebsd-hackers@FreeBSD.ORG Subject: Re: malloc References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Danny Braniss wrote: > > If you want GNU malloc behaviour, then you should install the port > > for the GNU allocator, and use it instead of the system allocator, > > and you will end up with the same behaviour that your application > > has on Linux. > > what ticked my curiosity was that the linux binary did work, while > the fbsd binary did the right thing with respect to the admin limits and > coredumped when the datasize limit was exeeded. The FreeBSD malloc uses anonymous pages mmap'ed off of /dev/zero. The Linux malloc uses pages added to the process address space via a call to sbrk. The FreeBSD malloc guarantees that the pages are zeroed before being obtained from the system; this is probably the majority of the cost. It is a security measure, so that you do not leak data from one process to another through anonymous pages. The Linux malloc does not. The FreeBSD malloc does not impose a size limit based on the (potential) collision of the stack with the heap. The Linux Malloc must impose a memory limit based on the possibility of such a collision. The FreeBSD malloc allocates untouched pages: the pages are faulted in when they are accessed. The Linux malloc pays the penalty up front, and so doesn't run into a usage shortage, if you use a thrashing access pattern, like your example "application" used, to intentionally thrash memory (twice; once on allocation, once again on checking of the reference, after). The FreeBSD malloc references an environment variable and a readlink() of a potentially non-existant symbolic link containing configuration data for the malloc. The Linux malloc does not have this overhead. The FreeBSD malloc would be lower performance than the Linux malloc, if you allocate space in teeny, tiny chunks; it has much higher performance for large allocations. Good programmers allocate their resources up front, once, instead of doing the allocations in time critical internal loops. The FreeBSD allocation is an overcommit allocation; this means that the malloc could succeed, obtain a memory mapping for the pages, but run out of pages to use as backing store for the address space so mapped. This *only* happens if the administrative limits on the applications are larger than the available physical resources: don't do that: "man login.conf", "man limit". If you want to have the Linux malloc behaviour on FreeBSD, then link your application with the Linux malloc library. It is available as a port for you to install on your FreeBSD system: cd /usr/ports/devel/libmalloc make all install ...and them link your applications with the "malloc" library, instead of using the system malloc. Can't really make it any more clear than that. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message