[comp.lang.c] Storage Allocation/compaction

lupton@uhccux.uhcc.hawaii.edu (Robert Lupton) (07/14/88)

I have been using malloc/free under 4.2/4.3 BSD in an image processing
programme that deals with 1Mby files, and otherwise makes heavy use of
dynamic memory. I find that after a while my process grows to vast sizes
(64 Mby or so), as the memory gets fragmented. Then malloc returns NULL,
or the system hangs up. Obviously, using limit to increase the datasize
would only postpone the problem.

Does anyone have a public domain storage allocator that could replace
malloc/realloc/free that also has a call to compactify the memory? I
don't wan't to write one, and I don't have a source licence to add a
call to the system version. From what I remember of the 4.2 malloc, using
realloc on freed space wouldn't help, as it doesn't compact the different
free lists.

		Robert Lupton

greim@sbsvax.UUCP (Michael Greim) (07/18/88)

In article <2045@uhccux.uhcc.hawaii.edu>, lupton@uhccux.uhcc.hawaii.edu (Robert Lupton) writes:
< I have been using malloc/free under 4.2/4.3 BSD in an image processing
< programme that deals with 1Mby files, and otherwise makes heavy use of
< dynamic memory. I find that after a while my process grows to vast sizes
< (64 Mby or so), as the memory gets fragmented. Then malloc returns NULL,
< or the system hangs up. Obviously, using limit to increase the datasize
< would only postpone the problem.
< 
< Does anyone have a public domain storage allocator that could replace
< malloc/realloc/free that also has a call to compactify the memory? I
< don't wan't to write one, and I don't have a source licence to add a
< call to the system version. From what I remember of the 4.2 malloc, using
< realloc on freed space wouldn't help, as it doesn't compact the different
< free lists.
< 
< 		Robert Lupton
There was one posted recently in comp.sources.unix. It carried the
signature
<Bill Sebok			Princeton University, Astrophysics
<{allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,vax135}!astrovax!wls
I cannot find the message id as we've cleaned up our disks and I have removed
the Id from my local copy. 
I tested the package a little bit and as far as I can tell it is about as
fast (or slow) as the BSD malloc but it really shrinks your storage. I tried
it on SUN and a SYS3 derivant and it worked without any problem.

Hope this helps,
		Michael
-- 
+------------------------------------------------------------------------------+
| UUCP:  ...!uunet!unido!sbsvax!greim   | Michael T. Greim                     |
|        or greim@sbsvax.UUCP           | Universitaet des Saarlandes          |
| CSNET: greim%sbsvax.uucp@Germany.CSnet| FB 10 - Informatik (Dept. of CS)     |
| ARPA:  greim%sbsvax.uucp@uunet.UU.NET | Bau 36, Im Stadtwald 15              |
| Phone: +49 681 302 2434               | D-6600 Saarbruecken 11, West Germany |
+------------------------------------------------------------------------------+
| # include <disclaimers/std.h>                                                |
+------------------------------------------------------------------------------+

sdutcher@netxcom.UUCP (Sylvia Dutcher) (07/22/88)

In article <540@sbsvax.UUCP> greim@sbsvax.UUCP (Michael Greim) writes:
>In article <2045@uhccux.uhcc.hawaii.edu>, lupton@uhccux.uhcc.hawaii.edu (Robert Lupton) writes:

	(lines deleted)

>< Does anyone have a public domain storage allocator that could replace
>< malloc/realloc/free that also has a call to compactify the memory? I
>< don't wan't to write one, and I don't have a source licence to add a
>< call to the system version. From what I remember of the 4.2 malloc, using
>< realloc on freed space wouldn't help, as it doesn't compact the different
>< free lists.
>< 
>< 		Robert Lupton

	(reply from Michael Greim deleted)
	(sorry about this, I couldn't find the original posting) 

Try Dr. Dobb's Journal (of Software Tools) from June 1988.  It discusses
malloc and free problems and includes C code.  I haven't tried it, but it
might help.  The column is C Chest by Allen Holub.

Good luck.

-- 
Sylvia Dutcher			    *   The likeliness of things
NetExpress Communications, Inc.	    *   to go wrong is in direct
1953 Gallows Rd.		    *   proportion to the urgency
Vienna, Va. 22180		    *   with which they shouldn't.