Christopher Hylands wrote:
>
> This is a feature of most common operating systems.
>
> Basically, the process requests more memory from the OS and gets it,
> uses it and then frees it, but does not return it to the OS.
>
> (As an academic question, if someone knows about OS under active
> development today that return memory from processes to the system, I'd
> like to here about it)
...
[ lines deleted ]
Hi Christopher:
Glibc-2.x based Linux systems use ptmalloc.c (Malloc implementation from
Wolfram Gloger <[EMAIL PROTECTED]> for multiple threads
without lock contention) which in turn is based on Doug Lea's
<[EMAIL PROTECTED]> excellent malloc-2.6.4 version (for single-threaded
applications). Doug Lea's malloc (dlmalloc) has been used for Linux
libc since 1996. It is able to release unused space back to the system.
Below is a short description:
> This is not the fastest, most space-conserving, most portable, or
> most tunable malloc ever written. However it is among the fastest
> while also being among the most space-conserving, portable and tunable.
> Consistent balance across these factors results in a good general-purpose
> allocator for malloc-intensive programs.
>
> The main properties of the algorithms are:
> * For large (>= 512 bytes) requests, it is a pure best-fit allocator,
> with ties normally decided via FIFO (i.e. least recently used).
> * For small (<= 64 bytes by default) requests, it is a caching
> allocator, that maintains pools of quickly recycled chunks.
> * In between, and for combinations of large and small requests, it does
> the best it can trying to meet both goals at once.
> * For very large requests (>= 128KB by default), it relies on system
> memory mapping facilities (mmap, munmap), if supported.
>
> About Memory Mapping
>
> In addition to extending general-purpose allocation regions via sbrk,
> most versions of Unix support system calls such as mmap that allocate a
> separate non-contiguous region of memory for use by a program. This
> provides a second option within (Doug Lea's) malloc for satisfying a
> memory request. Requesting and returning a mmaped chunk can further
> reduce downstream fragmentation, since a released memory map does not
> create a ``hole'' that would need to be managed. However, because of
> built-in limitations and overheads associated with mmap, it is only
> worth doing this in very restricted situations. For example, in all
> current systems, mapped regions must be page-aligned. Also, invoking
> mmap and mfree is much slower than carving out an existing chunk of
> memory. For these reasons, (Doug Lea's) malloc relies on mmap only if
> (1) the request is greater than a (dynamically adjustable) threshold
> size (currently by default 128KB) and
> (2) the space requested is not already available in the existing arena
> so would have to be obtained via sbrk.
>
> In part because mmap is not always applicable in most programs, (Doug
> Lea's) malloc also supports trimming of the main arena, which achieves
> one of the effects of memory mapping -- releasing unused space back to
> the system.
>
> When long-lived programs contain brief peaks where they allocate large
> amounts of memory, followed by longer valleys where they have more
> modest requirements, system performance as a whole can be improved by
> releasing unused parts of the wilderness chunk back to the system. (In
> nearly all versions of Unix, sbrk can be used with negative arguments to
> achieve this effect.) Releasing space allows the underlying operating
> system to cut down on swap space requirements and reuse memory mapping
> tables. However, as with mmap, the call itself can be expensive, so it
> is only attempted if trailing unused memory exceeds a tunable threshold.
For more information on Doug Lea's malloc see
http://gee.cs.oswego.edu/dl/html/malloc.html
Best regards,
Wolfgang.
--
Wolfgang Reimer (Dr.-Ing.) Senior Software Developer
V I R T U A L P H O T O N I C S I n g e n i e u r g e s . m b H
phone : +49 30 398058-25 fax : +49 30 398058-58
mailto:[EMAIL PROTECTED] http://www.VirtualPhotonics.com
----------------------------------------------------------------------------
Posted to the ptolemy-hackers mailing list. Please send administrative
mail for this list to: [EMAIL PROTECTED]
