sdk@surya.cs.ucla.edu (Scott D Kalter) (03/11/89)
I have an application (SBProlog) that needs to allocate large blocks of continuous memory. Unfortunately, I need do very little work before my 2meg expansion memory fragments too much for this application to be run. I have quickly looked through the fish disk collection and found a program that could summarize the fragmentation but did not see anything that could perform a compaction. Does anyone know of such a utility? Thanks, -Scott Kalter <sdk@cs.ucla.edu>
fgd3@jc3b21.UUCP (Fabbian G. Dufoe) (03/13/89)
From article <SDK.89Mar10181536@surya.cs.ucla.edu>, by sdk@surya.cs.ucla.edu (Scott D Kalter): > > > I have an application (SBProlog) that needs to allocate large blocks > of continuous memory. Unfortunately, I need do very little work > before my 2meg expansion memory fragments too much for this > application to be run. I have quickly looked through the fish disk > collection and found a program that could summarize the fragmentation > but did not see anything that could perform a compaction. > > Does anyone know of such a utility? > > Thanks, > > -Scott Kalter <sdk@cs.ucla.edu> I've spent quite a bit of time recently looking at the Amiga's memory management. I don't believe there is any way to write a utility to compact memory. When you allocate memory AmigaDOS revises the system memory free list so the allocated blocks don't appear. When you release that memory AmigaDOS puts it back in the memory free list. If you put it all back the free memory won't be fragmented. AmigaDOS merges any contiguous chunks of free memory into a single chunk. So long as some memory remains allocated the free memory will be fragmented. Why can't you move the allocated blocks together so the free memory will all be contiguous? Because AmigaDOS doesn't know what processes have the allocated memory or what they are using it for. If you were to write a program to compact free memory you would need to know, for each allocated block you moved, every place in the system that had a pointer to that block so you could revise the pointer. --Fabbian Dufoe 350 Ling-A-Mor Terrace South St. Petersburg, Florida 33705 813-823-2350 UUCP: ...uunet!pdn!jc3b21!fgd3
gilham@Portia.Stanford.EDU (fred gilham) (03/14/89)
In article <SDK.89Mar10181536@surya.cs.ucla.edu> sdk@surya.cs.ucla.edu (Scott D Kalter) writes: > > . . . >but did not see anything that could perform a compaction. > >Does anyone know of such a utility? > >Thanks, > >-Scott Kalter <sdk@cs.ucla.edu> Doing memory compaction is (virtually??) impossible because it would involve modifying the pointers in the programs that use the memory. The only real solution is virtual memory. (If anyone knows different please correct me...) -Fred Gilham
scott@applix.UUCP (Scott Evernden) (03/20/89)
In article <598@jc3b21.UUCP> fgd3@jc3b21.UUCP (Fabbian G. Dufoe) writes: > I've spent quite a bit of time recently looking at the Amiga's memory >management. I don't believe there is any way to write a utility to compact >memory. >... > If you were to write a program to compact free memory you would need >to know, for each allocated block you moved, every place in the system that >had a pointer to that block so you could revise the pointer. A memory subsystem which relies on doubly indirect pointers (called "handles") will allow for memory compaction. The Mac OS provides a facility which does this. An application must "lock" a handle to a data structure before accessing it; it "unlock"s the handle when it is not being used. The memory system is therefore free to move unlocked data/memory in order to coalesce holes. You simply need to make sure that you store any references to data via handles and not pointers. The handle is nothing more than an index into a table which provides the true current location of the information. This idea can be extended to provide a form of virtual memory. Data chunks, being freely mobile, can be swapped to secondary storage if the main memory pool becomes congested. As long as the total locked memory is smaller than the memory pool, total virtual storage requirements are limited only by disk size. Is anyone working on this? I think this might make a neat project. -scott