Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mit-eddie!genrad!decvax!decwrl!pyramid!uccba!hal!ncoast!allbery From: allbery@ncoast.UUCP Newsgroups: comp.unix.wizards Subject: Re: Big Programs Hurt Performance Message-ID: <4754@ncoast.UUCP> Date: Sat, 26-Sep-87 16:23:01 EDT Article-I.D.: ncoast.4754 Posted: Sat Sep 26 16:23:01 1987 Date-Received: Sun, 27-Sep-87 21:58:22 EDT References: <1665@ncr-sd.SanDiego.NCR.COM) <8579@utzoo.UUCP) <6886@eddie.MIT.EDU) <14888@topaz.rutgers.edu> <2501@xanth.UUCP> Reply-To: allbery@ncoast.UUCP (Brandon Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 45 As quoted from <2501@xanth.UUCP> by kyle@xanth.UUCP (Kyle Jones): +--------------- | In <14888@topaz.rutgers.edu>, hedrick@topaz.rutgers.edu (Charles Hedrick) sez: | > What you really want is shared libraries. That way, only one copy | > of the code is shared by all programs that use it, but you can | > change it. | | This doesn't sound much different from the current scheme. The | advantage of having the window system in protected RAM is that you | don't have gargantuan executables for small programs; calls to system | tools are simply linked to their known entry points in memory. +--------------- And what you describe is exactly what a shared library is. As an example: the 3B1 has libc, libtam (curses using the window devices), libm, and a few other libraries in its shared library. The first program run which uses the shared library allocates a shared memory segment at process address 0x300000 and copies /lib/shlib into it. The program is linked with a special crt0.o which does the shm attach and load (if necessary), and with a loader "ifile" (instruction file, a System V feature which gives fine control over an object file) which defines the addresses of routines in /lib/shlib with origin 0x300000, read-only data also within the shlib, and read-write data which is allocated at a fixed address just below the shlib. The result? Large programs get to use all of the routines in the shared library without having to have it compiled in (it is 126K on my 3B1) and without having to load it all the time (just once, actually done during the boot sequence). The shlib is loaded into a memory segment at some random location in memory, but is attached as a shared memory segment at a fixed address within each process using it. The bad thing about this is that a change to the shlib requires that any programs using it be recompiled, unless the changes are added to the end of the shlib... but this is true of any other method as well. And it could be remedied easily by making the first part of the shlib be a jump table to the actual code (i.e. instructions "jmp ") for each entry point. (It isn't set up that way on mine, alas.) And even so it's more mutable than ROM, all it takes is a reboot. In effect, it *is* the protected RAM scheme you speak of. -- Brandon S. Allbery, moderator of comp.sources.misc {{harvard,mit-eddie}!necntc,well!hoptoad,sun!mandrill!hal}!ncoast!allbery ARPA: necntc!ncoast!allbery@harvard.harvard.edu Fido: 157/502 MCI: BALLBERY <> "Mummy, what's an opinion?"