The document discusses 'slinky', a method of static linking which combines program libraries into a single executable, addressing the drawbacks of traditional static and dynamic linking. It enhances efficiency by sharing memory and disk space while reducing network bandwidth through deduplication. The method shows minimal performance degradation, comparable memory footprints, and low overhead compared to dynamic linking.

1. SLINKY: Static Linking
Reloaded
Christian Collberg, John Hartman et. al.
CSC 630, Fall 2013, University of Arizona
Sumin Byeon

2. Linking
• Combining a program and its libraries into
a single executable
• Resolving symbolic names of variables and
functions into their resulting addresses

3. Static Linking
• Incorporating libraries at compile-time[^1]
• Pros
• Easy to understand, implement, and use
• Self-contained apps
• Cons
• Duplications - spatial inefficiency
[^1]: More precisely, at link-time

4. Dynamic Linking
• Deferring linking until run-time
• Pros
• Space efficient (disk and memory)
• Flexibility
• Cons
• Complexity (e.g., version, path, dependency, etc.)
• Potential security risks

5. SLINKY
• Implicit sharing of libraries and data by
deduplication
• Best of both worlds
• Sharing memory pages
• Sharing disk space
• Reducing network bandwidth

6. Sharing Memory Pages
• When a page modified, it is no longer valid for
other processes. Potential solution: copy-on-
write.
• Share read-only code pages
• Data pages are likely modified, thus unlikely to
be shared anyway
• slink, digest, a set of Linux kernel
modifications

7. Slink
• Position independent code required
• Converts a dynamically linked executable
into a statically linked executable
• Finds all necessary libraries, organizes them
in the process’s address space, and resolves
symbols

8. Digest
• Inserts the digests for each code page
• Linux page: 4 KB, digest: 20 bytes - less than
0.5% overhead

9. Kernel Modifications
• Per-process digest table (PDT) - Maps page
number to digest
• Global digest table (GDT) - Contains the
digest of every code page in memory

10. Security
• Possibility of inserting malicious code
• Digest verification before loading a page to
the GDT
• Memory protection hardware
• SHA-1 or a different hash function of your
choice

11. Sharing Disk Space
• Breaking an executable into variable-size
chunks
• Only one copy of each unique chunk is
stored
• Similar idea to LBFS

12. Reducing Network
Bandwidth
• Transfers only a fraction of the chunks
• The initial transfer represents a worst-case
scenario
• Deduplication!

13. Performance
• Measured:
• Elapsed time to build the Linux kernel
• Page fault handling in both an unmodified Linux kernel
and a modified kernel
• Number of page faults - SLINKY’s effect on the page fault
rate and the memory footprints
• Suffers fewer page faults than their dynamically linked
counterparts
• Page fault rate decreased after several other executables
have added pages to the GDT

14. Memory Footprint

15. Storage Space

16. Network Bandwidth
• File size:
SLINKY exe >>>>> dynamically linked exe
• Amount of transferred data:
SLINKY exe > dynamically linked exe

17. Conclusion
• SLINKY overcomes disadvantages of static
linking by implicitly sharing data chunks
based on their digests
• Trivial performance degradation,
comparable memory footprint to dynamic
linking, and low overhead on storage