From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4450 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Removing sbrk and brk Date: Fri, 3 Jan 2014 12:33:01 -0500 Message-ID: <20140103173301.GU24286@brightrain.aerifal.cx> References: <20131221234041.GA13204@brightrain.aerifal.cx> <20131222184855.GS1685@port70.net> <20131223044609.GZ24286@brightrain.aerifal.cx> <20140102220302.GR24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1388770388 11321 80.91.229.3 (3 Jan 2014 17:33:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Jan 2014 17:33:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4454-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jan 03 18:33:16 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Vz8cV-0001u3-Kw for gllmg-musl@plane.gmane.org; Fri, 03 Jan 2014 18:33:15 +0100 Original-Received: (qmail 5125 invoked by uid 550); 3 Jan 2014 17:33:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 4093 invoked from network); 3 Jan 2014 17:33:14 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4450 Archived-At: On Fri, Jan 03, 2014 at 11:51:32AM +0000, Thorsten Glaser wrote: > Rich Felker aerifal.cx> writes: > > > sbrk may be re-added sometime after 1.0 if malloc is changed to no > > longer use the brk (option 5 above). > > You may want to import omalloc (based on mmap malloc, written from > scratch by Otto Moerbeek) with lots of security features: This discussion is about improving one aspect of malloc, not replacing it with a third-party implementation. The reason musl is significantly smaller and more maintainable than glibc and uclibc is that it's not a hodge-podge of copy-and-paste from various legacy code. I suspect omalloc is considerably higher quality than a lot of the things those two implementations copied, but from casual inspection, it doesn't look anywhere near as small or high-performance as musl's. The actual motivation for moving to mmap in malloc is twofold: preventing allocation failure when expansion of the brk is blocked by an inconveniently-placed mapping, and unifying an idea I have in mind for actually returning unneeded commit charge (right now, musl returns unneeded physical memory but not commit charge). > http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/malloc.c > http://www.openbsd.org/cgi-bin/man.cgi?query=malloc > > It does assume that mmap() is randomised and NULs the result. If so, this is a rather odd (incorrect) assumption and results in highly suboptimal behavior (O(n) malloc in place of O(1), where n is the size of the allocation). Rich