Java 27’de compact object headers: RSS değil heap küçülüyor
Java 27'de varsayılan gelen compact object headers, IntelliJ IDEA testinde RSS'i düşürmedi ama allocation hacmini yüzde 13'e kadar azalttı.
Bu haberde
Java 27 ile HotSpot, Project Lilliput kapsamındaki compact object headers özelliğini (JEP 534) varsayılan olarak açıyor. JetBrains, özelliği IntelliJ IDEA 2026.2.3 ve JBR 25.0.4 üzerinde boş ekran, Spring Petclinic ve 26,5 milyon satırlık IntelliJ monorepo’suyla ölçtü. Aynı -Xmx değerinde RSS anlamlı biçimde düşmedi, ama heap içindeki nesne boyutu ve toplam allocation hacmi azaldı.
Project Lilliput nedir, ne işe yarar?
Project Lilliput, HotSpot JVM’de Java nesnelerinin header boyutunu küçültmeyi hedefleyen bir OpenJDK projesidir. Header’daki mark word ve class pointer bilgisini daha az yere sığdırarak heap’te nesne başına harcanan belleği azaltır. Çok sayıda küçük nesneyle çalışan Java uygulamalarını işleten ekipleri ilgilendirir. Compact object headers özelliği bu projenin çıktısıdır.
Compact object headers JVM ekiplerine ne getiriyor
Java 27 ile HotSpot’ta nesne header’ı 12 byte yerine 8 byte yer kaplıyor. Bunun için artık ayrı bir ayar yapmanız gerekmeyecek. Milyonlarca küçük nesne taşıyan servislerde fark heap’te doğrudan görünüyor.
Ama JetBrains’in ölçümü beklentiyi doğru yere koymak gerektiğini gösteriyor. Kazanç process belleğinde değil, heap içinde ve garbage collection tarafında çıkıyor.
RSS grafiğiniz yerinden oynamayabilir
Aynı -Xmx değeriyle üç senaryoda RSS farkı yüzde -1,25 ile +3,22 arasında kaldı. Yön bile tutarlı değil.
Nedeni RSS’in neyi saydığında. Committed heap’teki boş alan, class metadata, JIT kodu, thread stack’leri, native buffer’lar ve paylaşılan kütüphaneler de bu sayıya giriyor. Header küçülünce heap’te yer açılıyor, ama -Xmx aynı kaldıkça JVM o alanı yine kullanabiliyor. Monitoring panelinde RSS’e bakıp “Java 27’ye geçtik, bellek düşmedi” demek bu yüzden yanlış sonuç verir.
Hangi nesne küçülüyor, hangisi aynı kalıyor
HotSpot nesne boyutunu varsayılan olarak 8 byte’ın katına yuvarlıyor. Bu yüzden 4 byte’lık kazanç çoğu zaman padding’e gidiyor. JBR 25.0.4 üzerindeki ölçümlerden birkaç örnek:
- Long 24 byte’tan 16 byte’a iniyor, Integer 16 byte’ta kalıyor.
- byte[1] ve byte[4] 24 byte’tan 16 byte’a iniyor, byte[8] 24 byte’ta kalıyor.
- Object[1000] iki düzende de 4.016 byte.
Yani kazancı nesne sayısı değil, nesnelerin şekli belirliyor. Boxed Long’lar, küçük DTO’lar ve referanslı node yapılarıyla dolu bir cache servisi tablodaki küçülen şekillere daha çok sahip. Büyük array ve buffer ağırlıklı bir iş yükünde fark küçük kalır. IntelliJ IDEA’nın kendi heap’inde modellenen tasarruf yüzde 6,3 ile 8,4 arasında çıktı.
Allocation ve GC tarafında ölçülen fark
Aynı script’li iş akışında toplam allocation Petclinic’te yüzde 8,8, monorepo’da yüzde 13,0 azaldı. Monorepo açılışı ve indexing sırasında GC olay sayısı yüzde 5,2 düştü. Compact header’lı her çalıştırma daha az GC olayı kaydetti.
Petclinic’teki yüzde 46,5’lik GC süresi düşüşü büyük görünüyor. Ama mutlak değer 24,3 ms’den 13,0 ms’ye iniş. Operasyon p95 gecikmesindeki iyileşme yüzde 2,3 ile 2,5 arasında kaldı.
Yüksek allocation hızıyla çalışan servislerde GC baskısı biraz hafifleyebilir. Gecikme hedeflerinizi bu değişikliğe bağlamayın, çünkü ölçülen hız farkı küçük.
Container’da Java 27’ye geçiş sırası
Kubernetes’te pod memory limit’ini -Xmx ile birlikte ayarlıyorsanız, yükseltme tek başına pod başına tüketimi düşürmez. Heap’te açılan yeri faturaya yansıtmak için limitin kendisini değiştirmeniz gerekiyor. Şu sırayla ilerleyebilirsiniz:
- Şu anki JDK ile heap dump alıp nesne dağılımını kaydedin. IntelliJ IDEA 2026.3 EAP’teki memory dump aracı, JOL layout modelleriyle compact header’lı tahmini boyutu da gösteriyor.
- Java 27 image’ında aynı yükle allocation ve GC metriklerini karşılaştırın.
- Heap’te gerçekten boşluk görürseniz -Xmx’i ve pod limit’ini kademeli düşürün.
JetBrains daha küçük -Xmx ile güvenilir çalışma sorusunu da test listesine koymuş. Elimizdeki metin bu bölümün sonucunu içermiyor, bu adımı kendi yük testinizle doğrulayın.
Hangi JVM’in hangi header ayarıyla çalıştığını ve process’in RSS değerini şöyle görebilirsiniz:
java -XX:+PrintFlagsFinal -version | grep -i compact
ps -o rss= -p <PID>RSS’i karşılaştırırken -Xmx’i sabit tutun ve tek ölçüme güvenmeyin. JetBrains de sırayı değiştirerek birden fazla çalıştırmanın medyanını kullandı.
