From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] Virtual memory & paging From: forsyth@caldo.demon.co.uk MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-qbvdaodgnammxxcqnymdbzzrjs" Message-Id: <20020204103320.B077D19A17@mail.cse.psu.edu> Date: Mon, 4 Feb 2002 10:30:39 +0000 Topicbox-Message-UUID: 4b1f0f7c-eaca-11e9-9e20-41e7f4b1d025 This is a multi-part message in MIME format. --upas-qbvdaodgnammxxcqnymdbzzrjs Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit there isn't a copy of the library in every executable because the linker includes from the library only the functions the program uses (directly or indirectly). this is typically smaller than the whole library. there would be scope for some sharing but the gain dynamically is typically small: not all the executables in /386/bin are in use simultaneously. after all, it's hard to buy a machine with less than 64mbytes these days and with plan 9 running rather a lot of that is free space, unless you've got big memory applications such as ghostscript in which case it's the application rather than the library that consumes the space. i suppose if you'd got an enormous application library shared by several applications in use at once you'd see more need for library sharing. in plan 9, that shared functionality might be better represented as a file server (though not always). dynamic linking might be of more interest (in Plan 9) for selection amongst a set of implementations at run-time. --upas-qbvdaodgnammxxcqnymdbzzrjs Content-Type: message/rfc822 Content-Disposition: inline Return-Path: <9fans-admin@cse.psu.edu> Received: from punt-2.mail.demon.net by mailstore for forsyth@caldo.demon.co.uk id 1012803949:20:22708:58; Mon, 04 Feb 2002 06:25:49 GMT Received: from psuvax1.cse.psu.edu ([130.203.4.6]) by punt-2.mail.demon.net id aa2124485; 4 Feb 2002 6:25 GMT Received: from psuvax1.cse.psu.edu (psuvax1.cse.psu.edu [130.203.8.6]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id 2B365199ED; Mon, 4 Feb 2002 01:25:07 -0500 (EST) Delivered-To: 9fans@cse.psu.edu Received: from ohio.river.org (river.org [192.160.193.125]) by mail.cse.psu.edu (CSE Mail Server) with ESMTP id DDA7E199BB for <9fans@cse.psu.edu>; Mon, 4 Feb 2002 01:24:26 -0500 (EST) Received: (from ru@localhost) by ohio.river.org (8.9.3/8.9.3) id WAA23600; Sun, 3 Feb 2002 22:21:45 -0800 (PST) To: 9fans@cse.psu.edu Subject: Re: [9fans] Virtual memory & paging Message-ID: <20020203222145.A22998@ohio.river.org> References: <20020203231258.8ED7B199E8@mail.cse.psu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20020203231258.8ED7B199E8@mail.cse.psu.edu>; from geoff@collyer.net on Sun, Feb 03, 2002 at 03:08:39PM -0800 Sender: 9fans-admin@cse.psu.edu Errors-To: 9fans-admin@cse.psu.edu X-BeenThere: 9fans@cse.psu.edu X-Mailman-Version: 2.0.8 Precedence: bulk Reply-To: 9fans@cse.psu.edu List-Help: List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.cse.psu.edu> List-Archive: Date: Sun, 3 Feb 2002 22:21:45 -0800 On Sun, Feb 03, 2002 at 03:08:39PM -0800, geoff@collyer.net wrote: > Even if your physical memory were as large as your virtual address > space, an obvious advantage to mapping addresses is [...] > Another potential use of mapping is to avoid copying data by remapping > pages. Plan 9 has no DLLs. It has a C runtime library. I'm sure it's smaller than the GNU C library, but is there a copy of the libary in every executable in /bin? is there a copy of it in every process's memory or is it shared among all the processses? if so, is memory mapping how the sharing is effected? (I know this is undergrad material. Let me know if I should stop asking elementary questions here.) --upas-qbvdaodgnammxxcqnymdbzzrjs--