Path: utzoo!attcan!uunet!ginosko!usc!sdsu!bionet!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: <208300014@s.cs.uiuc.edu> Date: 23 Aug 89 17:16:00 GMT References: <1392@lafcol.UUCP> Lines: 64 Nf-ID: #R:lafcol.UUCP:1392:s.cs.uiuc.edu:208300014:000:3508 Nf-From: s.cs.uiuc.edu!mccaugh Aug 23 12:16:00 1989 I tried to edit the preceding but it was already networked. Anyway, I apologize for the flame about Borland (only in that this is not the proper place for it). Responding to: filbo@gorn.santa-cruz.ca.us, who writes: > In article <1392@lafcol.UUCP>, Kenwyn A. Pilgrim writes: > [paraphrase: In Turbo Pascal 5.0, if two heap blocks are allocated and then > released in the opposite order, MemAvail acts as expected. If they are > released in the same order as they were allocated, the first FreeMem > increases MemAvail by less than expected; the second by more than expected; > but after both are released, MemAvail is as expected.] ..... > Without going into a great deal of detail, the memory manager keeps track of > free memory by maintaining a list of free blocks. Now what is unclear here is: does the memory manager start out with the free-block list or are the free blocks really just those that were freed up by the user but cannot yet be coalesced into the heap owing to non- contiguous addresses? It sounds as though the latter situation is the case, but I just would like to know for sure. > When the heap is empty, there are no free blocks in the list -- the large > block at the free end of the heap does not appear in the list and is tracked > by other pointers. Again, could the heap not also be empty with some free blocks present but all with non-contiguous addresses preventing re-formation of the heap? Perhaps we need clarification on the definition of "heap", which I do not consider the same as the free-block list. Also, if the heap is empty, what is the status of "the large block at the 'free end' of the heap"? > The 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)]. Yes, this is what led me to surmise above that there don't seem to be free blocks to start with, but rather become free'd by the user and tracked by the memory manager when they can't be absorbed into the heap. To say that "there are no free blocks at any time" in the first sequence does then make sense: the memory manager didn't start out with any, and whateve memory got free'd up by the user could get immediately coalesced into the heap. So I apologize for my earlier misunderstanding. > On the other hand, in the sequence [allocate(first); allocate(second); > free(first); free(second)], a free block is created when you free(first). Right: because memory was not de-allocated in LIFO order, the first block freed is not contiguous with the heap and so must be designated a "free block" and tracked until it can be coalesced. >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. Yes, now this makes sense to me - except that I recall MemAvail being off by 8 (rather than 4 bytes, which is all a pointer alone would account for), so I suspect the other 4 bytes refers to the size of the block, also taking up memory. > The key point here is that MemAvail may not exactly track the amounts > allocated and freed because of this automatic allocation for the free list.