Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!rpi.edu!deven From: deven@pawl.rpi.edu (Deven Corzine) Newsgroups: comp.sys.amiga Subject: Re: Tidying fragmented memory Message-ID: Date: 13 Apr 89 04:09:33 GMT References: <12913@louie.udel.EDU> Sender: usenet@rpi.edu Reply-To: shadow@pawl.rpi.edu (Deven T. Corzine) Organization: RPI Public Access Workstation Lab, Troy NY Lines: 55 In-reply-to: MROBINSON@wash-vax.bbn.com's message of 12 Apr 89 15:05:51 GMT In article <12913@louie.udel.EDU> MROBINSON@wash-vax.bbn.com writes: >A week or so ago I saw a message fly by about not being able to coalesce >free memory into bigger hunks, and that prompted some questions in my >mind. That problem was actually due to small chunks of ALLOCATED memory separating free blocks. [1. Ok to free adjacent allocated blocks as one?] Legit, but unnecessary, and you would have to depend on the memory allocator granularity. [2. Does Exec combine adjacent free blocks?] Yes. [3. Does Exec try to allocate large and small blocks separately, or system- and user-allocated blocks separately?] No. It traces through the free memory list (which CAN be reordered to give preference to a different memory block) looking for either the first block large enough for to block the be allocated, I believe. It MIGHT search for smallest free block large enough to hold the block to be allocated, but I doubt it; it would be inefficient and would defeeat the purpose of reordering the free list. Hence, it is most likely first fit. >My assumptions are 1. yes, 2. no, and 3. no. If these assumptions are >correct, what about 1. yes, 2. yes, 3. no. [4. asttempting to combine free blocks] Useless, since free blocks are combined. >Back to question 3... if the answer to 3 is no, why not? I realize that it >is difficult to predict how programs are going to use memory, but I think >there is probably some allocation routine that improves on "fastest is best" >allocation without taking too much time. Because of considerations, and because the free memory is kept as a free list, making it difficult to allocate from the top or bottom of memory. True, you COULD alternatively search from the TAIL of the free memory list, but then you have the problem of CHIP memory being given preference to FAST memory when searching the list in reverse. Most people would not like that idea. Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.