Açık konuşayım: Windows tarafında bellek yönetimi işi yıllardır biraz “tamam ya, böyle de idare ediyor” kafasında gidiyordu. NT Heap vardı, çoğu ekip önü kullanıyordu, kimse de fazla kurcalamıyordu. Şimdi Visual Studio 2026 version 18.6 ile — ki bu tartışılır — birlikte tablo biraz kayıyor — yeni C++ projeleri varsayılan olarak Segment Heap ile geliyor. Küçük bir detay gıbı duruyor, ama üretimde C++ koşturan ekipler için işin rengi değişebiliyor.
Geçen hafta bir oyun stüdyosu müşterimizde — adını veremiyorum tabii — eski bir render motorunu VS 2026’ya migrate ederken konu tam buradan açıldı. Ekip lideri “Segment Heap’i açsak ne ölür?” diye sordu. Hmm, kısa cevap veremedim. Mesele tek satırlık değil, performans tarafı var, uyumluluk tarafı var (bir de bazı eski alışkanlıklar var), yanı anlatınca uzuyor da uzuyor. Şimdi o konuşmayı biraz toparlayıp size aktarayım.
Segment Heap Aslında — hayır dür, daha doğrusu Ne? Kısa Bir Hatırlatma
Segment Heap yeni bir şey değil, hani öyle dün çıkmış bir özellik de değil. Windows 10’da, özellikle UWP uygulamaları için ortaya çıktı; sonra Windows 11 tarafında bazı sistem binary’lerinde de kullanıldı, ama C++ geliştiricileri için olay hep “opt-in” kaldı (yanı manifest’e elle yazman gerekiyordu), o yüzden çoğu kişi açık konuşayım hiç uğraşmadı.
İşin teknik tarafına girince tablo netleşiyor. NT Heap klasik heap implementasyonu, Windows NT günlerinden beri geliyor; Segment Heap işe daha modern bir tasarım. Ne sağlıyor? Birkaç noktayı ayırayım:
- Daha güçlü güvenlik: Use-after-free, heap overflow gıbı klasik bellek açıklarına karşı daha dirençli
- Yüksek allocation throughput: Hele bir de çok çekirdekli sistemlerde fark ediliyor
- Daha az fragmentasyon: Uzun süre çalışan servisler için kritik — ciddi fark yaratıyor
- Tahmin edilebilir performans: Yük altında “anı yavaşlamalar” azalıyor
- Çekirdek başına ölçeklenme: Modern 32+ çekirdekli sunucularda daha verimli
Ama dür bir saniye — bu iş her yerde otomatik kazanç demek değil. Küçük ve kısa ömürlü process’lerde fark etmeyebilir, hatta bazı edge case’lerde NT Heap biraz daha hızlı bile çıkabiliyor; yanı “her durumda Segment Heap açayım, mesele bitsin” kafası pek tutmuyor (şaşırtıcı ama gerçek). Test etmeden karar vermek burada riskli (en azından benim deneyimim böyle) (bu beni çok şaşırttı)
Evet.
Bi saniye — Lafı gevelemeden söyleyeyim: doğru yaklaşım test etmek, ölçmek ve sonra karar vermek. Çünkü aynı ayar bir serviste baya iş görüyor, başka bir workload’da işe idare eder seviyesinde kalabiliyor; işin aslı biraz da senaryoya bağlı.
Yeni Projelerde Otomatik, Eskilerde Manuel
VS 2026 18.6 ile birlikte yeni açtığınız C++ projeler zaten Segment Heap ile geliyor. Güzel taraf bu. Ama eski projelerde iş biraz değişiyor; sihirli bir geçiş yok, yanı mevcut olanı elle açmanız gerekiyor (yanlış duymadınız). Evet, biraz uğraştırıyor.
MSBuild Tarafı (Klasik.vcxproj)
MSBuild tabanlı projelerde iş aslında düz. Yolu da net: Project → Properties → Manifest Tool → Input and Output → Enable Segment Heap. Kısa yol bu kadar.
Bu ayar proje bazında çalışıyor. Yanı 30 projeli bir solution varsa, hepsini tek tek gezmen gerekebilir; ya da topluca halledersin, o ayrı. Ben burada genelde şöyle gidiyorum: önce kritik olmayan bir alt projede açıyorum, bir hafta production’da bakıyorum, sonra yavaş yavaş yayıyorum. Direkt core’un göbeğine basmak var ya, hani biraz fazla iddialı oluyor.
CMake Tarafı: Biraz Daha İlginç
Hani, CMake kullanıyorsanız Microsoft burada SegmentHeap.cmake diye bir helper script bırakmış. Bunu CMakePresets.json üzerinden devreye alıyorsunuz. Bak şimdi, örnek preset şu şekilde duruyor:
{
"name": "foo",
"displayName": "Foo",
"inherits": "",
"environment": {
"VS_SEGMENT_HEAP_ALLOWLIST": "target1;target2;",
"VS_SEGMENT_HEAP_EXCLUDE": "target3;"
},
"cacheVariables": {
"CMAKE_PROJECT_TOP_LEVEL_INCLUDES": "$env{VSINSTALLDIR}Common7/IDE/CommonExtensions/Microsoft/CMake/cmake/Microsoft/SegmentHeap.cmake"
}
}Burada hoşuma giden şey şu: VS_SEGMENT_HEAP_ALLOWLIST ile sadece seçtiğin target’lara Segment Heap uygulayabiliyorsun, VS_SEGMENT_HEAP_EXCLUDE ile de bazılarını dışarıda bırakabiliyorsun. Yanı 50 target’lı bir CMake projesinde kalkıp her yere aynı anda dokunmak zorunda değilsin; mesela sadece yeni geliştirdiğiniz X servisinde denersin, ölür mu olmaz mı bakarsın. Granül kontrol dediğimiz şey tam bu işte (ki bu çoğu kişinin gözünden kaçıyor). Kurumsal tarafta baya iş görüyor, çünkü bazı solution’larda 2002’den kalma legacy modüller oluyor ve açık konuşayım, onlara el sürmek istemiyorsun.
Tuhaf ama, Neyse uzatmayalım.
Eh, Burada, peki neden? Çünkü yeni projede otomatik gelmesi güzel ama eskiyi yönetmek hâlâ bizim işimiz.
Türkiye’deki Şirketler İçin Bu Ne Anlama Geliyor?
Şimdi işin yerel tarafına gelelim. Logosoft’ta son üç yıldır gördüğüm tablo biraz — itiraz edebilirsiniz tabi — net, biraz da kafa karıştırıcı; Türkiye’de C++ kullanımı iki uçta toplanıyor: bir yanda finans ve bankacılıktaki HFT işleri ile risk hesaplama motorları, öte yanda savunma sanayii ve oyun şirketleri. İki dünya da C++ seviyor ama dertleri aynı değil.
Bankacılık tarafında, özellikle geçen yıl bir kamu bankasında yaptığımız modernizasyon işinde, uzun süre çalışan trading process’leri vardı. Bunlar günlerce açık kalıyor, milyonlarca allocation yapıyor, sonra bir bakıyorsunuz heap şişmiş; işte asıl mesele orada başlıyor. Heap fragmentasyonu gerçek bir sorun, yanı teoride konuşması kolay ama production’da can sıkıyor (ben de ilk duyduğumda şaşırmıştım). Segment Heap’in vadettiği “daha az fragmentasyon” kısmı, gece restart ihtiyacını baya azaltabilir. Test ettik mi? Tam olarak henüz değil. Ama ilk sinyaller fena değil.
İşte tam da bu noktada devreye giriyor.
Oyun ve simülasyon tarafında işe durum biraz başka. Frame-based loop’larda allocation pattern’leri bambaşka akıyor, o yüzden Segment Heap kazancı sınırlı kalabilir; çünkü çoğu motor zaten kendi memory pool’unu kullanıyor. Yanı yeni heap gelsin diye herkes koşa koşa geçmeyebilir. Hatta bazı ekipler için bu değişiklik, pratikte sadece kenarda duran bir iyileştirme gıbı kalabilir.
Bence doğru yönde atılmış bir adım, ama hâlâ eksik kalan bir şey var: Microsoft’un “şu senaryoda %X kazanç” diye net konuşan bir benchmark suite’i yok. Herkes kendi yükünü ölçecek. Bu da Türkiye gıbı “önce kanıtla sonra al” diyen pazarlarda adoption hızını biraz yavaşlatacak.
Segment Heap Açık Mı? Nasıl Kontrol Edersiniz?
Bu konu küçük gıbı duruyor, ama değil. Geçen ay bir müşteride tam böyle bir şey yaşadık; manifest tool tarafında ayar açık görünüyordu, sonra araya giren bir intermediate build adımı manifest’i ezmiş, final binary’de Segment Heap kapalı kalmıştı. Buyurun, insan bazen bakıyor ve “nasıl yanı?” diyor. Bu konuyla ilgili Azure SDK for Rust GA Öldü: Sahadan İlk İzlenimler yazımıza da göz atmanızı tavsiye ederim.
Bir dakika — bununla bitmedi. SAP Sapphire 2026: Azure Tarafında Yeni Dönem Başlıyor yazımızda bu konuya da değinmiştik.
Doğrulamak için iki yol var. İkisi de iş görüyor, ama biri biraz daha pratik geliyor bana.
Yöntem 1: Executable’ı Visual Studio’da Açın
Eh, Evet,.exe dosyasını direkt Visual Studio’ya sürükleyip bırakabiliyorsunuz. Sonra RT_MANIFEST resource’una bakıp şu satırı arıyorsunuz:
<heapType>SegmentHeap</heapType>Eğer bu satır varsa, tamamdır. Segment Heap aktif demektir. Yoksa da hikâye net: manifest ya gömülmemiştir ya da sonradan başka bir adım tarafından üstü çizilmiştir. Kısacası, işin aslı bu kadar basit.
Yöntem 2: Developer Command Prompt + mt.exe
Şöyle söyleyeyim, Bu biraz daha “bak şimdi ne çıkacak” yöntemi. Developer Command Prompt’u açıp manifest’i dışarı alıyorsunuz:
mt.exe -inputresource:YourApp.exe;#1 -out:extracted.manifestSonra extracted.manifest dosyasını herhangi bir editörle açıp yine aynı heapType satırına bakıyorsunuz. Hani bazen GUI ile uğraşmak yerine komutla ilerlemek daha temiz ölür ya, işte burada da öyle (şaşırtıcı ama gerçek). CI/CD pipeline’ınıza bunu bir validation step olarak — ki bu tartışılır — ekleyebilirsiniz — ben olsam eklerim. Çünkü “açık sanıyorduk ama kapalıymış” sürprizi gerçekten can sıkıyor.
Burada, peki neden? Çünkü bu tıp ayarlar build zincirinde çok kolay kayboluyor. Bir yerde doğru set ediyorsunuz, başka bir yerde farklı bir paketleme adımı geliyor ve sonuçta elinizde bambaşka bir binary kalıyor.
Karşılaştırma: NT Heap vs Segment Heap
Tabloyla bakınca daha net oluyor, çünkü lafı uzatmadan farkı görüyorsunuz. Ama bir dakika, işin içinde küçük bir sürpriz de var; her ortamda aynı sonucu beklemek biraz fazla iyimser ölür (en azından benim deneyimim böyle)
| Özellik | NT Heap (Klasik) | Segment Heap |
|---|---|---|
| Yaş | Windows NT’den beri | Windows 10+ |
| Çok çekirdekli ölçeklenme | Orta | İyi |
| Fragmentasyon | Yüksek | Düşük |
| Güvenlik hardening | Sınırlı | Modern mitigations |
| Küçük allocation perf | İyi | İyi (genelde daha iyi) |
| Kısa ömürlü process | Avantajlı olabilir | Fark sınırlı |
| Uzun ömürlü servis | Fragmentasyon riski | Belirgin avantaj |
Evet, kağıt üstünde Segment Heap baya iş görüyor. En çok da uzun süre ayakta kalan servislerde, bellek parçalanması işi can sıkmaya başlayınca farkını hissettiriyor. Kısa yaşayan process tarafında olay o kadar da dramatik değil, yanı her yerde sihir beklemeyin.
Bunu gerçek hayatta da gördüm. Bir telco projesinde Segment Heap’e geçince (söylemesi ayıp) bellek kullanımı %12 düşmüş, açık konuşayım ben ilk duyduğumda “abartıyorlar mı acaba” dedim; sonra ölçümleri görünce tamam, bu sefer olmuş dedim. Başka bir projede işe neredeyse hiçbir değişiklik çıkmadı.
Peki neden? Çünkü heap davranışı uygulamanın allocation pattern’ine çok bağlı, hani sürekli küçük nesne üreten başka, uzun süre yaşayan blokları döndüren başka; aynı heap motoru ikisine de birebir aynı tepkiyi vermiyor.
Aynen öyle. Kubernetes v1.36 CCM: Route Sync Metriği Sahaya İndi yazımızda bu konuya da değinmiştik.
Pratik Onboarding Rehberi: İlk Adımlar
Şimdi işi somuta indirelim. Segment Heap’i kendi projende denemek istiyorsan, bence en sağlıklı yol şu sırayı bozmayarak gitmek, çünkü ilk günden her şeyi bir anda çevirmeye kalkınca neyin işe yaradığını ayırt etmek zorlaşıyor.
- Önce baseline ölç: Mevcut heap kullanımını, allocation pattern’ını, peak memory değerini kayıt altına al.
VMMap,PerfViewveWPAburada baya iş görüyor; hatta bazen insanın gözünden kaçan küçük şişkinlikleri bile yakalıyor. - Non-critical bir target seçin: Production’da can yakma ihtimali en düşük olan alt modülle başla. CLI tool ölür, test binary ölür, yardımcı servis ölür; yanı ilk denemeyi ana iş akışının göbeğinde yapma, sonra başın ağrır. — ciddi fark yaratıyor
- Manifest’i değiştirin: MSBuild tarafında GUI’den ilerle, CMake kullanıyorsan allowlist ile devam et. Kulağa basit geliyor ama şey, burada küçük bir işaretleme hatası neredeyse tüm sonucu ters yüz edebiliyor.
- Doğrulayın: Yukarıdaki mt.exe yöntemiyle gerçekten açılıp açılmadığını teyit et. Emin değilim ama sanırım çoğu kişinin atladığı nokta da burası; “ekledim” demekle “çalıştı” aynı şey değil.
- Aynı testleri tekrarlayın: Throughput, latency ve memory footprint testlerini yeniden koş. A/B karşılaştırmasını düzgün yapmadan karar verme; yoksa elinde sadece hissiyat kalıyor.
- Stres testi yapın: 48-72 saat boyunca sürekli yük altında çalıştır. Fragmentasyon farkı genelde burada kendini belli ediyor (ilk 10 dakikada değil), yanı sabırsız davranınca resmin yarısını kaçırmış oluyorsun.
- Kademeli yayın: Sonuçlar iyi gidiyorsa diğer target’lara geç. Olumsuzsa geri al, NT Heap ile devam et; açık konuşayım, bazen geri dönüş yapmak ileri gitmekten daha akıllıca oluyor.
Neyse, burada asıl mesele şu: önce küçükten başla, sonra büyüt. Evet, bu kadar basit görünüyor ama pratikte işin rengi biraz değişiyor; çünkü ölçmeden yapılan her değişiklik biraz tahmin oyunu gıbı kalıyor.
Peki neden? Çünkü heap tarafında farkı hissettiğin an ile farkı kanıtladığın an aynı ölmüyor. Bir yerde rahatlama görürsün, başka yerde latency ufak ufak oynar; tam da o yüzden kontrollü gitmek daha mantıklı.
Tam da öyle.
Enterprise vs Startup: Strateji Farkı
Bence, Küçük bir startup’taysanız, yeni proje başlatırken varsayılan ayarda bırakın. İşiniz kolaylaşır. Zaten VS 2026 yeni projelerde bunu otomatik açıyor; ekstra bir şey yapmanız gerekmiyor, sadece manifest’in production build’de gerçekten gömülü olduğunu CI tarafında kontrol edin, yoksa sonra “ama bende çalışıyordu” muhabbeti başlıyor.
Size bir şey söyleyeyim, Büyük bir kurumsal yapıdaysanız iş değişiyor (şaşırtıcı ama gerçek). Onlarca solution, yüzlerce target, 10+ yıllık legacy kod tabanları var; yanı tek bir ayar bile bazen domino etkisi yapabiliyor, bu yüzden önce bir “Segment Heap policy” yazın: hangı modüller eligible, hangileri değil, kim sahibi, rollback planı ne, hepsini netleştirin. Sonra mimarı komiteye götürün. Ardından pilot yapın. Sonra wave-based rollout ile ilerleyin. Acele etmeyin — bir HFT sisteminde latency dağılımı biraz oynarsa, risk yöneticileri kapınızı çalar, hem de hiç nazik olmadan.
Ve işler burada ilginçleşiyor.
Daha açık söyleyeyim, bi saniye — Maliyet tarafına gelince, Segment Heap için doğrudan bir lisans ücreti yok; Windows’un içinde geliyor. Ama işin görünmeyen kısmı var: test, ölçüm, validation eforu. Tahminimce ortalama bir Türk yazılım ekibi için orta büyüklükteki bir C++ servisini Segment Heap’e geçirmek 2-3 mühendis-haftası sürer. Karşılığında ne alırsınız? Daha az gece restart’ı, daha az “neden production’da memory yiyor” toplantısı. Biraz daha öngörülebilir performans. Bence fena değil.
Ekosistemdeki Diğer Hareketler
Bu konu tek başına durmuyor aslında. Microsoft tarafı boş oturmuyor, MSVC cephesinde epey bir modernleşme var — MSVC Build Tools v14.52 Preview: Mayıs 2026 Notları yazımda anlattığım derleyici değişiklikleriyle Segment Heap’i yan yana koyunca, C++ runtime tarafında işlerin sessiz sedasız. Kökten değiştiği baya belli oluyor. Paket yönetiminde de aynı hava var; vcpkg Nişan 2026 Güncellemesi: Paralel Build Kilitleri Geldi ile ekosistem resmen “daha hızlı, daha az sürtünmeli” tarafa kayıyor,. Sadece performans değil, kullanım şekli de biraz el değiştiriyor.
Bunu biraz açayım.
Güvenlik tarafını da atlayamayız. Atlanmaz zaten. Segment Heap’in verdiği memory safety iyileştirmeleri, statik analiz araçlarıyla birlikte kullanıldığında daha anlamlı hâle geliyor; tek başına bakınca fena değil. Asıl olay zincirin tamamında çıkıyor, hani bir parçayı çekince öbürü de yerinden oynuyor ya, tam o hesap. Bu yüzden CodeQL 2.25.4 Çıktı: Swift, C# ve Java Tarafında Neler Var? güncellemelerine de göz atmak gerekiyor; özellikle kod kalitesi ve güvenlik taraması birlikte düşünülünce tablo daha netleşiyor.
Yaşadığım Bir Hata ve Çözümü
Geçen ay test ortamında Segment Heap’i açtığımızda tuhaf bir şey öldü. Eski bir networking kütüphanesi, üstelik custom allocator kullanan o modül, bir anda crash etmeye başladı; stack trace’te HeapValidate falan görünüyordu, ben de ilk anda “tamam, Segment Heap yine saçmaladı” diye düşündüm. Yanılmışım.
Araya gireyim: İşin aslı şuydu: O kütüphane heap pointer’ları hakkında bazı varsayımlar yapıyordu, yanı adres aralıkları, alignment meselesi, hatta dolaylı olarak layout’un hep aynı kalacağı fikri — bence çok yerinde bir karar —. Segment Heap’in düzeni farklı olunca bu varsayımlar patladı. Çözüm de aslında çok dramatik değildi; o modülü VS_SEGMENT_HEAP_EXCLUDE listesine ekleyip izole ettik, geri kalan her şeyi Segment Heap’te bırakıp yolumuza devam ettik.
İlginç olan şu ki, Ders net. Eğer elinizdeki kütüphaneler heap internal’larına yaslanıyorsa, Segment Heap onları kırabilir. Ama açık konuşayım, bu bana göre kötü bir şey değil; tam tersine, o kütüphaneler zaten yanlış varsayımlarla yazılmış demek. Yine de production’da böyle bir sürprizle karşılaşmak istemezsiniz. Test ortamında görün bunu. Evet.
Sıkça Sorulan Sorular
Segment Heap’i açınca performans çoğu zaman artıyor mu?
Hayır, her zaman değil. Yanı bu tamamen workload’a bağlı bir şey. Uzun ömürlü servislerde ve çok çekirdekli ortamlarda genelde güzel kazanımlar görüyorsunuz, ama kısa ömürlü, single-threaded uygulamalarda fark ya çok az kalıyor ya da negatife dönüyor. Bence en sağlıklısı kendi senaryonuzla A/B test yapmak — başka türlü gerçekten bilemezsiniz.
Mevcut bir projeyi Segment Heap’e taşımak riskli mi?
Açıkçası düşük-orta arası bir risk var. Eğer kodunuz ya da bağımlı kütüphaneler heap internal’larına dayanan bazı varsayımlarda bulunuyorsa sorun çıkabiliyor. Ama standart C++ kodu yazan çoğu insan için sorunsuz çalışıyor. Tecrübeme göre en güvenli yol, önce pilot bir modülle başlayıp sonra yavaş yavaş yaygınlaştırmak.
CMake projelerinde sadece belirli target’lara Segment Heap uygulayabilir mıyım?
Evet, mümkün. VS_SEGMENT_HEAP_ALLOWLIST. VS_SEGMENT_HEAP_EXCLUDE environment variable’ları ile granül bir kontrol sağlayabiliyorsunuz. Bu özellikle çok target’lı büyük projelerde tedrici geçiş yaparken gerçekten hayat kurtarıyor.
Segment Heap aktif mi diye nasıl anlayabilirim?
İki yöntem var. Ya executable’ı Visual Studio’da açıp RT_MANIFEST resource’unda <heapType>SegmentHeap</heapType> satırını arıyorsunuz, ya da mt.exe -inputresource:YourApp.exe;#1 komutuyla manifest’i dışarı çıkarıp inceliyorsunuz. Bence bu kontrolü CI pipeline’ınıza da ekleyin — hani sonradan “aktif değilmiş” diye sürprizle karşılaşmayın.
Visual Studio 2022 ile de Segment Heap kullanabilir mıyım?
Manuel manifest düzenlemesiyle evet, kullanabiliyorsunuz — zaten Segment Heap özelliği işletim sisteminde mevcut. Ama VS 2026 18.6’daki entegre destek, yanı UI ayarları, CMake helper script, allowlist mekanizması gıbı şeyler işi çok daha kolaylaştırıyor. Eğer yeni VS’ye geçme imkânınız varsa açıkçası geçin, değer.
Kaynaklar ve İleri Okuma
Küçük bir detay: Microsoft C++ Team Blog: Segment Heap Support for C++ Projects in Visual Studio
Microsoft Docs: Application Manifests Referansı
CMake Presets in Visual Studio — Resmî Dokümantasyon
Windows Heap Functions Genel Bakış
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
