🚀 go-pugleaf

In article <76000174@uiucdcsp> gillies@uiucdcsp.cs.uiuc.edu writes:
>I believe that virtual memory does very little to solve the memory
>headaches for developers.  As a former developer, I believe these
>headaches are intrinsic to writing bullet-proof software.  We spent
>half the time alpha testing our machine (with VM) in unusual situations
>when some resource (RAM, Disk) was unreasonably low.  The software had
>to keep working.

You have a point for programs which are constantly doing allocation
(and maybe deallocation), but not all software falls into this category.

>Even if you macintosh has a 5 megabyte VM space, it is still necessary to
>write software that performs gracefully when the machine exhausts all 5 megs.

Very true, but the virtual limits are usually an order of magnitude farther
out than the real memory limits, and that means that any program that
falls between those limits becomes much more painful to write without
VM.  The Mac isn't really THAT much more advanced than the '60s and '70s
computers that required the writing of "overlays".  The programmer must
be acutely conscious of what he wants in memory at any instant, and manually
"swap out" stuff.  With VM this requires no coding at all, and frequently
gives better performance, since demand paging is based on the program's
ACTUAL behavior, not what the programmer thought it might do.

Further, without VM, running a program whose data structures are larger
than the available real memory is impossible.  I have one program whose
virtual image is 4+ MB, and whose working set is under 200 KB.  Rather
than being easy to port to the Mac, it is impossible without a major
rewrite substituting a file-resident database for a memory-resident one.
Without VM this program wouldn't work even on a Mac II with 4 MB; with it
it could probably run on a 512 KB Mac.

(Somewhat related question: Is there a C compiler for the Mac in which

#define	N_RECORDS	2000000
typedef	char	record;

	/* Allocate memory for database table. */
	table = malloc(sizeof(record)*N_RECORDS);			/*1*/
	if (table == NULL)
	{
		FATAL_ERR("Not enough memory to load database.");
	}

	/* Fill table from data file. */
	status = fread(table,sizeof(record),N_RECORDS,datafile);	/*2*/
	if (status <= 0)
	{
		FATAL_ERR("Problem reading database file.");
	}
	else if (status < N_RECORDS)
	{
		WARNING("Database was smaller than expected.");
		max_record = status;
	}
	else
		max_record = N_RECORDS;

	/* Begin doing real work with in-memory database. */
	x = table[index];						/*3*/

has a prayer of working?  Even assuming AUX and/or enough real memory?
That is, (1) Can you allocate LARGE chunks of contiguous memory?,
(2) Can you map them easily to and from files?, and (3) Can you have
arrays that are megabytes long and index them simply?)

>Your software should also do something reasonable when the disk runs
>out of free pages.  Professional developers worry about such things.
>Yes I know it's a pain, but it separates the men from the boys in
>software design.

It's ONE of the things that separates the mensches from the schmucks.

>Most software written for UNIX is very unprofessional and I'm not
>suprised source licenses are so cheap.  When a UNIX box begins to run
>out of VM, all hell breaks loose an many programs crash inexplicably.
>The same thing happens when the machine exhausts disk space.

Agreed, but at least you don't usually need to reboot.  I've got several
programs on my Mac that, if you try to run them under the wrong System/Finder,
will crash the whole machine.  I can only imagine what this must be like
under MultiFinder.  I've seen a kids games for the Mac that use a picture font
for matching-type puzzles, but doesn't have the font resource in the game file,
and doesn't bother to check whether the font exists, or whether any given
character happens to exist in whatever the System substitutes for it.  Ever
try explaining to a 3-year old why two identical squares don't match?  I am
forced to conclude that most Mac software is no better written than most UNIX
software.

Your comment about source licenses puzzles me.  Are you talking about UNIX
programs themselves (i.e., parts of the distribution)?

>There would be hell to pay if this happened to a customer running an
>editor they paid real $$$ for.  If he lost work because the editor
>crashed, I would be inclined to believe he deserved his money back.

Gee, when my UNIX editor has problems it sends me mail telling me how to
recover the file.  Pretty friendly if you ask me.  All it needs is a fraction
of a second warning that the system is going down; easy with signals ...

-- 
	Howard A. Landman
	{oliveb,hplabs}!intelca!mipos3!cpocd2!howard
	howard%cpocd2.intel.com@RELAY.CS.NET