Re: [HACKERS] new heap manager mmalloc - Mailing list pgsql-hackers

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, USAEveryone is
permittedto copy and distribute verbatim copiesof this license document, but changing it is not allowed.
 

[This is the first released version of the library GPL.  It isnumbered 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@uvo.do.eunet.de
> 
>                      " As a human being I claim the right
>                        to be widely inconsistent " John Peel              
>  
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 

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