-----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
referring to..
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
virtual machine)
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..
- Bill
-----BEGIN PGP SIGNATURE-----
Version: 2.6.1
iQCVAwUBMJq2kVpj/0M1dMJ/AQE2/gP+IyFy5kZq2v0QOtAue8f0Wr45hEy7QQrz
Icu9GBsn9nGn2DyWEw7AwZF4C9YKOuxXMsb1eZSEHMsWA2Q3z5c+OT2UzIMxgAm1
o36y7h3hVP6VG08urSomavbO6VMK+OhLCngsSDQCBChoWR77FRlj0xHZtb6foVsJ
nGQC/BpkkkU=
=Q+Z1
-----END PGP SIGNATURE-----
|