On Tue, Jul 13, 1999 at 11:29:03AM +0300, Ville-Pertti Keinonen wrote:
>
> Alan Cox <[EMAIL PROTECTED]> writes:
>
> > P.S. As an aside, just once, everyone should look at the /proc/"pid"/map
> > of a running cvsup. Each line you see is a vm_map_entry. (What you
> > see is a result of Modula-3's garbage collector.) Roughly speaking,
>
> Modula-3 really appears to be doing something weird, making half of
> the entries read-only. A garbage collected language should actually
> be capable of doing a better job than a non-gc one.
>
There's nothing weird going on. :-) It's fairly typical of a garbage
collector that leverages the VM system to detect (write) accesses
to data. (There was a DEC SRC or WRL techical report documenting
Modula-3's garbage collector. A search engine would certainly turn
it up.)
Before long, you'll see some Java implementations doing the same
thing.
> > on a page fault, if we're not faulting on the same range of addresses
> > as the last page fault, a linear cost search is performed
> > to find the correct entry.
>
> Are you suggesting that vm_map_entries should be in, say, a red-black
> tree (not a bad idea, I've done this), or that programs should just
> keep their memory contiguous ((s)brk rather than mmap)?
>
That's one possibility. You'd have the same number of vm_map_entry's
but finding the one you want is faster. (Btw, Linux has used an AVL
tree for this purpose.) The other possibility is...
Almost all of these vm_map_entry's started out as a single entry that got
fragmented as mprotects were performed by the garbage collector.
Instead of maintaining the page protections as part of the vm_map_entry,
you could separate them into a smaller, specialized data structure that is
attached to the original vm_map_entry. (SVR4, Solaris and Digital
Unix use some variation of an array with an entry per page.)
This way you address the problem by limiting the growth of the vm_map's
list of vm_map_entry's.
In the end, you may want to combine both approaches. I can't say
for sure.
Alan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
