NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/unix/bsd/10252

Text File | 1992-12-15 | 4.8 KB | 91 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!zaphod.mps.ohio-state.edu!darwin.sura.net!ra!tantalus.nrl.navy.mil!eric
From: [e-mail] (Eric Youngdale)
Subject: Re: Shared lib benchmarks, and experiences
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Naval Research Laboratory
References: <[e-mail]> <[e-mail]> <[e-mail]>
Distribution: usa
Date: Tue, 15 Dec 1992 19:44:49 GMT
Lines: 78

In article <[e-mail]> [e-mail] writes:
>So as long as you reserve enough extra space and you cause (using tools) the
>jump table to be ordered appropriately, your libraries can be made forward
>compatible.  The following restrictions still apply:
>
>  1) You must reserve enough space, which means wasting address space,
>     and, depending on how dynamicly the library changes, you may eventually
>     ``run out'' of space unless you are very liberal in what you reserve.
>     Neither of these problems is very major, assuming some care and
>     forethought in the creation of the library.
>
>  2) You still ``pollute'' the address space of all processes, due to the
>     assigned addresses.  I personally think this is a serious drawback
>     because this problem only grows worse with time, and cannot ever
>     be reduced without creating incompatibility.  And it requires central
>     authority...

    It is a drawback, but I feel that it is a relatively minor one.  Under
linux we have reserved 1.5Gb for sharable libaries, and a most we are using
about 0.25% of that right now.  If you assume that because of padding and
allowances for future expansion that the maximum usable fraction of this would
be no less than 25%, then this would mean that we could use at least 375Mb of
sharable libraries.  By todays standards this seems ridiculous, but if we are
looking 5-10 years down the road it might not seem so silly.  Still, this type
of usage would be extremely taxing on the 3/486 architecture as we know it
today and I suspect that any application that needs this much VM would probably
be best run on a 64 bit machine.

    You are also correct about the central authority.  This is all behind
the scenes for most users, but someone does need to coordinate.  Theoretically
we could end up with a situation where one library grew to the point where it
encroached upon another libraries VM, and this could be dealt with by dividing
the library into two separate but interdependent sharable images.  Clearly
given enough time, and enough expansion things could become a real mess.

    As a corralary to this, does anyone have a sense of how the dynamic
linking time grows as the library grows?  For example, would it go as N, N^2
(where N is the number of symbols), something inbetween?  If you assume that
function sizes remain roughly constant (so that human programmers can easily
manage them), then conceivably the number of entry points would be proportional
to N, and the number of externals that need to be resolved could also be
proportional to N.  We could also assume that machines will be M times faster,
and this would mean that the dynamic link time could go as N*N/M.  My point is
that the time to dynamically link to 100Mb worth of sharable libraries could
conceivably grow to unacceptable levels.  Right now all we can do is speculate
and extrapolate.

>| Inter-calling (calls within the library) are all resolved by the
>| linker without having to even look at the jump table.
>
>Which, BTW, is a restriction.  A staticly loaded replacement for such
>a routine will not be called by the library code.  Typical examples
>are malloc() routines...

    Yes, we do run up against this.  Emacs presents exactly this problem
with malloc.  I know that it can be solved because we all (who use emacs,
anyways) use a version that is linked to a sharable library, but this is
clearly something that does need to be considered in certain cases.

>| Anyway, we have been refining the concept for about 6 months, and we
>| now have it to a point where the drawbacks are quite minimal.
>
>I agree.  I still think that the benefits of DSLs make them worth the
>effort though.  I remember my sigh-of-relief when I went from SVR3 to
>SVR4 shared libraries...

    There are plusses and minuses to both approaches.  As long as the
details are handled properly, I think that either approach will work just fine
as far as the end user is concerned.  Now that I think about it, I recall that
in our case the people who wanted the DSLs were unwilling/unable to write the
code to make it work.  The people who wanted the fixed address libraries were
willing to do the programming, and this tipped the balance in favor of the
fixed address libraries.  Given that we both inhabit similar types of
"democracies", something like this could well be the deciding factor for 386bsd
as well :-).

--
Eric Youngdale