Java, Ruby ve Python gibi diller için JIT derleyicileri hakkında çok fazla yutturmaca vardı. JIT derleyicileri C / C ++ derleyicilerinden nasıl farklıdır ve C / C ++ derleyicileri yalnızca derleyiciler olarak adlandırılırken, neden JIT derleyicileri Java, Ruby veya Python için yazılmış derleyicilerdir?
Yanıtlar:
JIT derleyicileri kodu anında, yürütmeden hemen önce veya yürütürken bile derler. Bu şekilde, kodun çalıştığı VM, yalnızca çalışma zamanı bilgileriyle mümkün olabilecek optimizasyonlara izin vermek için kod yürütmedeki kalıpları kontrol edebilir. Ayrıca, eğer VM derlenmiş versiyonun hangi nedenle olursa olsun yeterince iyi olmadığına karar verirse (örneğin, çok fazla önbellek eksikse veya belirli bir istisna attığında kod sık sık), daha akıllı bir şekilde yeniden derlemeye karar verebilir derleme.
Diğer taraftan, C ve C ++ derleyicileri geleneksel olarak JIT değildir. Geliştiricinin makinesinde yalnızca bir kez çekim yaparlar ve daha sonra bir çalıştırılabilir üretilirler.
JIT tam zamanında derleyici için kısa ve isim yanlış: çalışma zamanı sırasında kodun optimizasyonuna değer belirler ve bunları uygular. Normal derleyicilerin yerini almaz, ancak tercümanların bir parçasıdır. Ara kod kullanan Java gibi dillerin her ikisine de sahip olduğunu unutmayın : kaynak kodundan orta kod çevirisine normal bir derleyici ve performans artırıcı tercümana dahil edilen bir JIT.
Kod optimizasyonları kesinlikle "klasik" derleyiciler tarafından gerçekleştirilebilir, ancak asıl farkı not edin: JIT derleyicileri çalışma zamanında verilere erişebilir . Bu büyük bir avantaj; Açıkça kullanmak, açıkça zor olabilir.
Örneğin, şöyle bir kod düşünün:
m(a : String, b : String, k : Int) {
val c : Int;
switch (k) {
case 0 : { c = 7; break; }
...
case 17 : { c = complicatedMethod(k, a+b); break; }
}
return a.length + b.length - c + 2*k;
}
Normal bir derleyici bu konuda çok fazla şey yapamaz. Bununla birlikte, bir JIT derleyicisi mbunun yalnızca k==0bir nedenden dolayı çağrıldığını tespit edebilir (zamanla kod değiştiğinde böyle şeyler olabilir); daha sonra kodun daha küçük bir versiyonunu oluşturabilir (ve bunu kavramsal olarak küçük bir nokta olarak düşünmeme rağmen, onu yerel koda derleyin):
m(a : String, b : String) {
return a.length + b.length - 7;
}
Bu noktada, şu anda önemsiz olduğu için yöntem çağrısının satır içi bile büyük olasılıkla olacaktır.
Anlaşılan, Güneş javac, Java 6’da yapılan çoğu optimizasyonu reddetti ; Bu optimizasyonların JIT’in yapmasını zorlaştırdığı ve sonunda derlenen kodların daha hızlı çalıştığı söylendi. Git figürü.
mkontrol etmediği bir sürümü ile ko kanıtlamak mümkün olacağını beri molurdu asla olmayan bir sıfır ile çağrılabilir k, ancak bu bile o yerini alabilir kanıtlamak mümkün olmadan onunla static miss_count; if (k==0) return a.length+b.length-7; else if (miss_count++ < 16) { ... unoptimized code for m ...} else { ... consider other optimizations...}.
k=0 her zaman ise , bunun girdi veya ortamın bir işlevi olmadığı anlamına gelir, testi bırakmak güvenlidir - ancak bunun belirlenmesi çok pahalı ve dolayısıyla derleme zamanında uygun maliyetli olan statik analiz gerektirir. Bir JIT, bir kod bloğundan geçen bir yol diğerlerinden çok daha sık alındığında kazanabilir ve bu yol için uzmanlaşmış bir kodun sürümü daha hızlı olacaktır. Ancak JIT, hızlı yolun uygulanıp uygulanmadığını kontrol etmek için bir test yayacak ve eğer değilse "yavaş yolu" izleyecektir.
Base* pparametre alır ve bunun üzerinden sanal işlevleri çağırır; çalışma zamanı analizi, her zaman (veya hemen hemen her zaman) işaret edilen gerçek nesnenin Derived1türünde olduğunu gösterir. JIT, işlevin yeni bir sürümünü, Derived1yöntemlere statik olarak çözümlenmiş (hatta satır içi) çağrılarla üretebilir . Bu kodun önünde, seçilebilir pişaretçinin beklenen Derived1tabloya işaret edip etmediğini kontrol eden bir şartlı kural gelir ; eğer değilse, bunun yerine yavaş yavaş dinamik olarak çözülmüş yöntem çağrıları ile fonksiyonun orijinal versiyonuna atlar.