Re: [HACKERS] new heap manager mmalloc

Two things against it...

First, its a Linux-ism...he's got it ported to Win and Linux, that's it...

Second:

GNU LIBRARY GENERAL PUBLIC LICENSE
Version 2, June 1991

Copyright (C) 1991 Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

[This is the first released version of the library GPL. It is
numbered 2 because it goes with version 2 of the ordinary GPL.]

On Thu, 28 Jan 1999, Ulrich Voss wrote:

> Hi,
>
> FYI regarding the recent performance issues.
>
> This lib is ported to win32. I don't know, how many unixes are
> supported. Perhaps it's better to reuse something and not to
> reimplementit from scratch. But you are to decide.
>
> forwarded from comp.os.linux.announce
>
> ---
>
> mmalloc is a heap manager. It is written from a scratch. Main goals were
> accurate RAM consuming and performance. Goals achieved using relatively
> new virtual memory mapping techniques (known in UNIX wolrd as mmap ;-) and
> AVL trees.
>
> Major advantages of this heap manager:
> * Trimming and "no commit". mmalloc immediately (not in Windows
> world) releases all deallocated pages to the system. Also all
> allocated pages are not commited, because new areas are just mapped
> in, still not commited and only user program could commit memory. So
> the following rule is real true:
> "NO UNUSED MEMORY WILL BE CONSUMED".
>
> * Best-fit. Best-fit strategy was used. As shown in real world
> experiments, best-fit proven to be more accurate than first-fit.
>
> * AVL Trees. Primary internal structure used for controlling large
> blocks (>256 bytes, tunable). So the time consumed by allocating
> new block is proportional to O(log N), where N is the number of memory
> fragments. Implementation is in pure C and optimized.
>
> * Small blocks grouped. Small blocks are grouped within pages. This
> provides more accurate memory consuming. When doing 100000 times
> mmalloc(1) only ~130k of real memory will be allocated.
>
> * Smart alignment. Blocks smaller than MALLOC_ALIGN (tunable)
> are not aligned. (typical for i386 are blocks <4 bytes). Other
> blocks are aligned by MALLOC_ALIGN.
>
> * Small overhead. For blocks large blocks overhead is 32 bytes. It is
> approximately 12.5% for 256 bytes long block. For larger blocks size
> of this control structure is ever less noticed. Small blocks are
> grouped within one page and resulting overhead is less than
> 0.2% (8/4096*100).
>
> * Pure ANSI-C. Pure ANSI-C without any extensions was used. So library
> should be portable. Only vmm functions are not portable, other library
> parts should be.
>
> Visit homepage:
>
> http://www.geocities.com/SiliconValley/Circuit/5426/index.html
>
> Valery
>
> ----
>
> Ciao
>
> Ulrich
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Ulrich Vo"3 uvo(at)uvo(dot)do(dot)eunet(dot)de
>
> " As a human being I claim the right
> to be widely inconsistent " John Peel
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy(at)hub(dot)org secondary: scrappy(at){freebsd|postgresql}.org