[gclist] Re: mmap maturity

[David Petrie Stoutamire]

> 2) The mechanisms for unmapping and remapping a page are not completely
> portable.  They're also less heavily excercised than brk and sbrk.  I've seen a
> reasonable number of both performance and correctness problems in this area,
> even for otherwise very stable and mature operating systems.  (I haven't
> retested this recently.  But, as one example, mmapped memory under older
> versions of SunOS4 appeared to have very different paging behavior from memory
> obtained by other means.  We sometimes saw large slowdowns with mmapped memory
> as a result.  As another example, I believe general mmap isn't very efficiently
> implementable on the original RS/6000 MMU.  I think it took IBM years to get
> any sort of credible implementation.)

I'll second this; I use some of the more esoteric features of mapping
and the /proc file system to deal with conservative roots, and have run
across no less than three implementation bugs in Solaris, starting at
version 2.3.  (2.5 has fixed two of them.  These are functional bugs
rather than performance bugs, but I haven't looked carefully at
performance yet.)  Who knows what I'd find if I were *trying* to break
it?  I don't mean to be coming down hard on Sun in particular; any
large piece of software most likely to have defects in the pieces that
are least used, and Solaris is pretty big.  Hans encountered some nasty
synchronization related bugs as well.

One of the things that makes GC fun is that aggressive implementations
tend to stress out systems in ways that they often were not designed
for, such as needing low page fault overhead, write-validate caching,
MMU interface, low-latency context switches, system timers; for
compilers, control over optimizations and sometimes register
allocation, proper debugging info, portable interfaces to word and page
size, I'm sure the list could go on and on.

This is both good and bad.  It's good because systems need to be
designed to do these things well; it's bad because it makes writing a
portable implementation even more gruesome than it already would be if
systems worked as advertised.

    - Dave S.