Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!agate!saturn!ucscc.ucsc.edu!gorn!filbo
From: filbo@gorn.santa-cruz.ca.us (Bela Lubkin)
Newsgroups: comp.lang.pascal
Subject: Re: FreeMem, GetMem & TP50
Message-ID: <8.filbo@gorn.santa-cruz.ca.us>
Date: 24 Aug 89 12:53:46 GMT
References: <208300013@s.cs.uiuc.edu>
Organization: R Pentomino
Lines: 37

In <208300013@s.cs.uiuc.edu>, mccaugh@s.cs.uiuc.edu writes:
> if (as I strongly suspect,
> knowing Borland Int'l as I do) they support only a naive memory-manager,
> then when blocks become available whose addresses are not contiguous (this
> is what I mean by NAIVE), they cannot coalesce the block with existing heap
Yes, exactly.  Within the constraints of the hardware and software
(specifically: 8086-compatible processors; a "pointer" rather than "handle"
heap), just what method did you have in mind of coalescing non-contiguous
memory blocks?

> so they (naievely) plant a pointer to it and charge the user for 8 bytes of
> space: 4 bytes for the pointer (address) and 4 for the block-size, which 
> would explain the discrepancy.
What is "naive" about this?  The user gets "charged" for free list storage
only when it's needed.  If a program allocates memory but never frees any,
or frees it in strict reverse order, the entire heap is available for user
storage.  I'd rather have that than be >required< to set aside memory for the
free list.

A different concern is: is it really beneficial to store the free list
separately, rather than >within< the free blocks?  Borland's main rationale
is that their method allows arbitrarily small heap blocks.  I think it's
more important that the free list is (somewhat) more protected from being
trashed by bad accesses to heap blocks (e.g. accesses to a deallocated
pointer).  The main disadvantage, of course, is the memory taken up by the
free list.  More subtly: their old heap manager (in Turbo 3.0 and earlier)
had 8-byte granularity and did in fact store the free list within the free
blocks.  Having worked with both, I think 8-byte granularity is much better
for minimizing heap fragmentation.  Of course this could be maintained by
shelling around the heap functions...

Bela Lubkin     * *   filbo@gorn.santa-cruz.ca.us   CIS: 73047,1112
     @        * *     ...ucbvax!ucscc!gorn!filbo    ^^^  REALLY slow [months]
R Pentomino     *     Filbo @ Pyrzqxgl (408) 476-4633 & XBBS (408) 476-4945

** gorn's MX record is currently broken; you MUST use UUCP routing
** via ...ucbvax!ucscc!gorn!filbo or gorn!filbo@ucscc.ucsc.edu