Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!gatech!udel!new
From: new@udel.EDU (Darren New)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Virtual Memory
Message-ID: <16173@louie.udel.EDU>
Date: 24 May 89 19:30:00 GMT
References: <8905222150.AA05890@jade.berkeley.edu> <6959@cbmvax.UUCP> <3866@sugar.hackercorp.com>
Sender: usenet@udel.EDU
Reply-To: new@udel.EDU (Darren New)
Organization: University of Delaware
Lines: 21

In article <3866@sugar.hackercorp.com> karl@sugar.hackercorp.com (Karl Lehenbauer) writes:
>In article <6959@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
>> Then again, I haven't found a way to use up 7 megabytes of physical memory
>> yet, so I don't really suppose I have a need for virtual memory myself.  Other
>There are huge memory applications forthcoming, however.  A 4000X4000 24-bit 

I've been following this without saying much, but I think there may
be a good interim solution. Just adding a bit to the load format headers
that say this hunk is allowed to be in VM will help alot (pun intended). Also, 
allowing virtual memory allocation to be done explicitly would help
"huge memory applications" of the future. However, to back-patch
VM into current applications seems extremely difficult to get right.
What about applications that use AvailMem to keep from allocating
so much ram that requesters fail (is there a better way, BTW?)?
What about programs like DPIII which could use VM for the images, but
would really like to read-ahead the images during playback? 
What about a program running when your swap-disk has been ejected?
I think explicit support is much easier to do than trying to guess what is 
safe on current applications. At least until CBM has had time to tell
developers what VM will support in future releases.
	     -- Darren (much better at finding problems than solutions) New