Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I like this (shared libraries are mindlessly overused) but there were two points I didn't understand.

  And the memory savings are often actually negative
Not sure but I think this is for a library with only a single user (ever). The GOT ... and the larger call/ret code cost memory.

  And the dynamic linking will actually cause a lot _less_ sharing because of all the fixups.
I have no idea why fixups cause less sharing.


Your program uses one function from a library.

If that library is statically linked, that one function is compiled into your program. The rest of the library is ignored.

If that library is dynamically linked, the entire library is loaded into memory, and the function address is shared with your program. More memory used.

The advantage of dynamic linking is if that specific version of the library is already in memory (because another application is using it) then it takes up no additional memory. Less memory used.


> If that library is dynamically linked, the entire library is loaded into memory, and the function address is shared with your program. More memory used.

False. Shared library pages, like pages in executables, are loaded only on demand. You pay a memory cost for what you use, not what's available.


... at page granularity.


I'm pretty sure Linus was talking about the fixups to the function addresses that happen at load time. Because those pages are modified, they aren't shared with other instances of the same process (unless those processes forked from same parent after the shared library was loaded?), causing more memory usage and less cache locality than static linking:

https://en.m.wikipedia.org/wiki/Relocation_(computing)


> If that library is statically linked, that one function is compiled into your program. The rest of the library is ignored.

At least for gcc, this isn't true unless you pass some obscure flags in; the whole .a gets pulled in


> And the memory savings are often actually negative

If you consider inlining and dead code elimination from inter-procedural optimizations, this could sometime offset the savings from a library shared across 2~5 binaries.


Fixups are done by usermode code, which means the pages containing them can't be shared between different processes. The kernel has no visibility into what is being fixed up.

(Also, the fixups themselves could actually be different between different processes due to address space layout randomization.)


Thanks, I've always thought of fixups as being a linker thing [1]. But I guess it's more general than that.

[1] https://llvm.org/doxygen/classllvm_1_1MCFixup.html


Fixups are only needed for position-dependent code - Fedora (and maybe other distros too) set -fPIC -pie in default CFLAGS for all shipped binary *.so's.


I have no idea why fixups cause less sharing.

I get this now. The fixups are runtime patches for call addresses in the application code to point to where the shared library function was mmap()'d. Those patches, although they will all be the same, are in fact COW writes which will in turn prevent page sharing. The solution that Linus doesn't mention is prelink.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: