Project Valhalla, Leyden AOT ve Loom Aynı Sürümde Buluştu: JDK 28’de Resmileşen JEP 401, JEP 544 ve JEP 543 Mimarisi

OpenJDK 28 Yol Haritasında Tarihi Kesişim: Üç Büyük Mühendislik Girişiminin Buluşması

Java ekosisteminin evriminde bazı sürümler yalnızca artımlı kütüphane iyileştirmeleri sunarken, bazı sürümler sanal makinenin (JVM) donanımla kurduğu temel sözleşmeyi yeniden yazar. OpenJDK JDK 28 resmi proje sayfasında peş peşe resmileşen yeni JEP (JDK Enhancement Proposal) hedefleriyle birlikte, JDK 28 sürüm takviminde hedeflenen toplam JEP sayısı 10'a ulaştı. Ekim ayında listeye eklenen son üç JEP dalgası ve hemen öncesinde kesinleşen çekirdek spesifikasyonlar incelendiğinde, OpenJDK şemsiyesi altında yıllardır geliştirilen üç dev mimari projenin aynı sürümde somutlaştığı görülür:

1. Project Valhalla (JEP 401: Value Objects & JEP 539: Strict Field Initialization in the JVM): Nesne kimliğini (object identity) isteğe bağlı hale getirerek Java nesnelerini C/Rust struct yapıları gibi başlıksız ve düzleştirilmiş (flattened) bellek bloklarına dönüştüren bellek devrimi.
2. Project Leyden (JEP 544: Ahead-of-Time Code Compilation): JIT derleyicisinin ürettiği yerel makine kodunu (native code) doğrudan AOT önbelleğine yazarak bulut-yerel konteynerlerde ısınma (warmup) süresini ortadan kaldıran derleme katmanı.
3. Project Loom (JEP 543: Structured Concurrency): Sanal iş parçacıklarını (Virtual Threads) deterministik bir görev ağacı altında birleştiren eşzamanlılık modelinin önizleme aşamasından çıkarak kalıcı (Final) standart haline gelmesi.

Bu üç ana sütuna ek olarak kriptografik anahtar yönetimini standartlaştıran JEP 542: PEM Encodings of Cryptographic Objects (Final), düşük gecikmeli çöp toplayıcı mimarisinde JEP 535: Shenandoah GC: Generational Mode by Default ve Ekim ayında resmileşen JEP 545 / JEP 546 (ZGC Startup & Adaptive Heap) ile JEP 540: Simple JSON API üçlüsü, JDK 28'i modern bulut altyapıları için en kapsamlı çalışma zamanı güncellemesi konumuna taşır.

1. Project Valhalla Çekirdeği: JEP 401 (Value Objects) ve JEP 539 ile Düzleştirilmiş Bellek Mimarisi

Java'nın 1995 yılından bu yana koruduğu "her nesnenin benzersiz bir kimliği (identity) vardır" varsayımı, modern CPU mimarilerinde ciddi bir donanım darboğazı yaratır. Standart bir 64-bit HotSpot JVM üzerinde oluşturulan her Object örneği, gerçek veri alanlarından önce 12 ila 16 baytlık bir nesne başlığı (Object Header — Mark Word ve Klass Word) taşır. Daha da önemlisi, Point[] gibi bir nesne dizisi bellekte bitişik veriler olarak değil, yığının (heap) farklı bölgelerine dağılmış nesnelere işaret eden 64-bitlik referans (pointer) dizisi olarak saklanır. CPU bir diziyi tararken her adımda referans takibi (pointer chasing) yapmak zorunda kalır ve 64 baytlık L1/L2 önbellek hatları (cache lines) sürekli ıskalanır (cache miss).

JEP 401: Value Objects (Preview), nesne kimliğine, senkronizasyon kilidine (synchronized) veya değişebilir (mutable) alanlara ihtiyaç duymayan veri yapıları için value class ve value record anahtar kelimelerini getirir:

// JDK 28 Project Valhalla (JEP 401 — --enable-preview)
public value record GeoCoordinate(double latitude, double longitude) {
    public GeoCoordinate {
        if (Double.isNaN(latitude) || Double.isNaN(longitude)) {
            throw new IllegalArgumentException("Geçersiz koordinat değeri");
        }
    }
}

public final class SpatialIndex {
    // Dizi elemanları referans olarak değil, doğrudan düzleştirilmiş
    // (flattened) ham double çiftleri halinde bitişik bellekte tutulur.
    private final GeoCoordinate[] grid = new GeoCoordinate[1_000_000];

    public double computeDistanceSum() {
        double acc = 0.0;
        for (int i = 0; i < grid.length; i++) {
            GeoCoordinate coord = grid[i];
            acc += (coord.latitude() * 0.5) + (coord.longitude() * 0.5);
        }
        return acc;
    }
}

JEP 401 ve JEP 539'un JVM Alt Katmanındaki Etkileri

• Yığın Üzerinde Dizi Düzleştirme (Heap Array Flattening): GeoCoordinate[] dizisi bellekte ayrı nesnelere işaret eden referanslar yerine, doğrudan [lat0, lon0, lat1, lon1, ...] şeklinde kesintisiz bir bayt dizisi olarak yerleşir. Nesne başlığı yükü %100 sıfırlanır ve donanım önbellek ön-getirme (hardware prefetching) birimleri tam kapasiteyle çalışır.
• JIT Yığın Çerçevesi Skalarizasyonu (Stack Scalarization): Bir metot çağrısında kullanılan GeoCoordinate nesnesi yığında (heap) hiç tahsis edilmez; C2 JIT derleyicisi nesnenin latitude ve longitude alanlarını doğrudan CPU yazmaçlarına (registers) ayırarak sıfır çöp toplama (zero-GC) baskısıyla işler.
• JEP 539 (Strict Field Initialization in the JVM) Güvencesi: Bir değer nesnesinin bellekte güvenle düzleştirilebilmesi ve kopyalanabilmesi için, nesne daha inşa edilirken (super() çağrısı tamamlanmadan önce) tüm final alanlarının kesin olarak ilklendirilmiş olması şarttır. JEP 539, JVM sınıf dosyası doğrulayıcısına (classfile verifier) katı ilklendirme kuralları ekleyerek yarı-inşa edilmiş (partially initialized) nesne durumlarının başka iş parçacıklarına sızmasını bayt kodu düzeyinde imkansız kılar.

2. Project Leyden Sıçraması: JEP 544 (Ahead-of-Time Code Compilation)

Bulut-yerel mikroservislerde ve Kubernetes yatay otomatik ölçekleme (Horizontal Pod Autoscaler) senaryolarında Java'nın en büyük yumuşak karnı JIT ısınma eğrisi (warmup curve) olmuştur. Daha önceki sürümlerde Project Leyden kapsamında sunulan JEP 483 (AOT Class Loading & Linking) ve JEP 514 / JEP 515 (AOT Command-Line Ergonomics & Method Profiling), sınıfların önceden yüklenmesini ve metot profillerinin önbelleğe alınmasını sağlamıştı. Ancak uygulama ayağa kalktığında C2 JIT derleyicisinin bu profilleri okuyup bayt kodunu yerel makine koduna (native machine code) derlemesi yine de ilk birkaç saniyede yoğun CPU tüketimine ve gecikme sıçramalarına (p99 latency spikes) neden oluyordu.

JEP 544: Ahead-of-Time Code Compilation, Leyden mimarisindeki eksik halkayı tamamlar: Artık eğitim çalışması (training run) sırasında JIT derleyicisi tarafından üretilen derlenmiş yerel makine kodları doğrudan AOT önbellek dosyasına (app.aot) kaydedilir.

# Tek adımlı eğitim ve AOT yerel kod önbelleği üretimi (JEP 514 + JEP 544)
java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf \
     -cp target/order-service.jar com.enterprise.OrderApplication

java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf \
     -XX:AOTCache=order-service.aot -cp target/order-service.jar

# Üretim ortamında sıfır JIT derleme gecikmesiyle çalıştırma
java -XX:AOTCache=order-service.aot -cp target/order-service.jar \
     com.enterprise.OrderApplication

Üretim konteyneri -XX:AOTCache=order-service.aot bayrağıyla başlatıldığında, HotSpot JVM yorumlayıcı (interpreter) ve C1 kademeli derleme (tiered compilation) aşamalarını tamamen atlayarak doğrudan önbellekteki optimize edilmiş x86_64/AArch64 makine kodunu belleğe eşler. GraalVM Native Image'in kapalı dünya (closed-world) kısıtlamalarına takılmadan — yani dinamik sınıf yükleme, JMX, Java Agent ve Reflection yeteneklerinden ödün vermeden — anında tepe performansa ulaşılır.

3. Project Loom Finalizasyonu: JEP 543 (Structured Concurrency)

JDK 21 ile kalıcı hale gelen Sanal İş Parçacıkları (Virtual Threads - JEP 444), milyonlarca eşzamanlı G/Ç işleminin çok düşük bellek maliyetiyle yürütülmesini mümkün kıldı. Ancak bu milyonlarca sanal iş parçacığının hata durumunda nasıl iptal edileceği, zaman aşımı (timeout) yönetimi ve iş parçacığı sızıntılarının (thread leaks) nasıl önleneceği konusu, beş sürüm boyunca önizleme aşamasında kalan Structured Concurrency API'sine bağlıydı.

JEP 543: Structured Concurrency ile birlikte java.util.concurrent.StructuredTaskScope API'si artık önizleme bayrağı (--enable-preview) gerektirmeyen kalıcı (Final) bir JDK standardı haline gelir. Temel mimari ilke nettir: Bir kod bloğu içinde çatallanan (fork) tüm eşzamanlı alt görevler, aynı kod bloğunun sonundan çıkmadan önce tamamlanmak veya iptal edilmek (join) zorundadır.

import java.util.concurrent.StructuredTaskScope;
import java.util.concurrent.StructuredTaskScope.Subtask;
import java.time.Duration;

public record RiskAssessmentReport(CreditScore score, FraudSignal signal) {}

public final class PaymentOrchestrator {

    public RiskAssessmentReport evaluateTransaction(String accountId) throws InterruptedException {
        // JDK 28 Final API: Konfigürasyon ve Joiner tabanlı açılış
        try (var scope = StructuredTaskScope.open(
                StructuredTaskScope.Joiner.<Object>awaitAllSuccessfulOrThrow(),
                cf -> cf.withName("risk-eval-scope")
                        .withTimeout(Duration.ofMillis(250)))) {

            Subtask<CreditScore> creditTask = scope.fork(() -> fetchCreditScore(accountId));
            Subtask<FraudSignal> fraudTask  = scope.fork(() -> scanFraudVector(accountId));

            // Her iki alt görev tamamlanana kadar bekler; biri hata fırlatırsa
            // veya 250ms aşılırsa diğer sanal iş parçacığını anında iptal eder.
            scope.join();

            return new RiskAssessmentReport(creditTask.get(), fraudTask.get());
        }
    }
}

StructuredTaskScope kullanımıyla birlikte jcmd <pid> Thread.dump_to_file -format=json komutu çalıştırıldığında, ebeveyn-çocuk sanal iş parçacığı ilişkileri tam bir ağaç hiyerarşisi halinde gözlemlenebilir hale gelir; gözden kaçan "hayalet iş parçacığı" (orphan thread) riski mimari olarak ortadan kalkar.

4. Kriptografik Standartlaşma, Kuşaksal Shenandoah ve Ekim JEP Üçlüsü

JDK 28 yol haritasındaki diğer yedi JEP, çalışma zamanının güvenlik, çöp toplama ve veri işleme katmanlarını tamamlar:

JEP 542: PEM Encodings of Cryptographic Objects (Final)

Yıllar boyunca Java uygulamalarında -----BEGIN PRIVATE KEY----- veya -----BEGIN CERTIFICATE----- biçimindeki standart PEM metinlerini PrivateKey, PublicKey ya da X509Certificate nesnelerine dönüştürmek için ya karmaşık Base64/ASN.1 ayrıştırma kodları yazılması ya da BouncyCastle gibi harici kütüphanelerin projeye eklenmesi gerekiyordu. JEP 542, java.security.PEMDecoder ve java.security.PEMEncoder sınıflarını kalıcı hale getirerek tek satırda tip güvenli dönüşüm sunar:

import java.security.PEMDecoder;
import java.security.interfaces.ECPrivateKey;

PEMDecoder decoder = PEMDecoder.of();
ECPrivateKey privateKey = decoder.decode(pemString, ECPrivateKey.class);

JEP 535 (Generational Shenandoah) ve Ekim Ayında Resmileşen Üç JEP (JEP 545, JEP 546, JEP 540)

• JEP 535: Shenandoah GC: Generational Mode by Default: Düşük duraklama süreli Shenandoah çöp toplayıcısında, genç nesneleri (young generation) yaşlı nesnelerden (old generation) bağımsız toplayan kuşaksal mod varsayılan (-XX:ShenandoahGCMode=generational) haline getirilerek CPU ve bellek tavanı düşürülür.
• Ekim Ayında Resmileşen ZGC ve JSON Üçlüsü: Ekim ayında hedeflenen son üç JEP olan JEP 545 (Faster Startup and Warmup with ZGC), JEP 546 (Adaptive Heap Sizing for ZGC) ve JEP 540 (Simple JSON API - Incubator) ise ZGC'nin 2 MB başlangıç yığınıyla 100 ms altında uyanmasını, -Xmx ayarına gerek kalmadan sistem belleğine göre otonom ölçeklenmesini ve JDK içinde sıfır bağımlılıklı değişmez (immutable) JSON ağacı işlenmesini sağlar.

5. JDK 28 Resmi Hedefli 10 JEP Mimari Karşılaştırma Matrisi

Aşağıdaki tablo, OpenJDK 28 sürümünde resmi olarak hedeflenen (Targeted) 10 JEP'in tamamını teknik etki alanlarına göre özetlemektedir:

6. Kurumsal Üretim Sistemleri İçin Mimari Değerlendirme

JDK 28, Java'nın yüksek soyutlama gücü ile donanım seviyesindeki C/Rust verimliliği arasındaki tarihsel uçurumu kapatan sürüm olarak öne çıkmaktadır. Kurumsal mikroservis mimarilerinde JEP 543 (Structured Concurrency) ve JEP 542 (PEM Encodings) önizleme bayrağı gerektirmeden doğrudan üretim kodlarında devreye alınabilir durumdadır. Konteyner dağıtım hatlarında JEP 544 (-XX:AOTCache) ile JEP 545/546 (-XX:+UseZGC) kombinasyonu, soğuk başlangıç ve kuyruk gecikmelerini (tail latency) minimuma indirirken; yüksek hacimli finansal hesaplama, oyun motoru ve vektör arama iş yüklerinde JEP 401 (Value Objects) önizlemesi bellek bant genişliği kullanımında radikal bir sıçrama vaat etmektedir.