Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!bloom-beacon!athena.mit.edu!eichin From: eichin@athena.mit.edu (Mark W. Eichin) Newsgroups: comp.unix.wizards Subject: Re: To find out the names of open files in a process Message-ID: <2672@bloom-beacon.MIT.EDU> Date: 30 Jan 88 13:48:45 GMT References: <2346@mandrill.CWRU.Edu> <339@tandem.UUCP> <7124@ncoast.UUCP> <904@thorin.cs.unc.edu> <1427@mips.mips.COM> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: eichin@athena.mit.edu (Mark W. Eichin) Organization: Massachusetts Institute of Technology Lines: 47 In article <1427@mips.mips.COM> hansen@mips.COM (Craig Hansen) writes: >In article <904@thorin.cs.unc.edu>, gallmeis@wasp.cs.unc.edu (Bill Gallmeister) writes: >> The answer? "Remember how much you asked for, dimwit!" > >Actually, if free() is going to be able to deallocate the space, the >dimwit malloc() ought to be salting the size away somewhere, since Exactly: a DIMWIT malloc might be allocating the exact amount of space asked for; this then requires a full copy on any realloc and causes other performance problems. A fast malloc might just manage the heap as a set of blocks of power of 2 sizes, which are near (modulo some hysteresis value) the actual size requested via malloc(). Thus free can just relink the block onto a chain, never knowing what the ACTUAL size was, msize() not being inherent in the block structure. This is more efficient than a serial allocator when there is much thrashing of the memory pool (eg. a lisp-like system or an editor) since you can just make the block available for quick re-use. {If anyone knows really precise results of this type, can you point me at them? We have ``proven'' them here in a small way, but real results might make a good thesis project...} The GNU Emacs malloc (derived from several places) did this, with the debugging option of keeping msize in the block header, and storing a magic number at each end of the block, which it could check at free or realloc time (simple bounds checking.) I enhanced this for a project here to fill the ENTIRE `extra' area with magic numbers, and then scanning them for error at the appropriate times... It also trashes freed blocks (with a magic number) and makes sure they aren't written in when they next get reused. These things have helped trap software bugs that make 4.nBSD malloc corrupt the memory pool, making debugging impossible... This project actually needed msize, so we left it always running with the first level of bounds checking (though we haven't gotten it stable enough for non alpha users, so we really run with full checking most of the time.) If it ran well, we would just hook an msize() onto what ever allocator we ended up with, so we could actually port the software. msize() was convenient enough (we were using `intelligent arrays') that we wanted to add it at the allocator level, for performance, rather than including it in the higher level structures. In summary: there IS a reason that there isn't an msize() by default, it is a constraint upon the allocator which can be overly restrictive in certain usage patterns. Mark Eichin SIPB Member & Project Athena ``Watchmaker''