-----BEGIN PGP SIGNED MESSAGE-----
content-type: text/plain; charset=us-ascii
> mmap() tricks would pay off but we'd have to be careful to do it
> in a portable way, because it isn't standard, and we still want to
> be able to build on systems that don't have it.
Even worse, some have it but it doesn't work reliably.
This can, of course, be dealt with using autoconf tricks.
NetBSD, for example (ever since and still) has a mmap() that cannot be
trusted when used over NFS. It looks up the right filesystem *meta*
information, but the *data* you get is maybe not what what the server
has, but something that is in the client's *memory* pages (not the
*buffer cache* pages).
Yup, I'm a NetBSD user and am well aware of the mmap bugs you're
What I was doing was suggesting using mmap/munmap of anonymous memory
to allocate space for the heap, which should be safe and which
shouldn't require very much change to the Scheme48 virtual machine.
You'd have three levels of support:
1) - use sbrk() or malloc() to grab memory
(what's done today)
2) use mmap/munmap to manage the semispaces, avoiding unnecessary
pageins of new-space during GC.
(something which should be a relatively minor change to the
3) do #2, plus use mmap() to "read" in the initial image.
The current NetBSD mmap should be safe for the 2nd level of support..
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----