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
library.
	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.

eric