Date: 13 Jul 1999 11:29:03 +0300 From: Ville-Pertti Keinonen <will@iki.fi> To: Alan Cox <alc@cs.rice.edu> 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: <86673p7y28.fsf@not.demophon.com> In-Reply-To: Alan Cox's message of "13 Jul 1999 10:32:41 %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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > 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)? The latter is becoming increasingly difficult with the large numbers of shared libraries and growing use of dynamically loaded internal modules (XFree86 4.0?). 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?86673p7y28.fsf>