Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!milano!molokai!werner
From: werner@molokai.sw.mcc.com (Werner Uhrig)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 7.0 Q & A -- memory protection (none)
Summary: a possible solution to the fragented heap problem?
Message-ID: <2363@molokai.sw.mcc.com>
Date: 17 May 89 12:19:15 GMT
References: <1838@internal.Apple.COM> <7320@hoptoad.uucp>
Organization: MCC, Austin, TX
Lines: 55

In article <7320@hoptoad.uucp>, tim@hoptoad.uucp (Tim Maroney) writes:
> In article <1838@internal.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes:
> >I don't think the probability will change at all under 7.0.  There is one 
> >large address space (up to 14 megabytes) and everything lives there.  
> >There is no protection at all.
> 
> In that case, I think the probability of one application trashing
> another actually increases in System 7.0.  To be useful, virtual memory
> requires that process sizes be able to increase.  Given one large
> address space, the only way to do this on the Mac is by discontiguous
> heaps -- that is, when the application heap runs out of memory, a new
> chunk is added at a discontiguous location in the global address
> space.  So after a few applications grow, their heaps are thoroughly
> intertwined.  One of the more common program errors consists of
> assuming that heap block is larger than it actually is and writing past
> the end.  In 7.0, that has a good chance of writing into another
> application's heap instead of simply corrupting one's own heap.
> Very messy, and it seems like a giant step backwards.
 
	I could imagine a virtual memory system split into 2 sections,
	identical size, and, and processes getting to use only, at most,
	half the total available space.  if a process size needs increasing,
	it gets swapped from one section into the other section into a
	contiguous, larger section. All that would be required would be
	a change of one bit indicating if the process is using the upper
	half of the virtual memory space or the lower half of the virtual
	memory space;  all the necessary maintenance shuffling can be
	done as "overhead" of the operating system;  heck, who cares
	with 4 Gig - and I would even welcome it with 14 or 8 Meg ...
 
	sure, *REAL* memory protection is nicer, but ....

> >The comment about low memory was simply repreating what was stated at the 
> >Developer's Conference.  If protection was done between application heaps 
> >(which it isn't), it would only be a red herring since the system heap and 
> >low memory is shared.  The thought was that it was better to come up with 
> >a total solution in some future system, rather than give users a false 
> >sense of confidence.

	oh, I look so forward to the "right" sense of confidence inspiring
	software.  That's the one that will REALLY get you!  (SDI, anyone?)

> Why wait?  Do you want developers to have to upgrade once for System 7.0
> and once for System 8.0?  Talk about your pissed-off users!

	because you can either have a virtual system without memory
	protection now, or wait much longer for new software *AND* hardware.
	of course, there will always be those "old" machines without
	hardware memory protection ....

-- 
--------------------------> please send REPLIES to <------------------------
INTERNET:    uhrig@mcc.com     (if unavailable: werner@rascal.ics.utexas.edu)
UUCP:     ...<well-connected-site>!milano!werner
ALTERNATIVE:   werner@astro.as.utexas.edu   OR    werner@utastro.UUCP