Hacker News Reader

> The first reason was disk space: object files could simply be smaller. Nowadays, for all intents and purposes, disk space is free and unlimited.

It's not for disk space, it's runtime RAM occupation usage. The code for a .so is going to be slightly larger than the equivalent .a. At the very least, you'll need to burn extra space for the PLT and GOT. And PIC relocations are going to tend to burn more space than static linking relocations.

The advantage of a .so you're talking about is that you can load a library shared by multiple processes at a fixed virtual address location that's the same for all processes, and thus you only burn the library once in RAM. For static libraries, the embedded addresses are going to be slightly different depending on their corresponding libraries, so even magic deduplication isn't going to be able to keep you from having the library in multiple places in physical memory.

To your first point: iOS takes this idea to its logical conclusion and it seems to be an important aspect of iOS’s performance. https://iphonedevwiki.net/index.php/Dyld_shared_cache

icache, TLB entries, and even L1 are much more limited than main memory, especially on embedded devices. By linking everything into a single object, iOS can save on wasted padding and use superpages to map the shared library into each process in a TLB-efficient way.

macOS as well.

Modern shared libs load at different addresses in different processes. For that to work, they have to be compiled with relocatable code generation, and mapped read-only.

Ancient Linux distributions once had something called "a.out shared libs". These were mapped to fixed addresses. The distribution had to work out non-conflicting addresses for all available libraries. The build procedure for a.out shared libs involved intercepting the assembly output of GCC and doing some text processing on it.

A modest proposal: let's use only static libraries (plugins aside). Let's help KSM efficiently merge the R/X, and the R/O memory pages of the static libraries of running processes. To maintain the current performance, let's give KSM a hint: the hint would be a string of standardized, canonical library pathname, including name and version number.

During the (static) linking of libraries, an extra metadata item would be stored in the ELF file: the canonical pathnames of all the static libraries used, along with base addresses of R/X segments (code) and R/O segments (r/o data). Upon forking a process, the information would be provided to kernel, and passed over to the KSM, to use as basis of same-page lookup and possible merging of the pages.

This effectively inverts the current mechanism. Currently when libraries are dynamically loaded, the dynloader uses actual file pathname of the shlib as the key for operation opposite to "merging" - i.e., re-uses the already loaded R/X and R/O pages, by adding proper memory mapping.

The proposed change is three-fold:

  1) extend the linker to add the metadata to ELF,

  2) extend in-kernel ELF interpreter to extract the info upon exec() and friends,

  3a) extend the KSM with a limited mode, where it would look up & merge only the hinted memory regions, in linear fashion, right after an exec() & friends.

An alternative to 3a), to avoid fussing about with KSM:

  3b) modify the VM subsystem to extend current swap/SHM so it provides an unique address range for each static lib canonical pathname. Requesting pages from this address range would map from the shared pages, if any process already loaded one such.

To handle adversarial processes on single machine, a further extension where crypto signatures are checked is possible.

RAM is free, too, at least as far as library code size is concerned.

A typical system has dozens or hundreds of processes running even when nothing is going on. If they all had their own copy of every system library in RAM, it wouldn’t look so free. Especially on mobile devices.

What if the OS could dedupe pages?

You'd need to arrange for the linking process to result in identical (and identically-aligned!) code pages. If you're going to all the trouble to ensure that, why not just write it all to a file and call it a shared library?

Exactly. Emperors' new clothes from naive convention abandonment of solved problems.

On the fly memory dedupe is incredibly expensive. Especially compared to just not duplicating in the first place.

Also, it's quite likely that static linked libraries wouldn't be located at the exact same page offsets every time they're linked in to a binary, making page-level dedupe not useful.

What if the OS could map a shared object that resides in one section of memory into the virtual address space of multiple processes?

Do any OSes actually do this, though? If not, this is academic until one actually does.

Linux does have something called "KSM" that de-dupes memory pages, but it appears that it's only so a hypervisor can de-dupe guest OS pages? Odd that it's not more general than that. Though I guess there is a cost: the KSM code needs to scan through memory to find duplicate pages, which I can't imagine is fast.

Would not work with any kind of LTO.

Meh, not so much. The processes will only page in the code they actually use.

Shared libraries are a goofy hack dating back to a time when people mistakenly thought they needed them, and they need to go away.

Shared object libraries are incredibly useful because they save memory and CPU resources. Cloning the process space during a fork(2) call, initializing structures, then context switching and whatnot is incredibly expensive.

shared library can be expensive as well, the dynamic symbol lookup could be a lot more expensive than people would assume.

Correct. Shared libraries trade away CPU for memory. Even with some benefits in terms of cache warmth, the extra indirection and loader/VM complexity make shared libraries a net loss in terms of CPU.

>Cloning the process space during a fork(2) call, initializing structures, then context switching and whatnot is incredibly expensive.

Err, we're running Electron apps today, with a full blown embedded browser engine, a vm, and a hellish complex DOM for rendering. Others run apps inside containers, with their own basic OS and standard libs -- compared to that the above is negligible.

> we're running Electron apps today

Some of us try not to on the belief that they don't perform acceptably.

You can usually avoid this problem by using the web version of Slack, Discord, Rocketchat, etc. A single browser running everything is obviously more efficient than running ten.

Nope. A strawman wrong doesn't justify anything related to the topic. fork() duplicates everything, which maybe overkill, which is why pthreads and vfork+exec also exist.

That's not why pthreads exist, and vfork barely does. Pthreads exist to facilitate parallel operation (hence the name) on shared data, not as an efficiency measure. As for vfork, it has been deprecated since every UNIX implementation started marking pages as copy-on-write instead of actually copying. I was doing some of that work myself in 1990-91, so it's hardly new.

The real problems with static linking don't have to do with fork, except in the sense of increasing reliance on VM overcommit (which IMO is a bad idea already). It's more to do with masking reuse of the same library across unrelated processes, as an efficiency issue but even more importantly in terms of tracking dependencies and updating software. No matter how good your configuration management (or similar mechanism) is, rebuilding large-N statically linked executables is less efficient and more error-prone than using the same information to update small-N shared libraries.

You are working on one of these electron-style apps, right?

(Shrug) RAM is there to be used.

I don't think we need to get into my optimization street cred, but suffice it to say I've never used Electron and couldn't really tell you exactly what it is.

Resources aren't infinite. It's arrogant and wasteful to be lazy and resource greedy.

Electron is an embedded web-browser meets cross-platform application platform.. it's bloated, slow and awful... it makes Java look snappy, lightweight and brilliant.

I don't get it. You're using more RAM for literally no benefit. The end result is exactly the same. There isn't even a productivity benefit in the vast majority of cases because a huge chunk of software is packaged by the OS to use shared libraries by default.

Avoiding DLL hell is certainly a benefit. It seems likely that few participants in this thread besides myself have ever actually had to support end users.

you would be surprised to learn that for very large binaries (think about monolithic front end codes at large internet companies), code size is actually enough to put pressure on instruction caches and lead to paging!

It used to be free, until people thought it was free to waste.

RAM is free as long as you don’t have to pay the price. But it does have a price.

> a couple of years ago I went static only

You mean for your code, deployed on your systems. Yeah, that works fine.

Now ship a binary to a client system with your static TLS implementation, JPEG decoder, LZ decompressor, whatever. And then go hire someone to watch the CVE feeds every day to know when you have to get them to install an upgrade.

Of, if you don't want it to be your fault when they get pwned, you could just link against the system libraries and tell them to stay updated.

"Static only" makes sense for web apps developed and deployed within the same organization, for embedded solutions where the whole update/upgrade process is known to be under the control of the developer, and... basically nowhere else.

This advice is bad, sorry.

Not the parent, but I think dynamic linking with system libraries is the only time it makes good sense. Otherwise you're just asking for trouble.

The GP argues that it should be abolished everywhere, even in the cases where it makes good sense.

Of course, you need to make sure that your system actually provides up-to-date implementations of these libraries.

Still a much better bet than that you will.

Do you play any steam games or most other modern games? Yea those static compile almost everything.

This example hurts the case, it doesn't help. Windows deployment, especially of C/C++ apps, is indeed a problem. And for decades it was absolutely routine that random windows binaries turn out to be subject to attacks against libraries like zlib or libjpeg which had been long since patched in linux distributions but lived on statically in exploitable blobs.

Things have in fact gotten much better over the past years, though. Largely because developers (even of games) have moved away from this architecture and onto managed runtimes like Java and .NET where the runtime and system provide cleaner separation of dependencies and don't require the "static all the time" nonsense that was the norm since the beginning of PCs.

Shared libraries by themselves are not the problem here, so I’m not sure why you bring them up.

The problem described in the article appears when you dynamically load/unload shared libraries. This only comes up in the context of plugin systems, or sometimes hot code reloading, and in those cases there is no alternative; there is nothing you can do with static binaries to emulate this behaviour.

I hack on the Android operating system. Without shared libraries, the system would fall over and die pretty much instantly, and Zygote helps only a little. Static linking the world is a luxury one can only afford in cornucopian backend environments where one can just throw money at resource limitations. On mobile, we have to work with the hardware we have. Economy is still important --- that's why I love it. Constraints breed creativity.

* Speaking in my own capacity

As short info, Zygote is gone on Android Q.

To be fair, DLL Hell has a lot more issues than just versioning or registering the unload handler.

First, there’s load order which can mean that you’re not actually loading the DLL you think you are.

The second is WOW64 (Windows on Windows). Rather than using fat binaries like Linux and Mac OS, Microsoft decided to use a “brilliant” strategy where the file system lies to you in the “right” ways so that old 32-bit folders are moved to new addresses and the old 32-bit named golfers hold 64-bit binaries. This means that unless you use the “I really mean it” escape mechanisms (e.g. the “sysnative” directory) 32-bit binaries on 64-bit windows is actually loading DLLs from different paths than the code says.

I want to live in this world where disk space is free and unlimited, but it isn't and has never been.

A primary goal that you don't really cover is conserving not just disk space, but memory. The disk space saved is a proxy for memory savings, which are (even more) valuable. Shared libraries linked in to multiple independent binaries can consume little to no additional memory due to the magic of virtual memory. The same does not hold true for static-linked libraries in multiple binaries.

Honest question: have you ever ran into a situation where reducing binary sizes dramatically improved either performance or disk-space utilization?

The reason I ask is, even as "bloated" as software is these days, I could fit ~100,000 fat 10 megabyte Go binaries on my SSD, without bothering to reach for compression. In practice, binaries on disk always pale in comparison to the amount of disk space I spend on media files, caches, backups and imaging, etc.

Perhaps your concerns about virtual memory are true, but looking at top on a machine running Firefox with many tabs open, Discord (an Electron based application,) 3 GNOME Terminal windows, HexChat, Wine, and Telegram... I still don't crack 100 tasks. Still.*

How about a server environment? Well, saving memory is certainly valuable on a server, but I would fail to imagine a scenario where you want so many different distinct binaries running that it would make a major difference in utilization. The shared memory savings that come from dynamically linked libraries are effectively removed when using Docker because each Docker container is going to have its own isolated system libraries and many of them probably won't be the same anyways, and yet I've never had any Kubernetes system where the majority of memory usage came from binary sizes.

I suppose if every single system binary was statically linked, you would maybe be able to notice some kind of difference. But honestly, probably not, unless you were really searching. Usually disk usage of binaries is a much less important concern than CPU and RAM usage, especially across large fleets.

*Though, that was only checking under my local user; it does turn out that there are a fair bit more tasks, but a good amount of them are actually kernel tasks. There's 400 counting kernel tasks, but only 191 not counting kernel tasks. Still not a very large number, in my opinion.

That world is here. Though people are running out of space, same as ever, if you took away movies and videos, they would not know what to do with all that space.

You missed the third one, which is used a lot in desktop software and application servers, plugins and dynamic configuration on production.

In name of stability, one may say to run external processes with shared memory instead, but now imagine the resource usage of something like InteliJ or Eclipse using only processes for their plugins.

Wouldn't this be analogous to web browsers running each tab in its own process? I don't run IntelliJ or Eclipse - do people generally have more plugins than they'd have browser tabs?

It kind of is, but do you happen to have around 300 tabs or more open?

And on an 8GB machine, which most business still use nowadays.

This kind of desktop software, each feature can be its own plugin, meaning menu entries, UI widgets, integration with external tool, database drivers, ….

Now imagine that to the extreme that every class could be a possible plugin, and even 300 will be a low bar.

IDEs are only one exemple, there are plenty of use cases on desktop software, like music, graphics editing for two other common cases.

Plugins have interactions.

Browsers are VM managers. Their tabs are the tabs of the VM manager like a VirtManager for KVM or VmWare vSphere. Browsers boot a JS VM fast over HTTP and then communicate over the same HTTP.

This is crazy! If every app in the iOS or Android app store "just shipped a static binary", all apps would be enormous, and the OS vendors would be unable to evolve the system whatsoever.

Already now, the main reason users uninstall apps is to play disk space tetris.

They already do, except for the slowly shrinking set of platform libraries.

> the slowly shrinking set of platform libraries

Not on iOS?

That is ok if you're just dealing with the upper layer of code, i.e., the final application. Then statically linking can very well be the best solution. But if you're building an operating system or distribution and do not want to recompile the whole of it (and let users download and reinstall the whole of it) each time you fix a bug in a core library, then static linking becomes pretty quickly a big pain.

More or less the same happens with C++ header-only libraries, which are basically uncompiled static libraries. They are very nice and possibly allow strong optimization, but are rather painful to handle in a distribution.

> Plus with a static binary, if you really care about order of loading/unloading etc (which you ideally shouldn't) its trivial to manage with a custom linker script.

Why? It seems to me rather sensible to deinitialize resources in the opposite order in which you initialized them. This way the time span of different resources are contained each within the other instead of just overlap. When using RAII in C++ (which is basically just atexit on a finer grain) it often makes sense to have this requirement.

How would i.e. OpenGL IHV drivers work as static libraries? No driver updates without a recompile? No driver switches (between vendors) without a recompile?

Re-link, but yeah.

Shared libraries also reduce RAM usage; multiple executables that use the same shared library can load it into memory just once.

If you alawys write exactly one monolith, you are probably fine. But when you don't buy into the hype of "every service/app/executable in it's own language", you probably want to share some code between all your executables. Say the DB driver, the model, or even just a video codec.

Without dynamic linking you duplicate all that stuff and, even worse, cannot be certain that all your executables use the same version.