🚀 go-pugleaf

In article <619@palladium.UUCP> nw@palladium.UUCP (Neil Webber) writes:
>In Article <32094@tut.cis.ohio-state.edu> Jeff Martens adds:
>>OK.  Let's keep track of every byte of RAM in the Amiga.  If we allow
>>for 8MB of RAM, then we need an 8Mb map, which comes to a megabyte.
>
>No existing programs track their own memory allocations that way
>(at least, I hope not!).  The OS wouldn't do it that way either.
>Nor would it do it in 8 or 16 byte chunks.  It would do it the same
>way every current program is forced to do it.  It won't be ANY slower.
>It won't take up ANY additional memory.

I don't think so (but I'm not corageous enough to just say "WRONG").
Currently, a program asks for X bytes and gets an address (i.e.: a
pointer).  When it is done with it, it says "free X bytes starting at this
address".  Remembering that the given address is associated with a chunk
of X bytes is the program's responsibility.  But it's easy for the program
to do so:  fooptr = AllocMem(sizeof(struct foo), ...);
FreeMem(fooptr, sizeof(struct foo)).  The "sizeof" is a constant whose
value is calculated at compile time (in assembly language, its an equated
constant).  Since the program knows what the pointer is used for, it knows
from context how big an area the pointer points to.  But if Exec is
tracking the allocations for the process, Exec must, at the very least, keep
an association list:  (address, length).  This takes extra memory.
Alternatively, you could do what some Unix malloc's do:  put the length at
pointer-4.  This still takes extra memory.  Both methods also encur a
fixed memory overhead per allocation, making it more efficient to do one
allocation rather than many.  Currently the penalty for such an approach
is very, very small.

I'm not trying to say that I prefer the current setup.  I just think that
it will take some extra memory (not much, but some).

			William LeFebvre
			Department of Computer Science
			Rice University
			<phil@Rice.edu>