Subject: Re: "filtered" shared libraries
To: None <email@example.com, firstname.lastname@example.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 11/01/2001 20:54:01
>>> 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
library containing all of them, you page in all of stdio and numerous
bits and pieces of other stuff - everything that happens to reside in
the same page as a piece of stdio. Depending on how the library is
built, this may be little or it may be a lot. Has anyone checked to
see how good the functional clumping is in libc?
> 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.)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML email@example.com
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B