Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!uxc.cso.uiuc.edu!uxc.cso.uiuc.edu!m.cs.uiuc.edu!s.cs.uiuc.edu!mccaugh
From: mccaugh@s.cs.uiuc.edu
Newsgroups: comp.lang.pascal
Subject: Re: FreeMem, GetMem & TP50
Message-ID: <208300011@s.cs.uiuc.edu>
Date: 22 Aug 89 07:01:00 GMT
References: <1392@lafcol.UUCP>
Lines: 47
Nf-ID: #R:lafcol.UUCP:1392:s.cs.uiuc.edu:208300011:000:2663
Nf-From: s.cs.uiuc.edu!mccaugh    Aug 22 02:01:00 1989


filbo@gorn.santa-cruz.ca.us in s.cs.uiuc.edu:comp.lang.pascal writes:

> size of the free-blocks-list floats according to how many free blocks there
> are.  In the example you gave, there are no free blocks at any time in the
> sequence [allocate(first); allocate(second); free(second); free(first)]. On
> the other hand, in the sequence [allocate(first); allocate(second);
> free(first); free(second)], a free block is created when you free(first).

 No, this is not quite what happens. First of all, by 'size' of the free-
 blocks-list do you mean the number of such blocks? If that is all that's
 given, it seems safe to assume they're all of the same size. Now, I believe
 the problem lies in your confusion as to what is a free block: when you say
 that "there are no free blocks at any time", well - if that were literally
 true - why didn't the user complain of a crash? With only 70 (50+20) bytes
 allocated, that seems unlikely. What actually happens is that in both of
 the sequences, a free block gets added ('second' in the first sequence and
 'first' in the second), not just in the second sequence of actions. So the
 only discrepancy here lies in the size of blocks freed.


> Memory usage looks something like this [not to any scale]:

  initially:            -------------

  allocate(first):      *------------
  allocate(second):     **-----------
  free(first):          -*----------*  should be: -*------------
  free(second):         -------------

> To keep track of the free block created by free(first), a free-block pointer
> is allocated at the end of the heap.  This accounts for the missing memory
> as reported by MemAvail.  free(second) allows that free block to coalesce
> with the rest of the heap, so the free-block pointer goes away, its memory
> becomes available again, and MemAvail once again reports the expected value.

  It sounds like you are saying that the first block freed is not coalesced
  into the heap but remains on some free-block list (otherwise why allocate
  a free-block pointer to it?) but then the second block freed is coalesced:
  this sounds like memory-mismanagement in that the destiny of freed blocks
  is left in question: do they go into the free-block-list or back into the
  heap? If the former, are they all the same size? (This is why I raised the
  question of equal-sized blocks earlier.) Was there a free-block-list from
  the beginning or did the compiler generate one on demand? And does MemAvail
  refer to that list or to the heap? My point is that if MemAvail refers to
  the free-list only, then it shouldn't have been affected by allocation of
  the free-block pointer off the heap.