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. > > 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. > > * - 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_______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
