Messages in this thread |  | | Date | Tue, 28 Jan 1997 20:09:04 -0500 (EST) | From | "Richard B. Johnson" <> | Subject | Re: 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. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
|  |