Farid Zakaria, doktora çalışmaları sırasında ve sektörde (özellikle Google gibi şirketlerde) karşılaştığı, ancak akademik makalelerde atıf yapamadığı bir sorunu ele alıyor: devasa ikili dosyalar (binaries). Özellikle büyük kod tabanlarına sahip şirketlerde, hizmetlerin daha hızlı başlaması ve dağıtımın kolaylaşması için tüm kodun statik olarak derlenmesi tercih ediliyor. Bu yaklaşım, debug sembolleri dahil 25 GiB'ı aşan ELF dosyaları gibi muazzam boyutlarda ikili dosyalara yol açabiliyor. Yazar, bu durumun, kod boyutunun belirli bir noktadan sonra sorunlu hale geldiği ve kodun nasıl bağlandığı (linking) ve derlendiği (building) konusunda yeniden düşünmeyi gerektiren bir "ses bariyeri"ne benzediğini belirtiyor.
Bu "ses bariyeri"nin teknik karşılığı, x86_64 mimarisi için 2 GiB'lık "Relocation Barrier" olarak açıklanıyor. Bu sınırın nedeni, konumdan bağımsız kodun (Position Independent Code - PIC) çalışma şekliyle ilgili. CALL gibi bazı komutlar, hedef adresi belirtmek için 32-bit işaretli göreceli bir ofset kullanır. Bu 32-bit ofset, mevcut talimat işaretçisine göre yalnızca yaklaşık +/- 2 GiB'lık bir aralığı adresleyebilir. Eğer çağrılacak fonksiyon bu 2 GiB'lık aralığın dışındaysa, standart CALL talimatı doğrudan kullanılamaz ve ikili dosya bu sınırı aşar.
Makale, objdump ve readelf gibi araçlarla basit bir C kodu örneği üzerinden bu mekanizmayı detaylandırıyor. e8 00 00 00 00 şeklindeki CALL opcode'unun nasıl 32-bit göreceli bir ofset aldığını ve R_X86_64_PLT32 gibi "relocation" girdilerinin, bağlayıcının (linker) bu adresleri daha sonra düzeltmesi için ikili dosyaya nasıl gömüldüğünü gösteriyor. Bu teknik sınırlama, büyük ölçekli yazılım geliştirmede karşılaşılan önemli bir performans ve mimari sorununa işaret ediyor.
Büyük kod tabanlarında statik bağlama tercihi nedeniyle ortaya çıkan devasa ikili dosyalar, x86_64 mimarisindeki 2 GiB'lık "Relocation Barrier" gibi teknik sınırlamalarla karşılaşarak yazılım geliştirme süreçlerini ve mimari kararları derinden etkiliyor.