JVM neden JIT kodu derlemiyor?

Sun'ın kanonik JVM uygulaması, kod birkaç kez çalıştırıldıktan sonra neredeyse yerel yürütme hızları elde etmek için bayt koduna oldukça karmaşık bir optimizasyon uygular.

Soru şudur, bu derlenmiş kod neden aynı işlevin / sınıfın sonraki kullanımları sırasında kullanılmak üzere diske önbelleğe alınmıyor?

Mevcut haliyle, bir program her çalıştırıldığında, JIT derleyicisi, kodun önceden derlenmiş bir sürümünü kullanmak yerine yeniden başlar. Bayt kodu esasen yorumlanırken, bu özelliğin eklenmesi programın ilk çalışma süresine önemli bir artış sağlamaz mı?

@ MYYN'nin gönderdiği bağlantıyı kesip yapıştırmaya başvurmadan, bunun JVM'nin gerçekleştirdiği optimizasyonların statik değil, daha çok veri kalıplarına ve kod kalıplarına dayalı olarak dinamik olduğundan şüpheleniyorum. Bu veri modellerinin uygulamanın ömrü boyunca değişmesi ve önbelleğe alınan optimizasyonları optimumdan daha az hale getirmesi muhtemeldir.

Dolayısıyla, kaydedilen optimizasyonların hala optimal olup olmadığını belirlemek için bir mekanizmaya ihtiyacınız olacak, bu noktada sadece anında yeniden optimize edebilirsiniz.

Oracle'ın JVM'sinin gerçekten bunu yaptığı belgelenmiştir - Oracle'dan alıntı yaparak,

derleyici, isteğe bağlı olarak veritabanı çağrıları, oturumları veya örneklerinde derlenmiş Java yöntemlerini sürdürmek için Oracle JVM'nin sınıf çözümleme modelinden yararlanabilir. Bu tür bir kalıcılık, anlamsal olarak Java kodunun değişmediği bilindiğinde, oturumlar veya örnekler arasında gereksiz yeniden derlemelerin ek yükünü önler.

Tüm karmaşık sanal makine uygulamalarının neden benzer seçenekler sunmadığını bilmiyorum.

Mevcut yanıtlara güncellendi - Java 8, bunu çözmeye adanmış bir JEP'e sahiptir:

=> JEP 145: Önbellek Derlenmiş Kod . Yeni bağlantı .

Çok yüksek bir düzeyde, belirtilen amacı şudur :

Büyük Java uygulamalarının başlatma süresini iyileştirmek için önceki çalıştırmalardan derlenmiş yerel kodu kaydedin ve yeniden kullanın.

Bu yardımcı olur umarım.

Excelsior JET , 2001'de piyasaya sürülen 2.0 sürümünden beri bir önbelleğe alma JIT derleyicisine sahiptir. Ayrıca, AOT derleyicisi tüm optimizasyonları kullanarak önbelleği tek bir DLL / paylaşılan nesne olarak yeniden derleyebilir.

JVM uygulamasına hiçbir şekilde dahil olmadığım için gerçek nedenleri bilmiyorum, ancak bazı makul nedenler düşünebilirim:

• Java fikri, her yere bir kez yazılabilen bir dil olmaktır ve sınıf dosyasına önceden derlenmiş şeyler koymak bunu bir nevi ihlal eder (sadece "tür" çünkü tabii ki gerçek bayt kodu hala orada olacaktır)
• Bu, sınıf dosya boyutlarını artırır, çünkü orada aynı koda birden çok kez sahip olursunuz, özellikle aynı programı birden fazla farklı JVM altında çalıştırırsanız (bu, farklı sürümlerin farklı JVM'ler olduğunu düşündüğünüzde çok da nadir değildir. gerçekten yapmak zorunda)
• Sınıf dosyalarının kendileri yazılabilir olmayabilir (bunu kontrol etmek oldukça kolay olsa da)
• JVM optimizasyonları kısmen çalışma zamanı bilgilerine dayalıdır ve diğer çalıştırmalarda uygulanabilir olmayabilir (yine de bazı faydalar sağlamaları gerekir)

Ama gerçekten tahmin ediyorum ve gördüğünüz gibi, nedenlerimin gerçek şovları durdurduğunu düşünmüyorum. Sun'un bu desteği bir öncelik olarak görmediğini düşünüyorum ve belki de ilk nedenim gerçeğe yakın, çünkü bunu alışkanlıkla yapmak insanları Java sınıf dosyalarının gerçekten olmak yerine her VM için ayrı bir sürüme ihtiyaç duyduğunu düşünmeye sevk edebilir. çapraz platform.

Tercih ettiğim yöntem, aslında önceden açıkça böyle bir şey yapmak için kullanabileceğiniz ayrı bir bayt kodu-yerel çevirmene sahip olmak, belirli bir sanal makine için açıkça oluşturulmuş sınıf dosyaları oluşturmak ve muhtemelen orijinal bayt kodu ile içlerinde olmaktır. farklı VM'lerle de çalışabilir. Ama bu muhtemelen benim deneyimimden kaynaklanıyor: Çoğunlukla Java ME yapıyorum, Java derleyicisinin derleme konusunda daha akıllı olmaması gerçekten canımı yakıyor.