cliffhanger@cup.portal.com (Cliff C Heyer) (05/31/90)
Re: MS-DOS MSC 5.1 I'm using a library (w/o source code) that with heapwalk shows to have lousy memory management (it was ported from a "real" OS that takes care of these things) and after awhile malloc() returns "Out of memory" when in fact there is 150KB free but broken up into 1KB chunks between other "in use" data. I would like to replace the MSC malloc() routines with ones that do garbage collection (and maintain an internal table to derefrence pointers so this can be done). Has anyone heard of such a library, and where it can be bought? I suppose I could write it myself.... Cliff
cliffhanger@cup.portal.com (Cliff C Heyer) (06/03/90)
Re: MS-DOS MSC 5.1
This is a re-posting of my question posted last
week. To my surprise, all my mail except one
came back from people saying "why would anyone
need such a thing?" I guess I'm on the "outer
bounds" of C programming....
What I am talking about is a "disk defragmentor"
for memory.
I would like to replace the MSC malloc() routines
with ones that do defragmentation. This is done
by having malloc() maintain an internal table to
DEREFERENCE POINTERS. eg., when you do a
malloc(), malloc() returns an address that is not
a physical address but the address of a table
entry that contains the physical address. In this
way when your new malloc() can't find a big
enough contiguous chunk of memory and wants to
return an "out of memory" condition, it can first
do memcpy() to move the data to new physical
addresses and update the table entries, thus
compacting memory ("garbage collection" in my
previous posting.)
Note that this is what a real OS does like UNIX, but
remember DOS is really just a program loader and
does no memory management for the program, so
with DOS you must do it yourself.
I'm AMAZED that there is not more attention to
this subject. Seeing how the DOS 640K limit is such a
problem, I would think that this problem would have
been tackled long ago.
This is EXACTLY what certain disk utilities
do to disks; DOS scatters clusters all over a disk
and the disk becomes fragmented, and the utility
"defragments" the disk.
Why do I need this?
I'm using a library (w/o source code) that with
heapwalk shows to have lousy memory management
(it was ported from a "real" OS that takes
care of these things) and after awhile malloc()
returns "Out of memory" when in fact there is
150KB free but broken up into 1KB chunks between
other "in use" data.
On DOS, it is the programmer's responsibility to take
care of memory because there is no OS to do it for
you! Windows 3.0 I understand does this.
Has anyone heard of such a library, and where it can
be bought?
Actually writing it myself appears no longer to be such
a chore!
Cliffinst182@tuvie (Inst.f.Techn.Informatik) (06/07/90)
cliffhanger@cup.portal.com (Cliff C Heyer) writes: >I would like to replace the MSC malloc() routines >with ones that do defragmentation. This is done >by having malloc() maintain an internal table to >DEREFERENCE POINTERS. eg., when you do a >malloc(), malloc() returns an address that is not >a physical address but the address of a table >entry that contains the physical address. > > ... > >Why do I need this? >I'm using a library (w/o source code) that with >heapwalk shows to have lousy memory management >(it was ported from a "real" OS that takes >care of these things) and after awhile malloc() >returns "Out of memory" when in fact there is >150KB free but broken up into 1KB chunks between >other "in use" data. I don't think such an indirect malloc library would be of much use in your case. If a library routine calls malloc () it expects to get a pointer to the allocated memory block, not a pointer to a pointer to this block. It would happily thrash your table. If you had the source, however you could change all *s to **s, but then you could change the memory management of this library, too. >On DOS, it is the programmer's responsibility to take >care of memory because there is no OS to do it for >you! Windows 3.0 I understand does this. Most "Real OSes" do garbage collection with a MMU (how else could the pointers remain unchanged), which the 8086 just doesn't have. It would be possible in protected mode on 80[234]86 systems, by using a segment per pointer, but switching segments is SLOW (I have been told, I just sold my XT, and bought a 386, and haven't done much experimenting yet). So even on a 80386 UNIX system you wouldn't have any garbage collection, although the unused blocks would probably only accumulate in the swap space, not in main memory. >Cliff | _ | Peter J. Holzer | Think of it | | |_|_) | Technische Universitaet Wien | as evolution | | | | | hp@honey.tuwien.ac.at | in action! | | __/ | ...!uunet!mcsun!tuvie!asupa!honey!hp | Tony Rand |