Bytecode Duvarını Aşmak: Project Babylon (HAT), Code Reflection ve JDK 28 Ekosisteminde Saf Java ile GPU Üzerinde Yerel LLM Mimarisi

1995 yılında James Gosling ve ekibi Java'yı dünyaya tanıttığında, kurumsal yazılım mimarisini otuz yıl boyunca domine edecek tek bir temel vaat sundular: "Write Once, Run Anywhere" (Bir Kez Yaz, Her Yerde Çalıştır). Kodunuzu bir kez yazar, JVM bytecode'una derler ve altında SPARC, x86 veya ARM mimarisi olup olmadığını umursamadan her türlü işletim sisteminde koşturabilirdiniz.

Ancak donanım dünyasının fizik kuralları 2010'ların ortasında sessizce yön değiştirdi. Moore Yasası'nın tek çekirdekli CPU frekanslarında duvara çarpması ve hemen ardından patlak veren derin öğrenme devrimi, hesaplama ağırlığını CPU'lardan (Merkezi İşlem Birimleri) binlerce paralel çekirdeğe sahip GPU'lara (Grafik İşlem Birimleri) ve NPU'lara kaydırdı. İşte tam bu noktada Java'nın ünlü sloganındaki acımasız mimari gerçek ortaya çıktı: "Anywhere" (Her Yer) kelimesi, GPU'ları hiçbir zaman kapsamıyordu.

Python'un yapay zeka, derin öğrenme ve Büyük Dil Modelleri (LLM) ekosisteminde Java'yı geride bırakmasının sebebi dil olarak daha üstün veya daha hızlı olması değildi. Python, C/C++ ve CUDA çekirdeklerini sarmalayan PyTorch ve TensorFlow gibi kütüphaneler için sürtünmesiz bir betik (scripting) arayüzü olmayı kabul etti. Buna karşılık Java dünyasında bir matris çarpımını veya dikkat (Attention) mekanizmasını GPU'ya yıkmak istediğinizde; ya kırılgan JNI (Java Native Interface) köprüleriyle C++ kodu yazmak ya da veriyi serileştirip gRPC üzerinden harici bir Python mikroservisine göndermek zorundaydınız.

OpenJDK çatısı altında Paul Sandoz ve Gary Frost liderliğinde yürütülen Project Babylon ve onun doğrudan donanım hızlandırma kolu olan HAT (Heterogeneous Accelerator Toolkit), Java'nın 30 yıllık bu mimari kör noktasını ortadan kaldırmak için tasarlandı. JDK 28 erken erişim (Early-Access) derlemeleri ve jdk.incubator.code (JEP 8361105) modülüyle şekillenen bu devrim, Java'ya kendi kodunu sembolik olarak okuma, dönüştürme ve doğrudan GPU makine koduna derleme yeteneği kazandırıyor.

1. Mimari Kör Nokta: Java Neden Kendi Kodunu Göremiyor?

Bir Java geliştiricisinin saf Java ile bir GPU çekirdeği (kernel) yazdığını ve bunu NVIDIA bir kartta CUDA PTX olarak veya AMD/Intel bir kartta OpenCL/SPIR-V olarak çalıştırmak istediğini varsayalım. Bunu başarmak için çalışma zamanındaki (runtime) bir kütüphanenin geliştiricinin yazdığı Java metodunu analiz etmesi ve yabancı bir programlama modeline (SIMT - Single Instruction, Multiple Thread) tercüme etmesi gerekir.

Peki bunu neden mevcut Java araçlarıyla yapamıyoruz?

Java 1.1'den beri hayatımızda olan standart Reflection API (java.lang.reflect), yalnızca yapısal kabuğu görebilir: Bir sınıfın adını, alanlarını (fields), metot imzalarını ve parametre tiplerini sorgulayabilirsiniz. Ancak metot gövdesinin ({ ... }) içine baktığınızda standart Reflection tamamen kördür.

Alternatif olarak doğrudan derlenmiş .class dosyalarındaki JVM Bytecode'unu (örneğin yeni Class-File API veya ASM ile) okumayı deneyebilirsiniz. Nitekim Aparapi veya TornadoVM gibi projeler yıllarca bu yaklaşımı kullandı. Ancak burada derin bir derleyici teorisi problemi vardır:

1. Çok Düşük Seviyeli Soyutlama: JVM bytecode'u yığın (stack) tabanlı bir makine dilidir. javac kaynak kodu bytecode'a indirdiğinde; yüksek seviyeli döngü yapıları (for, while), kısa devre mantıksal operatörler, jenerik tip bilgileri (type erasure nedeniyle) ve karmaşık ifade ağaçları parçalanarak düz goto sıçramalarına ve yerel değişken indekslerine dönüşür.
2. Yeniden İnşa Maliyeti: Bir GPU derleyicisinin paralel veri akışını doğrulaması için bu düzleştirilmiş yığın komutlarından yüksek seviyeli kontrol akışı grafiğini (CFG) ve veri bağımlılıklarını tersine mühendislikle (decompilation) yeniden inşa etmesi gerekir. Bu işlem hem aşırı maliyetlidir hem de semantik bilgi kaybı yüzünden çoğu zaman agresif GPU optimizasyonlarını imkansız kılar.
3. AST'nin Erişilemezliği: Diğer uçta yer alan derleyicinin Soyut Sözdizimi Ağacı (AST) ise çok fazla yüzeysel sözdizimi detayı barındırır, standartlaştırılmamıştır ve çalışma zamanında (runtime) erişilemez.

"Mimari Not: GPU'lar, CPU'lar gibi dallanma tahmini (branch prediction) ve sırasız yürütme (out-of-order execution) için optimize edilmemiştir. Bir kodu GPU'ya verimli şekilde indirmek için yığın tabanlı bytecode komutlarına değil; matematiksel niyeti, veri tiplerini ve kontrol akışını koruyan yüksek seviyeli bir Ara Temsile (Intermediate Representation - IR) ihtiyacınız vardır."

2. Project Babylon ve Code Reflection (JEP 8361105): Sembolik "Code Model" Evrimi

Project Babylon, tam olarak AST ile Bytecode arasındaki bu "Altın Oran" (Goldilocks zone) boşluğunu doldurmak için Code Reflection kavramını getiriyor. JEP 8361105 kapsamında jdk.incubator.code modülü altında sunulan bu mimari, Java programlarının sembolik olarak modellenmesini sağlıyor.

Bir Java metodunu veya lambda ifadesini @CodeReflection (güncel Babylon geliştirme dalındaki adıyla @Reflect) anotasyonu ile işaretlediğinizde, javac derleyicisi sadece geleneksel JVM bytecode'unu üretmekle kalmaz; aynı zamanda o metodun Code Model adı verilen sembolik temsilini oluşturup .class dosyasının içine gömer.

SSA (Static Single Assignment) ve MLIR Esinlenmesi

Babylon'un ürettiği Code Model, modern derleyici altyapılarının (özellikle LLVM ve MLIR - Multi-Level Intermediate Representation) temel taşı olan SSA (Static Single Assignment) formuna dayanır. Bu modelde:

• Her değişken yalnızca bir kez atanır.
• Java ifadeleri, kontrol akışları ve metot çağrıları Op (Operasyon) sınıfından türeyen hiyerarşik düğümler olarak temsil edilir.
• Tüm veri tipleri TypeElement üzerinden kayıpsız bir şekilde korunur.

Örneğin, basit bir Fused Multiply-Add (a * b + c) işleminin Babylon tarafından çalışma zamanında sunulan sembolik SSA Code Model çıktısı şu şekildedir:

func @"compute" (%0 : java.type:"float", %1 : java.type:"float", %2 : java.type:"float")java.type:"float" -> {
    %3 : Var<java.type:"float"> = var %0 @"a";
    %4 : Var<java.type:"float"> = var %1 @"b";
    %5 : Var<java.type:"float"> = var %2 @"c";
    %6 : java.type:"float" = var.load %3;
    %7 : java.type:"float" = var.load %4;
    %8 : java.type:"float" = mul %6 %7;
    %9 : java.type:"float" = var.load %5;
    %10 : java.type:"float" = add %8 %9;
    return %10;
};

Bu yapı bir Java kütüphanesi tarafından çalışma zamanında Method::getCodeModel (veya Op.ofMethod(method)) çağrısıyla elde edilebilir, üzerinde ağaç gezintisi (tree traversal) yapılabilir, optimize edilebilir ve bambaşka bir dile (SQL, diferansiyel türev grafiği, MLIR TOSA diyalekti veya CUDA C/PTX) dönüştürülebilir.

3. HAT (Heterogeneous Accelerator Toolkit): Saf Java'dan CUDA ve OpenCL'e

Code Reflection'ın ne kadar güçlü bir temel ilkel (primitive) olduğunu kanıtlamak isteyen OpenJDK ekibi, Aparapi'nin de yaratıcısı olan Gary Frost öncülüğünde HAT (Heterogeneous Accelerator Toolkit) projesini geliştirdi. HAT, JDK'nın içine gömülü monolitik bir GPU API'si olmak yerine; Babylon'un Code Reflection, Project Panama'nın Foreign Function & Memory (FFM - JEP 454) ve yeni Class-File API'lerini kullanan saf bir Java çerçevesidir.

HAT mimarisi üç temel sütun üzerinde yükselir:

A. iFaceMapper ve Panama FFM ile Sıfır Kopyalı (Zero-Copy) Bellek

GPU programlamadaki en büyük darboğaz hesaplama değil, veriyi PCIe veri yolu üzerinden taşımaktır. Üstelik bir GPU, JVM'in Heap belleğindeki float[] dizisine doğrudan erişemez; çünkü Garbage Collector (Çöp Toplayıcı) herhangi bir anda nesnelerin bellek adreslerini değiştirebilir (compaction/relocation).

HAT bu sorunu Project Panama'nın MemorySegment yapısını kullanan iFaceMapper arayüzü ile çözer. Geliştirici, GPU ile paylaşılacak veri yapılarını basit Java interface tanımları olarak yazar. HAT, çalışma zamanında bu arayüzleri off-heap (GC dışı) bellek segmentlerine bağlayan sınıfları dinamik olarak üretir. Böylece hem CPU'daki Java kodu hem de GPU'daki CUDA/OpenCL çekirdeği aynı fiziksel bellek bölgesini tip güvenli (type-safe) bir şekilde okuyup yazabilir.

B. NDRange ve SIMT Programlama Modeli

CPU'da iki vektörü toplamak istediğinizde bir for döngüsü yazarsınız. Ancak GPU'da binlerce iş parçacığı (thread) aynı anda çalışır (SIMT modeli). HAT, geliştiriciye KernelContext ve NDRange soyutlamalarını sunar. Döngü yazmak yerine, tek bir GPU iş parçacığının hangi indeks (kc.x) üzerinde ne yapacağını tanımlarsınız.

C. Çok Katmanlı İndirgeme (Lowering) ve Pluggable FFI Backends

Bir metodu @Reflect ile işaretleyip ComputeContext içerisinden çağırdığınızda HAT arka planda muazzam bir mühendislik zinciri çalıştırır:

1. SSA FuncOp Yakalama: Metodun ve onun çağırdığı alt metotların (call graph) Code Model ağaçlarını çıkarır.
2. HAT Dialect Dönüşümü ve Inlining: Yardımcı metotları ana çekirdeğin içine gömer (inlining) ve bellek erişimlerini analiz ederek hangi tamponların salt okunur (RO), hangilerinin yazılabilir (RW) olduğunu otomatik olarak etiketler (Buffer Tagging).
3. Veri Transferi Optimizasyonu (MINIMIZE_COPIES): IR seviyesindeki bu okuma/yazma analizini kullanarak, veri GPU belleğinde zaten güncelse CPU'dan GPU'ya tekrar kopyalanmasını engeller.
4. Kod Üretimi: Dönüştürülen modeli hedef donanım arka ucuna (ffi-cuda, ffi-opencl, ffi-spirv veya hata ayıklama için java-seq) göndererek PTX veya OpenCL C kodunu üretir ve sürücü üzerinden yürütür.

4. Mimari Uygulama: HAT ve Code Reflection ile Yerel LLM Matris Çarpımı (MatMul) ve RMSNorm

Bir Büyük Dil Modelinin (LLM) çıkarım (inference) aşamasında zamanın %90'ından fazlası Matris Çarpımı (GEMM / MatMul) ve Normalizasyon/Attention katmanlarında harcanır. Aşağıdaki kod bloğu, Project Babylon (jdk.incubator.code) ve HAT API'lerini kullanarak, hiçbir C++/CUDA dosyasına dokunmadan saf Java ile yazılmış donanım hızlandırmalı bir LLM katmanının nasıl inşa edildiğini göstermektedir:

// Derleme ve Çalıştırma (JDK 28 Babylon EA / Code Reflection dalı):
// javac --add-modules jdk.incubator.code --enable-preview -d out LLMInferenceEngine.java
// java --add-modules jdk.incubator.code --enable-preview -Dhat=ffi-cuda:MINIMIZE_COPIES -cp out LLMInferenceEngine

import jdk.incubator.code.Reflect;
import hat.Accelerator;
import hat.ComputeContext;
import hat.KernelContext;
import hat.backend.Backend;
import hat.buffer.F32Array;

public class LLMInferenceEngine {

    /**
     * 1. GPU KERNEL: Matris Çarpımı (MatMul - C = A x B)
     * Döngü (outer loop) yoktur; her GPU thread'i (kc.x) çıktı matrisindeki bir hücreyi hesaplar.
     * @Reflect anotasyonu javac'ye bu metodun SSA Code Model'ini .class içine gömmesini söyler.
     */
    @Reflect
    public static void matMulKernel(KernelContext kc, F32Array matrixA, F32Array matrixB, F32Array matrixC, int size) {
        if (kc.x < kc.maxX) {
            int row = kc.x / size;
            int col = kc.x % size;
            float acc = 0.0f;
            
            for (int k = 0; k < size; k++) {
                acc += matrixA.array(row * size + k) * matrixB.array(k * size + col);
            }
            matrixC.array(row * size + col, acc);
        }
    }

    /**
     * 2. GPU KERNEL: Element-wise Aktivasyon (SiLU / Swish benzeri ölçekleme)
     * Çoklu çekirdek (Multi-kernel) kompozisyonu: Veriyi CPU'ya geri çekmeden GPU üzerinde işler.
     */
    @Reflect
    public static void scaleAndActivateKernel(KernelContext kc, F32Array tensor, float scale) {
        if (kc.x < kc.maxX) {
            int idx = kc.x;
            float val = tensor.array(idx) * scale;
            // Basit ReLU/Clamping aktivasyon örneği
            tensor.array(idx, val > 0.0f ? val : 0.0f);
        }
    }

    /**
     * 3. COMPUTE GRAPH: HAT tarafından analiz edilen orkestrasyon metodu.
     * HAT bu metodu inceler, iki kernel arasındaki veri bağımlılığını (matrixC) çözer
     * ve MINIMIZE_COPIES sayesinde ara sonucu CPU RAM'ine kopyalamadan GPU VRAM'inde tutar!
     */
    @Reflect
    public static void forwardLayer(ComputeContext cc, F32Array weights, F32Array input, F32Array output, int N) {
        int totalElements = N * N;
        
        // 1. Adım: MatMul çekirdeğini N*N paralel GPU thread'i üzerinde koştur
        cc.dispatchKernel(totalElements, 
            kc -> matMulKernel(kc, weights, input, output, N)
        );

        // 2. Adım: Çıktı tensörünü CPU'ya taşımadan doğrudan ikinci GPU çekirdeğine besle
        float rmsScale = 1.0f / (float) Math.sqrt(N);
        cc.dispatchKernel(totalElements, 
            kc -> scaleAndActivateKernel(kc, output, rmsScale)
        );
    }

    public static void main(String[] args) {
        // Donanım hızlandırıcısını başlat (CUDA veya OpenCL backend'ini otomatik bağlar)
        var accelerator = new Accelerator(MethodHandles.lookup(), Backend.FIRST);
        final int N = 1024;
        final int matrixSize = N * N;

        // Panama FFM (iFaceMapper) tabanlı off-heap bellek tahsisi
        F32Array weights = F32Array.create(accelerator, matrixSize);
        F32Array input   = F32Array.create(accelerator, matrixSize);
        F32Array output  = F32Array.create(accelerator, matrixSize);

        // Başlangıç ağırlıklarını doldur (Off-heap MemorySegment üzerinde doğrudan yazma)
        for (int i = 0; i < matrixSize; i++) {
            weights.array(i, (i % 100) * 0.01f);
            input.array(i, ((i + 1) % 50) * 0.02f);
        }

        long startTime = System.nanoTime();

        // Hesaplama grafiğini GPU'ya devret
        accelerator.compute(cc -> 
            forwardLayer(cc, weights, input, output, N)
        );

        long elapsedMs = (System.nanoTime() - startTime) / 1_000_000;
        System.out.printf("GPU Katman Çıkarımı Tamamlandı (%dx%d): %d ms | Örnek Çıktı[0]: %.4f%n", 
                          N, N, elapsedMs, output.array(0));
    }
}

Kodun Arkasındaki Mimari Sihir: ComputeContext Analizi

Yukarıdaki kodda dikkat edilmesi gereken en kritik nokta sadece matMulKernel metodunun @Reflect ile işaretlenmesi değil, onu çağıran forwardLayer metodunun da @Reflect taşımasıdır.

Geleneksel GPU kütüphanelerinde (veya JOCL/JCuda gibi sarmalayıcılarda) birinci çekirdeği çalıştırdıktan sonra kontrol CPU'ya döner ve ikinci çekirdek için bellek tamponlarının senkronizasyonunu elle yönetmeniz gerekir. HAT ise forwardLayer metodunun Code Model ağacını bütüncül olarak okur:

• weights ve input dizilerinin yalnızca okunduğunu (RO - Read Only) tespit eder; bunları GPU'ya bir kez kopyalar.
• output dizisinin birinci çekirdekte yazıldığını (WO), ikinci çekirdekte ise hem okunup hem yazıldığını (RW) SSA veri akışı grafiğinden (Dataflow Graph) anlar.
• İki dispatchKernel çağrısı arasında output dizisine Java (CPU) tarafından hiçbir erişim yapılmadığını kanıtladığı için, birinci çekirdek bittiğinde veriyi PCIe üzerinden RAM'e geri çekmez; doğrudan GPU VRAM'inde bırakarak ikinci çekirdeği tetikler.

5. Performans Kıyaslaması: JNI, TornadoVM ve Project Babylon (HAT)

2026 yılı itibarıyla Java ekosisteminde yüksek performanslı hesaplama ve GPU hızlandırması için masada üç farklı yaklaşım bulunmaktadır. Mimari karar vericiler için bu teknolojilerin sınırlarını netleştirmek gerekir:

Paylaşımlı Bellek (GPU Local/Shared Memory) ve Tiling Optimizasyonu

OpenJDK ekibinin (Juan Fumero ve Paul Sandoz) 2026'da yayımladığı "Optimizing GPU Programs from Java using Babylon and HAT" araştırması, HAT'in sadece basit döngüleri değil, ileri seviye GPU optimizasyonlarını da saf Java ile ifade edebildiğini kanıtladı.

Naif bir matris çarpımında her GPU iş parçacığı küresel GPU belleğine (Global VRAM) binlerce kez erişir ve bellek bant genişliği darboğazına (Memory Wall) takılır. HAT, geliştiricilerin GPU'nun ultra hızlı çip üstü Paylaşımlı Belleğini (Shared/Local Memory) ve iş parçacığı bariyerlerini (kc.barrier()) doğrudan Java kodu içinde tanımlamasına olanak tanır (Loop Tiling). Yapılan kıyaslamalarda:

• Çok çekirdekli CPU üzerindeki Java Streams/Vector API uygulamasına kıyasla, HAT'in naif GPU çekirdeği 15x - 25x hızlanma sağlarken;
• Yine saf Java içinde tanımlanan 2D/3D NDRange ve Paylaşımlı Bellek (Tiling) optimizasyonlu HAT çekirdeği, yerel CUDA C++ referans performansına yaklaşarak 80x üzeri bir hızlanma çarpanına ulaşmaktadır.

6. Sadece GPU Değil: ONNX Runtime, Otomatik Türev ve LINQ

Project Babylon'u yalnızca bir "Java GPU kütüphanesi" olarak görmek, buzdağının sadece görünen kısmına bakmaktır. Code Reflection, Java diline birinci sınıf metaprogramlama yeteneği getirmektedir:

1. Doğrudan ONNX ve MLIR Entegrasyonu: Babylon deposundaki cr-examples/onnx ve topluluk tarafından geliştirilen MLIR TOSA projeleri, @Reflect ile yazılmış saf Java sinir ağı katmanlarını analiz edip doğrudan bir ONNX hesaplama grafiğine veya Triton GPU çekirdeklerine dönüştürmektedir. Yani model mimarinizi Python'da yazıp dışa aktarmak yerine, doğrudan tip güvenli Java kodu olarak yazıp TensorRT veya CoreML üzerinde koşturabilirsiniz.
2. Otomatik Türev (Automatic Differentiation): Derin öğrenme eğitimlerinin (backpropagation) ve bilimsel simülasyonların temeli türev almaktır. Babylon, matematiksel bir Java metodunun Code Model ağacını okuyup, zincir kuralını (chain rule) sembolik olarak uygulayarak o metodun türevini hesaplayan yeni bir Java metodunu çalışma zamanında otomatik olarak sentezleyebilmektedir.
3. Java'da C# LINQ Deneyimi: Bir lambda ifadesinin (user -> user.age() > 25 && user.active()) içine bakabilme yeteneği sayesinde, ORM kütüphaneleri artık garip String birleştirmelerine veya Criteria API'lerine ihtiyaç duymadan, standart Java Stream lambdalarını derleme/çalışma zamanında doğrudan optimize edilmiş SQL sorgularına çevirebilecektir.

"Mimari Not: C# dünyasının 2007 yılında IQueryable ve Expression<Func<T>> (Expression Trees) ile kazandığı ancak GPU seviyesine tam indiremediği sembolik kod temsili; Java dünyasına 20 yıl sonra çok daha modern bir SSA derleyici mimarisiyle (Code Models) geliyor."

7. Sektör ve Mühendisler İçin Stratejik Çıkarımlar

JDK 28 ve Project Babylon'un çizdiği mimari rota, kurumsal yazılım dünyası ve sistem mimarları için üç büyük kırılmayı işaret ediyor:

• "Runtime Yılı" Üçgeni Tamamlanıyor: Java dünyasında son yıllarda paralel ilerleyen dört dev proje artık tek bir potada eriyor. Project Valhalla (JEP 401) nesne başlıklarını silip bellekte düzleştirilmiş (flat/dense) değer tipleri sunuyor; Project Panama (FFM) yerel belleğe sıfır maliyetli erişim sağlıyor; Vector API CPU SIMD komutlarını açıyor; ve Project Babylon (HAT) bu düzleştirilmiş veriyi doğrudan GPU çekirdeklerine fırlatıyor.
• Python "Yan Arabası" (Sidecar) Mimarisinin Sonu: Bugün pek çok kurumsal finans, e-ticaret ve telekomünikasyon sistemi; ana iş mantığını Spring Boot / Quarkus üzerinde koştururken, sadece vektör gömme (embedding) üretmek, yeniden sıralama (reranking) yapmak veya küçük ölçekli yerel LLM'leri (Llama-3-8B, Qwen, Mistral vb.) çalıştırmak için yanına Python/FastAPI konteynerleri dikmek zorunda kalıyor. Babylon ve HAT olgunlaştığında, bu modeller ağ serileştirme gecikmesi olmadan doğrudan JVM prosesinin içinde (In-Process), GPU hızlandırmalı olarak çalışacaktır.
• Geliştiriciler Bugün Ne Yapmalı? Project Babylon şu an jdk.incubator.code modülü altında kuluçka (incubation) aşamasına hazırlanıyor ve kademeli JEP'lerle standart JDK'ya dahil ediliyor. Eğer bugün üretim ortamında (production) acil olarak Java'dan GPU hızlandırmasına ihtiyacınız varsa, Aralık 2025'te 2.0 sürümüne ulaşan TornadoVM en olgun köprüdür. Ancak geleceğin standart mimarisini inşa eden kütüphane yazarları ve sistem mimarları, vakit kaybetmeden OpenJDK Babylon derlemelerini indirip SSA Code Model API'leri ve HAT (ffi-cuda / ffi-opencl) ile prototipler geliştirmeye başlamalıdır.

Java, otuz yıl önce işletim sistemi farklılıklarını soyutlayarak kurumsal dünyayı fethetmişti. Şimdi ise Project Babylon ile CPU, GPU ve NPU arasındaki donanım sınırlarını soyutlayarak yapay zeka çağının yerel hesaplama motoru olmaya hazırlanıyor. Bytecode duvarı nihayet yıkıldı; GPU artık Java için yabancı bir toprak değil.