AOT ve JIT Derleme Dinamikleri

Bölüm 1: Bu Nedir ve Neden Hayati Önem Taşır?

Android ekosisteminin çalışma zamanı (runtime) mimarisi, uygulama performansının, pil ömrünün ve sistem kararlılığının belirleyicisidir. Dalvik, Android 4.4 (KitKat) öncesinde varsayılan sanal makine (VM) olarak, kayıt tabanlı mimari ve Just-In-Time (JIT) derleme ile bytecode’u çalışma anında makine koduna dönüştürürken; ART (Android Runtime), Android 5.0 (Lollipop) ile başlayarak Ahead-Of-Time (AOT) derleme paradigmasını benimsemiştir. Bu çalışma, iki çalışma zamanının ontolojik farkını; derleme stratejisi (JIT vs AOT), bellek yönetimi (GC algoritmaları), depolama maliyeti (DEX vs OAT/ART) ve yürütme hızı (Interpreter vs Compiled Native) eksenlerinde incelemektedir. Temel yaklaşım, “yorumlayıcı gecikmesi” ile “kurulum gecikmesi” arasındaki ticareti (trade-off), modern Profil-Guided Compilation (PGC) ve Cloud Profiles hibrit modelleri bağlamında yeniden değerlendirmektir.

Bölüm 2: Perde Arkası: Sistem Nasıl Çalışıyor?

Dalvik’in JIT derleyicisi, “hot” (sıcak) kod yollarını tespit edip bunları çalışma sırasında yerel koda derler; bu da başlangıçta yorumlayıcı (interpreter) modunda yavaş başlangıç, ısındıkça hızlanma profili yaratır. Bellek baskısı altında derleme önbelleği (code cache) serbest bırakılır. ART ise AOT ile uygulamayı cihaza yüklenirken (dex2oat aracıyla) tamamen yerel makine koduna (ELF formatında .oat/.art dosyaları) derler. Bu, başlangıç gecikmesini (startup latency) minimize eder ancak kurulum süresini ve disk alanını artırır. ART’in GC’si (Generational/Concurrent/Compacting), Dalvik’in “Stop-the-World” ağırlıklı mark-sweep kolektöründen farklı olarak, kopya toplama (copying collector) ve bölgelere ayrılmış yığın (region-based heap) ile duraklama sürelerini (pause times) milisaniyeler seviyesine indirir. Yürütme motoru, hızlı yorumlayıcı (Quick Interpreter) ve optimize edilmiş yerel kod arasında kesintisiz geçiş sağlar.

Bölüm 3: Bilim Dünyası ve Uzmanlar Nasıl İnceliyor?

Derleme süreci, Android Open Source Project (AOSP) derleme zinciri (Soong/Blueprint) ve dex2oat aracı standartlarıyla yönetilir. DEX (Dalvik Executable) bayt kodu formatı, IEEE 754 kayan nokta ve Java sanal makine spesifikasyonu (JVMS) alt kümesi uyumluluğu taşır. ART, LLVM tabanlı optimizing backend (Optimizing Compiler) kullanarak SSA (Static Single Assignment) formu üzerinden kayıt tahsisi, satır içi yerleştirme (inlining) ve ölü kod eleme (DCE) optimizasyonları uygular. Profil verileri, cur (current) ve ref (reference) profilleri olarak dexopt durum makinesi (verified, extracted, compiled, interpreted) tarafından işlenir. Google Play Cloud Profiles altyapısı, topluluk verisi (crowdsourced data) ile cihazda derleme önceliklerini (compilation filter: speed, speed-profile, verify, interpret-only) dinamikleştirir. SELinux politikaları ve seccomp filtreleri, derleme sürecinin izolasyonunu ve güvenliğini sağlar.

Bölüm 4: Önemli Parametreler ve Karşılaştırma Rehberi

Bölüm 5: Günlük Hayatta ve Doğada Nerede Karşımıza Çıkar?

Düşük seviyeli sistem uygulamaları (System Server, SurfaceFlinger) ve oyun motorları (Unity, Unreal) ART’in AOT derlemesinden en çok faydalanır; deterministik frame time’lar ve düşük GC duraklamaları 60/90/120 FPS hedefleri için kritiktir. Enterprise MDM (Mobile Device Management) çözümlerinde, dex2oat --compiler-filter=speed zorunlu kılınarak cihaz tesliminden önce tam derleme sağlanır, böylece kullanıcı ilk açılışta “Optimizing apps” beklemesi yaşamaz. Anında Uygulamalar (Instant Apps) ve Dynamic Delivery senaryolarında ise interpret-only veya verify filtreleri ile depolama ve bant genişliği tasarrufu yapılır, kod indirildikçe arka planda speed-profile derlemesi tetiklenir. Kotlin Coroutine ve Java Virtual Thread (Loom) yapıları, ART’in hızlı yorumlayıcısı ve optimize edilmiş monitorenter/monitorexit implementasyonu sayesinde context switching maliyetini minimize eder. Wear OS ve Android Automotive gibi kısıtlı kaynaklı cihazlarda dex2oat --image-format=lz4 sıkıştırılmış boot image kullanılarak RAM ve flash kullanımı dengelenir.

Bölüm 6: Karşılaşılan Zorluklar ve Pratik Çözümler

Derleme Zamanı Patlaması (Compilation Explosion): Büyük uygulamalarda (örn. 100MB+ DEX) dex2oat süresi dakikalara uzayabilir. Çözüm: compiler-filter=speed-profile ile sadece kritik yollar derlenir, Cloud Profiles ile önceden toplanan profiller cihaza indirilir. Depolama Baskısı: Düşük depolamalı cihazlarda (Go Edition) .oat dosyaları alanı doldurur. Çözüm: ProfileInstaller Jetpack kütüphanesi ile arka plan derlemesi ertelendi, dexopt durumu COMPLETED yerine PARTIAL bırakıldı. Uyumsuzluk (Hidden API): ART, greylist/blacklist mekanizmasıyla sun.misc.Unsafe veya android.* iç API’leri kısıtlar. Çözüm: @RequiresApi, reflection yerine public API kullanımı, --hidden-api-policy geçici geçişler. GC Parçalama (Heap Fragmentation): Uzun süreli süreçlerde (System Server) compacting GC olsa bile sanal adres alanı parçalanabilir. Çözüm: 64-bit geçişi (48-bit VMA) ve malloc arena izolasyonu (scudo allocator). OTA Güncelleme Sonrası Yeniden Derleme: Sistem imajı değiştiğinde tüm uygulamalar yeniden derlenir (Boot-time dexopt). Çözüm: Android 12+ artifacts (apex) modülerliği ve dexopt artımlı güncellemeleri ile sadece değişen modüller için derleme tetiklenir.

Bölüm 7: Gelecek Perspektifi ve Yeni Gelişmeler

Android 13/14 (Tiramisu/UpsideDownCake) sürümlerinde ART Module (APEX) yapısı sayesinde çalışma zamanı sistem imajından bağımsız olarak Play Store üzerinden güncellenebilmektedir. Baseline Profiles (Jetpack Macrobenchmark entegrasyonu), geliştiricilerin derleme önceliklerini kodla (.prof dosyası) bildirmesini sağlayarak Cloud Profiles’a bağımlılığı azaltmıştır. RISC-V 64-bit (RV64GCV) desteği, dex2oat backend’inde Vektör uzantıları (V extension) için auto-vectorization geçişleri eklenerek donanım hızlandırma kapısını aralamıştır. Virtual Threads (Project Loom) entegrasyonu için ART’in Thread sınıfı yeniden yapılandırılmış, VirtualThread scheduler kullanıcı alanında (user-space) çalışarak kernel context switch maliyetini ortadan kaldırmaktadır. Gelecek 5-10 yılda; Machine Learning Guided Optimization (MLGO) ile LLVM heuristikleri yerine RL tabanlı optimizasyon kararları (inlining, register allocation), CHERI (Capability Hardware Enhanced RISC Instructions) mimarisi ile bellek güvenliği donanımda zorunlu kılınacak ve Wasm (WebAssembly) Runtime entegrasyonu (WasmGC proposal) ile ART, sadece Java/Kotlin değil, Rust/Go/C++ Wasm modüllerini de yerel performansla barındıracak evrensel bir çalışma zamanına evrilecektir.

Bölüm 8: Merak Edilen Sorular ve Cevaplar

Soru 1: ART tamamen AOT mu, yoksa hala JIT mi kullanıyor?

Cevap: ART hibrit bir modeldir. Android 7.0 (Nougat) itibarıyla Profile-Guided Compilation kullanır. Uygulama yüklenirken verify veya speed-profile filtresiyle kısmi AOT derleme yapılır. Uygulama kullanıldıkça profil verisi toplanır (ProfileInstaller), arka planda dexopt servisi bu veriyle speed veya everything filtresiyle tam AOT derlemesini tamamlar. Yorumlayıcı (interpreter) her zaman yedek (fallback) olarak aktiftir.

Soru 2: Dalvik’ten ART’e geçişte uygulamam çöktü, neden?

Cevap: En yaygın nedenler: 1) JNI Yerel Kod Hataları: ART’in GC’si nesneleri taşır (compacting), Dalvik’te sabit kalan adresler ART’te geçersiz hale gelir (GetPrimitiveArrayCritical kullanımı sonrası Release unutulması). 2) Gizli API Kullanımı: java.lang.reflect ile erişilen sun.misc.Unsafe veya android.internal.* alanları ART’te kısıtlıdır (Greylist/Blacklist). 3) Dex Dosyası Yapısı: multidex yapılandırmasında MainDexList eksikliği veya sınıf sıralama hataları.

Soru 3: dex2oat ne işe yarar ve neden bazen çok uzun sürer?

Cevap: dex2oat (DEX to OAT), DEX bytecode’nu ELF formatında paylaşılan kütüphane (.so/.oat) olan makine koduna dönüştüren statik derleyicidir. Uzun süren nedenler: compiler-filter=everything (tüm metotlar optimize edilir), büyük DEX boyutu, düşük CPU/çekirdek sayısı, yetersiz RAM (swap kullanımı), veya System Server derlemesi sırasında tek işlemci çekirdeği kullanımı (Android 10 öncesi). --threads parametresi ve speed-profile filtresi ile hızlandırılır.

Soru 4: ART’in “Compacting GC” si Dalvik’ten nasıl farklı ve neden önemlidir?

Cevap: Dalvik’in Mark-Sweep GC’si belleği parçalar (fragmentation), büyük nesne ayırmaları OutOfMemoryError verirken boş bellek varken bile başarısız olur. ART’in Compacting GC (CMS / Generational / Region-based), canlı nesneleri bitişik bellek bloklarına kopyalayarak (evacuation) parçalanmayı önler. Bu, büyük bit eşlem (Bitmap) veya tampon (Buffer) ayırmalarında kritik başarı sağlar ve malloc performansını artırır.

Soru 5: Cloud Profiles (Bulut Profilleri) nasıl çalışır ve gizlilik riski var mı?

Cevap: Google Play, anonimleştirilmiş, toplanmış kullanım verisinden (hangi metotlar ne sıklıkla çağrılmış) cihaz bağımsız bir “referans profili” oluşturur. Uygulama yüklendiğinde bu profil cihaza indirilir ve dex2oat girdisi olarak kullanılır. Veri, kullanıcı kimliği olmadan, diferansiyel gizlilik (differential privacy) teknikleriyle toplanır; sadece popüler kod yolları paylaşılır, hassas veri paylaşılmaz. Geliştirici Play Console’dan devre dışı bırakabilir.

Soru 6: Baseline Profiles ile Cloud Profiles farkı nedir?

Cevap: Cloud Profiles topluluk verisidir, uygulama yüklendikten sonra indirilir, genel kullanıcı kitlesini temsil eder. Baseline Profiles geliştirici tarafından derleme anında (build-time) APK/AAB içine gömülür (assets/dexopt/baseline.prof), uygulama ilk çalıştırmadan önce kritik kullanıcı yolculuklarını (startup, scroll, navigation) hedefler. Baseline, soğuk başlangıcı (cold start) optimize etmek için zorunludur; Cloud Profiles zamanla ısınmayı (warm start) optimize eder.

Bölüm 9: Bilmeniz Gereken Temel Terimler

DEX (Dalvik Executable): Android’in çalıştırılabilir bayt kodu formatı. Java .class dosyalarından d8/dx araçlarıyla üretilir. Kayıt tabanlı talimat seti, sabit havuzu (string, type, method handles) içerir.
OAT (ART Ahead-of-Time): dex2oat çıktısı olan ELF formatında paylaşılan kütüphane. Yerel makine kodu (.text), VMap tabloları (GC haritaları), oatdata/oatexec/oatlast bölümlerini içerir. dlopen ile süreç adres alanına eşlenir.
Zygote: Linux fork() mekanizmasıyla önceden başlatılan, sistem sınıflarını (Boot Classpath) bellekte tutan şablon süreç. Tüm uygulama süreçleri Zygote’dan çatallanır (Copy-on-Write), başlangıç hızını ve bellek paylaşımını sağlar.
VMap Table (Verification Map / GC Map): Derlenmiş yerel kodun her talimat adresi için hangi kayıtların/yığın konumların nesne referansı (object reference) tuttuğunu gösteren harita. Compact GC’nin nesneleri taşımak için referansları güncellemesini sağlar.
Profile-Guided Compilation (PGC): Çalışma zamanı davranışına (profil verisine) dayanarak derleme kararları (hang metotlar optimize edilecek, hangileri yorumlanacak) veren dinamik optimizasyon stratejisi. ART’in speed-profile filtresinin temelidir.
Boot Image (art/boot.art): Zygote başlangıcında belleğe eşlenen, temel kütüphanelerin (core-libart, core-oj, okhttp, bouncycastle vb.) önceden derlenmiş ve sınıflandırılmış (pre-resolved) görüntüsü. Sınıf yükleme (class loading) maliyetini sıfırlar.
Hidden API / Greylist / Blacklist: SDK’ya dahil olmayan dahili API’lerin (android.*, com.android.*, sun.misc.*, libcore.*) erişim kısıtlama listeleri. Greylist: Uyarı verir ama çalışır (hedef API seviyesine göre); Blacklist: Çalışma zamanında NoSuchFieldError/NoSuchMethodError fırlatır.

Bölüm 10: Özet ve Çıkarılması Gereken Dersler

Android ART, Dalvik’in “yorumla, sonra derle” felsefesini “öncederle, profille optimize et, donanımı kullan” paradigmasına evrilmiştir. AOT derlemesi, başlangıç gecikmesini ve CPU döngü tasarrufunu (pil ömrü) kazandırırken; PGC ve Cloud/Baseline Profiles hibritliği, depolama maliyetini ve kurulum süresini dengelemiştir. Generational Compacting GC, parçalanma sorununu çözerek büyük yığın (large heap) uygulamaların (harita, oyun, video düzenleme) kararlılığını sağlamıştır. Stratejik olarak; Geliştiriciler Baseline Profiles entegrasyonunu CI/CD’ye gömerek “ilk izlenim” performansını garanti altına almalı; Sistem Entegratörleri (OEM) dex2oat derleme filtrelerini cihaz segmentine (Go/Entry/Flagship) göre kalibre ederek flash/RAM/CPU üçgenini optimize etmeli; Güvenlik Mimarları Hidden API kısıtlamalarını ve CFI/PAC/MTE donanım desteklerini zorunlu kılmalıdır. Gelecekte ART, WasmGC ve Virtual Threads ile dil bağımsız, güvenli, yüksek performanslı evrensel bir çalışma zamanı katmanına dönüşecek; bu da Android’i sadece bir mobil OS’den, edge-to-cloud hesaplama platformuna taşıyacaktır. Karar vericiler için yol haritası: Profil Kültürü (Baseline Profiles zorunluluğu), Modüler Güncelleme (ART APEX takibi), Donanım-Yazılım Bütünleşmesi (RISC-V/CHERI/MLGO yatırımları) üçgeni etrafında şekillenmelidir.