cmcmanis%pepper@Sun.COM (Chuck McManis) (08/15/89)
In article <7638@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > Well, if you use the C library routines malloc() and free(), there is >no _need_ to free everything, since the library implementation and exit() >code takes care of freeing malloc()ed memory. Doesn't mean I like the >practice: it places more reliance on the malloc to be unix-compatible, and >precludes replacing malloc (easily) with lower-level memory calls with less >overhead than malloc (such as AllocMem, or something like it). Doing something >like that saved me over 1K, by dumping malloc, and made my program run faster. Rewriting malloc to be faster is an old game, lots of people play. This whole bit about memory usage and calls are a religious argument but the two sides can be pretty clearly defined : The Package Argument : I use a memory management package that keeps track of what I allocate and free, when I exit the program I call the deallocate everything entry point and everything gets freed. I like this because I don't have to worry about what is and isn't freed. The System Call Argument : I use the system calls for allocating and freeing memory because I want to be absolutely sure I'm only using the memory I need, and don't like the overhead of memory management packages. I have to write some extra code in my exit routine to make sure I've taken care everything but the benefit is extra flexibility. Both are valid arguments, and they often depend on what you are trying to do. I tend to use a mixture because of the way in which the Amiga must have Chip ram for some things and my programs tend to build gadgetry and such on the fly. > Another reason I prefer a style where everything is freed is that it >makes the code more reusable: you can take a subroutine and use it, and not >have to worry about using immense mounts of virtual space that you are no >longer using. (Since you may use it repeatedly in a loop without exiting, >if it drops memory every time it can add up quickly.) This, on the other hand, is specious. If one writes a subroutine that has a memory leak then that is a bug in any system. If you are building data structures and returning them to your client that's one thing, but losing memory is just a bug. > As you might guess, I'm not a big fan of garbage collection. >-- >Randell Jesup, Keeper of AmigaDos, Commodore Engineering. You're comment implies that memory management packages have to be large cumbersome beasts that lose memory and must be scavenged periodically to defragment them. This is demonstrably untrue, so you must mean something else. The true advantage to memory management packages over system calls is that one can port them, and then all of your code works, rather than having to go into the code and find all occurrances of AllocMem() or what have you. In the case of malloc/free it just happens to be a defacto standard package because it works that way on UNIX. That means that you might not even have to port it when you get to the destination, and that saves time and energy. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"
jesup@cbmvax.UUCP (Randell Jesup) (08/15/89)
In article <121373@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >Rewriting malloc to be faster is an old game, lots of people play. This whole >bit about memory usage and calls are a religious argument but the two sides >can be pretty clearly defined : > >The Package Argument : I use a memory management package that keeps track of ... >The System Call Argument : I use the system calls for allocating and freeing ... Quite true (btw, my replacement gave both: smaller and faster than malloc, and it released everything for me if I hadn't when I exited.) >>if it drops memory every time it can add up quickly.) > >This, on the other hand, is specious. If one writes a subroutine that has a >memory leak then that is a bug in any system. If you are building data >structures and returning them to your client that's one thing, but losing >memory is just a bug. Maybe, but I've seen LARGE professional systems that do this. Admittedly, some of the people who do this are used to systems that garbage collect for them. For example, to quote from the Ada green reference manual (old, but all I have on me): "An object created by the execution of an allocator remains allocated for as long as this object is accessible directly or indirectly, that is, as long as it can be designated by some name. When such an object becomes inaccessible, the storage it occupies can be reclaimed (but need not be), depending on implementation." page 4-23, section 4.8 Ada has NO way to free allocated memory. BTW, I haven't seen an Ada compiler that did garbage collection yet (though having said that, I'm sure someone will point out that I'm wrong.) Can you say "VM Hog"? better learn if you run Ada. I believe (though I'm more likely to be wrong here) that LISPM's have the same sort of problem, when programmed in lisp (though they do have garbage collectors, and they make themselves known frequently.) -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com BIX: rjesup Common phrase heard at Amiga Devcon '89: "It's in there!"