From owner-freebsd-hackers Tue Oct 22 12: 2:39 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 48DB237B401 for ; Tue, 22 Oct 2002 12:02:37 -0700 (PDT) Received: from scaup.mail.pas.earthlink.net (scaup.mail.pas.earthlink.net [207.217.120.49]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC68243E77 for ; Tue, 22 Oct 2002 12:02:36 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0482.cvx21-bradley.dialup.earthlink.net ([209.179.193.227] helo=mindspring.com) by scaup.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1844IQ-0003b6-00; Tue, 22 Oct 2002 12:02:30 -0700 Message-ID: <3DB5A07F.AA118FA6@mindspring.com> Date: Tue, 22 Oct 2002 12:01:19 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tony Finch Cc: 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 Tony Finch wrote: > Terry Lambert wrote: > >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. > > Utter bollocks. FreeBSD malloc can be configured to re-initialize memory > on every allocation, but this is designed to assist with buggy programs, > it is *not* a security measure. Memory obtained from the kernel on *all* > unices (including Linux) is zeroed; that is when security matters, not > in malloc. This will not affect the relative performance of phk and gnu > malloc. *before being obtained from the system*. Once the application owns the memory, then it is the application's job to enforce security domains between threads. Since different threads can't have different credentials anyway (without assuming the threading inplementation), there are no guarantees that a *reallocation* will result in empty pages. And I didn't say that. I only said that the pages were zeroed *before being obtained from the system*. This is what you would expect, with anonymous memory accessed off /dev/zero. > >The FreeBSD malloc references an environment variable and a readlink() > >of a potentially non-existant symbolic link containing configuration > >data for the malloc. > > Once at program startup. This is not a significant cost. It is part of the overhead which he is measuring relative to the Linux implementation. > > >The FreeBSD allocation is an overcommit allocation > > True for Linux too, by default. There are some fundamental differences in sbrk() vs. mmap() based allocators, un terms of returning pages to the system following a free(). The FreeBSD implementation returns the pages back to the system very aggressively, which makes it much more apparently overcommit. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message