From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 20:11:39 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 975CA1065670 for ; Sun, 27 Mar 2011 20:11:39 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6F10B8FC0A for ; Sun, 27 Mar 2011 20:11:39 +0000 (UTC) Received: from [192.168.2.112] (host86-147-11-178.range86-147.btcentralplus.com [86.147.11.178]) by cyrus.watson.org (Postfix) with ESMTPSA id 2DF3846B43; Sun, 27 Mar 2011 16:11:38 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Robert N. M. Watson" In-Reply-To: <20110327200407.GL78089@deviant.kiev.zoral.com.ua> Date: Sun, 27 Mar 2011 21:11:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1301189037.4069.43.camel@hp-laptop> <20110327200407.GL78089@deviant.kiev.zoral.com.ua> To: Kostik Belousov X-Mailer: Apple Mail (2.1082) Cc: freebsd-hackers@freebsd.org, Jesse Smith Subject: Re: Prebind from OpenBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 20:11:39 -0000 On 27 Mar 2011, at 21:04, Kostik Belousov wrote: > The most serious issue with prebind is a consistency. > It is very easy to get prebind data out of date, and this is > esp. easy in the FreeBSD where buildworld and source port upgrades > are everyday activity. >=20 > Before this goes much further, yes, we need a benchmarks that = demonstrate > that system spends significant time in the symbol resolution for often > started images [*], and second, we need to have a workable model for = source > upgrades. >=20 > * - so that Firefox, OpenOffice etc do not qualify, IMHO. As I recall, Apple actually does prebinding/etc only for a small set of = commonly used libraries -- their libSystem, and then a dynamically = determined set of other libraries. Their model puts the libraries into a = common shared memory segment that can then be mapped at the same address = for all dynamically linked processes in the same chroot. This amortised = not only the cost of linking, but also the cost of managing memory = mappings (I believe it's a shared submap, but my VM terminology is ... = ageing). The downside to their approach is that it requires special = kernel support, and probably encodes things that we would prefer not to. However, you could imagine a daemon providing a similar service, in = which a file descriptor is made available via a UNIX domain socket to = instanced of rtld around the system, which can consistently map it in = the same place on each exec. This would also give us an upgrade model = that might work better -- the daemon actually prepares the contents of = that memory and makes them independent from on-disk storage: when an = upgrade is done, you kick the daemon to introduce a new shared memory = object, closing the previous one, which causes it to be GC'd when all = outstanding processes have exited. Robert=