[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121029095002.GP24157@port70.net>
Date: Mon, 29 Oct 2012 10:50:03 +0100
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: interesting discussion about static linking on luajit ML
* John Spencer <maillist-musl@...fooze.de> [2012-10-29 07:14:35 +0100]:
> especially the statement here about memory usage seems to be a
> common misconception:
>
> http://www.freelists.org/post/luajit/Creating-a-statically-linked-executable-for-a-LuaJITC-program,22
>
well obviously if the statically linked binary is smaller
then the dynamically linked one, then he cannot save
space the way he wants.. i'm not sure where he got that
size only matters on disk
but he is right about that usually dynamically linked programs
are smaller than statically linked ones
(you should not compare to glibc binaries as they are huge no matter what)
> rich, you recently said something about this topic on irc, iirc it
> was along the lines of:
> you'd need to link substantially huge parts of libc.a to use nearly
> as much memory,
> as is typically wasted with relocation overhead in dynamically
> linked apps, do i remember correctly ?
>
the point is that with dynamically linked binary you must
have the *entire* lib available in memory
(so even if you have that shared between different processes
you need multiple processes using the lib to gain anything)
(and of course not everything is shared: there are writable
data segments (.data, .bss) which cannot be shared between
processes once they are modified (although they are small in
case of musl), and pic code is a bit bigger as well)
with static linking you only link those object files that
are actually used by the binary
(eg. in case of musl the static lib is about 340k and about
80k is just the math+complex part, if you don't use any of
that then it won't get linked in so you don't have to keep
that around in memory)
(this does not help when you link with xlib because the
simplest x client pulls in a very large part of xlib
and when you run x you surely run several x clients)
(btw even static linked programs can have in memory sharing:
when you run the same process image several times.
this is a more limited sharing than what you get with dynamic
linking, but happens: ppl often have >10 terminals open
or >50 tabs open in a browser.. or a web server have >10 copy
of the same cgi script running (maybe written in lua), the
readonly segments should be shared between these even when
they are separate processes)
other issues with dynamic linking is that at exec you
need to do the magic relocations and symbol lookups etc
which slows down spawning new processes a bit, and
calling functions through plt or accessing data through
got is a bit slower as well
but it's true that security fixes in the libc can get
into the deployed binaries faster with dynamic linking
(and of course bugs can do as well, or when there is an
abi breaking change..)
i think a serious script language should have a static
version optionally available, there are situations where
it makes sense and the size difference they are complaining
about rarely matters
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
