🚀 go-pugleaf

In article <FAT.95Sep20185920@fat.cnit.nsk.su>,
Dmitry V. Irtegov <fat@cnit.nsk.su> wrote:
>In article <43nlc8$sll@orion.cybercom.net> jerry@cybercom.net (Jerry Shekhel) writes:

>> That's fine, but as your program executes, internal fragmentation builds up.
>> Eventually you have a process whose data space is huge and full of holes.
>
>Ugh. Objects have same _logical_ address, but nothing prevents
>them from changing _physical_ address. In paged memory, continguous area
>of logical memory can be mapped to many separate pieces of physical RAM,
>so there is no fragmentation problem at all.

Now wait; sorry to jump on the other side of the fence here, but Jerry
Shekhel was right about the fragmentation. Virtual memory doesn't eliminate
the possibility of fragmentation. Your are forgetting that demand paging
works at the granularity of a page. Once you allocate a certain number of
pages which are made to appear as a linear block, you still face the
possiblity of wastefully fragmenting the space. The underlying VM system
doesn't know about your used and unused areas. Library functions like
malloc() will typically _not_ free a frame of memory that is completely
within an allocation chunk that has just been freed.

My argument was that simple malloc-like heap management is more than
sufficient to manage the dynamic data space of most applications, and that
handle schemes are ridiculous overkill.

>> The Mac approach allows the operating system to compact the heap, collecting
>> all the free space into one large block.  This is very efficient memory-wise,
>> but it requires additional CPU activity at runtime and additional effort on
>> the part of the application developer.
>
>Mac approach put memory virtualisation on behalf of application programmer.
>Mac handle is, in fact, closest equivalent of logical address in 
>virtual memory systems. In Mac, programmer must do virtual->physical
>address translation by handle locking. VM systems do this in hardware,
>and hardware is called MMU - Memory Management Unit. It automagically
>takes care of all accesses to address, and automagically does locking/freeing.
>If object is discarded, it calls operating system. This is called page fault.

Right, but within an application, the objects that are discarded don't
fall neatly along virtual memory frame boundaries, and hence heap allocators
almost _never_ return pages to a system until the process terminates or
is killed. However, when that happens, we can reliably return all of the
memory resources of the process to the operating system. One program
doesn't fragment another program's memory (as is the case with a global
heap), nor can it corrupt another program's memory. This goal is far more
important than attempting to squeeze every last byte out of a global heap
(which is laughable in a system that will sooner crash for reasons of
heap corruption than run out of memory).

>Hardware implementation always are orders of magnitude faster than software
>equivalents, and in this case hardware implementation makes software
>several orders of magnitude simplier: programmer doesn't have to do
>locking in any form.

Fine, but that's not being quite fair. Remember that the original Macintosh
didn't have the hardware to do all this. My claim is that the design was
poor regardless, and that Apple waived all opportunities to fix things
for the last ten years in the name of backward compatibility.

A lot of old Mac programs (especially shareware) won't run on modern Macs,
but ghosts of the original design still plague the system.

(I once plodded through a CD-ROM full of "older" shareware using a Quarda
840AV. About 80% of the programs dated 1989 or older would not run
properly at all. It makes you wonder what all the compatibility fuss is for).

>> Internal fragmentation affects all programs regardless of the operating
>> system on which they run.  
>
>I never have meet internal fragmentation problems in unices and OS/2.
>These problems are strictly specific to Mac and, in lesser extent, to Win16.
>Demand-paged virtual memory systems, from VMS or IBM VM to Doom Operating 
>System NEVER, repeat, NEVER suffer from any form of "internal fragmentation".

You mean they don't suffer from external fragmentation.  The internal
fragmentation is there, but it's simply not a problem. You don't feel it.
What hits you is programs that have memory leaks, a problem that can't be
fixed by eliminating fragmentation. For instance, if you want to run 
a _large_ LPMud, be prepared to have over 100MB of virtual space and 
expect to reboot the game periodically! :)

>> UNIX systems ignore the problem and let the applications worry about their
>> own heap management.  The OS itself provides only rudimentary facilities
>> for expanding the heap.  On the other hand, UNIX provides very robust virtual
>> memory capabilities, so most programs can get by using only the
>> unsophisticated heap management of malloc() and related functions.
>
>They can do it because internal fragmentation of heap is practically not
>a problem under demand-paged VM. It might be a problem for a daemon
>that runs for several months and actively uses malloc/free, and these
>daemons might use advanced version of malloc or own allocations schemes.

Yup. Such programs, provided that they don't have memory leaks, will
expand until they reach a stable operating size.

>> AmigaOS gives you the worst of all worlds.  It ignores both internal and
>> external fragmentation problems, and offers no virtual memory.
>
>I have limited experience with Amigas, so no comment.
>From my perspective, they definitely have a problem here.

They have problems, but from my experience with Amigas, I have found
them to be quite stable compared to the Macintoshes. It could have something
to do with not contorting the act of programming around some asinine
memory allocation scheme.

We are overlooking portability in all this. If I wanted to port a non-trivial
program to the Macintosh, I would be faced with the difficult task to
comb through the code adding WaitNextEvent() calls all over the place, 
as well handle locks and dereferences. Converting self-referential data
structure management routines would be hair-reaisingly tedious and
error-prone to the point that a complete rewrite would be more feasible.
Either that, or the use of a hacked compiler which incorporates the
concept of a handle more-less transparently into a pointer object (the
very thought of the resulting performance hit makes me cringe).

Imagine that your program uses pointers to implement structures that
represent "one to many" graph relationships...
-- 
Finger c2a192@keats.ugrad.cs.ubc.ca for PGP public key. Or contact
one of the public key servers -- the key id is 0xD3C7995D.
Microsoft users: crash test dummies?