Sorunun geçmişi
Go'nun bellek güvenliği modeli, tampon taşmalarını ve bellek bozulmalarını önlemek için dilim ve dizi erişimlerinde sınır kontrolü gerektirir. Erken derleyici versiyonları bu kontrolleri çalıştırma zamanında ayrım gözetmeksizin gerçekleştiriyordu, ancak modern Go araç zincirleri, indeks geçerliliğinin matematiksel olarak yürütmeden önce garanti edilebildiğinde gereksiz kontrolleri ortadan kaldırmak için karmaşık SSA tabanlı statik analiz ("ispat" geçişi) içermektedir.
Sorun
Sınır kontrolleri, CPU talimat boru hatlarını bozan, SIMD vektörleştirmeyi engelleyen ve sıkı döngülerde önemli ölçüde döngü tüketen dal talimatları ekler. Paket işleme veya sayısal hesaplama gibi performans kritik alanlarda, bu kontroller yürütme zamanının %20-40'ını tüketebilir, geliştiricileri güvenli ama yavaş kod ile riskli unsafe.Pointer manipülasyonları arasında seçim yapmaya zorlayabilir.
Çözüm
Go derleyicisi, belirli desenler tespit edildiğinde sınır kontrollerini göz ardı eder: sınır içinde olduğu kanıtlanmış derleme zamanı değişken indeksler; for i := range slice döngüleri, burada aralık değişkeni örtük olarak uzunluktan daha küçüktür; aynı temel blok içinde açık öncek l engel uzunluk kontrolleri (örneğin, if i < len(s) { _ = s[i] }); ve indeksin dilim uzunluğundan daha küçük olduğunu garanti eden bitmasking işlemleri (örneğin, s[i & mask] burada mask = len(s)-1 güç iki uzunlukları için).
Problemin tanımı:
Yüksek verimli bir paket ayrıştırıcıyı optimize ederken, saniyede milyonlarca UDP datagramı işlediği sırada, profil oluşturma runtime.panicIndex sınır kontrolü aşırısı nedeniyle CPU döngülerinin %25'inin boşa harcandığını ortaya çıkardı. Ayrıştırıcı, her alan erişiminde güvenlik kontrollerini tetikleyen, indeksli erişim kullanarak sabit genişlikteki başlıkları çıkardı, halde protokolün sabit uzunlukları garanti etmesine rağmen.
Çözüm A: Unsafe ile manuel sınır kontrolü kaldırma
Uzunluk kontrolünü fonksiyon girişine çıkarmayı ve tüm sonraki kontrolleri atlamak için unsafe.Pointer aritmetiği kullanmayı düşündük. Bu yaklaşım tamamen dallanmayı kaldırdı ve verimliliği en üst düzeye çıkardı, ancak felaket güvenlik riskleri ortaya çıkardı: gelecekteki herhangi bir protokol değişikliği veya bozulmuş bir paket bellek bozulmasına neden olabilir ve kod, farklı hizalama gereksinimleri olan mimariler arasında taşınamaz hale geldi.
Çözüm B: Dilim yeniden dilimleme desenleri
Erişim desenlerini ilerleyici yeniden dilimleme (s = s[n:] ardından s[0]) kullanacak şekilde yeniden yazmak, derleyicinin uzunluğu kanıtlama sonrasında kontrolleri kaldırmasına izin verdi. Ancak bu, protokol alanı kaymalarının anlamını ciddi şekilde belirsiz hale getirdi, orijinal dilim referanslarını korumak için karmaşık durum yönetimi gerektirdi ve kodu protokol sürüm değişikliklerine karşı hassas hale getirdi.
Çözüm C: Sabit indeksleme ile açık uzunluk doğrulaması
Ayrıştırıcıyı açık uzunluk kontrolleri ile for len(data) >= headerSize { döngüleri kullanacak şekilde yeniden yapılandırdık ve ardından alan erişiminde sabit indeksler kullandık (örneğin, id := binary.BigEndian.Uint16(data[0:2])). Derleyicinin ispat geçisinin data[0:2]'nin uzunluk kontrolünden sonra geçerli olduğunu doğrulayabilmesini sağlayarak, unsafe olmadan otomatik sınır kontrolü kaldırma başardık. Bunun güvenlik ve sürdürülebilirlik açısından dengesini sağladık. Sonuç olarak, %30'luk bir verim artışı elde ettik ve güvenlikte hiçbir azalma yaşamadık.
Neden for i := 0; i < len(slice); i++ sıklıkla for i := range slice ile karşılaştırıldığında sınır kontrollerini göz ardı edemez?
Adaylar genellikle manuel indekslemenin aralık döngüleriyle eşdeğer olduğunu varsayıyorlar. Ancak, Go derleyicisinin ispat geçişi, range ifadesini i < len(slice)'in inşasında garanti eden kanonik bir desen olarak tanır, oysa manuel döngüler, döngü değişkeni değiştirilirse veya dilim döngü içinde yeniden dilimlenirse başarısız olabilecek karmaşık induksiyon değişkeni analizine ihtiyaç duyar, bu da sınır kontrolünün korunmasına neden olur.
Bitmasking (i & (len-1)) kullanarak dairesel bellek tamponlarına erişimde sınır kontrolü kaldırmayı nasıl garanti eder?
Genç geliştiriciler, len bir iki potansı olduğunda ve maske len-1 olduğunda, i & mask ifadesinin her zaman len'den daha az olduğunu gözden kaçırırlar. Go derleyicisinin SSA arka ucu, bu deyimi tanır ve sınır kontrolünü kaldırır, yüksek performanslı halka tamponları unsafe işlemleri olmadan mümkün kılar, koşuluyla maske doğru bir şekilde hesaplanır ve len kullanım yerinde kanıtlanabilir bir sabit olur.
Sınır kontrollerinin işlev sınırları boyunca kaldırılmasını engelleyen in-line etmenin başarısız olduğu koşullar nelerdir?
Yaygın bir yanlış anlama, çağrıcı işlevlerde açık uzunluk kontrollerinin çağrılanları koruduğudur. Diziye erişen bir işlev in-line edilmediğinde, derleyici çağrıcıda önceki sınır kontrolleri hakkında bağlamı kaybeder. Dolayısıyla, küçük erişim işlevleri //go:inline ile işaretlenmeli veya ispat geçişinin sınır bilgilerini çağrı noktalarına yaymasına izin vermek için in-line eşiğini karşılamalıdır, aksi takdirde gereksiz kontroller ikili dosyada var olmaya devam eder.