From owner-freebsd-current Tue Jul 13 2: 2:43 1999 Delivered-To: freebsd-current@freebsd.org Received: from cs.rice.edu (cs.rice.edu [128.42.1.30]) by hub.freebsd.org (Postfix) with ESMTP id 310251501E for ; Tue, 13 Jul 1999 02:02:29 -0700 (PDT) (envelope-from alc@cs.rice.edu) Received: (from alc@localhost) by cs.rice.edu (8.9.0/8.9.0) id EAA19079; Tue, 13 Jul 1999 04:01:56 -0500 (CDT) Date: Tue, 13 Jul 1999 04:01:56 -0500 From: Alan Cox To: Ville-Pertti Keinonen 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> References: <199907121853.WAA27876@arc.hq.cti.ru> <19990713023012.K6401@cs.rice.edu.newsgate.clinet.fi> <86673p7y28.fsf@not.demophon.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5us In-Reply-To: <86673p7y28.fsf@not.demophon.com>; from Ville-Pertti Keinonen on Tue, Jul 13, 1999 at 11:29:03AM +0300 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Jul 13, 1999 at 11:29:03AM +0300, Ville-Pertti Keinonen wrote: > > Alan Cox 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