Mengapa berbasis tumpukan JVM dan berbasis register VM Dalvik?

Saya penasaran, mengapa Sun memutuskan untuk membuat JVM berbasis tumpukan dan Google memutuskan untuk membuat berbasis register DalvikVM?

Saya kira JVM tidak dapat benar-benar berasumsi bahwa sejumlah register tersedia pada platform target, karena itu seharusnya platform independen. Oleh karena itu hanya menunda alokasi register dll, ke kompilator JIT. (Koreksi saya jika saya salah.)

Jadi orang-orang Android berpikir, "hei, itu tidak efisien, mari kita langsung mendaftar vm berbasis ..."? Tapi tunggu, ada beberapa perangkat Android yang berbeda, berapa register yang ditargetkan Dalvik? Apakah opcode Dalvik di-hardcode untuk sejumlah register tertentu?

Apakah semua perangkat Android yang ada di pasaran memiliki jumlah register yang kurang lebih sama? Atau, apakah ada alokasi ulang register yang dilakukan selama dex-loading? Bagaimana semua ini cocok?

— aioobe
sumber

Apakah itu keputusan Google untuk membuat berbasis register DalvikVM? Saya pikir DalvikVM diimplementasikan sebelum Google mengakuisisi Android Inc.

— RoboAlex

Anda benar tentu saja. (Tidak terlalu relevan dengan pertanyaan itu;)

— aioobe

Jawaban:

Ada beberapa atribut VM berbasis tumpukan yang cocok dengan tujuan desain Java:

Desain berbasis tumpukan membuat sangat sedikit asumsi tentang perangkat keras target (register, fitur CPU), sehingga mudah untuk menerapkan VM pada berbagai perangkat keras.
Karena operan untuk instruksi sebagian besar implisit, kode objek akan cenderung lebih kecil. Ini penting jika Anda akan mengunduh kode melalui tautan jaringan yang lambat.

Menggunakan skema berbasis register mungkin berarti generator kode Dalvik tidak harus bekerja keras untuk menghasilkan kode yang berkinerja baik. Berjalan pada arsitektur yang sangat kaya register atau register-miskin mungkin akan melumpuhkan Dalvik, tetapi itu bukan target yang biasa - ARM adalah arsitektur yang sangat menengah.

Saya juga lupa bahwa versi awal Dalvik tidak menyertakan JIT sama sekali. Jika Anda akan menafsirkan instruksi secara langsung, maka skema berbasis register mungkin adalah pemenang untuk kinerja interpretasi.

— Mark Bessey
sumber

Oke, itu menarik. Jadi, apakah DalvikVM mengasumsikan sejumlah minimal register pada perangkat target?

— aioobe

Juga, saya telah membaca bahwa beberapa orang menginstal Android di laptop mereka karena ini adalah os "ringan" ... Sepertinya ide yang buruk jika laptop bukan ARM, dan mungkin memiliki arsitektur dengan banyak register?

— aioobe

ok, saya baru saja mengetahui bahwa bytecode dex didefinisikan dalam istilah mesin register tak terbatas, dan dalam hal efisiensi, tampaknya sebagian besar tentang tapak memori.

— aioobe

Saya tidak dapat mengingat apakah Dalvik berbasis register tak terbatas, atau memiliki ukuran file register tetap. Jika tidak terbatas, maka akan cenderung bekerja secara optimal pada arsitektur yang memiliki register "cukup" untuk kode apa pun yang Anda jalankan.

— Mark Bessey

Penjelasan lebih detail dapat ditemukan di sini: markfaction.wordpress.com/2012/07/15/…

— noego

Saya tidak dapat menemukan referensi, tetapi saya pikir Sun memutuskan untuk pendekatan bytecode berbasis tumpukan karena membuatnya mudah untuk menjalankan JVM pada arsitektur dengan beberapa register (misalnya IA32).

Dalam Dalvik VM Internal dari Google I / O 2008, pencipta Dalvik Dan Bornstein memberikan argumen berikut untuk memilih VM berbasis register pada slide 35 slide presentasi :

Daftarkan Mesin

Mengapa?

hindari pengiriman instruksi

hindari akses memori yang tidak perlu

mengkonsumsi aliran instruksi secara efisien (kepadatan semantik yang lebih tinggi per instruksi)

dan pada slide 36:

Daftarkan Mesin

Statistik

30% lebih sedikit instruksi

35% lebih sedikit unit kode

35% lebih banyak byte dalam aliran instruksi

tapi kita bisa mengkonsumsinya sekaligus

Menurut Bornstein, ini adalah "ekspektasi umum yang dapat Anda temukan ketika Anda mengonversi sekumpulan file kelas ke file dex".

Bagian yang relevan dari video presentasi dimulai pukul 25.00 .

Ada juga makalah berwawasan berjudul "Virtual Machine Showdown: Stack Versus Registers" oleh Shi et al. (2005) , yang mengeksplorasi perbedaan antara mesin virtual berbasis stack dan register.

— Mengalir
sumber

Saya tidak tahu mengapa Sun memutuskan untuk membuat JVM stack based. Erlangs mesin virtual, BEAM mendaftar berdasarkan alasan kinerja. Dan Dalvik juga tampaknya berbasis register karena alasan kinerja.

Dari Pro Android 2 :

Dalvik menggunakan register sebagai unit penyimpanan data utama, bukan tumpukan. Hasilnya, Google berharap dapat menyelesaikan instruksi 30 persen lebih sedikit.

Dan mengenai ukuran kode:

VM Dalvik mengambil file kelas Java yang dihasilkan dan menggabungkannya menjadi satu atau beberapa file Dalvik Executables (.dex). Ini menggunakan kembali informasi duplikat dari beberapa file kelas, secara efektif mengurangi kebutuhan ruang (tidak terkompresi) hingga setengahnya dari file .jar tradisional. Misalnya, file .dex dari aplikasi browser web di Android berukuran sekitar 200k, sedangkan versi .jar yang tidak terkompresi berukuran sekitar 500k. File .dex dari jam alarm berukuran sekitar 50k, dan kira-kira dua kali ukuran itu dalam versi .jar-nya.

Dan seperti yang saya ingat Arsitektur Komputer: Pendekatan Kuantitatif juga menyimpulkan bahwa mesin register berkinerja lebih baik daripada mesin berbasis tumpukan.

— Jonas
sumber

Jika saya harus menebak, saya akan mengatakan Sun memutuskan untuk membuat JVM stack berbasis karena lebih mudah diimplementasikan daripada mesin register. (Tetapi dengan biaya kinerja yang tidak sepele, seperti yang disebutkan di sini.)

— Mason Wheeler

Saya tidak dapat menemukan referensi, tetapi saya pikir Sun memutuskan untuk pendekatan bytecode berbasis tumpukan karena membuatnya mudah untuk menjalankan JVM pada arsitektur register rendah.

— Alur

Untuk ISA perangkat keras, ya mesin register telah menang. Pada dasarnya setiap CPU / mikrokontroler adalah mesin register, karena yang lainnya menyebalkan jika dibandingkan. Beberapa memiliki register yang sangat sedikit , seperti hanya akumulator dan mungkin satu atau dua pointer atau register indeks, tetapi itu masih lebih seperti mesin register dalam pengertian teori komputasi. Tapi kita berbicara tentang VM yang diinterpretasikan , jadi "register file" jika ada akan benar-benar ada di memori. Kecuali jika Anda mengompilasi JIT ke kode mesin asli. Alasannya sangat berbeda karena reg lebih cepat daripada tumpukan.

— Peter Cordes