From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue,  4 Nov 2008 21:17:24 -0800
From: Roman Shaposhnik <rvs@sun.com>
In-reply-to: <45D12424-9708-4FA1-AC6D-347911D5437D@mac.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Message-id: <63B8FC54-74DC-4602-943F-28B870FF619B@sun.com>
MIME-version: 1.0
Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII
Content-transfer-encoding: 7BIT
References: <881195a3697792959fed01ea8b6980bf@terzarima.net>
	<45D12424-9708-4FA1-AC6D-347911D5437D@mac.com>
Subject: Re: [9fans] mmap and shared libraries
Topicbox-Message-UUID: 3007b31a-ead4-11e9-9d60-3106f5b1d025

On Nov 3, 2008, at 5:16 AM, dave.l@mac.com wrote:
> A thought ...
>
> Shared libraries do 2 possibly useful things:
> 1) save space
> 2) stop you having to re-link when a new library is released.
>
> Now 2) doesn't really happen anyway, due to .so versioning hell,
> so we're left with 1) ...
>
> I know it's kind-of hacky and unstructured (how do you know the
> venti block size?),
> but could you not block-align the library members in the .a,
> so venti would do the sharing on disk for you?
>
> As a further step, you could also page align the text segments of
> the library members,
> then implement a venti-like scheme for read-only pages in memory,
> so that when the executable loads, it gets any common library pages
> shared.

I was thinking about exactly the same approach when I was
contemplating the
evils of dynamic linking. It seems that if you link statically and you
use FS
to help you coalesce identical blocks (on storage devices and in RAM)
you get
all of the potential benefits of a dynamically linked binary except
one -- distribution.
A standalone statically linked binary is going to be considerable
larger while
in flight over data links.

> P.S. Sorry not to make Volos: where are the rest of the photos?

Yeah -- where are they?!?! ;-)

Thanks,
Roman.