[gclist] memory protections and system calls

[Hans Boehm]

Paul is right that this is a significant annoyance.  I know of several
systems that have run into it.

Various versions of PCR handle it by wrapping system calls.  So did at
least some versions of DEC Modula-3.

I don't consider this really satisfactory, since the code tends to be
highly nonportable.  System calls vary.  If you want the client to use
the usual names for the system calls, you need some mechanism for redefining
those names, but still invoking the original.  The "syscall" system call
often works, but not all UNIX systems implement it, and the SVR4 trend
seems to be away from it.

All of this is at best a 98% solution, since ioctl can write into protected
address space, and any oddball custom device driver can extend the semantics
of ioctl to write in new and interesting places in the user's address space.
Some unusual system calls like profil need different treatment anyway.

For our standalone garbage collector, I decided to only implement the 70%
solution instead of the 98% solution, and give the user the hooks to do the
other 30%.  The read system call comes pre-wrapped.  (It happens to be
a special case of readv on most systems, so even if syscall doesn't
exist, I have another way of naming the real system call.)  If you make another
system call that writes into the garbage collected heap, it's your problem.
The calls for wrapping the system call are provided.

My wrappers don't copy data.  They explicitly manipulate heap protections.
For a call like read that's preferable.  For calls that return small
structures, it's cheaper to copy.  Some of this gets appreciably trickier in
the presence of threads.

For GC use, I greatly prefer an OS interface that alows me direct access to
kernel-maintained dirty bits, assuming you have a GC algorithm that can get
away with just those.  I only know of one OS that gives those to
me, and none that give them to me with reasonable performance.  I don't
beleieve that there's any real reason for that, except for lack of
customer demand.

These are personal opinions ...
Hans-J. Boehm
boehm@mti.sgi.com
Hans-Juergen Boehm
boehm@mti.sgi.com