jon@bodedo.ucm.org (Jon Boede) (03/30/91)
I've been puzzled about the existence of a second library for malloc on my system for some time (I have a SCO '386 box). Other than being tunable beyond my wildest dreams, what does using -lmalloc buy me? What does it cost me? I would assume that there's a tradeoff or there'd only be one library entry. Jon
lanzo@wgate.UUCP (Mark Lanzo) (04/01/91)
In a prior article jon@bodedo.ucm.org (Jon Boede) wrote:
I've been puzzled about the existence of a second library for
malloc on my system for some time (I have a SCO '386 box). Other
than being tunable beyond my wildest dreams, what does using -lmalloc
buy me? What does it cost me? I would assume that there's a tradeoff
or there'd only be one library entry.
Well, I can't say anything about SCO '386 Unix, but I can tell you what
it buys you on HP-UX:
** SPEED **
It is a whole lot faster. We have a big X-windows application we are
working on. We changed our makefiles to link with -lmalloc -- program
startup times in our case dropped by an order of magnitude. (say, from
5 minutes down to 30 seconds). I saw the light :-)
Tradeoffs? I can't think of any real problems. Here's what our man
pages have to say:
This package usually uses more data space than malloc(3C).
The code size is also bigger than malloc(3C).
Note that unlike malloc(3C), this package does not preserve
the contents of a block when it is freed, unless the M_KEEP
option of mallopt is used.
Undocumented features of malloc(3C) have not been duplicated.
Gee. How awful. It doesn't support the bad programming practices
that the original malloc would let you get away with :-).dold@mitisft.Convergent.COM (Clarence Dold) (04/01/91)
in article <2@bodedo.UUCP>, jon@bodedo.ucm.org (Jon Boede) says: > I've been puzzled about the existence of a second library for malloc on my Aside from the differences noted in the manual, there used to be a tremendous difference in speed for small mallocs. malloc(3X) sbrks a large (#defined) arena, then responds to malloc requests from within the pool, for your application. There are two tradeoffs that I know. The code is quite a bit larger, especially if you are using shared libc, and now you've added all of -lmalloc, and there is a peculiarity of the old malloc, that it did not destroy memory contents upon free(), allowing you to reattach a particular segment later (yech). This can be changed by using mallopt(). Additionally, the standard malloc and memory management for sysVr3.2 seems to be enough smarter that the speed difference has gone away. -- --- Clarence A Dold - dold@tsmiti.Convergent.COM ...pyramid!ctnews!tsmiti!dold
nelson@wrl.epi.com (Ken Nelson) (04/04/91)
We just ported our product to HP-UX and could not get it to work with the normal allocation routines. In fact we couldn't get it to work with -lmalloc as well. BUT when we used -lmalloc we got error messages out that made sense (other than core dump) and we were able to fix the problem. -lmalloc offered diagnostic warnings that normal alloc didn't. It notified us when the program tried to allocate a block of space of size 0. The normal alloc just returned a bad address that we used until we corrupted something and the program died far away from the bad code. Of course we could have prevented this by putting a wrapper around any call to malloc that checked for valid requests and valid answers. Normally we do, but this code was inherited from another company (Sun Microsystems XView library). By the way the request for zero space works okay on every other system we have ported XView to (Sun3, Sun4, Dec, Concurrent, Apollo, Convex, and more). So this isn't just a testimonial for -lmalloc, but a call for more defensive programming. -------------------------------------------------------------------- | Ken Nelson (nelson@wrl.epi.com) | No thoughts today, sorry. | | Computer Systems Manager | | | Entropic Research Laboratory | | | Washington, D.C. | | |--------------------------------------------------------------------
scs@adam.mit.edu (Steve Summit) (04/05/91)
In article <869@epiwrl.UUCP> nelson@wrl.epi.com (Ken Nelson) writes: > [-lmalloc] notified us when the program > tried to allocate a block of space of size 0. The > normal alloc just returned a bad address that we > used until we corrupted something... What kind of "bad address?" It is legal for malloc(0) to return a non-null pointer, but that pointer points to zero bytes that you may modify (or inspect), so it is not good for anything other than comparison, or handing to free() or realloc(). Evidently the code in question did the equivalent of char *p = malloc(0); p[3] = 'x'; That the -lmalloc package "complained" about the malloc(0) did in fact catch this bug, but note that it would not have caught the very similar char *p = malloc(1); p[3] = 'x'; There are debugging malloc packages which will catch this error (and -lmalloc may be one of them). Steve Summit scs@adam.mit.edu