peter@ficc.uu.net (Peter da Silva) (01/08/90)
Note: faulting in the file is equivalent to RED's technique of only reading in the part of the file being used... > Given an appropriate system architecture, such as Mach, you could > even fault your blocks in from the file! > Mach doesn't do object (structure) paging to my knowledge. What I mean here is that you can allocate your block poimters, then call map_fd to map the file into memory. Now you point your block pointers into the file, but don't actually touch the memory. Now when you need a block, you just touch it, and it'll get faulted in from the file. I'm sure there are editors on friendlier VM systems than UNIX (such as Multics or VMS) that already do something like this. > 3> Allow the program to change the page mapping (think of it as mmap > to your own addess space). Then when you open a gap, you always > copy at most one page; you just split the page on which the gap > apears into two and translate the pages above or below by one. THAT is the thing to do to "fix" buffer gap. If you can do that you can also call map_fd to get the initial buffer. The problem with this is that now the program (or its custom external pager) is having to do much of the work of a block-splitting algorithm. Are there any major systems that give this capability? Mach could, but I hear external pagers aren't working very well yet. > You've already got paging hardware; why not use it to your advantage? Likewise. Buffer gap dirties a lot of memory, over & over again. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org> \_.--._/ v "Have you hugged your wolf today?" `-_-'
gumby@Gang-of-Four.Stanford.EDU (David Vinayak Wallace) (01/08/90)
Date: 7 Jan 90 20:05:37 GMT
From: peter@ficc.uu.net (Peter da Silva)
What I mean here is that you can allocate your block poimters, then call
map_fd to map the file into memory. Now you point your block pointers into
the file, but don't actually touch the memory.
The problem is that unless you copy the file on disk you can't back
out of your edits at the last moment (:q! for vi people). If you're
going to copy the file you might as well copy it into vmem.
> 3> Allow the program to change the page mapping
THAT is the thing to do to "fix" buffer gap. If you can do that you can also
call map_fd to get the initial buffer. The problem with this is that now
the program (or its custom external pager) is having to do much of the work
of a block-splitting algorithm.
malloc already does most of the required work. You could add a system
call or system macro to tell you how to xlate a page index from a
pointer and bingo.peter@ficc.uu.net (Peter da Silva) (01/08/90)
> What I mean here is that you can allocate your block poimters, then call > map_fd to map the file into memory. > The problem is that unless you copy the file on disk you can't back > out of your edits at the last moment (:q! for vi people). If you're > going to copy the file you might as well copy it into vmem. You misunderstand. I wasn't suggesting making direct edits on the memory image. On the contrary, you map it in read-only if you can. What I was suggesting was that since most of the things you're doing to the file don't involve modifying it, you might as well page it in from disk when you need it, only coping it to writable memory when you want to modify it. For example, suppose you want to do a search and replace. You fault in all the pages from here to the replacement location, copy the block that contains the replacement into two new blocks (using the block-splitting method) and add the new text. The blocks you just read can be discarded when needed by the memory manager, rather than having to be written out to the paging area, saving considerable disk access. Only modified blocks would need to be written. -- _--_|\ Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>. / \ Also <peter@ficc.lonestar.org> or <peter@sugar.lonestar.org> \_.--._/ v "Have you hugged your wolf today?" `-_-'
mellon@nigiri.pa.dec.com (Ted Lemon) (01/10/90)
> The problem is that unless you copy the file on disk you can't back > out of your edits at the last moment (:q! for vi people). If you're > going to copy the file you might as well copy it into vmem. Actually, this isn't a problem with a proper virtual memory system. If it's done right, you just implement a copy-on-write scheme with a different version number for the modified file, as with TOPS-20. BTW, I believe (perhaps wrongly) that Emacs under TOPS-20 mapped its files and did copy-on-write operations. TOPS-20 has a studly memory mapper. _MelloN_