Version française
Home     About     Download     Resources     Contact us    
Browse thread
Dynamic loading. Again.
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Gerd Stolpmann <gerd@g...>
Subject: Re: Dynamic loading. Again.
On Fri, 01 Dec 2000, John Max Skaller wrote:
>	Suppose I load library X. It gets mapped to
>
>	0xFF00-0000
>
>Now suppose YOU load library X. It is already in memory.
>The loader knows that. It gets mapped to
>
>	0xFF00-0000
>
>The same address for both of us.  Now I load Y, and you load Z.
>Y loads first, under X. Then Z loads, under Y.
>Or the other way around: the order doesn't matter, but the 
>address space used had better be the same. We all share
>the same physical memory at the same address (for the shared
>libraries).

This is impractical. What about libraries loading libraries, especially
libraries loading system libraries? System libraries are loaded at addresses
you cannot determine, and the loader will probably load the system library at
different addresses for different processes. So your patching approach will
fail, and you have to work around the problem. (Unless you have your own
operating system...)

The world uses a different solution, and it does not make sense to build a
parallel world with its own rules. Furthermore there are very good reasons not
to patch the text segment:

- The startup time of executables is much shorter (relocation on demand)

- The number of libraries per system is not limited by the address space.
  Say you have 1GB for shared libraries, and every library is 512k
  ==> maximum number of libraries per system = 1GB / 512k = 2048
  This is rather small for big systems, and may be even much smaller 
  because of the next issue

- No artificial fragmentation of the address space:
  Because of unloading libraries that are no longer used the address space 
  of the whole system will be fragmented. Perhaps you get into the situation
  that you cannot load a big library because you do not find a free region
  of addresses that is large enough

- It is possible to load the same library several times because the read-write
  mapped sections of the library (i.e. global variables) can be mapped twice at
  different addresses

- It is not necessary to move text segments of libraries to swap files if the
  library is swapped out; the already working image of the text segment can be
  reloaded from the original library file

Of course, on the IA32 the code of shared libraries runs slower; however this
is not true for properly designed processors. For C code, the factor is 5% to
20% depending on the nature of the code. I do not see any good reason why a
comparable factor could not be reached for O'Caml.

Gerd
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 100             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------