Go 1.26 Mulakat Rehberi: Green Tea GC, go fix Araci ve Stack Optimizasyonlari

Go 1.26, Subat 2026 itibariyla yayinlanan ve Go ekosisteminde onemli degisikliklere imza atan bir surumdur. Green Tea adi verilen yeni varsayilan cop toplayici (garbage collector), tamamen yeniden yazilan go fix araci ve stack tabanli dilim (slice) bellek optimizasyonlari bu surumun one cikan uc temel yeniligidir. Bu degisiklikler, Go calisma zamaninda (runtime) son yillarin en etkili iyilestirmelerini temsil etmekte ve teknik mulakatlarda giderek daha sik sorulan konular arasinda yer almaktadir.

Green Tea Cop Toplayici Nedir ve Nasil Calisir?

Beklenen yanit: Green Tea, Go 1.26 surumunde varsayilan cop toplayici olarak gorev yapan yeni mekanizmadir. Onceki uc renkli es zamanli (tri-color concurrent) toplayicinin tarama stratejisini tamamen degistirmektedir. Eski yaklasimda nesneler arasindaki isaretciler takip edilerek yigin (heap) uzerinde dagitik nesneler tek tek taraniyor ve bu durum surekli onbellek kayiplarina (cache miss) yol aciyordu. Green Tea ise bu nesne bazli tarama yerine 8 KiB boyutundaki bellek sayfalarini bitisik bloklar halinde taramaktadir.

Bu ardisik bellek erisim deseni, islemcinin onyukleme (prefetch) mekanizmasinin verimli calismisini saglamakta ve gercek dunya uygulamalarinda GC yukunu yuzde 10 ile 40 arasinda azaltmaktadir.

Modern islemcilerde (Intel Ice Lake veya AMD Zen 4 ve sonrasi), cop toplayici kucuk nesnelerin taramnasinda SIMD vektor talimatlarindan yararlanarak yaklasik yuzde 10 ek iyilestirme saglamaktadir.

Devam sorusu: Green Tea, cop toplama sirasinda islemci onbellek davranisini nasil iyilestirmektedir?

Onceki cop toplayici, yigin uzerindeki nesne isaretcilerini takip ederek calisiyor ve bu da sik sik onbellek kayiplarina neden oluyordu. Green Tea ise nesneleri sayfa sayfa, bitisik 8 KiB bloklar halinde islemektedir. Islemcinin onyukleme birimi ardisik bellek erisim desenlerini tahmin edebildiginden L1 ve L2 onbellekleri surekli sicak kalmaktadir. Bu yerellik iyilestirmesi, yuzde 10-40 arasindaki yuk azalmasinin birincil nedenidir.

// Previous approach: follow pointers across heap
func scanObject(obj *mspan) {
    for _, ptr := range obj.pointers {
        markReachable(ptr) // cache miss likely
    }
}

// Green Tea approach: scan contiguous pages
func scanPage(page *pageBlock) {
    // Sequential 8 KiB scan - CPU prefetcher friendly
    for offset := 0; offset < pageSize; offset += objSize {
        scanSlot(page.base + offset) // cache hit likely
    }
}

Green Tea, derleme asamasinda GOEXPERIMENT=nogreenteagc ortam degiskeni ile devre disi birakilabilmektedir. Ancak bu geri donus seceneginin Go 1.27 surumunde kaldirilmasi beklenmektedir.

Go 1.26 Dilim (Slice) Tahsisini Stack Uzerinde Nasil Optimize Etmektedir?

Beklenen yanit: Go 1.26, dilim destek belleklerinin stack uzerinde tahsis edilmesini append tabanli birikim islemerine kadar genisletmektedir. Onceki surumlerde ilk append cagrisi yigin uzerinde 1 elemanlik bir dilim olusturuyor, ardindan 2, 4 ve 8 olarak standart ikiye katlama stratejisi izleniyordu. Go 1.26 ise dongu baslamadan once kucuk bir stack tabanli destek bellek tahsis etmekte ve ilk birkac append isleminin sifir yigin tahsisi ile gerceklesmesini saglamaktadir.

func collectTasks(items []Item) []Task {
    var tasks []Task
    // Before Go 1.26: first append allocates on heap (size 1, 2, 4...)
    // Go 1.26: compiler inserts a stack-backed buffer
    for _, item := range items {
        if item.IsReady() {
            tasks = append(tasks, item.ToTask())
            // First ~4 appends use stack buffer, zero heap allocations
        }
    }
    return tasks
    // If slice escapes, runtime.move2heap() copies once at return
}

Devam sorusu: Dilim, fonksiyon kapsaminin disina ciktiginda (escape) ne olmaktadir?

Dilimin yigina cikmasi gereken durumlarda bile (fonksiyon dilimi dondurdugunde), Go 1.26 birikim islemi sirasinda stack tamponunu kullanmaya devam etmektedir. Derleyici, donus noktasinda verileri tek seferde yigina kopyalayan bir runtime.move2heap() cagrisi eklemektedir. Baslangicta 3 veya daha fazla yigin tahsisi (boyut 1, 2, 4...) yerine, sonucta yalnizca 1 adet yigin tahsisi gerceklesmektedir.

go fix Aracinda Neler Degisti?

Beklenen yanit: go fix araci, Go modernize edicileri (modernizers) icin bir platform olarak sifirdan yeniden yazilmistir. Go kod tabanlarini en guncel deyimler ve cekirdek kutuphane API'leri ile guncellemek icin tek tusla calistirilan bir mekanizma sunmaktadir. Yeni go fix, go vet ile ayni analiz cercevesi uzerine insa edilmistir; dolayisiyla teshis saglayan ayni cozumleyiciler artik duzeltme de onerebilmekte ve uygulayabilmektedir.

Yeni go fix aracinin temel ozellikleri sunlardir:

• Modern Go deyimleri ve API'leri icin duizinelerce duzeltici
• //go:fix inline yonergeleri ile etkinlestirilen kaynak duzeyi icsellestiricisi (inliner)
• Sifir davranis degisikligi garantisi (uretim kodu icin guvenli)
• Eski aractan kalma kullanilmayan duzeltciler kaldirilmistir

# Apply all modernizers to the current module
go fix ./...

# The tool automatically updates patterns like:
# - Old-style error wrapping to fmt.Errorf with %w
# - Deprecated API calls to their replacements
# - Legacy patterns to modern Go idioms

Devam sorusu: //go:fix inline nasil calismaktadir?

//go:fix inline yonergesi, bir fonksiyon veya metodu go fix tarafindan kaynak duzeyi icsellestirilmesine aday olarak isaretlemektedir. go fix calistirildiginda, isaretli fonksiyonun cagri noktalarini fonksiyon govdesiyle degistirmektedir. Bu islem, derleyici icsellestirilmesinden farklidir: uretilen makine kodu yerine kaynak kodu donusturmektedir.

Go 1.26 cgo Performans Iyilestirmesi

Beklenen yanit: Go 1.26, her cgo cagrisinin temel yukunu yaklasik yuzde 30 oraninda azaltmistir. Calisma zamani bunu, goroutine'lerin cgo cagrilari sirasinda gecis yaptigi bir ara durum olan _Psyscall islemci durumunu ortadan kaldirarak basarmistir. Bu gecis durumunun kaldirilmasi, her cgo cagrisindaki durum gecis sayisini azaltarak dogrudan gecikmeyi dusurmusutur.

Go 1.26 Dil Degisiklikleri

Beklenen yanit: Go 1.26 iki dil degisikligi sunmaktadir:

1. Genisletilmis new() fonksiyonu: Yerlesik new fonksiyonu artik islecin (operand) baslangic degerini belirten bir ifade kabul etmektedir. Onceki surumlerde new(T) her zaman sifir degerli bir *T donduruyordu.

type Config struct {
    Timeout  *int
    MaxRetry *int
}

// Before Go 1.26: helper function needed
func intPtr(v int) *int { return &v }
func makeConfig() Config {
    return Config{
        Timeout:  intPtr(30),
        MaxRetry: intPtr(3),
    }
}

// Go 1.26: direct initialization
func makeConfig() Config {
    return Config{
        Timeout:  new(30),  // *int pointing to 30
        MaxRetry: new(3),   // *int pointing to 3
    }
}

2. Kendine referansli jenerik tipler: Jenerik tipler artik tip parametresi kisitlamalarinda kendilerine referans verebilmektedir. Bu ozellik, F-sinirli polimorfizm (F-bounded polymorphism) gibi ileri duzey tip soyutlama kaliplarini mumkun kilmaktadir.

type Adder[A Adder[A]] interface {
    Add(A) A
}

type Vector2D struct{ X, Y float64 }

func (v Vector2D) Add(other Vector2D) Vector2D {
    return Vector2D{v.X + other.X, v.Y + other.Y}
}

// The constraint ensures the return type matches the receiver type
func Sum[A Adder[A]](items []A) A {
    var result A
    for _, item := range items {
        result = result.Add(item)
    }
    return result
}

Goroutine Sizinti Tespiti Go 1.26 ile Nasil Calismaktadir?

Beklenen yanit: Go 1.26, runtime/pprof paketinde deneysel bir goroutineleak profil tipi sunmaktadir. Sizinti yapan goroutine, bir es zamanlilik temel ogesi (channel, sync.Mutex, sync.Cond) uzerinde bloke olmus ve artik hicbir sekilde blokesinin kalkamayacagi bir goroutine'dir. Calisma zamani bu sizintilari cop toplayiciyi kullanarak tespit etmektedir: G goroutine'i P temel ogesi uzerinde bloke ise ve P herhangi bir calistirilabilir goroutine'den erisilemez durumdaysa, G'nin uyanmasi imkansizdir.

func processWorkItems(ws []workItem) ([]workResult, error) {
    ch := make(chan result)
    for _, w := range ws {
        go func() {
            res, err := processWorkItem(w)
            ch <- result{res, err} // goroutine blocks here if early return
        }()
    }
    for range len(ws) {
        r := <-ch
        if r.err != nil {
            return nil, r.err // remaining goroutines leak
        }
    }
    return results, nil
}
// Enable detection: GOEXPERIMENT=goroutineleakprofile
// Endpoint: /debug/pprof/goroutineleak

Go 1.26 Guvenlik Iyilestirmeleri

Beklenen yanit: Iki onemli guvenlik iyilestirmesi bulunmaktadir:

Yigin temel adres rastgelestirmesi (64-bit platformlar): Calisma zamani artik baslangitta yigin temel adresini rastgelestirmektedir. Bu durum, saldirganlariin cgo araciligiyla guvenlik aciklarini kullanirken bellek adreslerini tahmin etmesini zorlastirmaktadir. Basit bir ifadeyle, Go yigin bellegi icin ASLR benzeri bir savunma mekanizmasi saglanmaktadir.

Kuantum sonrasi kriptografi varsayilan olarak etkin: TLS baglantilari artik varsayilan olarak hibrit anahtar degisimi kullanmaktadir (SecP256r1MLKEM768, SecP384r1MLKEM1024). Bu yaklasim, klasik eliptik egri kriptografisini kuantum direnci icin ML-KEM (eski adiyla CRYSTALS-Kyber) ile birlestirmektedir.

Standart Kutuphane Performans Kazanimlari

Beklenen yanit:

| Fonksiyon | Iyilestirme | Detay | |----------|------------|--------| | fmt.Errorf (format fiili olmadan) | ~%92 daha hizli | Biclmlendirilmemis cagrilar artik errors.New performansina ulasmaktadir | | io.ReadAll | ~2 kat hizli, %50 daha az bellek | Dogrusal yerine ustel tampon buyumesi kullanmaktadir | | crypto/mlkem | ~%18 daha hizli | Kapsulleme ve kapsul acma islemleri optimize edilmistir | | image/jpeg | Daha hizli, daha dogru | Yeni kodlayici ve kod cozucu uygulamasi |

Bunlara ek olarak, bytes.Buffer yeni bir Peek() metodu kazanmis, errors paketine jenerik bir AsType() fonksiyonu eklenmis ve reflect paketine Go'nun range-over-func deseni ile uyumlu yineleyici metotlari eklenmistir.

errors.AsType Fonksiyonu Hata Yonetimini Nasil Basitlestirmektedir?

Beklenen yanit: errors.AsType[T](), errors.As() fonksiyonunun jenerik bir alternatifidir. As cagrilmadan once hedef degisken tanimlanma zorunlulugunu ortadan kaldirarak gereksiz sablonlari (boilerplate) azaltmaktadir.

// Before Go 1.26: two-step process
var pathErr *os.PathError
if errors.As(err, &pathErr) {
    log.Printf("path error on %s: %v", pathErr.Path, pathErr.Err)
}

// Go 1.26: single expression
if pathErr, ok := errors.AsType[*os.PathError](err); ok {
    log.Printf("path error on %s: %v", pathErr.Path, pathErr.Err)
}

Sonuc

Go 1.26 surumunde yer alan degisiklikler, dilin calisma zamani performansindan gelistirici araclarinaa ve dil tasarimina kadar genis bir yelpazeyi kapsamaktadir. Mulakat hazirliginda odaklanilmasi gereken temel noktalar su sekilde ozetlenebilir:

• Green Tea GC, isaretci takibi yerine 8 KiB bellek sayfalarini tarayarak kod degisikligi gerektirmeden GC yukunu yuzde 10-40 oraninda azaltmaktadir
• Stack tabanli dilim destek bellekleri, append donguleri sirasinda 3 veya daha fazla baslangic yigin tahsisini ortadan kaldirmakta ve yalnizca kacis noktasinda tek bir yigin kopyasi gerceklestirmektedir
• Yenilenmis go fix araci, go vet analiz cercevesi uzerine insa edilmis duizinelerce modernize ediciyi sifir davranis degisikligi garantisiyle uygulamaktadir
• new() fonksiyonu artik ifade kabul ederek isaretci yardimci fonksiyonlarina olan ihtiyaci ortadan kaldirmaktadir
• Kendine referansli jenerik tip kisitlamalari, F-sinirli polimorfizm kaliplarini mumkun kilmaktadir
• Goroutine sizinti tespiti (deneysel), kalici olarak bloke olmus goroutine'leri GC erisilebilirlik analizi ile bulmaktadir
• fmt.Errorf format fiili olmadan yuzde 92 daha hizli calisirken, io.ReadAll yuzde 50 daha az bellek tuketmektedir
• Kuantum sonrasi hibrit anahtar degisimi, TLS baglantillarinda varsayilan olarak etkinlestirilmistir

Go mulakat hazirligini derinlestirmek icin Go mulakat sorulari sayfasi incelenebilir. Go es zamanlilik rehberi ise goroutine sizinti tespiti konusunu tamamlayan temel es zamanlilik kaliplarini kapsamaktadir.