From: Gerd Stolpmann <gerd@gerd-stolpmann.de>
To: John Max Skaller <skaller@ozemail.com.au>, fabrice.le_fessant@inria.fr
Cc: Vitaly Lugovsky <vsl@ontil.ihep.su>, caml-list@inria.fr
Subject: Re: Dynamic loading. Again.
Date: Mon, 4 Dec 2000 22:06:52 +0100 [thread overview]
Message-ID: <00120422430804.00625@ice> (raw)
In-Reply-To: <3A27D683.5C34212E@ozemail.com.au>
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
----------------------------------------------------------------------------
next prev parent reply other threads:[~2000-12-04 22:06 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-26 0:09 Vitaly Lugovsky
2000-11-28 1:27 ` John Max Skaller
2000-11-29 16:42 ` Fabrice Le Fessant
2000-11-30 7:02 ` John Max Skaller
2000-11-30 16:08 ` Fabrice Le Fessant
2000-12-01 12:59 ` John Max Skaller
2000-12-01 14:24 ` Fabrice Le Fessant
2000-12-01 16:49 ` John Max Skaller
2000-12-04 21:06 ` Gerd Stolpmann [this message]
2000-11-30 18:00 ` Chris Hecker
2000-12-01 13:34 ` John Max Skaller
2000-11-30 20:55 ` Gerd Stolpmann
2000-11-28 11:14 Ken Wakita
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00120422430804.00625@ice \
--to=gerd@gerd-stolpmann.de \
--cc=caml-list@inria.fr \
--cc=fabrice.le_fessant@inria.fr \
--cc=skaller@ozemail.com.au \
--cc=vsl@ontil.ihep.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox