Date: Tue, 22 Oct 2002 12:01:19 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Tony Finch <dot@dotat.at> Cc: hackers@freebsd.org Subject: Re: malloc Message-ID: <3DB5A07F.AA118FA6@mindspring.com> References: <E183u5Y-0003Yc-00@cse.cs.huji.ac.il> <E183xYK-0003aB-00@chiark.greenend.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Tony Finch wrote: > Terry Lambert <tlambert2@mindspring.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB5A07F.AA118FA6>