Kaynak kodun Java bayt koduna dönüştürülmesinin kullanımı nedir?

Biri farklı mimariler için farklı JVM'lere ihtiyaç duyuyorsa, bu konsepti ortaya koymanın mantığının ne olduğunu çözemiyorum. Diğer dillerde, farklı makineler için farklı derleyicilere ihtiyacımız var, ancak Java'da farklı JVM'lere ihtiyacımız var, bu nedenle JVM veya bu fazladan bir adım kavramı tanıtmanın arkasındaki mantık nedir?

Mantık JVM bayt kodunun Java kaynak kodundan çok daha basit olmasıdır.

Derleyiciler, oldukça soyut bir düzeyde, üç temel bölüme sahip olarak düşünülebilir: ayrıştırma, anlamsal analiz ve kod oluşturma.

Ayrıştırma, kodu okumaktan ve derleyicinin hafızasındaki bir ağaç temsiline dönüştürmekten ibarettir. Anlamsal analiz, bu ağacı analiz ettiği, ne anlama geldiğini belirleyen kısımdır ve tüm üst düzey yapıları daha düşük seviyeli yapılara indirgemektedir. Kod oluşturma, basitleştirilmiş ağacı alır ve düz bir çıktıya yazar.

Bir bayt kodu dosyasıyla, ayrıştırma aşaması büyük ölçüde basitleştirilmiştir, çünkü özyinelemeli (ağaç yapılı) bir kaynak dil yerine JIT'in kullandığı düz bayt akış biçiminde yazılmıştır. Ayrıca, anlamsal analizlerin ağır kaldırılmasının çoğu Java (veya başka bir dil) derleyicisi tarafından gerçekleştirilmiştir. Tek yapması gereken, kodu akış okuma, minimum ayrıştırma ve minimum anlamsal analiz yapmak ve ardından kod oluşturma işlemini yapmak.

Bu, JIT'nin çok daha basit bir performans sergilemesini ve bu nedenle yürütülmesi çok daha hızlı olmasını sağlarken, tek satırlık, çapraz platform kodunu teorik olarak yazmayı mümkün kılan üst düzey meta verileri ve anlamsal bilgileri korurken.

Derleyici / çalışma zamanı tasarımında, birkaç nedenden dolayı çeşitli türlerin ara gösterimleri giderek yaygınlaşmaktadır.

Java örneğinde, başlangıçta bir numaralı neden muhtemelen taşınabilirlikti : Java başlangıçta "Bir Kez Yaz, Herhangi Bir Yere Çalıştır" olarak pazarlanmıştı. Bunu kaynak kodunu dağıtarak ve farklı platformları hedeflemek için farklı derleyiciler kullanarak başarabilirsiniz, bunun birkaç dezavantajı var:

• derleyiciler, dilin tüm uygunluk sözdizimlerini anlamak zorunda olan karmaşık araçlardır; Bayt kodu, makinede çalıştırılabilir koda, insan tarafından okunabilen kaynaktan daha yakın olduğundan daha basit bir dil olabilir; Bunun anlamı:
  • derleme bayt kodunu çalıştırmaya kıyasla yavaş olabilir
  • farklı platformları hedefleyen derleyiciler farklı davranışlar üretebilir veya dil değişikliklerine ayak uyduramazlar
  • Yeni bir platform için bir derleyici üretmek, bu platform için bir VM (veya bytecode-yerel derleyici) üretmekten çok daha zordur.
• kaynak kodunun dağıtılması her zaman arzu edilmez; bytecode tersine mühendislikten korunma için bazı koruma sağlar (kasıtlı bir şekilde gizlenmediği sürece derleme işlemi hala oldukça kolaydır)

Ara gösterimin diğer avantajları arasında şunlar bulunmaktadır:

• optimizasyon , desen byte gördü ve daha hızlı eşdeğerlerine aşağı derlenmiş, hatta programı çalışır gibi özel durumlar için optimize edilebilir ( "Tam Zamanında" a "JIT" seçeneğini kullanarak veya derleyici)
• aynı VM'deki birden fazla dil arasında birlikte çalışabilirlik ; bu, JVM (örneğin Scala) ile popüler hale gelmiştir ve .net çerçevesinin açık amacıdır.

Neden sadece kaynak kodunu dağıtmadığımızı merak ediyor gibisiniz. Bu soruyu tersine çevireyim: neden sadece makine kodunu dağıtmıyoruz?

Açıkçası buradaki cevap, Java’nın tasarım gereği, kodunuzun hangi makinede çalışacağını bildiğini varsaymamasıdır; bir masaüstü, bir süper bilgisayar, bir telefon veya aralarında ve ötesinde herhangi bir şey olabilir. Java yerel JVM derleyicisinin işini yapması için yer bırakıyor. Kodunuzun taşınabilirliğini arttırmanın yanı sıra, derleyicinin, varsa makineye özgü optimizasyonlardan faydalanma veya varsa en azından çalışma kodunu üretme gibi şeyleri yapmalarına izin vermek de güzel bir avantaja sahiptir. SSE talimatları veya donanım hızlandırması gibi şeyler sadece onları destekleyen makinelerde kullanılabilir.

Bu açıdan bakıldığında, ham kaynak kodunda bayt kodunun kullanılmasının nedeni daha açıktır. Ham makine diline mümkün olduğunca yaklaşmak, aşağıdaki gibi makine kodunun bazı avantajlarını gerçekleştirmemize veya kısmen gerçekleştirmemize izin verir:

• Daha hızlı başlangıç ​​zamanları, derleme ve analizlerin bir kısmı zaten yapıldığından.
• Güvenlik, bayt kodu biçiminde, dağıtım dosyalarını imzalamak için yerleşik bir mekanizmaya sahip olduğundan (kaynak bunu kurallara uygun olarak yapabilir, ancak bunu gerçekleştirme mekanizması, bayt kodunda olduğu gibi yerleşik değildir).

Daha hızlı işlemden bahsetmediğime dikkat edin. Hem kaynak kodu hem de bayt kodu, gerçek uygulama için aynı makine koduna tamamen derlenebilir veya olabilir (teoride).

Ek olarak, bayt kodu, makine kodu üzerinde bazı geliştirmelere izin verir. Elbette daha önce bahsettiğim platform bağımsızlığı ve donanıma özgü optimizasyonlar var, ancak JVM derleyicisine eski koddan yeni yürütme yolları üretmek için hizmet vermek gibi şeyler de var. Bu, güvenlik sorunlarını düzeltmek veya yeni optimizasyonlar keşfedilmişse veya yeni donanım talimatlarından yararlanmak olabilir. Uygulamada, bu şekilde büyük değişikliklerin görülmesi nadirdir, çünkü böcekleri açığa çıkarır, ancak bu mümkündür ve her zaman küçük yollarla gerçekleşen bir şeydir.

Burada en az iki farklı olası soru var gibi görünüyor. Bunlardan biri genel olarak derleyicilerle ilgilidir, Java temelde türün bir örneği. Diğeri, kullandığı belirli bayt kodlarını Java'ya özgüdür.

Genel olarak derleyiciler

Öncelikle genel soruyu düşünelim: neden bir derleyici belirli bir işlemci üzerinde çalışmak için kaynak kodu derleme sürecinde neden bir ara temsil kullanıyor?

Karmaşıklık Azaltma

Bunun bir cevabı oldukça basittir: O (N * M) problemini O (N + M) problemine dönüştürür.

Eğer N kaynak dilleri ve M hedefleri verilirse ve her derleyiciden tamamen bağımsız olursak, o zaman bütün bu kaynak dilleri tüm bu hedeflere çevirmek için N * M derleyicilerine ihtiyacımız var (burada bir "hedef" bir gibi bir kombinasyondur) işlemci ve işletim sistemi).

Bununla birlikte, tüm bu derleyiciler ortak bir ara temsil üzerinde hemfikirse, o zaman kaynak dilleri ara gösterime çeviren N derleyici ön uçlarına ve ara gösterimi belirli bir hedef için uygun bir şeye çeviren M derleyici arka uçlarına sahip olabiliriz.

Problem Segmentasyonu

Daha da iyisi, sorunu iki veya daha fazla ayrıcalıklı alana ayırır. Dil tasarımını, ayrıştırmayı ve bunun gibi şeyleri bilen / önemseyen insanlar, derleyici ön uçlarına konsantre olabilirken, komut setleri, işlemci tasarımı ve bunun gibi şeyleri arka uçta yoğunlaştırabilen insanlar.

Örneğin, LLVM gibi bir şey verildiğinde, farklı diller için birçok ön uçumuz var. Ayrıca birçok farklı işlemci için arka uçlarımız var. Bir dil adamı dili için yeni bir ön uç yazabilir ve hızlıca birçok hedefi destekleyebilir. İşlemci bir adam, dil tasarımı, ayrıştırma vb. İle uğraşmadan hedefi için yeni bir arka uç yazabilir.

Derleyicileri ön uç ve arka uç olarak ayırmak, ikisi arasında iletişim kurmak için bir ara temsil ile Java ile orijinal değildir. Uzun zamandır oldukça yaygın bir pratikti (Java gelmeden önce de zaten).

Dağıtım Modelleri

Java'nın bu konuda yeni bir şey eklediği ölçüde, dağıtım modelindeydi. Özellikle, derleyiciler uzun süre dahili olarak ön uç ve arka uç parçalarına ayrılsa da, tipik olarak tek bir ürün olarak dağıtıldılar. Örneğin, bir Microsoft C derleyicisi satın aldıysanız, dahili olarak sırasıyla "ön uç ve arka uç" olan bir "C1" ve "C2" ye sahipti. adet (ikisi arasında işlemleri koordine bir "derleyici sürücüsü" ile). Derleyici iki parça halinde oluşturulmuş olsa da, derleyiciyi kullanan normal bir geliştiriciye, kaynak kodundan nesne koduna çevrilmiş, aralarında hiçbir şey görünmeyen tek bir şeydi.

Java, bunun yerine, Java Geliştirme Seti'nde ön ucu ve Java Sanal Makinesi'nde arka ucu dağıttı. Her Java kullanıcısının kullandığı sistemi hedeflemek için bir derleyici arka ucu vardı. Java geliştiricileri ara formatta kod dağıttı, bu yüzden bir kullanıcı yüklediğinde, JVM kendi makinelerinde çalıştırmak için ne gerekiyorsa yaptı.

emsal

Bu dağıtım modelinin de tamamen yeni olmadığını unutmayın. Örneğin, UCSD P-sistemi benzer şekilde çalıştı: derleyici ön uçları P-kodu üretti ve P-sisteminin her kopyası, söz konusu hedef ^1'de P-kodunu yürütmek için gerekli olanı yapan sanal bir makine içeriyordu .

Java bayt kodu

Java bayt kodu P koduna oldukça benzer. Bu oldukça basit bir makine için temelde bir talimattır . Bu makinenin mevcut makinelerin bir soyutlaması olması amaçlanmıştır, bu nedenle hemen hemen her belirli hedefe hızlı bir şekilde çevirmek oldukça kolaydır. Çeviri kolaylığı erken dönemde önemliydi, çünkü asıl amaç, P-System'in yaptığı gibi bayt kodlarını yorumlamaktı (ve evet, tam olarak ilk uygulamaların işleyiş şekli buydu).

Güçlü

Java bayt kodu derleyici ön uç üretmek için kolaydır. (Örneğin) bir ifadeyi temsil eden oldukça tipik bir ağacınız varsa, ağacı geçmek ve her düğümde bulduklarınızdan doğrudan kod oluşturmak oldukça kolaydır.

Java bayt kodları oldukça kompakt - çoğu durumda, çoğu tipik işlemcilerin (ve özellikle de Java'yı tasarlarken Sun'ın sattığı SPARC gibi çoğu RISC işlemcileri için) kaynak kodlarından veya makine kodlarından çok daha küçüktür. Bu özellikle önemliydi, çünkü Java’nın büyük bir niyeti, çoğu kişinin bize telefon hatları üzerinden 28.8’de modemler aracılığıyla erişdiği bir zamanda, uygulamaları - web sayfalarına gömülü kodları - desteklemekti. Saniyedeki kilobit sayısı (tabii ki, daha eski ve daha yavaş modem kullanan birkaç kişi vardı).

Zayıf Yönler

Java bayt kodlarının en büyük zayıflığı, özellikle anlamlı olmadıklarıdır. Java'da bulunan kavramları oldukça iyi ifade edebilmelerine rağmen, Java'nın bir parçası olmayan kavramları ifade etmek için neredeyse çok iyi çalışmıyorlar. Benzer şekilde, çoğu makinede bayt kodlarını çalıştırmak kolay olmakla birlikte, herhangi bir makineden tam olarak yararlanabilecek şekilde daha zordur.

Örneğin, eğer gerçekten Java byte kodlarını optimize etmek isterseniz, temelde temsil etmek gibi, makine kodundan geriye çevirmek ve geri SSA talimatlarına (veya benzer bir şey) haline getirmek için bazı ters mühendislik yapmak oldukça rutin ² . Daha sonra, optimizasyonunuzu yapmak için SSA talimatlarını değiştirirsiniz, ardından oradan gerçekten ilgilendiğiniz mimariyi hedefleyen bir şeye çevirirsiniz. Bununla birlikte, oldukça karmaşık olan bu süreçte bile, Java'ya yabancı olan bazı kavramların, bazı kaynak dillerden, çoğu tipik makinede en iyi şekilde çalışan (hatta yakın) makine koduna çevrilmesinin zor olduğunu ifade etmek yeterince zordur.

özet

Genel olarak ara temsilleri neden kullandığınızı soruyorsanız, iki ana faktör şunlardır:

1. Bir O (N * M) problemini O (N + M) problemine azaltın ve
2. Sorunu daha yönetilebilir parçalara ayırın.

Java bayt kodlarının özelliklerini ve neden bu belirli temsili başka bir seçtikleri yerine seçtiklerini soruyorsanız, o zaman cevabın büyük ölçüde orijinal niyetlerine ve webin sınırlamalarına geri döndüğünü söyleyebilirim. aşağıdaki önceliklere öncülük eder:

1. Kompakt gösterim
2. Çözülmesi ve yürütülmesi hızlı ve kolaydır.
3. Yaygın olarak kullanılan makinelerde hızlı ve kolaydır.

Birçok dili temsil edebilmek veya çok çeşitli hedeflerde en iyi şekilde uygulama yapabilmek çok daha düşük önceliklerdir (eğer öncelikler olarak kabul edilmişlerse).

1. Peki neden P-sistemi çoğunlukla unutulur? Çoğunlukla bir fiyatlandırma durumu. P-sistemi Apple II, Commodore SuperPets, vb. Cihazlarda oldukça nezih satıldı. IBM PC çıktığında, P sistemi desteklenen bir işletim sistemi idi, ancak MS-DOS daha ucuza mal oldu (çoğu insanın bakış açısından aslında bedavaya verildi) ve Microsoft ve IBM'in (diğerlerinin yanı sıra) yazdığı şeyden dolayı hızla daha fazla program hazırladı.
2. Örneğin, Soot böyle işler.

Diğer insanların işaret ettiği avantajlara ek olarak, bytecode çok daha küçüktür, bu nedenle dağıtılması ve güncellenmesi daha kolaydır ve hedef ortamda daha az yer kaplar. Bu, özellikle çok yer kısıtlı ortamlarda önemlidir.

Ayrıca telif hakkıyla korunan kaynak kodunu korumayı kolaylaştırır.

Bunun anlamı, byte kodundan makine koduna derlemenin, orijinal kodunuzu tam zamanında makine koduna çevirmekten daha hızlı olmasıdır. Ancak, uygulamamızı çapraz platform yapmak için yorumlara ihtiyacımız var, çünkü orijinal kodumuzu her platformda değişiklik yapmadan ve herhangi bir hazırlık olmadan (derlemeler) kullanmak istiyoruz. Böylece ilk javac kaynağımızı bayt kodunu derler, sonra bu bayt kodunu herhangi bir yerde çalıştırabiliriz ve Java Virtual Machine tarafından kodunu daha hızlı bir şekilde makineye çevirir. Cevap: zaman kazandırır.

Başlangıçta, JVM saf bir tercümandı . Ayrıca, yorumladığınız dil mümkün olduğu kadar basitse , en iyi performans gösteren tercümanı elde edersiniz . Bayt kodunun amacı buydu: Çalışma zamanı ortamına verimli bir şekilde yorumlanabilir girdi sağlamak. Bu tek karar, Java'yı, performansıyla değerlendirildiği gibi, derlenmiş bir dile, yorumlanmış bir dile daha yaklaştırdı.

Ancak daha sonra, yorumlayıcı JVM'lerin performansının hala berbat olduğu anlaşıldığı zaman, insanlar iyi performans gösteren tam zamanlı derleyiciler oluşturmak için çaba harcadılar. Bu biraz C ve C ++ gibi daha hızlı diller arasındaki boşluğu kapattı. (Bazı Java doğal hız sorunları devam etse de, muhtemelen yazılı C kodunun yanı sıra performans gösteren bir Java ortamına sahip olamayacaksınız.)

Tabii ki, el altında just-in-time derleme teknikleri ile, biz olabilir aslında dağıtılmasına kaynak koduna geri dönmek ve sadece zamanında makine koduna derleme. Ancak, kodun ilgili tüm kısımları derleninceye kadar başlatma performansını büyük oranda azaltır. Bayt kodu, burada hala önemli bir yardımdır çünkü eşdeğer Java kodundan ayrıştırmak çok daha kolaydır.

Metin Kaynak Kodu, bir insan tarafından okunması ve değiştirilmesi kolay olan bir yapıdır .

Bayt kodu, bir makine tarafından okunması ve çalıştırılması kolay olan bir yapıdır .

Tüm JVM kodları ile yaptığı için okunup çalıştırıldığı için byte kodu JVM tarafından tüketilmeye daha uygun olur.

Henüz bir örnek olmadığını fark ettim. Aptal Sözde Örnekler:

//Source code
i += 1 + 5 * 2 + x;

// Byte code
i += 11, i += x
____

//Source code
i = sin(1);

// Byte code
i = 0.8414709848
_____

//Source code
i = sin(x)^2+cos(x)^2;

// Byte code (actually that one isn't true)
i = 1

Elbette bayt kodu sadece optimizasyonlarla ilgili değil. Bunun büyük bir kısmı, bir yöntem "foo" ya atıfta bulunurken, sınıfın dosyada daha aşağı bir yerde "foo" adlı bir üye içerip içermediğini kontrol etmek gibi karmaşık kuralları önemsemeden kod çalıştırabilmektir.