Date:	Wed, 11 May 94 15:21:06 -1000
From:	jthomas AT cs DOT uhh DOT hawaii DOT edu (Jim Thomas)
To:	turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp
Cc:	DJGPP AT sun DOT soe DOT clarkson DOT edu
Subject:	Re: malloc

Stephen,
(gomen nasai, nee)

Stephen> You may be right in general.  But I'd like to point out that DOS is a
Stephen> program and this is *exactly* what a memory manager does for DOS (or
Stephen> any OS), otherwise you'd have to reboot after every program, and
Stephen> multitasking would be impossible (on a continuing basis; your idea of
Stephen> malloc is that it is simply a memory leak).

But you are rebooting the program when you run a new one.  Anything that
has been malloc'ed no longer matters when the program exits because it's no
longer there.  So when you run a new program the cycle starts off fresh.

Stephen> If it's been free()'d the memory manager can assume it's not being
Stephen> used, and take it away.  Under protected mode, this should be
Stephen> implementable in such a way as to result in an access error.

Kind of.  Yes the manager can "take it away" but not change anything above
(at larger memory addresses).  The manager can reallocate the space in a
later malloc.  It could also remove pages from the address space if entire
pages were free'ed, but it has to leave holes there in their place.
Generally this is not done, at least in "unix(tm)" which likes contiguous
address spaces (though this is changing with shared libraries), including
for the BSS segment (that managed by sbrk).  But this would take a bunch of
code that checked for large free's and handled page overlaps, etc..  It
would be better to have a completely separate page management system for
large allocations like you're talking about so the free equivalent could
really just completely throw away the pages.

Stephen> David Ronis is talking about *huge* (not MS C "huge" :) blocks of
Stephen> memory, ceratinly including blocks that could theoretically be
Stephen> returned, even by your standard.  I am fuzzy on the details, but isn't
Stephen> it true that protected memory is effectively addressed via handles
Stephen> (implemented in hardware), and there fore you could resize blocks on
Stephen> the fly?  (By copying to a smaller block and resetting the handle.)
Stephen> This might not be worthwhile in general, or too dangerous, but in fact
Stephen> memory managers do it. ...

You can "resize blocks on the fly", but you can't change the addresses
above them.  The "dreaded" segmentation registers allow for exactly that
kind of manipulation, but if you look at all the unix(tm) implementations
on the 386 you'll find that the first thing they do is trash that
possibility by setting DS=ES=FS=GS=4GB .  If you have memory allocated as
follows:

	0000011111111112234444444

(where the digit is the sequence number of the malloc call, and each digit
stands for 1KB perhaps), and a free(#1) is done, then the result must look
like:

	00000xxxxxxxxxx2234444444

, where "x" is free'ed and possibly not accessible but is still part of the
range of addresses the program can address.  If a block has been malloc'ed
at virtual address 123456, it must stay there for the duration of program
execution because pointers to it could be anywhere.  (Or the program itself
has to do its own memory management completely - with garbage collection,
etc..)

Jim

- Raw text -