เหตุใด JVM stack-based และ Dalvik VM register-based?

ฉันสงสัยว่าเหตุใด Sun จึงตัดสินใจสร้าง JVM stack-based และ Google ตัดสินใจที่จะสร้าง DalvikVM register

ฉันคิดว่า JVM ไม่สามารถสันนิษฐานได้จริงๆว่ามีการลงทะเบียนจำนวนหนึ่งบนแพลตฟอร์มเป้าหมายเนื่องจากควรเป็นแพลตฟอร์มที่ไม่ขึ้นกับ ดังนั้นจึงเลื่อนการจัดสรรการลงทะเบียน ฯลฯ ไปยังคอมไพเลอร์ JIT (ช่วยแก้ให้ด้วยนะถ้าฉันผิด.)

พวกแอนดรอยด์ก็เลยคิดว่า "เฮ้มันไม่มีประสิทธิภาพไปขอ register ตาม vm ทันที ... "? แต่เดี๋ยวก่อนมีอุปกรณ์ Android ที่แตกต่างกันจำนวนการลงทะเบียนที่ Dalvik กำหนดเป้าหมาย? Dalvik opcodes ฮาร์ดโค้ดสำหรับการลงทะเบียนจำนวนหนึ่งหรือไม่

อุปกรณ์ Android ปัจจุบันทั้งหมดในตลาดมีจำนวนการลงทะเบียนเท่ากันหรือไม่? หรือมีการจัดสรรรีจิสเตอร์ซ้ำระหว่างการโหลด dex หรือไม่ ทั้งหมดนี้เข้ากันได้อย่างไร?

มีคุณลักษณะบางอย่างของ VM แบบสแต็กที่เข้ากันได้ดีกับเป้าหมายการออกแบบของ Java:

1. การออกแบบที่ใช้สแต็กทำให้มีข้อสันนิษฐานเกี่ยวกับฮาร์ดแวร์เป้าหมายน้อยมาก (การลงทะเบียนคุณสมบัติของ CPU) ดังนั้นจึงเป็นเรื่องง่ายที่จะใช้ VM กับฮาร์ดแวร์ที่หลากหลาย

2. เนื่องจากตัวถูกดำเนินการสำหรับคำแนะนำส่วนใหญ่โดยนัยรหัสออบเจ็กต์จึงมีแนวโน้มที่จะเล็กลง นี่เป็นสิ่งสำคัญหากคุณกำลังจะดาวน์โหลดโค้ดผ่านลิงก์เครือข่ายที่ช้า

การใช้รูปแบบการลงทะเบียนอาจหมายความว่าตัวสร้างโค้ดของ Dalvik ไม่จำเป็นต้องทำงานหนักเพื่อสร้างโค้ดที่มีประสิทธิภาพ การทำงานบนสถาปัตยกรรมที่มีการลงทะเบียนมากหรือมีการลงทะเบียนที่ไม่ดีน่าจะเป็นแต้มต่อ Dalvik แต่นั่นไม่ใช่เป้าหมายปกติ - ARM เป็นสถาปัตยกรรมที่อยู่ตรงกลางของถนน

ฉันลืมไปว่า Dalvik เวอร์ชันเริ่มต้นไม่ได้รวม JIT ไว้เลย หากคุณกำลังจะตีความคำแนะนำโดยตรงแผนแบบลงทะเบียนอาจเป็นผู้ชนะในการตีความ

ฉันไม่พบข้อมูลอ้างอิง แต่ฉันคิดว่า Sun ตัดสินใจใช้วิธี bytecode แบบสแต็กเนื่องจากทำให้ง่ายต่อการรัน JVM บนสถาปัตยกรรมที่มีรีจิสเตอร์น้อย (เช่น IA32)

ในDalvik VM Internalsจาก Google I / O 2008 Dan Bornsteinผู้สร้าง Dalvik ให้ข้อโต้แย้งต่อไปนี้สำหรับการเลือก VM แบบลงทะเบียนบนสไลด์ 35 ของสไลด์นำเสนอ :

ลงทะเบียนเครื่อง

ทำไม?

• หลีกเลี่ยงการจัดส่งคำสั่ง
• หลีกเลี่ยงการเข้าถึงหน่วยความจำโดยไม่จำเป็น
• ใช้กระแสคำสั่งอย่างมีประสิทธิภาพ (ความหนาแน่นของความหมายสูงขึ้นต่อคำสั่ง)

และในสไลด์ 36:

ลงทะเบียนเครื่อง

สถิติ

• คำแนะนำน้อยลง 30%
• หน่วยรหัสน้อยลง 35%
• เพิ่มไบต์ 35% ในสตรีมคำแนะนำ
  • แต่เราได้กินสองครั้ง

ตาม Bornstein นี่คือ "ความคาดหวังทั่วไปที่คุณจะพบเมื่อคุณแปลงชุดของไฟล์คลาสเป็นไฟล์ dex"

ส่วนที่เกี่ยวข้องของวิดีโอการนำเสนอเริ่มเวลา 25:00 น .

นอกจากนี้ยังมีบทความเชิงลึกที่มีชื่อว่า"Virtual Machine Showdown: Stack Versus Registers" โดย Shi et al (2005)ซึ่งสำรวจความแตกต่างระหว่างเครื่องเสมือนแบบสแต็กและรีจิสเตอร์

ฉันไม่รู้ว่าทำไมซันถึงตัดสินใจสร้าง JVM stack ตาม เครื่องเสมือน Erlangs, BEAM ถูกลงทะเบียนตามเหตุผลด้านประสิทธิภาพ และ Dalvik ดูเหมือนจะลงทะเบียนเนื่องจากเหตุผลด้านประสิทธิภาพ

จากPro Android 2 :

Dalvik ใช้รีจิสเตอร์เป็นหน่วยเก็บข้อมูลหลักแทนสแต็ก Google หวังว่าจะบรรลุคำแนะนำน้อยลง 30 เปอร์เซ็นต์ด้วยเหตุนี้

และเกี่ยวกับขนาดรหัส:

Dalvik VM ใช้ไฟล์คลาส Java ที่สร้างขึ้นและรวมเข้าเป็นไฟล์ Dalvik Executables (.dex) หนึ่งไฟล์ขึ้นไป นำข้อมูลที่ซ้ำกันจากไฟล์คลาสหลายไฟล์มาใช้ใหม่ช่วยลดความต้องการพื้นที่ (ไม่บีบอัด) ลงครึ่งหนึ่งจากไฟล์. jar แบบเดิมได้อย่างมีประสิทธิภาพ ตัวอย่างเช่นไฟล์. dex ของแอปพลิเคชันเว็บเบราว์เซอร์ใน Android มีขนาดประมาณ 200k ในขณะที่เวอร์ชัน. jar ที่ไม่มีการบีบอัดที่เทียบเท่าจะมีขนาดประมาณ 500k ไฟล์. dex ของนาฬิกาปลุกมีขนาดประมาณ 50k และมีขนาดประมาณสองเท่าในเวอร์ชัน. jar

และอย่างที่ฉันจำสถาปัตยกรรมคอมพิวเตอร์: แนวทางเชิงปริมาณยังสรุปได้ว่าเครื่องลงทะเบียนทำงานได้ดีกว่าเครื่องที่ใช้สแต็ก