Newsgroups: comp.lang.dylan,comp.lang.misc,comp.lang.lisp,comp.arch
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!oitnews.harvard.edu!purdue!lerc.nasa.gov!magnus.acs.ohio-state.edu!math.ohio-state.edu!news.cyberstore.ca!vanbc.wimsey.com!ddsw1!news.mcs.net!godot.cc.duq.edu!news.duke.edu!news.mathworks.com!newsfeed.internetmci.com!news.sprintlink.net!noc.netcom.net!ix.netcom.com!netcom.com!NewsWatcher!user
From: hbaker@netcom.com (Henry Baker)
Subject: Re: allocator and GC locality.
Message-ID: <hbaker-1008951349590001@192.0.2.1>
Sender: hbaker@netcom5.netcom.com
Organization: nil organization
References: <3vnvr1$9lb@jive.cs.utexas.edu> <9507261647.AA14556@aruba.apple.com> <3vb382$dtr@jive.cs.utexas.edu> <hbaker-3107951007190001@192.0.2.1> <3vnghm$sdl@info.epfl.ch> <3vtvi5$g8a@kernighan.cs.umass.edu> <kelvin.807660304@kickapoo> <hbaker-0708952138580001@192.0.2.1> <DD0722.Hst@cup.hp.com> <40dfmv$lcd@news.parc.xerox.com>
Date: Thu, 10 Aug 1995 21:49:59 GMT
Lines: 61
Xref: glinda.oz.cs.cmu.edu comp.lang.dylan:5044 comp.lang.misc:22624 comp.lang.lisp:18655 comp.arch:60344

In article <40dfmv$lcd@news.parc.xerox.com>, boehm@parc.xerox.com (Hans
Boehm) wrote:

> I'm all in favor of portable APIs to access the VM system.  But it's
> important to get the details right.  I think you want a call that marks
> certain pages "disposable", i.e. the operating system may replace them
> by zero-filled pages AT ITS DISCRETION.  An mmap/munmap style interface
> that gives the client explicit control over what's mapped doesn't seem
> quite right.  In particular, remapping a previously unmapped page is
> unavoidably expensive, even if there was no demand for the physical page.
> Security issues require that the page be cleared or somehow overwritten
> every time you do that.  (This is another reason I'm not convinced that
> malloc implementations should use munmap to return space to the OS.)

As many VM's and/or disks are already starting to compress pages when
swapping them out, the cost of zero'ing is no larger than the cost of
compressing, and compressing a page of zeros is moderately easy.  So
your concerns about the cost of zeroing out pages is probably misplaced.

If forced to live with an interface, I'd be happy with the following
simple interface:

The OS notices (either by compression or other means) that a page is
all 0's.  In this case, it doesn't bother writing the page to disk,
and free's the disk page as well.  (If you're still concerned about
security, then you're going to have to rewrite the page, or start
leaning on your disk vendors to provide destructive reads a la
linear logic.)  Later, if the page is referred to again, the VM
can reconstitute it, again without any disk I/O.  The same trick
will also work for caches.

The OS should also provide a call to explicitly zero a region of memory.
The first and last pages of the region can be zeroed explicitly, with
the remainder of the pages being zero implicitly by declaring them to
be 0's in the page table.  This is an optimization, since the user can
achieve the same effect more clumsily by zeroing the pages himself.

Finally, the OS could provide some method for 'write-allocate' in VM.  One
scheme might be to keep track of a compact region of a page that has been
written to.  Any reads will force a read from the disk, and a merging of
the new & old information.  Another method might be to do some kind of
checkpoint of the program at the point that it starts writing to the
page, and if it ever reads before the page is fully initialized, then
the program is restarted with the 'real' page.  Yet another scheme would
be to explicitly store the write-allocate bits from the cache in real
memory when the cache flushes.  If the page has write permission, but
not read permission, then a trap will occur if the program attempts
to access the page.

> I'd also love to see a cheap way to retrieve "page dirty" information
> from the OS.  A software write barrier isn't always practical (e.g.
> when dealing with third-party libraries.) And for some algorithms
> dirty bits suffice as a VM write-barrier.  And they're
> typically cheap to get from the hardware.

I've been trying since 1974 to get "page dirty" information from the VM with
relatively little success.

-- 
www/ftp directory:
ftp://ftp.netcom.com/pub/hb/hbaker/home.html
