Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] new heap manager mmalloc

From: "Patrick Welche" <prlw1(at)newn(dot)cam(dot)ac(dot)uk>
To: jwieck(at)debis(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] new heap manager mmalloc
Date: 1999-01-30 15:08:33
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Jan Wieck wrote:
>     Right  right  right!  Pooled allocation will gain performance
>     and the separate bookkeeping should be more useful.


>     But I can think of another thing that might help. A temporary
>     allocation pool stack.
>     The functions to manage it are:
>         void tmppalloc_push(void);
>         void tmppalloc_pop(void);
>         void *tmppalloc(Size size);
>         void *tmpuppalloc(Size size, int levels_up);

You might be interested in:

POOL(9)                      NetBSD Kernel Manual                      POOL(9)

     pool_create, pool_destroy, pool_get, pool_put, pool_prime - resource-pool


     These utility routines provide management of pools of fixed-sized areas
     of memory.  Resource pools set aside an amount of memory for exclusive
     use by the resource pool owner.  This can be used by applications to
     guarantee the availability of a minimum amount of memory needed to con
     tinue operation independent of the memory resources currently available
     from the system-wide memory allocator (malloc(9)).  The pool manager can
     optionally obtain temporary memory by calling the palloc() function
     passed to pool_create(), for extra pool items in case the number of allo
     cations exceeds the nominal number of pool items managed by a pool re
     source.  This temporary memory will be automatically returned to the sys
     tem at a later time.


     The pool manager is implemented in the file sys/kern/subr_pool.c.




In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 1999-01-30 20:18:15
Subject: Re: [HACKERS] Postmaster dies with many child processes (spinlock/semget failed)
Previous:From: Cary O'BrienDate: 1999-01-30 14:08:21
Subject: Re: [HACKERS] Postmaster dies with many child processes

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group