From owner-cvs-all Tue May 23 12:46:34 2000 Delivered-To: cvs-all@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5A85237B7C2; Tue, 23 May 2000 12:46:29 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id MAA69062; Tue, 23 May 2000 12:46:27 -0700 (PDT) (envelope-from dillon) Date: Tue, 23 May 2000 12:46:27 -0700 (PDT) From: Matthew Dillon Message-Id: <200005231946.MAA69062@apollo.backplane.com> To: Mike Smith Cc: Martin Cracauer , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: VM load with static binaries (Re: cvs commit: ports/shells/bash2) References: <200005231802.LAA09470@mass.cdrom.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :We don't support gzipped binaries anymore. : :> Shared libraries are only an advantage (with regards to VM space) when :> several *different* binaries that are linked to the *same* shared :> library run simultaneously (typical X11 situation). : :Typical situation with anything; : :-r--r--r-- 1 root wheel 1139620 May 10 13:26 /usr/lib/libc.a :-r--r--r-- 1 root wheel 540112 May 10 13:26 /usr/lib/libc.so.4 : :> I suggest that you look up the relevant discussions with John Dyson in :> the mail archives and adjust the zsh accordingly. : :Since most people run more than *just* a shell on their box (yes, I :realise you may be weird in this case), I'd expect that the static binary :win is imaginary. : :(Note also that two identical shared binaries will also occupy the same : vm space...) Actually there are instances where static binaries help, but they are few and far between and have nothing to do with shell binaries or general computing. It takes a very specialized case. The only reason dynamic libraries aren't always the best solution is simply the fact that when you have a program which uses a dynamic library, it dirties a couple of library-related pages doing the glue. The same program statically linked will actually have fewer dirty pages for the OS to deal with (and the dirty pages, being from a private map, are unshareable). So if you are running a few hundred instances of some program (exec'd, not forked), it may be beneficial to link that program statically and save the handful of dirty unshareable pages in each process that dynamic linking would give you. This is why two of the programs used in my Diablo news system are statically linked. Side note: programs that fork to create copies of themselves do not have this problem, since the dynamic libraries have already been loaded prior to the fork the fixup pages will be shared across all the forks. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message