Date: Sun, 27 Mar 2011 21:11:36 +0100 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org, Jesse Smith <jessefrgsmith@yahoo.ca> Subject: Re: Prebind from OpenBSD Message-ID: <BC16EE3E-1CE3-4A41-9DAF-5340B12F7BCE@freebsd.org> In-Reply-To: <20110327200407.GL78089@deviant.kiev.zoral.com.ua> References: <1301189037.4069.43.camel@hp-laptop> <alpine.BSF.2.00.1103272049440.50590@fledge.watson.org> <20110327200407.GL78089@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BC16EE3E-1CE3-4A41-9DAF-5340B12F7BCE>