lkml.org 
[lkml]   [1997]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Memory allocation errors
On Tue, 28 Jan 1997, David Schwartz wrote:

>
> On Tue, 28 Jan 1997, Alan Cox wrote:
>
> > You can use mmap() to get a block of memory you can hand back if you wish
>
> Yep. And you can easily write malloc/free implementations that
> operate on multiple 'pools' with differing lifetimes. Each 'pool' can be
> 'mmap'ed and the whole thing either freed when the pool's lifetime
> expires or when the last allocation from that pool is freed.
>
> If your malloc/free pattern has special characteristics, don't
> use the generic malloc/free routines -- use your own that take advantage
> of those characteristics. Slab allocators for large numbers of
> identically sized objects, pool allocators for variable sized (or single
> objects) with a known lifetime, and so on.
>
> Programs that expect or require any special behavior from
> malloc/free like this are broken, IMO. You can force them to work by
> using an LD_PRELOAD to give them a malloc/free implementation that uses
> mmap/munmap for allocations above a certain size.
>
> David Schwartz
>

Well this is all very nice. My point is that malloc/free is broken. There
are not supposed to be any special considerations for user mode code.

This is NOT special behavior for malloc/free. It's just what we've
gotten used to. Under Unix, the lifetimes of most programs are very
short. They live as seperate processes for a few seconds and then
the kernel cleans up after them, usually by simply marking their
resources as free.

In recent times, we have programs with lifetimes of months (hopefully).
The stuff that we've been getting away with now shows.

This is like the discussion I first had with a DEC "Software Engineer" when
I tried to compile something in an early Ultrix implementation. The program
ran, it was something simple like "Hello World". The problem was that the
machine had to be re-booted after. I was told; "This is UNIX, what do you
expect".

Just because there may be several memory allocators out there that are
broken, should not define such as "standard". X11R1 (which I worked on)
could not use malloc() for just this reason. Therefore, machine-dependent
memory allocation schemes had to be used with hundreds of #ifdefs.. Ten
years have passed since then. Current implementations should have been
fixed.

When a "standard" for C, first ANSI, then Posix was started, malloc()
was one of the initial problems to be resolved. I note that "libc" has
an alternate malloc() (malloc-93076).

That was the time that a machine-dependent "morecore()" was specified.
The rules were that the memory allocated (from the system) should
return a pointer to the required number of bytes, aligned on a
boundary that could take any object. A negative number of bytes was
supposed to return memory to the system.

All these hooks are in the current implimention of malloc/free. They
just don't work. This may be called normal. If so, broken is normal.

Cheers,
Dick Johnson
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Richard B. Johnson
Project Engineer
Analogic Corporation
Voice : (508) 977-3000 ext. 3754
Fax : (508) 532-6097
Modem : (508) 977-6870
Ftp : ftp@boneserver.analogic.com
Email : rjohnson@analogic.com, johnson@analogic.com
Penguin : Linux version 2.1.23 on an i586 machine (66.15 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.039 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site