Subject: Re: "filtered" shared libraries
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Eric Haszlakiewicz <firstname.lastname@example.org>
Date: 11/01/2001 23:11:54
On Thu, Nov 01, 2001 at 08:54:01PM -0500, der Mouse wrote:
> >>> Sounds like a cool idea, does ld.so already do this?
> >> Isn't this called "demand paging"?
> > Thanks for reminding me! I wonder why anyone would need "lazy
> > loading" to be explicitly supported by the link loader.
> Primarily, I would think, because it guarantees functional grouping.
> If you filter-load stdio, strings, and the resolver, let's say, and use
> only stdio, you page in only stdio. If you load a single shared
You get almost exactly that just by splitting the library into
sub-libraries that the filter lib links against. Then you'd only page in
the headers of each library until you actually used something in it.
> > I guess with "lazy loading" you could have even less mmap'ed in the
> > first place, but why would you need that on a server system?
> VM consumption? The ability to replace one library without having to
> rebuild and replace a whole humngous blob? The ability to defer
> deciding exactly which library to actually use until as late as
> possible? (For example, I could imagine a libc that lazily loads
> shared libraries for string stuff depending on wihch locale is in use.)
Replacing one small library doesn't require lazy loading, just a split
I believe deciding which library to load can be done using dlopen (of
course you still need a stub function in the primary library to do this)
So the only thing lazy loading really gets you is decreased VM consumption.