Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF4BF-QqxqZU8-mv+jbf0a-5Wckw1ekk7TK3kpNZRRGeHbEzmA@mail.gmail.com>
Date: Mon, 30 Jul 2018 11:09:05 -0400
From: Christopher Friedt <chrisfriedt@...il.com>
To: musl@...ts.openwall.com
Subject: Re: malloc implementation survey: omalloc

I haven't looked at omalloc, but I wrote a deadly simple buddy allocator
for Bionic some time ago with support for malloc(3), calloc(3), realloc(3),
free(3), and posix_memalign(3). It would obviously also support
aligned_alloc(3) for C11.

It ran well on everything from a arm cortex-m0 to an intel core i7. The
code compiled to 504 .text bytes, on cortex-m0, iirc.

I wrote it originally for using on the kernel-side of an rtos, but it could
easily be extended to make a syscall when a process runs out of ram.

Obviously, a shortcoming is that the memory blocks must be PoT and there is
the potential for fragmentation. Otherwise though, the meta-information is
intrinsic within the pointer, which obliviates the need for external
storage.

Every call takes approximately the same average time which is about log2(
depth ) for binary trees.

Objectively speaking though, in terms of choosing a new malloc
implementation, the best one should be based on algorithmic complexity, but
also size and speed metrics.

C

Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.