Date: Tue, 13 Jul 1999 04:01:56 -0500 From: Alan Cox <alc@cs.rice.edu> To: Ville-Pertti Keinonen <will@iki.fi> Cc: current@freebsd.org Subject: Re: Thread stack allocation (was Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c) Message-ID: <19990713040156.N6401@cs.rice.edu> In-Reply-To: <86673p7y28.fsf@not.demophon.com>; from Ville-Pertti Keinonen on Tue, Jul 13, 1999 at 11:29:03AM %2B0300 References: <Pine.BSF.4.05.9907121109280.19167-100000@sturm.canonware.com> <199907121853.WAA27876@arc.hq.cti.ru> <19990713023012.K6401@cs.rice.edu.newsgate.clinet.fi> <86673p7y28.fsf@not.demophon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 13, 1999 at 11:29:03AM +0300, Ville-Pertti Keinonen wrote: > > Alan Cox <alc@cs.rice.edu> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990713040156.N6401>