Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 Oct 2002 19:05:55 +0100
From:      Christoph Hellwig <hch@infradead.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Danny Braniss <danny@cs.huji.ac.il>, Poul-Henning Kamp <phk@critter.freebsd.dk>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: malloc
Message-ID:  <20021022190555.A2655@infradead.org>
In-Reply-To: <3DB50A5A.F87EDA78@mindspring.com>; from tlambert2@mindspring.com on Tue, Oct 22, 2002 at 01:20:42AM -0700
References:  <E183u5Y-0003Yc-00@cse.cs.huji.ac.il> <3DB50A5A.F87EDA78@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 22, 2002 at 01:20:42AM -0700, Terry Lambert wrote:
> 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.

There is no "Linux malloc", neither does Linux have a sbrk syscall :)

But glibc malloc indeed uses both brk and mmap.

> 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.

glibc malloc doesn not guarantee you zeroed memory if you reuse memory
that was freed in your process.  Otherwise it's of course zeroed.

> 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.

glibc malloc reads a bunch of enviroment variables, though to
allow stuff like memleak debuging and such

> 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.

It's certainly debatable wehther the whole point of a userlevel
memory allocator like malloc() isn't avoiding the reimlementation
of a better allocator in each an every program :)


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?20021022190555.A2655>