To find out the names of open files in a process

[Mark W. Eichin]

In article <1427 at mips.mips.COM> hansen at mips.COM (Craig Hansen) writes:
>In article <904 at thorin.cs.unc.edu>, gallmeis at 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
			<eichin at athena.mit.edu>
		SIPB Member & Project Athena ``Watchmaker''