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: E106c0f-000441-00@quartz.newn.cam.ac.uk (view raw or flat)
Thread:
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)

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

...

DESCRIPTION
     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.

...

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

eg. ftp://ftp.NetBSD.org/pub/NetBSD-current/src/sys/kern/subr_pool.c

Cheers,

Patrick

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-2014 The PostgreSQL Global Development Group