mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: Re: Removing sbrk and brk
Date: Fri, 3 Jan 2014 13:19:06 -0500	[thread overview]
Message-ID: <20140103181906.GV24286@brightrain.aerifal.cx> (raw)
In-Reply-To: <20140103173301.GU24286@brightrain.aerifal.cx>

On Fri, Jan 03, 2014 at 12:33:01PM -0500, Rich Felker wrote:
> 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.
> 
> > http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libc/stdlib/malloc.c

Quick summary of omalloc:

- Uses mmap directly for allocations of at least PAGE_SIZE (vs musl
  which only uses mmap directly past 128k/256k limit).

- Rounds all allocation sizes up to a power of 2 (vs musl which has
  exact sizes for all mod-16-aligned sizes up to 512 bytes, or
  mod-32-aligned up to 1024 bytes on 64-bit, and above that every 1/4
  unit between successive powers of 2).

- Global lock (vs musl which uses local, per-bin locks, allowing
  allocations of different sizes not to touch the same locks).

- Allocations smaller than PAGE_SIZE are made by allocating a whole
  page of same-size objects that cannot be merged or resized in-place
  (vs musl which splits and combines free ranges as needed from a
  large, growable heap).

Overall my assessment is that omalloc is _simple_ (in some ways
simpler than musl's), but looks to have much worse fragmentation
properties, much worse performance properties (both syscall overhead
and locking come to mind), and no other clear advantages.

Rich


  reply	other threads:[~2014-01-03 18:19 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-21 23:40 Rich Felker
2013-12-22  2:15 ` Luca Barbato
2013-12-22 17:58   ` Richard Pennington
2013-12-22 18:21     ` Luca Barbato
2013-12-22 18:48 ` Szabolcs Nagy
2013-12-22 21:55   ` Christian Neukirchen
2013-12-23  4:46   ` Rich Felker
2014-01-02 22:03     ` Rich Felker
2014-01-03 11:51       ` Thorsten Glaser
2014-01-03 12:59         ` Daniel Cegiełka
2014-01-03 17:33         ` Rich Felker
2014-01-03 18:19           ` Rich Felker [this message]
2014-01-03 19:03             ` Rich Felker
2014-01-06 14:51               ` Thorsten Glaser
2014-01-06 22:40                 ` Rich Felker
2014-01-07  9:43                   ` Thorsten Glaser
2014-01-07 16:06                     ` Rich Felker
2014-01-07 22:00                       ` Rich Felker
2014-02-21 16:03                         ` Daniel Cegiełka
2014-02-21 16:36                           ` Szabolcs Nagy
2014-02-21 16:47                             ` Daniel Cegiełka
2014-02-21 17:09                               ` Rich Felker
2014-02-21 22:34                                 ` Daniel Cegiełka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140103181906.GV24286@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).